RAG 分块长度与重叠如何取舍?

完整题目

在RAG（检索增强生成）系统中，如何优化文档的分段策略以提高检索质量和生成效果？请讨论分段长度、重叠策略和语义完整性的权衡。

本文目录

文档分段会同时影响召回、重排、生成和引用。真正要优化的不是某个chunk_size，而是让问题能召回完整证据，同时控制噪声、延迟和存储成本。

实践建议：先按标题、段落、列表、表格或代码边界产生候选，再对过长单元二次拆分。具体长度受embedding模型输入限制、查询类型和上下文预算共同约束。

保持查询集、答案标注和其他检索配置不变，逐组比较Recall@K、证据完整率、最终答案正确性、P95延迟、索引体积与重复召回率。根据bad case定位问题：证据被切断再调整边界或上下文补回；噪声过多则缩小候选单元或加强重排。没有实测结果时，只能陈述候选方案和验证方法。

换一种问法，检查是否真正理解

场景切入

假设你要做一个企业知识库问答系统，用户上传了一堆长文档，比如几十页的PDF。你会怎么切这些文档段落？切得太碎可能丢失上下文，切得太长检索又不准，你怎么权衡？

层层追问

RAG里文档分块你一般怎么处理？……固定长度切分会有边界问题吗？……那重叠策略呢？……语义完整性怎么保证，比如怎么避免把一个句子切到两个块里？

直球架构

在RAG系统中设计文档分段策略，需要考虑分块长度、重叠策略和语义完整性三者的权衡。你会怎么定？不同场景下比如事实问答和总结分析，策略有什么不同？

练习口述回答 · 约2分钟

这道题问的是，怎样让分块支持完整证据召回，而不是背一个chunk_size。块更小可能更容易命中局部事实，但上下文容易断；块更大能保留论证链，也会带来更多噪声。因此我会把分块当成需要验证的系统参数。

第一步先看文档。API文档优先按函数或接口切，合同按条款和层级切，报告按标题和段落切，表格与代码则保留自己的逻辑单元。过长单元再二次拆分，同时保留父级标题和原文位置。这样做比直接对所有文档使用固定长度更容易解释，也方便引用溯源。

第二步准备多组候选。较短分块、较长分块、结构化分块都在同一批真实问题上跑。重叠也比较零重叠、短窗口和较长窗口。重叠能补回跨边界答案，但会增加索引体积、重复召回和[[Rerank]]成本，所以不能默认越多越好。

第三步固定其他变量，比较Recall@K、证据完整率、最终答案正确性、P95延迟、索引体积与重复召回率。如果某类问题总是只召回半句，就先检查结构边界和父子上下文补回；如果召回内容太杂，就缩小候选单元或加强重排。

工程上我还会为每个chunk保存文档ID、父级标题、页码、原文起止位置和版本。召回后可以据此去重、合并相邻上下文，也能在文档更新时精确替换旧chunk，避免新旧版本同时命中。

最后我会明确区分实验结果和设计计划。做过实验，就说评测集、基线、指标变化和代价；没做过，就只说候选方案与验证步骤。面试官真正想听的是你如何证明这个参数适合自己的项目，而不是你记住了哪个经验数字。