RAG 知识库的分块大小是怎么决定的？

在 RAG（检索增强生成）系统中，分块（Chunking）大小并没有一个绝对的标准答案，而是需要根据具体的业务场景、文档类型以及模型限制来进行综合权衡。通常，决定分块大小需要综合考量以下几个核心维度：

1. 根据“内容类型”与“查询场景”选择

不同类型的文本承载的信息密度不同，所需的上下文长度也不同：

• 问答与对话类：如常见问题解答、客服支持或聊天上下文，推荐 128-384 token。较小的块有助于精确检索单个事实或对话轮次。
• 技术文档与代码：推荐 384-768 token。中等大小的块能够捕获完整的代码逻辑（如函数/类级别）和技术概念解释。
• 长篇复杂文档：如法律合同、研究论文等，推荐 512-1024 token。较大的块可以保持条款依赖关系、学术论证的完整性以及复杂的法律推理逻辑。

2. 权衡“检索精度”与“上下文完整性”

分块大小直接影响大模型的生成质量，需要在两者之间寻找平衡点：

• 较小分块：语义聚焦更好，检索更精确，且嵌入成本更低；但劣势在于容易缺乏足够的上下文，导致信息不完整或碎片化。
• 较大分块：能提供更全面的信息和更完整的上下文，适合处理复杂的综合分析查询；但劣势是语义信号容易被稀释，包含不相关信息的概率增加，导致精确检索性变差。

3. 系统资源与模型参数限制

• 大模型上下文窗口：检索到的总内容必须适配大模型的上下文容量。一般建议召回 Top-K 个文档后的总 token 数控制在模型上下文窗口的 30%-50% 之间，过多会导致注意力分散，过少则浪费窗口容量。
• 嵌入模型限制：分块大小必须在所选 Embedding 模型的最大 token 容量范围内（例如许多模型为 512 token，部分高级模型可达 8191 token）。

4. 采用“重叠（Overlap）”机制弥补边界丢失

无论分块大小如何设定，固定长度切割都可能在边界处截断关键语义。因此，业界通常会设置 10%-20% 的分块重叠度（例如 512 token 的块设置 50-100 token 的重叠）。这能确保连续分块之间的共享内容被保留，维持上下文的连续性。

最佳实践建议

在实际落地时，不建议单纯按固定长度进行机械切分。最好的做法是按语义单元分块（如完整的段落、Markdown标题层级、表格行组等），并为结构化数据（代码、表格）和非结构化文本设计差异化的分块策略。同时，建议构建一个包含多种真实查询类型的测试集，通过 A/B 测试对比不同分块配置下的检索准确率和答案质量，从而动态调优出最适合当前知识库的参数。