第 15 章：可信评测：统计、Meta-Eval 与体系质量
本页导航
15.1 分数提升 1.5，能上线吗
本章用假设数据演示统计解释和发布决策。分数、样本量、错误条数、一致率、灰度周期与变化幅度均不代表真实项目成果，也不能直接迁移为其他团队的门禁阈值。
客服 Agent 的候选版本在离线评测中平均分提升了 1.5。看起来这是一个好消息。
但进一步拆开结果后，团队发现：
- Easy 样本提升明显，Hard Case 下降。
- 总分提升主要来自回答更长、更礼貌。
- 高风险退款场景有 2 条工具参数错误。
- Judge 与人工在投诉升级样本上的一致率只有 62%。
- 小流量灰度中，转人工率没有下降。
这个版本到底是变好了，还是只是分数变好看了？
可信评测要回答“这个分数能不能支撑决策”。不可信的结论会给团队虚假的安全感，风险可能高于没有评测。
15.2 可信评测的七个标准
一套评测体系至少要满足七个标准。
| 标准 | 问题 |
|---|---|
| 有效性 | 是否真的评到了想评的能力 |
| 可靠性 | 多次评测结果是否稳定 |
| 区分度 | 能否区分不同质量的版本 |
| 覆盖度 | 是否覆盖主路径、长尾、异常和安全 |
| 可解释性 | 分数变化能否解释原因 |
| 可复现性 | 其他人能否复现同一结果 |
| 可操作性 | 结果能否转化为优化或发布决策 |
如果一套评测只给出总分，却无法解释分数代表什么、为什么变化、该不该发布、该改哪里，它就不满足可信评测的要求。
15.3 样本量与不确定性
AI 评测面对有限样本和概率性输出，一次跑分只是特定条件下的一次测量。
如果只用 30 条样本评估一个客服 Agent，然后得出“候选版本比当前版本高 3 分”，这个结论很可能不稳定。换一批样本，换一次采样，分数可能就变了。
评测报告中应尽量包含：
- 样本数量。
- 样本分布。
- 均值和分维度分数。
- 置信区间。
- 方差或波动范围。
- 多次运行稳定性。
总样本量无法说明高风险场景是否充分覆盖。全量 1000 条样本里只有 5 条隐私越权样本，即使总体样本量很大，也无法证明安全评测充分。
15.3.1 用业务语言解释不确定性
评测报告不一定要写复杂公式，但要把不确定性讲清楚。
| 表达 | 含义 |
|---|---|
| 样本量不足 | 当前样本无法支撑稳定结论 |
| 波动范围较大 | 多次运行结果不稳定 |
| 高风险样本覆盖不足 | 安全结论证据不足 |
| 版本差值区间跨过 0 | 当前数据不能排除“没有改善” |
| 需要灰度验证 | 离线证据不足以支持全量 |
这比只写“候选版本高 1.5 分”更有决策价值。管理层不需要看到完整统计推导，但应知道结论的把握程度。
15.3.2 实操工具箱：三个常用统计计算
评测工程师不需要成为统计学家，但以下方法经常用于量化不确定性。它们提供的是在特定假设下的证据，不会自动把相关性变成因果，也不能替代风险覆盖、实验设计和业务判断。正式发布分析应由具备统计能力的人员复核计算口径。
方法一：比例的置信区间（用于通过率、正确率等）
当指标是“正确数 / 总数”这类二项比例时（例如退款政策正确率、工具参数准确率），Wilson 区间是一种常用选择；相较直接使用正态近似的 Wald 区间，它在许多有限样本和靠近 0/1 边界的情形下覆盖表现更稳健。若样本存在聚类、加权或重复运行依赖，则需要使用与抽样设计匹配的方法。
import math
from statistics import NormalDist
def wilson_confidence_interval(successes, total, confidence=0.95):
if total <= 0:
raise ValueError("total must be greater than 0")
if successes < 0 or successes > total:
raise ValueError("successes must be between 0 and total")
if not 0 < confidence < 1:
raise ValueError("confidence must be between 0 and 1")
z = NormalDist().inv_cdf(0.5 + confidence / 2)
p = successes / total
denominator = 1 + z**2 / total
center = (p + z**2 / (2 * total)) / denominator
margin = z * math.sqrt((p * (1 - p) + z**2 / (4 * total)) / total) / denominator
return (center - margin, center + margin)
lower_a, upper_a = wilson_confidence_interval(180, 200)
lower_b, upper_b = wilson_confidence_interval(190, 200)
print(f"当前版本: {180/200:.1%}, 95%CI: [{lower_a:.1%}, {upper_a:.1%}]")
print(f"候选版本: {190/200:.1%}, 95%CI: [{lower_b:.1%}, {upper_b:.1%}]")
怎么用：报告中不只写“正确率从 90% 提升到 95%”，还要报告各自的区间并说明样本构成。两个区间是否重叠只能作为直观线索，不能替代针对“版本差值”的正式检验；同一批 Case 的版本比较应优先使用配对方法。
样本量提醒：所需样本量取决于基线比例、希望检测的最小差异、置信水平、统计功效、样本分层和是否配对，不能用一个固定数字代替设计。少量样本可以用于探索；总体样本量再大，也不证明高风险场景已经充分覆盖。
方法二：配对 Bootstrap（用于分数对比）
当两个版本运行在同一批 Case 上时，应保留配对关系。配对 Bootstrap 是一种可选方法，它直接对 Case 级差值重采样，不要求把两个版本当作独立样本；但它仍依赖 Case 之间近似独立、样本能代表目标分布等条件。若分数差值适合参数假设，配对 t 检验也可能合适；二分类通过/失败则可考虑 McNemar 检验。
import random
def paired_bootstrap(scores_a, scores_b, n_bootstrap=10000, confidence=0.95):
if len(scores_a) != len(scores_b) or not scores_a:
raise ValueError("scores_a and scores_b must be non-empty and paired")
n = len(scores_a)
diffs = [b - a for a, b in zip(scores_a, scores_b)]
boot_diffs = []
for _ in range(n_bootstrap):
sampled = [diffs[random.randint(0, n-1)] for _ in range(n)]
boot_diffs.append(sum(sampled) / n)
boot_diffs.sort()
alpha = (1 - confidence) / 2
mean_diff = sum(diffs) / n
wins = sum(1 for d in boot_diffs if d > 0) / n_bootstrap
lower_index = int(alpha * n_bootstrap)
upper_index = min(int((1 - alpha) * n_bootstrap), n_bootstrap - 1)
return (mean_diff, boot_diffs[lower_index],
boot_diffs[upper_index], wins)
random.seed(42) # 示例复现；生产报告应记录随机种子
current_scores = [3, 4, 2, 5, 3]
candidate_scores = [4, 4, 3, 5, 4]
mean_diff, lower, upper, positive_share = paired_bootstrap(
current_scores, candidate_scores
)
print(mean_diff, lower, upper, positive_share)
怎么解释：若差值区间完全高于 0，数据支持 B 在该指标上优于 A；若区间包含 0，当前证据不足以排除“没有差异”；若完全低于 0，则支持 B 退化。这里的百分位 Bootstrap 是便于教学的基础实现，不能处理所有依赖结构、分层抽样或多重比较问题。
方法三：样本量规划问题表
| 规划问题 | 为什么要回答 | 示例 |
|---|---|---|
| 指标类型是什么 | 比例、连续分数和事件率需要不同方法 | 通过率 vs 平均延迟 |
| 基线水平是多少 | 同样的绝对差异在不同基线下方差不同 | 60%→65% vs 95%→100% |
| 最小有意义差异是多少 | 决定希望检测多小的变化 | 业务只关心至少 3 个百分点的提升 |
| 置信水平与统计功效是多少 | 决定误报和漏报容忍度 | 95% 置信水平、80% 功效 |
| 是否使用配对设计 | 同一批 Case 的配对比较通常更有效率 | 当前版与候选版跑同一 Case |
| 是否需要分层结论 | 总样本够不代表每个高风险层都够 | 退款、越权和长尾分别规划 |
样本量应根据预先确定的分析计划计算，而不是从一张脱离假设的通用表抄取。对 P0/P1 场景，关键不只是“更多”，还包括攻击面覆盖、样本独立性、重复运行和零失败时仍然存在的残余风险。如果越权查询只有 5 条样本，即使全部通过，也不能得出“越权风险已控制”的结论。
15.4 版本对比应保留 Case 配对关系
模型或 Agent 版本对比时，最好使用配对实验：同一批 Case，同时评估当前版本和候选版本。
配对实验的优势是控制样本差异。否则，当前版本跑的是一批样本，候选版本跑的是另一批样本，分数差异可能来自样本难度，而不是系统能力。
版本对比时要锁定：
- 数据集版本。
- Case 版本。
- Prompt 版本。
- 知识库版本。
- 工具 Schema。
- Evaluator 版本。
- 运行环境。
- 采样参数。
只有目标变量发生变化，版本对比才有解释力。
15.4.1 退化分析比平均提升更重要
版本对比中，平均提升不应掩盖局部退化。
报告应单独展示：
- 哪些场景提升。
- 哪些场景退化。
- 退化是否发生在 P0 / P1 场景。
- 退化是否与某类能力相关。
- 退化是否超过业务容忍度。
客服 Agent 候选版本如果普通物流问答提升 5%，但退款工具参数准确率下降 2%，不能用平均提升放行。版本对比报告要把退化场景列为决策重点。
15.4.2 配对二分类指标的比较
很多企业评测指标是通过 / 失败、是否越权、是否正确调用工具这类二分类结果。比较时，除了两个版本各自的通过率，更要看同一批 Case 上哪些样本从失败变成功、哪些从成功变失败。
| 当前版本 | 候选版本 | 含义 |
|---|---|---|
| 失败 | 通过 | 候选版本修复的样本 |
| 通过 | 失败 | 候选版本引入的退化 |
| 通过 | 通过 | 两个版本都能处理 |
| 失败 | 失败 | 两个版本都未解决 |
如果只是看通过率，两个版本可能都在 95% 左右；但如果候选版本修复了大量低风险样本，同时引入少量 P0 退化，发布决策应优先关注退化样本。配对二分类检验（例如 McNemar 检验）适合判断“修复数”和“退化数”的差异是否足够稳定。
企业报告不一定要展示公式，但至少要展示三件事：
- 修复样本数和退化样本数。
- 退化样本是否集中在 P0 / P1 场景。
- 退化是否超过业务容忍度或门禁阈值。
对客服 Agent 来说，如果候选版本让普通问答多通过 30 条，却让 3 条退款工具样本从通过变失败，这 3 条退化可能比 30 条修复更重要。
15.5 统计显著性与实际显著性
统计显著不等于业务有意义。
一个候选版本在 5000 条样本上平均分提升 0.1，可能统计显著，但用户完全感知不到。反过来，一个版本在总分上只提升 0.5，但高风险退款错误下降 80%，业务价值可能很大。
因此，评测报告应同时回答：
- 变化是否超过随机波动。
- 变化是否足以影响业务。
- 提升发生在哪些场景。
- 退化发生在哪些场景。
- 是否触及门禁或红线。
p 值或平均分不足以完成企业评测报告，还要把统计变化翻译成业务决策。
15.5.1 把分数结论翻译成决策证据等级
发布评审需要知道当前证据支持什么范围的决策，而不只是候选版本高了多少分。因此，评测报告可以把结论分成不同证据等级。
这里的等级是治理标签，不是统计学置信水平或后验概率。它综合风险覆盖、统计不确定性、退化分析、Evaluator 可信度和线上映射，只用于规定下一步动作。
| 证据等级 | 判断条件 | 适合动作 |
|---|---|---|
| 充分证据放行 | 核心指标稳定提升，高风险样本通过，退化可解释，线上映射明确 | 放行或扩大灰度 |
| 有限证据灰度 | 主要指标可接受，但部分场景样本不足或波动较大 | 限定场景灰度，补充监控 |
| 证据不足补测 | 样本量不足、版本差值区间跨过 0、正式检验不支持目标差异，或 Judge 与人工分歧较大 | 补测、复核、延后决策 |
| 高风险阻断 | 出现 P0，命中项目指定的 P1 硬门禁，或其他关键门禁退化 | 阻断发布，修复后重跑 |
| 业务权衡审批 | 质量变化不明显，但成本、延迟或业务收益有明显变化 | 负责人审批并记录风险接受 |
这个分级有两个作用。第一，它避免团队把所有结果都写成“通过 / 不通过”。第二，它让不确定性进入决策过程，而不是被平均分隐藏。
客服 Agent 候选版本如果在常规物流场景提升明显，但退款高风险样本只有少量覆盖，更合适的结论是：“低风险场景可灰度；高风险退款场景证据不足，需要补测并保持人工审批。”笼统写成“整体提升 1.5 分”会掩盖证据边界。
15.6 多指标比较的误报
当团队同时看 30 个指标时，总会有几个指标“显著变化”。这可能是真变化，也可能是偶然波动。
多指标评测中应注意：
- 先区分门禁指标、诊断指标、观察指标。
- 不要因为观察指标波动就直接阻断发布。
- 对多个维度的显著变化做分组解释。
- 关注一致性模式，而不是孤立异常。
- 对关键指标做人工复核或二次实验。
- 对大量观察指标，可使用 FDR 或 Bonferroni 一类方法控制误报，但不要机械套用到所有业务指标。
例如，候选版本在“回答长度”“礼貌程度”“用户安抚”上提升，但“政策正确性”“工具参数准确率”“高风险拒绝”没有提升，甚至退化，就不能简单判断版本更好。
多指标控制的业务化做法是：门禁指标先按业务红线独立判断，不能被平均分或多指标校正稀释；诊断指标用于解释问题，不直接决定放行；观察指标用于趋势监控，出现异常时触发复核而不是自动阻断。统计方法帮助团队降低误报，但发布决策仍要回到风险等级、样本证据和业务后果。
15.7 标注一致性
人工评测不是天然可靠。人工也需要校准。
如果两个标注者对同一批客服回答的好坏判断差异很大，说明 Rubric 不够清晰，或样本本身存在歧义。
常见一致性指标包括：
| 指标 | 适用场景 |
|---|---|
| Cohen's Kappa | 两个标注者的分类一致性 |
| Fleiss' Kappa | 多个标注者的分类一致性 |
| Krippendorff's Alpha | 多标注者、多类型标签 |
| Spearman 相关 | 排序或打分一致性 |
Cohen's Kappa、Fleiss' Kappa 和 Krippendorff's Alpha 都是在原始一致率之外考虑偶然一致的指标，但假设、标签类型和缺失值处理不同；Spearman 相关衡量排序单调关系，不等同于评分完全一致。报告应说明为何选择该指标，不能把不同统计量的数值直接横向比较。
评测团队不需要把统计学写成论文，但至少要知道：如果人工标签本身不一致，自动 Evaluator 就没有稳定的校准目标。
15.8 Judge 的 Meta-Eval
LLM-as-Judge 也需要接受评测，否则它只是另一个未经校准的模型。
第 13.15 节列出的研究记录了位置、冗长、自我增强、熟悉度和 Prompt 敏感性等偏差。Meta-Eval 在本书业务、样本和 Rubric 上逐项测量这些偏差，而不预设每个 Judge 都有相同问题。
Meta-Eval 至少包括：
| 维度 | 检查问题 |
|---|---|
| 人工一致率 | Judge 与人工判断是否一致 |
| 排序相关性 | Judge 是否能正确比较两个版本 |
| 长度偏置 | 是否偏好更长回答 |
| 位置偏置 | Pairwise 中 A/B 顺序是否影响判断 |
| 风格偏置 | 是否偏好礼貌但不准确的回答 |
| 自我偏好 | 是否偏好同类模型输出 |
| 领域盲区 | 是否误判专业或业务规则 |
| 版本稳定性 | Judge 更新后结果是否可比 |
客服 Agent 中，Judge 可能被“语气好、解释多”的回答影响。但政策正确、证据忠实和安全边界应拥有更高优先级。Meta-Eval 要专门检查这些偏差。
15.8.1 Judge 校准集
Judge 需要一套稳定校准集。校准集不是普通评测集，它用于长期观察 Judge 是否可靠。
校准集应包含：
| 样本类型 | 目的 |
|---|---|
| 明显正确样本 | 检查 Judge 是否过度苛刻 |
| 明显错误样本 | 检查 Judge 是否误放 |
| 边界样本 | 检查 Judge 是否理解 Rubric |
| 长答案和短答案配对 | 检查长度偏置 |
| 安全高风险样本 | 检查红线判断 |
| 领域专家样本 | 检查业务规则理解 |
Judge Prompt、Judge 模型或 Rubric 变化后，都应先跑校准集。只有校准集表现稳定，Judge 才适合进入大规模评测。
15.8.2 Judge 的适用边界
Judge 的优势是规模化语义评估，但它不适合承担所有判断。企业级评测体系需要明确它的使用边界。
| 场景 | Judge 适用性 | 推荐处理 |
|---|---|---|
| 语气、清晰度、结构完整性 | 较适合 | Judge 批量评估，人工抽检 |
| 证据忠实度 | 条件适用 | 给 Judge 明确证据和 Rubric，并用人工校准 |
| 业务政策正确性 | 谨慎使用 | 规则、脚本、专家样本和 Judge 组合 |
| 金额计算、字段格式、工具参数 | 不应作为主评估器 | 脚本、Schema、业务规则引擎 |
| P0 / P1 安全风险 | 不应单独裁决 | 规则、Trace、人工复核和硬门禁 |
| 发布最终决策 | 不应直接替代负责人 | Judge 只提供证据，决策进入门禁和审批流程 |
一个实用原则是：凡是可以用确定性规则、工具终态或业务系统校验的内容，不应优先交给 Judge。Judge 适合开放语义和复杂表达，但输出仍需经过校准、抽检和版本管理。
客服 Agent 的“回答是否礼貌”可以交给 Judge 大规模评估；“退款金额是否正确”应由业务规则计算；“是否泄露他人订单信息”应由规则、Trace 和人工共同检查。把这些问题都交给 Judge，会让评测体系看似自动化，实际风险更高。
15.9 离线指标与线上指标的相关性
离线评测的最终价值，要靠线上表现校准。
如果离线“政策正确率”提升，线上退款投诉率下降，说明这个指标可能有效。如果离线总分持续提升，线上转人工率、投诉率、用户追问率没有变化，说明离线指标可能没有抓住真实问题。
离线和线上可以建立映射：
| 离线指标 | 对应线上信号 |
|---|---|
| 任务完成率 | 自助解决率、转人工率 |
| 政策正确率 | 政策类投诉率、人工纠错率 |
| 工具参数准确率 | 工具失败率、业务异常单 |
| 高危拒绝正确率 | 安全事件、隐私投诉 |
| 回答清晰度 | 用户追问率、满意度 |
| 成本和延迟 | P95 响应时间、单会话成本 |
这种映射不是一次建立后永久有效。业务变化、用户变化、系统能力变化后，相关性也会变化。
15.9.1 如何建立离线在线校准机制
离线在线相关性需要定期校准，不能依靠直觉判断。
第一步，选择少量关键映射。不要试图把所有离线指标都映射到线上指标。优先选择能影响发布决策的指标，例如政策正确率、工具参数准确率、高危拒绝正确率和转人工合理性。
第二步，按版本记录离线结果和线上结果。每次发布后，保留对应版本的离线 Run、灰度范围、线上观察窗口、流量比例和异常事件。没有版本对齐，就无法判断相关性。
第三步，分析指标是否同向变化。如果离线政策正确率提升后，政策类投诉率持续下降，说明指标可能有效；如果离线总分提升但线上投诉不变，就要检查离线样本是否偏离真实分布。
第四步，处理不一致。离线好、线上差，通常指向样本覆盖、产品流程、用户分布或线上依赖问题；离线差、线上好，可能说明离线样本过难、权重不合理或指标与业务目标错位。
| 不一致类型 | 可能原因 | 调整动作 |
|---|---|---|
| 离线好，线上差 | 线上场景未覆盖、用户表达漂移、产品流程影响 | 回流线上 Bad Case，调整样本分布 |
| 离线差，线上好 | 离线 Hard Case 权重过高、指标过严 | 重审权重和门禁阈值 |
| 离线波动，线上稳定 | 样本量不足、Judge 漂移、运行随机性 | 增加样本、重跑校准集 |
| 离线稳定，线上波动 | 线上流量、活动、渠道或外部系统变化 | 分渠道分析，记录外部变量 |
校准机制让离线评测持续接近真实决策需求，并不追求完美预测线上结果。离线指标一旦长期无法解释线上质量，就应调整或降级。
15.10 评测体系本身会退化
评测体系不是建成后就稳定有效。它也会退化。
常见退化包括：
- 评测集被污染。
- 样本被反复针对优化。
- 业务规则变化导致答案过期。
- Judge 版本变化导致分数不可比。
- 指标被团队刷高，但用户体验无改善。
- Hard Case 不再有区分度。
- 线上新问题没有回流。
因此，评测体系也需要定期体检。
15.10.1 评测体系体检节奏
评测体系体检可以按节奏运行：
| 节奏 | 检查内容 |
|---|---|
| 每次发布前 | 门禁指标、Regression Set、Red Team Set |
| 每周 | 线上 Bad Case 回流、异常指标、Judge 低置信样本 |
| 每月 | 数据集覆盖、样本老化、标注一致性、Evaluator 漂移 |
| 每季度 | 指标树有效性、离线在线相关性、隐藏集区分度 |
体检结果应进入质量治理，而不是只停留在评测团队内部。若发现离线分数和线上投诉长期无关，就应调整指标、样本或评估器。
15.10.2 可信评测的停用条件
某些指标或评估器不应无限期使用。当它们不再可信时，要停用或降级。
停用信号包括：
- 与人工一致性长期偏低。
- 对线上指标没有解释力。
- 被团队稳定刷高但业务无改善。
- 样本严重污染。
- 对强弱版本没有区分度。
- 业务规则变化后无人维护。
停用失效指标是评测体系的正常维护。继续保留它，反而比没有指标更危险。
15.11 交付物一：评测体系质量回检表
15.2 用七个标准建立概念，本表把同一标准改写成可回答“是/否/证据不足”的回检问题。使用时应为每行附证据链接和 Owner，而不是再次抄写定义。
| 标准 | 回检问题 |
|---|---|
| 有效性 | 指标是否对应真实业务目标 |
| 可靠性 | 重复运行是否稳定 |
| 区分度 | 能否区分强弱版本 |
| 覆盖度 | 是否覆盖高频、高危、长尾和安全 |
| 可解释性 | 分数变化是否能归因 |
| 可复现性 | 是否记录数据、模型、Prompt、工具、Evaluator 版本 |
| 可操作性 | 结果是否触发门禁、修复或回流 |
如果一套评测体系只能回答“分数是多少”，不能回答“为什么、怎么办、能不能上线”，它还没有达到企业级要求。
15.12 交付物二：版本对比实验设计模板
| 字段 | 内容 |
|---|---|
| 实验目标 | 比较候选版本是否优于当前线上版本 |
| 对比对象 | 当前版本、候选版本 |
| 控制变量 | 数据集、知识库、工具、Evaluator、采样参数 |
| 样本范围 | Golden、Regression、Hard Case、Red Team |
| 主要指标 | 门禁指标和核心业务指标 |
| 次要指标 | 诊断指标、观察指标 |
| 显著性判断 | 置信区间、配对差异、人工复核 |
| 退化处理 | 识别退化场景，决定阻断、灰度或修复 |
| 发布建议 | 全量、灰度、阻断、人工审批 |
15.13 交付物三：离线-在线相关性分析模板
| 字段 | 内容 |
|---|---|
| 离线指标 | 任务完成率、政策正确率等 |
| 线上指标 | 转人工率、投诉率、用户追问率等 |
| 观察周期 | 例如 7 天或 14 天 |
| 版本范围 | 涉及哪些版本 |
| 相关性判断 | 同向、反向、无明显相关 |
| 异常解释 | 样本分布、用户变化、业务策略变化 |
| 调整动作 | 更新评测集、调整指标、补充线上回流 |
15.14 方法依据与延伸阅读
- E. B. Wilson, Probable Inference, the Law of Succession, and Statistical Inference（1927）：比例区间的经典来源。
- B. Efron, Nonparametric Estimates of Standard Error: The Jackknife, the Bootstrap and Other Methods（1981）：Bootstrap 方法的基础文献。
- NIST/SEMATECH：配对观测分析与 McNemar 检验说明。
这些资料提供统计方法依据，但不会替具体业务自动选择指标、效应量、样本量和门禁阈值。
15.15 本章小结
可信评测的底线，是不用不可靠的分数做高风险决策；统计方法应与这个目的相匹配。
一套评测结论要能支撑企业决策，至少要说明：
- 样本是否足够，分布是否合理。
- 版本对比是否控制变量。
- 分数变化是否超过随机波动。
- 提升是否具有业务意义。
- Evaluator 是否经过人工校准。
- 离线指标是否能解释线上表现。
- 评测体系本身是否仍然有效。
至此，评测方案设计的核心链条已经形成：指标树决定评什么，数据资产决定用什么评，Case Schema 决定如何执行，Evaluator 决定如何判定，Trace 决定如何看过程，可信评测决定结论能否用于发布和优化。下一章，我们将引入评测中常被忽略的第三个维度——成本和延迟，看看如何在质量、成本和速度之间做出工程化权衡。