RAG 数据契约问题：摄取管道如何悄然破坏检索质量

你的 RAG 系统存在一个不会抛出异常的 Bug。它不会拉高错误率，不会在延迟仪表盘上留下痕迹。相反，它会悄悄地给出听起来自信、合理却错误的答案——而没有人在数周内察觉。

这就是 RAG 中的数据契约问题：你的摄取管道是下游所有环节的事实来源，但它没有 Schema 校验、没有新鲜度保障，也没有在外部世界的形态悄然改变时发出告警。每当上游数据源新增字段、分块参数发生偏移，或者嵌入模型被更新，检索质量就会无声地退化。

80% 的企业级 RAG 项目在生产环境中会遭遇严重故障，而其中最隐蔽的那些故障从不宣告自身的存在。

为什么 RAG 的失败方式与传统 ML 不同

在传统机器学习中，当输入分布发生偏移时，通常会有明显的破坏信号：预测值集中在意料之外的区间，下游业务指标出现波动。你有一个输出可测量结果的模型，一旦该指标漂移，你就能察觉。

RAG 系统的失败方式截然不同，因为它拥有第二条管道——摄取管道——而这条管道完全处于代码部署生命周期之外。当摄取管道退化时，LLM 不会抛出异常。它会检索出错误的文档，将其作为上下文，并基于过时或受损的信息生成流畅、自信的文本。输出看起来没问题，你的幻觉检测器可能不会触发，忠实度指标也保持绿色——因为答案对检索到的上下文是忠实的，而那个上下文本身就是错的。

等用户反映系统在给出错误答案时，退化可能已经运行了数周。而且由于代码没有变化，你的第一反应是去排查模型，而不是索引。

RAG 中的故障分类如下：

• Schema 漂移：上游文档新增、删除或重命名了你的提取逻辑所依赖的字段
• 分块参数变更：对块大小或重叠的"微小"调整悄然降低了召回率
• 嵌入模型更新：切换或微调嵌入模型会导致向量分布不匹配，前提是索引中有部分内容使用的是旧模型
• 元数据丰富失败：用于过滤的字段（类别、日期、敏感级别）开始在不同文档来源间以不一致的方式填充
• 数据新鲜度腐化：已索引的文档变得过时，却仍留在语料库中，对它们曾经能正确回答的查询仍然排名靠前

每一种失败模式在表面上产生相同的症状：答案变得稍差。但没有一种会产生错误日志。

数据契约类比

数据工程团队对这个问题有一个实用的概念：数据契约。契约是数据生产者与数据消费者之间的一份正式、明确的协议，规定数据的外观——包括 Schema、质量约束、新鲜度保障，以及在发生偏差时谁负责。

RAG 摄取管道需要同样的东西。现在，大多数团队将摄取管道视为基础设施管道：它运行，它索引文档，直到它不再正常工作。没有明确的契约说明"本管道保证每个 chunk 都有 source_id，语义重复文档不超过 1%，过期 90 天以上的文档在经过新鲜度复核前不得出现在政策类别中"。

没有这些保障，管道中任何地方的每一次变更——从源 Schema 到分块逻辑再到嵌入模型——都是一个静默风险。

一份最小化的 RAG 摄取契约包含四个组成部分：

结构性保障：稳定的 chunk ID、一致的元数据 Schema、无缺失嵌入。每个 chunk 必须有 document_id、chunk_id、source 和 timestamp。若一批数据未通过此检查，则不得进入索引。

质量保障：元数据完整率高于阈值（必填字段为 100%）。语义重复率低于 1%。引用完整性高于 95%——如果文档链接到外部资源，应有相当比例的链接仍然有效。

新鲜度保障：按内容类型设置明确的 TTL。政策文档 12 个月过期，API 文档 30 天过期，竞争分析 7 天过期。这些不是软性建议，而是索引的可强制执行属性——超过 TTL 的文档会被自动标记或删除。

血缘追踪：索引中的每个 chunk 都应携带元数据，记录哪个嵌入模型版本生成了它的向量，以及使用了哪些分块参数。没有这些信息，诊断检索回归就如同考古。

静默退化的真实面貌

考虑嵌入模型微调时会发生什么。直觉上很有吸引力：在领域专属数据上微调，获得领域相关的嵌入，从而获得更好的检索。基准测试通常在被优化的特定任务上证实了这一直觉。

基准测试没有捕捉到的是语料库其余部分的分布偏移。实际上，在窄任务上微调中等规模的嵌入模型可能导致广泛检索能力下降 40%。系统在窄任务上变得更好，在其他所有方面变得更差。由于评估集就是窄任务，回归在用户提出超出该范围的问题之前不会被发现。

分块变更也有同样的动态。页面级分块与自适应语义分块之间的召回率差距可达 9 个百分点。不同块大小之间的差距较小，但仍然有意义。当团队在部署中途调整分块参数——即便出于好意，比如改善连贯性——他们实际上是在没有重新评估的情况下重新索引了。如果新的分块策略在现有查询分布上表现更差，这一信息只有在用户开始投诉后才会浮现。

加载中…