Stale Data Used to Be Annoying

TL;DR · AI 摘要
Stale Data Used to Be Annoying - Gradient Flow Stale Data Used to Be Annoying Posted by Ben Lorica September 23, 2026 Au...
核心要点
- 主题聚焦:Stale Data Used to Be Annoying
- 来源:Gradient Flow,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
过时数据曾经令人烦恼 - Gradient Flow
过时数据曾经令人烦恼
作者:
Ben Lorica
2026年9月23日
2026年8月31日
发布于:
未分类
.meta-info
.post-thumbnail
想象一位采购代理在检查库存并决定库存已低于补货阈值时,会下达新的订单。问题是几分钟前已经记录了一笔大额到货,而代理查询的数据副本尚未更新。基于过时数据运行的仪表板可能会显示错误的库存数字。基于过时数据运行的代理可能会下达错误的订单。
多年来,许多分析系统可以容忍一些延迟、模糊和不完美的数据,因为结果和行动之间有一个人作为缓冲。这个人可以等待缓慢的查询,注意到某个数字看起来有问题,或者询问适用的定义。代理去除了大部分这种缓冲。它们会检查数据、采取行动、观察结果并再次检查。
上周我写了关于保留工作执行历史价值的文章。本周我想探讨代理在执行任务时需要了解的内容。
##### 仅相关性已不再足够
第一波企业AI的重点是检索:找到与问题相关的信息并将其呈现给模型。代理需要回答不同的问题。不仅是哪些信息相关,而是当前哪些信息是真实的。付款是否已到账?库存是否还存在?账户是否一小时前被暂停?其他流程是否已经修改了记录?五分钟后的信息可能对研究问题来说没问题,但对行动来说可能是危险的错误。
新鲜度不是唯一的问题。定义同样重要。假设有两个系统对什么是活跃客户存在分歧。注意到模糊性的分析师可以停下来询问他人。而代理可能会选择一个定义并继续执行。
一个小型基准测试展示了这个问题。当业务定义和关系在事前建模时,准确性显著提高。我发现失败模式比分数更有趣。当语义层(编码这些定义和关系)无法回答问题时,它会明确说明。而当模型直接对数据编写SQL时,它可能会返回一个完全合理但错误的数字。
当数据指导人类时,模糊性会导致分析错误。当代理基于这些数据行动时,同样的模糊性可能导致操作失误。
##### 分析查询成为生产依赖
如果正确答案来得太慢或根本没有,也是不够的。人类运行分析查询时通常可以等待。代理可能需要等待该查询完成才能进行下一步操作。
如果查询是二十步中的第七步,每一秒的额外延迟都可能影响后续步骤。超时可能会中断客户交互或业务流程,而不仅仅是让人盯着仪表板发呆。软件还可以同时启动许多任务,并随着条件变化重新访问相同的数据。
这给一些分析系统带来了不同的要求。延迟、可用性、并发性和工作负载隔离开始以更像应用程序基础设施的方式变得重要,而不仅仅是传统的分析。
##### AI行动时数据质量更加重要
过时记录、重复项、定义不一致以及文档不完善的字段是常见的数据问题。更优秀的模型并不能让这些问题消失。不同之处在于,当代理对这些数据采取行动时可能发生的事情。
一个重复记录可能引发重复的外联或第二次交易。错误的实体匹配可能导致对错误账户采取行动。文档不完善的字段可能悄然改变代理认为正在测量的内容。
在一项实验中,添加用户画像和查询历史使分析代理的可靠性约为40%。清理数据模型并改进文档后,可靠性提升至约90%。这是一个具体结果,而非基准测试,但其中的教训很有价值:基础的数据建模和文档比增加更多上下文更重要。
一些看似是人工智能失败的案例,实际上是旧数据问题的后果,这些后果现在已经演变为运营层面的问题。
##### 权限必须跟随数据
代理还使得一个古老的权限问题更加复杂。一个任务可能需要从仓库、搜索索引、SaaS应用、向量存储或缓存中提取信息。这些系统不一定以相同方式执行访问控制。
假设源系统隐藏了某个员工的文档,但基于该系统的搜索索引未保留相同的限制。代理从索引中检索信息时,现在能看到该员工无法从源系统获取的内容。
这就是为什么权限不能仅在数据首次进入系统时进行检查。当信息被复制、索引、缓存或从其他地方检索时,访问规则必须随之传递。
实际问题依然简单:当代理读取一条记录时,它行使的是谁的权限?
##### 生产环境需要的不只是检索
我去年提到的一些数据库架构在此背景下更有意义。Databricks 正在通过一种架构进一步推动这一理念,该架构使事务处理和分析工作负载能够在一个统一的存储层上运行,而不是不断将操作数据复制到单独的分析系统中。减少复制可能意味着业务变化与应用程序或代理获取该变化之间的延迟更小。
但我认为,更广泛的教训比任何单一架构都更有价值。原型可以展示代理执行任务的可能性,但无需证明周围的数据系统能否可靠支持。
生产环境必须回答更困难的问题。状态是否具有权威性?代理如何学习到某事物发生了变化?数据被复制或索引时权限是否仍然有效?部分失败后会发生什么?重试能否重复执行某个操作?一个可用的演示可能掩盖了仍需构建的数据基础设施规模。
多年来,数据栈主要帮助公司观察和理解自身。如今,代理在执行任务时越来越多地使用相同的信息。
一旦代理能够对其检索到的数据采取行动,数据栈就成为应用程序的一部分。