分块策略 Chunking Strategies

所属：01-fundamentals / 03-rag
面试权重：★★★
来源：通用领域知识（B站「RAG 面试」合集高频）；未做一手考证

一句话#

Chunking 决定检索的最小语义单元：切得太大，向量被稀释成「主题平均」，召回不准、还挤占生成上下文；切得太小，一句半句缺主语，召回了也没用 —— 它本质是在检索粒度与生成上下文完整性之间找一个平衡点，而且这个平衡点由 embedding 模型的长度上限、文档结构与问题类型共同决定。

为什么重要（面试角度）#

Chunking 是 RAG 里最高杠杆、最容易被忽略的一个决策。很多「RAG 效果差」的真实根因就在切分上，但因为症状出现在检索或生成，大家会先去调 prompt、换模型，绕一大圈。

面试官想看的不是「我用 RecursiveCharacterTextSplitter，chunk_size=512, overlap=50」这串配置（虽然要能报出来），而是：

• 你知不知道 chunk size 和 embedding 模型的 max sequence length 是耦合的（超过就被截断，尾部内容形同没有）
• 你能不能说出固定 / 递归 / 语义 / 父子四种策略各自的适用场景与代价
• 你理解 overlap 是「用冗余换召回」，代价是索引膨胀与近重复结果
• 你意识到结构信息（标题、表格、代码块）比字数更重要 —— 切在句子中间几乎总是错的

核心内容#

四种策略#

「结构感知」是横切的一层：Markdown 按标题层级切、按表格/代码块边界切、按 PDF 的版面切。规则是 优先切在语义/结构边界，长度只是保底手段。真实系统通常是组合式：先按文档结构（H1/H2）分段，段内再递归切，必要时加语义边界修正。

尺寸与 overlap 的取舍#

chunk size：

• 太小（如 < 128 token）：embedding 的语义被上下文缺失搅浑（「它的价格是 300 元」里「它」指谁？），召回语义模糊；且一条完整答案被拆到多个 chunk，命中一个也答不全。
• 太大（如 > 1024 token）：embedding 被多主题平均化，向量落在「主题重心」上，具体问题的分辨力下降；同时 top-n 注入的 token 暴涨，噪声增多、成本上升、lost-in-the-middle 更容易发生。
• 常见起点在 256–1024 token 量级、相邻块重叠 10%–20% —— 但这是经验值，随语料、embedding 模型、问题类型大幅变化，面试里别当结论背，要说「靠评测集扫出来」。

  ⚠️ 口径统一说明：本文此前写「200–512」，而 02-interview/design/01-enterprise-rag.md 写「~500–1000」，两处上界差了一倍，被追问「为什么是 512 不是 1024」时会露怯。现统一为 256–1024 / overlap 10%–20%（与《深入理解 AI Agent》第 3 章的实践口径一致），并明确：这个区间的意义是「在这里起步」，不是「答案在这里」 —— 最终值必须由评测集扫出来。

overlap：

• 作用：防止答案正好落在切点上被腰斩，让边界信息在两个 chunk 里都出现。
• 代价：索引体积与 embedding 成本按 1/(1-overlap_ratio) 放大；检索结果里出现近重复 chunk，浪费 top-n 名额。
• 经验值 overlap 常取 chunk size 的 10%–20%；overlap 太大等于变相缩小有效 chunk size。

chunk size 与 embedding 模型的 max length 耦合#

这是最容易被忽略、也最能区分候选人的一点：

• 每个 embedding 模型有 max sequence length（如 512 token，或因位置编码外推而更长的 512/8192 等，具体上限随模型不同，必须查该模型的 model card）。
• 如果 chunk 的 token 数超过这个上限，编码器会截断（多数实现保留前 N 个 token）或池化出退化表示 —— 结果是你以为 chunk 包含的信息，其实尾部根本没进向量。文档里明明写着的答案，检索永远找不到。
• 所以 chunk size 必须 ≤ embedding max length（一般取 0.8 倍留余量），否则 chunking 再讲究也白搭。
• 反过来，用长上下文 embedding 模型（支持几千 token）时，chunk 可以更大，但要注意：模型支持的长度 ≠ 在该长度上语义分辨力好，长文本 embedding 普遍存在「细节被平均掉」的问题。

与检索/生成的张力#

同一个 chunk 要同时服务两个目标，而它们偏好相反：

父子分块（small-to-big）正是为解这个矛盾而生：用小 chunk 去匹配查询（检索精度），返回父块或邻近窗口给 LLM（生成完整性）。这也是面试里最值得主动抛出的解法。

怎么选：一个可操作的流程#

1. 先看文档结构：有标题/表格/代码就先做结构感知切分，别一上来就按字数。
2. 定上界：chunk size ≤ 0.8 × embedding max length。
3. 在评测集上扫参：准备带 gold chunk 标注的问答集，扫 chunk size ∈ {128, 256, 512, 1024} × overlap ∈ {0, 10%, 20%}，看 Recall@k（检索侧）与 Faithfulness（生成侧）的联合变化，而不是拍脑袋。
4. 必要时上父子分块：检索用 256、喂生成用 1024（或整节）。
5. 增量为维护留口：新增文档要能只重切/重嵌变化的 chunk，所以 chunk id 要可稳定生成。

常见坑的归类#

常见面试问法#

Q：你的 chunk size 怎么定的？ A：不是拍脑袋。先保证 chunk ≤ 0.8×embedding 模型 max length 不被截断；再在有 gold chunk 标注的评测集上扫 {128/256/512/1024}×{10%/20% overlap}，用 Recall@k 和 Faithfulness 联合选。除此之外先做结构感知切分（标题/表格/代码），长度是保底手段而非首选。

Q：chunk 越小检索越准吗？那是不是越小越好？ A：不是。太小的 chunk 缺上下文，embedding 语义模糊（指代、省略都解不了），而且一条完整答案被拆散、命中也不完整。小 chunk 的优势在检索分辨力，但会牺牲生成所需的完整性 —— 正确做法是用父子分块把两者分开满足。

Q：overlap 有什么用？开大点是不是更保险？ A：overlap 防止答案正好落在切点被腰斩，让边界信息在两块中都出现。但代价是索引与 embedding 成本按 1/(1-r) 放大，且产生近重复 chunk 挤占 top-n。常用 10%–20%，不是越大越好。

Q：为什么 chunk size 会和 embedding 模型相关？ A：每个 embedding 模型有 max sequence length，超长会被截断或池化退化，导致 chunk 尾部根本没进向量 —— 文档里有的内容永远检索不到。所以 chunk size 的上界由 embedding 模型决定，长上下文 embedding 可以放宽这个上界，但不代表长文本的语义分辨力同样好。

Q：语义分块听起来更高级，为什么不是默认选择？ A：它以「相邻句 embedding 相似度骤降」为切点，确实更贴语义边界，但代价是索引阶段要多跑大量 embedding、阈值对语料敏感、效果提升并不总是稳定（取决于文本是否本来就有清晰的主题切换）。所以在结构清晰的文档上，结构感知 + 递归切分往往性价比更高。

易错点#

• ❌ 只报一个 chunk_size=512 的数字，说不出为什么、也没提评测依赖。
• ❌ 忽略 chunk size 与 embedding max length 的耦合 —— 超长被截断是「内容存在但召不回」的经典隐形杀手。
• ❌ 把 overlap 当「越大越保险」，不承认它的索引膨胀与近重复代价。
• ❌ 认为存在普适最优 chunk size（它高度依赖语料与问题类型，必须靠评测选）。
• ❌ 只按字数切，无视标题、表格、代码这些天然边界。
• ❌ 断言语义分块一定优于递归分块 —— 这是依赖语料的经验判断，不是定论。
• ❌ 忘了增量：文档更新时要能重建受影响的 chunk，而不是全量重嵌。

自测#

1. 一个用户说「文档里明明写了答案，RAG 就是检索不到」。除了换 embedding 模型，chunking 上有哪两个最值得先查的假设？

2. 为什么说父子分块（small-to-big）能缓解检索粒度与生成上下文的矛盾？

3. overlap 从 10% 提到 50%，会发生什么？

4. 什么样的语料适合语义分块，什么样的不适合？

5. 如果面试官让你「现在就定一个 chunk 方案去做 POC」，你会怎么说？