RAG 效果差？可能是你的“分块策略”没选对！

刚接触 RAG时，很多人都会有一个疑问：“现在的大模型上下文不是已经很大了吗？为什么还要把文章切碎？

其实原因很简单：大模型上下文变大，并不意味着“整篇文档直接塞进去”就是最优解。

真正的问题，不是“能不能放进去”。而是：模型能不能精准找到答案。

为什么不能把整篇文章直接“喂”给大模型？

很多人刚做 RAG 时，会采用一种最直觉的方案：直接把整篇文章拼接 Prompt，让 LLM 自己找答案。这种方案理论上可行，但实际很快会遇到几个严重问题。

主要原因有几个：

• 上下文窗口有限：尽管模型能力在增强，但面对海量的企业知识库（如数百万字的文档），整篇输入依然会超出限制。
• 信噪比与“迷失”：即使模型能装下，在数以万计的文字中寻找一个具体答案，就像在大海里捞针。信息过载会导致模型“走神”，不仅推理成本高昂，还容易因为噪音太多而产生幻觉或忽略关键细节。

因此，“化整为零”是必由之路。我们需要在数据进入向量数据库之前，通过“文本分块”将长文档转化为一个个语义独立的小片段。

常见的分块策略：从入门到精通

分块策略的选择，本质上是在计算成本与语义完整性之间做权衡。我们可以将其分为三个层级：

基础策略：基于规则的“硬切”

这一层级的策略不关心文本内容，只关心“切在哪里”。

固定大小分块

• 原理：每隔固定数量的字符或 Token 切一刀。
• 评价：实现最简单，但极其暴力。它往往会切断句子甚至单词，导致严重的语义丢失，不推荐在生产环境单独使用。

重叠分块

• 原理：在固定切分的基础上，引入重叠区域（例如 10%-20%）。
• 评价：相比固定分块，它缓解了边界处的语义断裂，但本质上依然是“盲目”切割，且会增加存储冗余。

递归分块

例如：先按章节切->再按段落切->再按句子切->最后才按字符切

• 定义：先尝试用最大的分隔符切，切完如果某个块还是太大，就换一个更小的分隔符继续切，直到所有块都在 chunkSize 以内。

• 评价：目前最通用的基准策略。它在一定程度上兼顾了语义结构（段落/句子）和块大小控制。
• 局限：依然依赖预设的分隔符，对于格式混乱的文本效果不佳。

进阶策略：基于语义的“智能切”

上述策略都有一个共同局限：它们都不理解文本在说什么。语义分块引入了 AI 模型来辅助决策。

语义分块

• 流程：
  • 先将文本按句子拆分。
  • 对每个句子生成向量。
  • 计算相邻句子之间的向量相似度。
  • 当相似度低于某个阈值时，说明话题发生了转换，在此处进行切割。
• 评价：
  • 优点：切割点基于语义而非标点，生成的每个块主题高度内聚，检索精度最高。
  • 缺点：需要调用 Embedding 模型，每个句子都做向量化，计算成本高，延迟大，且相似度阈值难调，太高切不动，太低切太碎。
• 适用场景：法律文档、医疗知识库、金融合规等对精度要求极高的领域。

高级策略：混合分块

为了兼顾效果与效率，工业界常采用混合策略。

常见策略：

• 递归+语义

  • 流程：先用递归分块做粗切，把文本按段落、章节切成大块；然后对每个大块再用语义分块做细切。

• 按照文档类型选策略

• 分块 + 后处理

  • 先用递归分块切完，然后对结果做一轮后处理：合并太短的块、拆分太长的块、给每个块补充元数据.

优缺点：

• 优点：灵活，能针对不同内容选择最合适的策略，整体效果最好.

• 缺点：实现复杂度高，需要维护多套分块逻辑和路由规则.

策略总结与选型建议

没有一种分块策略是万能的，最佳选择取决于你的文档类型和应用场景。