链上 AI 结果可信化：别把模型回答直接写进合约
一、链上可信和 AI 输出天然有张力
区块链强调可验证、确定性和不可篡改，大模型强调概率生成、上下文相关和非确定性。把两者放在一起时，第一反应可能是让 AI 直接给结果，再写进合约。但这很危险：模型输出可能不稳定，输入上下文可能被污染，推理过程多数情况下不可链上复现。
因此链上 AI 应用要先把信任边界画清楚。合约不应该盲信模型回答，而应该验证来源、签名、时间、输入摘要和争议处理机制。AI 可以在链下计算，链上负责记录承诺、校验权限和执行确定性逻辑。
更底层的冲突在浮点确定性。大模型推理依赖矩阵乘法和注意力机制，在不同 GPU 架构、推理框架甚至不同 batch size 下，浮点累加顺序可能导致输出向量产生可观测偏差。区块链的确定性执行依赖每一笔交易在同一状态下得出相同结果，而 transformer 的向前传播不是这种确定性——即便 temperature 为零，也不能保证跨部署一致性。这不是 Bug，是硬件浮点计算的物理约束，意味着"链上重放模型推理"在架构上不通。
二、架构链路：链下推理，链上验证
flowchart TD A[用户请求] --> B[链下 AI 推理服务] B --> C[生成结果与证据] C --> D[签名与输入哈希] D --> E[提交到智能合约] E --> F[合约校验签名] F --> G[执行链上状态变更]这里的关键不是“AI 是否聪明”，而是“结果是否可追溯”。链下服务应记录输入、模型版本、Prompt 版本、检索证据和输出摘要。提交链上时，不一定把完整数据都上链，但至少要提交输入哈希、结果哈希、签名和过期时间。
合约只验证确定性信息。例如签名是否来自授权 oracle，结果是否未过期，用户是否有权限，是否已经提交过同一请求。合约不负责判断自然语言回答是否正确。让合约理解 AI 文本，基本是在制造幻觉入口。
三、合约示例：只验证签名和哈希
下面是一个简化思路，展示链上只保存结果承诺。
struct AiResult { bytes32 inputHash; bytes32 outputHash; uint256 expiredAt; address signer; } mapping(bytes32 => AiResult) public results;真实项目中还需要 ECDSA 验签、重放保护和访问控制。重点是不要把合约设计成“接收一段 AI 文本就执行”。链上状态变化必须由可验证字段驱动，文本只适合给前端展示。
如果需要更强可信，可以引入多 oracle、挑战期或零知识证明。但成本和复杂度会明显上升。多数产品早期可以先做签名 oracle 和审计日志，不要第一版就把所有前沿技术堆满。
四、风险处理：争议和回滚要提前设计
AI 输出可能错，链上交易又不可轻易回滚。涉及资产、授权和积分结算时，必须设置人工复核、挑战窗口或延迟生效。越接近资金，越不能让模型直接触发不可逆动作。
前端也要透明展示。用户需要知道这个结果来自哪个 AI 服务、何时生成、是否可申诉、链上记录是什么。Web3 产品如果只强调“去中心化 AI”，却不告诉用户信任路径，就只是换了个包装。
最后，链下服务本身也要高可用。oracle 掉线会影响业务，签名私钥泄漏会造成严重风险。密钥管理、限流、监控和轮换机制都要设计。链上可信不代表链下可以随便写。
还要设计结果撤销或标记机制。链上数据不可轻易删除，但可以追加一条状态，标记某次 AI 结果已被挑战、已失效或已被新结果替代。这样既保持链上历史透明，也给错误结果留出处理空间。可信系统不是永不出错，而是出错后能被发现、被标记、被纠正。
产品层也要避免过度承诺。如果推理结果只是辅助判断，页面就应该写成“AI 建议”而不是“链上真相”。Web3 用户对信任很敏感，措辞和架构一样重要。
五、总结
链上 AI 结果可信化的核心是边界：AI 在链下生成，合约在链上验证确定性承诺。输入哈希、输出哈希、签名、过期时间和争议机制，比把模型回答直接写进合约更可靠。可信不是一句口号，而是一条可追溯路径。
