完整题目
在构建基于RAG的系统时，分块（Chunking）策略应如何设计以平衡文本的上下文完整性与信息检索的精确性？有哪些常用的最佳实践？
本文目录
核心矛盾
分块本质是上下文完整性与检索精确性的权衡：
- 块过大 → 噪声多、检索精度下降、embedding稀释
- 块过小 → 语义断裂、LLM缺乏上下文
常用分块策略
| 策略 | 适用场景 | 特点 |
|---|---|---|
| 固定长度 | 通用场景、快速上线 | 按token/字符数切分，实现简单 |
| 递归分块 | 结构化文档 | 先按段落/句子，再递归细分，保持层级 |
| 语义分块 | 高质量要求场景 | 用embedding相似度判断边界，保证语义完整 |
| Agentic分块 | 复杂文档 | LLM判断边界，成本高但最精准 |
关键最佳实践
1. 重叠策略（Overlap）
- 把零重叠、短窗口与较长窗口列为候选，在同一评测集上验证是否减少跨边界证据缺失
- 对代码、法律条文等边界敏感内容尤为重要
2. 边界感知
- 优先在段落、句子边界切分，不在词中间断开
- 特殊内容（表格、列表）尽量保持完整
3. 尺寸匹配
- 参考embedding模型的训练长度（如text-embedding-ada-002用8191 tokens）
- 预留LLM的上下文空间：chunk大小 + prompt + 输出 < context window
4. 元数据增强
- 存储chunk的标题、章节、页码等，用于重排序或过滤
5. 评估驱动迭代
- 用Hit Rate、MRR等指标对比不同策略
- 结合端到端问答效果做最终判断
实际项目中可先把递归分块、结构分块和不同重叠窗口作为候选，再根据同一评测集和bad case决定是否引入语义分块。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做客服文档检索，用户问“怎么退款”，系统从知识库找答案。如果一篇文章很长，你是整个塞进去还是切开？切的话怎么保证上下文不丢、又能精确命中问题？
层层追问
RAG系统里文档怎么处理才能让检索效果好？……那如果直接按固定字数切，会不会把一句话切开？……怎么在完整性和精确性之间找平衡？具体你会怎么设计？
直球架构
设计一个RAG系统的分块策略，核心目标是平衡上下文完整性和检索精确性。你会考虑哪些分块方法？有什么最佳实践？比如重叠、边界处理这些，具体怎么落地？
练习口述回答 · 约4分钟
- 一句话定位：分块本质是上下文完整性和检索精确性的平衡
- 边界划分与策略选择：固定长度 vs 语义分块，递归分块+重叠是起步标配
- 业务场景举例：企业合规文档检索，段落边界和重叠策略的实际应用
- 落地风险与前提：embedding长度限制、LLM上下文窗口、评估驱动迭代
- 工程师判断收尾：倾向递归分块起步，根据bad case逐步优化
这道题其实问的是，在[[RAG]]系统里怎么切文本才能既保证语义连贯又不让检索跑偏。说白了，[[分块]]就是在上下文完整性和检索精确性之间找平衡。块太大，噪声多，[[embedding]]被稀释，精度掉得厉害；块太小，语义割裂，LLM拿到的上下文不够，答非所问。
那具体怎么做呢？先说说几种常见策略的适用边界。固定长度分块，按token或字符数硬切，实现简单，适合快速上线，但对自然语言不友好，容易在句子中间断开。语义分块用embedding相似度判断边界，能保持语义完整，适合高质量要求，但计算成本高，对短文本不太灵敏。真正落地时，我不会把某一种组合当成起步标配，而是把递归分块、结构分块以及零重叠、短窗口、较长窗口列成候选。保持层级结构后，再用同一评测集验证哪组方案能减少切口上的证据缺失。举个例子，企业合规文档检索，比如员工查报销政策，段落边界很明确，递归分块就能保持政策条款完整，重叠能覆盖像“但是以下情况除外”这种转折信息。如果只固定切，很可能“但是”前面在上一块，后面在下一块，检索就漏了。
这里有个坑，就是边界感知。优先在段落、句子边界切，绝对不要在词中间断开，尤其对代码、法律条文这种边界敏感的内容。另外，尺寸匹配很关键。要参考embedding模型的最大长度，比如text-embedding-ada-002是8191 tokens，同时留足LLM的上下文空间，chunk大小加prompt加输出，不能超过context window。如果不满足，上线后你会发现长文档检索结果质量波动很大，因为embedding被截断或LLM拿不到完整上下文。
还有就是元数据增强。存储chunk的标题、章节、页码，配合[[Rerank]]或过滤，能大幅提升精准度。比如搜索“报销流程”，如果chunk带章节号，可以优先返回对应章节的块。
最后，评估驱动迭代。用Hit Rate、MRR这些指标对比不同策略，但最终还是要看端到端问答效果。常见失败场景是，指标好看但实际回答不相关，因为chunk里噪声多。
其实分块还有个隐藏问题，就是chunk之间的语义关联怎么处理。比如一个概念在前一块定义，后一块直接引用，分块后LLM可能看不到定义。有人用[[Parent Document]]方式，检索子块后返回父块全文，但这样上下文窗口压力大。这块我觉得值得深入，比如结合[[知识图谱]]来建模实体关系。