RAG 分块参数调优
chunk size、overlap 与层级切块参数的实验调优
原题：在构建RAG系统时，如何进行有效的文本分块（chunking）？请介绍不同的分块策略、考虑因素以及各种方法的优缺点。
文档处理 · 百度真题
30 秒回答
- 分块策略分类（固定长度、语义、递归等）及适用场景
- 分块粒度与检索精度的权衡关系
- 边界处理策略（句子/段落完整性）
- 重叠策略的作用与设置
回答与解析
答案要点
- 分块策略分类（固定长度、语义、递归等）及适用场景
- 分块粒度与检索精度的权衡关系
- 边界处理策略（句子/段落完整性）
- 重叠策略的作用与设置
- 实际选型需结合文档类型和业务需求
核心分块策略
1. 固定长度分块（Fixed-size）
- 按token数或字符数切分，具体长度作为候选变量
- 优点：实现简单、Embedding均匀、便于批量处理
- 缺点：可能切断语义，边界信息丢失
2. 递归分块（Recursive）
- 优先按段落→句子→固定长度层级切分
- 优点：尽量保持语义单元完整
- 缺点：块大小不均，短块信息密度低
3. 语义分块（Semantic）
- 用Embedding计算句子相似度，聚类形成语义连贯的块
- 优点：块内主题一致，检索精度高
- 缺点：计算成本高，块大小难控
4. 结构化分块
- 按文档固有结构：标题、章节、表格、代码块等
- 适用于PDF、Markdown、HTML等结构化文档
关键考虑因素
| 因素 | 建议 |
|---|---|
| 块大小 | 需结合Embedding输入限制、文档结构和LLM上下文预算提出候选 |
| 重叠（Overlap） | 比较零重叠、短窗口与较长窗口，用同一评测集验证边界证据完整性 |
| 边界对齐 | 优先在句号、换行处切割，避免截断句子 |
| 元数据保留 | 记录来源位置、标题等，用于重排序和答案溯源 |
实践选型建议
- 通用文档：递归分块 + 适度重叠，平衡效果与成本
- 问答场景：比较多组粒度与重叠窗口，联合验证命中率和证据完整性
- 长文摘要：比较较大块、父子索引与结构分块，验证上下文完整性和噪声
- 混合策略：先结构化提取，再对长段落语义分块
最终需通过检索召回率和端到端问答效果验证，无绝对最优，只有场景最优。
口语版讲法(约4分钟)
- 一句话定位：分块本质是信息密度与检索精度的平衡
- 三种核心策略：固定长度、递归、语义，各有适用边界
- 混合策略与业务落地：以客服退款文档为例
- 关键参数：块大小、重叠、边界对齐
- 落地风险：匹配模型窗口、元数据保留、效果验证
这道题问的是文本分块，但本质其实是在问怎么在信息密度和检索精度之间做平衡。块切太大，语义是完整了，但检索时容易命中一堆无关内容；块切太小，精度上去了，但上下文碎片化，大模型反而看不懂。所以没有一个万能策略，得根据文档类型和业务场景来选。
先说三种核心策略，各有各的适用边界。固定长度分块最简单，按token数或者字符数一刀切，具体长度作为候选变量。优点是实现快、Embedding均匀、批量处理效率高。但缺点是它不管语义边界，可能一句话被拦腰切断，关键信息就丢了。所以它适合那种内容结构统一、长度一致的文档，比如日志或者固定格式的报告。递归分块就聪明一些，它先按段落切，段落太长再按句子切，句子还长才用固定长度兜底。这样尽量保住语义单元完整，但代价是块大小不均匀，短块信息密度低。语义分块更高级，用 Embedding 算句子相似度，把主题一致的句子聚成一个块。块内主题纯度高，检索精度好，但计算成本高，而且块大小不好控制，可能有的块特别大。
真正落地的时候，我很少只用一种策略。更常见的做法是混合。比如处理客服退款文档，我会先按文档固有结构分，像标题、章节、表格这些，结构化强的部分直接用结构化分块；对里面的大段说明文字，再用递归分块，保证句子完整；如果某个段落跨越多个主题，比如既有退款规则又有操作流程，那我会考虑用语义分块把它拆开。这样既利用了结构信息，又兼顾了语义连贯性。
具体参数上，有几个坑要注意。块大小要结合Embedding模型的实际输入限制、文档结构和LLM上下文预算提出候选。重叠也要比较零重叠、短窗口与较长窗口，用同一评测集验证是否补回边界证据。边界对齐很重要，一定要在句号、换行处切，别在句子中间截断。还有元数据要保留，比如来源位置、标题，这对后续重排序和答案溯源很有帮助。
最后说落地风险。一个常见失败场景是，块大小和LLM上下文窗口不匹配。比如LLM支持8K上下文，你把块切成2K，然后检索时一次塞4个块，结果超出窗口长度，模型直接截断。所以上线前一定要验证检索召回率和端到端问答效果，不能只看分块本身。
我其实更倾向把分块看成整个RAG系统的一部分，跟检索、重排一起调优。比如分块粒度细了，检索精度会高，但可能漏掉全局信息，这时候可以用 Parent Document 机制，先召回子块，再关联到父块喂给大模型。
所以我的总结是，没有最优策略，只有场景最优。我会先根据文档类型选基础策略，然后通过实验调块大小和重叠，最后结合检索效果做取舍。
关键一句:分块粒度与检索精度的权衡，以及Parent Document机制作为补充
面试官还可能这样问
- 问法 1 · 场景切入
假设你做一个企业知识库问答系统，文档里有长章节、表格、代码。用户问“第三季度营收多少”，你怎么把文档切成一块块，既能定位到数据，又不丢失上下文？
- 问法 2 · 层层追问
RAG里文本怎么切块？……你一般用固定大小还是按语义？……那如果你切断了句子，召回时会不会找到不完整的答案？怎么避免？
- 问法 3 · 直球架构
比较一下固定长度分块、递归分块和语义分块各自的优缺点，以及实际应用里块大小、重叠、边界对齐这些参数怎么设置？