你花了数周时间调优一个 AI 聊天机器人。答案准确，利益相关方签字认可，然后你把它上线。三个月后，系统对用户提出的问题中大约三分之一都在自信地给出错误答案。没有人改过模型，也没有人动过提示词。只是外部世界变了：价格调整了，政策更新了，产品规格发布了新版本，而底层知识库没有同步变化。

这不是一个假设场景。它是当前企业 AI 在生产环境中最常见的故障模式之一，而且无论 AI 系统如何检索数据，大多数数据工程团队都没有合适的工具来捕捉它。随着企业从 AI 试点走向大规模生产部署——Gartner 一直将数据质量列为 AI 采用的主要障碍之一——这类故障正在从偶发的麻烦演变为系统性风险。

看起来不像故障的故障

AI 应用并不关心它是从向量库、文档索引还是 API 调用中检索内容。无论机制如何，标准检索管道中都没有任何东西会检查它提供的内容是否仍然正确。一份过期的定价文档会像当前文档一样被自信地检索出来，因为系统评分的是相关性或可用性，而不是正确性。出于同样的原因，一条悄然缺失某个字段的记录也会像完整记录一样顺利通过。

因此，这种故障在设计上就是不可见的。过时或不完整的数据仍然会在相关性上获得高分，或者通过数据管道被设计用来执行的每一项检查。模型会充满信心地作答，因为检索到的上下文看起来很权威。你监控的每个仪表盘都保持绿色。系统看起来像是在正常工作。它只是错了。

我曾在 AI 语境之外的一个金融科技管道中看到过类似情况。一个上游系统在没有通知下游用户的情况下更改了某个字段。管道没有失败；它只是把错误值传播到了仪表盘中，因为系统只检查作业是否完成，而不检查数据是否仍然正确。问题直到一位客户发现不一致之处时才暴露出来。到那时，错误数据已经流向下游。

无论是一份已经过时的文档，还是一个悄然缺失的字段，故障形态都是一样的：没有报错并不等于存在正确性；如果不构建适当的验证层，管道中就没有任何东西能够识别问题。随着 AI 代理从回答问题转向执行操作，风险也在上升——一个基于过期价格或废止政策行动的代理，可能执行错误交易，而不只是返回错误答案。

为什么这是一个数据工程问题

遇到这种故障的团队往往会误诊，而且通常会误诊两次。

归咎于模型： 第一反应是责怪模型，尝试另一个 LLM，调整提示词。真正的问题位于更上游的数据工程层——这与上面金融科技故障背后的直觉相同：监控是为管道而建的，不是为数据而建的。

归咎于检索层： 一旦排除了模型，下一种本能就是转而责怪检索层或上下文层，并购买一个更好的方案。这个时点并非巧合。随着企业把这些系统推向真实生产环境，这一缺口正在开始显现，而供应商的反应也随处可见。AWS 刚刚凭借一个可从代理使用中学习的知识图谱加入“上下文层”竞赛。Snowflake 新推出的 Horizon Context 和 Cortex Sense瞄准的正是本文开头描述的症状：代理自信地给出错误答案，因为其底层业务逻辑没有被治理。

这些都是对真实问题的真实回应，但它们位于问题之上一层；知识图谱仍然依赖于输入给它的内容。真正的问题位于更上游的数据工程层。团队检查的是作业是否运行，而不是它搬运的数据是否仍然真实——这种惯性早在 AI 出现多年以前就存在。监控是为管道构建的，不是为数据构建的。

真正缺失的是什么：数据可观测性

数据可观测性是一个广为人知的概念，但在实际实施方式上并没有得到足够关注。过去几年，这一类别本身已经成熟起来——Monte Carlo Data 等公司已经为此构建了专门平台，IBM 也在 2022 年收购 Databand，以加强自身的数据可观测性能力——但采用情况仍不均衡，尤其是在那些近期才开始基于现有数据基础设施构建 AI 应用的团队中。

相关指标不是一个百分比，而是覆盖率：关键数据集里有多大比例具备真正可查询的血缘关系，而不是只存在于某个人的脑子里。

Uber 很早就构建了专门的数据质量和可观测性平台，远在检索增强生成出现之前。其 Unified Data Quality 平台支持超过 2,000 个关键数据集，并能在约 90% 的数据质量事件到达下游消费者之前检测到它们。

Netflix 解决了同一问题的另一个部分：它构建了一个全公司范围的数据血缘系统，让任何人都能回答某个数据集来自哪里，以及在流转过程中经过了哪些环节。它映射 Kafka topic、ML 模型和实验系统之间的依赖关系，而不仅仅是数据仓库表。与 Uber 类似，这个平台最初是为人类构建的，而随着 AI/LLM 应用的兴起，它现在变得更加重要。

Uber 和 Netflix 合在一起覆盖了值得构建的四项能力中的两项。在实践中，我将其视为四个维度，每个维度都可以用自身的标准来衡量。

正确性： 每条记录是否符合它应有的形态和规则——字段类型是否正确，是否没有意外的空值，取值是否在范围内。Great Expectations 和 Soda 等工具在这方面做得很好：它们提供自动化的行级和列级验证，而不是等到出问题后再进行人工检查。应跟踪每次运行中通过验证的记录百分比。

时效性： 数据相对于其来源是否仍然是最新的，而不只是相对于上一次检查来说是最新的。应按数据源跟踪距离上次成功更新的时间，并为每个数据集设置 SLA，而不是使用一个统一阈值，因为有些来源需要每小时刷新，而有些并不需要。

一致性： 同一个事实在所有存储或索引位置的读取结果是否一致。这类问题会静默失败——只有当两个由同一来源供给的系统开始相互矛盾时才会显现。定期在下游目标之间进行交叉检查，并在不匹配率超过阈值时标记出来，就足以尽早发现问题。

血缘关系： 你能否将任何输出追溯到其来源，以及它经过的每一次转换——这正是 Netflix 构建其系统所要回答的问题。

这些都不需要大多数数据团队尚未拥有的基础设施。我知道这一点，因为我不仅主张过它，也实际构建过它。

在 Socure，客户数据会以客户想发送的任何形式到达，而且偶尔会在无声无息中出错。挑战在于构建一个系统，使错误数据能够在传播到下游之前被识别出来。同样的原则适用：验证到达的数据，理解它来自哪里，并防止坏数据变成别人的问题。

Great Expectations 成为这一基础的一部分：在摄取阶段进行模式和范围验证，为每个来源设置时效性 SLA，执行跨系统一致性检查，并建立文件级血缘关系。所有这些都位于一个写入-审计-发布模式之后：数据先进入暂存区，经过验证，只有在通过所需检查后才会流向下游。

结果在下游显现出来：报告、ML 模型以及建立在同一数据之上的 AI 检索，整体准确性都有所提升。

周一早上该做什么

如果你正在生产环境中运行基于检索的 AI 系统，诊断问题不应是下一步尝试哪个模型，或迁移到哪种检索架构。它应是四个更具体的问题：

1. 底层数据是否按照其消费者所要求的标准进行了验证？
2. 当前被高置信度提供的最旧内容是什么？
3. 同一来源的两个片段是否可能在同一个检索结果中相互矛盾？
4. 如果它最终被证明是错误的，你能否追溯它来自哪里？

如果你无法回答这些问题，那么缺口就位于你的源系统与代理所读取内容之间的管道中。这是一个数据工程修复问题，而不是更换模型或迁移供应商的问题。

无论你是在构建报告管道、ML 系统还是 AI 代理，正确性、时效性、一致性和血缘关系才是让数据可信的基础。AI 只是暴露了数据工程中一直存在的薄弱环节。