RAG 中如何选择 Chunk 大小和重叠长度？

面试时怎么答

这题不要报一个“万能 512”。先说 Chunk 应贴合文档结构和答案粒度，再解释小块定位准但语境少，大块信息全但相关性被稀释；重叠只是在边界处补信息，不是越多越好。

若问怎样选参数，就答用真实问题集按文档类型扫描块长和重叠，并考虑父子检索或 Small-to-Big，而不是只看向量相似度。

可以这样答：

Chunk 大小没有统一答案，应由文档结构、问题粒度和上下文预算共同决定。标题、段落、表格和代码块优先按语义边界切；小块更易精准召回，却可能缺少上下文，大块更完整但噪声和成本更高。边界问题可用少量重叠或父子检索补足。参数要在真实问答集上比较 Recall、最终正确率、重复证据比例、索引体积和延迟。

核心回答

Chunk 没有适用于所有语料的固定大小。较小的 Chunk 定位更精确，但容易丢失上下文并增加索引数量；较大的 Chunk 保留更多语义，却可能让关键信息在向量中被稀释，并占用更多生成上下文。Overlap 能缓解边界切断，但会增加存储、重复召回和 token 成本。参数应结合文档结构、典型问题的证据跨度、Embedding 输入限制和评估结果选择。

展开说明

常见切分方式包括：

固定长度切分：实现简单，适合结构弱且格式统一的文本，但可能切断句子或表格。
递归或结构化切分：优先按标题、段落、句子、代码块和表格边界拆分，更容易保持语义完整。
语义切分：根据相邻内容的语义变化确定边界，质量和计算成本都需要实测。
父子 Chunk：用小 Chunk 做精确召回，命中后返回较大的父段落补充上下文。

Overlap 应小于 Chunk 本身，并只保留跨边界真正需要的上下文。标题、章节路径、文档 ID 和页码通常应作为元数据或前缀随 Chunk 保存，避免片段离开原文后失去含义。

工程实践

在代表性问题集上扫描多个 Chunk 大小和重叠比例，同时记录 Recall@K、上下文精确度、答案正确率、索引体积、查询延迟和输入 token。对表格、代码、合同条款等特殊文档单独设计切分器，并在上下文组装阶段合并相邻命中、消除重复文本。

常见追问

Chunk 越小，向量检索越准确吗？ 不一定。小块语义更集中，但可能把问题与答案拆开、缺少标题和限定条件，最终可回答性反而下降。
父子检索与直接使用大 Chunk 有什么区别？ 父子检索用小块提高定位精度，命中后返回更大的父块补上下文；直接检索大块会让向量被多主题稀释。
为什么固定百分比的 Overlap 可能造成大量重复？ 长文档中每个相邻块都复制相同尾首内容，重叠会同时膨胀索引和 Top-K 重复证据；应结合语义边界与去重。

一句话复习

Chunking 是在检索粒度、语义完整性和上下文成本之间取舍，最佳参数必须用真实问题评估。

参考资料

面经主题：Datawhale 真实面试题中的文本切块问题
官方资料：Azure AI Search 文档切块指南、按文档结构进行语义切块