Uber Finch：财务问答先解决口径和权限，再生成查询

财务人员问出一个短问题，背后可能藏着数据源、指标定义、地域、时间和币种等多重选择。Uber 的 Finch 不是让模型凭记忆回答数字，而是在 Slack 中把问题转为受控的数据查询。

其值得借鉴的地方，是先降低数据面的复杂度，再给模型补足企业语义，最后检验查询结果。自然语言只是入口，可靠性仍取决于这些入口之后的工程约束。Uber 官方工程文章

把多系统找数变成可追溯的请求

Uber 财务人员原来需要在 Presto、IBM Planning Analytics、Oracle EPM 和文档之间找数据；会写 SQL，也未必清楚当前指标应从哪个系统取。Finch 把请求留在已有协作环境中，监督代理负责选择适当的专业代理，专业代理调用数据工具。

这不是让一个 SQL 工具代替全部系统。官方集成图区分 SQL、MDX、JSON 等接口路径。SQL 面向关系查询，MDX 面向多维数据；同样一句业务问题，在不同系统中可能需要不同表达和口径。官方图示的工具列表也不能当成某次请求实际逐项执行的日志。

监督层的价值不只是“分发任务”。如果两个工具都能回答近似问题，却对应不同财务用途，路由错误仍可能得到一个能正常执行、看似可信的数字。因此路由需要单独评价，不能只看工具有没有报错。

数据集先收敛，模型才有可控的选择空间

Finch 使用经过整理的、领域专用的单表数据集，将常用指标集中起来，减少复杂关联。它没有把整个企业数据库的结构一股脑交给模型。

这项取舍把一部分难度前移给数据团队：指标整合和治理需要维护，但模型每次查询需要猜测的关联路径减少了。它尤其适用于高频、口径相对稳定的财务问题；不能由此推断任意跨库分析都已自动化。

另一层约束来自 OpenSearch 中的元数据。索引不仅有列名，还有列值的自然语言别名。以官方上下文图为例，GBs 指向 gross bookings，不能随意译成“收入”；US&C 需要落到美国与加拿大的区域表达。列名映射解决“取哪一个量”，列值映射解决“筛哪一部分”。

只给表结构和几行样本，往往覆盖不了企业缩写或历史命名。别名层把这些知识变成可查找的资产，也让错误定位有了对象：是没找到指标、选错候选，还是把业务地域翻译成了错误筛选值？这是语义问题，换一个更会写 SQL 的模型未必解决。

查询上下文里，字段和业务规则缺一不可

官方 Figure 2 把上下文取得拆为四项工具职责，而不是一次检索后就生成 SQL：

这些工具结果逐步进入 Agent Context，SQL Writer 据此继续取证、构造和解释查询。最后的交付包括问题与查询的映射、带注释的查询和完整结果链接。图没有公开完整 SQL、候选排序算法或所有规则，所以不应从两个候选反推一套已知选表公式。

这个细节影响最终答案：字段存在，不等于适用于当前问题；日期范围补错、币种规则遗漏，查询照样可能成功执行。表级说明应与字段一起到达生成环节，而不是留在用户另一个文档标签里。

从输入到输出，公开可确认的职责链是：Slack 接收问题；监督代理选择专业代理；专业代理检索字段、值别名和表级说明；构造查询；执行前验证用户权限；执行错误反馈给代理用于改写；返回结果、所执行查询的细节及可用的 Sheets 链接。

这条链并未公开完整系统提示词、查询工具的参数结构或鉴权令牌如何跨服务传递。不能把一种合理的接口设计画成 Uber 已实现的接口。

可横向查看，点击打开原尺寸 ↗

图分别依据官方 Figure 2 与 Figure 3 重构。它们是不同证据视图，不能连成同一条调用日志。

文章文字按 SQL 解释用户旅程，但 Figure 3 界面列出的真实工具包括 mdx_writer、cube_element_finder、mdx_dim_writer、execute_dim_mdx_query、execute_cube_mdx_query。它们分别指向多维查询构建、维度元素查找、维度查询和立方体查询的工作职责。公开界面显示了这组工具，不足以确定每次调用的参数、完整内容或严格顺序；不能把它们拼进 Figure 2 的 SQL 执行链。

状态消息、追问和导出，是查询产品的一部分

查询不总能立即完成。Finch 的 LangGraph 应用通过回调更新 Slack 状态，让用户知道正在发生工具调用。Slack 的建议问题、固定入口和分栏交互降低了找入口的成本；状态反馈则减少用户把后台执行误认成卡住的机会。

官方演示允许在上一轮基础上追问、修改比较期间，再把结果送到 Google Sheets。连续追问要求系统保留业务上下文：变了时间，不意味着前面指标和其他限定条件都该消失。不过官方没有公开其会话状态对象、条件覆盖优先级或结果版本协议。

这也是产品设计和安全设计相遇的地方。查询时有权限，并不自动证明导出后仍维持相同访问范围。Uber 文章公开了查询权限与导出能力，没有披露 Sheets 分享策略、导出时再次鉴权或失效机制。它们应成为迁移项目的核查项，而不能借此案例宣称已有完整答案。

错误改写有用，但“最终执行成功”不是正确答案

数据库报错可以提示语法或字段错误，代理据此重写。它无法独自发现“选错了能正常查询的数据源”或“时间与口径不符”。所以 Finch 的评价分层展开：

结果比较比逐字匹配 SQL 更贴近财务任务，但仍依赖标准查询可信、数据时间一致、比较规则合理。官方没有公布测试集大小、容差与具体分数，也没有给出足以独立复算的速度或成本结果。

文章还提到查询优化、可并行任务和高频指标预取。这些不能泛化成所有步骤并发：依赖表选择或权限判定的动作，仍有先后关系。具体并发控制和重试预算未公开。

人工验证按钮当时仍是计划

Uber 把“请求专家验证”列为未来方向：把问题与生成结果交给领域专家核对，再反馈用户。现有财务结果不代表逐份经过专家签署。

同样，未来更多意图和工具的架构图是扩展方向，不是当前覆盖清单。当前公开材料支持一个有明确边界的财务查数代理，尚不足以证明自动完成预测、预算和所有高风险决策。

迁移时，先验一个数字的来路

选择一项真实高频指标，沿一条已授权请求逐项核查：业务名命中什么表和列？地域、期间和币种如何确定？谁允许执行？追问改变了哪个条件？用户能否查看查询依据？导出后的访问范围由谁负责？

再用同一批问题分别检查路由、查询结果和整段对话。若最后只剩一个“回答正确率”，就会重新把口径错误、权限失败和语言表达混在一起。Finch 最有价值的经验，是让这些不同责任有可以分别检验的边界。