Tool Receipts, Not Zero-Knowledge Proofs: Practical Hallucination Detection for AI Agents

本文提出了名为 NabaOS 的轻量级验证框架，该框架借鉴印度认识论（Nyaya Shastra）对 LLM 主张进行来源分类，并通过 HMAC 签名的工具执行收据在实时交互中高效检测幻觉，从而在极低延迟下实现了比零知识证明更实用的成本 - 延迟 - 覆盖权衡。

要点

这篇论文介绍了一个名为 NabaOS 的新系统，它的核心目的是解决一个让 AI 助手非常头疼的问题：“一本正经地胡说八道”（幻觉）。

想象一下，你让 AI 帮你查邮件、看股票或者找新闻。AI 可能会自信满满地告诉你：“爱丽丝给你发了 3 封邮件，主题是‘截止日期’。”
但真相可能是：AI 根本没查邮件，或者查了但只找到 1 封，甚至它把邮件主题编造成了“截止日期”。

传统的解决方法（比如零知识证明）就像是为了验证这句话，要求 AI 先花几分钟在超级计算机上跑一个复杂的数学证明。这太慢了，就像为了确认“今天天气不错”，让你先花半小时去气象局跑个实验，根本没法用在日常对话中。

NabaOS 的解决方案：给 AI 发“小票”（Receipts）

作者从古老的印度哲学（正理派 Nyāya）中汲取灵感，提出了一种更聪明、更轻量的方法。我们可以把它想象成**“给 AI 的每一次操作都打印一张带防伪码的小票”**。

1. 核心比喻：餐厅的小票 vs. 厨师的口头承诺

• 以前的 AI（口头承诺）： 厨师（AI）端上一盘菜，说：“这是刚炒的，有 5 个虾仁。”你只能选择相信他，或者怀疑他。如果他说谎，你很难当场揭穿。
• NabaOS 系统（带小票）：
  1. 当你问 AI 问题时，AI 会去“厨房”（调用工具，比如查邮件 API）干活。
  2. 厨房干活时，会自动生成一张加密的“小票”（Tool Receipt）。这张小票记录了：“在 10:00 查了邮件，找到了 3 封，内容是……" 并且盖上了一个只有厨房有、AI 拿不到的防伪印章（HMAC 签名）。
  3. AI 把菜端给你时，必须同时出示这张小票。
  4. 系统会瞬间核对：AI 说的"5 个虾仁”和小票上的"3 封邮件”对得上吗？AI 提到的“小票编号”真的存在吗？

如果 AI 想撒谎（比如编造没查过的邮件），它拿不出那张带防伪章的小票，或者小票上的数字对不上，系统会立刻报警：“嘿，你在撒谎！”而且这个过程只需要15 毫秒，比你眨眼还快。

2. 聪明的分类法：不是非黑即白，而是“信任分级”

传统的验证系统通常只给两个结果：“是真的”或“是假的”。但这很笨，因为 AI 有时候是在推理，而不是在陈述事实。

NabaOS 像一位聪明的老学究，把 AI 说的话分成五类（基于印度哲学的知识来源分类）：

1. 亲眼所见 (Pratyaks.a)： AI 直接引用了小票上的数据。
   • 例子： “爱丽丝发了 3 封邮件。”（系统核对小票，确认无误 -> 完全可信）
2. 合理推测 (Anumāna)： AI 根据数据猜出来的。
   • 例子： “爱丽丝看起来很焦虑。”（系统知道小票里只有邮件内容，没有“焦虑”这个词，所以标记为：这是 AI 的推测，仅供参考）
3. 听人说的 (Śabda)： AI 引用了外部新闻。
   • 例子： “据路透社报道……"（系统会去检查是否真的抓取了路透社的页面 -> 可信度取决于来源）
4. 没找到 (Abhāva)： AI 说“没找到结果”。
   • 例子： “没找到爱丽丝的邮件。”（系统核对小票，确认确实返回了空列表 -> 可信）
5. 瞎编的 (Ungrounded)： AI 没有任何依据，纯粹瞎说。
   • 例子： “爱丽丝可能去了火星。”（系统没找到任何相关小票 -> 不可信，请忽略）

这种分类的好处是： 它不会把 AI 的“合理推测”当成谎言直接杀掉，而是告诉用户：“这是推测，你要自己判断。”这比简单的“通过/不通过”要人性化得多。

3. 为什么它比“零知识证明”好？

• 零知识证明 (ZK)： 就像为了验证一道数学题，要求 AI 在黑板上写满几页复杂的公式，证明它算对了。虽然数学上无懈可击，但太慢了，而且就算算对了，如果题目本身是错的（比如 AI 算错了 2+2=5 但过程完美），它还是错的。
• NabaOS (小票法)： 不关心 AI 怎么算的，只关心它有没有真的去查。它直接看“小票”上的结果。
  • 速度： 快如闪电（<15 毫秒）。
  • 硬件： 普通手机或电脑就能跑，不需要昂贵的超级显卡。
  • 针对性： 专门抓“胡说八道”，而不是抓“计算过程”。

4. 实验结果：真的管用吗？

作者做了一个叫 NyayaVerifyBench 的考试，里面有 1800 个场景，故意让 AI 犯各种错误（比如编造工具调用、数错数量、瞎编新闻来源）。

• 结果： NabaOS 抓出了 91% 的谎言。
• 对比： 其他方法要么太慢（比如让 AI 自己检查自己，慢 3-5 秒），要么准确率只有 50% 左右。
• 多语言： 无论用英语、中文、印地语还是西班牙语，效果都很稳定。因为“小票”是数字和代码，跟语言没关系。

总结

NabaOS 就像是给 AI 助手配了一个“随身审计员”。

它不要求 AI 变得完美无缺，而是通过**“小票验证”和“知识分类”**，让用户清楚地知道：

• 哪些话是 AI 亲眼看到的（可信）；
• 哪些话是 AI 猜的（仅供参考）；
• 哪些话是 AI 瞎编的（千万别信）。

这让 AI 变得透明且实用，不再是一个只会一本正经胡说八道的黑盒子，而是一个我们可以放心托付日常任务的智能伙伴。

技术摘要

论文技术总结：工具收据而非零知识证明：AI 代理幻觉检测的实用方案

1. 研究背景与问题定义 (Problem)

随着大型语言模型（LLM）代理（Agents）从对话助手演变为能够自主执行邮件、财务、代码部署等任务的系统，**幻觉（Hallucination）**问题变得尤为严峻。代理可能会编造工具调用结果、错误报告输出数量，或将推断内容伪装为已验证的事实。

当前解决可验证 AI 推理的主流方案是零知识证明（Zero-Knowledge Proofs, ZK）。然而，ZK 方案在交互式个人代理场景中存在三大根本性缺陷：

1. 延迟过高：证明生成需要数分钟，无法满足秒级响应的交互需求。
2. 硬件门槛：需要专用 GPU 基础设施，不适合边缘设备或个人使用。
3. 语义不匹配：ZK 仅能证明“计算过程正确执行”，无法证明“输出内容符合事实”。LLM 可以完美地执行计算并生成一个自信但完全错误的（幻觉）答案，ZK 无法检测此类语义错误。

核心问题：如何在极低延迟下，区分代理的声称是源于真实的工具执行证据，还是模型编造的幻觉？

2. 方法论：NabaOS 验证框架 (Methodology)

作者提出了 NabaOS，一个受印度哲学**正理派（Nyāya Śāstra）认识论启发的轻量级验证框架。其核心思想是将 LLM 响应中的每一个事实性主张根据其认识论来源（Pramāṇa）进行分类，并通过工具执行收据（Tool Execution Receipts）**进行实时交叉验证。

2.1 认识论分类体系 (Pramāṇa Classification)

框架将代理的声称映射为六种认识论类别，并据此决定验证策略：

• Pratyakṣa (直接感知)：直接引用工具输出（如"Alice 发了 3 封邮件”）。验证方法：核对收据中的计数和事实字段。
• Anumāna (推断)：基于工具数据的推断（如"Alice 似乎很担心”）。验证方法：检查前提是否存在于收据中。
• Śabda (外部证言)：引用外部来源（如“据路透社报道”）。验证方法：确认是否实际调用了获取该来源的工具。
• Abhāva (缺席)：声称未找到结果（如“未找到匹配邮件”）。验证方法：确认工具返回了空结果集。
• Upamāna (类比)：比较或类比。
• 无根基 (Ungrounded)：无证据支持的观点。

2.2 工具执行收据 (Tool Execution Receipts)

这是 NabaOS 的底层机制。代理运行时（Runtime）而非 LLM 本身执行工具调用，并生成HMAC 签名的收据。

• 结构：包含工具名称、输入/输出哈希、结果计数、提取的关键事实、时间戳及 HMAC 签名。
• 特性：
  • 不可伪造：LLM 无法访问签名密钥，无法伪造不存在的工具调用。
  • 防篡改：任何对收据字段的修改都会导致签名验证失败。
  • 完整性：每次工具调用生成唯一收据，可检测遗漏或虚构的调用。

2.3 验证协议流程

1. 执行与收据生成：运行时执行工具，生成签名收据。
2. LLM 自标记：LLM 在生成回复时，被提示将每个事实性主张标记为上述认识论类别，并引用对应的收据 ID。
3. 实时交叉验证：验证引擎检查每个标记：
   • 检查收据 ID 是否存在。
   • 验证 HMAC 签名。
   • 比对声称的计数/事实与收据中的 facts 字段。
   • 对于推断类（Anumāna），检查前提是否真实存在。
4. 输出信任标签：最终输出带有信任级别（如“完全验证”、“大部分验证”、“不可靠”）的增强回复。

2.4 深度代理交叉检查 (Deep Agent Cross-Checking)

针对自主代理（无法控制内部工具调用的场景），采用独立策略：

• URL 重新获取：独立抓取代理引用的 URL 以验证内容。
• 计算重放：独立重新执行算术或代码逻辑。
• 时间一致性检查：验证时间逻辑是否合理。

3. 主要贡献 (Key Contributions)

1. Pramāṇa 分类法：首次将正理派认识论框架应用于 LLM 代理输出的验证，将验证从二元的“真/假”转变为多维的信任信号。
2. HMAC 签名收据机制：提供了一种轻量级、不可伪造的工具调用证明机制，实现了确定性的幻觉检测。
3. 验证协议与交叉检查：设计了包含自标记和独立重验证的完整协议，覆盖从简单工具调用到复杂自主任务。
4. NyayaVerifyBench 基准测试：构建了包含 1,800 个场景（4 种语言，6 种幻觉类型）的基准测试集，专门用于评估代理幻觉检测。
5. 实证结果：证明了基于认识论分类的信任指标具有良好的校准性（Calibration），"完全验证"的响应准确率高达 98.7%。

4. 实验结果 (Results)

在 NyayaVerifyBench 上的评估显示，NabaOS 在检测率、误报率和延迟方面均优于现有基线（如自一致性检查、RAG grounding、正则匹配等）。

• 检测率 (Detection Rate)：
  • 整体检测率：91%。
  • 虚构工具调用：94.2%。
  • 数量错误（Count Mismatch）：87.6%。
  • 虚假缺席（False Absence）：91.3%。
  • 推断伪装成事实：82.3%。
• 误报率 (FPR)：在干净的控制场景下仅为 4%，显著低于 RAG 方法（18%）和自一致性方法（12%）。
• 延迟 (Latency)：每个响应的验证开销仅为 <15 ms，远低于 ZK 证明（分钟级）和自一致性（秒级）。
• 多语言表现：在英语、印地语、中文、西班牙语中表现稳定（88.7% - 92.8%），证明了基于结构化收据的验证不受语言差异影响。
• 信任校准：
  • "Fully Verified"（完全验证）：正确率 98.7%。
  • "Unreliable"（不可靠）：正确率仅 23.4%，有效标记了高风险输出。

5. 意义与结论 (Significance)

• 实用性与成本效益：NabaOS 证明了对于交互式个人代理，基于收据的验证比零知识证明更具实用性。它在几乎零延迟和零额外计算成本的情况下，解决了语义层面的幻觉问题。
• 可操作的信任信号：通过区分“直接观察”与“推断”，NabaOS 为用户提供细粒度的信任信号，而非简单的二元判断。这允许用户根据上下文（如医疗诊断 vs. 邮件摘要）自主决定信任程度。
• 架构互补性：该方法与 ZK 证明并不冲突，而是互补的。ZK 可保证计算完整性（模型是否按预期运行），NabaOS 保证语义 grounding（输出是否有据可依）。
• 开源贡献：作者开源了 NyayaVerifyBench 基准测试集及 Rust 实现的验证引擎，推动了可验证 AI 代理的发展。

总结：NabaOS 通过引入轻量级的密码学收据和哲学认识论分类，为 AI 代理提供了一种高效、实时且用户友好的幻觉检测方案，填补了当前可验证 AI 在语义正确性验证方面的空白。