LLM 评测的下一步是一张二维矩阵

过去十几年，工程师调 bug 看的是 stack trace。stack trace 是”代码的执行路径”，每一帧是确定的、可重放的，错了往上翻几层就能定位。

最近两年，工程师开始调 agent。agent 没有 stack trace，它有一种新的东西，姑且叫 trajectory trace——”语义的执行路径”。这条路径每跑一次都可能不一样：第一次 LLM 决定先查数据库再调工具 A，第二次它决定先调工具 A 再查数据库，第三次它决定根本不查数据库。代码本身一行没改，行为却已经分叉了三次。

Arize 的 Dat Ngo 在最近一期 AI Engineer 大会上做了一个 16 分钟的演讲，把这件事说得很清楚：传统软件的 audit 靠代码，agent 的 audit 只能靠遥测。原视频在这里：LLM Observability, Evaluation, Experimentation Platform — Dat Ngo, Arize。

这是一篇产品演讲，但讲的不是产品，是这个赛道这两年长出来的一套新心智。我想把这套心智写下来，顺便对着我自己之前写的 Langfuse 那一篇做点补充。两家路线很不同，放在一起看更清楚。

代码不审计 agent，遥测才审计

演讲一开始 Dat 给了一个极小的例子，我觉得它比后面所有架构图都重要。

一个 agent 应该先调工具 A，再调工具 B，因为 B 的输入依赖 A 的输出。但 LLM 这次决定先调 B，再调 A。代码层面看，两个工具都被调用了，没有报错，返回值也都是合法的；如果你只看单元测试和接口契约，这个 trace 是”绿的”。但业务结果错了，因为 B 拿到的是空依赖、走的是默认分支。

代码静态检查永远抓不到这种问题，因为代码里压根没有”先 A 后 B”这个约束。它存在于 prompt 里、存在于工具说明里、存在于 LLM 那次推理的语义里。这个约束有没有被遵守，只有把整条调用链按时间序看一遍才知道。

这就是为什么 Arize 把所有产品都建在 OpenTelemetry 之上：trace 和 span 是 agent 时代唯一可靠的审计形式。一行 auto-instrumenter，把 agent 在每个 framework、每个 SDK 里发生的事情捞出来，变成可查询的 span 树。这件事 Langfuse 也这么做，方向是共识，没有什么取巧空间。

但 trace 只是”看得见”。看得见之后，麻烦才真正开始。

从单 span 到 session，一共有四层

agent 跑起来之后，你可以观察的对象不止一个。这是和传统服务最大的差别。

Arize 把可观测对象切成四层，由细到粗：

• span：单次工具调用，一个输入、一个输出。等同于传统的”一次 RPC”。
• multi-span：一组相关的调用，比如三个子 agent 之间互相传数据。
• trajectory：整条任务执行链，包含所有分支和循环。这层只有 agent 才有，传统服务里没有对应物。
• session：用户和 agent 的整段对话，可能跨多个 trajectory，是个状态机。

这四层切分的关键在于”要问什么问题”，不在于细节深浅。

span 层问的是：这次调用 input/output 是不是对的？multi-span 问的是：几个 agent 之间数据有没有传歪？trajectory 问的是：选的这条路径是不是合理的、各步顺序对不对、有没有死循环？session 问的是：用户从头到尾问的几个问题，到底有没有被回答清楚？

之前那个 B-before-A 的 bug，只有 trajectory 层抓得到。span 层每一次调用都合法，session 层用户可能只是回了一句”这个结果不太对”，既给不了你定位线索，也未必每次都说。中间这两层是 agent 时代独有的、最难抓也最有价值的诊断面。

我之前写 Langfuse 那篇文章时，重点放在它的数据模型：Session、Trace、Observation、Score 嵌套，Score 有 NUMERIC / CATEGORICAL / BOOLEAN / TEXT 四种类型。那是”评测产物长什么样”的视角。Arize 的四层切分则是”被评测对象在哪一层”的视角。这两个维度是正交的，组合在一起才是完整图景。

五类信号 × 四层 scope = 一张评测矩阵

这是整个演讲里我觉得最值钱的一段。

Dat 把评测信号分成五类：

1. LLM as judge：用一个 LLM 来给另一个 LLM 的输出打分。便宜、好扩展，问题是”判官自己也不准”，需要校准。
2. Human feedback：终端用户的反馈、运营同事的人工标注。最贵也最稀缺，但代表真实价值。
3. Golden dataset：人工精挑细选的标准答案集，作为校准其他评测方式的锚点。
4. Deterministic checks：纯逻辑判断，比如”输出是不是合法 JSON”、”必填字段在不在”。完全确定，几乎免费，但只能覆盖有限维度。
5. Business metrics：归到三件事，多赚钱、省钱、省时间。最终评测都要回到这里。

这五类之间有依赖关系：deterministic 是地板，LLM as judge 是扩展，golden dataset 用来校准 judge，human feedback 是最贵的真相源，business metric 是终点。一个成熟的 eval 体系不会只押一种，五种信号会同时存在、各负责一段。

把这五类信号叠在前面那四层 scope 上，就得到了一张矩阵：

矩阵里有些格子是空的，这是有意为之。并非所有格子都该填。Dat 在演讲里专门强调了一句：「能 eval 不代表应该 eval」。每加一个评测都有成本，要找的是「能让我判断系统是不是按预期运行」的最小集，而不是去堆覆盖率。

这一点和我之前写过的只增不改观测原则是同一个脉络。观测和评测都是边际成本很低、但堆多了会反噬的工具，节制比堆叠更难。

两种人要在同一个工作台上协作

视频里有一段我反复回放了两次，因为它讲的是产品决策，不是技术决策。

Dat 说，团队会自然分成两种人：技术型（AI engineer、developer），擅长把流程自动化、写测试、写代码；领域型（PM、subject matter expert），不太会写代码，但知道这个 AI 系统”该长什么样”才算对。前一类人不该去定义评测，因为他们不懂业务什么算”答得好”；后一类人不该自己手搓评测代码，因为效率太低。

Arize 给的答案是：同一套评测，UI 上能拖拽配置，CLI 上能 import 成代码，两条入口接同一个底层。这听起来像市场宣传话术，但背后是个挺硬的工程决策：评测的定义要存成一种中立的、跨表达层的结构（不是一段 prompt 字符串，也不是一段 Python，而是一个能从两边读写的东西），才能让两类人对同一个评测做修改。

Langfuse 现在偏开发者向，更像 SDK + dashboard。Arize 这步往”非技术人也能改”再走了一格，是不是真的落地我现在没法判断，但方向我相信。LLM 时代真正稀缺的是领域专家的判断，工具该围着他们的工作流转，不是反过来。

Phoenix 和 AX：开源单体 + 企业 AI 层

产品形态上 Arize 给了两个东西。

Phoenix 是开源的，MIT 协议，单容器部署，不需要 Kubernetes。我看了一下，定位非常清晰：让独立开发者和小团队能在本地跑起来，几分钟就能看到第一条 trace。这件事很关键。可观测工具的第一杀手锏永远是接入门槛，能不能在 5 分钟内看到第一条数据，决定了它会不会被试用。Phoenix 在这点上和 Langfuse 路线一样，都是”开源 + 单体优先”。

Arize AX 是企业版，里面藏着一个叫 Alex 的 AI 层。Alex 不是 chat 接口的皮，它真正能做的事情是：扫所有 trace，主动告诉你「这段 trajectory 延迟异常」「这里报错率突然上去了」「我建议你加一条评测，因为这类输入还没被覆盖」。然后通过 CLI 让 Claude Code 这种 coding agent 也能调用 Alex 的全部 primitive，把”建评测”这件事从 dashboard 里拿出来，放回开发者每天用的命令行环境。

Dat 在收尾时说了一句很狂但我觉得方向是对的话：「我们的目标是把你从 observability 流程里 automate 出去」。意思是，未来你不应该需要登进 dashboard 去判断系统健康，也不应该需要手动决定加哪条评测，这些都交给另一个 AI 去做，你只在它请求确认时介入。dashboard 退到兜底位置，平时根本不用打开它。

我会怎么用这套心智

下面是我自己的延伸，不是视频内容，单独标一下。

我手上几个东西，内部 agent 框架、运维 copilot、知识库摘录管道，都已经走到”能跑出结果，但不知道这个结果好不好”的阶段。这个阶段最容易做的事情是加 dashboard，最不容易做的是建评测。看完这场演讲，我打算回去做的事情大致有几件。

最优先的是把现有 trace 体系按这四层重新分一次类。我现在大部分埋点停在 span 层，trajectory 和 session 几乎是空的。trajectory 这层不补，B-before-A 这类问题永远只能靠用户投诉才发现。

然后是五类评测信号里我目前只用了 deterministic（schema 校验）和零散的 human（自己上手抽查）。要补的是 LLM as judge 和 golden dataset 这一对，judge 不准就用 golden 校准，这是个标准操作。business metric 那一层等业务跑稳一点再接，现在接太早会被误导。

最后一件，评测一定要做成”能被 AI 调用的 primitive”，不要做成 dashboard。我之前在 OpenClaw harness 那条线上写过类似的判断，当时的依据是 skill 准入治理：同一件事用 skill / CLI / dashboard 三种壳包出来，长期看 skill 一定赢。Arize 的 Alex 是另一个佐证：你做的所有能力，最后都会有一个 AI 想直接调用它，那就别让它先经过一个鼠标。

最后给读者留一句话：可观测和评测不是同一件事。可观测让你看见，评测让你判断。这两年大部分团队卡在前者，但真正难做、也真正决定产品命运的是后者。Arize 这场演讲让我多看清的一件事就是，后者其实是一张可以照着补全的矩阵，不再是漂在空中的概念。

原视频地址：https://www.youtube.com/watch?v=JsCCrBF7F1g。Phoenix 开源仓库：https://github.com/Arize-ai/phoenix。