AI 能不能独立做科研这个问题从 ChatGPT 出现开始就一直被讨论但大多数讨论都停留在“AI 能帮我读文献、写代码、润色论文”这个层面。真正的问题是如果没有人类全程盯着AI 能不能自己发现问题、设计实验、跑数据、分析结论最后形成一项站得住脚的研究成果这就是清华近期备受关注的 ASI-Bench 试图回答的问题。它不是一篇科普文章而是一个面向“科学自主性”的评测基准用来衡量 AI 作为 Research Agent 到底能独立走完科研流程的哪一步。这篇文章会把 ASI-Bench 拆开来看它要评估什么、为什么传统评测基准不够用、一个科学自主性评测框架一般包含哪些维度和任务类型。同时我会从工程角度给出自建同类测试环境的完整思路包括任务数据格式、评测脚本、批量执行方式、结果聚合逻辑和常见坑。如果你以后要做 Agent 评测、给内部模型建能力基线或者只是想知道“怎么量化 AI 的科研能力”这篇文章可以直接收藏。1. ASI-Bench 核心信息速览先说结论。ASI-Bench 的定位是面向科学自主性的评测基准核心对象是具备科研执行能力的 Agent 系统而不是单轮问答模型。它想测的不是“这道题你会不会做”而是“从一道研究问题出发你能不能独立完成完整科研链路”。信息项说明项目定位科研自主性评测基准面向 Research Agent要回答的问题AI 能否独立完成科学研究的核心环节评估对象科研 Agent、论文级模型、自动推理系统区别于传统基准更关注多阶段、长链路、工具调用与决策能力典型任务类型假设生成、实验设计、数据推导、结果分析、论文写作标注方式通常结合规则校验和模型评审硬件要求取决于被测模型云端 API 或本地多卡均可是否支持 API基准本身可封装为评测服务被测模型走接口接入是否支持批量任务支持评测任务天然适合批处理适合读者LLM 应用开发者、Agent 开发者、评测工程师、科研管理相关技术人员需要说明的是这里的部分信息来自对 ASI-Bench 名称和论文定位的合理推断。如果你手上有论文全文或官方仓库属于论文明确给出的参数、数据和方法细节请以原论文和官方代码为准。下面我展开分析为什么需要这类基准以及它的评测框架会怎么搭。2. 为什么需要 ASI-Bench 这类科学自主性评测基准2.1 传统评测基准的局限传统基准比如 MMLU、GSM8K、HumanEval测的是单点能力。MMLU 测知识广度GSM8K 测数学推理HumanEval 测代码生成。它们都是“给一个问题出一个答案对一下标准结果”的封闭式评测。这种模式对模型能力的横向对比很有用但和真正的科研工作方式相差很远。科研是一个链式过程。拿到一个问题之后你需要检索和阅读相关文献识别当前方法存在的问题提出可验证的科学假设设计实验来验证假设编写代码或配置实验环境获取数据分析数据判断结果是否支持假设把结论写成论文并回应可能的质疑。传统基准没有覆盖这个链路。它只考核链路中的某个片段而且片段之间是割裂的。因此模型在 MMLU 上表现好不代表它能独自推进一项研究。2.2 Research Agent 需要新的评测维度最近一两年研究型 Agent 越来越多。有的 Agent 能读论文库辅助选题有的能自动写代码跑实验有的能生成论文初稿。但评测一个 Agent 是否“能科研”需要一套更完整的指标体系。ASI-Bench 的核心贡献就是把这个“更完整的指标体系”提出来让评测从“答题正确率”升级为“科研自主度”。科研自主度可以拆成几个关键维度任务分解能力面对一个开放式问题能否拆出合理的工作步骤工具调用能力是否会调用搜索引擎、文献数据库、代码解释器、绘图工具条件约束能力在预算、时间、算力资源有限的情况下能否选择可行方案推理可追溯性每一步决策是否有文献依据或逻辑依据结果可验证性最终输出能否被独立验证而不是自说自话。一个设计良好的评分体系应该让以上五个维度都有可量化的观测点。3. ASI-Bench 评测框架的设计思路关于 ASI-Bench 的具体网络架构和评分权重我这里没有看到完整论文内容所以不做编造。但一个面向科学自主性的评测基准在通用设计思路上通常有这些阶段。3.1 科学自主性分层评测基准首先需要定义“自主”的等级。常见分层方法是按人类干预程度划分层级定义人类参与程度L1工具增强型人类全程决策AI 只做检索、生成辅助内容L2局部自主型人类设定目标AI 完成部分子任务例如假设生成或实验代码L3流程自主型人类只提供资源和约束AI 完成实验设计到结果分析L4完全自主型AI 自主发现问题、设定研究计划、执行并产出论文人类只做最终确认ASI-Bench 这类基准要测的核心层级大概是 L2 到 L4。评测时会给 Agent 一个研究问题描述、一套可用的工具接口和资源然后记录它的行为链路而不是只看最终答案。3.2 评测任务类型设计按科研流程划分任务类型可以包括文献综述与问题定位给定一个研究领域让 Agent 总结研究现状找出至少一个值得深入的问题。假设生成给定背景材料和数据让 Agent 提出可检验的假设并说明检验方式。实验方案设计给定研究目标和可用资源让 Agent 设计实验组、对照组、变量控制方案。数据处理与结果分析给定一份模拟或真实数据集让 Agent 完成清洗、统计检验和结论提取。图表解读给出一张论文图表让 Agent 解释其含义并指出可能存在的误导。论文写作与润色给定研究数据和分析结果让 Agent 撰写结构化摘要或完成论文某个章节。每个任务都要有明确的输入、预期输出格式和评分标准。如果评分标准不明确模型能力的差异就无法被稳定测量。4. 一套可落地的 Research Agent 评测数据格式无论 ASI-Bench 官方如何组织数据站在工程角度一个可扩展的评测基准应当使用结构化的任务格式。下面给出一个通用 JSON 任务格式你可以按自己的项目需要调整。{ task_id: asi_bench_0001, phase: experiment_design, domain: computational_biology, difficulty: medium, background: 给定一个基因表达数据集目标是判断某种药物处理是否显著改变特定通路活性。, question: 设计一个完整的分析流程包含数据预处理、差异表达分析、通路富集分析和可视化方案。, resources: [ data/expression_counts.csv, data/metadata.csv, docs/ref_papers.md ], constraints: [ 必须给出每一步可执行的代码或伪代码, 必须说明每一步的输入输出格式, 流程总步数不超过 8 步 ], expected_output: { type: markdown, structure: [overview, pipeline_steps, expected_charts, quality_control] }, judge: { method: rule_and_llm, rules: [步骤完整性, 合理性, 可执行性], llm_system_prompt: 你是一名计算生物学专家请从方法论合理性角度评价以下实验设计方案。 } }这个格式的好处是任务创建、模型调用、结果评分三个阶段完全解耦。测试时替换question和judge字段就能快速扩展新任务。5. 自建 ASI-Bench 风格评测流水线拿到上面的任务格式下一步是搭评测流水线。这里提供一个最小可运行的设计被评测对象假设是任意支持对话补全的 LLM API。5.1 评测流水线整体结构tasks.json - task_loader读取任务 - agent_runner调用被测模型收集回复 - judge规则评分 LLM 评审 - report汇总输出 CSV/JSON5.2 Python 评测脚本示例下面是一个通用评测脚本你需要按实际模型接口调整请求方式和认证信息。# eval_pipeline.py # 通用 Research Agent 评测脚本使用前请替换模型 API 配置 import json import time from datetime import datetime def load_tasks(path: str) - list: with open(path, r, encodingutf-8) as f: return json.load(f) def build_user_prompt(task: dict) - str: prompt f研究背景{task[background]}\n prompt f研究问题{task[question]}\n prompt 约束条件\n for c in task.get(constraints, []): prompt f- {c}\n prompt \n请按照 expected_output 的结构输出结果。 return prompt def call_agent(task: dict, api_config: dict) - str: # 这里替换为目标模型的真实调用方法 # 示例使用的是 OpenAI 兼容接口实际项目按自己的端点和 key 调整 import openai client openai.OpenAI( api_keyapi_config[api_key], base_urlapi_config[base_url] ) response client.chat.completions.create( modelapi_config[model_name], messages[ {role: user, content: build_user_prompt(task)} ], temperature0.2, max_tokens2048 ) return response.choices[0].message.content def run_eval(task_file: str, api_config: dict, output_file: str): tasks load_tasks(task_file) results [] start_time datetime.now() for idx, task in enumerate(tasks, 1): task_start time.time() try: agent_output call_agent(task, api_config) success True error except Exception as e: agent_output success False error str(e) elapsed time.time() - task_start results.append({ task_id: task[task_id], phase: task.get(phase), success: success, elapsed_sec: round(elapsed, 2), output: agent_output, error: error }) print(f[{idx}/{len(tasks)}] {task[task_id]} success{success} time{elapsed:.1f}s) summary { total: len(results), success_count: sum(r[success] for r in results), start_time: start_time.isoformat(), end_time: datetime.now().isoformat() } with open(output_file, w, encodingutf-8) as f: json.dump({summary: summary, results: results}, f, ensure_asciiFalse, indent2) print(f评测完成结果已写入 {output_file}) if __name__ __main__: # 实际运行前请替换这些配置 run_eval( task_filetasks.json, api_config{ api_key: YOUR_API_KEY, base_url: https://YOUR_ENDPOINT/v1, model_name: YOUR_MODEL_NAME }, output_fileeval_results.json )5.3 命令行启动评测# 启动评测 python eval_pipeline.py # 如果只需要跑其中一个阶段 python eval_pipeline.py --filter phaseexperiment_design实际项目里可以在脚本里加参数解析比如task_file、model_name、concurrency、output_dir。6. 批量任务与并发执行ASI-Bench 这类评测通常有几十到几百个任务。逐个串行跑会很慢尤其是本地部署大模型时。正确做法是引入并发执行和失败重试。6.1 并发评测设计# batch_runner.py # 批量评测任务的并发执行示例 import json import time from concurrent.futures import ThreadPoolExecutor, as_completed def process_one(task, api_config): # process_one 内部调用 call_agent见前文 try: output call_agent(task, api_config) return {task_id: task[task_id], status: ok, output: output} except Exception as exc: return {task_id: task[task_id], status: failed, error: str(exc)} def run_batch(tasks, api_config, workers4, max_retry2): results [] for attempt in range(max_retry): pending [t for t in tasks if t.get(_status) ! ok] if not pending: break with ThreadPoolExecutor(max_workersworkers) as executor: future_map {executor.submit(process_one, task, api_config): task for task in pending} for future in as_completed(future_map): result future.result() if result[status] ok: results.append(result) else: task future_map[future] # 记录重试信息 task[_status] retry task[_last_error] result[error] # 超过重试次数后放弃 if attempt max_retry - 1: results.append({ task_id: task[task_id], status: failed, error: result[error] }) time.sleep(2) # 防止过快请求导致限流 return results6.2 批量评测注意事项API 有速率限制时并发数不要开太大先试workers4本地推理模型时显存不够就降低并发或改用批量推理每个任务都要记录elapsed_sec和status方便统计超时和失败评测结果分文件保存一次评测一个文件避免丢失。7. 评测结果的判定与质量观察7.1 评分策略评分是评测基准的核心也是争议最大的部分。常见方案有两种规则评分和模型评分。规则评分适合有明确答案的任务比如“流程是否包含差异表达分析”“是否输出可视化代码”。优点是稳定、可复现缺点是覆盖不了开放性问题。模型评分适合论文写作、方案合理性这类任务。做法是让一个强 LLM 扮演领域专家按评分维度输出分数和理由。优点是灵活缺点是可能存在评分者偏差因此需要多次采样取平均。一个稳妥的方案是两者结合{ judge: { method: hybrid, rules: [ {name: 步骤完整性, weight: 0.3}, {name: 可执行性, weight: 0.3} ], llm: { model: judge_model, dimensions: [逻辑性, 创新性, 内容与背景相关性], sampling_times: 3 } } }7.2 解读结果时重点观察什么成功率多少任务没有返回结果或直接报错平均响应时间反映 Agent 的推理效率阶段性失败率哪个科研阶段失败率最高说明 Agent 在该能力上存在短板结果方差不同任务之间表现波动大不大幻觉比例输出内容里存在多少编造的数据或引用。8. 常见问题与排查方法自建 Research Agent 评测流水线会遇到各种问题这里整理一份排查清单。问题现象可能原因排查方式解决方案评测任务加载失败JSON 格式错误或字段缺失检查任务文件并用 json.tool 校验补全必填字段统一 schema大量任务超时模型响应过慢或上下文过长查看耗时分布定位超时任务减小 max_tokens、降低并发或增加超时阈值模型接口调用失败API key 错误、接口地址不对、限流先用 curl 验证接口连通性检查配置按说明重试输出内容不完整上下文窗口不足检查报错信息里的 token 数截断背景材料或改用支持长上下文的模型评分结果不稳定模型评分采样次数不足多次运行对比评分分布增加采样次数降低 temperature评测结果无法复现模型设置为非确定性推理固定 seed 和 temperature统一推理参数设置 temperature0本地推理显存不足模型参数量过大查看显存监控日志换小模型或开启量化推理批量任务某个阶段卡死Agent 进入循环或死锁查看日志中的重复调用增加步数上限、循环检测和超时中断9. 使用边界与合规注意事项ASI-Bench 这类基准讨论的是“AI 做科研”但这不意味着 AI 生成的结论可以直接作为科学结论发布。在工程应用和科研流程里必须明确以下边界。数据授权评测任务里用到的论文、数据集、图表必须确认具有合法使用和再分发权限。隐私保护如果任务数据涉及患者信息、个人信息或未公开实验数据任何环节都不应脱离授权环境处理。学术诚信AI 辅助生成论文内容可以但作者署名、数据真实性、实验可复现性仍是研究者的责任。发布前必须复核 AI 生成的结果确认没有编造实验数据或虚假引用。版权边界模型可能从训练数据中学到受版权保护的表达生成内容用于商用前要做查重和来源核对。测试环境安全本地部署模型时做实验和评测的服务器尽量与生产环境隔离避免测试脚本误操作影响线上服务。避免不当用途任何将 AI 技术用于伪造数据、规避检测、生成误导性科研内容的行为都不可接受。评测基准本身是中性工具衡量 AI 能力上限。技术使用者要在真实科研场景中守住合规底线。10. 最佳实践构建高质量 Research Agent 评测如果你按照 ASI-Bench 的思路自建一套评测体系下面几点是实际项目中比较有用的做法。第一先小规模试跑。不要一上来就设计 500 道题全量跑。先选 20 到 30 道覆盖各阶段的题目跑通流程后再扩展。第二任务难度要有梯度。全部是难题会拉不开模型差距全部是简单题又会造成分数虚高。按难度分层设计才能更好地区分模型能力。第三评分标准要提前固化。如果评测目标是横向对比模型评分维度、权重和规则在评测过程中不能随意改动否则结果不可比。第四每道任务要有“参考答案”或“参考评分点”。没有参考信息模型评分容易天马行空有参考评分点才能保证不同模型输出被公平比较。第五保留完整日志。Agent 调用历史、模型输出、评分记录、错误信息都要落盘方便事后复现问题。评测工程最大的坑不是模型不行而是结果出问题时查不到原因。第六做好任务库版本管理。任务文件用 Git 管理每次改动记录版本。这样模型升级后回测可以清楚知道基线变化是因为模型还是因为评测任务改了。11. AI 科研自主性的评测难点即使是 ASI-Bench 这类基准要准确衡量 AI 的科研自主性依然有几个很难绕开的难点。一是科研任务很难被完全标准化。真实科研充满偶然性一个实验失败可能转向另一个方向这个过程中 Agent 的决策是否合理很难用固定的评分项覆盖。二是存在数据泄漏风险。如果基准任务基于公开论文数据设计模型在训练时可能已经见过类似问题测试结果会被高估。三是“自主性”和“正确性”不完全等价。一个 Agent 可能做了很多自主决策但方向全错另一个 Agent 可能每一步都问人最终结果反而更可靠。基准需要同时考核自主程度和结果质量。四是长链路评测的成本问题。完整的科研 Agent 评测需要多次模型调用、工具调用和临时文件读写单个任务的成本可能是普通问答评测的几十倍。做评测预算时要把这个成本考虑进去。这些问题不只是 ASI-Bench 一家面临的整个 Agent 评测领域都在探索更好的方案。12. 下一步可以怎么做如果你对 AI 科研自主性感兴趣建议从两个方向入手。研究方向读 ASI-Bench 论文原文关注它的任务设计、指标体系和实验设置。重点关注它选用了哪些科研领域、哪些任务类型、如何计算综合得分。这些信息能直接用来改进自己的评测思路。工程方向用上面的通用评测框架先搭一个最小验证闭环。找几个测试任务跑两个能力差距明显的模型看评测结果能不能稳定区分它们。跑通之后再逐步扩展任务数量和评分维度。从实际使用角度看ASI-Bench 这类基准最大的价值不是给出一个排行榜而是把“AI 能不能做科研”这个口号式问题变成了可量化、可比较、可迭代的工程问题。对做 Agent 的人来说这种转变比争论 AI 是否具备意识更有意义。先跑通一个最小闭环再谈完善。这是做评测最实用的起点。
ASI-Bench全解析：如何评测AI科研自主性与搭建Agent评测流水线
AI 能不能独立做科研这个问题从 ChatGPT 出现开始就一直被讨论但大多数讨论都停留在“AI 能帮我读文献、写代码、润色论文”这个层面。真正的问题是如果没有人类全程盯着AI 能不能自己发现问题、设计实验、跑数据、分析结论最后形成一项站得住脚的研究成果这就是清华近期备受关注的 ASI-Bench 试图回答的问题。它不是一篇科普文章而是一个面向“科学自主性”的评测基准用来衡量 AI 作为 Research Agent 到底能独立走完科研流程的哪一步。这篇文章会把 ASI-Bench 拆开来看它要评估什么、为什么传统评测基准不够用、一个科学自主性评测框架一般包含哪些维度和任务类型。同时我会从工程角度给出自建同类测试环境的完整思路包括任务数据格式、评测脚本、批量执行方式、结果聚合逻辑和常见坑。如果你以后要做 Agent 评测、给内部模型建能力基线或者只是想知道“怎么量化 AI 的科研能力”这篇文章可以直接收藏。1. ASI-Bench 核心信息速览先说结论。ASI-Bench 的定位是面向科学自主性的评测基准核心对象是具备科研执行能力的 Agent 系统而不是单轮问答模型。它想测的不是“这道题你会不会做”而是“从一道研究问题出发你能不能独立完成完整科研链路”。信息项说明项目定位科研自主性评测基准面向 Research Agent要回答的问题AI 能否独立完成科学研究的核心环节评估对象科研 Agent、论文级模型、自动推理系统区别于传统基准更关注多阶段、长链路、工具调用与决策能力典型任务类型假设生成、实验设计、数据推导、结果分析、论文写作标注方式通常结合规则校验和模型评审硬件要求取决于被测模型云端 API 或本地多卡均可是否支持 API基准本身可封装为评测服务被测模型走接口接入是否支持批量任务支持评测任务天然适合批处理适合读者LLM 应用开发者、Agent 开发者、评测工程师、科研管理相关技术人员需要说明的是这里的部分信息来自对 ASI-Bench 名称和论文定位的合理推断。如果你手上有论文全文或官方仓库属于论文明确给出的参数、数据和方法细节请以原论文和官方代码为准。下面我展开分析为什么需要这类基准以及它的评测框架会怎么搭。2. 为什么需要 ASI-Bench 这类科学自主性评测基准2.1 传统评测基准的局限传统基准比如 MMLU、GSM8K、HumanEval测的是单点能力。MMLU 测知识广度GSM8K 测数学推理HumanEval 测代码生成。它们都是“给一个问题出一个答案对一下标准结果”的封闭式评测。这种模式对模型能力的横向对比很有用但和真正的科研工作方式相差很远。科研是一个链式过程。拿到一个问题之后你需要检索和阅读相关文献识别当前方法存在的问题提出可验证的科学假设设计实验来验证假设编写代码或配置实验环境获取数据分析数据判断结果是否支持假设把结论写成论文并回应可能的质疑。传统基准没有覆盖这个链路。它只考核链路中的某个片段而且片段之间是割裂的。因此模型在 MMLU 上表现好不代表它能独自推进一项研究。2.2 Research Agent 需要新的评测维度最近一两年研究型 Agent 越来越多。有的 Agent 能读论文库辅助选题有的能自动写代码跑实验有的能生成论文初稿。但评测一个 Agent 是否“能科研”需要一套更完整的指标体系。ASI-Bench 的核心贡献就是把这个“更完整的指标体系”提出来让评测从“答题正确率”升级为“科研自主度”。科研自主度可以拆成几个关键维度任务分解能力面对一个开放式问题能否拆出合理的工作步骤工具调用能力是否会调用搜索引擎、文献数据库、代码解释器、绘图工具条件约束能力在预算、时间、算力资源有限的情况下能否选择可行方案推理可追溯性每一步决策是否有文献依据或逻辑依据结果可验证性最终输出能否被独立验证而不是自说自话。一个设计良好的评分体系应该让以上五个维度都有可量化的观测点。3. ASI-Bench 评测框架的设计思路关于 ASI-Bench 的具体网络架构和评分权重我这里没有看到完整论文内容所以不做编造。但一个面向科学自主性的评测基准在通用设计思路上通常有这些阶段。3.1 科学自主性分层评测基准首先需要定义“自主”的等级。常见分层方法是按人类干预程度划分层级定义人类参与程度L1工具增强型人类全程决策AI 只做检索、生成辅助内容L2局部自主型人类设定目标AI 完成部分子任务例如假设生成或实验代码L3流程自主型人类只提供资源和约束AI 完成实验设计到结果分析L4完全自主型AI 自主发现问题、设定研究计划、执行并产出论文人类只做最终确认ASI-Bench 这类基准要测的核心层级大概是 L2 到 L4。评测时会给 Agent 一个研究问题描述、一套可用的工具接口和资源然后记录它的行为链路而不是只看最终答案。3.2 评测任务类型设计按科研流程划分任务类型可以包括文献综述与问题定位给定一个研究领域让 Agent 总结研究现状找出至少一个值得深入的问题。假设生成给定背景材料和数据让 Agent 提出可检验的假设并说明检验方式。实验方案设计给定研究目标和可用资源让 Agent 设计实验组、对照组、变量控制方案。数据处理与结果分析给定一份模拟或真实数据集让 Agent 完成清洗、统计检验和结论提取。图表解读给出一张论文图表让 Agent 解释其含义并指出可能存在的误导。论文写作与润色给定研究数据和分析结果让 Agent 撰写结构化摘要或完成论文某个章节。每个任务都要有明确的输入、预期输出格式和评分标准。如果评分标准不明确模型能力的差异就无法被稳定测量。4. 一套可落地的 Research Agent 评测数据格式无论 ASI-Bench 官方如何组织数据站在工程角度一个可扩展的评测基准应当使用结构化的任务格式。下面给出一个通用 JSON 任务格式你可以按自己的项目需要调整。{ task_id: asi_bench_0001, phase: experiment_design, domain: computational_biology, difficulty: medium, background: 给定一个基因表达数据集目标是判断某种药物处理是否显著改变特定通路活性。, question: 设计一个完整的分析流程包含数据预处理、差异表达分析、通路富集分析和可视化方案。, resources: [ data/expression_counts.csv, data/metadata.csv, docs/ref_papers.md ], constraints: [ 必须给出每一步可执行的代码或伪代码, 必须说明每一步的输入输出格式, 流程总步数不超过 8 步 ], expected_output: { type: markdown, structure: [overview, pipeline_steps, expected_charts, quality_control] }, judge: { method: rule_and_llm, rules: [步骤完整性, 合理性, 可执行性], llm_system_prompt: 你是一名计算生物学专家请从方法论合理性角度评价以下实验设计方案。 } }这个格式的好处是任务创建、模型调用、结果评分三个阶段完全解耦。测试时替换question和judge字段就能快速扩展新任务。5. 自建 ASI-Bench 风格评测流水线拿到上面的任务格式下一步是搭评测流水线。这里提供一个最小可运行的设计被评测对象假设是任意支持对话补全的 LLM API。5.1 评测流水线整体结构tasks.json - task_loader读取任务 - agent_runner调用被测模型收集回复 - judge规则评分 LLM 评审 - report汇总输出 CSV/JSON5.2 Python 评测脚本示例下面是一个通用评测脚本你需要按实际模型接口调整请求方式和认证信息。# eval_pipeline.py # 通用 Research Agent 评测脚本使用前请替换模型 API 配置 import json import time from datetime import datetime def load_tasks(path: str) - list: with open(path, r, encodingutf-8) as f: return json.load(f) def build_user_prompt(task: dict) - str: prompt f研究背景{task[background]}\n prompt f研究问题{task[question]}\n prompt 约束条件\n for c in task.get(constraints, []): prompt f- {c}\n prompt \n请按照 expected_output 的结构输出结果。 return prompt def call_agent(task: dict, api_config: dict) - str: # 这里替换为目标模型的真实调用方法 # 示例使用的是 OpenAI 兼容接口实际项目按自己的端点和 key 调整 import openai client openai.OpenAI( api_keyapi_config[api_key], base_urlapi_config[base_url] ) response client.chat.completions.create( modelapi_config[model_name], messages[ {role: user, content: build_user_prompt(task)} ], temperature0.2, max_tokens2048 ) return response.choices[0].message.content def run_eval(task_file: str, api_config: dict, output_file: str): tasks load_tasks(task_file) results [] start_time datetime.now() for idx, task in enumerate(tasks, 1): task_start time.time() try: agent_output call_agent(task, api_config) success True error except Exception as e: agent_output success False error str(e) elapsed time.time() - task_start results.append({ task_id: task[task_id], phase: task.get(phase), success: success, elapsed_sec: round(elapsed, 2), output: agent_output, error: error }) print(f[{idx}/{len(tasks)}] {task[task_id]} success{success} time{elapsed:.1f}s) summary { total: len(results), success_count: sum(r[success] for r in results), start_time: start_time.isoformat(), end_time: datetime.now().isoformat() } with open(output_file, w, encodingutf-8) as f: json.dump({summary: summary, results: results}, f, ensure_asciiFalse, indent2) print(f评测完成结果已写入 {output_file}) if __name__ __main__: # 实际运行前请替换这些配置 run_eval( task_filetasks.json, api_config{ api_key: YOUR_API_KEY, base_url: https://YOUR_ENDPOINT/v1, model_name: YOUR_MODEL_NAME }, output_fileeval_results.json )5.3 命令行启动评测# 启动评测 python eval_pipeline.py # 如果只需要跑其中一个阶段 python eval_pipeline.py --filter phaseexperiment_design实际项目里可以在脚本里加参数解析比如task_file、model_name、concurrency、output_dir。6. 批量任务与并发执行ASI-Bench 这类评测通常有几十到几百个任务。逐个串行跑会很慢尤其是本地部署大模型时。正确做法是引入并发执行和失败重试。6.1 并发评测设计# batch_runner.py # 批量评测任务的并发执行示例 import json import time from concurrent.futures import ThreadPoolExecutor, as_completed def process_one(task, api_config): # process_one 内部调用 call_agent见前文 try: output call_agent(task, api_config) return {task_id: task[task_id], status: ok, output: output} except Exception as exc: return {task_id: task[task_id], status: failed, error: str(exc)} def run_batch(tasks, api_config, workers4, max_retry2): results [] for attempt in range(max_retry): pending [t for t in tasks if t.get(_status) ! ok] if not pending: break with ThreadPoolExecutor(max_workersworkers) as executor: future_map {executor.submit(process_one, task, api_config): task for task in pending} for future in as_completed(future_map): result future.result() if result[status] ok: results.append(result) else: task future_map[future] # 记录重试信息 task[_status] retry task[_last_error] result[error] # 超过重试次数后放弃 if attempt max_retry - 1: results.append({ task_id: task[task_id], status: failed, error: result[error] }) time.sleep(2) # 防止过快请求导致限流 return results6.2 批量评测注意事项API 有速率限制时并发数不要开太大先试workers4本地推理模型时显存不够就降低并发或改用批量推理每个任务都要记录elapsed_sec和status方便统计超时和失败评测结果分文件保存一次评测一个文件避免丢失。7. 评测结果的判定与质量观察7.1 评分策略评分是评测基准的核心也是争议最大的部分。常见方案有两种规则评分和模型评分。规则评分适合有明确答案的任务比如“流程是否包含差异表达分析”“是否输出可视化代码”。优点是稳定、可复现缺点是覆盖不了开放性问题。模型评分适合论文写作、方案合理性这类任务。做法是让一个强 LLM 扮演领域专家按评分维度输出分数和理由。优点是灵活缺点是可能存在评分者偏差因此需要多次采样取平均。一个稳妥的方案是两者结合{ judge: { method: hybrid, rules: [ {name: 步骤完整性, weight: 0.3}, {name: 可执行性, weight: 0.3} ], llm: { model: judge_model, dimensions: [逻辑性, 创新性, 内容与背景相关性], sampling_times: 3 } } }7.2 解读结果时重点观察什么成功率多少任务没有返回结果或直接报错平均响应时间反映 Agent 的推理效率阶段性失败率哪个科研阶段失败率最高说明 Agent 在该能力上存在短板结果方差不同任务之间表现波动大不大幻觉比例输出内容里存在多少编造的数据或引用。8. 常见问题与排查方法自建 Research Agent 评测流水线会遇到各种问题这里整理一份排查清单。问题现象可能原因排查方式解决方案评测任务加载失败JSON 格式错误或字段缺失检查任务文件并用 json.tool 校验补全必填字段统一 schema大量任务超时模型响应过慢或上下文过长查看耗时分布定位超时任务减小 max_tokens、降低并发或增加超时阈值模型接口调用失败API key 错误、接口地址不对、限流先用 curl 验证接口连通性检查配置按说明重试输出内容不完整上下文窗口不足检查报错信息里的 token 数截断背景材料或改用支持长上下文的模型评分结果不稳定模型评分采样次数不足多次运行对比评分分布增加采样次数降低 temperature评测结果无法复现模型设置为非确定性推理固定 seed 和 temperature统一推理参数设置 temperature0本地推理显存不足模型参数量过大查看显存监控日志换小模型或开启量化推理批量任务某个阶段卡死Agent 进入循环或死锁查看日志中的重复调用增加步数上限、循环检测和超时中断9. 使用边界与合规注意事项ASI-Bench 这类基准讨论的是“AI 做科研”但这不意味着 AI 生成的结论可以直接作为科学结论发布。在工程应用和科研流程里必须明确以下边界。数据授权评测任务里用到的论文、数据集、图表必须确认具有合法使用和再分发权限。隐私保护如果任务数据涉及患者信息、个人信息或未公开实验数据任何环节都不应脱离授权环境处理。学术诚信AI 辅助生成论文内容可以但作者署名、数据真实性、实验可复现性仍是研究者的责任。发布前必须复核 AI 生成的结果确认没有编造实验数据或虚假引用。版权边界模型可能从训练数据中学到受版权保护的表达生成内容用于商用前要做查重和来源核对。测试环境安全本地部署模型时做实验和评测的服务器尽量与生产环境隔离避免测试脚本误操作影响线上服务。避免不当用途任何将 AI 技术用于伪造数据、规避检测、生成误导性科研内容的行为都不可接受。评测基准本身是中性工具衡量 AI 能力上限。技术使用者要在真实科研场景中守住合规底线。10. 最佳实践构建高质量 Research Agent 评测如果你按照 ASI-Bench 的思路自建一套评测体系下面几点是实际项目中比较有用的做法。第一先小规模试跑。不要一上来就设计 500 道题全量跑。先选 20 到 30 道覆盖各阶段的题目跑通流程后再扩展。第二任务难度要有梯度。全部是难题会拉不开模型差距全部是简单题又会造成分数虚高。按难度分层设计才能更好地区分模型能力。第三评分标准要提前固化。如果评测目标是横向对比模型评分维度、权重和规则在评测过程中不能随意改动否则结果不可比。第四每道任务要有“参考答案”或“参考评分点”。没有参考信息模型评分容易天马行空有参考评分点才能保证不同模型输出被公平比较。第五保留完整日志。Agent 调用历史、模型输出、评分记录、错误信息都要落盘方便事后复现问题。评测工程最大的坑不是模型不行而是结果出问题时查不到原因。第六做好任务库版本管理。任务文件用 Git 管理每次改动记录版本。这样模型升级后回测可以清楚知道基线变化是因为模型还是因为评测任务改了。11. AI 科研自主性的评测难点即使是 ASI-Bench 这类基准要准确衡量 AI 的科研自主性依然有几个很难绕开的难点。一是科研任务很难被完全标准化。真实科研充满偶然性一个实验失败可能转向另一个方向这个过程中 Agent 的决策是否合理很难用固定的评分项覆盖。二是存在数据泄漏风险。如果基准任务基于公开论文数据设计模型在训练时可能已经见过类似问题测试结果会被高估。三是“自主性”和“正确性”不完全等价。一个 Agent 可能做了很多自主决策但方向全错另一个 Agent 可能每一步都问人最终结果反而更可靠。基准需要同时考核自主程度和结果质量。四是长链路评测的成本问题。完整的科研 Agent 评测需要多次模型调用、工具调用和临时文件读写单个任务的成本可能是普通问答评测的几十倍。做评测预算时要把这个成本考虑进去。这些问题不只是 ASI-Bench 一家面临的整个 Agent 评测领域都在探索更好的方案。12. 下一步可以怎么做如果你对 AI 科研自主性感兴趣建议从两个方向入手。研究方向读 ASI-Bench 论文原文关注它的任务设计、指标体系和实验设置。重点关注它选用了哪些科研领域、哪些任务类型、如何计算综合得分。这些信息能直接用来改进自己的评测思路。工程方向用上面的通用评测框架先搭一个最小验证闭环。找几个测试任务跑两个能力差距明显的模型看评测结果能不能稳定区分它们。跑通之后再逐步扩展任务数量和评分维度。从实际使用角度看ASI-Bench 这类基准最大的价值不是给出一个排行榜而是把“AI 能不能做科研”这个口号式问题变成了可量化、可比较、可迭代的工程问题。对做 Agent 的人来说这种转变比争论 AI 是否具备意识更有意义。先跑通一个最小闭环再谈完善。这是做评测最实用的起点。
