评测基准与动态任务环境

• 评分扰动与置信区间（置信区间、标准误）的构造
• 覆盖率归一化（per-sample 平均 vs 直接平均）与加权
• 两两比较的显著性检验，避免把"看起来更高"误判为"显著更强"

不要直接对每个基准算出的平均分再取平均并据此排序，因为覆盖度不同的基准对不同模型不公平，且单次运行带随机性。工程做法是：先对每个基准按样本级得分计算均值与标准误，构造置信区间；综合排名时用覆盖度加权（样本越多权重越大）或统一到 per-sample 平均的尺度；对任意两个模型做两两显著性检验（如配对 t 检验或 bootstrap 检验），只有当差异在给定显著性水平下成立时，才把排名差异视为可信；否则将两者归入"无显著差异"区间，展示为一组而非绝对顺序。最终汇报时给出每个模型的得分区间与彼此是否有显著差异，而不是单一排名数字。

单次实验的运气（seed、采样温度、网络抖动）会放大表面差异；区间与显著性把"统计噪声"与"真实能力差异"分开，避免为了几个百分点差异而做错误的选型或发布决策。这也是回归基线里"只有显著退化才阻断"的同一套逻辑。

• 新旧基准并行期与双轨运行
• 基线的重新校准与阈值对齐
• 切换期门禁的降级策略与历史可比性

采用"新旧并行过渡"策略：新基准上线后与旧基准并行运行一段时间，收集足够样本后把旧基准的得分区间映射到新基准尺度（用同一批模型在两者上的得分回归对齐），再更新门禁阈值。切换期间 CI 门禁跑双轨，只有两个基准都通过才放行，或采用"旧基准通过即放行、新基准仅记录不阻断"的渐进策略，避免瞬间切换导致大面积误报。对退役基准的历史结果保留快照，作为归档与排查依据，但不再用于门禁判定。

突然切换基准会导致两个问题：一是旧基线失效导致新基准下历史模型全部"不达标"引发误报；二是新基准尚不稳定，个别样本质量问题会被误当成模型退化。双轨并行与映射对齐能让门禁在过渡期既不误伤也不放过真实退化。

• 人工验证剔除有歧义/损坏的 issue 的意义
• 回归控制（fail-to-pass 测试判定）如何保证"真修好"而非"改坏"
• 不可解 issue 子集如何作为能力边界与上限的参照

SWE-bench Verified 用法上：人工验证保证 issue 描述清晰、可复现，降低评测噪声；回归控制用 fail-to-pass 测试（先前失败、修复后通过的测试）判定正确性，同时用 pass-to-pass 测试防止回归破坏原有功能；不可解 issue 子集（无人工修复参考或环境无法复现）用于识别 Agent 的能力瓶颈与评分上限的参照，不应混入主评分集。工程上应把 Verified 集作为 Agent 端到端代码修复能力的标准化基准，同时配合"是否有可复现的测试变更"来判定，避免只看"是否改动了代码"。

若缺少 fail-to-pass 判定，Agent 可能改了代码但没真正通过测试，被误判为修复成功；不可解 issue 若混入主集，会稀释有区分度的样本并拉低整体分数，应单独作为边界分析。

• 样本规模差异对置信度的影响
• 多模态样本（含图片 issue）的比例与引入的额外维度
• 与 Verified 的分布差异（代码仓库、语言、难度）导致不可直接比较

SWE-bench Lite 约 300 条、Verified 约 500 条，而 Multimodal 规模更小且包含大量带截图的 issue（多模态输入）。解读时：样本少意味着置信区间更宽，分数差异需更大才显著；Multimodal 额外测"理解截图/UI 图"的能力，与纯文本 Verified 不可直接比；各基准的仓库构成、语言分布和难度不同，直接横向对比分数会误导。正确做法是记录各自基准与版本，做同基准纵向对比，跨基准比较时说明作为"能力切片"而非总排名。

多模态比例不同意味着测的是叠加能力，分数差异可能来自"多模态理解"而非"代码修复"；样本规模影响统计置信度。因此必须分基准解读，不能混为一谈。

• 多任务覆盖不同能力维度
• 能力切片（per-task）诊断
• 从薄弱点反推改进方向（工具、上下文、规划）

AgentBench 把 Agent 放进操作系统、数据库、购物网站、博弈游戏等多样环境，每个环境测不同能力（命令执行、SQL 操作、网页交互、长期规划）。工程上不只看总分，而是按任务维度做能力切片分析，找出区分度最高的任务与得分最低的任务，定位薄弱能力（如长程规划、多步工具调用、错误恢复）。据此反推改进：工具设计是否清晰、上下文是否足够、规划是否长远、失败重试是否有效，并针对薄弱切片补充专项评测与训练数据。

单一基准分数掩盖了能力结构；按任务切片能揭示"是工具使用问题还是规划问题"，让改进有针对性，避免把算力花在已经强的能力上。

• GAIA 代表通用知识问答+工具组合的"任务粒度"
• WebArena 代表网站交互的"操作粒度"
• OSWorld 代表桌面 GUI 操作的"环境粒度"

GAIA 用真实世界问题测试 Agent 的通用助手能力（多步推理、外部知识、工具调用后综合），粒度是"开放式任务完成"；WebArena 用真实网站（电商、论坛、社交）测试网页导航与操作端点，粒度是"网站任务操作"；OSWorld 用桌面操作系统 GUI 测试鼠标键盘交互，粒度是"桌面环境操作"。三者覆盖从"会答"到"会用网页"再到"会用桌面"的能力纵深，组合使用可全面评估 Agent 在知识、Web、桌面三层的能力，分别对应不同产品形态。

三种基准粒度不同，不能互相替代；选型时按产品形态（纯问答、网页助手、桌面 Agent）选择对应粒度，并叠加其他基准补全能力面。

• 双轮用户模拟制造有状态、多轮对话
• 领域任务（零售、航空等）难度分层
• 对话型 Agent 的槽位抽取、澄清与工具调用综合评估

τ-bench/τ²-bench 用模拟用户与 Agent 进行多轮对话，模拟用户会给出新信息、追问、指正，从而制造有状态的真实交互场景；任务覆盖零售、航空等具体领域，难度分层（单任务、多任务、跨任务）。评估时不只看最终是否完成任务，还看对话轮次、澄清次数、工具调用正确性、是否需要用户反复纠正。工程上用它测对话型 Agent 的"主动澄清、信息抽取、带状态工具调用"能力，并作为对话产品回归与上线门禁的一部分。

静态单轮问答无法覆盖真实对话的转折与状态；双轮用户模拟能暴露 Agent 在澄清、纠错、多步状态维护上的缺陷，是对话型 Agent 专项评测的关键。

• 动态环境 vs 静态题库的差异（可执行环境、后门、迭代）
• 候选集隔离与时间切分防泄漏
• 现已公开样本的污染规避

静态题库直接给问答对，无法模拟"执行—报错—再试"的闭环；动态评测环境提供可执行沙箱，Agent 能真正运行代码、看测试结果、迭代修复，更接近真实。防作弊设计：一是时间切分（按 issue 创建时间把训练与评测集分开，防止时间泄漏）；二是隔离新发样本（线上新 issue 随测随收，不进入公开训练语料）；三是把已公开的旧样本标记为"已被污染"，作对比参照而非主评分；四是防止 Agent 直接 grep 答案或强制覆盖测试文件，用 fail-to-pass 判定并限制沙箱文件系统权限。

动态环境最怕"评测集被训练语料或网上公开"造成污染虚高，以及 Agent 走捷径绕过真正修复。时间切分、候选隔离、行为约束是防作弊的核心。

• 种子问题收集与去重
• 标注规范与一致性
• 迭代回流（badcase 回流、覆盖度更新）

流程分四步：一、种子问题收集，从线上日志、用户反馈、客服工单、竞品 badcase 中抽取高频与高价值问题，去重并分类；二、标注，制定标注规范（正确答案、参考依据、可接受边界），由领域专家标注，用双人标注+一致性校验（如 Cohen's Kappa）保证质量；三、分层组装，按难度、场景、意图分层采样，构成评测集并做版本控制；四、迭代回流，把线上新增的 badcase 和评测失败但人工确认话术合理的样本回流，定期更新评测集并重新验证，防止覆盖度漂移。

业务评测集必须贴近真实输入分布，否则离线分数虚高上线翻车；标注一致性与迭代回流保证评测集长期有效并与业务共同演进。

• 各层级测评对象与工具
• 分层定位与配合
• 用户反馈作为最终 KPI

评测分四层：一、单元评测，对单个组件（如单个 prompt、函数、解析器）做针对性断言，用输入输出映射或 LLM judge 校验；二、集成评测，测多组件协同（检索+生成、工具调用链），验证数据流与接口契约；三、端到端评测，跑完整用户流程（如 RAG 问答、Agent 任务），用任务成功率、事实一致性等整体指标；四、用户反馈，通过线上满意度、点赞点踩、留存与转化等真实信号。四层构成"下层层层保障、上层最终验证"的漏斗，单元/集成快速定位问题，端到端保整体质量，用户反馈作为最终决策依据。

只看端到端难以定位故障点，只看单元又无法反映整体体验；分层配合让问题快速定位且最终以真实用户信号为准。

• 生成→判别器→去重→分层的流水线设计
• 分布偏差（合成集太简单/太规整）导致虚高的防控
• 评测题与训练语料重合导致污染虚高的防控

流水线：先用 LLM 从真实日志改写（改写保留原意与难点）与扩写（生成变体）得到候选样本；再用判别器（分类器或 LLM judge）过滤掉语义错误、与原文重复、无价值样本；用 embedding 向量做相似度去重，保留高多样性样本；最后按难度分层（简单/中等/困难/对抗）并按比例采样。防虚高：一是保留真实种子样本做"锚点"混合，对比合成与真实样本的难度分布，若合成样本难度显著偏低则回填真实样本并修正采样；二是用时间切分/隔离，确保评测题不进入训练语料，定期检测与训练数据的相似度（embedding 近邻）剔除已被污染的题。

合成样本易"规整化"导致分布偏向简单，从而离线分数虚高；评测题若出现在训练语料中则模型"见过答案"造成污染虚高。锚点混合、难度对齐与污染检测是两类虚高的关键防线。

• 站点变更导致评测失效
• 登录态与地区差异
• 不可重现时的处理策略

处理策略：一是对依赖登录态的任务，统一用受控测试账号、固定登录环境和清扫数据，保证初始状态一致；二是对地区内容差异，明确设定地区/语言参数并记录，避免随机内容影响判定；三是站点变更时，采用"任务关键路径快照"或部署可控的测试站点（staging），用固定版本页面保证可复现；四是失效任务自动标记并隔离，避免脏数据混入分数。能完全复现的用受控环境，不能复现的做"任务级人工复核"而非自动打分。

真实站点内容动态变化，自动判定会因环境差异产生噪声；受控测试账号、固定环境与快照是保证可重现的关键，必要时人工复核兜底。

• 分布偏差（离线集 vs 线上输入）
• 评测口径与线上口径不一致
• 环境差异（延迟、并发、上下文）与修复方向

归因步骤：一、对比离线评测集与线上输入分布（意图、长度、难度、语言），若分布不匹配则补充线上样本重训评测集；二、检查评测口径与线上口径是否一致（如离线用参考答案、线上用用户满意度），不一致则校准评测口径；三、检查环境差异（离线单次、线上并发+限时+真实上下文），用影子评估/线上回放对齐。修复：回填线上样本、增加困难/对抗样本、引入用户反馈信号进评测、必要时用线上 A/B 作为最终裁决。

错位几乎都源于"评测集不能代表线上"或"评测口径与线上指标不一致"；归因是找到断点，再针对性地补样本、改口径或加影子评估校准。

• 人工标注的准确性与成本
• 对抗样本的边界探测
• 自动生成的规模与质量风险

人工标注准确、贴近真实需求，但成本高、规模有限；对抗样本针对模型薄弱点与边界设计（如越狱、歧义、长尾），能测出常规样本测不出的问题但难判定"正确答案"；自动生成（LLM 改写/扩写）规模大、成本低，但可能分布规整、含噪声。组合策略：以人工标注为黄金标准（做锚点与校准），用自动生成扩规模，用对抗样本压边界，三者按比例混合并做分层、去重与一致性校验。

单一来源各有缺项：人工贵、自动噪、对抗难；混合并用才能兼顾规模、准确性与边界覆盖，且要先人工校准再自动扩展。

• 版本快照与冻结
• 评分标准变更的映射
• 双轨重跑与迁移说明

做法：一是对任务模板、指标与评分标准做显式版本化并冻结快照，历史结果始终绑定其版本；二是指标或评分标准变更时，在旧版本上重跑一批代表性样本，量化新旧打分差异并建立映射/校准系数，说明"分数变化里多少是模型变化、多少是评分标准变化"；三是过渡期双轨运行（新旧并跑），确认稳定后再切换；四是所有历史记录带版本标签，便于按版本同比或分组对比。

直接更新评分标准会让历史分数不可比，无法区分"模型变好"还是"规则变严"；版本冻结+重跑校准+双轨过渡是保证可比性的关键。

• 样本量计算（功效分析）
• 显著性检验（p 值、置信区间）
• 多重比较校正（Bonferroni/FDR）避免假阳性

先做功效分析确定样本量：给定期望提升幅度、显著性水平（如 0.05）与功效（如 0.8），算出所需样本量，避免样本过小导致"差异不显著"或过小又大。再用显著性检验（配对 t 检验或 bootstrap）比较两组，看置信区间是否包含 0；同时注意业务显著性（差异是否值得上线）与统计显著性分开。当同时比较多个指标或多个变体时，用多重比较校正（Bonferroni 或 FDR）控制假阳性，避免被偶然显著的指标误导。

样本量不足会吞掉真实差异，多重比较不校正会放大偶然显著；业务显著性与统计显著性要分开判断，是严谨评测的统计基础。

• 变更触发评测
• 门禁判定（通过/阻断）
• 联动与回滚

设计：prompt 变更提交后，触发 CI 自动运行对应评测集（可选冒烟子集+全量子集分层），跑完后按门禁规则判定——通过率/回归阈值（如关键指标相对基线下降不超过 X%）则放行，否则阻断并生成 diff 报告。门禁与 prompt 版本绑定：记录每个 prompt 版本对应的评测结果与基线，变更超阈值时自动阻断并提示人工审批；同时支持"feature flag 灰度"先小流量验证再全量。复盘时按 prompt 版本回看评测趋势，定位是哪个改动引入退化。

把 prompt 变更与评测门禁联动，能防止"悄悄改 prompt 导致质量退化数周才发现"；版本绑定+阈值阻断+灰度是回归门禁的核心。