评测与可观测性

一个在公开榜单上排名靠前的模型，落到自己的产品里仍然可能表现糟糕。基准测试衡量的是固定数据集上的通用能力，而实际应用跑的是一条特定的提示词，叠加自有的检索上下文，运行在一个智能体循环里，面对的是逐周漂移的真实用户输入。弥合这个差距的学科有两半，到 2026 年年中，它们已基本融合为同一个工具品类。实践问题在于，如何选择并接好这套工具，同时不把公开基准上的质量误认为产品里的行为。

在技术栈中，这一层承接第七部分定义的测量理论。第 47 章 抽象地衡量模型，第 48 章 判断一个差距是否站得住，第 49 章 定义人的标签，第 50 章 讲模型评判者，第 51 章 讲有据性，第 52 章 讲多步轨迹，第 53 章 则把这一切变成发布闸门。这里衡量的是正在运行的系统。它消费服务层（第 82 章）和模型网关（gateway）（第 88 章），并产出反馈信号回流给智能体（第 85 章）与微调（第 84 章）：评测数据集会变成偏好数据，而智能体轨迹正是故障真正浮出水面的地方。

循环的两半

**评测（Evaluation）**问的是「输出好不好？」，对照自己定义的标准。它既离线运行（在精挑细选的数据集上、在 CI 里、上线之前），也在线运行（从生产流量中采样、持续打分）。工作的基本单位是一个分数。分数有三类，通常混着用：

• 确定性断言：正则、JSON-schema 校验、精确匹配、延迟或成本预算。便宜、快，是第一层检查。
• 基于参考的指标：BLEU、ROUGE，以及它们在检索领域的近亲，如上下文精确率、上下文召回率、忠实度。
• LLM 作为裁判：用第二个模型按评分细则给第一个模型打分。这是大规模为开放式质量打分的可扩展办法，第 50 章 的主体内容讲的正是如何做这件事而不至于自欺。

可观测性（observability）问的是「到底发生了什么？」它捕获一条轨迹（trace）：一个请求在系统中流动时的完整树形结构，每一次 LLM 调用、检索、工具调用、嵌套的智能体步骤，每个 span 上都挂着输入、输出、计时、token 计数与成本。没有它，就只能靠读扁平日志来调试一个非确定性的分布式系统。

这两半之所以相连，是因为评测的对象，正是所观测到的那条轨迹。一条生产轨迹会变成一个测试用例。一个裁判在采样的 span 上运行，产出在线分数。仪表盘里抓到的一次回归，会变成离线套件里的一个固定用例。这个循环先观测、再打分、再筛选、再重测，正是「持续评测一个 LLM 应用」的实践内核，本章后续围绕它展开（图 87.2）。

2026 年的洗牌

2026 年年初的两起收购重塑了格局，也指明了大方向：独立的评测/可观测性工具，正在变成更大的数据或模型平台里的一个功能。

• OpenAI 收购了 Promptfoo（2026 年 3 月 9 日宣布），并弃用自家托管的 Evals 产品（2026 年 10 月 31 日转为只读，11 月 30 日关停），引导用户转向 Promptfoo 与 Datasets。开源的 openai/evals 仓库保留，托管仪表盘则不再保留。
• ClickHouse 收购了 Langfuse（2026 年 1 月 16 日，与 ClickHouse 4 亿美元 D 轮同步）。Langfuse 表示其开源与自托管承诺继续有效。

看谁归谁所有，并不是重点。这种动荡是真实的，所以要偏好那些数据与埋点都能带走的工具。下文 OpenTelemetry 就是这样的选择。

主要玩家

下表所有许可证、定价与收购方面的论断都截至 2026 年年中，出处见延伸阅读。定价是撰写时已公布的清单形态，变动频繁，所以请把确切金额视为指示性参考。裁判准确度与「最适合」的论断取决于具体工作负载，本处未做独立基准测试。

评测框架与套件

追踪与可观测性平台

底层基座

截至 2026 年年中，OTel GenAI 规范在很大程度上仍是实验性的（「Development」稳定级别），不过核心属性（gen_ai.system、gen_ai.request.model、token 计数）正在趋稳。可以用 OTEL_SEMCONV_STABILITY_OPT_IN 选用最新版本。OpenInference 跑在规范之前，并能向任意 OTel 后端（Datadog、Grafana、Jaeger）输出，这正是它当下成为实用之选的原因。

如何选择

第一刀切在能力评测与应用评测之间，因为它们是由不同工具完成的不同任务。

当衡量的是一个模型时，选能力套件：对比检查点、验证微调（第 84 章），或复现一个榜单数字。任务偏智能体、用工具、带安全色彩时用 Inspect，经典学术基准用 lm-evaluation-harness。

当衡量的是自己的系统时，选应用评测工具：这条提示词、这条 RAG 流水线、这个智能体，对照对产品要紧的标准。在应用评测内部，有四条轴决定选型：

LLM 作为裁判：成本对信任

裁判大约比人工评审便宜 500 到 5000 倍，且能逼近人与人之间的一致度，但只有在校准过之后。一个没校准过的裁判，会信心十足地打分，也同样信心十足地出错，外部却很难看出来。截至 2026 年年中，第 50 章 深入展开的共识做法是：

• **对照人工标注样本验证。**报告 Cohen's kappa（即对偶然一致做过校正后的一致度），先达到 $0.8$ 左右，再信任裁判去为任何东西把关。
• **控制位置偏差。**同时对 A/B 与 B/A 两种顺序打分，只统计一致的胜出。
• **控制冗长偏差与自偏好偏差。**永远不要把同一个模型家族同时用作生成者和裁判。
• 使用显式的、按标准分离的评分细则（G-Eval 风格）。把硬规则拆成一个检查的 DAG，而非一条含糊的提示词。

改变人类标注里「好」的基率，看着原始一致度居高不下、而 Cohen's kappa 却塌掉，这正是为什么「裁判 90% 的时候都同意」几乎什么也证明不了。

import numpy as np

# 一个几乎总是说「好」的偷懒裁判，对照人工标注来评分。
# 原始一致度看着很漂亮，但 Cohen's kappa 校正了偶然因素后就塌掉了。
def kappa(m):
    m = np.array(m, float); n = m.sum()
    po = np.trace(m) / n                       # 原始一致度
    pe = (m.sum(0) * m.sum(1)).sum() / n**2    # 偶然预期下的一致度
    return po, (po - pe) / (1 - pe)

n = 1000
for good_rate in [0.70, 0.80, 0.90, 0.95]:
    good = int(n * good_rate); bad = n - good
    caught = int(bad * 0.20)                    # 裁判只标出 20% 的坏答案
    miss = int(good * 0.02)                     # 并错误地标出 2% 的好答案
    cm = [[caught, miss], [bad - caught, good - miss]]
    po, k = kappa(cm)
    verdict = "trust" if k >= 0.8 else "do NOT trust"
    print(f"human good={good_rate:.0%}  agreement={po:.2f}  kappa={k:.2f}  -> {verdict}")

一个合理的默认选择

对一个典型团队，正在交付一两个 LLM 功能、想要一个持续评测循环而又无需组建平台团队，这套默认栈开源优先、可自托管、OTel 原生、由 CI 把关，且日后升级到托管平台有一条干净的路径。

选择这套默认时有两点提醒。其一是动荡：Promptfoo 现归 OpenAI，Langfuse 现归 ClickHouse，长期投入前请重新确认路线图与许可证。其二是别加用不上的厂商。已统一到 Databricks 的团队应优先 MLflow 3 Evaluate，在 Weights & Biases 上的团队应优先 Weave，而不是再栓上一个新平台。

接线

循环经由模型网关（第 88 章）闭合：被测应用、评测与裁判都调用网关，绝不直连提供商。

一份最小的 Promptfoo 配置如下，指向网关，并在 LLM 裁判前面放了一个确定性守卫。把它存为 promptfooconfig.yaml，运行 npx promptfoo@latest eval。

# promptfooconfig.yaml
providers:
  - id: openai:chat:gpt-5            # resolved by the gateway, not OpenAI directly
    config:
      apiBaseUrl: https://gateway.internal/v1
      apiKey: ${GATEWAY_VKEY}        # scoped virtual key, budget-capped
prompts:
  - "Answer using only the context:\n{{context}}\n\nQ: {{question}}"
tests:
  - vars: { question: "...", context: "..." }
    assert:
      - type: is-json                # deterministic guard, runs first and free
      - type: llm-rubric             # LLM-as-judge, calibrated rubric
        value: "Answer is faithful to the context and cites it."
        provider: openai:chat:gpt-5-mini   # judge via gateway, different family

要为合并把关，在 CI 里跑这一条命令，遇到回归就让任务失败：

# CI step: fail the build if any eval assertion regresses
npx promptfoo@latest eval -c promptfooconfig.yaml --no-cache --output results.json
# exit code is non-zero when assertions fail, which fails the pipeline

整个系统的心跳是提升步骤。一条来自 Langfuse 或 Phoenix、未通过在线裁判的生产轨迹，会被提升进上面的 tests: 集合，于是离线套件针对的是生产里真正看到的故障，而非设计时凭空想象的故障。没有这个提升步骤，手里就是两件互不相干的工具；有了它，才成为一个循环。

生产评测循环

这套循环只有在同时改变三条运维轴时才真正划算。可观测性把非确定性行为变成可调试的东西，从而提升能力；评测把「感觉更好」变成一道发布闸门。网关让在线裁判便宜到可以持续运行，而确定性断言在裁判调用发生之前就拦下成本低、也更该提前发现的故障。信任则落在校准与可携带性上：一个 LLM 裁判可信到何种程度，取决于它对照人类的校准，而 OTel 基座的作用，正是让轨迹与分数能从任何变更条款的厂商那里带走。只有这三者都成立，这套循环才值得搭建；而在 2026 年年中，工具终于成熟到让它们能够成立。

延伸阅读