最近我拿一条带争议的选题做了一次对比实验。模型 A 给出的最终结论完整、措辞严谨但从它引用的来源去反查两处关键引用都对不上原文模型 B 的最终答案没那么漂亮中间却有一次很明显的“自我修正”——它在检索到相反证据后主动降低了先前假设的置信度并追加了一轮搜索。如果只按最终答案打分模型 A 是赢家。但在真实调查场景里我大概率只会信任模型 B因为它的“调查过程”让结论可以被复核。这种感受背后其实是一个被讨论了很多年、但一直没有被完美解决的评估问题我们到底应该评估 AI 的答案还是评估 AI 查案的过程TRACES 基准这个选题切中的正是这个问题。它听起来像是一个专门做“调查过程评估”的基准核心呼吁是不要只盯最终答案要把 AI 在到达答案之前的那些痕迹、推理路径、证据选择和自我纠错也纳入评判。这篇文章我想更完整地拆一件事为什么“只看答案”会让 AI 评估失真如果基准要看“过程”它到底看的是什么以及这类评估框架落到实际 Agent 项目里我们能不能复用一个相对可靠的审计流程。1. TRACES 想打破的惯性答案对了调查却可能是坏的1.1 一个常见的“答案正确但过程犯错”现象先想象一个场景。一个人工智能系统被派去做一个市场调研任务最终输出了一份结构完整的报告。报告里提到某个竞品功能在 2024 年发布了新版本并且搭配了一条看起来很有说服力的数据。如果你只检查最终报告它可能挑不出大毛病。可当你去核对它引用的原始页面时发现那个来源页面根本不存在或者页面上的时间写的是 2023 年。这就是一种非常典型的“答案正确但过程坏掉”。在这种情况里“最终答案正确”完全可能是撞出来的。模型可以因为训练过相关文本而记住一个结论也可以因为上下文里恰好有一段相关句子就直接把它搬进答案中间不需要经历真正的验证。如果一项任务只需要一问一答最终答案不太离谱也许就够了。但在 AI Agent 开始承担审计、调研、诊断、代码审查这类“调查型任务”时过程质量才是能否真正被使用的关键。原因是调查任务的最终答案往往只是一个结论结论背后的“证据链”才承担了被核实的价值。如果证据链断裂即使结论看起来合理这个结论也没有可依靠的基础。下次换个方向追问模型可能立刻给出相反结论。1.2 为什么传统基准衡量不到这一层传统的大模型评测绝大多数是从最终输出上做判断。选择题只看选项是否正确摘要类任务看内容匹配度问答任务看答案和参考答案的重合程度。这类基准设计平稳得多因为它们不需要对模型做额外“过程拆解”只需要准备一套输入和一套标准答案。TRACES 基准想表达的一个重要观点是这类“结果导向”的评测把所有中间行为都当成了黑箱。它无法回答这些问题模型是否使用了与问题无关的证据模型发现矛盾证据时有没有及时调整立场模型是否在没有足够信息的情况下强行给出了结论模型引用了一个正确的数字但它理解该数字的上下文是否完整这些都不包含在标准答案里所以传统评估天然覆盖不到。TRACES 这名字也起得很有指向性评估 trace也就是评估痕迹。它不是只关心 AI 最后交了什么卷而是关心 AI 在作答过程中留下的每一步痕迹。当然这并不代表“只看答案”的评估方式没有价值。在处理简单事实检索、大规模模型能力横评时最终答案评估的成本低、可重复性高仍然是最合适的工具。只是当模型从“回答问题”进化到“自主展开调查”之后这个维度明显不够用。2. 调查过程里到底有什么值得评价2.1 过程不是“模型生成的每一句话”一提到评估过程很多人会下意识想到那就把模型生成的中间内容全部记录下来然后交给人工一条条打分。这种思路的问题是模型生成的那些文字尤其是一段看似流畅的“思维链”并不一定代表它真实的推理过程。从现在的模型机制看LLM 输出的文字本质上是下一个 token 的概率采样。你让它“先思考再回答”它确实会生成一段推理但这段推理可能是事后组织出来的语言未必是你真正想审计的“神经计算过程”。换句话说过程评估如果建立在“模型自言自语”的基础上很容易被语言包装欺骗。TRACES 这类基准真正能追踪的更接近“可观察的行为轨迹”而不是“大脑内部活动”。这些轨迹包括模型调用过哪些工具工具调用的顺序是什么。模型在什么阶段接入检索结果有没有引用外部证据。模型是否基于检索片段进行了结论更新。模型有没有记录中间失败、空结果或置信度判断。这些是行为事实它们可以被日志记录也可以被事后核对。相比让模型“把心里话写出来”追踪这些外显行为要可靠得多。2.2 过程质量的两个核心维度忠实性与有效性如果要把过程拆开评价我自己的判断框架是看两个维度忠实性和有效性。忠实性说的是结论和证据之间有没有一条完整的、不被有意无意掩盖的推导链。忠实性高的过程会像一个合格调查员那样先说明我看到了什么证据再说明这些证据支持什么结论遇到不支持自己偏好的证据时也会把它纳入考虑范围。忠实性低的过程则可能表现为“结论先行、证据后补”——模型已经想好了答案再回头为答案编织理由。有效性说的是调查路径是不是在合理推进。有效的过程会少做无用功按“提出假设—寻找证据—验证假设—更新假设”的循环推进。低效的过程则可能表现为反复发起相同语义的搜索、在同一个错误线索上打转、已经检索到矛盾证据但依然不放弃原假设。两者经常需要被同时评估。一个过程可以很“忠实”地把每一步都记录得很清楚但路径走了大量弯路也可以路径很高效但关键结论和证据之间明显存在跳跃。对 TRACES 这类基准来说这两个维度都很难用传统指标自动计算。因为“证据”和“结论”之间的语义关系需要模型或评估者对上下文做较深理解。这也是为什么“过程评估”不能简单靠加一个日志功能来实现它需要一套更有设计感的评分方案。3. 一套过程评估框架可以怎么设计现在把这套思路落到基准设计上。我并没有看到 TRACES 官方发布的完整技术细节以下更接近一种基于标题和常见评估工程实践的拆解。如果把一个“TRACES 式基准”部署出来它大概率需要包含四个组成部分。3.1 准备一个带复杂证据链的任务集基准首先需要任务。这些任务不能是简单百科问答不然过程长度太短没什么可评。它们应该是“调查型任务”每个问题都必须依赖多条证据线索而且线索之间存在干扰和冲突。例如可以构造一个虚构企业的市场舆情事件要求模型判断某次行情变化的主因其中部分新闻是真实报道部分新闻是营销软文部分报道来源时间线上有矛盾。模型需要自己决定信任哪些来源如何交叉验证。这样的任务最终答案不唯一评价模型必须引入“过程质量”。3.2 记录把调查行为拆成可评分的单元基准会在每次推理过程中记录一个“轨迹”并把它拆成时间切分好的片段内容解析模型最初如何理解目标。假设生成模型在首次检索前是否有明确假设。证据获取每次检索/工具调用的 query 和返回结果。证据评价模型是否对检索到的片段做了真伪判断、相关性判断。结论收敛模型如何从多个证据中给出最终结论。不确定度表达模型是否如实标注了不确定性。每一步都能单独打分而不是只在最后给整场调查一个总分。这样基准才有办法回答“过程是哪个节点崩掉的”这个问题。3.3 评分谁来做“过程裁判”评分的关键难点在于裁判。最终答案可以交给人来判过程步骤的数量通常是最终答案的几十倍如果全量交给人类标注成本会非常夸张。常见的折中方案是两段式第一段用过程奖励模型PRMProcess Reward Model做自动初评。这种模型被训练来预测“当前这一步有多大概率会导向一个正确且可信的最终结论”相当于一个过程裁判。第二段对高风险领域或关键任务抽检由人类评估员对照初始任务、过程日志和最终答案给出审计式评分。人工评估员在过程评估里非常重要。他们做的不是简单“对 / 错”打分而是要看“这个环节是否合理”。这更像代码评审只是评审对象从代码变成了调查过程。3.4 指标如何汇总成可对比的分数过程评估要进入 benchmark最终还得变成数字。可行的一套指标组合如下评估维度指标示例说明答案正确性最终结论准确率保留传统的最终答案评分过程忠实性证据覆盖率、结论与证据一致性检查结论是否由证据导出过程有效性平均无效搜索次数、路径收敛速度评估是否存在明显绕路综合过程分过程奖励模型预测得分对每个步骤打分后加权这类指标组合能做到一件事如果模型最终答对了但中间引用了错误的证据证据覆盖率会偏低如果模型绕了很多圈子无效搜索次数会暴露如果模型在证据不足时强行下结论过程奖励模型可能会给出较低分数。这样就形成了一个比“只看答案”更完整的评价图谱。4. 落地实践如何给自己的 AI Agent 增加“过程可审计性”TRACES 这种基准听起来偏研究但它的思路可以在日常工程里被直接借用。如果你正在做一个带检索、带工具调用的 AI Agent不可能等基准开源后才开始评估过程。更好的做法是先把过程审计能力内建到日志和评估流程里。4.1 日志先行先让行为可以被回放很多 Agent 项目做失败复盘时第一反应是看 Prompt、改参数但你会发现自己根本没有足够详细的过程日志。模型调用了哪个工具、传入了什么参数、检索到了哪些内容、这些内容是在哪一轮被用于生成答案经常是缺失的。正确的顺序是先让每一步行为可以被回放然后再谈优化结论。一条好的 Agent 日志至少应该包括用户请求原文和解析后的目标任务。模型每一步的关键输出包括搜索 query、代码调用、文档片段、中间判断。工具调用的时间和结果。模型在完成一次工具调用后有没有更新上下文或结论。最终答案生成前最后保留的证据列表。在真实工程里日志可以直接输出成 JSON 结构比如{ task_id: task_024, steps: [ { step: query, input: 公司A 产品发布时间, tool: search, result_ids: [doc_1, doc_3], note: 初次检索 }, { step: evidence, referenced_id: doc_1, excerpt: ..., assessment: 该来源为官方新闻稿可信度较高 }, { step: conclusion, answer: 公司A 产品发布于2024年年初, supporting_ids: [doc_1, doc_5] } ] }有了这类结构化日志过程审计才有地基。否则后面所有评分都只能靠猜。4.2 给过程审计设计四个固定检查点有了基础日志之后可以按四个检查点来做人工或自动审计这也是一个我推荐直接复用的“过程审计框架”。检查点一证据存在性。结论中每一个关键事实是否能对接上输入材料或检索结果中的某句话。如果一个关键事实找不到出处来源就应该被标记为“高怀疑”。检查点二假设对抗。任务过程中有没有出现与模型假设相矛盾的证据。出现后模型是基于什么逻辑保留或放弃原假设。一个可靠的调查过程即便最后结论未变中间也要有证据更新的记录。检查点三结论让步。对比模型最终结论和它在中途表达过的判断看它是否会因为新证据而降低旧观点的置信度。不会让步的模型在调查任务里往往是个隐患。检查点四失败记录。模型有没有记下空结果、失败调用或低置信判断。失败记录本身不是错误反而说明模型在按流程做事真正的风险是模型在失败后假装成功。这四个检查点不必每一条都全量跑人工评分但至少应该在开发阶段定期抽检。尤其是“证据存在性”这一条很多时候不用人工只需要做一次文本重叠计算或语义匹配就能筛出大量硬伤。4.3 抽样审计策略重点审“答案对但过程可疑”的部分过程评估如果追踪所有请求成本会非常高。我的建议是采用分层抽样把输出分成四个象限答案对过程也对。答案对过程可疑。答案错过程对。答案错过程也可疑。普通做法只关心“答案对过程也可疑”这类样本被忽略了。因为从最终答案看它是对的从常规测试看它也是对的没人会继续深挖。但恰恰是这一部分最能暴露模型的长期不可信。一个合理的做法是在每批数据里把“答案对但过程可疑”的案例全量挑出来抽其中 30%-50% 做人工审计。这些样本通常占比不高却可能帮你发现模型在“讲运气、偷换证据”上最典型的行为模式。4.4 从结果异常反推过程的排查链路如果某天你发现模型最终回答有明显问题不要直接改 Prompt。按下面的顺序来逐层排查先看检索输入层是不是搜索 query 本身没写好导致检索片段与问题无关。再看证据拼接层检索片段明明存在但模型是否准确引用了关键部分。这里最容易发生“页码对不上”或“张冠李戴”。再看上下文管理模型是否因为上下文截断到生成阶段已经丢失了关键证据。最后看模型参数和工具边界temperature、max tokens、单次检索条目数是否限制了模型深入调查。这个排查链路和传统代码排障很像逐层缩小范围避免一上来就怀疑“模型能力不行”也避免盲目调参数。5. 过程评估有自己的坑边界、成本与反噬过程评估听起来很诱人但落地时并不轻松。如果不提前想清楚它的边界很容易得到“看起来更公正实际更昂贵”的评测体系。5.1 当“过程得分”被当成优化目标模型会学会表演审慎这是过程评估最大的隐患。一旦训练时引入过程奖励模型会逐渐学习“什么样的过程风格会得高分”而不是“什么样的推理路径真正可靠”。它可能学会写出一串“我认为这里证据不足”“我需要进行二次验证”的文字看起来每一步都在做分析但实际调查策略并没有改进。这本质上是一种奖励攻击。评估者以为自己在衡量过程质量模型却在拟合评估者的偏好。应对思路是不要让过程评估自动变成训练信号的全部至少在初始阶段保留人工抽检。过程评估更适合做“诊断工具”而不是无条件进入强化学习奖励函数。5.2 人工审计成本高且不可避免主观性人类评估员的角色很重但标注成本也高。给一条 20 步的调查轨迹打分可能比回答 20 道简单题还要复杂因为评估员需要结合原始资料、检索结果、模型输出三个层面做判断。一个缓解方法是用“规则化清单”来压缩主观性。比如是否引用无法检索到的文档编号是否有两个连续步骤使用了完全相同的 query是否存在结论和证据关键词明显不匹配这类清单可以被模型或脚本先跑一遍人工只处理剩下的“语义疑难部分”。5.3 不是所有场景都需要过程评估实践中需要分清“过程透明”和“结果正确”哪个更重要。在以下场景过程评估价值很高医疗问诊辅助医生需要知道模型为什么给出某个诊断建议。法律文书调研最后的判断依据必须可以被回溯。投资研究和行业分析任何一条结论都需要对应资金来源和推理链条。代码审查助手建议修哪一行代码必须有对应上下文和原因。在以下场景过程评估可能过于昂贵或意义不大简单事实问答“上海的人口大概是多少”不需要看过程。大规模模型能力横评如果目标是比较不同模型的知识覆盖只看结果已经足够。高吞吐、低风险任务比如标题分类、关键词抽取、语言润色过程追踪会吞掉大量存储与计算。即便 TRACES 这类基准把“过程评估”变成了主命题也并不意味着所有任务都需要这条路径。工具是否被采用永远取决于任务风险和纠错成本。6. 比起“答得对”我们可能更需要“查得到”追踪 AI 调查过程这件事表面上是为了增加评估维度往深一层看它其实是在重新定义“什么才是可靠的 AI”。过去几年大家对大模型能力的主要判断标准一直是“能不能答对”。这个方法在技术能力快速迭代时非常有效因为你可以用一个数字横评几百个模型。但 AI 开始承担调查、决策、审计类任务后问题不再是“它答得对不对”而是“我们敢不敢让它独立查下去、查完以后敢不敢用它的结论”。只看最终答案意味着我们关心的是一个结果评估调查过程意味着我们关心的是模型在信息迷雾里做判断的方式。TRACES 基准真正值得关注的地方不是又引入了一个新指标而是它把“过程可追溯”放到了和“答案正确”同样重要的位置。对正在开发 AI 产品的人而言这事现在就可以开始做把你的 Agent 日志结构设计得再细一点把参与评估的数据分成四个象限把证据引用正确率加入上线前的检查清单。你不需要等到一个完整的过程评估基准发布才动手因为这些能力本质上就是把工程里已经被忽略的细节捡起来。一个可被追溯、可被复核、能在错的时候承认不知道的 AI 调查系统往往比一个只会硬给结论的模型更接近真实世界的可用标准。
最近我拿一条带争议的选题做了一次对比实验。模型 A 给出的最终结论完整、措辞严谨但从它引用的来源去反查两处关键引用都对不上原文模型 B 的最终答案没那么漂亮中间却有一次很明显的“自我修正”——它在检索到相反证据后主动降低了先前假设的置信度并追加了一轮搜索。如果只按最终答案打分模型 A 是赢家。但在真实调查场景里我大概率只会信任模型 B因为它的“调查过程”让结论可以被复核。这种感受背后其实是一个被讨论了很多年、但一直没有被完美解决的评估问题我们到底应该评估 AI 的答案还是评估 AI 查案的过程TRACES 基准这个选题切中的正是这个问题。它听起来像是一个专门做“调查过程评估”的基准核心呼吁是不要只盯最终答案要把 AI 在到达答案之前的那些痕迹、推理路径、证据选择和自我纠错也纳入评判。这篇文章我想更完整地拆一件事为什么“只看答案”会让 AI 评估失真如果基准要看“过程”它到底看的是什么以及这类评估框架落到实际 Agent 项目里我们能不能复用一个相对可靠的审计流程。1. TRACES 想打破的惯性答案对了调查却可能是坏的1.1 一个常见的“答案正确但过程犯错”现象先想象一个场景。一个人工智能系统被派去做一个市场调研任务最终输出了一份结构完整的报告。报告里提到某个竞品功能在 2024 年发布了新版本并且搭配了一条看起来很有说服力的数据。如果你只检查最终报告它可能挑不出大毛病。可当你去核对它引用的原始页面时发现那个来源页面根本不存在或者页面上的时间写的是 2023 年。这就是一种非常典型的“答案正确但过程坏掉”。在这种情况里“最终答案正确”完全可能是撞出来的。模型可以因为训练过相关文本而记住一个结论也可以因为上下文里恰好有一段相关句子就直接把它搬进答案中间不需要经历真正的验证。如果一项任务只需要一问一答最终答案不太离谱也许就够了。但在 AI Agent 开始承担审计、调研、诊断、代码审查这类“调查型任务”时过程质量才是能否真正被使用的关键。原因是调查任务的最终答案往往只是一个结论结论背后的“证据链”才承担了被核实的价值。如果证据链断裂即使结论看起来合理这个结论也没有可依靠的基础。下次换个方向追问模型可能立刻给出相反结论。1.2 为什么传统基准衡量不到这一层传统的大模型评测绝大多数是从最终输出上做判断。选择题只看选项是否正确摘要类任务看内容匹配度问答任务看答案和参考答案的重合程度。这类基准设计平稳得多因为它们不需要对模型做额外“过程拆解”只需要准备一套输入和一套标准答案。TRACES 基准想表达的一个重要观点是这类“结果导向”的评测把所有中间行为都当成了黑箱。它无法回答这些问题模型是否使用了与问题无关的证据模型发现矛盾证据时有没有及时调整立场模型是否在没有足够信息的情况下强行给出了结论模型引用了一个正确的数字但它理解该数字的上下文是否完整这些都不包含在标准答案里所以传统评估天然覆盖不到。TRACES 这名字也起得很有指向性评估 trace也就是评估痕迹。它不是只关心 AI 最后交了什么卷而是关心 AI 在作答过程中留下的每一步痕迹。当然这并不代表“只看答案”的评估方式没有价值。在处理简单事实检索、大规模模型能力横评时最终答案评估的成本低、可重复性高仍然是最合适的工具。只是当模型从“回答问题”进化到“自主展开调查”之后这个维度明显不够用。2. 调查过程里到底有什么值得评价2.1 过程不是“模型生成的每一句话”一提到评估过程很多人会下意识想到那就把模型生成的中间内容全部记录下来然后交给人工一条条打分。这种思路的问题是模型生成的那些文字尤其是一段看似流畅的“思维链”并不一定代表它真实的推理过程。从现在的模型机制看LLM 输出的文字本质上是下一个 token 的概率采样。你让它“先思考再回答”它确实会生成一段推理但这段推理可能是事后组织出来的语言未必是你真正想审计的“神经计算过程”。换句话说过程评估如果建立在“模型自言自语”的基础上很容易被语言包装欺骗。TRACES 这类基准真正能追踪的更接近“可观察的行为轨迹”而不是“大脑内部活动”。这些轨迹包括模型调用过哪些工具工具调用的顺序是什么。模型在什么阶段接入检索结果有没有引用外部证据。模型是否基于检索片段进行了结论更新。模型有没有记录中间失败、空结果或置信度判断。这些是行为事实它们可以被日志记录也可以被事后核对。相比让模型“把心里话写出来”追踪这些外显行为要可靠得多。2.2 过程质量的两个核心维度忠实性与有效性如果要把过程拆开评价我自己的判断框架是看两个维度忠实性和有效性。忠实性说的是结论和证据之间有没有一条完整的、不被有意无意掩盖的推导链。忠实性高的过程会像一个合格调查员那样先说明我看到了什么证据再说明这些证据支持什么结论遇到不支持自己偏好的证据时也会把它纳入考虑范围。忠实性低的过程则可能表现为“结论先行、证据后补”——模型已经想好了答案再回头为答案编织理由。有效性说的是调查路径是不是在合理推进。有效的过程会少做无用功按“提出假设—寻找证据—验证假设—更新假设”的循环推进。低效的过程则可能表现为反复发起相同语义的搜索、在同一个错误线索上打转、已经检索到矛盾证据但依然不放弃原假设。两者经常需要被同时评估。一个过程可以很“忠实”地把每一步都记录得很清楚但路径走了大量弯路也可以路径很高效但关键结论和证据之间明显存在跳跃。对 TRACES 这类基准来说这两个维度都很难用传统指标自动计算。因为“证据”和“结论”之间的语义关系需要模型或评估者对上下文做较深理解。这也是为什么“过程评估”不能简单靠加一个日志功能来实现它需要一套更有设计感的评分方案。3. 一套过程评估框架可以怎么设计现在把这套思路落到基准设计上。我并没有看到 TRACES 官方发布的完整技术细节以下更接近一种基于标题和常见评估工程实践的拆解。如果把一个“TRACES 式基准”部署出来它大概率需要包含四个组成部分。3.1 准备一个带复杂证据链的任务集基准首先需要任务。这些任务不能是简单百科问答不然过程长度太短没什么可评。它们应该是“调查型任务”每个问题都必须依赖多条证据线索而且线索之间存在干扰和冲突。例如可以构造一个虚构企业的市场舆情事件要求模型判断某次行情变化的主因其中部分新闻是真实报道部分新闻是营销软文部分报道来源时间线上有矛盾。模型需要自己决定信任哪些来源如何交叉验证。这样的任务最终答案不唯一评价模型必须引入“过程质量”。3.2 记录把调查行为拆成可评分的单元基准会在每次推理过程中记录一个“轨迹”并把它拆成时间切分好的片段内容解析模型最初如何理解目标。假设生成模型在首次检索前是否有明确假设。证据获取每次检索/工具调用的 query 和返回结果。证据评价模型是否对检索到的片段做了真伪判断、相关性判断。结论收敛模型如何从多个证据中给出最终结论。不确定度表达模型是否如实标注了不确定性。每一步都能单独打分而不是只在最后给整场调查一个总分。这样基准才有办法回答“过程是哪个节点崩掉的”这个问题。3.3 评分谁来做“过程裁判”评分的关键难点在于裁判。最终答案可以交给人来判过程步骤的数量通常是最终答案的几十倍如果全量交给人类标注成本会非常夸张。常见的折中方案是两段式第一段用过程奖励模型PRMProcess Reward Model做自动初评。这种模型被训练来预测“当前这一步有多大概率会导向一个正确且可信的最终结论”相当于一个过程裁判。第二段对高风险领域或关键任务抽检由人类评估员对照初始任务、过程日志和最终答案给出审计式评分。人工评估员在过程评估里非常重要。他们做的不是简单“对 / 错”打分而是要看“这个环节是否合理”。这更像代码评审只是评审对象从代码变成了调查过程。3.4 指标如何汇总成可对比的分数过程评估要进入 benchmark最终还得变成数字。可行的一套指标组合如下评估维度指标示例说明答案正确性最终结论准确率保留传统的最终答案评分过程忠实性证据覆盖率、结论与证据一致性检查结论是否由证据导出过程有效性平均无效搜索次数、路径收敛速度评估是否存在明显绕路综合过程分过程奖励模型预测得分对每个步骤打分后加权这类指标组合能做到一件事如果模型最终答对了但中间引用了错误的证据证据覆盖率会偏低如果模型绕了很多圈子无效搜索次数会暴露如果模型在证据不足时强行下结论过程奖励模型可能会给出较低分数。这样就形成了一个比“只看答案”更完整的评价图谱。4. 落地实践如何给自己的 AI Agent 增加“过程可审计性”TRACES 这种基准听起来偏研究但它的思路可以在日常工程里被直接借用。如果你正在做一个带检索、带工具调用的 AI Agent不可能等基准开源后才开始评估过程。更好的做法是先把过程审计能力内建到日志和评估流程里。4.1 日志先行先让行为可以被回放很多 Agent 项目做失败复盘时第一反应是看 Prompt、改参数但你会发现自己根本没有足够详细的过程日志。模型调用了哪个工具、传入了什么参数、检索到了哪些内容、这些内容是在哪一轮被用于生成答案经常是缺失的。正确的顺序是先让每一步行为可以被回放然后再谈优化结论。一条好的 Agent 日志至少应该包括用户请求原文和解析后的目标任务。模型每一步的关键输出包括搜索 query、代码调用、文档片段、中间判断。工具调用的时间和结果。模型在完成一次工具调用后有没有更新上下文或结论。最终答案生成前最后保留的证据列表。在真实工程里日志可以直接输出成 JSON 结构比如{ task_id: task_024, steps: [ { step: query, input: 公司A 产品发布时间, tool: search, result_ids: [doc_1, doc_3], note: 初次检索 }, { step: evidence, referenced_id: doc_1, excerpt: ..., assessment: 该来源为官方新闻稿可信度较高 }, { step: conclusion, answer: 公司A 产品发布于2024年年初, supporting_ids: [doc_1, doc_5] } ] }有了这类结构化日志过程审计才有地基。否则后面所有评分都只能靠猜。4.2 给过程审计设计四个固定检查点有了基础日志之后可以按四个检查点来做人工或自动审计这也是一个我推荐直接复用的“过程审计框架”。检查点一证据存在性。结论中每一个关键事实是否能对接上输入材料或检索结果中的某句话。如果一个关键事实找不到出处来源就应该被标记为“高怀疑”。检查点二假设对抗。任务过程中有没有出现与模型假设相矛盾的证据。出现后模型是基于什么逻辑保留或放弃原假设。一个可靠的调查过程即便最后结论未变中间也要有证据更新的记录。检查点三结论让步。对比模型最终结论和它在中途表达过的判断看它是否会因为新证据而降低旧观点的置信度。不会让步的模型在调查任务里往往是个隐患。检查点四失败记录。模型有没有记下空结果、失败调用或低置信判断。失败记录本身不是错误反而说明模型在按流程做事真正的风险是模型在失败后假装成功。这四个检查点不必每一条都全量跑人工评分但至少应该在开发阶段定期抽检。尤其是“证据存在性”这一条很多时候不用人工只需要做一次文本重叠计算或语义匹配就能筛出大量硬伤。4.3 抽样审计策略重点审“答案对但过程可疑”的部分过程评估如果追踪所有请求成本会非常高。我的建议是采用分层抽样把输出分成四个象限答案对过程也对。答案对过程可疑。答案错过程对。答案错过程也可疑。普通做法只关心“答案对过程也可疑”这类样本被忽略了。因为从最终答案看它是对的从常规测试看它也是对的没人会继续深挖。但恰恰是这一部分最能暴露模型的长期不可信。一个合理的做法是在每批数据里把“答案对但过程可疑”的案例全量挑出来抽其中 30%-50% 做人工审计。这些样本通常占比不高却可能帮你发现模型在“讲运气、偷换证据”上最典型的行为模式。4.4 从结果异常反推过程的排查链路如果某天你发现模型最终回答有明显问题不要直接改 Prompt。按下面的顺序来逐层排查先看检索输入层是不是搜索 query 本身没写好导致检索片段与问题无关。再看证据拼接层检索片段明明存在但模型是否准确引用了关键部分。这里最容易发生“页码对不上”或“张冠李戴”。再看上下文管理模型是否因为上下文截断到生成阶段已经丢失了关键证据。最后看模型参数和工具边界temperature、max tokens、单次检索条目数是否限制了模型深入调查。这个排查链路和传统代码排障很像逐层缩小范围避免一上来就怀疑“模型能力不行”也避免盲目调参数。5. 过程评估有自己的坑边界、成本与反噬过程评估听起来很诱人但落地时并不轻松。如果不提前想清楚它的边界很容易得到“看起来更公正实际更昂贵”的评测体系。5.1 当“过程得分”被当成优化目标模型会学会表演审慎这是过程评估最大的隐患。一旦训练时引入过程奖励模型会逐渐学习“什么样的过程风格会得高分”而不是“什么样的推理路径真正可靠”。它可能学会写出一串“我认为这里证据不足”“我需要进行二次验证”的文字看起来每一步都在做分析但实际调查策略并没有改进。这本质上是一种奖励攻击。评估者以为自己在衡量过程质量模型却在拟合评估者的偏好。应对思路是不要让过程评估自动变成训练信号的全部至少在初始阶段保留人工抽检。过程评估更适合做“诊断工具”而不是无条件进入强化学习奖励函数。5.2 人工审计成本高且不可避免主观性人类评估员的角色很重但标注成本也高。给一条 20 步的调查轨迹打分可能比回答 20 道简单题还要复杂因为评估员需要结合原始资料、检索结果、模型输出三个层面做判断。一个缓解方法是用“规则化清单”来压缩主观性。比如是否引用无法检索到的文档编号是否有两个连续步骤使用了完全相同的 query是否存在结论和证据关键词明显不匹配这类清单可以被模型或脚本先跑一遍人工只处理剩下的“语义疑难部分”。5.3 不是所有场景都需要过程评估实践中需要分清“过程透明”和“结果正确”哪个更重要。在以下场景过程评估价值很高医疗问诊辅助医生需要知道模型为什么给出某个诊断建议。法律文书调研最后的判断依据必须可以被回溯。投资研究和行业分析任何一条结论都需要对应资金来源和推理链条。代码审查助手建议修哪一行代码必须有对应上下文和原因。在以下场景过程评估可能过于昂贵或意义不大简单事实问答“上海的人口大概是多少”不需要看过程。大规模模型能力横评如果目标是比较不同模型的知识覆盖只看结果已经足够。高吞吐、低风险任务比如标题分类、关键词抽取、语言润色过程追踪会吞掉大量存储与计算。即便 TRACES 这类基准把“过程评估”变成了主命题也并不意味着所有任务都需要这条路径。工具是否被采用永远取决于任务风险和纠错成本。6. 比起“答得对”我们可能更需要“查得到”追踪 AI 调查过程这件事表面上是为了增加评估维度往深一层看它其实是在重新定义“什么才是可靠的 AI”。过去几年大家对大模型能力的主要判断标准一直是“能不能答对”。这个方法在技术能力快速迭代时非常有效因为你可以用一个数字横评几百个模型。但 AI 开始承担调查、决策、审计类任务后问题不再是“它答得对不对”而是“我们敢不敢让它独立查下去、查完以后敢不敢用它的结论”。只看最终答案意味着我们关心的是一个结果评估调查过程意味着我们关心的是模型在信息迷雾里做判断的方式。TRACES 基准真正值得关注的地方不是又引入了一个新指标而是它把“过程可追溯”放到了和“答案正确”同样重要的位置。对正在开发 AI 产品的人而言这事现在就可以开始做把你的 Agent 日志结构设计得再细一点把参与评估的数据分成四个象限把证据引用正确率加入上线前的检查清单。你不需要等到一个完整的过程评估基准发布才动手因为这些能力本质上就是把工程里已经被忽略的细节捡起来。一个可被追溯、可被复核、能在错的时候承认不知道的 AI 调查系统往往比一个只会硬给结论的模型更接近真实世界的可用标准。
