构建理解产品分析语言的数据Agent

这篇博文由 Amplitude 的 Agents 产品营销负责人 Nikhil Gangaraju 共同撰写在你最优秀的分析师编写第一条 SQL 之前，他们已经完成了查询无法捕捉的工作。

他们记得“用户注册”被定义为“转化事件”。他们检查了上周的实验是否将流量转移到了具有不同注册流程的变体。他们在心里排除了 iOS 队列，因为上周二的 SDK 更新改变了 onboarding_finish 的触发方式，而数据尚未重新处理。他们回忆起官方仪表板中的数字使用了过滤定义，排除了内部员工。

这些信息大部分需要将正确的事件、细分定义、实验历史和该业务特有的平台行为拼接在一起。经验丰富的分析师知道该看哪里以及哪些关系重要。他们的个人背景成为分析产品数据时极其宝贵的部分。

现在把同样的问题交给一个根据数据仓库生成 SQL 的 AI 代理。它没有关于产品如何运作的背景。它看到的是列和表。它生成语法有效的查询。它返回一个数字。数字很精确，返回很快，但在没有预先知道答案的情况下，往往很难发现其错误。

AI 代理有望简化分析工作流程。这个承诺是真实的，但在实践中，它们只是更快地生成 SQL，对数据的实际含义理解甚少。

从上下文问题开始

我们构建 Agents 时最早的挑战之一是冷启动问题。代理需要良好的上下文来准确回答真实的产品问题。

客户通过正常产品使用创建的每个事件、漏斗、队列、实验和分类定义都为代理提供了可供利用的上下文。当产品团队构建跟踪 onboarding 转化的图表时，该定义可供代理使用。当他们定义“超级用户”队列时，代理可以引用它。当他们运行实验时，处理组和结果之间的关系被结构化地捕获。团队为使数据对自身分析更有用而做的所有工作也最终改善了代理的思考方式。

我们倾向于这个想法：团队使用 Amplitude 越多，其代理应该获得更多关于事件、指标、仪表板和分类的上下文，而无需额外的语义工程。因此，我们着手构建以产品分析语言推理的代理。

这种差异在难题上最为明显，这些问题为你的业务提供了最大价值。你需要知道为什么你的绩效在变化以及下一步该做什么。你需要提出后续问题并探索不同的假设。这种分析需要大量结构良好的行为上下文。你团队中的某个人可以有意识地构建这一切，或者你可以使用一个一直在默默积累这种上下文的平台。

Amplitude 是语义层

这个概念解释起来比构建起来简单：Amplitude 本身就是一个语义层，并随着客户的使用而增长。那么这在实践中意味着什么：

原始数据源

原始分类法包括事件名称、属性名称及其描述。使用元数据捕获每个事件被查询的频率、摄入量以及在平台上的位置。

图表和仪表板带有标题、描述以及关于其测量内容的上下文。仪表板被标记为官方。我们跟踪内容被查看的频率、查看者以及最近一次查看的时间。

实验、笔记本、队列以及平台中引用事件和属性的每个部分都增加了另一层结构化含义。

然后是客户自己带来的上下文：产品文档、组织级描述、关于数据怪癖和命名约定的项目级笔记。所有这些都汇入同一个池中。

语义元数据

这对代理有用的关键在于接下来发生的事情。我们的嵌入模型运行在所有原始分类法源上，以分类和标记分类法数据，我们称之为语义元数据。我们生成类别、描述和引用标签，这些被捕获在嵌入模型中，以便代理在查询时访问

目前产品中没有任何地方可以直接检查给定事件或属性的语义元数据——这是一个我们正在探索的方向——但就目前而言，它在幕后工作以支持代理推理。

查询时检索

以下是在查询时检索的工作原理：当用户向全局代理询问类似“告诉我为什么注册转化率呈下降趋势”时，分类代理会利用一个嵌入模型，该模型基于每个带“注册”或“转化”字样的图表和仪表板，以及这些图表中使用的事件和属性构建。它还会在整个分类法上运行语义搜索，发现“registration”是“sign-up”的同义词，即使事件名称中不包含这些词。

一个客户轶事很好地说明了这一点：一个团队注意到 AI 在某些话题上遇到困难。于是他们创建了涵盖这些话题的结构良好的仪表板，并看到 AI 在这些问题上的表现实时改善。这些仪表板成为新的语义真值来源——具有受治理定义和使用模式的官方内容，直接流入上下文层。

语义层随着团队的工作而积累，并随着他们使用平台而复合增长。

在代理框架内部

一切始于用户的提示，但系统接下来做的是汇集现有上下文。代理的上下文窗口包括系统提示（我们控制的），加上客户添加的任何组织级或项目级自定义上下文。它还会获取页面上下文：如果你在仪表板上打开代理，它会知道你正在查看哪个仪表板。它还有完整的聊天历史，因此在对话的第七轮，代理拥有你已讨论内容的上下文。

所有这些都会发送给LLM，代理开始使用我们的MCP工具和子代理来处理任务。它首先解释问题的意图，计划调用哪些工具以及顺序，执行该计划，并综合结果。

最后，有特定的后处理步骤：在用户业务上下文中解释数据，添加引文和链接以便用户验证结果，并生成后续问题以便代理继续后续问题。

策划正确的上下文

我们很早就认识到，语义元数据再丰富也不总是足够的。每家企业都有自己的术语、季节性和数据怪癖。因此我们构建了一种方式，让客户直接向代理添加这些上下文。

在Amplitude中，有几种方法可以用上下文丰富代理的知识。

组织上下文

在组织层面，你可以描述你的业务、目标以及你所在行业独特的季节性模式。对于你的每个项目，你还可以解释特定数据项目衡量什么，标记命名约定，或注明特定的埋点怪癖。

知识库

我们还构建了一个知识库，代理可以在分析过程中使用它进行检索增强生成，从上传的文档中提取上下文。你可以上传产品策略文档、数据字典，或任何分析师为了正确回答问题通常必须从Google Doc中翻找的东西。对许多团队来说，上传文档比填写10,000字符的文本字段更快。

这种影响在大规模应用中很快显现。我们的一位客户上传了一份63页的数据字典，自动丰富了超过5,000个事件和属性的描述。当你以这种规模操作时，文档上传往往是唯一能足够快地把上下文落实到位的方法。

组织上下文和知识文档在捕捉变化不大且适用于整个组织的上下文方面非常出色。然而，我们也看到客户在跨每次对话编撰偏好、术语和数据问题的某些细微差别方面遇到困难。

记忆

为了解决这些限制，我们正在引入记忆。

使用记忆可以让代理自动从过去的对话中学习——尤其是那些有用户明确反馈的对话，尤其是当模式、纠正或偏好反复出现时。此外，记忆会根据近期性、强化和矛盾来分配重要性。

运行时上下文

最后，在运行时，我们从用户提示和用户提问的页面添加上下文（例如图表名称、图表定义等）。这是关键上下文，对于确保代理的响应与用户的问题相关是必要的。

为代理可靠性构建反馈循环

全局代理在所有分析任务中的整体成功率，显示随时间持续改进。基线9%代表最佳的仓库Text-to-SQL性能在多查询生产级工作流中。

构建在生产环境中工作的代理，真实用户提出意外问题，而错误答案会侵蚀信任，这是一个问题。分析结果被证明是更难的人工智能用例之一：客户数据混乱，问题模糊，当问题是开放式的时，验证见解可能很困难。

构建评估框架。 我们建立了评估框架早期，但真正让它有用的是将其与具体的、可衡量的分析任务联系起来，而不是通用的"代理有帮助吗？"指标。

我们定义了代理应该能够完成的四类分析工作，按难度递增排列。

描述性（发生了什么？）：代理能否正确描述跨指标、时间段和段的用户行为？

诊断性（为什么会发生？）：它能否进行多步分析，探索假设，并识别可能的根本原因？

预测性（将会发生什么？）：它能否基于历史模式和行为信号预测结果？以及

规范性（我们应该做什么？）：它能否推荐与数据相关的具体行动？

每个都映射到用户实际提出的问题类型，并且每个都有清晰的标准来定义正确答案的样子。我们使用LLM作为评判者，根据人工定义的标准评估每个回答，对捕获目标见解的响应百分比进行评分。

我们的基线——用直接指向数据的简单查询工具能取得的最佳成绩——在现实、多步骤的生产工作流中得分约为9%。经过六轮连续的添加专门子代理、改进上下文检索和调整基础设施，全局代理在四种任务类型中达到76%。现在它在描述性和诊断性工作方面表现良好，在预测性和规范性方面能力正在增长。

可观测性贯彻到底。 每次代理交互都被记录：调用了哪些工具，注入了什么上下文，模型推理了什么，以及哪里出错了。自定义会话查看器让团队逐步回放代理交互。这弥补了我们以为用户会问的问题与实际提出的问题之间的差距。我们已经在此详细介绍了我们如何构建代理分析作为在线评估的基础。

为代理工作负载创造可扩展的经济性

当人类分析师每天运行几十个查询时，基础设施成本是可控的。代理改变了我们的计算方式。

一个单一的洞察可能触发数十个查询，因为代理会探索数据、检查假设，并在迭代循环中完善答案。行为分析查询通常计算量很大：会话化、漏斗分析、留存曲线、路径分析，所有这些都需要在大型事件表上进行多次连接。早期，我们看到代理的成本优化成了一个持续的工程问题，叠加在分析工作本身之上。

这正是我们的Nova引擎发挥真正作用的地方。Nova是Amplitude专有的行为模型，专为这类查询而构建。它将分析原语预计算到受治理的缓存层中，这意味着产品分析查询中最昂贵的部分（连接、会话化和漏斗步骤匹配）在代理提问之前就已经处理好了。

为了了解这在实践中到底有多重要，我们在Nova和Snowflake上对具有代表性的产品分析工作负载进行了成本比较，使用了来自不同数据量客户的真实数据集。我们使用真实数据集，对比了Nova和Snowflake在代表性查询类型（事件细分、多步骤漏斗和留存）上的表现。

对于每个查询，我们在Nova和不同大小（X-Small到X-Large）的Snowflake仓库上运行了等效查询，记录了运行时间、Snowflake计费成本以及用于归一化比较的AWS等效计算成本。

平均而言，在所有客户规模和查询类型中，Snowflake的成本高出2到8倍。随着数据量增大和查询更复杂（如漏斗和留存），差距进一步扩大。要让Snowflake达到最佳性能，还需要大量的数据工程工作：按查询访问模式对事件表进行聚类，将嵌套属性提取为可查询的列等。

我们也没有将额外的ETL成本计入比较。这个测试假设数据准备/转换得当。在数据准备不当的情况下，我们看到成本相比Amplitude增加了15到65倍。

我们的Nova引擎将代理规模的查询量转化为可预测的成本，没有随代理工作负载增长而增加的每次查询定价。实时摄入还意味着代理使用最新数据。对于功能发布或影响收入的实验上线，当分钟至关重要时，这可能是区分在用户仍在会话中时发现问题，还是在转化率下降后才发现问题。

异步代理弥合了洞察与行动之间的差距

大多数分析代理只在你坐着提问时工作。我们认为这是一个比听起来更大的限制。代理可以异步运行，在你参加下一个会议时工作，并处理原本会排队的分析工作流。

这就是为什么我们在构建全局代理的同时，还构建了专用代理，并且像投资按需聊天体验一样，投资了异步形式。全局代理是按需专家：你提问，它分析你的数据，并采取行动。

专用代理是异步工作开始显现的地方。会话回放代理可以在后台监控你的结账漏斗，持续扫描新会话。一天早上，它发出警报：“iOS移动用户在8秒内放弃支付页面。75%的人从未滚动到表单。主CTA上检测到三次愤怒点击模式。”该发现附有证据（会话回放片段、定量细分）和建议的后续步骤。没有人需要检查仪表板或分配工作。

代理可以在分析和行动之间切换，无需更换工具。发现漏斗中摩擦点的代理可以调出会话回放，显示用户为何遇到困难，检查是否已有实验正在测试修复方案，或必要时设置一个。

我们最终的目标是让代理从头到尾拥有一个分析工作流：检测信号，找出原因，并推荐应对措施。我们关心的转变是，无论是否有人在看，工作都会发生。

我们学到的经验

六个月来在生产环境中构建和运营代理，改变了我们对几个领域的思考：

#1 语义层比模型更重要。

早期，我们认为更好的模型将是代理质量的主要驱动力。它们有帮助，但准确性的最大提升来自丰富代理可用的上下文，而不是换成更强大的模型。一位客户直接教会了我们这一点：他们的团队注意到代理在某些主题上较弱，构建了涵盖这些领域的结构良好的仪表板，并看到准确性实时提升。这个反馈循环现在塑造了我们对整个系统的思考。首先投资语义层，然后模型升级会在此基础上复利增长。

#2 成本结构比我们预期的更重要。

如果每个代理查询的成本与云数据仓库上人类发起的查询相同，那么代理很快就会变得昂贵。Nova预计算的行为模型将代理规模的查询量从成本问题转变为可处理的工程问题。没有这个基础，我们会在成本优化上花费比代理质量更多的时间。

#3 当我们将评估建立在客户关心的实际工作流上时，评估才变得有用。

通用的“有帮助”分数几乎告诉不了我们什么。四类框架（描述性、诊断性、预测性、规范性）为我们提供了一种共同语言，用于说明代理应能在客户工作负载中做什么，并成为衡量进展的具体方式。

#4 向异步工作的转变被证明是一个重大解锁

代理擅长监控、模式检测和假设检验，这些工作没人有时间手工完成。专门的代理可以端到端地拥有该工作流程，而异步形式正是实现这一目标的方式。

展望未来

我们这一旅程已进行了六个月，有一点很明确：系统在持续累积。每一轮改进——更丰富的语义上下文、更好调优的子代理、更严格的评估标准——都建立在上一轮的基础上。我们在描述性和诊断性工作方面最强，预测性和规范性能力也在每一次迭代中提升。

虽然还处于早期阶段，但轨迹已明确。代理正成为产品分析的主要界面，而要成功实现这一点，需要将语义上下文、评估严谨性和成本效率视为一流的工程问题。