引子测试集跟线上脱节分再高也是自嗨。题从公开集里抄几条、自己拍脑袋编几条跟线上用户真会问的东西根本不是一回事。这篇只写两件事数据从哪来开源集子能不能直接当自家评测标准。动笔前先想清三件事别一上来就「堆一百道题」。先能回答题是谁出的、从哪条流程来的日志 / PRD / 生成场景、难度、领域是不是故意摊开的还是全挤在一个角上标准答案谁认、有没有争议、后面谁来维护三条里有一条含糊后面测出来的数都很难解释。数据来源的 3 条路路一真实用户日志从线上对话里抽请求按场景归堆分析、客服、写代码之类每堆挑一批典型问法人工补期望行为或参考答案再标难度。好处是贴近业务——你测的就是用户真会问的。代价也实在贵、慢、脱敏和合规要跟人扯清楚。GDPR、《个保法》这条线不签字就别硬导日志脱敏后也仍需审批没有条件就换下面两条。SWE-bench代码修复类 Benchmark顺带说一句斯坦福那套从 GitHub issue 里来的题曾经当代码修复的标杆用公开久了训练集里「见过原题」的争议很大分容易虚高。现在更多人会看持续更新的题源例如 LiveCodeBench或仓库级任务RepoBench这类「不那么好背」的。再真的数据公开时间长了也会被模型啃过评测前心里要有这根弦。什么时候用有稳定日志、量能撑起抽样。多少算个量级每个场景先凑个几十条再谈代表性别个位数硬撑。先保证核心场景有覆盖再谈统计量。路二业务场景还原没日志就啃 PRD、工单、客服记录每个核心需求反推「用户会怎么问」写出题面拉业务认答案。离业务近、成本比全日志方案好控。麻烦在协同业务一忙你这边就断粮需求文档本身糊还原出来的题也糊。GAIAMeta 通用助手 Benchmark属于这类思路的放大版题是人按「真实会干的事」编的查航班、写邮件、跑数都有。硬伤是几乎靠人判分自动化难很难塞进日常 CI一般当上线前抽检或对照用不当每天跑的回归集。一句话不能自动判的集子更适合当「验收」不适合当每天盯的「监控」。什么时候用有清晰产品边界、没有现成日志。量级核心场景先十几二十条把高频盖住你心里有数的二八那些再往外扩。先保证核心场景有覆盖再谈统计量。路三合成生成写个 prompt 让模型批量出题、可选顺带写参考答案再人工抽 10%20% 过眼。便宜、快、量好控。坑也直白出题模型往往最会答自己出的题分布还容易飘在「正常、干净」的输入上边界和脏输入反而少。ToolBench工具调用 Benchmark就是典型九千多道 GPT-4 生成的工具调用题后面大家发现高分模型在真工具链上未必好使——分布跟线上差一截。它也不是完全没用覆盖面大拿来当「工具描述能不能读对、参数能不能组对」的单元测素材还行别当最终成绩单。什么时候用冷启动凑第一批、或当补充和压力测。量可以上到几百条但抽检别省全自动化放行等于给自己埋雷。半合成我更推荐纯生成信不过就搞「真数据 变异」先攥几十条真的再用规则换实体张三→李四、再用模型改句式口语、错字、同义最后过人眼确认没编歪。分布还在真实附近边界又能多铺一层比纯 prompt 空生成强得多。三条路怎么选|真实日志业务还原合成生成贴近业务程度最高高偏低成本高中低速度慢中快答案可信度一般较好一般较好必须抽检易自动化判分通常可以通常可以看你怎么设计期望我咋用有就用没日志时的主力补量、冒烟、专项预算紧的时候我宁愿多砸时间在数据上少在报告排版上折腾——集子歪了后面全是解释成本。开源数据集能不能直接用能别当「自家标准答案」整包端上去。主流开源集子随手查数据集规模领域一句话AgentBench清华数千级通用 Agent改编多多半要对应你自家场景SWE-bench斯坦福2294代码修复公开久注意污染对照可看 LiveCodeBenchLiveCodeBench持续更新代码生成/修复题源相对「难背」适合横向比GAIAMeta514通用助手题好人判贵难进日常流水线WebArena812网页操作真站环境但只覆盖浏览器这条线ToolBench9096工具调用别当终评可当工具解析类单测TA-Bench飞书1200企业工具飞书生态偏重迁移要改编三个常见坑场景对不上。AgentBench 里「数据分析」可能是算式级别你线上是十万行周报。分 90 和线上六成失败可以同时成立——科目顺山路照样翻。数据泄露。题面进过训练集模型是「背」不是「会」。老早就有讨论公开 benchmark 与训练语料重叠会抬分。换模型、换题源前先问一句这题有没有被啃过。对 benchmark 过拟合。厂商对着公开集调参分上去、泛化未必上去。SWE-bench 上分数挤过一轮的换未公开题源常常要掉一截——不一定是模型差了是水分被挤掉了。开源集子在我这边的用法横向对比A/B 模型同一套题公平一点。混用和自建题掺在一起开源部分别太重我心里一般不超过三成权重除非你只做纯研究对标。单测例如用 ToolBench 子集盯工具描述解析不当「上线唯一依据」。终评尽量自建 日志抽样开源整包直接当 KPI这是不行的。改编可以改编完期望答案和难度标记人得重过一遍。收束能拿日志就拿日志没有就老老实实从业务还原合成当调料当主食容易营养失衡。开源集子适合对标和补洞别默认它等于你的业务。集子建完还会旧覆盖、难度、答案争议隔段时间要审计下一篇写五项检查和脚本。附三道自测题扫一眼即可Q1智能体测试和传统测试差在哪输出不固定同一条多跑几次都可能变所以更看「一类场景有没有盖住」而不是死盯「输入 A 必须等于输出 B」一条断言打天下。Q2从零开始先干啥先画自己 Agent 的能力地图哪些是核心、哪些是边缘。核心能力上把最高频问法先铺实再谈「全场景」。
【AI测试智能体4-1】为什么你的 Agent 评测分很高，上线却翻车？
引子测试集跟线上脱节分再高也是自嗨。题从公开集里抄几条、自己拍脑袋编几条跟线上用户真会问的东西根本不是一回事。这篇只写两件事数据从哪来开源集子能不能直接当自家评测标准。动笔前先想清三件事别一上来就「堆一百道题」。先能回答题是谁出的、从哪条流程来的日志 / PRD / 生成场景、难度、领域是不是故意摊开的还是全挤在一个角上标准答案谁认、有没有争议、后面谁来维护三条里有一条含糊后面测出来的数都很难解释。数据来源的 3 条路路一真实用户日志从线上对话里抽请求按场景归堆分析、客服、写代码之类每堆挑一批典型问法人工补期望行为或参考答案再标难度。好处是贴近业务——你测的就是用户真会问的。代价也实在贵、慢、脱敏和合规要跟人扯清楚。GDPR、《个保法》这条线不签字就别硬导日志脱敏后也仍需审批没有条件就换下面两条。SWE-bench代码修复类 Benchmark顺带说一句斯坦福那套从 GitHub issue 里来的题曾经当代码修复的标杆用公开久了训练集里「见过原题」的争议很大分容易虚高。现在更多人会看持续更新的题源例如 LiveCodeBench或仓库级任务RepoBench这类「不那么好背」的。再真的数据公开时间长了也会被模型啃过评测前心里要有这根弦。什么时候用有稳定日志、量能撑起抽样。多少算个量级每个场景先凑个几十条再谈代表性别个位数硬撑。先保证核心场景有覆盖再谈统计量。路二业务场景还原没日志就啃 PRD、工单、客服记录每个核心需求反推「用户会怎么问」写出题面拉业务认答案。离业务近、成本比全日志方案好控。麻烦在协同业务一忙你这边就断粮需求文档本身糊还原出来的题也糊。GAIAMeta 通用助手 Benchmark属于这类思路的放大版题是人按「真实会干的事」编的查航班、写邮件、跑数都有。硬伤是几乎靠人判分自动化难很难塞进日常 CI一般当上线前抽检或对照用不当每天跑的回归集。一句话不能自动判的集子更适合当「验收」不适合当每天盯的「监控」。什么时候用有清晰产品边界、没有现成日志。量级核心场景先十几二十条把高频盖住你心里有数的二八那些再往外扩。先保证核心场景有覆盖再谈统计量。路三合成生成写个 prompt 让模型批量出题、可选顺带写参考答案再人工抽 10%20% 过眼。便宜、快、量好控。坑也直白出题模型往往最会答自己出的题分布还容易飘在「正常、干净」的输入上边界和脏输入反而少。ToolBench工具调用 Benchmark就是典型九千多道 GPT-4 生成的工具调用题后面大家发现高分模型在真工具链上未必好使——分布跟线上差一截。它也不是完全没用覆盖面大拿来当「工具描述能不能读对、参数能不能组对」的单元测素材还行别当最终成绩单。什么时候用冷启动凑第一批、或当补充和压力测。量可以上到几百条但抽检别省全自动化放行等于给自己埋雷。半合成我更推荐纯生成信不过就搞「真数据 变异」先攥几十条真的再用规则换实体张三→李四、再用模型改句式口语、错字、同义最后过人眼确认没编歪。分布还在真实附近边界又能多铺一层比纯 prompt 空生成强得多。三条路怎么选|真实日志业务还原合成生成贴近业务程度最高高偏低成本高中低速度慢中快答案可信度一般较好一般较好必须抽检易自动化判分通常可以通常可以看你怎么设计期望我咋用有就用没日志时的主力补量、冒烟、专项预算紧的时候我宁愿多砸时间在数据上少在报告排版上折腾——集子歪了后面全是解释成本。开源数据集能不能直接用能别当「自家标准答案」整包端上去。主流开源集子随手查数据集规模领域一句话AgentBench清华数千级通用 Agent改编多多半要对应你自家场景SWE-bench斯坦福2294代码修复公开久注意污染对照可看 LiveCodeBenchLiveCodeBench持续更新代码生成/修复题源相对「难背」适合横向比GAIAMeta514通用助手题好人判贵难进日常流水线WebArena812网页操作真站环境但只覆盖浏览器这条线ToolBench9096工具调用别当终评可当工具解析类单测TA-Bench飞书1200企业工具飞书生态偏重迁移要改编三个常见坑场景对不上。AgentBench 里「数据分析」可能是算式级别你线上是十万行周报。分 90 和线上六成失败可以同时成立——科目顺山路照样翻。数据泄露。题面进过训练集模型是「背」不是「会」。老早就有讨论公开 benchmark 与训练语料重叠会抬分。换模型、换题源前先问一句这题有没有被啃过。对 benchmark 过拟合。厂商对着公开集调参分上去、泛化未必上去。SWE-bench 上分数挤过一轮的换未公开题源常常要掉一截——不一定是模型差了是水分被挤掉了。开源集子在我这边的用法横向对比A/B 模型同一套题公平一点。混用和自建题掺在一起开源部分别太重我心里一般不超过三成权重除非你只做纯研究对标。单测例如用 ToolBench 子集盯工具描述解析不当「上线唯一依据」。终评尽量自建 日志抽样开源整包直接当 KPI这是不行的。改编可以改编完期望答案和难度标记人得重过一遍。收束能拿日志就拿日志没有就老老实实从业务还原合成当调料当主食容易营养失衡。开源集子适合对标和补洞别默认它等于你的业务。集子建完还会旧覆盖、难度、答案争议隔段时间要审计下一篇写五项检查和脚本。附三道自测题扫一眼即可Q1智能体测试和传统测试差在哪输出不固定同一条多跑几次都可能变所以更看「一类场景有没有盖住」而不是死盯「输入 A 必须等于输出 B」一条断言打天下。Q2从零开始先干啥先画自己 Agent 的能力地图哪些是核心、哪些是边缘。核心能力上把最高频问法先铺实再谈「全场景」。
