做评测的人，本质是把用户替在前面用、替在嘴边说、替在手上试的那个人。用户不会写评测报告，但用户会感觉到一个事实：同一句话，豆包这次答得挺好，下次好像又差一点意思。这个「时好时坏」的体感，就是非确定性。评测人的第一份责任，是把这种模糊的体感，翻译成可判断、可交付的结论。

而要把这件事做对，得先接受一个传统测试人最难咽下的事实：豆包不是「输入 A 必得输出 B」的软件。你写的每一条用例，跑一次是一个答案，再跑一次可能又是一个答案，两个答案都能算对。上篇（04）讲到「同一版本跑两次分数都可能不同」时，埋下的就是这个根。本篇把这个根挖开：非确定性系统下，评测到底该怎么想、怎么动手。

二、六大范式转移：传统测试 vs AI 评测

传统软件测试那一套心法，在豆包面前一条条塌。先把最关键的六条对照摆出来，后面所有方法都从这六条长出来。

传统测试	AI 评测	关键差异
验证「对 / 错」	评估「好 / 坏」	没有唯一正确答案，只有更好的答案
追求 100% 覆盖率	追求风险分布覆盖	穷举不可能，按风险优先级抽样
一次性验证	持续监控	同一版本跑两次分数可能不同，需多轮取分布
用例即预期	用例即参考	测试用例不是标准答案，而是参考范围
Bug 定位到代码行	退化定位到维度与 case 类型	没有代码错误，只有能力退化
发布时间等于测试结束	发布时间等于监控开始	离线评测只是第一关，线上表现才是终局

这六条不是并列的。最底下那条「验证对错到评估好坏」是总开关，其余五条都是它的推论。所以下面篇幅不平均，重心压在「怎么从验证对错转向评估好坏」这件事上。

三、核心思维转变：从「找 bug」到「建标准」

传统测试的交付物，是一张 pass / fail 列表，旁边标着「这里错了」。AI 评测的交付物，应该是一张维度分数加分布加趋势的表，旁边标着：这个版本在 XX 维度比上个版本低了 3 分，95% 置信区间 ±1.5，达到退化告警阈值。

这两张单子的差别，就是评测岗和非确定性系统相处的方式。

为什么必须这么转？因为非确定性下不存在「唯一正确答案」。同一个问题，十种回答可能都算合格，只是有的更贴切、有的更啰嗦、有的更安全。你的工作不再是判断「它对不对」，而是判断「它够不够好、比上个版本好还是差、差多少、这个差是不是真的」。

落到日常，有一条纪律值得刻在评测报告模板上：结论落到分布和趋势，不落到单次对错。单次跑出的一句「答错了」，在 AI 评测里几乎不构成证据；但你连续五轮采样、看到某个维度均值稳定往下掉、置信区间还不重叠，这就是能写进交付意见书的硬结论。

四、落地一 · 多轮采样评分布

思维转过来之后，第一件要改的动手习惯是：别再跑一次就下结论，改为跑 N 次、看分布。

为什么必须多轮？因为豆包的输出天然带采样。解码时的 temperature、top-p，检索增强时召回的文档集合，调用工具时的环境状态，甚至并发和 batch 的微小差异，都会让同一条输入两次产出不同结果。这不是 bug，是模型的本性。一次采样看到的，只是这个分布里的一个点，拿一个点当结论，和拿一次抽奖结果说「这个彩票不中奖」一样不可靠。

实操上，我把配置拆成几件具体的事。

采样次数。关键 case 至少跑 3 到 5 次。学界评测代码类任务常取 5 次以上，业务评测可据置信度要求定，但低于 3 次基本没法定分布。

固定随机性。明确写清 temperature 取值；temperature 设成 0 能压低随机性，但仍可能因 batch 组合、并发顺序出现细微差异，不能当成完全确定。框架支持的话固定 random seed，便于别人复现你这次的结果。

报告区间，不报告单点。每次评测给出维度均值、标准差，以及 95% Bootstrap 置信区间（Bootstrap 由 Efron 1979 提出，用重采样估计区间，不依赖正态假设，适合小样本）。一个维度「本次 4.2 分，95% CI [4.0, 4.4]」比「本次 4.2 分」信息量高出一个量级。

指标选择。连续质量分看均值加区间；代码类任务看 pass@k（跑 k 次中至少 1 次通过的比例，HumanEval 体系由 Chen et al. 2021 确立），它天生就是在非确定性下定义的指标，比单次 pass / fail 更贴实际。

判法。单条 case 永远不下结论。维度层面看分布；如果发现两次跑结果差很多，先区分是模型非确定性还是评测代码问题：换机器、换时间、代码没动，结果仍然漂移，多半是模型采样；同条件下方差异常大，查采样配置和评分脚本。退化判定用这条：本版某维度均值较上版低了 X%（比如 ≥ 3%），且 Bootstrap 置信区间不重叠，才算一个真实退化信号，值得拉响告警。

数据来源。采样次数、区间计算都能在本地复算，不依赖外部；Bootstrap、pass@k 的方法出处标在文末参考。评测记录里必须存下 temperature、seed、采样次数，否则别人无法复现，你也分不清「模型变了」还是「配置变了」。

五、落地二 · 风险优先覆盖

第二件要改的习惯是：别再追求覆盖率，改为按风险排序抽样。

传统测试里「覆盖率」是个光荣指标，分支覆盖、行覆盖越高越安心。到了非确定性系统，输出空间几乎无限，你永远穷举不完。继续追覆盖率，只会把精力平均撒在大量低价值 case 上，真正高危的场景反而覆盖不足。

正确做法是按业务影响排优先级。我习惯用一张风险矩阵把场景排出来：

场景	影响面（用户量 / 关键度）	发生概率	优先级	抽样条数
核心对话、支付相关	高	高	P0	全量 + 高覆盖回归集
常见任务、查询	中	高	P1	中等覆盖 + 定期轮换
长尾知识问答	低	中	P2	按风险抽 + 私有保留题
极端边界输入	低	低	P3	少量探活

判法有两条。第一，P0 场景必须有专门的回归集，每次版本发布都跑，不允许「这次太赶先跳过」。第二，长尾不靠穷举，靠私有保留题加线上监控补（保留题的做法在后面持续监控一节会接上）。

数据来源。优先级不是拍脑袋，来自业务埋点、用户反馈分类、历史缺陷分布。哪个场景投诉多、哪个维度历史波动大，哪个就排前面。评测人要做的是把这份业务风险地图，翻译成评测集的抽样权重。

六、落地三 · 持续监控替代一次性验收

第三件要改的习惯最反直觉：别把发布当成测试的终点，当成监控的起点。

非确定性系统的「坏」常常发生在发布之后。环境在变、检索的文档在变、用户用法在变，更隐蔽的是版本更新带来的「无声退化」：豆包版本迭代很密（截至 2026 年 7 月，仍保持高频更新节奏），某些维度可能悄悄掉一点，单次发布评测未必抓得住，等用户投诉上来才发现。所以发布时间等于监控开始，不是测试结束。

落地形态我拆成三块：

保留 golden set。挑一批核心回归 case 存进版本库，每次版本发布、每周定时跑，跟踪各维度均值和区间的走势。它不追求覆盖全，追求稳定可比。

影子评测。把线上真实流量复制一份进评测通道，不干预用户，只打分。这能抓到离线评测集碰不到的真实分布。

告警接 CI。趋势告警看均值加区间是否不重叠，单点波动不告警（噪声会制造狼来了）。阈值要按指标类型区分，这方面业界已有成熟做法（也和 01 篇产品质量红线一脉相承）：Rubric 0 到 5 分指标，黄灯 ≥ 0.15 分下降、红灯 ≥ 0.3 分下降；Pass Rate 类，黄灯 ≥ 2 个百分点、红灯 ≥ 5 个百分点下降；延迟类，黄灯 P95 ≥ 10%、红灯 P95 ≥ 20% 上升。所有退化告警必须附 Bootstrap 95% 置信区间，否则没法判断是真的退化还是采样噪声。

数据来源。线上日志采样加评测 Pipeline 加 CI 系统。监控不是评测团队单干，要和产品埋点、算法发布流程打通，退化信号才能流到该做决策的人那里。

七、原理补一刀：非确定性从哪来

前面给了方法，这一节补一点原理，帮你判断「该采多少次样、阈值定多严」，而不是凭感觉。

非确定性的源头主要有四类。解码采样，temperature 和 top-p 直接决定输出的随机程度。检索增强，RAG 每次召回的文档集合可能不同，答案随之浮动。工具调用，环境状态、接口返回顺序都会变。并发和 batch，即使 temperature 设 0，底层调度仍可能引入细微差异。

对应的统计基础要记几个词。分布和单点，永远看分布。方差和标准差，衡量一次采样的离散程度。置信区间，95% 对应 Z 值 1.96，告诉你「真实均值大概率落在这个范围」。p 值，判断两次差异是否显著，还是只是噪声。Kappa 一致性（Cohen 1960 提出），衡量评分者之间的一致性，评测里常用它看评分 Agent 稳不稳，一般 ≥ 0.6 算可接受、≥ 0.8 算好。

理解这些，你才不会犯两个错：采样次数太少就下结论（方差大、区间宽，什么也说明不了），或者阈值定得太严（把正常波动当退化，团队被狼来了搞疲）。

八、业界是怎么做的

这套「建标准、看分布、持续监控」不是我个人的偏好，业界已经有扎实的验证，举两个最相关的。

一个是基准本身的有效性审计。UIUC Kang Lab 2025 年提出 Agentic Benchmark Checklist（简称 ABC，43 项条目，从 17 个主流 agent 基准提炼），把它套到 10 个广泛使用的 agent 基准上，结果是：7 个存在任务有效性缺陷（即任务能被不具备目标能力的捷径 agent 通过），7 个存在结果有效性缺陷（评分并不能真实反映任务成败），10 个全都有报告透明度问题。连基准这个分数本身都会失真，更说明评测不能盯着一个点，要建标准、看分布。这一点和 04 篇的核心判断一致：基准分数高不代表就能交付，分数本身也需要被审视。

另一个是 LLM 当裁判。Zheng et al. 2023（NeurIPS，arXiv:2306.05685）系统证明，强模型当裁判（GPT-4 级别）与人类偏好一致性超过 80%，达到人类评审之间的同意水平，LLM-as-a-Judge 才成为可信方法。但同一篇也指出 position、verbosity、self-enhancement 三类偏置必须缓解。落到非确定性评测，一个通行做法是评分 Agent 跑多次取中位数，因为对同一 case 多次评分稳定一致，比一次评得「准」更重要，稳定性优先于单次准确性。

还有 Bootstrap 置信区间报告，早已是学界和工业界评测报告的标配，不再单列来源。这几条拼起来，印证本篇的方法不是野路子。

九、四个典型误用

方法讲完，列四个评测人最常踩的坑，都是前面内容的反面。

第一，单次跑下定论。跑一次看到一句不好的回答，就写「该场景不达标」。正确做法：多轮采样取分布，单点不构成证据。

第二，综合分掩盖分布。一个 4.2 的综合分很好看，拆开看安全维度只有 3.0，这 3.0 才是能不能发的关键。这和 01 篇「能力分治、别用综合分盖住短板」是同一纪律，也和 04 篇拆基准分维度同源。

第三，抽样无风险权重。平均用力追覆盖率，P0 场景反而没覆盖够。正确做法：风险矩阵排优先级，高危场景全量回归。

第四，离线过了就放心。发布评测绿了就觉得万事大吉，忽视线上监控，无声退化上线后才爆。正确做法：发布等于监控开始，golden set 持续跑。

十、建一套非确定性评测 SOP

把前面四、五、六、七、八拧成一份能直接落地的清单，评测新人照着建就不会偏。

1. 采样配置卡。每次评测记录 temperature、seed、采样次数（默认 5）、是否固定随机性。没有这张卡，结果无法复现，你也分不清模型变了还是配置变了。

2. 置信区间与退化阈值模板。报告 95% Bootstrap 置信区间；退化告警阈值写清楚：维度均值下降 ≥ X% 且区间不重叠才算信号。附一个样例字段：维度名 / 上版均值 / 本版均值 / 下降幅度 / 本版 CI / 是否告警。

3. 风险矩阵模板。场景、影响面、发生概率、优先级、抽样条数，五列一张表（见第五节），每次建评测集先填这张表。

4. 监控接入 CI。golden set 每周定时跑，趋势告警挂进 CI；评分一致性校验：评分 Agent 对同一 case 跑 3 次，标准差 ≤ 0.5，否则分数不可信、不能做回归对比。

5. 复用纪律。评测集、配置卡、阈值模板全部进版本库。任何人、任何机器、同条件跑，必须得到同一结果，这是评测工程化的第一原则（可复现）。

给一个可直接抄的采样配置示例，评测脚本头部写清：

eval_config:
  temperature: 0.7
  seed: 20260720
  n_samples: 5
  metric: rubric_0to5 + bootstrap_ci_95
  regression_set: golden_set_v3
  degrade_alert: mean_drop >= 0.15 (yellow) / 0.3 (red) with non-overlapping CI

这几条凑齐，非确定性系统评测就从「靠感觉」变成「有标准、有分布、有监控」。

下篇预告

这篇把非确定性下评测的核心范式立住了：从「找 bug」转向「建标准」，三条落地策略是多轮采样评分布、风险优先覆盖、持续监控替代一次性验收。但你可能心里还有一个更实际的问题：我一个传统测试转过来的人，具体要补哪些能力、原来那些用例设计、缺陷管理、自动化的本事哪些能直接复用？下篇讲算法评测 vs 传统测试：你的能力账本，把现有技能和新增要求对照起来，画一条能执行的学习路径。

作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证文章质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。

参考与延伸

• UIUC Kang Lab. Establishing Best Practices for Rigorous Agentic Benchmarks (2025). Agentic Benchmark Checklist (ABC). https://uiuc-kang-lab.github.io/agentic-benchmarks
• Zheng L. et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. arXiv:2306.05685
• Chen M. et al. Evaluating Large Language Models Trained on Code (HumanEval / pass@k). 2021.
• Efron B. Bootstrap Methods (1979). Cohen J. A Coefficient of Agreement for Nominal Scales (Kappa, 1960).
• 跨篇：01 篇（五大能力 taxonomy、产品质量红线、能力分治），04 篇（基准分是准入证不是通行证、拆维度看最弱项）。