在 RAG 系统中，文档不会整篇直接用于检索，而是被切分成一个个较小的单元，通常称为“分块”（chunk）。分块质量直接影响检索的命中率和最终回答的准确性。一个理想的分块策略，需要在语义完整、信息密度、检索粒度之间找到最适合当前业务场景的平衡点。
1. 语义完整：别把话拦腰截断
原则：每个分块应当尽可能包含一个相对独立的、完整的意思。
- 为什么重要
如果切分点恰好切断了一个关键句子或逻辑链条，检索到的片段就可能让模型产生误解。例如，条款“年假天数调整为 18 天，但前提是入职满两年”被拦腰切成两块，其中一块只有“年假天数调整为 18 天”，模型据此回答就很可能遗漏关键限制条件。
- 做法建议
- 优先按段落或章节的天然分隔切分。
- 对技术文档、FAQ，可以按一问一答、一条条款一条分块。
- 避免在句子中间强行切断；必要时使用滑动窗口重叠（overlap）来保持上下文连通。
- 对表格、列表类内容，尽量将表头与相关行放在同一块中。
真实场景：一份产品规格书，每个型号的参数描述自成一个段落，直接按段落切分就好；如果某个型号的说明跨段，用一个小标题作为分块边界，比用固定字数更可靠。
2. 信息密度：让每一块都能“独立作答”
原则：每个分块需要携带足够的信息，能在较大程度上独立支持回答相关提问。同时要避免冗余过长，稀释关键信息。
- 为什么重要
如果分块信息量太少（例如只有一句话），检索时虽然可能精准命中，但模型看到的上下文过于单薄，生成的回答往往不完整。反之，如果分块过长，包含过多无关内容，不仅会增加模型的阅读负担，还容易引入噪音，降低回答的聚焦程度。
- 衡量标准
一个好的分块，在脱离原文的情况下，仍然能让一个懂业务的人看明白“这段内容主要在说什么”。
- 做法建议
- 每个块最好包含一个完整的观点或一条完整的记录（如一整条规章制度、一个 FAQ 问答对）。
- 宁可块稍微“丰满”一些，再用检索策略（如 rerank）筛选精炼，也不要过度切碎难以还原语义。
- 对篇幅差异较大的文档，可设置最小/最大字符数窗，比如 200–800 字，允许一定浮动，但保持相对均匀。
真实场景：处理法律合同时，每一条合同条款通常可独立成块，因为审阅时常需要定位具体条款。条款本身的信息密度足够，块内无需塞入无关内容。
3. 检索粒度平衡：在精准与全面之间找平衡
原则：分块的大小决定了检索的“粒度”。粒度太细（小块）检索更精准，但容易丢失上下文；粒度太粗（大块）覆盖更全，但可能降低相似度计算的准确性，并且给生成模型带来长文本负担。
- 为什么重要
向量检索的核心是计算用户问题与分块之间的相似度。如果分块过大，包含的语义过于混杂，其向量表示就可能不够聚焦，导致与问题的相似度不高，本应命中的片段被淹埋。如果分块过小，虽然相似度匹配可能更精准，但召回时往往需要拼凑多个小块才能还原完整答案，拼接的准确率又是一个挑战。
- 平衡策略
- 实验驱动：没有绝对的最佳粒度。通常从 512 个 token（中英文混合约三四百字）开始试验，再根据问答效果调整。
- “小分块+扩展上下文”：将分块做得较小以提高检索精度，但在生成时，不仅取命中的小块，还同时附带它前后的相邻块，以补全上下文。
- 多级索引：先用小分块做初步检索，锁定相关区域后，再提取该区域更大范围的文本给模型生成。
- 按内容类型区分粒度：对于 FAQ，粒度可以是一个问答对；对于长篇政策文档，可以是小章节标题下的完整段落。
真实场景：某企业知识库中包含产品说明和技术白皮书，FAQ 类文档分块小（一问一答），白皮书按小标题分块。这样既保证 FAQ 的精准匹配，又让白皮书回答技术问题时信息充分。
实践中常见的分块方法速览
| 方法 | 适用场景 | 优缺点 |
|------|----------|--------|
| 固定字符数（如 500 字） | 通用文档，快速上手 | 简单，但容易切断语义 |
| 按段落/标题 | 结构良好的文档 | 语义完整，但分块大小不一 |
| 按句子 + 滑动窗口 | 高上下文依赖的叙述文本 | 语义流畅，但信息密度可能偏低 |
| 递归分块（小→大） | 多层级检索 | 灵活，但实现复杂度略高 |
归根到底，分块设计没有“一刀切”的方案，它依赖于知识库的内容结构、用户提问的典型形式以及对生成质量的容忍度。将语义完整作为底线，信息密度作为评分尺，检索粒度作为调整旋钮，通过多轮验证不断逼近最佳配置，是分块优化的可靠路径。