Claude Fable 5.1 在同一批故障上做根因分析（RCA），通过 Prometheus、Loki、Tempo 三个接口查数据，答对 27/28 次，估算花了 72 美元；通过 GreptimeDB 一个接口查同一份数据，答对 26/28 次，花了 37 美元。正确数几乎没变，读进去的 token 少了一半。

这是我们做 Agent RCA Bench 时看到的一组数字。做 LLM Agent 的 RCA，模型和 prompt 通常最受关注，我们想测的是另一个变量：模型和 prompt 不动，只换查询接口，Agent 的调查会有什么变化。我们原本的判断是，统一的数据模型和查询语言会带来帮助，只是缺少数据来说明。评测比较三组接口：Prometheus、Loki、Tempo 的原生接口，GreptimeDB 的 SQL 和 PromQL，以及在 GreptimeDB 上增加表语义和实体关系的语义层。

六个模型、每组 168 次端到端调查，先说结果：

• Raw（GreptimeDB 查询接口）诊断正确 130 次，Split（三支柱接口）105 次，错误诊断少了 40%；Raw 的累计输入 token 少约 48%，估算运行成本低约 45%。
• 六个模型的输入总量全部下降，五个模型的诊断正确数上升。
• 增加语义层后，找表、找依赖的专项评测返回的数据更少；服务组件与依赖边故障的正确诊断从 106 次增加到 112 次，六个模型中四个上升，节点故障上则从 24 次降到 12 次。端到端效率指标未通过统计检验。

评测使用 OpenRCA、OpenRCA2 和 RCA-100 的公开数据，以及开源功能。代码、协议和结果工件全部公开，六模型完整报告可以查看逐模型结果和调查记录。

三组接口，怎么比较

组别	Agent 使用的接口
Split	通过工具封装调用 Prometheus、Loki、Tempo 的原生查询 API
Raw	通过只读 SQL 和 PromQL 查询 GreptimeDB 中的 metric、log、trace 表
Graph	在 Raw 上增加表语义检索和 Semantic Graph 查询工具

每个配对使用相同的模型配置、故障、源遥测数据和工具调用预算。系统 prompt 中的调查方法与诊断输出契约完全一致，接口说明随工具变化。Raw 与 Split 比较的是完整接口组合，存储、查询语言和工具设计同时变化。发布前的重跑及执行差异在文末说明。

端到端评测有 14 个故障：10 个来自 OpenRCA2，包括服务重启、调用路径延迟、CPU 饱和和内存压力；4 个来自 RCA-100，涉及节点 CPU、内存、磁盘 I/O 和主机不可用。六个模型在每种接口上各跑两次，共 504 次。

另有 192 次专项评测，分别测试找到承载故障证据的表，以及从已知异常信号找到正确的直接依赖。

判分不使用 LLM judge。正确数覆盖全部运行；效率检验只纳入诊断正确、有成功且未截断的查询引用、没有运行器错误且未耗尽预算的配对。同一故障的重复差值先取中位数，再做跨故障统计。

同一个模型，调查成本能差多少

开头 Fable 的数字来自这里：Split 下答对 27/28 次，Raw 下 26/28 次；累计输入约 3,090 万对 1,583 万 token，估算运行成本 72.37 对 36.86 美元。

其他模型的差别还体现在正确数上：GPT 从 13 次增加到 22 次，DeepSeek 从 13 次增加到 18 次。

模型	Split 正确数，满分 28	Raw 正确数，满分 28	Raw 输入降幅
GPT-5.6-Sol	13	22	53.00%
DeepSeek V4 Pro	13	18	21.97%
Claude Fable 5.1	27	26	48.78%
GLM-5.3	10	14	27.07%
Gemini 3.8 Flash	22	25	63.42%
Qwen3.8-Max	20	25	24.40%

这些是全部运行的描述性总量，包括答错的调查。按预先指定的效率检验，Fable、Gemini 和 Qwen 的输入减少通过了 Holm 校正。最初四模型和后续两模型分别冻结了检验范围，沿用各自的 8 端点和 4 端点校正，没有合并成 12 端点统一校正。

工具调用次数从 Split 的 6,576 次降到 Raw 的 6,129 次，减少约 6.8%，六个模型中五个用更少的调用得到了正确诊断；累计输入则减少约 48%。没有模型的调用次数端点通过校正。

六模型每组 168 次调查的估算成本，Split 为 183.95–187.39 美元，Raw 为 98.37–100.50 美元。平均每次调查，分别约 1.09–1.12 美元和 0.59–0.60 美元。区间来自 Gemini 部分缓存用量明细缺失，计价和汇率见完整报告，只计模型调用费用。

SQL 在调查中做了什么

一体化存储支持跨信号 JOIN，这批轨迹里它很少出现。Raw 和 Graph 共 336 次调查，有 192 次成功的 SQL JOIN，涉及 trace 表内的 span 关联和 metric 表之间的关联，跨信号 JOIN 只有 3 次。

模型会把重启次数与就绪状态、内存用量与限额按时间和实体关联，让数据库返回可比较的多列结果，也会通过 trace 自连接比较同一次请求的客户端与服务端耗时。

这些工作如果没有在查询中完成，模型就需要从返回内容中匹配记录、记住数值再比较。大段结果还可能随历史消息进入后续请求，继续累积输入 token。后面的 case 007 可以看到具体差别。

模型确实主要选择了 SQL：GreptimeDB 两组只有 22 次调查成功使用原生 PromQL，Split 则有 160 次。PromQL、LogQL 支持聚合，本次工具也提供了 Tempo 的 TraceQL metrics 接口。各类查询对输入差距贡献多少，我们还没有量化。

语义层：检索步骤更省，端到端收益不一致

Graph 增加了两类工具：search_table_semantics 按遥测概念查表，query_semantic_graph 查询实体、源数据支持的关系及窗口统计，另附一份语义覆盖范围快照。168 次 Graph 调查都成功调用过后者，共 369 次。接口介绍见语义层概念文档。

专项评测中，找表任务的 35 个合格模型—故障结果全部减少了返回行数；依赖检索任务的 12 个合格结果中，11 个同时减少了返回行数和调用次数。

端到端正确数却是 Graph 124 次、Raw 130 次，效率端点没有一个通过校正。GLM 的正确数从 14 次增加到 16 次；DeepSeek 保持 18 次，在 10 个合格故障中有 8 个调用更少、7 个返回行数更少。GPT 和 Fable 没有一致收益。语义查询也有输入开销，Fable 在找表任务上的输入差值中位数增加了 7,129 token。

按故障类型拆分，还有另一组差异：

故障组	Raw 正确数	Graph 正确数
服务组件与依赖边故障	106/120	112/120
基础设施节点故障	24/48	12/48

这个拆分是在测量后做的，两组分别来自 OpenRCA2 和 RCA-100，故障层级与数据集重合，这里只能描述现象。节点故障的图里有部署关系：核对四个节点故障的 96 条 Raw/Graph 轨迹后，我们确认，48 次 Graph 调查中有 39 次拿到了 runs_on 和 part_of。下面的节点案例会继续看模型如何使用这些信息。

同一个故障，模型怎么查

我们挑了两个故障，检查查询、返回结果和最终诊断，也核对了重复运行。这是事后观察，用来解释具体调查过程。

accounting 的错误日志，还是 shipping 的慢调用

case 007 来自 OpenTelemetry Demo：shipping 调用 quote，accounting 是另一个服务。对照源数据的注入记录，这次是在 shipping 到 quote 的方向上注入了网络延迟，类型为 NetworkDelay。Agent 看不到这份记录。

GPT 使用 Split 时，从全局 ERROR 日志开始，取回 accounting 的 8 条 Order parsing failed:，随后继续查它的 trace、PostgreSQL span 和解析失败次数，最终归因到 accounting。这些错误在告警前就已存在，没有解释 shipping 到 quote 的延迟。

Fable 同样使用 Split，先统计错误和耗时，再按操作名和 span 角色检查 shipping，分别取回一条慢请求和一条告警前的请求：

请求	shipping 客户端 span	quote 对应服务端 span
告警前	约 1.51 ms	约 0.29 ms
慢请求	约 1,692 ms	约 0.30 ms

客户端多等了一秒多，服务端处理耗时却基本没变。Fable 随后检查两边的 CPU、内存、重启和日志，定位到 shipping → quote 的调用路径延迟。它用了 24 次调用，GPT 用了 32 次。第二次运行，Fable 仍答对，GPT 仍归因到 accounting，不过换成了内存泄漏。

换成 Raw，同一个 GPT 的调查方向变了。查看表结构后，它先按服务、操作和 span 角色统计耗时，再比较告警前后的变化，随后查询 shipping 和 quote 的具体请求。

第二次 Raw 调查中，GPT 用 SQL 自连接，按 trace ID 和父子关系配对两端 span，再按正常、异常时段聚合。查询返回两行，分别列出两个时段的客户端和服务端耗时，模型直接比较结果。它在 Raw 下两次都答对，分别用了 22 和 17 次调用；Fable 也两次答对，调用次数从 Split 的 24、28 次降到 20、19 次。

GPT 第一次 Raw 调查没有用 JOIN，也答对了。JOIN 在这里的作用是让比较在查询里完成，正确率的变化还有别的因素。

查到了节点 CPU，最后还是判成服务故障

case 011 是节点 CPU 饱和。先看 Raw：Fable 比较服务和操作在两个时段的耗时，查询部署位置，用 trace 自连接比较客户端与服务端，再按节点检查资源指标。异常节点的 CPU 从约 6% 升到接近 100%。它继续检查涉及该节点的调用和节点状态，30 次调用后正确归因到节点 CPU。

Gemini 第一次 Raw 调查也查到了这个节点。第 28 次调用按 CPU 最大值列出节点，第 29 次取回两个候选节点的完整 CPU 时间序列，没有截断。但它随后继续查 recommendation 的日志、trace 和慢调用，最终判成 recommendation 服务延迟，47 次调用后仍答错。第二次同样用了 47 次调用，却答对了；Fable 两次都答对。

Gemini 用 Split 反而两次都答对，分别用了 43 和 44 次调用。第一次全节点 CPU 查询被截断后，它单独取回故障节点的时间序列，再检查该节点的 Pod 和 trace，最后定位到节点 CPU 饱和。

Fable 加上语义层后，也出现了不同结果：两次 Graph 调查都判成 checkout 服务延迟。第二次的第 21 次查询已经返回故障节点的 CPU 变化。最终答案提到了这个节点，但认为 checkout 慢调用出现得更早，而且 checkout 位于另一个 CPU 正常的节点，所以排除了节点 CPU 故障。

两个案例让我们开始关注工具对调查方向的影响。GPT 用 Split 时，两次都追查 accounting 的错误；换成 Raw，两次都转向 shipping 和 quote 的耗时比较。Fable 用 Raw 找到了故障节点，加上语义层后，却两次都围绕 checkout 的延迟展开解释。

工具返回什么，可能影响模型接下来关注什么。一个方向被选中后，后续查询不断补充相关信息，模型也可能越来越倾向于沿着它解释新证据。节点 CPU 异常虽然已经查到，最后仍被排除了。

借用那篇论文的标题，Attention Is All You Need——我们想进一步测试，查询接口是否也在分配模型的“调查注意力”。让某类信息更容易获得，会不会同时让模型在某类解释上停留太久？

查询和诊断可在四模型轨迹工件和两模型轨迹工件中，按 case 007、011、模型和 repetition 查找。

对 Agent RCA 的一些想法

做 Agent 时，我们经常把工具调用成功、返回结果完整，当作一次正常执行。但这次不少错误调查里，这两件事都做到了。模型甚至查到了故障节点，最后还是选了另一个答案。只检查工具是否调用成功，发现不了这种问题。

我更想检查的是：每次工具返回之后，Agent 为什么选择了下一条查询？ GPT 看到 accounting 的错误，就继续查 accounting；Fable 选中 checkout 后，又用 checkout 的时间和部署位置去排除节点故障。后续查询有依据，但最初选中的方向未必对应当前告警。如果评测只看单次工具调用和最终答案，中间这一段很容易被漏掉。

这也会改变我们设计工具的方式。一个接口返回“哪些服务最慢”，另一个返回“同一操作在故障前后变了多少”，即使数据相同，模型接下来要做的判断也不同。设计返回结果时，除了字段是否齐全、token 是否足够少，还应该问：模型读完之后，最容易接着查什么？这个工具会不会反复把它带向同一类解释？

我会先在评测里加一个检查：把答错的运行找出来，看关键证据有没有返回过。没返回，就检查工具和查询；已经返回，就继续看它在哪一步被忽略或排除。对应的改动也应该分开验证。否则，我们可能给一个已经查到答案、却解释错了的 Agent，加上更多工具和更长上下文，然后为同一个错误付更多钱。

测试修正与结果限制

首批测试只有四个模型，Qwen 和 Gemini 是后续单独冻结协议的扩展批次。发布前复盘发现，Tempo 的保留设置会让历史 trace 在测试期间过期，Split 封装还在每条记录中重复返回标签名，额外增加了输入。我们修正保留设置，将三个 Split 查询工具的重复字段名移到表头，保留样本数和截断规则，重跑了全部 168 次 Split 调查。本文使用重跑后的结果。

为控制成本，Raw/Graph 没有重跑。少量 PromQL 查询仍有重复标签名开销，估计分别占输入的 0.71% 和 0.21%，使 GreptimeDB 显得更费 token。固定查询和轨迹，扣除后 Split 与 Raw 的输入差距扩大约 0.8%，这是对输入编码的离线估算。两批运行时间不同，各项修正和时间差的影响混在一起；工具说明、限速和临时连接失败重试记录见完整报告。

端到端共有 14 个故障，资格筛选后每项效率检验有 2–14 个。模型排名也只描述各自冻结配置在这批任务中的表现。

评测由 Greptime 赞助和维护。仓库提供从公开工件复现 JSON 和 HTML 的命令，无需调用模型或启动 GreptimeDB，生成结果可以与发布结果逐字节比对。