RAG分块策略：粒度、重叠与写入

回答与解析

分块粒度选择

核心原则：分块不是先猜一个万能数字，而是先保留文档的标题、段落、表格和代码边界，再用同一批业务问题比较候选方案。块更小可能更容易命中局部事实，但也更容易丢失上下文；块更大能保留论证链，却可能引入更多无关内容。

关键判断：同一个chunk能否独立解释被命中的事实，以及加入上下文后是否真的改善最终答案。不能只看块长，还要看Recall@K、证据完整率、答案正确性、延迟和索引膨胀。

重叠处理

• 不要预设固定比例：把零重叠、短窗口和较长窗口作为候选方案，在同一评测集上回放
• 作用：缓解答案跨越切分边界时的信息丢失
• 代价：重复索引会放大存储、召回冗余和重排成本
• 实现：记录每个chunk在原文中的起止位置与父级结构，便于合并、去重和溯源

向量化写入流程

原始文档 → 清洗（去噪/格式标准化）→ 结构化解析（提取标题/表格/代码块）
    ↓
产生多组分块候选 → 在固定问题集上评测 → 生成chunk元数据（来源、位置、类型）
    ↓
Embedding模型编码 → 按实际显存、限流和失败重试能力确定批量大小 → 写入向量库
    ↓
按需建立倒排索引，用于混合检索

工程注意点：

• batch size 要根据文本长度、向量维度、显存、接口限流和失败重试成本压测，不能照搬固定值
• 元数据携带原始文档ID和chunk位置，方便召回后重排序、去重或拼接上下文
• 对高频更新场景，设计版本、幂等与增量更新机制，避免新旧chunk同时被召回

面试回答落点

先说明业务问题和文档结构，再给出候选切法、评测集与指标，最后说清最终选择的收益和代价。没有真实实验时，应明确说这是待验证方案，而不是把经验数字说成结论。

口语版讲法(约2分钟)

• 一句话点题：分块的核心是语义完整与检索精度的平衡
• 粒度选择：按文档结构提出多组候选，代码按函数、论文按段落，实际常混合
• 重叠处理：比较零重叠、短窗口与较长窗口，用评测结果决定
• 写入流程：清洗→解析→分块→编码→批量写入，元数据携带来源位置
• 风险与取舍：元数据设计、增量更新、上线前用固定query验证召回率

这道题问的不是你记住了多少分块参数，而是你能不能把语义完整性、检索精度和工程成本放进同一个验证流程。

我会先看文档结构和问题类型。API文档适合按函数、类或接口边界切，论文和报告优先保留标题与段落层级，对话则要避免把指代关系拆开。企业SOP往往要混合处理：先按章节和段落切，表格、代码块和清单再走各自的解析规则。这里没有一种粒度能通吃所有场景，所以我不会一上来就宣布某个token数最好。

接着我会准备几组候选方案。块较小时，局部事实可能更容易命中，但上下文也更容易断；块较大时，论证链更完整，向量却可能混入无关语义。重叠同样不是固定比例：我会比较零重叠、短窗口和较长窗口，用同一批真实问题回放，观察Recall@K、证据完整率、最终答案正确性、延迟与索引体积。只有答案跨边界的bad case明显改善，而且冗余成本可以接受，才保留重叠。

写入流程上，原始文档先清洗和结构化解析，提取标题、表格、代码块与页码；然后执行候选分块并生成来源、父级标题、原文位置和版本等元数据；再调用Embedding模型编码，批量写入向量数据库。batch size 需要根据文本长度、向量维度、显存、接口限流和失败重试能力压测，不能从别的项目抄一个数字。需要混合检索时，再同步维护倒排索引。

上线还要处理增量更新与一致性。文档更新后，要能定位受影响的chunk，写入新版本，再安全下线旧版本；否则新旧政策可能同时被召回。元数据里保留原文位置，是为了召回后去重、拼接相邻上下文、重排序和引用溯源。

最后我会用固定评测集记录每组方案的指标与bad case，再决定上线配置。如果没有做过这些实验，我会明确说这是候选设计和验证计划，不会把一个经验范围包装成自己的项目结果。

关键一句:分块策略与重排阶段互相影响，需要根据重排结果反向调整粒度，形成闭环。

面试官还可能这样问

1. 问法 1 · 场景切入

   我看你做过知识库问答，假设用户上传了一本产品手册，系统要检索相关段落来回答。你会怎么切这些文本？比如一段话跨了两页，或者一个表格横跨几行，切分时怎么保证不丢失关键信息？

2. 问法 2 · 层层追问

   RAG系统里文本分块你一般怎么处理？……如果chunk太小，语义不完整怎么办？……那再加点重叠是不是能缓解？具体重叠多少合适？……最后这些块怎么批量写到向量库里，流程上有什么坑？

3. 问法 3 · 直球架构

   设计RAG的文本分块策略，说说你选多大粒度、怎么处理重叠，以及从文档到向量库的完整写入流程。要考虑不同文档类型，比如代码、论文、客服对话，分别怎么切？