TRACES 基准的核心目标是把“AI 探索性研究过程”从黑盒变成可审计的过程数据。传统评测往往只关心最终答案正确与否但在研究型任务中同一个结论可以由质量完全不同的过程产生有的经过多轮检索、交叉验证和反例排除有的只是模型凭记忆直接生成。后者即使答案正确也无法满足科研、审计、合规等场景对可信度的要求。本文围绕 TRACES 基准要回答的问题展开如何评估一个 AI 在研究任务中的探索过程是否完整、忠实、可复现。文中会给出评估框架、trace 数据契约、一个最小 Python 评分实现以及实际落地时最容易踩的几个坑和对应排查路径。1. TRACES 基准要解决什么问题从结果评测走向过程评测1.1 为什么只看最终答案不够在普通问答任务里答案本身就能反映模型能力答对了就是会答错了就是不会。但探索性研究任务不一样典型表现是“结论相同路径天差地远”。例如让 AI 分析一个开源项目为什么频繁出现内存告警。低质量过程可能是模型直接凭训练记忆列出一串原因甚至编造了不存在的接口名高质量过程应该是先拿到告警日志再定位到具体类和方法查证引用计数或对象生命周期最后才能给出结论。两者最终都输出了“可能存在内存泄漏”可是后者才经得起追问你在哪一步看到的崩溃日志哪些代码证据支撑这个判断有没有排查过其他可能性TRACES 基准强调“可审计”正是因为研究任务里过程比结果更值得信任。过程可审计意味着每一步都有输入和输出可以重新执行。每个结论都能回溯到具体证据。即使结论错了也能从轨迹里定位到哪一步推理出了问题。大模型在生成答案时会出现 AI 幻觉编造来源、拼凑引用是常见现象。结果评测很难发现这种问题因为幻觉经常不影响最终答案的措辞只有把过程拉开看才能看到引用列表里是否混入了不存在的链接、检索步骤是否真的发生过。1.2 可审计的探索性研究过程包含哪些环节探索性研究没有一个万能流程但可以抽象出几个通用阶段。TRACES 基准在设计任务时通常会把这些阶段作为评测对象阶段关键行为审计点计划把研究任务拆成子问题计划是否可执行是否覆盖任务核心检索查找相关资料、代码、日志检索词是什么返回了哪些来源是否去重取证阅读资料并摘录关键证据是否有原文引用引用是否被曲解推理结合证据推导排除反例推理链条是否连续是否存在跳跃结论输出最终答案和研究说明结论是否与前面证据链一致是否声明局限每个阶段至少要记录四个字段输入、输出、引用来源、发生时间。只有记录完整审计员才能回答“AI 为什么在这里这么想”。1.3 TRACES 基准的定位与评测对象TRACES 基准不是传统意义上的“闯关题库”它更像一个评估框架由三部分组成任务集一组需要多步探索才能完成的研究型任务。trace 格式统一记录研究过程中每个步骤的数据契约。评分器对轨迹的完整性、忠实性、可复现性进行量化评估。学习环境里可以先用合成任务验证流程比如给一个模拟日志目录让 AI 找出某个异常出现的根因。生产环境则要额外处理权限、日志脱敏、存储周期和人工审计环节。设计评测时需要先明确“过程标准答案”是什么否则评分器只能统计步骤数量无法判断质量。2. 评估框架设计三个核心维度与 trace 数据契约2.1 三个核心维度完整性、忠实性、可复现性TRACES 基准在评测一个探索过程时重点看三个维度。维度一是完整性考察研究过程是否覆盖了任务要求的必要阶段。公式化地看completeness 轨迹中出现过的必要步骤类型数 / 任务要求的必要步骤类型数如果任务要求至少包含 plan、search、evidence、reason、conclude 五个阶段而轨迹里只有 search 和 conclude那过程完整性就是 2/5。这里要注意不是步骤越多越好而是“必要步骤不能缺失”。维度二是忠实性考察每个结论有没有被轨迹中的证据支撑。忠实性通常拆成两个指标引用准确率引用列表里真实存在且内容相关的比例。证据覆盖度最终结论里有多少关键断言能在轨迹中找到对应证据。严格实现时引用准确率不能只看 URL 是否以 http 开头还要实际抓取内容并验证是否支持对应断言。这一步最容易暴露出幻觉引用。维度三是可复现性考察独立执行者能否沿着轨迹复现相同结论。常见做法是抽样的审计员随机抽取 N 个步骤逐一判断“如果给我同样的输入我是否能得到同样的输出”。可复现性得分就是正向评价数除以总评价数。reproducibility 审计员判定为可复现的步骤数 / 审计员抽查的步骤总数2.2 设计统一的 trace 数据契约要让不同模型、不同工具链的输出可以横向比较必须先统一轨迹格式。TRACES 基准建议使用 JSON 作为存储格式每个任务一条记录。一个最小可用的 trace 示例如下{ task_id: trace-ev-001, model: demo-model-v0.1, config: { temperature: 0.0, max_steps: 20 }, started_at: 2025-06-01T08:00:00Z, steps: [ { step_id: step-001, type: plan, input_text: 研究任务定位 demo-service 内存增长根因, output_text: 先查日志再定位热点类最后分析引用链, references: [], tool_calls: [], timestamp: 2025-06-01T08:00:03Z }, { step_id: step-002, type: search, input_text: 检索 demo-service 错误日志关键字, output_text: 发现 OutOfMemoryError频率每分钟 3 次, references: [ https://example.com/logs/demo-service/2025-06-01.log ], tool_calls: [grep, curl], timestamp: 2025-06-01T08:00:09Z } ], final_answer: 内存增长主要由缓存未设置上限导致 }这个契约里steps是核心。每个 step 的type决定了它属于哪个阶段references是审计的关键来源tool_calls记录了实际调用的工具。注意final_answer必须和steps放在同一个 trace 里否则无法做忠实性校验。实际项目中不同 Agent 框架产出的日志格式差异很大。建议在采集端就先做一层归一化把工具调用、HTTP 请求、检索结果统一转换成上述 schema而不是把原始日志直接塞进评测库。2.3 任务集设计要求TRACES 基准的任务集不能全是“检索一下就能答”的简单任务否则所有模型都能拿到很高的完整性分数评测失去区分度。合理任务集至少包含四类任务类型考察点最低探索步骤文献综述检索、引用准确、归纳5代码缺陷根因分析日志定位、代码取证、反例排查6技术方案选型多方对比、权衡量化、结论论证6实验复现步骤还原、参数确认、结果核对7推荐按难度分层每层至少准备几十条任务并保留一组人工标注的“参考轨迹”用于校准评分器。没有参考轨迹时评分器只能做语法层统计无法判断过程质量。3. 最小可运行实现用一组 Python 脚本给轨迹打分3.1 环境准备与项目结构这个最小实现只依赖 Python 标准库Python 3.9 以上即可运行不需要安装任何第三方包。mkdir -p traces-bench/traces cd traces-bench推荐文件结构traces-bench/ ├── traces/ │ ├── example.json │ └── bad_example.json ├── trace_eval.py └── README.mdtrace_eval.py负责加载轨迹、计算指标、输出报告traces目录存放待评测的轨迹文件。这样设计是为了让评分逻辑和采集逻辑解耦采集端只管生成 JSON评分端只管消费 JSON。3.2 定义加载与校验逻辑先写一个加载函数并校验必要字段是否存在。实际项目里schema 校验可以用 jsonschema 库这里先用基础校验演示思路。import json import sys REQUIRED_STEP_TYPES {plan, search, evidence, reason, conclude} def load_trace(path): with open(path, r, encodingutf-8) as f: trace json.load(f) if task_id not in trace: raise ValueError(trace 缺少 task_id 字段) if steps not in trace or not isinstance(trace[steps], list): raise ValueError(trace 缺少 steps 数组) return trace加载完成后建议立刻打印task_id和步骤数量确认文件解析正确再进入评分。3.3 实现三个核心指标完整性评分直接按阶段类型匹配计算def score_completeness(trace): observed set() for step in trace.get(steps, []): step_type step.get(type, ) if step_type: observed.add(step_type) if not observed: return 0.0 hit observed REQUIRED_STEP_TYPES return round(len(hit) / len(REQUIRED_STEP_TYPES), 4)忠实性评分先做语法层检查也就是统计引用总数、有效 URL 数量和有效比例。更深层的内容级校验需要额外传入检索接口这一步先不接入。def score_citation_syntax(trace): total 0 valid 0 for step in trace.get(steps, []): for ref in step.get(references, []): total 1 if ref.startswith((https://, http://)): valid 1 ratio round(valid / total, 4) if total else 0.0 return { total_citations: total, valid_citations: valid, valid_ratio: ratio }可复现性需要人工审计结果这里用一个reviewer_marks列表传入元素为 0 或 1def score_reproducibility(reviewer_marks): if not reviewer_marks: return 0.0 return round(sum(reviewer_marks) / len(reviewer_marks), 4)最后写一个主入口输出 JSON 报告并附带基础告警。告警用于提示轨迹中缺失关键字段def build_warnings(trace): warnings [] steps trace.get(steps, []) if len(steps) 3: warnings.append(步骤数过少探索过程可能不完整) if not trace.get(final_answer): warnings.append(缺少 final_answer无法做结论校验) for step in steps: if not step.get(output_text): warnings.append(f{step.get(step_id)} 缺少 output_text) return warnings def main(path): trace load_trace(path) report { task_id: trace.get(task_id), model: trace.get(model), step_count: len(trace.get(steps, [])), completeness: score_completeness(trace), citation_syntax: score_citation_syntax(trace), warnings: build_warnings(trace) } print(json.dumps(report, ensure_asciiFalse, indent2)) if __name__ __main__: main(sys.argv[1])这里要点是把可自动化的指标和必须人工的指标分开完整性、引用语法可自动算可复现性和内容级忠实性必须先让人或更高级校验器介入。不要在同一个脚本里强行把人工步骤也自动化成虚假分数。3.4 运行与验证准备一个示例轨迹traces/example.json内容包含五个阶段的最小步骤然后运行python trace_eval.py traces/example.json预期输出类似{ task_id: trace-ev-001, model: demo-model-v0.1, step_count: 5, completeness: 1.0, citation_syntax: { total_citations: 3, valid_citations: 3, valid_ratio: 1.0 }, warnings: [] }再准备一个bad_example.json只保留最终答案、没有 steps运行后应输出completeness: 0.0和告警。这个“好样例能通过、坏样例能报错”的验证方式是评测脚本最基本的回归保障。4. 参数设计、评测流程与结果解读4.1 关键参数速查表评分器暴露的参数越多越容易在对比实验里产生偏差。建议把参数固定下来并写入配置而不是散落在代码里。参数默认值含义调大影响调小影响required_step_typesplan/search/evidence/reason/conclude完整性计算依据完整性分数变严更容易拿高分min_citations2每个结论最少引用数逼模型补充证据弱结论也可能通过max_steps20单任务最大步骤数允许更深入探索截断长轨迹reviewer_sample_size10人工抽查步骤数审计更稳但费人力抽样误差变大temperature0.0模型生成参数探索更多样结果更稳定需要特别注意temperature。可复现性评测要求模型行为稳定实验时如果 A 模型用 0.0、B 模型用 1.0分数差异就混入了随机性不能归因于模型能力。4.2 从任务生成到审计报告的完整流程一次完整的 TRACES 基准评测包含七个步骤从任务池中采样任务固定系统和用户提示词。在 Agent 的调用链路中加入日志采集中间件记录每次工具调用、检索和推理。把原始日志归一化为统一 trace JSON。运行 schema 校验字段缺失直接标记为无效样本。运行自动评分器得到完整性和引用语法分数。抽取reviewer_sample_size个步骤交给人工审计计算可复现性。合并输出报告包含各指标分位数、失败样例链接和审计备注。每一步都要留下可追溯记录。尤其是第 2 步如果日志采集不完整后面的评分再精确也没有意义。4.3 结果解读不要只盯一个总分TRACES 基准里一个总分无法说明问题。假设两个模型完整性都是 0.8但一个丢的是 plan另一个丢的是 evidence它们的审计风险完全不同。报告里至少要有三项各维度得分及置信区间。分任务类型的得分矩阵。失败样本和对应步骤 ID。推荐用中位数和四分位数代替简单的平均值避免个别极端异常轨迹拉高或拉低整体结果。评估报告应当明确标注“分数只在当前任务集、当前配置下有效”不能跨数据集随意类比。5. 常见问题与排查路径5.1 轨迹里看不到关键步骤现象评测报告完整性分数很低但模型声称自己完成了研究。可能原因采集端只记录了模型最终输出没有记录工具调用中间态。模型把多个步骤压缩在一条消息里归一化时被当成一个 step。任务提示词没有鼓励模型显式分步模型选择直接输出结论。检查方式打开原始日志查看工具调用是否有记录。打印归一化后的 JSON确认每个 step 的type是否被正确标注。检查提示词里是否明确要求“分阶段探索”。解决方式改进日志采集中间件在工具调用的入口和出口各埋一个事件归一化时把一条多动作消息拆成多个 step。预防的关键是提前定义 trace schema并让 Agent 框架按 schema 输出。5.2 模型自述过程与实际行为不一致现象模型在 final_answer 里说自己检索了某个文档但 steps 里没有任何对应检索记录。可能原因模型编造了不存在的检索行为评测要求模型“自述研究过程”而模型在编故事。检查方式对比每个结论断言和 steps 中的tool_calls、references逐个回溯。解决方式不要依赖模型自述过程。轨迹必须从日志中间件、真实工具调用和外部检索接口的响应中采集。模型生成的文本只能作为output_text不能作为审计事件来源。这个坑在 RAG 类应用里尤其常见一定要区分“模型声称做了什么”和“系统记录到它做了什么”。5.3 引用看起来有效实际内容是幻觉现象引用 URL 以https://开头格式校验全部通过但人工点开发现页面不存在或内容与结论无关。可能原因语法层校验只检查字符串前缀无法验证内容模型训练数据里混入了大量错误链接。检查方式对引用列表执行实际抓取比对标题、关键段落和结论中的断言。解决方式在评分器里加入“检索回查”步骤对每个引用抓取页面片段用文本相似度判断是否支持对应断言。生产环境中要设置抓取超时和失败重试并记录抓取失败原因。内容级校验成本高建议按引用数量抽样不必全量验证。5.4 不同模型的分数不可比现象模型 A 在处理相同任务时比模型 B 少了三分之一步骤但完整性分数接近。可能原因两个模型使用不同的工具链A 把一次检索合并输出B 则拆成多次任务本身区分度不足运行参数不一致。检查方式检查两份 trace 的tool_calls和 step 数量分布确认两个评测使用的 temperature、max_steps 一致。解决方式先在同等环境下复测再按任务类型分层对比而不是只看总分必要时给 trace 归一化逻辑增加“合并同类动作”规则让不同工具链的输出处于同一层级。跨模型对比必须固定环境否则结论不具备可审计性。5.5 可复现性人工审计不稳定现象同一份轨迹两个审计员给出相反结论。可能原因审计标准不明确一个审计员按“能否重新执行”另一个按“是否觉得合理”。解决方式制定审计标准清单比如“步骤输入是否完整、输出是否可从输入推导、引用是否可访问、前置条件是否缺失”。同时定期做审计一致性测试统计两名审计员在同一批样本上的一致率低于阈值就要重新培训或简化标准。6. 最佳实践与落地清单6.1 TRACES 基准落地七步清单在真实项目里落地这样一套过程可审计评测可以按下面的清单逐项确认先定义任务集至少区分简单检索、多跳推理、根因分析和实验复现四类。在 Agent 框架的工具调用层埋点采集每一步的输入、输出、引用和时间。统一 trace schema并做版本管理schema 变更时保留迁移逻辑。编写 schema 校验字段缺失直接标记无效样本而不是自动补值。自动评分只结算可验证指标内容级忠实性必须走人工或检索回查。每轮评测固定模型参数、提示词和任务采样种子保证可比性。发布报告时附带样本失败的 trace 链接方便回查。6.2 学习环境与生产环境的差异学习环境可以为了快速验证而简化生产环境不能沿用同一套逻辑。环节学习环境生产环境任务来源合成日志、样例文档真实工单脱敏样本轨迹采集本地打印 JSON日志系统统一采集按任务 ID 聚合数据安全无要求脱敏、权限控制、保留周期策略审计方式单人抽查双人复核 一致性统计评分报告命令行输出定时任务生成报告并落库生产环境中还有一个容易被忽略的问题trace 里可能混入密钥、内部地址、用户隐私。采集中间件必须在落库前完成脱敏比如把数据库地址替换成占位符、把用户 ID 做哈希处理。6.3 扩展方向从自动评分到持续审计TRACES 基准的最终形态不应只是一次性评测工具而应该是持续审计能力。在 CI 中接入最小评测集每次修改 Agent 提示词或工具链后自动跑一遍防止过程质量回退。对上线后的真实请求按比例采样保存 trace由审计员定期抽查形成“离线评测 在线审计”双通道。当新模型或新工具链上线时先在保留的基准任务集上跑全量评测再灰度到真实流量。持续审计的价值在于它能尽早发现过程质量退化的趋势。比如某次升级后最终答案准确率没变化但引用有效比例从 0.9 掉到 0.6这种问题只有在跟踪 trace 指标时才会暴露。评估一个研究过程是否可审计本质是把“研究者如何得到结论”这个隐性问题显性化。TRACES 基准提供一个思路统一记录轨迹、按完整性和忠实性自动打分、用人工抽样确认可复现性。落地时最该记住的不是某个指标公式而是三条原则轨迹必须来自真实系统日志引用必须能回查内容评估报告必须能指出问题发生在哪一步。把这三件事做扎实再逐步扩展任务集和自动化程度这套基准才能真正服务于可审计、可追溯、可复现的 AI 研究工程实践。