完整题目
文本分块（Chunking）策略如何影响RAG系统的性能？请系统阐述常见分块方法（如按语义边界分割、滑动窗口、重叠分块、固定长度分块等）的原理、优缺点及适用场景，并结合实际案例对比分析其对检索精度、召回率和生成质量的影响。
本文目录
核心权衡
分块是在语义完整性、检索噪声、召回覆盖、上下文预算和索引成本之间取舍。块大小与效果不存在跨数据集通用的单调关系，必须结合文档结构、查询分布、embedding 模型和生成任务评测。
常见策略
| 方法 | 做法 | 主要优点 | 主要风险 |
|---|---|---|---|
| 固定长度 | 按 token 或字符数切分 | 简单、吞吐和容量容易估算 | 可能切断句子、表格或章节 |
| 结构或语义边界 | 按标题、段落、句子或解析树切分 | 更容易保留完整语义单元 | 块大小不均，依赖解析质量 |
| 固定步长滑窗 | 用窗口长度与步长生成候选块 | 增加跨边界覆盖 | 重复内容多，索引与去重成本上升 |
| 语义块加重叠 | 在相邻结构块之间保留少量上下文 | 缓解指代和边界信息丢失 | 重叠过大会造成重复召回 |
滑动窗口通常本身就包含重叠；若把二者分开比较，应明确滑窗是固定窗口加固定步长，而“语义块加重叠”是在结构切分后补邻接上下文。
对系统的影响
- 小块通常噪声更少，但可能缺少定义、指代或跨句证据；大块上下文更完整，但相关信息占比可能下降。
- 重叠可能提高边界证据的召回，也可能让多个近重复块占满 Top-K。
- 摘要类、多跳类查询往往需要更完整或分层的上下文；精确事实查询可能更偏好较小且自包含的块，但都不是固定规则。
评测方法
在同一文档集和查询集上比较多组 chunk size、结构切分方式和 overlap。检索侧看证据 Recall@K、MRR 或 NDCG、重复率和过滤后有效证据数；生成侧看答案正确性、忠实度和引用覆盖；工程侧看索引体积、延迟与上下文 token。最终选择 Pareto 更优的配置，并单独检查表格、代码、跨页和多跳问题。
结论：分块没有“语义切分一定最准”或“滑窗一定召回最高”的统一排序，可靠结论来自同一评测集上的对照实验。
图解
换一种问法，检查是否真正理解
场景切入
我看你简历上做过知识库问答。假设用户问一篇技术文档里的问题，比如问“RLHF的训练流程”，你觉得文档是切成小段好还是整章一起给模型？怎么切才能既找到相关段落又不漏掉细节？
层层追问
RAG系统里文档你怎么分块的？……固定长度切和按句子切你觉得哪个好？……那如果一段话被切断了，比如“如图3所示”跑到了下一块，检索到上一块就废了，这种你怎么处理？
直球架构
请系统讲一下RAG中分块策略对检索和生成的影响。按固定长度、语义边界、滑动窗口和重叠分块这四种，分别说原理、优缺点，再举个例子对比精度和召回率的变化。
练习口述回答 · 约4分钟
- 分块的本质是粒度与完整性的博弈
- 四种方法：固定长度、语义边界、滑动窗口、重叠分块
- 对精度、召回率、生成质量的影响
- 案例：百度知识库的RLHF问题
- 选型建议与给出可延伸点
[[Chunking]] 对 [[RAG]] 的影响非常大，因为它决定了知识库里最小的检索单元。切得好，检索能找到刚好回答问题的证据；切得不好，要么找不到，要么找回来一堆噪声，最后生成模型也会被带偏。
它的核心权衡是信息粒度和上下文完整性。块太小，语义容易断，比如一句“该方法效果更好”被单独切出来，模型不知道“该方法”指什么；块太大，里面噪声多，[[embedding]] 会被多个主题稀释，检索精度下降，塞给大模型也浪费窗口。
常见方法里，固定长度分块最简单，按 token 或字符数硬切。优点是稳定、好控制，适合日志、流水、某些无明显结构的文本；缺点是容易切断段落和表格。
语义边界分块是按标题、段落、句子或条款切。它能保留完整语义，适合论文、产品文档、合同、技术手册。但问题是块大小不稳定，有的章节很长，需要再做递归切分或摘要压缩。
[[滑动窗口]]是用固定窗口加步长往前滑。窗口长度与 overlap 都只是待测试变量；它可能缓解边界信息丢失，也会带来冗余，必须在同一评测集比较召回、答案质量、索引体积和去重成本。
重叠分块是一个候选方案，相邻块保留一部分重叠区域。它可能比纯固定切分更不容易断语义，但也会增加索引和去重成本；是否适用要和无重叠方案放在同一评测集比较。
对检索精度来说，块越聚焦，通常越容易匹配准；对召回率来说，有 overlap 或滑动窗口通常更不容易漏；对生成质量来说，最关键的是 chunk 是否自包含，里面是否有足够的上下文支撑答案。
举个技术文档例子，用户问“[[RLHF]] 训练流程里 [[PPO]] 是怎么用的”。如果照搬某个固定长度硬切，可能 RLHF 流程在上一块，PPO 细节在下一块，检索只召回一个就答不完整。按二级标题切能保留完整章节，但章节过长时仍要二次处理。比较稳妥的做法是先保留标题和段落边界，再把不同窗口长度和 overlap 作为候选，用同一评测集选出方案，同时给每个子块带上父标题和章节 metadata。
选型上我会看三件事：文档结构、用户 query 类型、Embedding 模型能力。结构化文档优先语义切分，代码可以按函数或 AST，FAQ 可以按问答对；精确问答适合更小粒度，摘要分析需要更大上下文；如果 embedding 模型对长文本表示能力弱，chunk 就不能太长。
最后一定要评估。用一批真实 query 比较不同 chunk 大小和 overlap，观察 Recall@K、MRR、答案正确率和引用准确率。Chunking 不是一次性拍参数，而是 RAG 里最值得 A/B 的基础环节。