可验证 AI（Verifiable AI）

约 1975 字大约 7 分钟

2026-05-12

Verifiable AI 关注的是：当 AI 输出会影响资产、权限、声誉或治理时，我们能否验证它的输入、模型、执行环境、推理过程或至少留下可审计证据。

为什么要学这个

普通 AI 产品里，模型说错了可以重新生成。但在链上场景里，AI 输出可能触发付款、清算、授权、仲裁或治理动作。错误输出会进入可执行系统。

可验证 AI 不是要求每个模型 token 都上链证明。更现实的目标是按风险分层：低风险场景留日志，高风险场景需要 TEE、ZK、attestation、审计轨迹、challenge 或多方验证。

Verifiable AI 的核心，是让“相信模型”变成“验证证据和约束”。

第一性原理

验证成本必须和输出影响力匹配。

给用户总结新闻，不一定需要 ZK proof；释放 escrow 或罚没 stake，就不能只靠一句模型输出。系统要根据风险选择验证强度。

先验证来源：输入、模型版本、服务方、执行时间。
再验证过程：是否在可信环境中执行，是否可重放或可证明。
最后验证结果影响：输出能改变什么链上状态，是否需要挑战期。

知识节点

TEE

难度：中级。 TEE 用可信执行环境隔离代码和数据，并通过 attestation 证明某段程序在特定环境中运行。

TEE 适合需要隐私和较低证明成本的场景，例如私有数据评分、模型推理、agent runtime 证明。它的限制是仍然依赖硬件和供应链信任。

TEE 的强项是工程上相对可用：可以跑复杂程序，可以处理私有输入，证明成本低于 ZK。它适合“我不能公开输入或模型细节，但需要证明这段程序在某个受保护环境里运行过”的场景。

弱点也要直说：TEE 不是纯密码学信任。硬件漏洞、远程证明服务、供应链和运行时配置都会成为信任假设。因此文档里要写清楚信任谁、证明什么、不证明什么。

ZK

难度：高级。 ZK 允许证明某个计算满足条件，而不泄露全部输入或重新执行完整计算。

ZK 的优势是密码学验证强，但生成证明可能成本高、工程复杂。对 AI 来说，不是所有模型都适合直接做 ZK proof。

ZK 更适合证明边界清楚、计算规模可控的任务。例如证明某个小模型对输入做了分类，证明某个后处理规则正确执行，证明某个数据聚合满足约束。

对 LLM 来说，完整证明每一步 token 推理通常还不现实。很多产品会选择证明关键部分，而不是证明整个模型大脑。

zkML

难度：高级。 zkML 是把机器学习推理转成可证明计算的方向。

它适合模型较小、结构固定、输出需要强验证的场景。大型 LLM 的完整 zk proof 仍然非常昂贵，所以实际系统常用混合方案：只证明关键步骤，或证明较小模型和后处理逻辑。

zkML 设计时要先问：是否真的需要隐藏输入，是否真的需要链上验证，是否能接受证明延迟，模型是否能转成电路。很多“需要可信 AI”的场景，其实用签名日志、TEE 或人工复核更经济。

适合 zkML 的例子包括：小型风控模型、资格判断、图像/文本分类的关键阈值判断、隐私数据上的简单推断。

Proof of Inference

难度：高级。 Proof of Inference 试图证明某个输出确实来自某个模型、输入和执行环境。

实现路线可能是 TEE attestation、ZK proof、签名执行日志、可重放推理或服务方证明。选哪种取决于成本、隐私、延迟和可信假设。

Proof of Inference 不一定要追求“最强证明”。如果只是证明某个服务返回过这个结果，签名日志可能够用；如果要证明结果来自特定二进制和模型，TEE 更合适；如果要最小化信任第三方，ZK 更强但更贵。

产品文档应该明确证明对象：证明输入没变、证明模型版本、证明运行环境、证明输出未篡改，还是证明完整计算正确。这几个目标不是同一件事。

Verifiable Compute

难度：中级。 Verifiable Compute 关注的是让链下计算结果能被链上或第三方验证。

AI 推理只是其中一种计算。更广泛的场景包括风控评分、数据聚合、任务评估、证明生成和批量结算。链下执行、链上验证，是很多 AI x Web3 系统的现实路径。

Verifiable Compute 适合把昂贵计算放在链下，把摘要、证明或签名结果放到链上。这样既保留链上可验证性，又避免把复杂推理直接塞进合约。

但要注意数据可用性。链上只有一个 hash 或 proof 时，用户仍然需要知道原始输入和输出在哪里、谁能访问、多久保存。

Benchmark

难度：中级。 Benchmark 用来比较模型或 Agent 的能力，但不能替代任务级验证。

公开 benchmark 能说明一般能力，不能证明某次输出正确。Agent 系统需要自己的任务集：交易解释、风险识别、拒绝越权、引用链上证据、处理失败工具调用。

Benchmark 还容易被优化过度。模型可能在通用榜单很好，但在你的链上任务里经常读错 decimals、忽略 chain id、误判授权风险。项目应该建立自己的 benchmark。

一个 AI x Web3 benchmark 应该包含正常样本、边界样本和攻击样本：错误链、恶意上下文、过期价格、同名 token、revert 交易、假合约文档。

Audit Trail

难度：初级。 Audit Trail 是最基础、最实用的可验证层。

它记录输入、输出、模型版本、工具调用、时间、用户确认、交易哈希和错误。即使没有 TEE 或 ZK，完整审计轨迹也能支持复盘、争议和改进。

Audit Trail 是最容易落地的可验证 AI 起点。它不能证明模型绝对正确，但能证明系统当时看到了什么、调用了什么、用户确认了什么。

日志要避免泄漏隐私和 secret。做法通常是：敏感原文加密保存，公开层只放 hash、摘要和权限可控的引用。

在 AI x Web3 中的位置

Verifiable AI 是 AI Oracle、Agent Trust、Settlement 和 Governance AI 的基础。它不一定总是链上证明，但必须让关键输出有可追溯证据。

一个成熟系统通常会混合使用：日志用于日常复盘，attestation 用于服务证明，ZK/TEE 用于高风险场景，challenge 用于处理争议。

最小实践

为一个 AI 风险评分设计验证方案：

定义输入数据来源和更新时间。
记录模型版本、prompt 模板和输出 schema。
设定低风险输出只记录 audit trail。
设定高风险输出需要人工复核或 challenge window。
写出未来如何升级到 TEE 或 ZK 证明。

扩展阅读

Oasis ROFL Documentation：了解 TEE 方向的可验证链下执行。
RISC Zero：了解 zkVM 方向的通用可验证计算。
EZKL：了解 zkML 推理证明工具。
Ethereum Oracles：理解外部结果进入链上的基础问题。
ERC-8004：查看 validation registry 如何支持 Agent 结果验证。