数据截至 (上游 commit f72f75d8c3eb)
04 · 评测闭环
本章讲「怎么知道 agent 答得对不对」:多次采样 → 裁判模型判分 → Pass@k 统计。这是评测 agentic 能力的标准套路,细节在
run_multi_react.py和evaluation/。
3.1 为什么要跑多次(rollout)
深度研究是随机的——temperature=0.6、搜索结果随时间变,同一道题跑两次可能一次对一次错。所以评测要跑多次取统计量。run_multi_react.py 默认 roll_out_count=3(run_multi_react.py:22),每道题独立跑 3 次,结果分别落 iter1.jsonl / iter2.jsonl / iter3.jsonl(run_multi_react.py:87-89)。
3.2 并发调度:线程池 + 粘性端口
run_multi_react.py 用 ThreadPoolExecutor(默认 20 worker)把所有 (题, rollout) 任务并发跑(run_multi_react.py:174-181)。
巧妙处 —— 粘性端口分配(run_multi_react.py:117-140): 有 8 个 vLLM 端口(6001-6008)。同一道题的所有 rollout 固定分到同一个端口(question_to_ports 缓存),不同题用轮询(round-robin)均摊。好处:同题请求命中同一服务实例,可复用 KV cache、负载也均衡。
还有断点续跑:启动时扫已有 iterN.jsonl,把已成功(有 question、无 error)的题记进 processed_queries,跳过不重跑(run_multi_react.py:93-108、134)。
3.3 打分:LLM-as-judge
模型输出的是自然语言答案,不能字符串精确匹配(「巴黎」vs「Paris, France」)。所以用一个裁判模型读「问题 + 参考答案 + 模型预测」,判等价与否。核心在 evaluate_deepsearch_official.py:76-144(call_llm_judge)。
巧妙处 —— 裁判模型按数据集切换(evaluate_deepsearch_official.py:461-476): 不同基准用不同裁判和不同提示词:
| 数据集 | 裁判模型 | 判分提示词 |
|---|---|---|
| gaia / webwalker | qwen2.5-72b-instruct | JUDGE_PROMPT_GAIA |
| xbench-deepsearch | gemini-2.0-flash-001 | JUDGE_PROMPT_XBENCH(中文,结论=正确/错误) |
| browsecomp_zh / _en | gpt-4o-2024-08-06 | JUDGE_PROMPT_BROWSECOMP_OFFICIAL |
browsecomp 还用 OpenAI 的 structured output(response_format 强制 JSON schema,evaluate_deepsearch_official.py:33-51,107-118),让裁判必须吐出 {correct: yes/no, confidence, …},再据 correct 字段定对错——比让模型自由发挥更稳。
判定「算对」的逻辑很宽松(evaluate_deepsearch_official.py:72-73):裁判输出等于 "correct",或首字母是 a(对应 GAIA 提示词里的选项 A)即判对。
3.4 Pass@k 怎么算
有了 3 轮的对错,算三种指标(evaluate_deepsearch_official.py:405-445):
| 指标 | 含义 | 怎么算 |
|---|---|---|
| Pass@3 | 3 次里任一次对就算这题解决 | calculate_pass_at_k(k=3) |
| Best Pass@1 | 三轮各自 Pass@1 里最高的那轮 | calculate_best_pass_at_1 |
| Avg Pass@3 | 三轮 Pass@1 的平均 | calculate_avg_pass_at_3 |
Pass@3 衡量「能力上限」(多试几次能不能对),Avg Pass@1 衡量「单次稳定性」——两者一起看才不被单次运气误导。
3.5 顺带算的行为统计
评测脚本 还从轨迹里挖了一堆行为指标(single_round_statistics, evaluate_deepsearch_official.py:209-325):平均动作数、平均 visit/search 次数、答案长度、思考(<think>)长度、每题 assistant token 数、终止原因分布……这些用来分析「答对的题通常调了几次工具」(calculate_enhanced_statistics, evaluate_deepsearch_official.py:328-379)——即效率画像,而不只是准确率。
3.6 另一条评测线:HLE
evaluation/evaluate_hle_official.py 是给 Humanity's Last Exam 单独准备的官方评测脚本(README 的 evaluation 段提到它走 eval_hle_old_react.py 入口)。它与 deepsearch 那条并列,针对 HLE 的判分口径。本文档聚焦主线 deepsearch 评测;HLE 细节按需读该文件。
代码地图
| 主题 | 文件路径 | 符号名 |
|---|---|---|
| 多 rollout 调度 + 粘性端口 | inference/run_multi_react.py | question_to_ports、ThreadPoolExecutor 段 |
| 断点续跑 | inference/run_multi_react.py | processed_queries_per_rollout |
| LLM 裁判判分 | evaluation/evaluate_deepsearch_official.py | call_llm_judge |
| 按数据集选裁判 | evaluation/evaluate_deepsearch_official.py | main(judge_model 分支) |
| 是否算对 | evaluation/evaluate_deepsearch_official.py | is_correct_judgement |
| Pass@k 指标 | evaluation/evaluate_deepsearch_official.py | calculate_pass_at_k、calculate_avg_pass_at_3 |
| 行为统计 | evaluation/evaluate_deepsearch_official.py | single_round_statistics |
| 判分提示词 | evaluation/prompt.py | JUDGE_PROMPT_GAIA、JUDGE_PROMPT_BROWSECOMP_OFFICIAL、JUDGE_PROMPT_XBENCH |