23｜Evaluation：怎样证明一次优化真有收益
本章目录
本章预备知识
评价前先定义一次尝试、一个任务和成功条件，之后才有分母。重复运行相关、样本少、评分偏置，都可能让看起来明确的提升不可靠。
本章各题列出所需基础。可先完成相应基础课，也可通过自检确认掌握程度。
进入深读前的小检查：按p=0.8计算三次至少一次成功0.992与三次全部成功0.512，解释两种指标为什么不能互换。
术语带虚线时可点击速查。公式中的字母先看定义；不要用猜缩写替代推导。
评测不仅是“跑一个排行榜”。需要定义任务、试验、成功条件、环境与统计单位，才能区分真正改进、偶然波动和评价器偏差。[EVALS]
沿着对象与状态理解本章
两个平均成功率之间的差值，不能告诉你哪些题退化。先看同题配对表：两边都成功、新版独胜、旧版独胜、两边都失败，再看成本、方差和评分器误差。
下方图解的固定输入在“输入与适用条件”中声明。它用于解释本章机制，不与本章其他独立例子的数值暗中接续。
涨了10个百分点，为什么还不能急着下结论？
一次实验怎样区别真实改进与偶然波动？
像给同一组题换两种解法：同题对照能减少题目难度不同带来的干扰。统计方法帮助表达不确定性，不会自动告诉你退化是否可接受、成本是否值得。实际决策还要回到任务类型、失误严重性和重复表现。
输入与适用条件：构造的20题配对表：10都成、4新成旧败、2旧成新败、4都败。不把它当真实模型胜率。
1 / 5 · 同20题，两版各跑一次
窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。
配对意味着旧版和新版面对同一题。先列出两者在每道题上的成功与失败关系，而不是只看两个总分。
20个配对任务；不是40个独立任务默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。
为什么需要
避免因一个小样本的好看结果就把优化推向全部任务。
怎样实现
固定题集、版本和预算，配对重复，记录退化，并检查置信区间等不确定性。
可能的代价与误解
只保留成功重跑、反复调参又用同一评测集验收，会高估能力。
如何判断是否做对
重算全部配对原始记录，报告净提升、退化和成本，而不是只报均值。
Q089｜Agent评测最小单元是什么？Task、Trial、Trace、Outcome怎样区分？
核心回答
Task是要完成的问题与初始环境；Trial是一次具体运行；Trace记录过程；Outcome是环境中的最终结果。模型说“完成”属于Trace里的输出，不自动等于Outcome成功。Grader根据明确标准评判结果与必要过程。[EVALS]
一条可重跑的软件任务
保存用户需求、仓库快照、依赖锁定、测试环境、工具权限和预算。每个trial从干净环境启动，避免上次运行留下修复文件或缓存影响。记录模型/配置/skill版本与实际调用，结束后由独立检查确认补丁是否解决问题、有没有回归和越权。
Trace有助于定位失败：没有找到文件、读错版本、错误补丁、测试没跑。Outcome则检查实际产物。两者都重要：只看最终答案会被口头承诺骗；只看过程是否像人类步骤会惩罚不同但正确的方案。
任务集应包含常见任务、边界任务、困难任务和真实失败案例。训练/调Prompt用开发集，最终比较保留独立测试集。反复在同一套公开题上调到很高，可能只是记住测试分布。
一个任务跑三次，统计表到底有几行
输入与条件。有任务T1和T2，每个运行3次，共6条执行轨迹。T1结果成功、失败、成功；T2成功、成功、成功。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1任务层 | 数据集只有2个独立任务定义 | 不能说覆盖了6种业务问题。 |
| 2尝试层 | 共6次trial | 每次有自己的模型输出、工具日志和资源开销。 |
| 3结果层 | 5/6次成功 | 一次执行成功率约83.33%。 |
| 4任务覆盖 | 两个任务都至少成功过一次 | 至少一次成功的任务覆盖100%，含义不同。 |
| 5稳定性 | T1并不稳定 | 不能被“两个任务都做出来过”掩盖。 |
把过程连起来。任务、尝试、轨迹与结果要分层保存，评测分母才不会偷换。
边界与反例。仅两任务不支持广泛泛化；多次运行应考虑同一任务内相关性。
依据与适用范围：[EVALS]。示例输入和场景由本书明确设定。
追问：Replay录制工具结果能代替端到端评测吗？
能隔离模型决策和协议处理，降低成本；但它固定了环境反馈，无法验证真实工具、副作用和新查询。应把离线replay与真实沙箱运行分开报告，不能用前者冒充全部系统可靠性。
追问：为什么基础设施噪声会影响结论？
CPU/内存、网络、依赖下载、并发和超时都可能改变运行成功率。A版本碰巧在空闲机器、B在拥塞机器，会形成假差异。应尽量配对/随机化运行顺序，并记录基础设施失败单独分类。
追问：没有大量任务就不能评测吗？
少量真实案例仍能发现明显回归和验证机制，但统计精度有限。明确样本量与边界，从高价值失败开始，比等到建好巨大平台才测更实际。不要把小样本结果夸大为总体胜率。
Q090｜pass@1、pass@k、pass^k有什么区别？请算一个例子。
核心回答
pass@1看一次尝试成功；pass@k看k次尝试至少一次成功；pass^k强调k次均成功的可靠性。前者偏向可搜索能力，后者偏向重复运行稳定性，不能混用。[HUMANEVAL][TAU]
从单题概率到估计式
若同一题每次独立成功概率p，则至少一次成功为1−(1−p)^k，全部成功为p^k。p=0.8、k=3时，至少一次约0.992，三次全成功却只有0.512。两者差异很大：能通过多次采样找出一个好答案，不等于每次都可靠。
HumanEval常用的pass@k估计式在n个样本中有c个成功时为：
pass@k = 1 − C(n−c,k)/C(n,k), n≥k
n=10、c=3、k=2，结果1−C(7,2)/C(10,2)=0.533333。它计算从这批样本抽k个至少一个成功的比例；不是简单用c/n乘k。公式适用需要明确采样与评测设置。
Agent业务任务不能忽略失败尝试的副作用与成本。生成十个代码候选再离线筛选和对生产系统尝试十次写操作完全不同。允许多次尝试的评测必须说明谁选择成功候选、有没有可靠oracle、失败造成什么。
pass@3与连续三次都成功，数字为何差很多
输入与条件。先作独立同分布假设：单次成功概率p=0.8。再看有限样本估计：10个候选中6个成功。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1一次成功 | pass@1 | 0.8。 |
| 2三次至少一次 | 1−(1−0.8)^3 | 0.992。 |
| 3三次全成功 | 0.8^3 | 0.512。 |
| 4有限候选抽3个 | 1−C(4,3)/C(10,3) | 约0.966667，与直接代入无限独立模型不是同一估计。 |
| 5工程解读 | 用户只会正常执行一次 | 用pass@3替代pass@1可能掩盖重试成本。 |
把过程连起来。“至少一次”“全部成功”和“从已生成样本中抽取”是不同事件，不能共用一个解释。
边界与反例。独立假设常不严格成立；真实Agent多次失败可能由同一环境或证据缺陷相关地造成。
依据与适用范围：[EVALS]。示例输入和场景由本书明确设定。
追问：不同任务难度不同时，能先平均p再代入公式吗？
一般不等价。应按任务计算对应指标再汇总，因为非线性函数作用于平均值与平均函数值不同。难题/易题混合会掩盖重要分布差异。
追问：100次全成功能证明成功率100%吗？
不能。在独立同分布的二项模型下，100次全成功的双侧95% Clopper–Pearson下限约为0.025^(1/100)=0.9638。这仍依赖抽样假设，且不代表未覆盖任务类型的可靠性。本包核对的是这个数学数值，不是某Agent实测。
追问：多次运行结果相关怎么办？
共享缓存、环境、模型错误或同一任务重复会引入相关性，简单独立公式可能过于乐观。应按任务聚类统计、控制环境并报告假设；不要把同一道题跑100遍当100个独立业务场景。
Q091｜A/B版本成功率差两个百分点，怎样判断是否真实？配对评测为何重要？
核心回答
看同一任务上的成败变化、样本量和不确定区间，而不是只比较总百分比。配对设计控制任务难度，使差异主要来自版本；统计显著也不等于工程上值得，仍要看成本与风险。
一张四格表
对相同N个任务，统计：两者都成功a；旧成功新失败b；旧失败新成功c；两者都失败d。成功率差为(c−b)/N。真正体现版本差异的是b和c，而不是a。
例：N=100，a=70、b=5、c=10、d=15，新版净增5个百分点，但同时让5个原成功任务退化。若这5个恰好是高风险任务，净增不一定值得。必须看任务类型和失败后果。
可以对任务对进行bootstrap，重复抽样任务ID并计算差异，得到区间；对于配对二元结果可使用McNemar思路检验不一致对的方向。多trial时应按任务为主要聚类单位，避免把同题重复运行当完全独立样本。
成本也做配对：同题新旧Token、耗时、重试和人工返工。把平均成功率提升与P95耗时翻倍放在一起，才能做真实决策。
20个任务提升20个百分点，证据足够强吗
输入与条件。同一20任务上A/B对比：两者成功10，两者失败2，仅B成功6，仅A成功2。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1总成功率 | A=(10+2)/20，B=(10+6)/20 | 60%对80%，观测提升20个百分点。 |
| 2配对变化 | 真正发生差异的是8个任务 | B赢6，A赢2。 |
| 3零假设 | 差异方向等可能 | 精确双侧二项概率2×(C8,0+C8,1+C8,2)/2^8。 |
| 4计算 | 2×(1+8+28)/256 | p=0.2890625，不能用这小样本宣称确定普遍改善。 |
| 5下一步 | 分析赢/输任务的原因，并扩大代表样本 | 不要仅把同20任务重跑到得到想要的p值。 |
把过程连起来。观测收益可以有工程价值，但统计不确定性必须与收益一起报告。
边界与反例。p值不是“方案错误概率”，未显著也不证明两方案完全等效。
依据与适用范围：[EVALS]。示例输入和场景由本书明确设定。
追问：只在新版成功的案例上算耗时有什么问题？
产生选择偏差。新版失败或超时的高成本任务被排除，显得更快。应报告所有任务成本、成功任务成本以及失败处理，明确超时如何计入。
追问：多次试很多Prompt，选最好的再报告测试集分数可以吗？
这会把测试集变成开发集，最优结果可能是对噪声过拟合。应保留未参与选择的最终集，或使用合理的交叉验证与多重比较意识。实验记录要保留尝试范围，不只留下最漂亮的一次。
追问：样本小、区间宽时该怎么做工程决定？
结合机制证据、失败严重性和可回滚性。明显修复确定性Bug可先合并并观察；昂贵复杂新架构则需要更多证据。诚实说“不足以量化总体提升”不妨碍修复已确认问题。
Q092｜LLM-as-a-Judge为什么有用又危险？怎样降低评分偏差？
核心回答
模型评判可以覆盖开放式质量、证据支持与风格等难以完全规则化的维度，但会受位置、长度、措辞、模型偏好和信息不足影响。应使用明确rubric、盲化/换序、校准样本，并优先让确定性验证承担可机械判断部分。[JUDGE]
把一个笼统打分拆成可审查判断
“这份代码好不好，0到10分”很难稳定。可以改为：是否满足每条需求；是否引入不必要接口变更；有没有证据支持测试声明；是否存在具体可复现缺陷；哪些只是风格建议。要求每个负面判断给出位置、原因和最小反例，而不是泛泛批评。
对A/B答案随机排序，避免总把新版放后面；适当隐藏模型和版本身份，减少先验偏好。对部分样本由人或独立工具复核，检查一致性和误报。多个Judge也可能共享偏见，不应把多数票当真理。
确定性检查优先：JSON可解析、测试退出码、文件存在、数值计算、权限范围不需要模型评语。开放设计可用模型辅助，但对重要缺陷仍需证据验证。
判分模型偏爱第一个答案，怎样发现
输入与条件。同一对答案A、B，判分器按A在前时给A胜；交换位置后却给B胜。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1固定题目与标准 | 只交换答案呈现顺序 | 避免同时改变内容。 |
| 2第一次 | A/B | 选A。 |
| 3第二次 | B/A | 选B。 |
| 4诊断 | 赢家随位置变化 | 存在位置敏感，不能当稳定质量排序。 |
| 5处理 | 匿名化、双向呈现、明确证据标准，抽样人工核对 | 并记录仍无法判定的平局。 |
| 6更强证据 | 代码是否通过外部测试 | 可执行结果不应被一个流畅的评语轻易推翻。 |
把过程连起来。LLM-as-judge本身也是待验证系统，而不是无偏权威。
边界与反例。两次示例只能展示一种失败模式；实际偏差程度需要重复、代表性配对评测。
依据与适用范围：[EVALS]。示例输入和场景由本书明确设定。
追问：让执行模型自己评价自己够吗？
可作为廉价初筛，但它可能坚持原假设或只复述理由。独立模型也不保证独立；更有效的是引入新证据、反例和工具验证。自评置信度应经过校准，不直接当通过门槛。
追问：为什么“解释越详细”可能得分越高但质量不更好？
Judge可能把长度和专业词当质量代理。评分应明确要求相关性、正确性和最小必要复杂度，允许简洁正确答案胜出。用户任务需要代码修复时，长篇设计说明不能抵消未修改代码。
追问：生产中能否全靠Judge自动放行？
取决于风险，但关键权限、不可逆操作和确定性不变量不应仅由概率评分决定。Judge适合辅助分流和发现问题；放行边界需要可验证条件及必要人工授权。