任何 eval 系统都在回答三个问题：评什么 · 拿什么对照 · 怎么打分

历史上的五种范式（沉淀下来的真共识）

agent 评估必备

LLM-judge 校准的标准做法：用小样本人类标注校准 judge，确保 judge 和人类一致率 ≥ 0.8（Cohen’s kappa）。这是 OpenAI / Anthropic / Google 在论文里都报的标准动作，没这一步 judge 的分数没人会信。

Pairwise 偏差：position bias（先看到的更易选）、verbosity bias（更长的更易选）、self-preference（judge 偏好自己家模型）。修法：A/B 互换 + 至少两次结论一致才计。这不是 EvalView 的发明，是 LMSYS Arena 2023 的标准做法。

标准评估的 6 步 SOP

1. 定边界 —— 评 prompt / LLM call / agent / agent+skill / pipeline 中的哪一层
2. 建数据集 —— (input, optional_reference, metadata)，N ≥ 50 才有统计意义
3. 定 metrics —— 每个 metric 都是 (run_output, reference?, metadata) -> score
4. 跑评估 —— 每 case 跑 K ≥ 3 次处理非确定性，case-level 汇总
5. 校准 —— LLM-judge 必须人工对齐
6. 闭环 —— CI 拦截退化、生产采样回灌

市面对标（2026 最值得参考的几个）

EvalView 细节（最值得抄的）

数据流就是 snapshot → check → diff。test case YAML：

name: refund-needs-order-number
turns:
  - query: "I want a refund"
    expected:
      output: { contains: ["order number"] }
      tools: ["lookup_order"]
      forbidden_tools: ["delete_order"]

四层评分组合成 composite：

1. tool calls & sequence（确定性，免费）
2. code-based check（regex/json schema/contains，免费）
3. embedding similarity（~$0.00004/test）
4. LLM-as-judge（~$0.01/test）

最关键：evalview check --statistical 10 --auto-variant —— 跑 N 次，自动把 tool-call 路径聚类，把不同但有效的轨迹都当 golden。这就是我设计里“洞 2”（LLM 非确定性）的标准答案，比 K-sample 均值更聪明。