乐于分享
好东西不私藏

文档切多大才好搜?分块的艺术

文档切多大才好搜?分块的艺术

文档切多大才好搜?分块的艺术

吴恩达新课《RAG》解读 · 第 5 篇(共 10 篇)

引子:把一整本书压成一个向量,是灾难

假设你的知识库有 1000 本书。最省事的做法是:每本书用嵌入模型变成一个向量,存进向量库。

听起来没问题?问题很大——你在把整本书的含义压缩进一个向量

一本几十万字的书,可能讲了十几个主题。一个向量表达不了这么多内容,只能"平均"成一个模糊的影子。结果就是:搜什么都搜不准,因为每个向量都"什么都是又什么都不是"。

更糟的是,一旦命中,你返回给 LLM 的是一整本书——几句话的提问,塞过去几十万字,瞬间撑爆 LLM 的上下文窗口。

所以 RAG 系统里几乎必做的一步是:把长文档切成小块(chunk),每块单独做向量。 这就叫 chunking(分块)

一、为什么要分块

三个理由:

  1. 1. 嵌入模型有长度上限:大多数嵌入模型只能处理有限长度(几百到几千 token)的输入,太长直接报错或截断
  2. 2. 提升检索精度:小块的主题更聚焦,向量能更"尖锐"地表达一个具体话题,搜得准
  3. 3. 省 LLM 上下文窗口:只把最相关的几小块发给 LLM,而不是整篇文档,既省钱又留余地

切完之后,你的 1000 本书可能变成 100 万个段落——但向量数据库轻松扛得住。

二、块大小:太大太小都不行

这是个需要权衡的关键参数:

  • • 切太大(比如按章)→ 又回到"一个向量塞太多主题"的老问题,且很快塞满上下文窗口
  • • 切太小(比如按词)→ 每个向量失去周围句子的上下文,搜得也不准
  • • 按句子 → 还是常常太碎

没有万能尺寸,通常在"一次能捕捉一个完整小话题"的粒度上找平衡。

三、四种主流分块策略

最简单

看结构

看意思

用模型

原始文档
分块策略
固定尺寸分块如每 500 字符
递归字符分割按换行/段落切
语义分块按含义转折切
LLM 分块让模型决定边界
向量库

1. 固定尺寸分块(最常用起手)

最简单:每 N 个字符切一刀。比如每 250 字符一块:

块1 = 字符 1~250块2 = 字符 251~500块3 = 字符 501~750...

问题:切分点完全是机械的,经常把一个词、一句话、一个完整思路拦腰切断

解决:加重叠(overlap)——相邻块共享一段内容:

块1 = 字符 1~250块2 = 字符 226~475   ← 和块1重叠 25 字符块3 = 字符 451~700   ← 和块2重叠 25 字符

重叠让被切断的词在两个块里都"有上下文",显著缓解切断问题。代价是存储变多(有冗余)。重叠一般用占整块的百分比表示,10% 左右常见。

一个稳妥的起手默认:每块约 500 字符,重叠 50~100 字符。多数项目从这里开始调。

2. 递归字符分割(看文档结构)

不再机械等分,而是按特定字符切——比如按换行符(段落之间)切。这样块边界天然落在语义单元上,相关内容更可能呆在同一块里。

代价:块大小不固定,可能冒出特别大或特别小的块。对不同类型文档还能选不同切分字符:HTML 按 <p> 标签切,代码按函数定义切,纯文本按换行切。

3. 语义分块(看意思)

更高级:按"意思的转变"来切。算法逐句扫描,用嵌入模型算"当前这段"和"下一句"的相似度——

  • • 相似度高 → 同一话题,并入当前块
  • • 相似度跌破阈值 → 话题变了,在这里切断,开新块

好处:块的边界贴合作者思路的转折。代价:要给每个句子算向量,预处理很贵,但换来更高质量的检索。

4. LLM 分块 + 上下文感知(最智能)

最激进:直接让 LLM 来决定怎么切,给它文档和指令"按含义分块、相似概念放一起、出现新话题就切"。LLM 像生成任何文本一样生成切分结果。

进一步还能让 LLM 给每个块补一段上下文摘要——比如末尾一个"致谢名单"块,单独看不知所云,LLM 给它加上"本文末尾的致谢部分"说明,既利于检索,也利于 LLM 理解。

代价同样是算力昂贵(要 LLM 过一遍整个知识库),但随着模型成本下降,越来越划算。

四、怎么选

策略
难度
质量
适用
固定尺寸 + 重叠
⭐ 最简单
够用
原型、默认起点
递归字符分割
⭐⭐
较好
结构化文档(HTML/代码/带段落)
语义分块
⭐⭐⭐
对检索质量要求高、能承受预处理成本
LLM 分块 + 上下文
⭐⭐⭐⭐
最好
追求极致、预算充足

实用建议:

  • • 起步用固定尺寸(500 字符 + 50~100 重叠)
  • • 拿小批量数据实验,看换更高级策略是否真有提升(用上一篇讲的 Precision/Recall 衡量)
  • • 上下文感知分块可叠加在任何策略之上,常作为"第一个值得加的升级"

记住一个原则:目标不是用最前沿的技术,而是找到成本与收益最匹配的那一档。

五、别忘了元数据

切出来的每个块,应当继承源文档的元数据(标题、作者、日期、权限、所在位置等),甚至加上"这是文档第几块"这种位置信息。这样元数据过滤(权限、区域、时间)才能在块级别生效。

小结与预告

这一篇我们讲了分块——一个不起眼但深刻影响 RAG 质量的环节:

  • • 必须分块:整篇做向量 → 主题糊化、撑爆上下文
  • • 块大小要平衡:太大太小都搜不准
  • • 四种策略:固定尺寸、递归字符、语义、LLM + 上下文感知
  • • 起手用 500 字符 + 重叠,按需升级

到目前为止,我们讲的都在检索这一侧——怎么把资料找出来、找得准、找得快。但资料找到之后,LLM 怎么用它生成高质量回答,是另一整套学问。

下一篇我们换边,钻进 LLM 与提示工程:Transformer 怎么工作、怎么调温度/Top-P、怎么写系统提示、怎么用思维链。


本文基于 DeepLearning.AI《RAG》课程整理。下一篇《怎么让 LLM 答得更准?提示工程实战》即将更新。