智能体错误:数据工程视角

8 小时前 暂无评论 阅读 18 次
收听本文语音

智能体错误:数据工程视角

您花费数周时间精心调校AI聊天机器人,回答准确无误,相关方签字认可,系统顺利上线。然而三个月后,系统对用户提出的近三分之一问题给出了错误却自信满满的答案。模型未变,提示词未动,但世界已经发生变化:价格调整、政策更新、产品规格迭代,而底层知识库却停滞不前。

这并非假设场景,而是当前企业AI应用中最常见的生产故障模式之一。无论数据检索机制如何,大多数数据工程团队都缺乏适当的工具来捕捉这种问题。

隐形的设计缺陷

AI应用程序并不关心它是从向量存储、文档索引还是API调用中检索数据。无论采用何种机制,标准的数据检索管道都不会检查其所提供的信息是否仍然准确。过时的定价文档与最新的文档同样被自信地检索出来,因为系统评估的是相关性或可用性,而非正确性。某个字段悄然缺失的记录与完整的记录一样能顺利通过,原因相同。

因此,这种故障在本质上就是隐形的。过时或不完整的数据在相关性评分上依然很高,或通过了数据管道设计的所有检查。智能体因其检索到的上下文看起来权威而充满自信地回答,您监控的所有仪表盘保持绿色,系统看似正常运行,实则错误百出。

我在AI领域之外见过类似情况,发生在一家金融科技公司的数据管道中。上游系统更改了某个字段却未通知下游用户。管道并未失败,只是错误地传播了这些数值到仪表盘,因为系统只检查作业是否完成,而非数据是否仍然正确。直到客户发现不一致之处,问题才浮出水面,但此时错误数据已向下流动。

无论是文档过时还是字段悄然缺失,故障模式相同:错误的缺席不代表正确性的存在,若不构建适当的验证层,管道中的任何环节都无法识别问题。

数据工程问题的本质

遭遇此类故障的团队往往会误判问题,并且通常会犯同样的错误。

归咎于模型:第一反应是指责模型,尝试不同的LLM,调整提示词。真正的问题位于更上游的数据工程层,这与上述金融科技故障背后的本能相同:为管道而非数据构建的监控。

归咎于检索层:一旦模型被排除嫌疑,下一个本能是指责检索或上下文层,购买更好的解决方案。时机并非巧合:随着企业将这些系统推向实际生产环境,这一差距开始显现,供应商的回应也层出不穷。

  • 亚马逊凭借一种从智能体使用中学习的知识图谱,进入了”上下文层”竞赛。
  • 雪花公司的新的Horizon Context和Cortex Sense直接针对本文开头描述的症状:智能体给出自信的错误答案,因为其底层业务逻辑缺乏治理。

这些都是对真实问题的真实回应,但它们位于问题的一层之上;知识图谱仍依赖于其输入的数据。

真正的问题位于更上游的数据工程层。团队检查的是作业是否运行,而非其所移动的数据是否仍然真实——这种本能早在AI出现前就已存在。监控是为管道构建的,而非为数据。

缺失的关键:数据可观测性

数据可观测性是一个众所周知的概念,但在实际实施中未得到足够重视。相关指标不是百分比,而是覆盖率:关键数据集中有多少比例的来源实际上可查询,而非仅存在于某人的脑海中。

在检索增强生成出现之前,优步就构建了专门的数据质量和可观测性平台。其统一数据质量平台支持超过2000个关键数据集,能在数据质量事件到达下游消费者前检测约90%的问题。

Netflix解决了同一问题的不同部分,构建了公司范围内的数据来源系统,使任何人都能回答数据集的来源及其经历的转换过程。它映射了Kafka主题、机器学习模型和实验之间的依赖关系,而不仅仅是仓库表。与优步类似,该平台最初为人类构建,随着AI/LLM应用的兴起,其重要性愈发凸显。

综合两家公司的做法,我认为数据可观测性应关注四个维度,每个维度都有其可衡量的标准:

正确性:每条记录是否符合其应有的形状和规则,正确的字段类型,无意外空值,数值在合理范围内。Great Expectations和Soda等工具能很好地处理这一点:自动化行级和列级验证,而非在问题出现后的手动检查。跟踪每次验证中通过的记录百分比。

新鲜度:数据相对于其来源是否仍然最新,而不仅仅是上次检查时的最新状态。跟踪每个源上次成功更新的时间,为每个数据集设定SLA,而非采用单一阈值,因为某些源需要每小时刷新,而其他不需要。

一致性:相同事实在存储或索引的各个地方是否保持一致。这种故障悄无声息,只有当两个由同一源提供数据的系统开始出现分歧时才会显现。在下游目的地之间进行定期交叉检查,标记超过阈值的差异率,足以早期捕获问题。

来源:能否将任何输出追溯至其来源及经过的每个转换,这正是Netflix构建其系统要回答的问题。

这些都不需要大多数数据团队尚未拥有的基础设施。我在Socure的经历证明了这一点,客户数据以客户发送的任何形式到达,偶尔也会出现静默错误。挑战在于构建一个能在错误数据向下传播前识别出它的系统。相同的原则适用:验证到达的数据,理解其来源,防止坏数据成为他人的问题。

Great Expectations成为该基础的一部分:摄入时的模式和范围验证,每个源的新鲜度SLA,跨系统的一致性检查,以及文件级别的来源追踪。所有这些都采用了写入-审计-发布模式,数据首先进入暂存区,经过验证,只有通过所需检查后才会向下流动。

结果在下游显现:整体准确性提升,包括报告、机器学习模型和AI检索等各方面。


关注微信号:智享开源 ,及时了解更新信息。


评论列表
发表评论
😀 😂 😃 😄 😅 😆 😉 😊 😋 😎 😍 😘 🥰 😜 😝 🤗 🤔 😭 😤 👍