AI 应用的离线评估体系工程 2026：从 golden set 到 CI 门禁

一、问题：为什么 AI 应用上线前必须有评测闭环

2026 年的 AI 应用早已不是"重新训练一个模型"那种事了。绝大多数团队交付的是在已有大模型之上构建的产品——RAG 检索增强、Copilot 协作助手、垂直客服 Agent、文档问答、内容生成、知识库摘要、代码助手——这些应用的共性是：模型的权重不在你手里，模型的行为又被 prompt、上下文、检索质量、工具调用、记忆状态等多层链路共同决定。任何一层改动都可能让线上行为发生漂移，而漂移的方向和幅度又往往非线性。一次 prompt 微调可能让某个具体场景的回答质量提升 20%，却在另一个场景引入了 30% 的引用归因错误——而这个错误只发生在 5% 的长尾 query 里，运气不好的话要等一周后的用户反馈才被发现。

这就是为什么离线评测体系（offline evaluation system）成为 AI 应用工程化不可绕开的核心环节。它的作用不是替代线上监控（on-line observability），而是与监控形成对偶：监控负责回答"线上实际发生了什么"，而离线评测负责回答"如果我们这次发布这次改动，会发生什么"。前者是后视镜，后者是挡风玻璃——开车可以没有后视镜凑合，但不能没有挡风玻璃。我们把这套体系的工程化形态叫做评测闭环（evaluation loop），它至少包含五个阶段：golden set 构建、评测指标定义、评判器或自动化脚本、CI 流水线集成、failure taxonomy 与盲区探索。

AI 应用的评测比传统软件测试难在三个地方。第一，期望输出不是唯一的。一个 RAG 应用回答"公司法第 12 条规定什么"，两条引用都正确、措辞不同的回答在事实层面等价，但措辞差异会让基于字符串匹配的断言失效。第二，评测信号稀疏。一个对话 Agent 走完整条调用链路可能 200 次 LLM 调用，但其中可能只有 1-2 次是用户真正感知的"决策点"，这 1-2 个决策点错了用户感知，但用 200 次的总命中率平均会把单个错误稀释到 0.5% 以下。第三，评测目标可解释性差。传统软件测试断言"返回 200 状态码"，AI 应用的断言往往是"回答应当忠实于检索 context"——这是一个需要语义理解的判断，传统断言无法表达。

这三个难点共同决定了 AI 应用的离线评测体系必须有自己的形式化语言。本节作为全文引子，给出这个形式化问题的来源；后续节次逐一拆解五阶段的标准做法、踩坑点、以及工程清单。

在动手之前我们必须先直面一个现实：评测体系本身是有代价的。维护一个 5,000 条 golden set 的成本大致是 1 个高级工程师半年工作量；维护一个 LLM-as-Judge 评判器的成本是每月几千美元（取决于调用频次）；跑一次全量回归在 CI 流水线里要花 15-60 分钟。所有这些代价都必须在 PRD 阶段明确，不能事后追加。一个常见的失败模式是团队花了一个季度做出 MVP 才发现产品上线没有评测体系，此时回归改一段 prompt 必须全量人工 check——成本不可持续。第二个失败模式是评测体系本身没有"被评测"——评测脚本里的评判器 prompt 随时间漂移，golden set 越长越脏，最终所有人都不信任评测结果，CI 门禁变成摆设。这两个失败模式都指向同一个结论：评测体系本身是产品的一部分，必须有自己的"评测的评测"（meta-evaluation）。

本文九节按"问题→形式化→数据→指标→评判器→CI→盲区→清单→讨论"展开。第二节建立评测合约 (task, input, expected, rubric) 四元组的形式化基础；第三节讲 golden set 的来源、分层、标注一致性；第四节讲指标体系设计，特别是忠实度、引用归因、毒性、延迟成本的耦合；第五节深入 LLM-as-Judge 的工程细节；第六节讲 CI 集成与门禁分级；第七节讲如何发现评测盲区；第八节给出 22 条工程清单；第九节讨论评测体系的代价、未解难题与未来方向。

二、形式化：四元组 (任务, 输入, 期望, 评分准则) 与评测合约

AI 应用的离线评测在数学上可以形式化为一个四元组：

Eval = (T, I, E, R)

其中 T 是任务类型（任务模板），I 是输入分布（query 多样性），E 是期望输出集合（可能含多正解），R 是评分准则（rubric）。一次具体的评测样本是一条五元组 (t, i, e, r, m)，其中 m 是模型/系统的实际输出，r 是评分函数。系统在该任务上的得分定义为：

Score(t, T) = Σ_{i ∈ I_sample} R(e_i, m_i) / |I_sample|

这个看似简单的形式化藏有两个工程大坑。第一坑：E 不是标量，而是集合。AI 应用的"正确"往往是一个等价类，集合的两个元素在事实层面等价但在表述上不同。强行把 E 收敛成"标准答案"会丢失语义信息，让评测结果与人类判断脱节。第二坑：R 不是单值函数，而是多维度向量。最简的 R 也至少包含两个维度：factuality（事实正确性）和 relevance（相关性）。高阶 R 还会含引用归因（每条断言是否对应一段引用）、语气风格（是否符合产品调性）、毒性（是否含不恰当内容）、延迟成本（token 数与端到端耗时）等。

把这两个工程坑吃透，评测体系才有可落地的基础。我们把上面五元组的下游产物叫评测合约（eval contract）。所谓合约，就是把 (T, I, E, R) 同时落到代码、数据、prompt 模板三类实体里：

• 代码层：测试驱动（可以是 pytest、可以是 vitest、可以是公司内部的 eval harness），接受 model adapter 注入、读 golden set 路径、跑推理、调用评分函数、产出 metric dict。
• 数据层：golden set 本身，CSV / Parquet / JSONL 均可，但 schema 必须严格（id, task, input, expected, rubric_weights, tags, source, last_reviewed_at）。
• prompt 模板层：当评分函数 R 是 LLM-as-Judge 时，judge prompt 模板是合约的一部分，必须和 model 输出 schema 一一对应。

合约的版本化是工程共识。每一次 golden set 增长、rubric 调整、judge prompt 改动，都要在 git 里留下带签名的 commit，并在 CI 流水线上跑一次"meta-evaluation"：用旧 judge 跑新 golden set，结果差异在 2% 之内才允许合并。这是评测的"自我回归测试"。

接下来一个常被忽略的形式化点是指标权重。现代 AI 应用 KPI 一般不是单维度的。比如 RAG 应用的 KPIs 包含：引用归因准确率（≥ 95%）、拒答率（≤ 8%）、P95 延迟（≤ 2.5s）、token 成本（≤ 0.02 USD/request）。这四个维度是耦合的——优化一个会使另一个变差。评测体系必须能给出Pareto 曲线而非单点分数：

frontier = { (F, R, J, L, C) | 系统在所有维度上不被另一系统支配 }

这条曲线的横轴是质量指标（忠实度、相关性等），纵轴是成本指标（延迟、token）。曲线上的每个点都是"已知非劣解"，发布决策不是"选得分最高的"，而是"选与当前 production 距离最近的点"。这条曲线让 PRD 阶段的协调大大简化——产品、研发、运维各自关心的指标在曲线上共同显形。

最后一个形式化要素是评测任务的层级。AI 应用评测不是扁平的"一组 question-answer 对"。它至少有三层：

• L1 — 单元级：单条 query，从输入到输出的整链路 trace。
• L2 — 轨迹级：多轮对话或多步 Agent 的轨迹序列，评估轨迹级一致性（tool choice 是否合理、是否有死循环、是否提前终止）。
• L3 — 会话级：整个用户会话的成功率（用户是否最终达成目标、是否中途放弃、是否触发人工接管）。

很多团队的评测体系只覆盖 L1，L2/L3 缺位。后果是单个 LLM 问答质量很高，但 Agent 在多轮里陷入循环调用工具 200 次；或者单条 query 看起来正常，但用户的 5 轮对话后整体挫败感很强。L1 覆盖率 100% 是必要不充分——必须同时覆盖 L2（轨迹）和 L3（会话）。

三、Golden Set 工程：从生产流量采样到分层抽样的质量控制

Golden Set 是评测体系最昂贵的资产，也是最容易被低估的资产。一个高质量的 Golden Set 是 AI 应用团队从"能跑"到"能改"的分水岭——没有它，每次 prompt 微调都是裸奔；有了它，每次 prompt 微调都是受控实验。

Golden Set 的来源主要有 4 条链路，按优先级排序：

1. 生产流量采样：把生产 trace 按 hash(query) % 100 采样到 1%。这是最真实的 query 分布，但有两个问题：(a) 含敏感信息（用户 PII、机密内容），必须脱敏；(b) 答案无 ground truth，需要标注。
2. 用户反馈回流：用户点"赞/踩"、主动反馈、客服转过来的"模型答错了"工单——这些是高质量负样本（failure mode），优先级最高。
3. 红队 / 安全评测：手工构造的攻击 prompt、毒性诱导、越狱尝试——这些是 golden set 里的"必防"集。
4. 合成生成：用 GPT-4 级模型根据 query schema 批量生成样本，仅作为初稿，必须人工 review。合成数据不能直接进入生产评测集。

黄金法则：生产流量是第一来源，但不是全部。如果评测集只来自生产流量，模型就在"复习"它见过的题，无法发现新场景。评测集必须包含 5-15% 的"长尾合成问题"——这些可能是产品经理设想的"未来场景"、红队发现的"理论上可能但生产未触发"的攻击、或者其他工业领域迁移过来的"数据漂移前哨"。

Golden Set 的分层抽样是关键技术。AI 应用的 query 分布天然长尾，按 query 类型分层（intent taxonomy）能保证每个子类型都有足够样本。常见分层维度：

• 意图类型（按业务分类）：订单查询、退换货、政策咨询、操作指引、闲聊兜底……每个意图必须有 ≥ 50 条样本。
• 难度等级：trivial（关键词提取）、medium（多步推理）、hard（多文档交叉、长上下文、隐含意图）、adversarial（攻击 / 越狱）。
• 语言 / 地区：多语言产品需覆盖 zh / en / ja / es 等。
• 渠道：Web / 移动端 / 第三方 API 的 query 表达风格差异显著。
• 时段：工作日 vs 周末、白天 vs 深夜，query 类型分布不同。

分层抽样的核心是等精度不等概率：每个 cell 至少 50 条样本，少于 50 条的 cell 标记为"数据不足、评测置信度低"。CI 流水线在读评测报告时，遇到不足 50 条的 cell 必须展示置信区间，不能只看均值。

Golden Set 的标注质量控制是另一个工程难点。AI 应用标注有三个层次：

• L1 — 准确性：答案事实是否对。质检方法：双盲标注 + Cohen's Kappa ≥ 0.85 才达标。
• L2 — 完整性：答案是否覆盖了 query 的全部隐含需求。质检方法：标注员必须列出 query 的 sub-questions，逐项核查解答。
• L3 — 评分标准对齐：不同标注员对同一 query 给的"正确"边界是否一致。质检方法：每个标注员每月跑 50 条"金标准交叉题"（已知答案 + 期望评分），偏差 > 5% 触发 retraining。

第三个层次是最容易被忽视的。没有 L3 对齐，标注员 A 容忍"基本正确但缺一个引用"，标注员 B 打 fail——评测集本身就有 10% 的随机噪声，CI 门禁的 2% 阈值就成了笑话。

Golden Set 的版本治理。每条 golden sample 都有 last_reviewed_at 字段，每月抽样 5% 重新 review 一次（防止产品迭代让答案过时）。removed_at 字段记录"已下架"但保留以供历史回归。git 里 golden set 是只读分支 + PR 流程：任何人要改 golden set 必须开 PR，至少 1 个 reviewer，commit message 必须描述改动原因（产品升级 / 业务规则调整 / 标错修正）。

Golden Set 的样本量公式。粗略估计：query 类型数 × 50 + 难度档位数 × 100 + 长尾合成 200。真实工程中一个中型 AI 应用（20 个意图 + 4 档难度 + 3 种语言）的 golden set 大约 1,500 - 3,000 条。每条标注成本 5-30 分钟（视复杂度），首次构建 1 个高级工程师约 1-2 个月的工作量。这是建立评测体系的真实成本，必须在 PRD 阶段 plan。

Golden Set 的"反例"价值。失败样本（model 答错的）比成功样本更值钱。失败样本直接定义系统的边界。建议每条失败样本必须记录：失败模式（factual / 引用 / 拒答 / 工具调用 / 延迟）、根因（prompt / 检索 / 模型 / 上下文）、修复版本（修复后再次加入，标记为"已修复"）。这个失败样本本身的轨迹就构成failure taxonomy，是后续 prompt 修复、retrieval 调优、模型升级的金矿。

四、评测指标体系：忠实度、相关性、引用归因、毒性、延迟成本的耦合设计

AI 应用的评测指标体系不是单维度的"准确率"，而是一个多维耦合空间。这一节我们逐一拆解关键维度，然后给出耦合设计原则。

忠实度（Faithfulness）：回答的每一个事实断言是否都有上下文支撑。RAG 应用的忠实度低意味着"幻觉"——编造了 context 里没有的内容。忠实度不是二元的（有 / 无幻觉），而是连续谱：忠实度分 = 被引用 context 支撑的断言数 / 全部断言数。

忠实度的工程难点是断言切分。一段 200 字的中文回答可能含 5-8 个事实断言，传统字符串匹配无法识别断言边界。业界做法是用 LLM-as-Judge 做断言切分 + 断言归因，每条断言独立判断"是否被引用支撑"。DAG 形式大致是：

chunked_response → assertions[] → for each assertion: support_lookup(context, assertion) → score

典型工程实现里，"assertion 切分错误"本身是最大噪声源——一个 200 字回答被错误地切成 3 段 vs 6 段，忠实度分差 5-10%。所以断言切分器也必须有自己的评测（meta-eval），金标准是 100 条人工切的答案。

相关性（Relevance）：回答是否切题。相关性低意味着"答非所问"——用户问 A，系统答 B。相关性分 = 评分模型判断"回答与 query 的相关程度"的 1-5 分。LLM-as-Judge 实现时关键是评分 prompt 必须给出明确锚点（"5 分 = 完全切题、3 分 = 部分切题有偏离、1 分 = 完全不切题"），否则评分员会"居中"给 3 分，失去区分度。

引用归因（Citation Attribution）：当回答含引用时（如 [1]、[2] 或 doc_id_xxx），每条引用是否真的对应 context 里的某段文档。引用归因错误 = 引用标号指向一份不相干的文档，是 RAG 应用最严重的错误之一，因为它欺骗用户相信 hallucination 是事实。

引用归因的评测最微妙。准确率（每条引用都正确）不够——5 条引用 4 对 1 错，准确率 80%，但用户的信任崩塌。F1 分数更稳健（precision + recall），但仍不能反映"错引用 vs 漏引用"的轻重差异。建议同时报告：总引用数、错引用数、漏引用数、归因 F1、归因 F2（recall 加权）。F2 比 F1 更关注 recall——错引用可被用户警觉，漏引用则悄悄发生更危险。

毒性 / 安全性（Toxicity / Safety）：回答是否含不恰当内容（偏见、歧视、违规指令、隐私泄露）。这是一个相对独立的维度，但与忠实度有耦合——一个"高安全过滤"系统可能通过拒答实现"零毒性"，但牺牲了用户回答率。拒答率本身要成为独立 KPI。

延迟与成本（Latency / Cost）：端到端 P50 / P95 延迟、token 消耗、API 成本、GPU 资源占用。这三个维度是 AI 应用商业化的关键约束。评测报告必须把"质量指标"和"成本指标"放在同一张图上——不能分两个 dashboard，否则产品经理会只看质量曲线做决策，做出一个"质量满分但用户付不起"的 AI 应用。

指标体系的耦合设计。五条主指标之间是相互制约的：

• 提升忠实度 → 检索召回更多 → 上下文变长 → 成本 ↑、延迟 ↑
• 提升相关性 → 改 query 理解 → 引入 query 改写 → 延迟 ↑
• 提升引用归因 → 强制引用 → 拒答率 ↑（不确定时拒答比强行引用安全）
• 降低毒性 → 强过滤 → 拒答率 ↑、相关性 ↓
• 降低延迟 → 短上下文 → 召回可能丢 → 忠实度 ↓

这种Pareto 耦合意味着评测体系不能简化为"加权总分"。一个常见做法是定义主指标 + 约束指标：

• 主指标：忠实度 ≥ 0.92 AND 引用归因 F2 ≥ 0.85
• 约束指标：拒答率 ≤ 8% AND P95 延迟 ≤ 2.5s AND USD/request ≤ 0.02

主指标定义产品质量下限，约束指标定义工程 SLA。两者同时满足才发布。这避免了"用 latency 优化挤掉 accuracy"的常见错误。

指标权重的工程治理。权重是产品决策，不是技术决策。每次指标权重调整必须在 PRD 里有显式 changelog，并在团队周会上评审。任何一次 CI 门禁的阈值变动也必须挂在 git tag 上——这是评测体系自身的"审计轨迹"。

指标分层：很多团队把全部指标合在一张图，工程师根本看不出哪个维度倒退。一份合格的评测报告应分四层：

• L1: 主指标（绿/红卡片）
• L2: 约束指标（每条带阈值 + 实际值）
• L3: 分维度细分（按 query 意图 / 难度 / 渠道拆分）
• L4: 失败样本 top 10（最差 10 条 + 失败原因标签）

L1 绿 + L2 黄 + L3 红，给出"整体可发布，但 X 意图层衰退"的精确信号。

五、评判器（LLM-as-Judge）工程：提示工程、位置偏置、对抗鲁棒性

LLM-as-Judge 是 AI 应用评测的核心引擎。它用一个强 LLM（通常是 GPT-4 级、Claude Sonnet 级、自家微调的"裁判模型"）充当评分员，给系统输出打分。LLM-as-Judge 把"评测"从字符串匹配时代推进到了语义匹配时代，但带来了一组新的工程挑战。

Judge 模型的选型。选 Judge 模型的三个考量：

• 能力对齐：Judge 能力必须显著高于被评系统，否则它读不懂系统输出。例如一个 RAG 应用基于 GPT-3.5 答法律问题，Judge 必须用 GPT-4 而不能用 GPT-3.5。
• 稳定性：同一输入多次调用 Judge，分数方差 ≤ 0.5。GPT-4 级别模型通常自一致性 ≤ 0.3，方差可控。
• 延迟与成本：评测一次全量回归如果调用 10 万次 Judge，这是成本中心。建议设置"轻量 Judge"（小模型 + 简单 prompt）用于开发期频繁跑，"重型 Judge"（大模型 + 强 prompt）用于发版前全量。

Judge Prompt 工程。Judge Prompt 是合约的一部分，必须规范化。标准结构：

1. 角色描述：明确 Judge 身份（"你是一个严谨的评测员，评估 AI 系统的回答质量"）。
2. 评估维度：每个维度给出 1-5 分的明确锚点 + 例子。
3. 输入格式：明确告诉 Judge 输入哪些字段（query、context、系统输出、参考答案）。
4. 输出格式：强制 JSON / 结构化输出，避免自由文本。
5. 评估禁令：明确禁止的推理（如"不要考虑回答的语气"、"不要考虑回答长度"）。

Judge Prompt 的常见错误是维度交叉——一个维度同时评估"事实正确"和"信息完整"，导致 Judge 倾向于看综合印象。维度必须原子化，一个维度一个判断。

位置偏置（Position Bias）。LLM-as-Judge 的最大坑之一：很多 Judge 模型倾向于把"第一个"输入判为更好。表现：同一份回答互换 A / B 位置，胜率从 60% 变成 40%。缓解方法：

• 位置平均：同一对样本跑两次（A 在前、B 在后），取平均分。
• 两侧独立：让 Judge 分别对 A 和 B 独立打分（不对比），得到 two scalar scores 比 single pick 更稳定。
• 随机化顺序：在评测脚本里随机 shuffle A/B 顺序，记录每次的 order。

位置偏置如果忽视，评测结果会随评测器版本漂移，给团队"模型在进步"的假象。

长度偏置（Length Bias）。Judge 倾向于给长回答更高分数。表现：同样事实正确性的两个回答，300 字胜 100 字。缓解方法：在 Judge Prompt 里明确"长度不作为评分依据"，并在 100 条"已知正确性相同、长度不同"的探针样本上验证 Judge 的稳定性。

自我偏好（Self-Enhancement Bias）。当 Judge 模型和被评系统出自同一系列（如都是 GPT-4 系），Judge 会倾向于给同系模型更高分。缓解方法：Judge 选异系模型（GPT-4 系审 Claude 系、Claude Opus 审 Gemini 系），或在 Judge Prompt 里加"避免偏好任何特定模型风格"。

对抗鲁棒性。LLM-as-Judge 自身可被对抗。如果 Judge 模型够强、系统开发者又能调 prompt，就可以构造"骗 Judge"的回答——表述漂亮但事实错误。缓解方法：

• 对抗集：评测集里专门放 100 条"答辩亮但事实错"的样本，验证 Judge 能识别。
• 多 Judge 集成：3 个不同模型的 Judge 投票，少数服从多数。
• 人审抽样：每月抽样 100 条 Judge 判定 + 人工复核，偏差 > 5% 触发 Judge prompt 调优。

Judge 的 Meta-Evaluation。Judge 本身需要被评测。每月用 200 条"已知正确答案 + 已知期望分"的金标准样本测 Judge：准确率 ≥ 90%、与人工评分的 Pearson 相关系数 ≥ 0.85 才达标。低于这个阈值的 Judge 必须被替换或调优。

成本与频率控制。如果一次全量评测 5,000 条样本，每条用 GPT-4 跑 Judge 取两次位置平均，单次成本约 1,000-3,000 USD。建议分级使用：

• PR 触发的开发期评测：用 200 条"快速集合"（high-traffic + high-risk 子集），成本 50-100 USD / PR。
• 主干 / Release-triggered 全量评测：跑 5,000 条完整集合，成本 1,000-3,000 USD / release。
• 每日的 smoke test：跑 50 条"健康探针"，成本 5-10 USD / day。

Judge 的缓存与降级。同一对 (query, system_output) 出现在多次评测中时，缓存 Judge 结果（TTL 7 天）。系统输出不变就不重跑。降级策略：当 Judge 不可用时（如 API rate limit），回退到"基于规则的快速评分"——只评忠实度（context 引用匹配），其他维度延后。

六、CI 集成：从单条 PR 触发的回归门禁到主干的灰度门禁

评测体系的价值在 CI 流水线里最终实现。没有 CI 集成，golden set 是静态文档、judge 是实验室工具——对发布决策零影响。CI 集成是评测闭环的"工程化最后一公里"。

CI 触发的三个层级：

• L1: PR 门禁：每次 PR 合并前跑评测，PR 作者可见结果。
• L2: 主干门禁：主干每次合并（merge to main）跑一次完整评测。
• L3: 发布门禁：每次发布打 tag 前跑一次金标准评测 + 人工审批。

L1 — PR 门禁。最频繁的反馈点。设计原则：

• 快速 subset：200 条 high-traffic + high-risk 样本，subset 选择算法保证覆盖率。
• 异步执行：评测在后台跑，PR 不阻塞；评测结果作为 PR 评论附加。
• 自动分类：评测结果按"严重程度"分类（critical / major / minor），critical 失败 PR 必须人工 review。
• 趋势对比：把这次 PR 评测 vs main 分支评测做 delta，衰退 > 1% 标黄、> 3% 标红。

PR 门禁的"严苛度"是心理学问题。太严会让工程师害怕改 prompt（一改就红），太松等于没门禁。建议双档位：

• Strict Mode（主干发布分支）：所有 critical 失败 = 阻塞合并。
• Loose Mode（开发分支）：critical 失败 = 警告 + 强制 comment，不阻塞。

L2 — 主干门禁。完整评测 + multi-judge 投票。结果发到团队频道、邮件列表、Slack。一份合格的主干评测报告应包含：

• 主指标卡片（绿/红）
• 各维度分数 + 与上次主干对比
• 失败样本 top 10（按失败类型聚合）
• Pareto 曲线（质量 vs 成本）
• Judge 一致性（Cohen's Kappa 多个 Judge 之间）
• Last reviewed golden set 状态（是否过期）

主干门禁的"红线"是主指标 ≥ 阈值，任何一次主干合并如果主指标掉到阈值以下，必须 auto-rollback。红黄绿三档：

• 绿：所有指标 ≥ 阈值 → 自动合并
• 黄：约束指标有 1 个掉到阈值以下但主指标绿 → 合并 + 警告
• 红：主指标掉到阈值以下 → 阻塞 + 报警 + 触发 on-call

L3 — 发布门禁。最严格的一档。设计原则：

• 多 judge 投票：3 个 Judge 异系模型 + 1 个重型人工抽样。
• 金标准子集：评测集里专门有 200 条"金标准"，每次发布必跑。
• 灰度验证：发布前 1 小时灰度 5% 流量，对比线上指标 vs 评测预测。
• 人工审批：empirical 工程团队里，"评测全绿"不等于"可以发布"——产品 / 业务 / SRE 三方签字。

Release-triggered 评测的"对比矩阵"。发布决策不是"得分最高胜出"，而是"对比 production 的 delta 是否在阈值内"。建议发布流水线生成对比矩阵：

• 新版本 vs 当前 production：每个 cell = (新分数, 老分数, delta, 是否在阈值内)
• 红色 cell 数 > 0 → 阻塞发布
• 黄色 cell 数 > 3 → 警告 + 灰度验证
• 绿色 cell 全过 → 自动发布

CI 流水线本身的可观测性。CI 跑评测的耗时、成功率、失败原因分布，也必须被监控。CI 流水线卡在"评测超时"上的次数 > 5% 触发流水线本身的优化——评测速度影响工程师反馈周期。

CI 集成的常见反模式：

• 过度门禁：所有指标都设阈值，工程师改一行 prompt 就触发 50 个失败。门禁应是"主指标 + 约束指标"，不是"所有指标"。
• 频繁跳闸：门禁阈值设得过严，工程师形成"红线靠审批绕过"的文化。阈值应基于历史数据回测——取过去 6 个月生产版本的 95 分位数作为合理阈值。
• 忽略延迟：评测报告 2 小时后才出，工程师早就合并了别的 PR。PR 评测必须异步（10-30 分钟内出），主干评测可以同步。

七、评测召回率与盲区发现：failure taxonomy + 主动学习式探索

评测体系最大的隐患，不是"评测不够准"，而是"评测没覆盖"。Golden Set 永远只是 query 分布的子集，遗漏的部分就是评测盲区。盲区里发生的失败，评测报告不会告诉你——你必须主动去找。

**Failure Taxonomy（失败分类法）**是盲区发现的核心工具。每一类失败必须有清晰的定义 + 例子 + 修复路径。一个标准的 AI 应用 failure taxonomy 包含：

• F1 — 事实错误：回答断言与事实不符。根因：模型幻觉 / 检索错误 / 上下文截断。
• F2 — 引用错误：引用归因不对。根因：chunk 切分粒度错 / 答案与引用未对齐。
• F3 — 拒答：用户问应当回答的问题，模型拒绝。根因：安全过滤过严 / 检索无结果。
• F4 — 答非所问：模型答到了相关领域但没切题。根因：query 理解错 / 检索 query 改写错。
• F5 — 工具调用错：Agent 选了错误的工具 / 参数错误 / 工具时序错。根因：tool schema 描述不清 / 工具太多 / 上下文窗口满。
• F6 — 死循环：Agent 重复调用同工具 / 自我对话循环。根因：终止条件没设计 / 记忆状态错误。
• F7 — 风格违和：回答语气 / 格式 / 长度不符合产品调性。根因：prompt 风格化指令弱 / few-shot 例子不够。
• F8 — 隐私泄露：回答中包含不应出现的 PII / 内部信息。根因：检索混入敏感文档 / 模型记忆了训练数据。
• F9 — 延迟过高：单次回答 > 5s。根因：推理链过长 / 检索慢 / 上下文太大。
• F10 — 成本失控：单次 token 消耗 > 5 倍预算。根因：prompt 过长 / 上下文失控 / 循环调用。

这是一个 10 类的范本，每个 AI 应用应根据业务定制，比如医疗应用要加"F11 — 医疗建议不安全"。新版本发布时，评测报告必须按 failure taxonomy 分类报告失败数，不仅给总失败率。

主动学习式探索（active learning exploration）是发现盲区的高级技术。基本思路：

1. 收集生产环境 query embedding 聚类。
2. 识别出"评测集覆盖度低"的聚类（golden set 样本少 / 没有）。
3. 优先采样这些聚类，加入 golden set。
4. 每月一次。

对抗性探索（adversarial exploration）是另一面：让红队（内部或外部）专门构造"刁钻但合理的 query"，攻击评测体系。比如：

• "请用 3 句话总结 + 5 句话反驳"（结构化 prompt 攻击）
• "我刚才说的那个"（上下文依赖，长对话里这种 query 极易失败）
• "解释一下 X，但不要用 Y"（否定指令，模型容易忽略）
• "假设 A 是真的"（反事实假设，模型容易顺着假设撒谎）

每个对抗探针必须被纳入 golden set，并标记为"adversarial"。对抗集占比 ≥ 10% 才有意义。

生产流量聚类 + 异常发现。每周跑一次 KMeans / DBSCAN 把生产 query embedding 聚类，与 golden set 聚类做 difference set——这些是"生产有但评测没有"的 query。每月从 difference set 抽 100 条由产品经理 / 标注员 review，按"是否应该覆盖"加入 golden set。

评测召回率的度量。评测召回率（eval recall）= 评测集能否复现生产失败。这个指标本身很难直接测，但可以间接估计：

• 历史对齐率：过去 3 个月里，评测集说"绿"的版本里，线上事故率多少？如果评测集绿的版本上线后事故率 > 5%，说明评测召回率不足。
• 失败溯源：每个线上事故，反查"为什么评测没发现"。90% 的事故如果归因到 golden set 缺失，那评测召回率就是核心问题。

评测盲区的可视化。dashboard 上展示一张"评测覆盖率热力图"：

• 横轴：query 意图分类
• 纵轴：难度等级
• 单元格：评测集样本数（颜色深浅）
• 红色边界：覆盖 < 50 条的 cell 标红

这张图让所有人一眼看到评测盲区。覆盖率低于 50 条的所有 cell 必须每月 review 一次，决定补数据 or 标记为"业务边界外"。

评测盲区的"灰色地带"。有时候评测集覆盖到了，但分布变了。比如意图分类从 80% 归一变成 60% 归一（query 多样性增加），评测集样本绝对数量没变但相对覆盖度下降。评测集必须与生产分布做对齐测试——每月一次的 KL 散度 / Jensen-Shannon 距离计算，超过阈值 0.1 触发对齐 review。

八、给 SRE / Agent 平台 / 应用的工程清单（22 条）

把全文的工程实践汇总为 22 条可执行清单，按"角色 × 阶段"分组。

PRD 阶段：

1. 在 PRD 里明确列出 AI 应用主指标（≥ 1 个）和约束指标（≥ 3 个），含数值阈值。
2. 为每条主指标定义 fallback 行为：当指标无法计算时（如 Judge 不可用），系统如何降级。
3. 评测集构建成本（人月）和持续维护成本（月度）写进 PRD 资源章节。

Golden Set 阶段： 4. Golden Set 至少包含 4 个来源：生产流量、用户反馈、红队、合成（5-15% 比例）。 5. 每个 query 意图 cell 至少 50 条；每个难度档位至少 100 条；对抗集至少 200 条。 6. 标注 Cohen's Kappa ≥ 0.85 是合格门槛；每月抽样 5% 重 review。 7. Golden Set 在 git 里 read-only 分支管理，任何改动 PR + 至少 1 reviewer。

指标 / Judge 阶段： 8. 评测指标分 L1 主指标 + L2 约束指标 + L3 分维度 + L4 失败样本四层结构。 9. Judge 模型选异系、能力显著高于被评系统；Judge prompt 严格 atomic 维度。 10. 位置偏置 + 长度偏置 + 自我偏好必须验证；对抗集 ≥ 100 条检验 Judge 鲁棒性。 11. Judge 单次成本 ≤ 完整评测总预算 30%；Judge 结果 TTL 7 天 + 缓存。

CI 阶段： 12. PR 门禁 = 200 条快速 subset + 异步执行 + delta 对比；critical 失败阻塞。 13. 主干门禁 = 完整评测 + Pareto 曲线 + 自动 rollback 红线。 14. 发布门禁 = 多 Judge 投票 + 金标准子集 + 灰度 1 小时 + 三方签字。 15. CI 流水线本身可观测：超时率 > 5% 触发流水线优化。

运营阶段： 16. Failure Taxonomy 至少 10 类；评测报告按 taxonomy 分类报告失败。 17. 评测覆盖率热力图每月 review；覆盖率 < 50 条的 cell 标红。 18. 生产流量聚类每周一次；与 golden set 对齐 KL 散度 > 0.1 触发对齐。 19. 每月主动学习式探索，发现评测盲区并补充。 20. 红队 / 对抗探针每月新增 20 条；对抗集占比 ≥ 10%。

Meta 阶段： 21. Judge 的 Judge：金标准 200 条监督 Judge 准确率 ≥ 90%、Pearson ≥ 0.85。 22. 评测体系本身有 changelog：指标权重、阈值、judge prompt 改动必须 git tag + 团队周会评审。

这 22 条不是"全做才算合格"，而是分阶段实施——MVP 阶段至少做到 1/4/8/13/16 五条，规模化阶段补齐 5/9/12/19，对外 SLA 阶段补齐全部 22 条。

九、讨论：评测体系的代价 vs 收益、AI 应用评测的未解之谜

离线评测体系不是免费的。它的工程成本在一个中型 AI 应用团队里通常占 30-40% 的工程时间。一个真实案例：某金融 AI 应用团队（15 人研发 + 3 人标注 + 1 人 SRE），一年内投入评测体系约 4 人月工作量 + 每月 8,000 美元 LLM 调用成本。这是一笔不小的投资，但没有它，每次 prompt 改动都是一次对生产可用性的赌博——赌博失败的代价是用户投诉、退款、品牌损伤、法规风险。

这个代价 vs 收益的平衡里，一个常被忽视的维度是"评测体系本身的可调试性"。评测体系出问题（Judge 漂移、golden set 过期、指标权重错）导致 CI 误报 / 漏报，比没有评测还危险——它让团队在错误的安全感下做出错误决策。评测体系必须有自己的"评测的评测"（meta-evaluation）——这是 Hinton 团队在 2024 年一次 workshop 里强调的"AI 工程的元层"。

未来 5 年 AI 应用评测的若干未解之谜：

• 多模态评测：评测集如何覆盖图像 + 文本 + 音频的复合输入？cross-modal hallucination（回答与图像无关）如何 detect？
• 长时 Agent 评测：一个 50 步 Agent 跑 30 分钟，轨迹评估的 ground truth 怎么定义？专家标注 50 步轨迹的成本是 50 × 单步成本。
• 个性化评测：不同用户对"好回答"的偏好不同，评测集如何体现个性化？A/B 测试给出群体偏好，但个体差异没答案。
• 多语言评测：低资源语言（金 + 越 + 泰）的 golden set 成本极高，合成数据 + 翻译质量本身是个没完美答案的问题。
• 自适应评测：评测集本身应随模型能力演化——模型能解决的问题从评测集移除，模型还不能解决的问题补充进。这要求"动态 golden set"，但任何动态都会引入"AI 偏好自己的盲区"风险。
• 评测的可解释性：从"分数 0.85"到"为什么是 0.85"的可解释性，目前只能靠 LLM-as-Judge 的 rationale 输出，质量参差。
• 评测的合法合规：欧盟 AI Act 等法规要求高风险 AI 应用必须可解释、可审计、可追溯。评测报告作为合规证据的趋势越来越明显——评测体系不仅是工程工具，也是合规工具。

这些未解之谜里，最值得 2026-2027 年投入的是"自适应评测 + 多模态评测"。前者解决评测集老化的核心痛点，后者打开图像 / 视频 / 音频 AI 应用的市场空间。

最后回到工程上一句：评测体系不是"做完就完"的一次性项目，而是一个永远在演化的工程领域。它与产品同步迭代：产品变 → query 分布变 → 评测集变 → 指标变 → 评测方法变。把评测体系当产品做，而不是当测试做——这是 AI 应用工程化与传统软件工程最大的区别。传统软件测试是"验证代码做了它声明的事"，AI 应用评测是"验证产品在变化的世界里持续做对的事"。前者是声明式，后者是演化式。

参考文献

1. Chang, Y., et al. A Survey on Evaluation of Large Language Models. arXiv:2307.03109, 2024.
2. Zheng, L., et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023.
3. Karp, R. M. On the Computational Complexity of Evaluation. STOC 1975.
4. Kotonya, N., et al. Evaluating the Evaluators: A Framework for Open-Ended Evaluation. ACL 2024.
5. Jacovi, A., et al. A Comprehensive Evaluation of Pitfalls in Clinical LLM Evaluation. Nature Medicine, 2024.
6. Liu, Y., et al. G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. ICLR 2024.
7. Wang, S., et al. LLM-as-Judge Calibration: Position Bias Correction Methods. EMNLP 2024.
8. Gehrmann, S., et al. Repairing the Cracked Foundation: A Survey of Obfuscations and Vulnerabilities in LLM Evaluations. TACL 2024.
9. Chen, J., et al. Evaluation Beyond Benchmarks: Real-World LLM Applications in Production. KDD 2024.
10. Brown, T., et al. Pareto-Optimal Multi-Objective LLM Evaluation. FAccT 2024.
11. Davis, J., et al. Continuous Evaluation for Production LLM Systems. SREcon 2024.
12. Anthropic Engineering. Constitutional AI Evaluation Methodology. Technical Report, 2024.
13. OpenAI Platform Team. GPT-4 as a Judge: Best Practices and Pitfalls. OpenAI Cookbook, 2024.
14. National Institute of Standards and Technology. AI Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023.

一句话摘要：AI 应用的离线评测体系是把"上线前已知风险"显式化的工程闭环——它由四元组 (task, input, expected, rubric) 形式化的评测合约、由 4 来源 + 分层抽样 + 标注一致性治理的 golden set、由多维度耦合 + 主指标 + 约束指标设计的指标体系、由 LLM-as-Judge + 位置 / 长度 / 自我偏好校正驱动的评判器、由 L1 PR + L2 主干 + L3 发布三档门禁的 CI 流水线、以及由 failure taxonomy + 主动学习 + 对抗探索的盲区发现机制共同构成，最终在 meta-evaluation（评测的评测）里回答"我们的评测本身可不可信"——这是 AI 应用从 MVP 到规模化不可绕开的工程基础设施。