AI Evaluation Pipeline：四种评估闭环

比较离线回归、Shadow、在线实验与 Production Feedback 四种 evaluation topology：每种回答什么问题、要多少样本才看得出差异（带误差范围的算例）、LLM judge 的已知偏差怎么校准、版本和 join key 怎么记，以及回归门禁、影子流量和用户反馈各自怎样出错、怎么恢复。

一个 eval score 不能代表 production quality。上线前需要可复现的离线回归，上线时需要不影响用户的 shadow 观察，变更决策需要受控实验，上线后还要把真实 failure 变成新的测试样本。

每一种闭环都要回答三个问题：这个分数回答的是什么问题；分差多大才不是噪声；分数背后的数据和评分器是哪个版本。 第二个问题最常被跳过：500 道题上 81% 对 79%，很可能什么都说明不了（下文有算例）。

四种 AI evaluation pipeline 架构

有约束的设计问题

一个客服助手要换一版 prompt 和一个更便宜的模型。团队要回答四件事：新版本有没有把已知能处理好的问题搞坏；在真实流量上会不会冒出离线集里没有的失败；用户的问题解决率到底有没有变好；上线后用户点踩的那些对话，怎样变成下一次改版前的测试。每一件事该用哪种闭环？

四种闭环

架构	数据路径	State owner	回答的问题	风险
Offline Regression	versioned dataset → candidate → graders → report	dataset + run manifest	新版本是否破坏已知能力	数据集过拟合、泄漏
Shadow Evaluation	live copy → candidate → compare，结果不返回用户	shadow log	真实流量上会怎样	隐私和双倍推理成本
Online Experiment	assignment → A/B → outcome join	experiment assignment	用户结果是否改善	干扰、样本偏差、错误指标
Feedback Flywheel	production trace → triage → labelled case → dataset	governed case store	新 failure 怎样进入下一轮	错误反馈污染数据集

版本和 join key

每次 run 记录 dataset revision、prompt revision、model snapshot、tool schema、grader revision 和 random seed（若适用）。Online experiment 的 assignment 必须稳定，outcome 通过同一个 experiment/user/request key 回连。用户反馈不能直接进入训练或 golden set，必须经过去敏、去重和审核。

一份 run manifest 可以长这样：

{
  "run_id": "eval_2026_09_22_0412",
  "dataset": "support-regression@v37",
  "candidate": { "prompt": "support-system@r58", "model": "<model-snapshot-id>", "tools": "support-tools@v12" },
  "baseline_run_id": "eval_2026_09_15_1180",
  "graders": ["exact_policy_match@v4", "llm_judge_helpfulness@v9"],
  "samples_per_case": 3,
  "seed": 1234
}

少记任何一项，两次 run 的分差就说不清是哪个变量带来的。grader 也要版本化：换了 judge 的 prompt，分数可能整体移动，这不是被测系统变了。

1. Offline Regression：固定数据集上和基线逐题比较

候选版本在一份版本化的数据集上跑，评分器打分，和基线 run 比较。OpenAI 的 evaluation best practices 列出的流程是：定义目标、收集数据、定义指标、运行比较、持续评估；并把「靠感觉」（vibe-based evals）和数据集不反映生产流量列为反模式。Anthropic 的文档建议 eval 要贴合真实任务分布、尽量自动评分，并且「更多题目配略低信号的自动评分，好过更少题目配高质量人工评分」。

分差多大才算数。 Anthropic 的研究文章和对应论文（Evan Miller，Adding Error Bars to Evals）给了五条建议：用中心极限定理报告均值的标准误（SEM）和 95% 置信区间（均值 ± 1.96 × SEM）；题目成组相关时用聚类标准误，文章说在流行 eval 上聚类标准误可能是朴素标准误的三倍以上；对同一题多次采样来降低题内方差；比较两个模型时分析配对差值；用功效分析决定题目数量。

算一下：通过率 80%、500 道独立题目，

$$ SEM = \sqrt{\frac{0.8 \times 0.2}{500}} \approx 0.018 $$

95% 置信区间约 ±3.5 个百分点。如果两次 run 当成独立样本比较，差值的标准误约 0.018 × √2 ≈ 0.025，置信区间约 ±5 个百分点，81% 对 79% 落在噪声里。同一批题目上的配对比较把两边都答对或都答错的题抵消掉，差值方差更小，这是论文建议配对分析的原因。500 道题里如果有 50 篇文档、每篇 10 道题，要按文档聚类算标准误，否则会高估精度。

门禁规则。 一个可执行的例子（阈值为假设）：候选相对基线的配对差值，95% 置信区间下界低于 -2 个百分点就阻止发布；另有一组「必须通过」的用例（安全拒答、合规话术），任何一条失败都阻止发布，不参与平均。

防止过拟合。 反复针对同一份集合改 prompt，分数会上去但泛化不会。留一份不参与调优的 held-out 集，只在发布前跑；集合里的题不要出现在 prompt 的 few-shot 示例里。

2. Shadow Evaluation：复制真实流量给候选，结果不返回用户

线上请求照常由当前版本处理并返回；同时把一部分请求复制给候选版本，候选的输出只记日志，不给用户看。之后用评分器或人工对比两边的输出。

它回答离线集回答不了的问题：真实输入的长度分布、语言混杂、奇怪的工具返回，在候选上会怎样。代价是推理成本和隐私：复制 5% 的流量（假设），推理成本就多 5%；影子日志里是真实用户数据，保留期和访问权限要和生产日志一样管。候选有副作用的工具调用（下单、发邮件）在影子里必须替换成 stub，否则一次请求会执行两遍。

3. Online Experiment：随机分组，比较用户结果

把用户按稳定的哈希分组，例如 hash(experiment_id, user_id) mod 100 < 50 进实验组，同一个用户每次都落在同一组。实验组用新版本，对照组用旧版本，结果指标（问题解决率、转人工率、用户评分）按同一个 experiment / user / request key 回连到分组。

要多少样本。 二元指标、双侧 α = 0.05、功效 80% 时，每组样本量的常用近似是

$$ n \approx \frac{16 \times p(1-p)}{\delta^2} $$

问题解决率基线 p = 30%，想检测 1 个百分点的提升：16 × 0.21 / 0.0001 ≈ 33,600 个样本每组；检测 2 个百分点约 8,400 每组。每天只有 2000 次对话的产品，1 个百分点的差异需要跑一个多月，这时要么接受只检测更大的差异，要么把门禁更多地放在离线回归上。

常见的错：按请求而不是按用户分组，同一个人在两个版本之间来回切，体验和指标都被污染；中途偷看结果、显著了就停，假阳性率会远高于 5%；只看模型侧的分数，不看用户侧的结果。

4. Feedback Flywheel：把生产中的失败变成下一轮的测试

生产 trace（输入、工具调用、输出、用户反馈）进入分拣队列；人工或规则判断是不是真实失败、属于哪一类；确认的失败去敏、去重，写上期望行为，作为新用例进入受治理的用例库；下一次发布前，这些用例进入离线回归集。

用户的点踩不等于错误：有人因为答案对但不是他想听的而点踩，有人手滑。直接把反馈当标签灌进 golden set，数据集会被噪声和个人偏好污染；如果含有个人信息，还会把 PII 带进长期保存的测试集。所以中间必须有审核这一步，用例库要有来源、审核人和版本。

LLM judge 要先校准

用模型给开放式回答打分便宜、可扩展，但有已知偏差。Zheng 等人的论文（Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena）研究了位置偏差、冗长偏差、自我偏好偏差和有限的推理能力，同时发现强模型作为 judge 与人类偏好的一致率超过 80%，和人类之间的一致率相当。OpenAI 的 best practices 同样列出位置偏差和冗长偏差，建议用成对比较或 pass/fail 提高可靠性，并在优化成本之前先对照人工标注验证 judge 的一致性。

落到流水线里：成对比较时交换两个回答的顺序各评一次，不一致就判平局或送人工；控制长度，或在评分标准里明确不按长度加分；拿一两百条人工标注的样本（数量为假设）定期测 judge 与人工的一致率，judge 的 prompt 或模型一换就重测。Google Vertex AI 的评估服务提供按每条 prompt 生成 pass/fail 细则（adaptive rubrics）的方式，也是把开放式评分变成可检查条目的一种做法。

故障与恢复

架构	故障	用户看到什么	恢复
Offline	分数升了 2 个点就发布，实际是噪声	上线后质量没变或变差	报告置信区间，配对比较，门禁按区间下界判断
Offline	反复在同一份集合上调 prompt	离线分数很高，线上投诉增加	held-out 集只在发布前跑；定期从生产补充新用例
Offline	换了 judge prompt 没记版本	所有版本分数一起移动，趋势图断层	grader 版本进 manifest；换 grader 时在同一批数据上重跑基线
Shadow	候选的工具调用没有 stub	用户收到两封邮件、下了两单	影子环境里所有有副作用的工具替换为 stub
Shadow	影子日志保留过久、权限过宽	隐私事故	与生产日志同等的保留期、脱敏和访问控制
Online	按请求分组	同一用户体验忽好忽坏，指标失真	按用户（或会话）稳定哈希分组
Online	中途看到显著就停止实验	假阳性上线	事先定样本量和时长；或使用为连续监测设计的检验方法
Feedback	点踩直接进 golden set	数据集被噪声污染，门禁失效	分拣、去敏、去重、人工审核后再入库
Judge	冗长偏差	越来越啰嗦的版本分数越来越高	控制长度；对照人工标注测一致率

怎么选

每次改 prompt、模型、工具 schema 都要跑：Offline Regression，配对比较 + 置信区间 + 必须通过用例。
离线集覆盖不到真实输入分布，又不能冒险让用户看到候选：Shadow Evaluation，副作用 stub，控制采样比例。
要证明的是用户侧的结果变化，且流量足够：Online Experiment，按用户稳定分组，事先算样本量。
上线后持续有新的失败类型：Feedback Flywheel，审核后入库，进入下一轮离线回归。
四种不是互斥的，是一条链：离线门禁挡住明显回归，影子看真实分布，实验验证用户结果，反馈把新失败送回离线集。

回到开头的客服助手：换 prompt 和模型先过离线回归门禁；再用 5% 影子流量看真实输入上的差异；流量够的话做按用户分组的实验，看解决率和转人工率；上线后点踩的对话经过审核进入下一版的回归集。

面试时这样回答

复述约束：要改的是什么（prompt、模型、工具）、有多少流量、用户侧的结果指标是什么、有没有不能出错的用例。
点名数据路径：版本化数据集 → 候选 → 评分器 → 和基线配对比较 → 门禁；生产 trace → 分拣 → 审核后的用例 → 回到数据集。
说清状态归谁：数据集和 run manifest 是离线的权威记录；实验分组表决定结果怎么回连；用例库有审核记录，反馈本身不是标签。
说一个代价和一个故障：例如 500 道题的置信区间约 ±3.5 个百分点，想检测更小的差异要更多题目或配对分析；故障选「用户点踩直接进 golden set」，修法是分拣和审核。