像圣训学者评级叙述者那样，为AI Agent建立可信度档案

把 AI agent 的可靠性像圣训学者给叙述者评级那样去评估这个思路值得认真聊。我最近在连续测试几个 agent 系统时最直观的感受是单看 demo 都能跑一旦进入多步任务“错误从哪来”就变得非常难判断。答案是模型生成错了还是检索拿到了过时资料工具返回了空结果还是 prompt 根本没约束住指令如果只看最终输出你根本没有足够信息定位问题。所以当看到“为什么我们不像圣训学者给叙述者评级那样给 AI agents 评级”这个问题时我意识到它指出了一个在 AI agent 工程里经常被忽视的问题可靠的 agent 不只需要更强的模型还需要一套能追溯来源、识别薄弱环节、对每次输出给出可信度判断的机制。圣训学者在几百年前面对的困难本质上也是这个在信息靠口耳相传的时代如何判断“这条信息可不可信、是谁传的、传述过程中有没有失真”。现代的 AI agent 虽然换了媒介但问题相同——一条输出背后模型、工具、数据、提示词各自贡献了什么谁在为这些贡献建立档案下面就把这个古典方法论拆成 AI 开发者能直接落地使用的评估和管理思路。1. 圣训式评级的核心不是“评分”而是“让可信度可追溯”1.1 他们评的是整条传述链不是一句话这个类比里的“圣训学者”指的是古典文本考据传统中专门负责判断传述信息可靠性的学者。他们最典型的做法是不只看一段文本本身读起来合理不合理还要看它从最早的记录者一路传到后人手里的整条链条。放在当时的环境里这其实是一个非常超前的工程思维。在没有录音、没有数据库、没有自动化回放的情况下一条信息只能依靠人与人之间的口头传承。学者需要回答的问题不是简单的“这句话对不对”而是“这句话是怎么到我们这里的”。为此他们会给每一条传述建立传述链链条上的每个叙述者都会被单独评估。评估维度包括这个人是否公正可靠记忆力是否稳定传述是否严谨有没有和其他可靠记录冲突的历史甚至还要看他在什么年龄段传述的这条信息。评级结果也很有意思它不是简单的“可信”或“不可信”而是分层的。有的人被评为可靠有的人被评为诚实但记忆力不稳定还有的人被认为早年可靠、晚年传述开始混乱。这些分层不是为了让某条信息“得高分”而是为了让后来的查证者知道这条信息在哪个环节可信在哪个环节需要保留。这个思想放在今天看本质上是一套“可信度追溯系统”。它不假设信息源绝对可靠也不假设传递过程不会失真。它只是通过严格的记录和评估把一条信息从源头到最终呈现之间的每一步都暴露出来让每个人都能看到薄弱点在哪。1.2 今天的 Agent 评测缺的正是这种“叙述者档案”现在的 AI agent 评测也就是很多人说的 evals主要在做两类事情一类是给模型本身出题看准确率另一类是给 agent 跑任务看成功率。这两个指标都有用但都有同一个问题它们把结果聚合成一个数字或一个百分比却不解释失败发生在哪一步。举个例子。一个 agent 执行“查上季度销售数据并生成摘要”这个任务如果最终摘要错了你很难从“成功还是失败”里看出问题到底出在哪。可能是数据库查询语句写错可能是知识库检索召回了过时资料可能是 LLM 在生成时脑补了不存在的数字也可能是 prompt 根本没有要求模型引用来源。这些原因对应的修复方式完全不同SQL 问题要改工具调用逻辑检索问题要换数据源或加 reranker幻觉问题要改生成策略引用问题要改 prompt。没有 step 级别的 trace就只能靠猜。圣训式评级在这里给了一个很重要提示知识可信度不能只用最终结果来判断必须依赖过程档案。你不仅要接受“这件事值得信”这个结论还要知道“是哪个环节降低了我对它的信任”。把这个逻辑搬进 agent 工程就是要让每个 agent 输出都有可追溯的“叙述者档案”也就是运行轨迹和来源记录。2. 把评级逻辑翻译到 Agent 工程从日志到可信度档案2.1 一条 Agent 调用链就是一条现代传述链现代 AI agent 系统通常由多段调用组成。用户提出一个问题后agent 可能会先调用检索器去查询知识库再调用一个工具去执行 SQL甚至把中间结果传给另一个模型做摘要最后才返回给用户。每一步在功能上都像传统传述链里的一个“叙述者”它拿到上一步的信息处理后传给下一步。这里最隐蔽的问题是错误继承。每一步都只接收上一步传过来的输出不会主动检查上游数据是否可靠。如果检索器返回了错误资料后续的生成模型大概率会把错误内容写进答案如果工具返回了空列表agent 可能不会识别异常而是根据对话历史继续生成一个看似完整的回答。在圣训学者看来这就是“传述链条上某个叙述者不可靠”的典型场景必须单独标记而不是让整条链默认可靠。工具调用和模型生成交错执行的场景更容易失控。比如 agent 先调用代码解释器跑一段数值计算再把运行结果塞给 LLM 生成结论。如果运行代码时发生了静默异常或者代码忽略部分输入最终结论就会被污染。这类问题如果只做端到端评测很难定位源头。所以第一步不是追求更高的准确率而是先回答这条链上的每个环节是否能被完整记录每个环节的输出是否知道它基于什么输入这就是现代版的传述链建设。2.2 可信度档案的字段设计如果要照搬圣训式评级第一步不是做复杂评分而是给 agent 的每一次运行建立结构化档案。我建议从比较小的字段集合开始先记录关键信息再逐步补充。字段含义为什么重要task_id每次任务的唯一标识把评测、日志和人工反馈关联起来trace_id多步调用链路的标识还原 agent 的执行顺序agent_version使用的 agent 代码版本避免版本混乱导致结果不可比model_name / model_version底层模型及版本模型升级会显著改变行为prompt_version当前使用的 prompt 版本prompt 改动也是评测变量tool_name / tool_version调用的工具及版本工具升级、权限变化会影响结果input_source输入数据来自哪里用于判断是否过期、越权或污染tool_status工具调用是否成功区分 agent 答错和工具本身失败evidence_list当前步骤引用了哪些来源可追溯性的核心依据output_content_hash输出内容校验值便于多次运行结果差异比对字段不需要一开始就设计得很完美但上述几项属于底线。没有这些信息后面对话级评测、批量统计、失败排查都会变成无源之水。2.3 先把日志记录下来再谈评分我见过不少团队上来就想搞一个复杂的评测平台结果连最基本的调用日志都没有。实际落地时建议从一个最简单的结构化日志开始。比如每个任务结束后输出一段 JSON以下是一个通用示例结构不是某个生产项目的真实日志{ task_id: task_20240101_001, query: 统计上季度销售数据并生成摘要, agent_version: sales_report_agent_v0.3, model: gpt-class-model-v2, prompt_version: prompt_sales_summary_20231215, trace: [ { step: retrieve_knowledge, tool: knowledge_base_search, query: 上季度销售数据, status: success, source: [kb://finance/sales_q4.md], output_excerpt: 2023Q4 total sales: 1280000 }, { step: sql_query, tool: database_readonly, sql: SELECT SUM(amount) FROM sales WHERE date 2023-10-01 AND date 2024-01-01, status: success, affected_rows: 128, source: [db://prod/sales?regioncn] }, { step: generate_summary, tool: llm_call, model: gpt-class-model-v2, temperature: 0.2, status: success, evidence: [kb://finance/sales_q4.md, db://prod/sales?regioncn], output_excerpt: 上季度总销售额为128万。 } ], final_answer_source_reliable: true, uncertainty: low }你完全可以用现有日志框架输出类似结构。关键是每条 step 必须包含状态、来源和输出摘要否则后续无法验证。记录一周之后再开始设计评分维度。很多时候问题会在整理日志时自然暴露出来比如某个工具总是返回空结果某个 prompt 版本下经常不引用来源某个模型版本升级之后错误率明显升高。这些发现远远早于你做一个漂亮的评分页面。3. 从单任务到批量评测具体怎么打分3.1 先定义错误类型再定义评分维度不要用笼统的“对”和“错”给 agent 打分。在 AI 测试里我一般会先把错误拆成类型再做评价。常见的错误类型包括事实性错误、推理错误、检索不完整、指令偏离、工具调用失败、引用缺失、幻觉无来源生成。不同类型对应不同的处理策略。评分维度可以从这几个方向看可追溯性最终答案的每个关键断言是否都有来源正确性答案是否符合事实和任务预期完整性用户提出的要求是否都被满足一致性多次运行或同一链路不同步骤之间是否有冲突合规性是否包含越权访问、敏感数据泄漏或违反产品规则。评分不一定要是 0 到 100可以用 0/1 分制加备注也可以直接用等级制。关键不是分数长什么样而是你要能回答一个问题这条结果为什么会被扣分扣分点落在哪个环节如果无法回答说明字段记录还不够细。3.2 单任务验证先跑十到二十条样例批量评测之前先跑小样本。10 到 20 条具有代表性的任务逐条打开 trace人工打分。我建议选择能代表生产环境真实分布的案例不要只挑简单的。如果评测集里全是“你好”“介绍一下自己”这类任务那跑再多也反映不了真实问题。单条任务怎么判断合不合格按证据链判断就行最终答案是否可追溯到具体来源如果答案没有来源agent 是否明确说明这是推测工具调用是否成功失败时 agent 有没有处理异常prompt 要求的目标是否被执行完整。这些判断比单一准确率更有可操作性。如果小样本里已经发现三类以上的失败模式不要急着扩量。先把错误源头处理掉再继续跑。比如模型总是漏掉引用就先调 prompt工具总是超时就先查工具本身知识库总是返回重复内容就先清洗数据。小样本的价值在于快速暴露问题而不是得出一个可靠得分。3.3 批量聚合别让表现最好的样本掩盖整体问题小样本跑通之后再扩大规模。批量评估最忌讳只看平均值。举个例子评测集里 80% 是简单问答agent 正确率 95%剩下 20% 是多步工具操作结果全部失败。平均下来也有 76%看起来还行但实际上所有真实多步任务都会崩。正确做法是按任务类型分层统计。可以按“任务复杂度”“工具调用次数”“输入来源类型”“输出长度”切分样本单独看每层准确率和失败率。同时还要关注稳定性同样输入连续跑三次结果是否一致如果时好时坏平均值再高也不能直接上生产。批量任务里还要记录资源消耗。同一个任务不同 prompt 版本可能让 token 消耗翻倍也可能让平均调用时间从 3 秒变成 15 秒。这些指标虽然不影响“答案对不对”但直接影响成本和用户体验。圣训式评级关心的不只是真伪也包括“这个传述过程有没有异常”。放到 agent 场景就是耗时、重试次数、工具调用失败率和 token 波动。3.4 人工复核和自动校验怎么分工自动校验适合规则明确的环节。例如检查工具返回状态、引用字段是否为空、输出是否为合法 JSON、字符串是否包含特定字段。事实性判断建议人工抽样复核或者用知识库做对照。如果有争议最好让两个人独立标注再看标注一致性。自动评分和人工判断冲突时先检查自动指标定义是不是有问题不要直接改阈值迁就。比如自动打分要求“必须有引用”但某些任务本来就不需要外部资料这时应该按任务类型区分规则而不是放宽所有引用要求。评测系统的价值不在于给出一个好看的数字而在于每次评分变化都能定位到具体的 trace 变更。4. 做 Agent 评测时最容易踩的四个坑4.1 只评最终答案不评推理和调用过程在 agent 场景里最终答案正确不等于过程可靠。Agent 完全可能检索到错误资料后模型根据自身知识修正了答案。看起来答对了但从系统角度看知识检索已经失效换一个输入很可能就会崩。也可能最终答案是从错误信息里硬凑出来的语句通顺但事实错误。如果评测只保存最终文本这些问题全都会漏掉。正确做法是同时保存每个 step 的输入、输出、来源和错误信息。至少要在评测报告里标注“最终答案正确但中间存在工具失败”或“答案无误但引用来源为空”。这类备注对后续优化非常有价值。4.2 把模型“置信度”当成可信度很多 AI 助手会在回答后加一句“我对这个答案有 90% 把握”但这并不是可信度评估。LLM 的自评置信度受话术、上下文和训练数据影响很大。在事实数据不足时它也可能流畅地编出详细解释甚至附上虚假引用。这在 AI 幻觉相关测试里非常常见模型对自己的错误答案越自信越容易误导用户。圣训式评级关心的是证据链不是叙述者嘴上说自己有多可靠。对 LLM 来说唯一可靠的“可信度”来自外部验证。检索到的资料、数据库返回值、代码执行结果这些都是可以复核的证据。当一个断言没有外部证据时应该标记为“未验证”而不是让模型自评。4.3 忽略工具返回值和上游数据质量Agent 是一个信息放大器。上游数据错了下游一定错。我在测试时遇到过很典型的情况agent 调用查询工具工具返回空列表agent 没有检查空值而是根据上一轮对话继续生成最后给出一个看似完整的回答。从最终文本看语句通顺结构清楚但内容完全是瞎猜。如果不记录工具返回的原始内容或摘要排错时根本不会想到问题出在空结果上。所以评测时要记录工具返回的原始值、状态码、耗时和重试情况。至少也要保存原文或哈希方便回放。上游数据源本身也要定期检查尤其是知识库、数据库、外部 API 的内容有没有更新版本有没有过期。4.4 收到报错就改参数不先定位是模型还是环境问题你可能会遇到 agent 突然不按指令执行。有时候是 prompt 问题有时候是工具返回值格式变化有时候是依赖版本升级导致函数签名变了。如果一报错就调温度、调 max_tokens、加重试次数很可能越调越乱。排查顺序建议固定先看日志和 trace定位是哪一步失败再检查输入格式、路径、权限、数据源是否正常确认环境没问题后再看 prompt 版本和模型版本最后才考虑调整随机性相关参数。很多问题和温度无关而是环境或数据源的问题。只有每一步都确认过才能确定要改哪里。这也是为什么“可追溯日志”是圣训式评级的基础设施没有日志排查永远只能靠猜。5. 落地“圣训式评级”的最小实践清单5.1 先给 Agent 建“叙述者档案”在 AI agent 开发里可以给每个 agent 建立一个类似 AGENT_CARD 的记录文件。写清楚这个 agent 是谁底层模型、prompt 版本、工具列表、输入输出格式、已知限制、最近变更。每次发布前更新一次。这个档案的作用不是宣传而是帮助评测工程师快速知道一个分数变化到底是因为模型升级、prompt 调整还是工具权限变化。没有档案评测结果就是无源之水。你可能会遇到“昨天还行今天全错”的情况如果档案里记录了今天改过 prompt 版本排查范围就能快速缩小一半。5.2 用分级可信度替代单一分数与其给每次输出打一个 0 到 100 的分不如定义几个可信度等级更容易让下游使用者理解。一个可参考的分级方式是A 级每个关键断言都有来源来源可访问工具调用成功无事实冲突。B 级大部分断言有来源但部分来源时效不明或范围有限。C 级部分输出来自模型自身生成缺少明确来源。D 级存在工具失败、内部不一致或引用不可查需要人工介入处理。对知识问答、报告生成、风险预警这类场景至少应该要求 B 级以上才能对外使用。对纯创意写作则可以放宽。分级可信度的好处是产品侧可以直接根据等级决定展示方式A 级可以直接呈现C 级要加提示D 级需要走人工复核流程。5.3 让 Agent 在低证据场景主动说“我不确定”在 prompt 或策略层写清楚没有检索到证据时必须声明这是基于模型知识的推测不能伪造引用。这个改动会牺牲一点点流畅度但能减少很多误导。对 AI 产品经理来说明确告诉用户“这个回答没有得到资料支持”比一个自信但可能是幻觉的答案要可靠得多。这套机制可以配合检索置信度、工具失败标志、来源数量一起用。当证据不足时agent 不一定要停止回答但至少要降低语气确定性而不是用理所当然的口吻给出结论。5.4 哪些场景适合哪些场景不要硬套这套方法适合对可追溯性和准确性要求高的场景企业内部知识问答、周报摘要、风险报告初稿、法律和医疗辅助材料、代码审查建议。对这些场景用户需要知道来源也需要知道哪个环节可能出错。但并不是所有场景都值得付出这套成本。如果只是做一个轻松的聊天机器人或者给短视频写创意文案强制给每个回答建立证据链会很别扭也会增加延迟和成本。圣训式评级本质上是一条“评价与审计”路径不是所有对话都需要这么重的机制。落地时要做取舍先对高风险、强证据需求的任务启用分级可信度再逐步扩展到更多 agent。这样既不会拖慢开发节奏也能在最容易出错的环节真正守住可靠性这条底线。