12.4 LLM 评测与可观测性：从样本评分到发布决策

假设 A 版更受文风评审偏爱，却偶尔漏掉必填 JSON 字段；B 版的格式更稳定。仅凭平均偏好分无法决定发布，先要明确漏字段是否属于不可接受失败。

LLM evaluation 是一套决策协议：定义任务分布、可接受行为、评分方法、统计单位和上线阈值。模型、prompt、检索器、索引或工具任何一项变化，都可能让旧结论失效。

本课目标

• 构建由确定性检查到在线实验的分层评测；
• 为开放式回答设计 gold、rubric 和 pairwise comparison；
• 识别 LLM-as-judge 的位置、长度与自偏好；
• 评估 RAG 证据链和 Agent 执行轨迹；
• 建立可复现、隐私受控的生产观测与回归集。

1. 从发布问题倒推评测

先写一页 evaluation contract：

• target users、任务和流量分布；
• 成功、可接受失败和不可接受失败；
• 主指标、guardrail 与 slice；
• 比较对象和最小有意义差异；
• 样本单位、聚合方式和置信区间；
• 谁能修改 rubric，谁批准发布；
• model/prompt/tool/index 版本和 decoding config。

“准确率达到 90%”若没有任务分布、评分规则和分母定义，无法支持发布决定。

2. 建立分层评测栈

第 0 层：确定性验证

能用代码判定的先不用模型 judge：JSON Schema、正则、SQL result、compiler/test、数学 verifier、citation ID、forbidden tool、latency 与 cost budget。

这些检查便宜、稳定、可定位。它们不评价文字是否“有帮助”，却能挡住大量结构和执行错误。

第 1 层：组件评测

• retriever：Recall@K、MRR/nDCG、权限过滤；
• reranker/context packer：证据覆盖与截断；
• tool routing：工具与参数准确率；
• classifier/guard：各风险 slice 的 precision/recall；
• structured generator：字段语义和 verifier pass rate。

组件通过不等于系统通过，但能快速定位回归来源。

第 2 层：行为与端到端评测

在完整对话或 workflow 上评价任务完成、事实支持、格式、安全、恢复和用户效用。保存完整输入、检索证据、工具轨迹和最终输出，而不只保存一个总分。

第 3 层：在线评测

Shadow、canary 或 A/B test 观察真实流量中的任务成功、投诉、人工接管、延迟、成本和安全 guardrails。用户 thumbs-up/down 受自选择和界面影响，不能直接等同无偏质量标签。

Shadow 请求应抑制真实写操作，也无法直接测量用户对未看到的答案如何反应。Canary 与随机 A/B 的流量分配及结论边界不同，应在看结果前明确分配单位和停止规则。

3. Gold 与 Rubric 要能复核

封闭任务可提供标准答案和 verifier；开放任务需要明确 rubric。例如客服回复可拆成：

• 是否正确识别用户问题；
• 是否只使用当前政策；
• 是否给出可执行的下一步；
• 是否出现未经支持的承诺；
• 语气和长度是否在范围内。

每项写 positive/negative anchors 和 edge cases，注明权重与 hard-fail。让两名评审先独立标注一小批样本，讨论分歧并修订 rubric，再扩展数据。若专家之间长期无法一致，问题可能在定义，不应让 judge 制造虚假的精确分数。

4. Pointwise 与 Pairwise 的取舍

Pointwise rating 适合检查绝对门槛，但不同评审对 1–5 分标尺理解不一。Pairwise comparison 更容易回答“A 与 B 谁更好”，适合回归比较；它仍需要平局、都不合格和理由标签。

比较时：

• 对同一 prompt 配对，使用 paired analysis；
• 随机交换 A/B 位置；
• 隐藏模型身份和版本；
• 控制或分层回答长度；
• 报告 tie 与 invalid rate；
• 按用户/会话/来源聚类时，用正确统计单位计算不确定性。

不要把同一文档生成的许多近重复问题当成独立样本，否则置信区间会过窄。

平局口径会改变胜率：40 胜、40 负、20 平，平局算半胜时为 50%，仅以胜场除以全部 100 场则为 40%。先声明口径，另列无效判定。

5. LLM-as-Judge 是有偏测量工具

LLM judge 可以降低开放式评测成本，也会表现出：

• position bias：偏爱先出现或后出现的答案；
• verbosity bias：把更长、更像报告的文本当作更好；
• self-enhancement bias：偏爱与自身风格或家族相近的输出；
• rubric drift：遗漏限制或自行增加标准；
• knowledge error：无法可靠核验领域事实；
• prompt injection：被待评文本操纵。

使用前先在人工 gold set 上校准。把 rubric 与待评文本分隔，随机化顺序，要求输出结构化 reason codes，并对判定不稳或高风险样本回到人工。多 judge 投票能降低部分随机误差，但同源模型可能共享系统偏差，不能自动获得独立性。

Judge agreement 高也不证明结论正确；它只说明测量工具在该样本上稳定。

MT-Bench 与 Chatbot Arena 研究 检查了位置、冗长与自偏好。偏差大小取决于 judge、rubric 和任务，要在目标数据上实测。

6. 把“幻觉率”拆成可判定错误

“幻觉”容易把不同故障混在一起。更可操作的分类是：

• unsupported claim：证据未支持；
• contradicted claim：与证据冲突；
• citation mismatch：引用存在但不支持断言；
• fabricated entity/source；
• stale claim：使用失效版本；
• omission：漏掉会改变结论的限制条件；
• overclaim：把可能、相关或局部事实写成确定、因果或普遍结论。

在 RAG 中按 atomic claims 标记 support，并分别报告 citation precision/completeness、groundedness 和 answer correctness。正确答案可能来自模型记忆而未被当前证据支持；有证据支持的答案也可能引用了过时来源。

7. RAG 与 Agent 要评轨迹

RAG trace 至少包括 query rewrite、候选、filter、rerank、packed context、citations 和 index version。Agent trace 至少包括每步模型版本、proposed calls、validation/auth decisions、tool results、approvals、retries、state transitions 和 side effects。

因此可以定位：

最终答案错
├─ 没召回证据：retrieval failure
├─ 证据被截断：context failure
├─ 有证据却说错：generation/grounding failure
├─ 工具选错：routing failure
├─ 参数错：argument failure
└─ 工具成功但重复执行：orchestration failure

只有 final-answer score 会把这些不同修复路径压成一个数字。

8. 统计结论要与采样设计一致

优先用 paired comparison；对非正态、复杂指标可按正确单位做 paired bootstrap。若样本按用户、文档或会话聚类，resampling 也应按 cluster，而不是按单条消息。

同时检查：

• overall 与关键 slices；
• effect size 和 confidence interval；
• 多指标/多切片带来的 multiple testing；
• sample selection 与 benchmark contamination；
• 评测集是否被训练、prompt tuning 或人工调试反复看过。

反复针对公开 benchmark 调整系统，会把它变成训练信号。保留 private/blind set，并从生产事故构建未公开 regression cases。

零次观察失败不等于零风险。在独立同分布 Bernoulli 假设下，100 次中零失败的单侧 95% 上界是 $1-{0.05}^{1/100}\approx 2.95\mathrm{\%}$。会话聚类或部署分布变化都会破坏这项简单计算的前提。

9. 生产可观测性必须能复现一次回答

每个 run 关联：

• model/checkpoint/API version；
• system/developer prompt hash 与 template version；
• sampling parameters；
• retriever/embedding/reranker/index versions；
• tool schemas、tool versions 与 policy version；
• token usage、latency、cost、retries 和 errors；
• citations、tool trace 与 final status；
• user feedback、人工接管和后续纠错。

日志不是越多越好。对 prompt、文档、工具输出和 memory 做 data classification、redaction、retention、access control 与删除；敏感 payload 可保存 hash/受控引用和必要的结构化指标。

Hash 只能与保留的候选内容比对身份，不能还原输入。受控引用需要在保留政策内确实可取回的 artifact。即使 trace 完整，托管模型变化或非确定性 kernel 也可能只能支持复盘，不能逐字节重放。

Dashboard 应把质量、风险、成本和性能一起看。降低延迟却让 empty retrieval 上升，或提高胜率却增加人工接管，都可能不满足发布条件。

10. 从事故回流到回归集

线上错误修复后，保留最小、去敏的复现样本，记录：

• failure taxonomy 和 root cause；
• 哪个层级应捕获；
• 修复版本；
• expected behavior 与 deterministic checks；
• 适用 slices；
• 是否加入 release-blocking suite。

回归集要定期去重、重标和更新权威答案。数据过时会把模型强行拉回旧政策。

常见误区

• 一个 benchmark 总分代表生产质量：真实任务、风险与数据分布可能不同。
• LLM judge 等于廉价人工：它是需要校准和监控的有偏测量工具。
• 多跑几次取平均就可靠：系统偏差不会被平均掉。
• 最终答案正确就算 Agent 成功：越权尝试和重复副作用同样是失败。
• 日志越全越可观测：没有版本关联、隐私边界和 failure taxonomy 的日志难以复盘。

练习

1. 为机器学习团队的 JSON 问答任务写 evaluation contract。
2. 将“幻觉率”拆成至少四个可标注标签。
3. 设计随机换位实验，测量一个 judge 的 position bias。
4. 为 RAG 错误构建 retrieval/context/generation 三层诊断表。
5. 指定一个 Agent 发布门槛，至少含质量、权限、重复副作用和成本 guardrails。

小结

LLM 评测的产物不是排行榜，而是可复核的发布证据。确定性检查负责硬约束，组件评测定位问题，人工和经过校准的 judge 衡量开放式行为，在线实验验证真实流量，版本化 trace 让每次回归可以追溯。

机器学习团队已经拥有后训练、外部知识、工具调用和评测管线。下一章会处理更难的边界：偏见、隐私、滥用、供应链和治理责任。