如何判断一个AI智能体是否真正使用了正确的证据

AI 智能体可以引用来源、检索文档,却仍然使用错误的证据。一个来源可能具有权威性,但与具体主张无关。一段检索到的文本可能只支持答案的一部分。一个正确的来源可能已经过时、被取代,或者只适用于错误的司法管辖区、产品版本、用户或系统状态。这就产生了一个比简单引用检查更难的评估问题:智能体是否真的为其所提出的主张使用了正确的证据?
为什么仅有引用还不够
引用只能回答一个狭窄的问题:系统将某个主张或回复与某个来源关联了起来。它并不能自动证明该来源支持这一具体主张、该来源对该任务足够权威、被引用的文本包含必要条件或例外情况,或者模型依赖了该证据,而不是根据先前的模型知识生成答案。
Anthropic 关于研究型智能体评估的指南明确区分了扎根性、覆盖率和来源质量。OpenAI 的智能体评估指南同样强调轨迹,因为最终输出无法揭示智能体是否选择了正确的工具或遵循了预期的工作流程。这些观点指向一个更广泛的结论:证据质量是执行路径的属性,而不仅仅是最终文本的属性。
每一项重要主张都应通过的四个问题
| 维度 | 问题 | 典型失败 |
|---|---|---|
| 主张支持 | 证据是否直接支持这一确切主张? | 来源在主题上相关,但并不能证明该陈述 |
| 证据权威性 | 对于这类主张,这是否是适当的来源? | 在需要一手来源或实时系统的地方使用了二手摘要 |
| 适用性 | 证据是否适用于该时间、版本、司法管辖区、用户、状态或人群? | 一个真实的陈述被应用到了其有效条件之外 |
| 证据使用 | 该证据在智能体的执行路径中是否实际可用并被使用? | 最终答案是正确的,但检索到的证据无关或未被使用 |
1. 主张支持:来源是否证明了智能体所说的话?
证据应在主张层面进行评估。一份文档可能与主题相关,却仍然无法支持某个具体陈述。如果来源说某项功能仅在部分区域可用,那么“该功能在全球可用”这一答案就是没有依据的,即使引用看起来似乎合理。
这正是宽泛的“有依据 / 无依据”判断往往过于粗糙的地方。将回复拆分为重要主张,把每项主张映射到支持它的最小证据片段,并对关系进行分类:直接支持、部分支持、矛盾或无支持。
2. 证据权威性:这是正确类型的来源吗?
正确的证据选择不仅仅是语义相关性。来源必须适合该决策。当前账户状态应来自账户系统,而不是一封旧邮件。关于 API 行为的主张最好应依据当前供应商文档或可复现行为来核查。法律要求可能需要适用法律、监管机构或权威指南,而不是一篇泛泛的博客文章。
来源权威性是任务特定的。对于供应商文档未承认的真实世界漏洞,社区报告可能是最佳证据。供应商公告对于供应商所声称的内容可能具有权威性,但对于独立性能而言则是弱证据。因此,评估者需要为任务制定明确的来源层级,而不是使用一个通用的权威评分。
3. 适用性:证据正确,条件错误
最危险的证据错误往往不是伪造来源,而是有效来源被用在其边界之外。建议可能会随软件版本、日期、司法管辖区、硬件修订版、用户权限、产品可用性、当前游戏状态、租户配置或其他环境变量而变化。
对于每个重要来源,都要保留决定其是否仍然适用的条件。这在摘要之后尤其重要:压缩后的记忆或引用可能保留了结论,却丢掉了使该结论有效的例外、日期或前提条件。
4. 证据使用:智能体是否真正依赖了证据?
即使检索失败,答案也可能是正确的。模型可能已经知道答案,从不相关的上下文中推断出答案,或者只是碰巧猜对了。如果评估只检查最终正确性,系统可能看起来有充分依据,而证据路径却是断裂的。
要评估证据使用情况,需要检查追踪记录。确认检索到了哪些来源、哪些段落进入了模型上下文、它们何时可用,以及最终主张能否由这些输入解释。OpenAI 当前的智能体评估工具强调追踪评分,正是因为仅凭最终答案无法可靠地重建工作流层面的行为。
证据利用测试
一种实用的评估可以构建为受控的反事实测试。不要只问答案是否正确,而是改变证据并观察主张是否按预期方向变化。
证据利用测试
主张–证据矩阵比来源列表更有用
| 主张 | 证据 | 支持 | 权威性 | 适用性 | 追踪中是否使用 |
|---|---|---|---|---|---|
| 功能 X 可用 | 供应商文档 | 直接 | 对可用性主张具有高权威性 | 当前版本和地区必须匹配 | 是 / 否 |
| 配置 Y 更快 | 供应商基准测试 | 部分 | 对供应商的测试具有高权威性,但不代表独立性能 | 硬件和工作负载必须匹配 | 是 / 否 |
| 政策适用于此用户 | 当前政策 + 账户状态 | 仅组合时直接 | 高 | 管辖范围、日期、角色和账户状态必须匹配 | 是 / 否 |
| 某产品有库存 | 实时库存 API | 直接 | 对当前库存具有权威性 | 很快过期 | 是 / 否 |
这个矩阵迫使人们提出几个传统引用检查所隐藏的问题。一个主张可能需要多个来源。一个来源可能只支持主张的一部分。一个权威来源可能只有很短的有效期。而一个完全良好的来源,如果从未进入执行路径,也可能无关紧要。
将检索质量与证据质量分开
检索指标询问是否找到了相关材料并进行了排序。证据评估询问这些材料是否证明了由此产生的主张。两者相关但并不相同。
检索成功不等于证据成功
| 情况 | 检索 | 证据质量 | |
|---|---|---|---|
| 正确文档,错误主张 | |||
| 正确事实,过时来源 | |||
| 弱来源,正确答案 | |||
| 需要多个来源 |
将来源质量作为评分标准来评估,而不是域名白名单
硬编码的“可信域名”列表很诱人,但往往很脆弱。来源质量应改为反映主张类型。有用的维度包括一手与二手地位、时效性、直接性、可复现性、独立性、领域专业知识、数据来源、更新频率,以及来源是否有夸大主张的动机。
Anthropic 的研究智能体评估指南明确将来源质量检查与有据性和覆盖范围并列提出。因此,实际实施应同时评估来源说了什么,以及该来源是否适合这类陈述。
证据覆盖范围:每个重要主张都需要支持,而不是每句话
并非每一句话都需要引用。过渡性语言、从引用值透明推导出的算术结果,或明确标注的解释,可能不需要单独的来源。但每一个实质性的、可外部验证的断言都应有足够的支撑,使评估者能够重建为什么该智能体被允许这样说。
因此,覆盖度应按断言重要性加权。装饰性细节缺少支撑,与价格、资格决定、安全说明、法律要求、技术兼容性声明或驱动推荐的事实缺少支撑,并不等同。
证据来源必须在摘要化和记忆化后仍然保留
长期运行的智能体常常会总结先前的工作或写入持久记忆。如果证据来源在这一转换过程中被剥离,未来的智能体可能检索到一个干净的结论,却不知道它来自用户陈述、实时 API、旧文档、模型推断,还是未经核实的网络结果。
对于重要事实,至少应保留来源身份、检索或观察时间、证据类型、相关版本或状态,以及所存储文本是引用、摘要、推断还是派生。来源信息使后续智能体能够判断该证据应被信任、刷新、限制还是丢弃。
实用的证据记录
| 字段 | 用途 |
|---|---|
| claim_id | 标识被支撑的实质性断言 |
| source_id / source_url / system | 标识证据来自何处 |
| evidence_span | 保留支撑该断言的最小段落、记录或工具结果 |
| retrieved_at / observed_at | 允许进行新鲜度和时间线检查 |
| source_version / object_version | 允许进行取代和可复现性检查 |
| authority_role | 解释为什么该来源适合该断言 |
| applicability | 存储相关日期、司法管辖区、产品版本、用户、租户、状态或其他条件 |
| transformation | 标记证据是原始、引用、摘要、规范化还是派生 |
| trace_step | 显示证据何时对智能体可用 |
| support_status | 直接、部分、矛盾、无支撑或不确定 |
看似有依据但实际上没有的失败模式
| 失败模式 | 为什么它能骗过评估者 | 应测试什么 |
|---|---|---|
| 引用装饰 | 答案包含来源,因此看起来经过研究 | 将每个实质性断言映射到精确的支撑片段 |
| 权威不匹配 | 来源声誉良好,但对具体事实并不权威 | 定义针对具体断言的来源层级 |
| 时间不匹配 | 来源在发布时是正确的 | 检查检索时间、来源日期和取代性证据 |
| 条件剥离 | 摘要保留了结论,却丢弃了例外 | 将生成的断言与完整的本地来源上下文进行比较 |
| 事后引用 | 在答案生成后才附上一个看似合理的来源 | 检查追踪顺序以及证据是否先于断言出现 |
| 参数化覆盖 | 模型忽略检索到的证据,依据先验知识作答 | 运行反事实证据利用测试 |
| 证据洗白 | 模型推断被摘要化,随后被当作来源事实存储 | 在记忆写入过程中保留转换类型和来源信息 |
| 来源多数谬误 | 多个二手页面重复同一无支撑陈述 | 将断言追溯至独立或一手证据 |
如何在生产环境中评估智能体
证据评估流水线
OpenAI 当前的评估指南建议采用任务特定评估、持续评估、源自生产的数据集,以及用于调试智能体行为的追踪。Anthropic 同样建议为研究型智能体组合多种评分器类型,因为正确性、来源质量、覆盖度和有据性是不同的维度。证据评估应遵循同样的模式:多个窄范围评分器比一个不透明的“质量”分数更具诊断价值。
不要让 LLM 评判者成为唯一的证据评判者
LLM 评分器可用于可扩展的断言分类、相关性检查和成对比较,但它们可能与其所评估的系统共享同样的盲点。评分器可能接受一个看似合理但无支撑的断言,漏掉微妙的版本边界,或高估一个经过润色的来源。
OpenAI 的评估指南建议根据人工判断校准自动评分器,并使用清晰、有范围的准则。对于证据密集型系统,应尽可能使用确定性检查:时间戳、对象版本、权限范围、精确来源 ID、检索顺序、文档哈希,以及证据是否在模型生成断言之前就已存在。
什么会改变这个答案?
当智能体在小型、不可变、权威的语料库上运行,且每个答案都严格是抽取式的时候,评估可以更简单。在这种环境中,来源权威性和适用性大多是固定的,断言到片段的支撑可能就足够了。
当智能体混合使用网络搜索、长期记忆、实时工具、多个司法管辖区、快速变化的信息、用户特定状态或自主行动时,评估必须变得更严格。在这些系统中,证据有效性不仅取决于来源文本,还取决于证据是何时以及如何获得的。
未来的模型可能会更擅长在内部追踪来源和不确定性,但在需要可审计性的系统中,这并不能消除对外部证据记录的需求。当轨迹和来源元数据能够提供更强证据时,系统不应依赖模型对自身受何影响的自我报告。
局限性
仅凭轨迹并不总能证明因果性的证据使用。一个来源可能存在于上下文中,却没有影响答案,而模型也可能独立地知道同一事实。反事实测试能增强推断,但测试本身也可能改变任务分布。
来源权威性也可能存在争议,或取决于领域。有些问题没有单一的权威来源,专家也可能对哪些证据应获得更大权重存在分歧。在这些情况下,评估者应保留分歧,并依据明确的评分标准来评估透明度、覆盖范围和推理,而不是假装存在一个不容置疑的真理来源。
结论
“智能体是否引用了来源?”这个问题对于生产级 AI 来说太弱了。更强的问题是:每个重要主张是否都来自真正支持它的证据,该证据是否具有正确的权威性,是否仍适用于当前条件,并且在主张提出之前是否已存在于执行路径中?
这使证据从装饰变成了可评估的系统属性。捕获轨迹。将主张映射到证据。检查权威性和适用性。运行反事实证据测试。在摘要和记忆中保留来源信息。这样,正确答案不仅看似合理——它还拥有一条你可以检查的证据路径。
常见问题
评估 AI 智能体中的证据使用
引用是否能证明 AI 答案有依据?
如何测试 AI 智能体是否实际使用了检索到的证据?
有依据性和来源质量有什么区别?
为什么真实来源仍可能导致错误的 AI 答案?
为了评估证据,我应该记录什么?
术语表
关键证据评估术语
- 主张支持
- 特定证据片段直接确立生成主张的程度。
- 适用性
- 证据对某一主张仍然有效的条件,包括时间、版本、司法管辖区、用户、人群、系统状态或其他边界。
- 证据利用
- 智能体的输出是否实际响应并依赖于其执行路径中可用的证据。
- 反事实证据测试
- 一种评估方法,通过移除、替换或更改决定性证据,来测试智能体的主张是否会相应变化。
- 来源信息
- 记录证据来自何处、何时获取、如何被转换以及它代表哪个版本或状态的元数据。
主要来源与延伸阅读
OpenAI — 评估智能体工作流关于轨迹评分、工作流级评估、数据集以及可重复的智能体评估运行的指导。
OpenAI — 评估最佳实践关于特定任务评估、源自生产的数据集、限定范围的指标、持续评估和评分器校准的指导。
Anthropic — 揭开 AI 智能体评估的神秘面纱智能体评估指导,包括针对研究智能体的有依据性、覆盖范围和来源质量检查。
OpenAI — 可信第三方评估的共享手册强调现代智能体性能取决于工作流和环境,而不仅仅是最终模型输出的评估指导。
Related Articles

Quectel RM500U-EA在ZBT Z8102AX中:5G频段、o2德国及实际信号表现
ZBT Z8102AX 使用移远 RM500U-EA 调制解调器实现 4G 和 5G 连接。在首次实际测试中,该路由器成功连接至德国 o2 网络,使用 LTE Band 3 和 NR n28 频段。调制解调器工作正常,但更深层次的诊断功能如 RSRP、RSRQ、SINR、频段锁定及小区行为仍需进一步测试。

答案有效性边界:相关性到可靠AI答案之间缺失的层级
一个来源可能相关、权威,但对于所提出的问题仍然是错误的。缺失的层次是适用性:答案成立的条件,以及迫使其被重新考虑的变化。本文介绍了“答案有效性边界”这一面向人类、AI搜索和RAG系统的来源设计模式。

规范化架构、URL 设计、解析器逻辑、API 与可扩展性规范
面向多租户门户的地理发现架构。定义了规范化 URL、解析器逻辑、缓存策略以及不依赖 CMS 耦合或数据库重构的地理读模型。该设计旨在确保 SEO 稳定性、高可扩展性,并支持未来的功能扩展,例如预订和地图。

ZBT Z8102AX 硬件与包装评测:强劲路由器,薄弱包装
ZBT Z8102AX 作为一款纤薄黑色金属5G OpenWrt路由器,配备多个天线接口、双SIM卡槽、USB、LAN/WAN端口及实用配件套装,给人留下扎实的第一印象。硬件设计实用且专业,但包装显然是薄弱环节。

MCP vs A2A vs UCP vs AP2 vs A2UI:智能体协议栈详解
MCP、A2A、UCP、AP2 和 A2UI 常被描述为相互竞争的智能体标准。它们大多解决的是不同的互操作性问题。本指南将每个协议映射到其实际标准化的边界,并展示它们如何在同一个生产系统中协同工作。

AI代理应该记住、遗忘、重新计算还是再次检索什么?
长时间运行的代理不应记住所有内容。本文提供了一个实用的生命周期模型,用于决定哪些内容应属于持久记忆、哪些内容应重新检索、哪些内容重新计算更安全,以及哪些内容应过期或被取代。

为什么更多上下文会让AI的回答更糟
更大的上下文窗口并不保证更好的答案。本文解释了信号稀释、证据冲突、状态过时、位置敏感性和有损压缩如何降低AI可靠性——并介绍了一种实用的上下文压力测试。

计算机使用代理:为什么成功的演示仍可能是一个不可靠的系统
计算机使用代理如今能够完成令人印象深刻的浏览器和桌面工作流程,但一次成功的运行证明的是能力——而非可靠性。本文展示了如何测试可重复性、环境鲁棒性、长时程控制、状态感知、结果验证以及安全的目标处理。

你应该购买带有旧固件的5G OpenWrt路由器吗?以ZBT Z8102AX为例
购买搭载旧版固件的5G OpenWrt路由器在特定条件下是合理的。ZBT Z8102AX型号清晰展现了利弊两面:硬件实用、调制解调器工作正常,测试中路由器保持稳定,但OpenWrt 21.02版本、简陋的包装以及不明确的升级路径,要求消费者在购买时需审慎决策。