看了一篇uber 在内部通过 agent 来做业务数据检索的实践，是很标准的 agent 逻辑，值得参考，如果你在产品里还没找到 AI 落地的方式，那么可以做一些内部提效的实践，积累经验

《Uber 如何构建用于财务分析的对话式 AI 助手：让查数据像给同事发消息一样简单》ybzavo65ti.feishu.cn

如果想查一些业务数据，要么自己去找风神/灯塔之类的数据后台，要么找数据分析师跑 sql，响应比较慢。于是 uber 做了一个对话式数据助手，在 slack 问 agent 数据问题，agent 直接回复，让数据检索如同向同事发送消息般简单。

就像老板半夜问我一个数，如果周报里没有现成的，我就要看遍数据集，甚至求DS 帮我跑 sql，然后给老板一个直接、清晰、简洁的答案。

几年前我和DS 说，能不能以后出来一个人工智能，老板想看什么数据，它就从数据库里跑出来，不要老是找我。DS 对我说，你不就是老板现成的人工智能吗...

在字节的时候，风神里也有输入自然语言，然后AI 帮我写 sql，但是发现实际用处不大，那些字段、口径，你都不知道水有多深，最终还是要靠 DS。在字节头一年，我学会了数据分析，后两年，我学会了口径分析。

这里总结一下 uber 的跑数 agent 的核心逻辑，我真希望各个公司都有这样的基建，让跑数不再反人性。

1. multi-agent 架构

主 agent做意图识别和分流，子 agent 处理对应的具体任务，比如写 sql。

关于走 multi 还是 single，我觉得 uber 的场景走 multi 是合理的，因为每个 sub 的任务都比较独立且复杂，在 sub之间的传递信息也都比较明确，而很多业务场景其实用不到 multi架构，直接 single 就可以了。

2. 数据处理

最难的是数据源，因为不同数据集的字段都不一样，以及员工的自然语言的术语和数据集的字段名也不一样。如果直接把海量原始数据给 LLM，肯定是跑不出来靠谱的数。有两个关键方法

1）统一不同数据集的字段：不是直接在包含大量连接的复杂数据库上运行查询，而是做了一个精心策划的、单一表格的数据集市 (curated, single-table data marts) ，作用是为 Finch 提供一个高速、高清晰度、预先整理好的数据源。数据治理一直是难题，是 DS 的泪，一般人都不敢主动碰。我不确定 uber 是否真的解决了这个问题。

2）统一自然语言和字段名的映射：通过OpenSearch 来存储元数据。这些元数据包含了字段（列名）及其值对应的自然语言别名。这个持续维护也是比较难的。

3. 效果测评：

比较标准化，其实就是把环节拆分，分别用有标准答案的 case 来测评，最后端到端再验证。

1）路由准确性：当用户提出问题时，主 agent需判定应由哪个子agent处理请求。

2）子 agent 准确度：建一组常见用例，有正确可信的标准答案。通过将agent输出与预期答案比对，能及时发现准确率下降的情况。

3）端到端验证：通过模拟真实场景的查询来确保从输入到输出的完整流程正常运行。这有助于发现组件单独测试时可能遗漏的系统性问题