数字可以很近，分析合同仍然失败：Thumbtack 用轨迹评测企业分析智能体

数字可以很近，分析合同仍然失败：Thumbtack 用轨迹评测企业分析智能体

Teja Venkat Kolli（通信 tkolli@thumbtack.com）、Sang Su Lee、Xueying Yan、Jessie Chen、Chi Cheng、Kartik Ravisankar、Shishir Dash、Vijay Anand Raghavan。单位均为 Thumbtack，San Francisco，CA，USA。

KDD Workshop on Evaluation and Trustworthiness of Agentic AI，2026 年 8 月，济州。预印本 arXiv:2609.09182v1，2026-08-28。

摘要

企业分析智能体（analytics agent，用工具查企业数据、再写成自然语言答案的系统）不只是 text-to-SQL（把一句自然语言写成数据库查询）。它们要理解业务意图、选定指标定义、选择数据源、执行工具、检查结果，并写出答案。这些答案可能影响运营、财务或高管决定。只给最终答案打分，会藏起它们在哪里失败。一个看起来合理的答案，可能用了错误的权威来源（source of truth，公司认定应以此为准的表），跳过了规定的拆解，在没有证据时声称因果关系，或在重复运行里改变对表的解释。

本文给出一套分析智能体的端到端评测方法。它从三类行为打分：语义理解、执行质量、可靠性。打分使用带有人工标准答案（golden answer，领域专家写明“应当怎样分析”的合同，而不只是一个最终数字）的问题库、重复运行，以及运行轨迹（trace，一次运行留下的工具调用、查询、结果和错误记录）。每次运行先做有效性检查，再得到分层的、把弃答当作正式结论的分数。这些分数进入一个决策框架，而不是一道发布闸门。

作者把这套方法用在一家大型在线市场上、受控的内部分析智能体上。案例使用 50 个分析问题、两种匿名模型配置，每种配置随机重复 3 次，共 300 条轨迹。能力更高的配置把早期拒绝从 73% 降到 0%，把使用真实数据的回答从 21% 升到 73%。但它也在 16% 的运行上耗尽工具轮次预算，在 77% 的轨迹上超出表结构探索预算，并在 50 个问题中的 41 个上改变了对表的解释。在带有结构化标准答案的金融题上，源表使用和升级行为有改善，但规范拆解在两种配置上都弱。这些结果说明：信任分析智能体，需要端到端、以轨迹为据的评测，而不是只看 SQL 是否正确，或最终答案好不好。

1 引言

分析智能体正在成为企业数据仓库的自然语言接口。用户可能问收入为什么变了，也可能问某个日指标是否异常，或什么在推动预测缺口。要回答，智能体必须理解业务问题，并把它映射到正确的指标定义、权威来源、查询和最终回复。

这是一条分析工作流，不是一次生成。最终答案可以看起来合理，却因为很多原因是错的。智能体可能选了非权威表，或用了错误的日期窗口。它可能漏掉一条业务规则过滤，跳过规定的拆解，或叙述没有依据的因果主张。反过来，一个数字接近的答案，也可能没有满足领域专家要求的分析合同。

因此评测问题比 SQL 准确率更宽。SQL 正确是必要的，但不够。可信的分析智能体评测必须检查答案是怎么产生的，必须检查智能体是否遵循了预期方法，还必须测试重复运行是否给出稳定的解释。

作者提出一套面向决策级分析智能体的端到端评测方法。他们把“决策级”用得很窄：评测应表明，一个答案是否可靠到可以用来告知一项业务决定；也应表明，智能体是否应当弃答、升级（escalation，证据不足时不自己下结论，而交给人或更严格的流程），或把答案送去人工复核。这套方法被定位为智能体治理的测量基础，而不是治理本身的替代。

贡献有三项：

1. 定义一套工作流层面的分析智能体评测方法。它覆盖解释、来源选择、SQL 与工具执行、分析方法、依据、信心和可重复性。
2. 给出一份针对分析场景的失败分类。它把一般的轨迹失败接到具体的数据和决策风险上。
3. 在 300 条轨迹的案例上做实证（第 5 节）。它表明，能力更高的配置可以回答更多问题，同时仍然在来源选择、拆解、依据、效率和跨次一致性上失败。

2 分析智能体评测为什么不同

标准的 text-to-SQL 评测问的是：对一个自然语言问题，查询是否返回预期答案。企业分析智能体面对的任务更大。它们必须处理含糊的业务语言、本地指标定义、权威来源的层级、表的粒度（grain，一行数据代表的业务单位，例如一天、一笔订单或一个项目）和时间窗口。它们还必须考虑用户想做的那个决定。

方法从四个人工复核维度出发：

• 问题解释。智能体是否理解了指标、范围、时间区间、细分和决策情境？
• SQL 与数据来源。是否用了正确的表、连接、过滤、粒度和计算？
• 洞察推理。是否解释了结果、拆解了驱动因素，并避免了没有依据的因果主张？
• 输出质量。答案是否完整、可读、有限定，并且对用户有用？

这四个维度覆盖三类信号：语义理解、执行质量、可靠性。问题解释加上 SQL 与数据来源，构成语义理解。洞察推理加上输出质量，构成执行质量。四个维度上的跨次可重复性，构成可靠性。

这些维度引出三项评测要求，来自两个互补视角。分析视角问：智能体是否选对了指标、来源、粒度和解释。过程视角问：它是否正确使用工具、从错误中恢复、避免循环，并在证据弱时升级。把两个视角合在一起，评测才不会藏起领域错误，也不会藏起轨迹错误。

第一，评测必须看见轨迹。使用工具时的失败，常常在最终答案里看不见。智能体可能用错参数调用了正确的工具，跳过必要的前置查询，在表结构发现上打转，没能恢复，或在证据弱时仍不升级。

第二，评测必须针对分析场景。一般的轨迹检查不知道一张表是不是规范表，也不知道一个指标有没有本地定义或必选过滤。分析智能体评测必须把一般的工具失败映射成领域失败。例子包括：来源错误、粒度错误、时间窗口错误、缺少拆解、没有依据的建议。

第三，评测必须测量可重复性。一次成功不能建立可靠性。如果同一个问题在重复运行里给出不同的表、数字或结论，智能体可能制造一种虚假的稳定感。对预测、异常解释、实验结果解读和高管报告这类高风险分析问题，可重复性尤其重要。

3 端到端评测方法

方法分三步。第一步，建一个有代表性的问题库，配上人工标准答案，并在隔离、随机、重复的试验里运行智能体，同时采集运行轨迹。第二步，每次运行先做有效性检查，再做分层打分：把主信号和诊断信号分开，并把弃答当作一等结论。第三步，分数进入一个对照领域专家复核校准过的决策框架。图 1 是流水线；后面各小节说明每一步。

图 1：分析智能体的端到端评测流水线。原文这一图是文字流程，没有独立图片文件。顺序是：有代表性的问题库，向下到人工标准答案和量规，向下到隔离、随机、重复的运行，向下到运行轨迹（工具、SQL、结果、错误、最终答案），再做运行有效性检查，然后到主信号，再到诊断信号，最后到决策框架、报告、失败分类和一致性分析。

3.1 有代表性的问题库

评测从一个取自真实分析工作流的问题库开始。问题应按业务领域、问题类型、来源层级、含糊程度和决策风险打标签。这样，一个总分才不会把探索性的趋势题，和需要更严可靠性的高精度金融题或预测题混在一起。

3.2 人工标准答案

标准答案规定预期的分析合同。它可以包括必用来源、禁用来源、日期窗口和过滤。也可以包括拆解步骤、数值区间、应出现的用语，以及答案不得做出的主张。标准答案不只是一个最终答案。它是领域专家所期望的工作流的一份简短说明。在案例里，每份标准答案由负责该业务领域的专家起草，再由第二位分析师独立复核并批准，并用明确的“草稿 / 已批准”状态跟踪。作者没有计算正式的评分者间信度（第 9 节）。

标准答案也把语义知识和评测接起来。以后的语义上下文层，可以把同一份知识放进运行时指导。指导可以包括指标定义、来源层级、规范查询、业务规则和拆解模板。这些字段定义了运行时语义指导需要覆盖什么。

3.3 隔离的重复运行

每个问题在隔离的会话里运行。运行器在题目之间重置状态，用固定种子打乱题目顺序，并提示智能体把每道题当作独立问题。重复使随机行为变得可观察。评测不问某一次抽到的答案好不好，而问智能体是否反复选择同一种解释。

3.4 采集运行轨迹

每一次运行，评测记录原始问题、配置元数据，以及工具调用、查询文本、查询输出、错误、重试、延迟、工具轮次数和最终答案。这些轨迹是核心证据。结果如果错了，轨迹可以把失败定位到解释、来源选择、SQL 构造、工具失败、结果解释或最终答案合成。

3.5 打分前先检查运行是否有效

在给答案质量打分之前，评测先检查这次运行是否有效到可以解释。案例使用的有效性信号包括硬错误和早期拒绝模式，也检查用户能看见的认证提及、是否出现真实数据，以及工具输出里的基础设施认证失败。这一步避免把坏掉的执行环境误当成智能体行为。

3.6 主信号、诊断信号，以及把弃答算进去的打分

方法把主信号和诊断信号分开。主信号评估核心分析合同，用于复核、比较或测量干预。诊断信号解释一项主结果为什么变了。这个区分重要，因为分析评测很容易堆出很多评分器；复核的人不该把每一项诊断都当成发布闸门。

每个评分器返回四种结论之一：是、部分、否，或未知。未知是一等的弃答，不是失败。汇总应把覆盖率与通过率分开报告，这样缺少标准答案、超出范围的问题，以及轨迹里没有的字段，才会被看见。具体做法是：未知不进入分母，并单独报成覆盖率；在已判定的运行里，是记 1.0，部分记 0.5，否记 0.0，报告的通过率是这些分数的均值。从不给出“部分”的二元评分器，就变成：是 /（是 + 否）。

3.7 从分数到决定

主分数和诊断分数支持工程和复核决定。它们不定义一套通用的发布政策。表 1 说明本文如何解释这些信号。运行有效性失败，意味着质量分数不可信。主信号用来比较版本或干预。诊断信号用来选定下一步要修什么。跨次检查用来测试解释是否稳定。在自动评判器或阈值变成部署闸门之前，必须先做人工校准。

表 1：解释评测信号的决策框架。

因此作者称之为决策框架，而不是一套已经验证的发布政策。方法让失败看得见、可行动。精确阈值应在成为阻断式部署标准之前，用领域专家复核来校准。

3.8 人工校准

自动打分在驱动阻断或批准决定之前，应对照人工复核校准。领域专家可以用四维量规给一批带轨迹的运行打分，再把自动结论和专家判断比较。在案例里，确定性和以轨迹为据的信号构成主要证据；校准过的大语言模型评判器仍是后续方向。

4 针对分析场景的失败分类

表 2 汇总用来解释结果、并排列干预优先级的分类。分类有意按工作流组织：每种失败模式都指向一种可能的修复，修的是上下文、工具、流程强制或复核政策。

分类把第 2 节的两个视角都落到操作上。问题解释、语义与来源选择、分析方法、洞察推理，抓住的是分析场景特有的正确性。SQL 与工具执行、信心与依据、可重复性，抓住的是使用工具的智能体在过程上的失败。

表 2：分析智能体失败分类。

分类也说明为什么只有语义上下文不够。指导告诉模型好的行为长什么样。流程强制阻止模型跳过必做步骤。轨迹评测核实这些步骤是否发生。分析智能体三者都需要。

5 案例

作者评测一家大型在线市场上、受控的内部分析智能体。它用表结构查询和查询执行工具，在企业仓库上回答自然语言业务问题，再合成自然语言答案。为匿名，两种模型配置称为 Fast 和 Reasoning。

案例使用 50 题的问题库，在五个内部业务领域上平衡，每个领域 10 题。每题对两种模型配置各跑 3 次，共 300 条轨迹。两种配置使用同一套工具、同一套提示骨架和同一个运行器。有意做出的差别是模型配置。

金融是唯一有完整结构化标准答案的领域。案例用这 10 道金融题做结构化标准答案记分卡。两种配置都按同样的 3 次随机重复打分，每种配置 30 条金融轨迹。另外四个领域没有同等的标准答案覆盖。因此金融记分卡被当作诊断证据，而不是一套完整基准。

6 结果

结果不被呈现成模型基准。它们是证据：端到端评测能露出只给最终答案打分时藏住的失败。下面五小节是同一批 300 条轨迹的五种看法：运行有效性、金融记分卡、合同违反、只在轨迹里看得见的风险，以及跨次一致性。

6.1 运行有效性与回答行为

表 3：每种配置 150 条轨迹上的顶层运行指标。

如表 3，Reasoning 回答得频繁得多。它把早期拒绝从 73% 降到 0%，把真实数据回答从 21% 升到 73%。但它也慢得多，并在 16% 的运行上碰到工具轮次预算上限。主要失败从提前放弃，变成过度探索和解释不稳定。

6.2 金融标准答案

表 4：选出的金融评分器差值。通过率是已判定运行上结论得分的均值，未知被排除并另报为覆盖率（第 3.6 节）；各行的样本因评分器是否适用而不同。“不应拒绝”抓住的是证据已经够、智能体仍然拒绝的情形；“拆解方法”看答案是否使用了预期的分析拆解。

表 4 报告选出的金融评分器差值。Reasoning 改善了若干主信号：它更常尝试回答，升级更得当，也更常找到必用的源表。但必用表的使用只到 50%，拆解方法在两种配置上都弱。更强的模型能力提高了愿意回答和探索的程度，但没有可靠地产生预期的分析方法。

6.3 数字对了，分析合同错了

一道金融题要求做第一季度收入的同比比较。在一次有代表性的 Reasoning 运行里，智能体选了一张看起来合理的收入表。标题收入数字落在标准答案大约 0.3% 以内。月度趋势也很接近。

但是答案在分析合同的重要部分失败了。它没有使用规定的权威来源表，没有计算所要求的“项目数以及每项目收入”拆解，也漏掉了预期的驱动因素检查。只看最终答案的评测器，可能因为标题数字接近而给它加分。端到端评测则把它标成不完整，因为它跳过了解释收入为什么变动所要求的方法。这种分歧并不少见。在 30 条 Reasoning 金融轨迹里，最终答案评分器在每一条上都看到一份完成的、看起来合理的答案；以轨迹为据的打分则显示，30 条里有 15 条（50%）用了非规范的权威来源表，30 条里有 27 条（90%）跳过了拆解。因此只看最终答案，仍会把 Reasoning 排在 Fast 之上，但会把这次升级报成一场没有保留的胜利，并藏起这些合同失败。

6.4 只在轨迹里看得见的风险

只看轨迹的诊断，露出那些不需要完整标准答案也能看见的风险。表 5 报告每种配置 150 条轨迹上的五项此类信号。Reasoning 比 Fast 产生更多不可信的数值主张，以及更多硬矛盾。Fast 乍看更安全，但它较低的数值主张率，部分是因为用数字回答的问题更少。沉默不是可靠性。

表 5：每种配置 150 条轨迹上、只看轨迹的诊断信号。计数的分母是 150 条轨迹；百分比也以 150 为底。

6.5 跨次一致性

表 6：50 个问题上的跨次确定性。

表 6 是跨次确定性的分解。最强的可靠性信号是解释不稳定。Reasoning 尝试了每一道题。但在 50 题里的 41 题上，它在重复运行之间改变了所用的表集合或查询解释。这是决策级的可靠性风险。用户今天可能收到一份连贯的答案，明天收到另一份同样连贯的答案，而答案本身并不显示底层的权威来源已经变了。

7 从评测到干预

案例支持三条把方法接回干预策略的教训。每条教训指向一类具体干预。第 7.1 节写出：在任何答案可以被信任用于业务决定之前，这些干预所需要的治理原语。

模型升级不够。Reasoning 回答了更多问题，也产生了更多有依据的输出。它仍然有权威来源错误、拆解弱、表结构探索超限、自相矛盾和解释漂移。模型能力改变了失败的表面，并没有取消对流程控制的需要。

分析智能体需要语义上下文，加上强制执行。观察到的失败指向这些干预：指标词典、来源层级、规范表路由、领域拆解模板、行数检查，以及查询后的校验。但指导必须和强制配对。智能体不能只是能访问定义或规范模式。流程必须让查询、校验和升级变得可观察、可测试。

评测应当指导干预的测量。语义上下文层这类宽干预，应在可能时拆开。更小的测试可以分别针对表元数据、指标定义、来源层级、查询模式和流程骨架。拆不开时，分层打分仍然能显示什么变了。一次语义干预可能改善来源选择，却没有改善答案完整性。这仍然可行动。

7.1 业务决定所需的治理

在本文里，治理指的是：在分析智能体的答案可以被信任用于业务决定之前，评测所需要的那些原语。方法提供五项，每一项都落在第 3 节的一个机制上：

1. 可追溯：靠运行轨迹采集。
2. 弃答与升级：靠把弃答算进去的打分。
3. 主信号与诊断信号的角色：靠分层打分。
4. 运行稳定性：靠隔离的重复运行和跨次一致性分析。
5. 版本比较：靠以轨迹为据的合同。

这些原语使治理成为可能；它们本身不是一套已经部署的治理计划。

8 相关工作

智能体评测越来越承认最终答案不够。ReAct 表明把推理和行动交错起来的价值，使轨迹成为智能体行为的中心（Yao 等，2023）。GAIA 和 tau-bench 评测的是工具使用和多步智能体可靠性，而不只是简单问答（Mialon 等，2023；Yao 等，2024）。tau-bench 尤其相关，因为它在使用工具的领域里评测重复的任务成功和跨次一致性。

Spider、BIRD 和 Spider 2.0 这类 text-to-SQL 工作，评测的是从自然语言到数据库查询的能力（Yu 等，2018；Li 等，2023；Spider 2.0 团队，2024）。这些基准是必要的，但企业分析智能体在 SQL 执行之外还有要求。智能体必须在相互竞争的权威来源表之间做选择，遵守本地业务定义，并按领域惯例解释结果。

以大语言模型为评判器的工作，包括 MT-Bench 和成对竞技场基准，研究模型评判何时与人类一致（Zheng 等，2023）。自我改进方法表明，大语言模型可以批评并改进自己的输出（Madaan 等，2023）。本文的做法与基于评判器的打分兼容，但所报告的证据主要依赖确定性和以轨迹为据的信号。大语言模型评判器最有用的地方，是在对照领域专家分数校准之后，去评细微的解释和洞察质量。

企业分析评测不同于公开基准。受治理的仓库、本地指标定义和权威来源层级，使分析智能体的正确性变成领域特定的，公开的 text-to-SQL 或轨迹基准覆盖不了。本文的方法加上先前工作没有覆盖的三项。第一，工作流层面的评测把轨迹检查接到分析合同上。第二，针对分析场景的失败分类，把一般的工具失败映射到领域修复目标。第三，300 条轨迹的案例演示了这套方法，并露出最终答案评测藏住的失败模式。

9 限制与以后的工作

这项研究有几项限制。第一，数据和智能体都属于一家公司内部。第二，案例比较两种模型配置，但不是完整的模型基准。第三，案例没有评测一个已经部署的语义层。证据说明哪里需要语义上下文和规范路由，但没有表明它们已经改善了这个智能体。

第四，跨次一致性由每题 3 次重复估计。三个样本能给出界限，但不能精确估计次与次之间的稳定性，因此解释不稳定的计数应读成下界，而不是精确比率。第五，延迟和执行效率的数字专属于这个数据仓库和执行环境。它们反映的是这次部署，不是模型的固有性质，不应被读成可搬移的模型基准。第六，金融标准答案在内部写成，没有报告评分者间信度；两种模型配置被匿名成 Fast 和 Reasoning，这限制了读者能把观察到的差值归到哪一个模型家族。写一份结构化标准答案并复核，大约要熟悉该领域的数据科学家每题数小时，时间主要花在把分析合同写下来，以及第二位分析师的复核。用校准过的自动化去降低其中较机械的检查的成本，是以后的工作。

以后的工作有三个优先项。第一，对照领域专家复核校准决策框架，使主信号的阈值成为可信的闸门。第二，给语义上下文层（指标词典、来源层级、规范路由）装上测量，并用同一份以轨迹为据的合同测量每个部件。第三，把方法用到另一个领域的第二个分析智能体上，检验失败分类如何推广。

可复现性。方法、评分器和决策框架可以独立复现。实践者可以把它们用到自己的分析智能体、问题库和标准答案上。这个具体案例不能直接复现。问题库、智能体系统和数据仓库都属于一个组织内部，不能共享。可以带走的贡献是方法，不是这些具体比率。

10 结论

分析智能体需要在分析工作流的层面上被评测，而不只是最终答案。这套方法把问题库、人工标准答案、重复运行和运行轨迹合在一起。每次运行在分层的主信号与诊断信号打分之前，先通过有效性检查。它还加上把弃答算进去的打分、一个决策框架，以及跨次一致性分析。

案例说明这种端到端看法为什么重要。能力更高的配置回答了更多问题，也更常使用真实数据。它仍然产生权威来源错误、弱拆解、表结构探索超限、自相矛盾和解释漂移。这些正是最终答案评测藏起来的失败。以轨迹为据的端到端评测，给团队一块测量面，用来改进分析智能体，而不把“看起来合理”误当成可靠。

参考文献

按原文保留作者、题名和出处，不另增文献。

• Li 等，2023，Can LLM Already Serve as A Database Interface? A Big Bench for Large-Scale Database Grounded Text-to-SQLs，NeurIPS 36，42330–42357。
• Madaan 等，2023，Self-Refine: Iterative Refinement with Self-Feedback，NeurIPS 36，46534–46594。
• Mialon 等，2023，GAIA: A Benchmark for General AI Assistants，arXiv:2311.12983。
• Spider 2.0 团队，2024，Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows，arXiv:2411.07763。
• Yao 等，2024，tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains，arXiv:2406.12045。
• Yao 等，2023，ReAct: Synergizing Reasoning and Acting in Language Models，ICLR，arXiv:2210.03629。
• Yu 等，2018，Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task，EMNLP，3911–3921，doi:10.18653/v1/D18-1425。
• Zheng 等，2023，Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena，NeurIPS 36，46595–46623。

Teja Venkat Kolli，Sang Su Lee，Xueying Yan，Jessie Chen，Chi Cheng，Kartik Ravisankar，Shishir Dash，Vijay Anand Raghavan，Evaluating Enterprise Analytics Agents: An End-to-End, Trace-Backed Methodology，2026-08-28，https://arxiv.org/abs/2609.09182 ，CC BY 4.0。