从0到1，彻底搞懂 RAG 分块的艺术（附开源代码）

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">你是否也曾困惑：为什么我的 RAG 系统总答非所问？明明喂给它了完整的文档，为什么还是抓不住重点？

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">答案可能藏在最基础、也最容易被忽视的一环 ——ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(15, 76, 129);">分块（Chunking）。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">分块是 RAG 系统的“数据预处理器”，它连接着原始文档和语义检索，是决定模型能否“读懂”资料、并给出精准回答的命脉。今天，我们就来一场深度探索，彻底搞懂 RAG 分块这门艺术。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;padding: 0px 0.2em;color: rgb(255, 255, 255);background: rgb(15, 76, 129);">为什么分块如此重要？

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">想象一下，让一个嵌入模型（Embedding Model）去阅读一篇包含多个主题的长篇报告。如果直接将整篇文档丢给它，模型就像陷入了一片信息的汪洋，试图将所有内容压缩成一个单一的向量表示。结果可想而知——生成的向量会变得模糊不清，语义混乱。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">合理的分块，就是为了解决两大核心问题：

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(15, 76, 129);">为语义“降噪”，让信息更纯粹

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">为了让嵌入模型达到最佳效果，我们提交的每一个文本块都应聚焦于单一的核心主题。通过精细化的文本分块，我们确保每个单元的语义都高度内聚和纯粹，避免主题混杂。这种做法能帮助模型精准地捕捉其核心特征，是后续实现高质量向量检索的成功基石。

适应模型的“记忆力”限制

大语言模型（LLM）的上下文窗口是有限的。即便技术飞速发展，这个“记忆力”上限依然存在。将长文档切分成小块，可以确保每一份信息都在模型的最佳处理范围内，从而获得更高质量、更精确的嵌入向量。

分块大小的“黄金法则”

这是一个非常普遍的误区：认为分块大小应该尽可能接近嵌入模型的 Token 上限（如 8191 Tokens）。事实恰恰相反，为了追求高精度的检索，我们往往需要更小的分块。

嵌入模型的“Token 陷阱”

信息压缩的物理极限：嵌入模型将文本块压缩成一个固定维度的向量（例如 1536 维）。输入 10 个文本句子和 1000 个文本段落，输出的嵌入向量维度都是相同的。文本块越大，信息被压缩得越狠，损失也越严重。

语义密度的稀释：一个巨大的文本块通常包含多个子主题。这会导致嵌入向量成为一个“大杂烩”，虽然包含了所有信息，但对任何一个具体信息的表达都不够精确。就像一张包含了城市全景的照片，虽然信息量大，但你看不清任何一栋建筑的细节。

检索精度的下降：当用户查询一个非常具体的问题时，一个内容宽泛的大块，很可能因为包含了太多不相关的“噪音”而在相似性计算中败下阵来。

实践中的最佳选择

即便模型支持 8000+ Token，业界公认的最佳分块大小通常在 200-800 Token 之间。这在保持语义完整性和确保“语义密度”之间取得了最佳平衡。

案例剖析：主题稀释如何影响检索？

假设我们有一份关于“糖尿病”的医疗文档。

❌ 不理想的大文本块：

糖尿病是一种慢性代谢疾病，主要分为 1 型和 2 型。1 型糖尿病通常在儿童期发病，需要终生胰岛素治疗。2 型糖尿病多见于成年人，与肥胖和生活方式密切相关。糖尿病的常见并发症包括糖尿病肾病、糖尿病视网膜病变和糖尿病足。糖尿病肾病是糖尿病最严重的并发症之一，可导致慢性肾功能不全。在治疗方面，除了药物控制血糖外，饮食管理也至关重要。患者应避免高糖、高脂食物，增加膳食纤维摄入。定期运动有助于改善胰岛素敏感性，建议每周至少 150 分钟中等强度运动。

当用户查询 “糖尿病肾病的症状” 时，这个大块虽然包含了关键词，但由于混合了分型、其他并发症、饮食、运动等多个主题，其整体相关性分数反而会降低。

✅ 理想的小文本块：

块 1：糖尿病肾病是糖尿病最严重的并发症之一，可导致慢性肾功能不全。早期症状包括蛋白尿、水肿，晚期可能出现尿毒症症状。

块 2：糖尿病患者应避免高糖、高脂食物，增加膳食纤维摄入。建议选择低升糖指数食物，如全谷物、蔬菜等。

块 3：定期运动有助于改善胰岛素敏感性，建议每周至少 150 分钟中等强度运动。适合的运动包括快走、游泳、骑自行车等。

现在，当用户查询 “糖尿病肾病的症状” 时，块 1会因为其高度聚焦的主题而获得极高的相似性分数，从而被精准召回。

分块大小如何影响生成质量？

分块不仅影响检索，更直接决定了 LLM 最终生成内容的质量。我们再看一个医疗咨询案例。

场景：患者咨询“胸痛应该怎么办？”

方案一：大文本块 (500+ Token)

胸痛是急诊科常见症状，需系统性评估。可能原因包括心血管疾病（急性心肌梗死、心绞痛）、肺部疾病（肺栓塞、气胸）和消化系统疾病（胃食管反流）。急性心梗常伴随放射痛、胸闷、出汗，需立即心电图和心肌酶检查。肺栓塞常伴随呼吸困难、咳血，需 D- 二聚体和 CT 肺动脉造影... 处理原则是首先排除危及生命的疾病...

• •优势：提供了完整的诊断思路和上下文，适合生成宏观、复杂的回答。
• •劣势：信息过载，检索精度可能下降，回答可能不够聚焦。

方案二：小文本块 (100-200 Token)

块 1：胸痛可能是心肌梗死的症状，需要立即就医。

块 2：心电图检查对胸痛诊断很重要。

块 3：肺栓塞也可能引起胸痛和呼吸困难。

• •优势：检索精度极高，能精准命中用户最关心的问题点。
• •劣势：上下文缺失，可能导致 LLM 的回答过于片面，缺乏深度。

方案三：中等文本块 (200-300 Token) - 推荐

块 1：胸痛的心血管原因及特征：急性心肌梗死常表现为放射性疼痛，伴有胸闷、出汗。需立即进行心电图和心肌酶检查。

块 2：胸痛的肺部和消化道原因：肺栓塞常伴随呼吸困难、咳血。胃食管反流引起的胸痛通常与进食相关，制酸剂可缓解。

• •优势：完美平衡！既保证了检索的精度，又为 LLM 提供了足够的上下文进行高质量、有深度的回答。

四大主流分块策略

选择哪种分块策略，取决于你的文档类型和应用需求。

进阶：让检索精度再上一个台阶

当基础分块无法满足你的极致追求时，可以试试以下高级索引技巧：

句子窗口检索 (Sentence Window)

这就像用一个“滑动的窗口”来阅读。
做法：我们只对单个句子进行嵌入和检索，以获得最高的精度。但在检索到这个句子后，我们将它前后的几个句子（即“窗口”）一同送给 LLM。

效果：既有针尖般的检索精度，又有足够丰富的上下文供 LLM 生成答案。

父文档检索器 (Parent Document Retriever)

这是一种“小块索引，大块作答”的策略。

做法：将文档切成小的“子块”用于检索，但同时保留指向原始“父块”（更大的块或整个文档）的链接。当检索到某个“子块”时，我们将完整的“父块”交给 LLM。

效果：结合了小块检索的精准和大块上下文的完整性，是平衡精度与信息量的绝佳方案。

摘要索引 (Summary Indexing)

这是分级索引策略中一种非常高效的具体实现，完美解决了传统全文检索容易引入无关信息的痛点。

核心思想：检索时，我们不直接面对海量的、细节丰富的原文，而是先从高质量的“摘要层”入手。

做法：

• •索引阶段：为每一个文档块（父块）创建一份精炼的摘要。然后将摘要和原文块都进行索引，并建立两者之间的链接。
• •检索阶段：当用户查询时，系统首先在“摘要层”进行检索。因为摘要更短、语义更集中，所以这一步能快速、精准地锁定最相关的文档块。
• •获取原文：一旦找到最佳摘要，系统会通过链接轻松获取其对应的、包含完整上下文的原文块，并将其送给 LLM。

效果：这种“先摘要，后原文”的两阶段方法，极大地提升了检索效率和结果的相关性，有效避免了在庞杂的原文细节中“迷路”。

元数据过滤 (Metadata Filtering)

这就像给你的文档装上了精准的“筛选器”。

核心思想：在分块时，不仅关注文本内容本身，还为每个文本块附加结构化的“标签”——即元数据。

做法:

• •索引阶段：在对文档进行分块时，为每个生成的文本块（chunk）添加描述其来源和属性的元数据。例如，常见的元数据属性包括页码、时间、类型和文档标题等，它们可以用来标记和描述文档的基本属性。
• •检索阶段：在进行向量检索之前或之后，可以利用这些元数据进行预过滤或后过滤。例如，用户查询“第二季度财报中关于市场增长的部分”，系统可以先筛选出所有 document_title 为“2024 年 Q2 财报”的文本块，再在这些块中进行语义搜索。

• {"page_number":3,"document_title":"2024年Q2财报","publish_date":"2024-07-26"}

效果：大大缩小了检索范围，避免了在不相关的文档中进行无效的向量搜索，极大地提升了检索速度和精度，特别是在处理海量、多源文档时效果显著。

总结

分块没有一成不变的银弹，它是一门需要根据具体场景不断权衡和实验的艺术。

最后，为你总结几条可以直接上手的最佳实践：

✅忘掉 Token 上限：选择 200-800 Token 作为你的起点。

✅首选递归分块：它在大多数场景下表现最好。

✅结构化文档用格式分块：如果你的文档是 Markdown 或 HTML，别浪费了这些天然的边界。

✅实验是检验真理的唯一标准：构建评测集，大胆尝试不同的分块策略和参数组合，找到最适合你业务的方案。

✅考虑高级策略：当精度遇到瓶颈时，试试句子窗口或父文档检索器，效果拔群。

分块是优化 RAG 系统的第一步，也是最关键的一步。希望这篇文章能帮助你构建出更智能、更精准的 RAG 应用。