RAG 的 chunk 优化策略有哪些？｜阿里巴巴算法面经解析

60 秒回答模板

RAG 里的 chunk 优化不能只理解成把文档按固定长度切开，它直接影响召回精度、上下文噪声、生成答案的可依据性和整体成本。我一般会从四层回答：第一是合理控制 chunk size，太小会丢上下文，太大 embedding 表达会混杂，常见做法是按 token 或段落设一个初始范围，再根据文档密度调参；第二是设置 overlap，用少量重叠缓解边界信息被截断的问题，但 overlap 过大会造成重复召回和上下文浪费；第三是语义和结构化切分，优先按标题、段落、列表、表格、代码块、FAQ 问答对等自然边界切，而不是机械滑窗；第四是给 chunk 加 metadata，例如文档标题、章节层级、时间、产品线、权限、来源和实体标签，召回时可以过滤、加权或用于引用溯源。最后必须通过评估闭环优化，比如看 Recall@K、MRR、nDCG、答案准确率、引用命中率、上下文利用率和噪声率，而不是凭感觉调 chunk。

考点 chunk size 的粒度选择

主线 overlap 的边界保护

易错点 只按固定字符数切分，不考虑标题、段落、表格、代码块和问…

深入解析

chunk size 的粒度选择

chunk size 是最基础也最容易被误调的参数。过小的 chunk 可能只包含一个局部事实，缺少前因后果，导致模型虽然召回到了关键词却无法形成完整回答；过大的 chunk 会把多个主题混在同一个向量里，embedding 表达被平均化，相关性下降，同时放进 prompt 后增加上下文噪声。实践中可先根据 token 数、段落数或语义单元设默认值，例如知识库问答偏中等粒度，法规和技术文档偏保留完整条款，短 FAQ 可一问一答成块，再用评估集微调。

overlap 的边界保护

overlap 的作用是解决切分边界把关键信息切断的问题，比如定义在上一段、条件在下一段，如果完全不重叠，召回到其中一块时模型可能缺少必要上下文。常见做法是设置一定比例的 token 或句子重叠，尤其适合连续叙述型文档。但 overlap 不是越大越好，重叠过多会导致索引膨胀、重复召回、rerank 分数集中、prompt 中同质内容变多，最终降低可用上下文容量。因此需要结合 chunk size 和文档结构一起调。

语义切分优先于机械切分

高质量 RAG 通常优先使用语义边界切分，而不是固定每 N 个字符直接截断。语义切分可以依据句子、段落、标题层级、主题变化、实体连续性或 embedding 相似度断点来决定边界，目标是让每个 chunk 内部主题集中且自洽。比如产品说明文档可以按功能模块切，论文可以按章节和小节切，客服知识库可以按问题与答案对切。这样得到的 chunk 更容易被准确召回，也更容易让生成模型判断哪些内容真正支持答案。

结构化文档的保真处理

结构化文档不能简单抽成纯文本后统一切分，否则表格、标题层级、编号条款、图片说明、代码块和列表关系容易丢失。表格可以按行、列语义、表头和说明一起组织，必要时转成带字段名的文本；标题层级要随 chunk 保留，避免只看到子段落不知道所属主题；代码和配置文档应保持代码块完整，不能在语法结构中间切断。对 PDF、网页、Word 等来源，还要处理页眉页脚、目录、重复导航和噪声文本，否则会污染索引。

metadata 与检索约束

metadata 是 chunk 优化中非常关键但容易被忽略的一层。每个 chunk 除了正文，还应携带文档 ID、标题、章节路径、来源 URL、更新时间、作者、业务线、权限级别、语言、实体标签、版本号等信息。检索时可以用 metadata 做过滤、加权、分桶或后处理，例如只查最新版本、只查某产品线、优先返回同一章节的相邻块。metadata 还能帮助答案引用溯源，提高可信度，并在多租户或权限敏感场景下避免错误召回。

召回精度与上下文噪声权衡

chunk 优化的核心矛盾是召回精度和上下文噪声之间的权衡。小 chunk 往往更容易匹配具体关键词和细粒度事实，但需要补充邻近上下文；大 chunk 包含更多背景，但可能召回不够精准，放入模型后还会干扰答案生成。工程上可以采用多阶段策略：先用细粒度 chunk 提高召回覆盖，再通过 rerank、相邻 chunk 扩展、父子 chunk 或摘要 chunk 补充上下文。这样既能保持检索精度，又能给生成阶段提供足够完整的依据。

评估驱动的迭代优化

chunk 策略必须通过评估闭环验证，不能只靠主观观察。检索侧可以看 Recall@K、Precision@K、MRR、nDCG、命中正确文档比例、相同文档重复率；生成侧可以看答案准确率、引用正确率、幻觉率、拒答质量和上下文利用率；系统侧还要看索引规模、延迟、token 成本和更新成本。比较不同 chunk size、overlap、切分方式和 metadata 过滤策略时，应在同一批真实问题集上做 A/B 或离线评测，避免只用少量样例调参。

易错点

只按固定字符数切分，不考虑标题、段落、表格、代码块和问答对等语义边界。
认为 chunk 越大越安全，忽略大 chunk 会稀释向量语义并增加上下文噪声。
把 overlap 设置得过大，导致索引膨胀、重复召回和 prompt 空间浪费。
不保留 metadata，导致无法按版本、权限、业务线、时间和来源做过滤或溯源。
只评估检索命中率，不评估最终答案准确率、引用正确性和幻觉率。
忽略结构化文档保真，把表格、列表和章节层级压平成难以理解的普通文本。

面试官追问

chunk size 一般设置多大比较合适？

没有通用最优值，需要按文档类型、embedding 模型能力、query 粒度和上下文窗口决定。实践中可以先选一个中等范围作为 baseline，再比较不同大小下 Recall@K、答案准确率、上下文噪声和 token 成本。FAQ 可更小，长篇技术文档或法规文档通常需要更完整的语义单元。

overlap 是不是越大越好？

不是。overlap 可以缓解边界截断，但过大会让索引规模膨胀，多个 chunk 内容高度重复，召回结果缺乏多样性，也会浪费 prompt 上下文。比较合理的方式是只覆盖边界必要信息，并配合相邻 chunk 扩展或父子 chunk，而不是单纯把 overlap 调很大。

语义切分和固定长度切分有什么区别？

固定长度切分实现简单，但可能把一个完整论点、表格或步骤切断，导致 chunk 不自洽。语义切分会尽量沿标题、段落、句子、列表、问答对或主题变化处切分，使每块内部表达一个相对完整的意思。通常语义切分的召回可解释性和生成可用性更好。

如果 chunk 很小，生成时上下文不够怎么办？

可以采用两阶段策略：检索阶段用小 chunk 精确命中，组装上下文时再补充同章节的相邻 chunk、父级 chunk 或原文片段。也可以用 rerank 先过滤噪声，再做上下文扩展。这样比一开始就用很大的 chunk 更容易控制召回精度和上下文质量。

如何判断 chunk 优化真的有效？

需要构建真实问题评测集，并同时看检索和生成指标。检索侧关注 Recall@K、MRR、nDCG、重复率和正确文档命中率；生成侧关注答案准确率、引用正确率、幻觉率和上下文利用率。只有在相同问题集上对比不同策略，才能证明优化有效。