数据Agent将制造机器查询洪峰，传统数仓面临新负载
译文 AI 逐段翻译
过去一年，智能体几乎出现在软件领域的各个角落，但有一个明显的例外：数据。这有点奇怪，因为查询数据正是智能体擅长的结构化、可检查的任务。最可能的罪魁祸首是时机。大型语言模型只是在最近六到九个月内才可靠地擅长编写SQL，而该领域尚未跟上这所带来的可能性。值得区分这一理念的两种形式：做分析的智能体，以及帮助你运行数据管道（data plumbing）的智能体。事实证明，两者都比乍看起来更有用。执行分析，以及帮助您运行数据管道的代理。两者都比初看起来更有用。
数据工程之所以困难，主要是因为你要受制于你无法控制的系统。模式（schema）会在没有警告的情况下发生变化。数据源会离线。你从中拉取数据的API会发布新版本。一个只包含整数的列开始返回小数。一个你假设唯一的字段出现了重复，下一次连接（join）就会爆炸成笛卡尔积（Cartesian explosion）。记录会丢失，或者在一个小时内返回错误，然后悄悄自行修复。如果什么都不变，数据工程就会变得容易。但正如他们所说，唯一不变的就是变化。
无聊的工作是智能体茁壮成长的地方
平淡无奇的维护工作正是智能体真正擅长的。每个数据模型都是一堆假设的堆叠：这个字段是唯一的，那个字段总是有值的，这两个表可以干净地连接。智能体可以读取你代码中的这些假设，并将其转化为测试，检查这些假设是否仍然成立。很多修复实际上都是机械性的：表被重命名了，类型被扩展了，列被移动了。智能体通常可以自行修补这些问题，当它无法修复时，它仍然可以做跑腿的工作，追踪变化并交给人类一个诊断和修复建议，而不是仅仅在凌晨3点给出堆栈跟踪（stack trace）。
上下文是故事的另一半，而上下文的现状实际上是一团糟。供应商们努力让你相信只有他们的语义建模语言才能拯救你，而目前还不完全清楚这些语言是否有必要，甚至是否充分。无论你将业务逻辑放在像MetricFlow或Malloy这样的语义层中，还是直接放在纯Markdown中，目标都是一样的：将该逻辑转化为LLM可以使用的形式。上下文几乎总是手动创建的，就像所有手写的文档一样，从写下的那一刻起就开始漂移。MetricFlow或Malloy，或者就用普通的Markdown，目标都是一样的：将这些逻辑转化为LLM可以使用的形式。上下文几乎总是手工创建的，就像所有手写文档一样，它从写下的那一刻起就开始漂移。
这凸显了一个机会，即智能体恰好擅长上下文中机械性的部分，而恰恰不擅长非机械性的部分。智能体可以推断哪些表可以连接到哪些表，一列通常包含什么值，你的销售区域是什么，以及人们实际查询哪些表。它无法推断的是那些从未真正是数据问题的东西：计算收入的“正确”方法，什么算作“客户”，财年何时开始。这些不是隐藏在数据仓库中等待被发现的事实。它们是决策，通常是业务决策，需要由人来做出。智能体所能做的是在其中一个悄悄不再成立的时候发出警告。正确的计算收入的方式，什么算作“客户”，财年何时开始。这些并不是藏在数据仓库里等待被发现的事实。它们是决策，通常是商业决策，必须由人来做出。代理能做的，是在其中一个决策悄悄不再成立的那一刻发出提醒。
自动化的智能体洞察仍然是一个幻想
更华丽的推销，即智能体揭示你从未问过的洞察，是我最不看好的那个。拥有免提分析听起来很棒。智能体会监视你的数据，注意哪些重要，并投放一个根据今天发生的事情定制的仪表板。但相关性（relevance）的门槛很高，误报（false positives）可能让人类用户失去信心。
确定性告警系统也有同样的问题。人们最终会关掉警报，因为它们太难调优了。但是，如果编写预置触发器的人类都很难做对，那么智能体也很难做得更好（至少在我们获得某种形式的超级智能之前不会）。虽然我预计主动洞察（proactive insights）将成为未来的一部分，但它们在目前仍然是一个研究原型。
以下是数据团队为让他们的技术栈为智能体做好准备而应该做的三件具体事情：
- 先打好基础。有吸引力的智能体用例建立在大多数团队尚未铺设的基础之上。在你决定你的上下文将如何工作之前，你不需要智能体来管理你的上下文。
- 然后追求上下文。编写几个评估（evals），将它们自动化，然后等待看看什么会出问题。评估是承重墙（load-bearing）。它们是让智能体靠近你的管道变得安全的关键，因为它们会在智能体出错的那一刻告诉你。
- 在适合智能体行为的基础设施上运行。智能体在一瞬间从零到查询洪流（flood of queries），所以你需要能够快速扩展和缩小的东西。智能体还会分叉（fan out），同时追踪多个线程，因此你既需要足够的空间（headroom），也需要租户隔离（tenant isolation）来吸收突发负载。一个智能体的好奇心不应该摧毁其他人运行查询的能力。
延迟比看起来更重要
当你使用智能体时，延迟比你预期的更重要。虽然你可能会等上几秒或几分钟让Claude Code完成它的工作，但它经常在运行一堆任务。智能体花费的部分时间在等待LLM，但越来越多的时间花在使用其他工具上，比如查询数据库。随着时间的推移，你可以预期LLM会变得更快；你可以使用更小的模型、更聪明的模型、本地模型或更高级的GPU。随着这种情况的发生，智能体使用的工具将成为瓶颈。
设想两个引擎：一个在10毫秒内回答，另一个在100毫秒内。人不会注意到差异，因为两者都感觉接近瞬时，而且人思考下一个问题所花费的时间远远超过任何一个引擎回答它所花费的时间。对智能体来说感觉瞬时的是非常不同的，它不需要停下来思考。当其下一个查询依赖于上一个结果时，10倍的差距会直接转化为每分钟多10倍的工作量。
让代理更快的方法之一是将其更多的工作并行运行。但这也会增加系统的负载。你需要确保有足够的并行容量和隔离性，以便能够同时扩展到所有并行代理查询。为人类耐心调优的引擎和为代理吞吐量调优的引擎不是同一种引擎。
无论哪个团队是否准备好，代理浪潮都即将到来，而开始准备自己和你的技术栈的最佳时机就是现在，在查询开始涌入之前。这不仅仅是面向未来。早期行动起来的团队是那些找出其他团队最终会效仿的模式的人。现在的一点好奇心能换来真正的领先优势。
—
新科技论坛为技术领导者——包括供应商和其他外部贡献者——提供了一个以空前深度和广度探索和讨论新兴企业技术的场所。选择是主观的，基于我们认为对InfoWorld读者重要且最感兴趣的技术。InfoWorld不接受营销材料用于发表，并保留编辑所有投稿内容的权利。将所有咨询发送至[email protected]。