劣质分块毒害RAG回答：分块质量调试指南

每一次RAG调试最终都会到达同一个地方：你检查检索到的分块，然后意识到问题不在检索，不在LLM，也不在提示词。分块本身就是垃圾。分块管道忠实地将你的文档分割成了碎片，而这些碎片是不连贯的、不完整的或具有误导性的。

分块就是RAG中"垃圾进，垃圾出"的环节。如果分块质量差，下游的一切都会变差——嵌入编码了错误的语义，检索返回了错误的上下文，LLM生成了错误的答案。再多的提示词工程或重排序都无法修复根本性的分块缺陷。

本文汇总了最常见的分块故障，展示了劣质分块的真实样貌，并为每种故障提供了实用的修复方法。

劣质分块模式1：句中断裂

表现形式：

分块A以此结束："本保单的最高赔付限额为"

分块B以此开始："每次事故500,000美元，免赔额为2,500美元，适用于2026年1月1日之后提出的所有索赔。"

原因分析： 固定大小分块（每N个token切分一次）不具备句子边界感知能力。当一个句子跨越分块边界时，两个分块都变得单独无意义。分块A说明了赔付限额但没有数字。分块B提供了数字但缺少它所指代的上下文。

下游损害： 如果用户问"最高赔付额是多少？"，检索可能找到分块A（它包含"赔付"和"最高"这些词）但找不到分块B。LLM要么捏造一个数字，要么说找不到相关信息——尽管答案确实存在于语料库中。

修复方法： 使用句子感知分块。分块算法应当尊重句子边界，确保每个分块都在完整句子处开始和结束。在分块之间添加10-15%的重叠，使边界句子同时出现在两个相邻分块中。

劣质分块模式2：孤立上下文

表现形式：

分块："利率为4.5%。对于超过阈值的账户，将额外收取1.2%的附加费。例外情况列于附录C。"

缺失的内容： 什么利率？什么阈值？什么类型的账户？这个分块语法上是完整的，但语义上是孤立的——它包含了具体细节，却缺少使这些细节可以被理解的框架上下文。

原因分析： 分块策略按章节或标题分割，但该章节本身是一个子章节，需要依赖父章节才能获得上下文。来自"第3.2.1节：费率表"的分块，如果不知道第3.2节讲的是"商业贷款产品"、第3节讲的是"企业银行业务"，就毫无意义。

下游损害： LLM收到这个分块后必须猜测"利率"和"阈值"指的是什么。它要么猜错（幻觉），要么用模糊的答案搪塞。无论哪种情况，用户都得到了无用的回答。

修复方法： 在每个分块前添加层级上下文。如果一个分块来自第3.2.1节，分块文本应当以"企业银行业务 - 商业贷款产品 - 费率表："开头，然后才是分块内容。这为LLM提供了解读具体细节所需的框架。一些团队将此称为"上下文分块"或"面包屑分块"。

劣质分块模式3：表格碎片化

表现形式：

分块A："| 方案 | 月费 | 存储空间 |"

分块B："| --- | --- | --- | | 免费版 | $0 | 5 GB | | Builder | $34.50 | 50 GB |"

分块C："| Agency | $149 | 200 GB | | Agency Pro | $349 | 500 GB |"

原因分析： 表格是固定大小分块的最坏场景。表头行落在一个分块中，前几行数据在另一个分块中，剩余行在第三个分块中。每个分块单独来看都没有用处——表头没有数据，数据没有表头，而且一个表格被分成两个分块，完全看不出它们属于同一个表格。

下游损害： 用户问"Agency方案要多少钱？"，检索返回分块C，其中包含答案但没有列标题。LLM看到"$149"和"200 GB"，但如果没有表头行就无法判断哪个数字是价格、哪个是存储限额。

修复方法： 在解析过程中检测表格，并将每个表格作为原子单元处理。如果表格超过分块大小限制，在每个分块顶部重复表头行。如果你的文档包含单个分块放不下的大表格，在分块之前将复杂表格转换为结构化文本（键值对或散文描述）。

劣质分块模式4：重叠冗余

表现形式：

分块A（token 0-500）："我们的隐私政策确保个人数据按照GDPR要求进行处理。数据主体有权访问..."

分块B（token 400-900）："...有权访问、更正和删除其个人数据。数据主体有权访问其数据并随时请求更正。我们的隐私政策确保个人数据按照..."

原因分析： 过度的分块重叠（40-50%或更多）导致大量文本在相邻分块之间重复。重叠设置得过于激进，可能是为了解决句中断裂的问题。

下游损害： 检索返回多个包含几乎相同信息的分块，浪费了上下文窗口空间。LLM可能在回答中自我重复，或者更糟糕的是，将冗余的提及视为佐证并表达出超出合理范围的信心。

修复方法： 将重叠保持在分块大小的10-20%之间。重叠的目的是保留边界上下文，而不是复制整个段落。如果你使用的重叠超过25%，你很可能是在弥补分块粒度问题——应该修正粒度而不是增加更多重叠。

劣质分块模式5：元数据-内容混杂

表现形式：

分块："最后更新：2024-03-15 | 作者：J. Smith | 部门：法务 | 版本：3.2 | 状态：已批准 | 审核日期：2025-03-15 | 第7节中的赔偿条款要求承包商维持不低于..."

原因分析： 文档解析器提取页面上的所有内容，包括元数据头、文档属性和管理信息。分块管道不区分文档元数据和文档内容。

下游损害： 元数据token占据了分块空间却不贡献语义价值。嵌入将元数据噪音与实际内容一起编码，降低了嵌入的表征质量。检索可能匹配到元数据术语（"作者：J. Smith"）而不是内容相关性。

修复方法： 在解析过程中将元数据提取与内容提取分离。将元数据作为结构化字段存储在分块的元数据中（在向量存储中可过滤），而不是嵌入到分块文本中。如果元数据对检索有用，将其作为单独的元数据字段添加，而不是作为嵌入文本的一部分。

劣质分块模式6：多主题分块

表现形式：

分块："员工每个日历年有权享受20天带薪休假。未使用的PTO不结转。另外，公司节日聚会将于12月15日在市中心万豪酒店举行。请在12月1日前回复确认出席。此外，IT部门提醒全体员工每90天必须进行一次密码轮换。"

原因分析： 源文档（员工通讯、会议记录、Slack导出）按顺序包含多个不相关的主题。固定大小分块将它们归入一个分块，仅仅因为它们在文本中恰好相邻。

下游损害： 这个分块的嵌入是三个不相关主题的平均值——PTO政策、聚会后勤和IT安全。对于这三个主题中任何一个的特定查询，它都不会是好的匹配结果。关于PTO政策的查询可能检索不到这个分块，因为嵌入被聚会和密码内容稀释了。

修复方法： 对非结构化或多主题文档使用主题感知分块。主题分割算法可以检测文档内的主题边界并相应地分割分块。对于结构化文档，按章节标题进行分块。对于非结构化文本（会议记录、聊天日志），考虑在分块之前使用LLM插入主题边界。

如何审计你的分块

在调试检索之前，先调试你的分块。以下是一个实用的审计流程：

第1步：随机抽样。 从你的向量存储中随机抽取50个分块。像一个从未见过源文档的人一样阅读每一个。你能理解每个分块讲的是什么吗？它包含一个完整的想法吗？

第2步：测试边界分块。 找到在句中开始或结束的分块。计算它们的数量。如果超过10%的分块存在断裂的边界，你的分块策略需要修订。

第3步：检查孤立分块。 识别引用了"上述"、"如前所述"、"本节"或类似相对引用但引用对象不存在于分块中的分块。这些是孤立的分块，会让LLM困惑。

第4步：测量冗余度。 比较相邻分块。如果超过30%的内容重叠，你的重叠设置过于激进。

第5步：检查表格和列表。 找到包含不完整表格（没有表头的数据）或不完整列表（没有列表介绍的条目）的分块。这些需要原子化分块。

第6步：查找元数据混杂。 找到超过20%文本是文档元数据而非内容的分块。这些需要解析器层面的修复。

构建更好的分块管道

劣质分块的根本原因几乎总是一个选择了一次就再也没有回顾过的分块策略。团队从LangChain教程中选择"递归字符文本分割器，1000个token，200重叠"，部署上线，然后从不查看它实际产生的分块。

分块不是一个配置参数。它是一个数据质量决策，直接决定了你的RAG管道回答质量的上限。没有任何下游技术——重排序、提示词工程、更大的上下文窗口——能够弥补不包含连贯完整信息的分块。

Ertas Data Suite包含一个专用的RAG Chunker节点，让你可以配置分块策略，在画布上直观检查输出分块，并在分块到达嵌入阶段之前迭代调整参数。当你能看到你的分块——真正地逐个阅读它们——你就能在垃圾进入向量存储之前发现它。当分块只是埋在Python脚本中的一个函数调用时，没有人会去看输出。

审视你的分块。阅读它们。如果它们对你来说没有意义，对LLM来说也不会有意义。