证据驱动的可验证智能推理：通过工具证明消除 LLM 经验推理中的幻觉

arXiv 发布论文提出 EG-VAR 框架，基于 Lean 4 内核和工具证明公理，确保 LLM 每个经验推理输出都来源于经过验证的工具调用和内核检查的推理链，否则输出 Abstain。在 TableBench 数值推理子集（n=120）上达到 120/120，反事实压力测试保持 100% 源忠实，残余语义形式化错误率在 Sonnet 上为 3.3%、Opus 上为 1.7%。

此前仅靠工具访问无法保证 LLM 推理可溯源和可验证，EG-VAR 通过 Lean 内核实现每个输出必须从工具证据和形式化推理链派生，将未经验证的输出替换为可审计的 Abstain，首次在数值推理和压力测试中达到 100% 源忠实，为高安全场景提供了可落地的技术治理接口。

EG-VAR 让 LLM 在运行时充当形式化翻译器，将自然语言命题转换为 Lean 类型和证明目标；Lean 内核通过工具证明公理（tool-attestation axioms）和源提升声明（source lifts）作为唯一验证者，仅当输出能从工具调用和内核检查的推理链数学推导时才签发 Verified，否则输出 Abstain 并附带可重放审计轨迹。

产品须集成 Lean 形式化侧车（sidecar），增加推理流程的部署复杂度和计算开销；但可杜绝幻觉导致的财务、法律等高风险错误，适用于医疗诊断、金融合规、合同审查等场景的输出审计；残余形式化错误（3.3%/1.7%）意味着仍需人工复核边界案例。

• 在金融报告生成 API 中嵌入 Lean 侧车，使每个数字或陈述附带可审计的证据链
• 开发面向法律合同的 AI 文档工具，遇到无法验证的声明时自动标记 Abstain 并触发人工复核
• 在科研数据分析产品中集成 EG-VAR，确保图表和结论严格来源于原始数据和运算过程
• 将 Lean 形式化模板预置到模型训练/微调流水线，降低部署时的形式化负担

• 该框架在开放域对话或长文本生成中的推理效率和形式化覆盖率如何？
• Lean 侧车能否同时支持多个第三方工具（如搜索、计算器、数据库）的联合证明？
• 残余形式化错误是否可归因于 LLM 翻译能力，还是 Lean 内核本身的限制？
• 工程上如何简化 Lean 形式化侧车的部署，使其能被中小团队快速使用？