可验证 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 结果验证。