把同一个复杂研究问题交给两个大模型一个会先检索资料、逐条核对来源、在不确定时明确说出“这里证据不足”另一个则凭记忆直接生成了一段看起来逻辑通顺的答案。只看最终结论两者的分数可能相差不大但一旦进入工程落地、合规审计、资料更新第一个模型的过程可以被复核第二个模型只能整体推翻重来。TRACES 这类面向“AI 可审计探索性研究过程”的基准核心就是解决这个矛盾不只看结论更看过程能不能被追踪、被复核、被复现。这篇文章会把 TRACES 基准拆开讲清楚它评估什么、为什么过程审计比结果对拍更重要、一个可审计评估任务要记录哪些中间数据、怎么设计一个 TRACES 风格的小规模评估流程以及在 AI Agent 开发、模型部署和合规审查里怎么落地。如果你正在做模型评测、Agent 验收、RAG 系统验证或者只是想知道“怎么证明 AI 不是乱编的”这篇文章可以直接收藏。1. TRACES 基准核心能力速览先给一张速览表把项目定位讲清楚。TRACES 不是一个新的“题库式”问答基准也不是单纯测试模型知识覆盖率的榜单它更接近一套评估协议在探索性研究场景下把 AI 从接收任务到产出结论的完整过程记录下来再逐段审计。能力项说明基准类型面向 AI 可审计性的探索性研究过程评估基准评估对象大模型、AI Agent、检索增强系统、工具调用型研究流程核心思路让评估者审计过程轨迹而不是只对比最终答案关注维度步骤可追溯性、证据可复现、推理一致性、失败透明性、来源完整性任务形式开放式问答、文献调研、数据分析、工具调用链、多轮研究计划输出结果审计报告、轨迹记录、证据链通常以结构化日志呈现硬件门槛取决于被测模型可以在纯 API 环境运行也可以本地 GPU 复现适用场景模型评测、Agent 开发验收、合规审查、RAG 系统可靠性验证从目前公开资料看这个基准更强调“过程证据”而不是“最终得分”。换句话说如果一个大模型在某个研究任务上给出了正确答案但它无法提供检索来源、无法展示推理步骤、无法说明失败后的重试逻辑那这次的回答在 TRACES 框架里会被判定为“不可审计”得分上限会明显受限。实际使用中TRACES 这类基准可以拆成两个部分一是“被审计的对象”即大模型或 Agent 做研究时留下的全过程记录二是“审计规则”即如何判断每一步是否合理、是否足够透明。下面几章会沿着这两个部分展开。2. 为什么探索性研究过程必须可审计探索性研究过程和普通问答最大的区别在于任务不是一次推理就能完成的而是需要多个步骤的组合。一个典型的研究任务可能包括把大问题拆成若干子问题根据子问题检索资料对多个来源做交叉验证筛选出可信信息结合已有知识做出推断在某个方案失败时更换路径。传统基准评估通常只取最终答案与标准答案做相似度对比或人工评分。这套做法在封闭式问答、数学计算、代码生成上仍然有效但在开放式研究场景里会暴露出几个明显问题。第一个问题是答案正确不等于过程正确。模型可能靠记忆偶然命中正确答案也可能检索到了正确资料但没有真正理解还有可能在推理中途出现了错误只是靠输出分布侥幸修正。只看结果这些情况无法区分。第二个问题是过程正确但最终结论偏离。研究过程中可能存在多个候选答案模型判断“哪个更好”的标准并不透明最终结论可能在一个合理范围内波动人工评分容易产生分歧。第三个问题是隐性失败很难被发现。比如模型在检索第 3 步就出现了工具调用错误后续步骤全都在错误上下文上展开最终结论看着还行但实际上整条链路早就断了。TRACES 这类过程审计基准要补上的正是这层“中间状态”的信息。它把评估重心从“模型的输出是什么”挪到“模型是如何得到这个输出的”让评估者能回到每一个分支节点去检查这一步的依据是什么这一步的操作是否合理如果这一步失败之后的步骤有没有被发现并纠正从 AI 工程角度看过程可审计的价值更直接。部署在业务系统里的大模型或 Agent上线后一旦出问题工程师需要快速定位是上游检索问题、Prompt 设计问题、模型能力问题还是外部工具调用问题。如果只有最终答案没有过程日志排查成本会非常高。如果过程记录完整就能像软件工程里看日志和链路追踪一样按时间轴逐层回溯。这也是 TRACES 基准对模型评测体系最大的启发把应用系统里常见的可观测性理念反向引入到模型评估框架里。3. TRACES 的评估维度拆解在可审计研究过程这个前提下评估维度会比传统基准丰富很多。下面这个表格可以看作一个通用检查清单实际使用 TRACES 时可以根据任务类型裁剪。维度评估方向典型观察点检索与来源可追溯性每一步检索是否保存了证据是否保留原始链接、文档 ID、查询语句信息筛选一致性是否说明采纳或拒绝某个来源的理由是否有筛选记录还是直接跳转结论工具调用有效性调用外部工具是否合理、是否处理错误是否存在重复调用、空结果时是否重试推理链完整性从任务到结论是否有关键断点是否存在未解释的跳跃推理自我纠正记录失败后是否明确重试或更换路径是否有错误标记和新的行动描述不确定性披露低置信度时是否明确说明有没有遇到资料不足仍然强答的情况成本与效率完成任务使用了多少步、多少 token是否在合理成本内完成任务合规与授权是否使用了受限来源、核心素材是否授权数据来源是否符合许可要求下面展开几个最关键的维度。3.1 检索与来源可追溯性这是过程审计的基础。没有来源记录其他一切免谈。审计时判断的标准不是“有没有引用”而是“引用是否能够回溯到检索动作”。一份好的轨迹里应该能看到类似这样的信息第 1 步搜索了关键词 A返回了结果 1、2、3选中了结果 2 作为后续依据第 2 步打开结果 2摘录了部分内容并关联到当前结论。每一步的输入和输出都能对上。如果模型在最终回答里写“根据某项开源报告”但轨迹里根本找不到对应的检索记录那就属于来源不可追溯。这类问题在 RAG 系统里尤其常见因为检索器返回的片段和模型生成内容之间的关联关系经常没被记录。3.2 信息筛选一致性探索性研究必然涉及信息筛选。模型看到 10 条候选资料最终只用 2 条这时候审计要看它为什么忽略另外 8 条。TRACES 框架下合理的路径应当是模型对候选资料做简要评估说明“该来源时效性不足”“该来源与任务不相关”或“该来源信源权威性存疑”然后才进入下一步。如果模型直接“跳”到结论没有筛选痕迹审计人员会标记为“推理链断点”。3.3 自我纠正记录真实研究过程一定会有失败步骤比如搜索返回空结果、代码执行报错、文档解析失败。传统基准测试里这些失败通常被忽略模型只要最终答对就行。但 TRACES 会把失败和重试看作重要评估素材一次失败后模型是盲目重复相同操作还是调整了查询词、更换了工具、明确记录“上一步失败原因是什么现在改用什么方式”这直接反映模型的鲁棒性和元认知能力。3.4 不确定性披露研究任务中经常出现资料不足或相互矛盾的场景。传统评分倾向于鼓励模型给出确定答案哪怕底层证据不够。TRACES 则会把“明确说出证据不足”当作加分项而不是扣分项。在可审计框架里好的回答往往包含边界声明“基于当前检索结果可以确认 A但 B 的结论还需要更多数据验证。”这种表达虽然看起来不够果断却更符合真实研究过程中的负责任行为。4. 评估数据的记录格式与参考实现可审计评估的前提是能拿到完整的执行轨迹。TRACES 这类基准一般会要求被测系统按要求保存过程日志而不是只输出最终答案。下面给出一份通用的轨迹数据格式它不是官方实现但代表了一个可行的记录结构实际使用时可以根据自己的 Agent 框架调整。{ session_id: trace-2025-0007, task: 评估三个开源 OCR 模型在中文票据场景下的可用性, model: { name: example-llm, variant: local-demo }, steps: [ { step_index: 1, action: search, input: { query: 开源 OCR 中文票据 识别 准确率 对比 }, output: { candidates: 12, selected_ids: [3, 7] }, evidence: [ https://example.com/ocr-benchmark-a, https://example.com/ocr-tech-report-b ], status: ok }, { step_index: 2, action: read_webpage, input: { url: https://example.com/ocr-tech-report-b, extract_target: 准确率指标 }, output: { key_value: reported accuracy 96% }, status: ok } ], final_answer: 在中文票据场景下建议优先测试模型 B..., uncertainty_statement: A 模型缺少真实票据测试数据结论待验证 }一个可审计轨迹需要包含几个关键元素任务标识、模型标识、每一步的动作类型、动作输入、动作输出、证据引用、执行状态、最终答案和不确定性声明。只有把这些信息完整落入日志后续审计才有据可查。下面这段 Python 代码演示了如何对一个轨迹做基础校验判断是否存在“缺少证据”或“失败后没有重试”这类问题import json def load_trace(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) def check_trace(trace: dict) - list: issues [] steps trace.get(steps, []) for step in steps: if step.get(status) error: if retry_action not in step: issues.append( fstep {step.get(step_index)} failed but no retry record ) if step.get(action) in (search, read_webpage): if not step.get(evidence): issues.append( fstep {step.get(step_index)} missing evidence ) if not trace.get(final_answer): issues.append(trace has no final answer) return issues if __name__ __main__: result check_trace(load_trace(trace-2025-0007.json)) print(result)这类工具脚本可以直接纳入评估管道。审计脚本的输出是一份问题清单评估者根据问题数量和严重程度对被测模型给出“可审计程度”评分。5. 一个 TRACES 风格的小规模评估流程理解了维度与数据格式后可以开始搭建自己的小规模评估流程。这里给出一个可执行的通用流程适用于验证某个 Agent 或模型是否具备过程可审计能力。整个流程分为六个环节环节内容任务集构建准备 5-20 个探索性研究问题要求需要检索或多步推理环境固定固定模型版本、检索工具版本、Prompt 模板、随机种子轨迹采集运行任务并保存完整轨迹包括中间步骤和最终回答审计打分使用规则脚本或人工审计按维度给每个任务打分汇总报告计算各维度通过率输出审计报告复跑验证对同一任务重复运行 3-5 次检查过程稳定性任务集构建时建议混合三类问题一类是必须检索才能回答的事实型问题一类是资料互相矛盾需要判断的开放型问题一类是需要调用代码或计算工具的实操型问题。这样能覆盖 TRACES 最主要的几个审计维度。运行任务时可以用下面的配置模板管理任务和审计规则task_set: - id: t001 question: 2024 年至 2025 年开源的 OCR 模型有哪些值得关注 required_evidence: true max_steps: 12 - id: t002 question: 不同开源模型在中文长文档解析场景下的优劣势如何 required_evidence: true max_steps: 15 audit: check_dims: - evidence - retry - citation - uncertainty output_dir: ./eval_results max_sessions: 20命令启动可以采用模板形式# 实际命令需要根据选用的 Agent 框架调整 python run_audit_eval.py \ --config configs/trace_task.yaml \ --output ./eval_results \ --max_sessions 20整个评估流程的目的不是简单地得出“通过/不通过”而是给人一份可以逐条回溯的审计报告。比如某个模型在“证据完整性”上得了 80 分但在“自我纠正记录”上只得了 40 分评估者可以明确看到问题出在哪个任务、哪一步骤然后针对性优化模型或 Prompt。6. 可审计评估在 AI 工程化和 Agent 开发中的接入TRACES 这类基准不只是学术研究用的评测工具它可以直接接入 AI 工程化体系。在 Agent 开发的验收阶段过程审计能力应当和功能正确性放到同等重要的位置。一个典型的接入方式是把它变成自动化测试的一部分。每次 Agent 代码变更或模型版本升级后跑一组固定的研究任务自动采集轨迹并运行审计脚本如果“证据缺失率”或“未知失败率”超过阈值就阻断合并请求。这个思路类似软件工程里的回归测试只是断言对象从“函数返回值”变成了“Agent 执行过程的可审计性”。接入阶段需要重点考虑三点。第一给 Agent 框架增加可观测性层。在工具调用的入口和出口统一埋点把模型输入、模型输出、工具名称、工具参数、工具返回结果、耗时、状态字段全部记录到结构化日志。这步做不好后续所有审计都是空谈。第二把审计结果和业务指标绑定。在正式环境里不只记录“最终回答是否被用户认可”还要记录“回答是否有完整的检索证据链”“用户追问时模型能否定位到具体来源”。这些指标在客服、办公助手、研究辅助类产品中非常重要。第三在合规审查中把审计报告当作可交付物。面向金融、医疗、法律等强监管场景时AI 系统的输入来源和生成依据需要能够应对审计。TRACES 式的过程记录正好提供了这种追溯能力让 AI 系统不只是“输出结果”而是“能够解释结果”。这里要提醒一句过程记录也会带来安全边界问题。长轨迹日志可能包含敏感查询、用户原始问题和未经脱敏的文档内容因此在采集和存储时需要对存储权限、加密方式和保留周期做明确规定避免审计日志本身成为新的数据风险点。7. 资源消耗与成本观察探索性研究任务和普通问答不同它的推理成本高很多尤其是配置了检索和工具调用的 Agent。一个任务可能涉及多次模型调用、多轮检索、长上下文输入最终产出一条几百字的回答但中间消耗的 token 可能是直接回答方式的 10 倍以上。在评估这类基准时需要把成本纳入观测范围。建议记录以下指标观测对象说明每任务平均 token 消耗区分输入 token 和输出 token每任务工具调用次数搜索、读网页、执行代码等动作的次数平均耗时从任务开始到最终回答结束的墙钟时间轨迹日志大小记录所有中间步骤后日志膨胀情况失败重试触发率失败后重试的次数占比资源占用需要以实际测试环境为准。如果被测模型是本地部署的 7B 或 13B 模型还需要同时观察显存占用和推理吞吐如果使用的是 API 服务则更应关注单任务成本和并发限制。显存占用与实际模型参数、量化方式、上下文长度、并发数直接相关不能根据基准类别一概而论。降低评估成本有几个常见做法先跑小参数模型做流程验证确认完整通后再跑大模型配置上限和预算上限防止单个任务无限循环对重复检索结果做缓存减少相同查询的重复计算对长文档只提取关键片段保持上下文窗口可控批量任务时串行与并发结合先小批量试运行再扩大规模。评估成本本身也是可审计的一环。一次研究任务的成本异常偏高往往意味着 Agent 在无效搜索上打转这也是一种值得记录的问题信号。8. 常见问题与排查方法使用 TRACES 风格的过程审计评估时遇到问题不用慌大多数情况可以从数据和环境两个方向排查。下面整理了一份常见问题对照表。问题现象可能原因排查方式解决方案轨迹里缺少中间步骤记录Agent 框架没有统一埋点检查工具调用日志在工具调用入口和出口增加结构化记录最终回答引用了不存在的来源检索结果与回答生成阶段解耦回检检索记录和引用列表要求模型在最终回答中只引用轨迹内证据模型失败后反复执行相同操作缺少错误反馈机制查看失败步骤的返回状态在工具返回错误时给模型明确错误提示多次运行结果差异大随机种子未固定、搜索排序变化固定温度和种子保存检索快照测试时使用固定语料快照或固定 API 参数审计脚本报格式错误不同任务轨迹字段不统一检查 JSON Schema统一轨迹记录结构增加 schema 校验显存不足导致评测中断本地模型上下文太长或并发过高观察 GPU 利用率和显存曲线降低并发、缩短上下文、使用量化模型同样的任务在不同环境结论不一致检索工具版本或模型版本不同对比环境依赖用 Docker 或 requirements 固定版本审计报告太多噪音项评估维度设置过细或过粗检查规则脚本阈值把硬指标和人工复核指标分层处理最重要的是第一次跑评估时不要追求完美覆盖。先设置 3-5 个任务跑通数据采集和审计脚本确认整条链路可复现再扩大任务集。过程审计的底层逻辑和软件开发一样先保证观测系统本身可靠再谈评估模型的可靠性。9. 版权、隐私与合规边界做任何以研究过程为对象的 AI 评估都绕不开版权、隐私与合规边界。有几点必须在实际评估前定清楚。第一构建任务集时注意素材授权。如果任务集中包含论文摘要、新闻报道、网页文本或源码片段要确认这些素材的使用是否符合来源方的许可要求。尤其在做商业化评测时不能直接把第三方付费内容、需要授权的数据库内容塞进评估集。第二如果评估过程会调用真实网络检索输出日志里可能包含大量第三方网页内容。这些内容即使只是作为“证据”被记录也可能涉及版权问题。稳妥的策略是存放在受控环境内不对外公布完整检索原文只保留来源 URL、关键片段和引用说明。第三涉及个人信息时必须做脱敏处理。比如使用真实用户提问、真实票据图片、真实病例文本做评估时要先完成匿名化并遵守所在地区的个人信息保护法规。第四TRACES 式审计并不意味着“授权免责”。它会记录检索到哪、引用了什么但这只是过程透明不能替代对数据来源合法性的确认。评价一个 AI 系统的过程可审计性和保护版权、保护隐私是两个层面的事缺一不可。在公开评估报告时还要注意只发布必要的证据细节避免把完整轨迹原样公开。轨迹里可能包含内部系统名称、未公开工具参数、内部查询策略这些都属于敏感工程信息需要做最小化披露。10. 善用 TRACES从基准走向工程实践的建议TRACES 这个基准真正值得关注的地方不在于它给出了多少分而在于它把“过程可审计”变成了 AI 评估里一个不可回避的指标。如果你正在做 Agent 开发或模型验收可以先从一个小范围实验开始不必一步到位搭建完整评测平台。建议先用 5 个研究任务试运行重点观察三件事第一当前 Agent 框架能不能稳定输出结构化轨迹第二人工审计一份轨迹需要多长时间第三审计结果是否能发现“只看最终答案发现不了”的问题。如果这三件事都能跑通再逐步扩大任务集把审计脚本接入到日常 CI 流程中。最容易踩的坑有两个。一个是只记录模型回复不记录工具调用过程导致最终发现轨迹里只有“想”和“答”没有“做”审计无从下手另一个是一开始就追求大规模评估结果投入大量 token 后才发现格式不统一、复现性差。从最小闭环开始先把一条完整链路打磨稳后面扩展会顺利得多。如果整个团队之前只习惯用“最终答案正确率”来评估模型TRACES 这套思路会带来一个明显的评价观转变一个宁可承认“这里不确定”但能给出完整证据链的回答比一个看起来完美但无法追溯来源的回答更值得信任。这个判断标准在学术研究、企业知识库问答、专业助理等场景里会越来越有价值。下一步可以延伸的方向包括把审计维度接入 RAG 评估体系把过程日志接入可观测性平台或者在 Agent 长期运行中做持续性的可审计性监控。TRACES 类的过程审计不会替代传统的能力基准它会成为一种补充专门回答一个过去很难回答的问题这个 AI 做研究的时候能不能让人放心地看着它做。