Leanstral 1.5：当 AI 学会了证明而不仅是猜测——Mistral 的数学定理证明模型

来源: Mistral AI
模型: Leanstral 1.5
定位: Lean 4 形式化证明与自动定理证明
架构: 119B MoE (6.5B active)，128 experts，256K 上下文
许可证: Apache 2.0
发布: 2026年6月30日

一、一个数学家的噩梦："看起来对"和"真的对"之间隔着一条河

想象你正在解一道微积分题。你写了几行推导，觉得"看起来没问题"，然后交了卷。

你的老师阅卷时：

• 如果她是人类，她会看一遍你的推导，觉得"逻辑通顺"，给你满分
• 但如果这道题错了，她没有发现——因为"看起来通顺"不等于"每一步都严格正确"

这就是传统数学和计算机科学长期面临的问题：

"看起来正确"的代码，运行起来可能崩溃。
"看起来通顺"的证明，可能有一个隐藏的漏洞。

Lean 4 是一个"证明助手"（Proof Assistant）。它像一个极度严格的数学老师：你写的每一步推导，它都会机械地检查——不是"觉得你对"，而是用逻辑规则验证你的每一步。

但 Lean 4 有一个问题：它只会检查，不会写。你需要自己写出完整的证明，它才能验证。

Leanstral 1.5 就是来解决这个问题的：一个 AI 模型，它不仅能"猜测"答案，还能在 Lean 4 的严格框架下"写出可被机械验证的证明"。

二、为什么"可被验证的证明"比"聪明的答案"更重要？

先理解传统 LLM 和 Lean 4 的根本区别：

关键洞察：传统 LLM 的弱点——幻觉（hallucination）——在 Lean 4 的框架下被彻底消除。如果 Lean 编译器说"这个证明步骤不对"，那就是不对，没有商量余地。

Leanstral 1.5 的聪明之处在于：它利用 LLM 的生成能力，但把它约束在 Lean 4 的验证框架内。它生成的每一个证明步骤，都必须通过 Lean 的机械检查。

三、架构：119B 参数，但只"激活"6.5B——MoE 的精妙

Leanstral 1.5 的架构是 Mixture of Experts（MoE，混合专家模型）：

• 总参数: 119B
• 活跃参数/每 token: 6.5B
• 专家数: 128 个
• 每 token 激活专家数: 4 个
• 上下文窗口: 256K tokens
• 输入: 多模态（文本 + 图像）
• 输出: 文本

为什么用 MoE？

传统密集模型（Dense Model）每次前向传播都要用所有参数。119B 的密集模型需要巨大的 GPU 集群才能运行。

MoE 的直觉是：不同的任务需要不同的"专家"。证明一个几何定理，需要的数学知识和证明一个代数定理需要的知识不同。MoE 的"路由器"（Router）会为每个输入 token 选择最合适的 4 个专家，只激活这些专家的参数。

结果：119B 的"知识容量"，但运行时只计算 6.5B 的参数——效率和能力的平衡。

256K 的上下文窗口也极其重要。一个复杂的数学证明可能有数万 tokens 长。256K 意味着 Leanstral 可以"记住"整个证明的前因后果，在长推理链中不丢失上下文。

四、训练：三阶段"教 AI 学会证明"

Leanstral 1.5 的训练分为三个阶段：

阶段 1：Mid-training（中期训练）

在基础预训练模型之上，继续用数学和代码数据训练。让模型熟悉 Lean 4 的语法、数学概念、证明模式。

阶段 2：Supervised Fine-Tuning（监督微调）

用"专家演示"训练——人类数学家写的 Lean 4 证明。模型学习"什么样的证明步骤是合理的"。

阶段 3：Reinforcement Learning with CISPO（强化学习）

这是最关键的阶段。CISPO（可能是某种 RL 变体）让模型通过"试错"学习：

训练环境 1：Multiturn（多轮证明）

1. 模型收到一个定理陈述
2. 它尝试写证明
3. 提交给 Lean 编译器
4. 编译器返回：成功 / 错误（在哪一行，什么错误）
5. 模型根据反馈修改，再试
6. 重复直到成功或耗尽预算

这和人类学数学一样：你写证明，老师批改，你改错，再提交。

训练环境 2：Code Agent（代码代理）

模型在一个真实的文件系统里工作：

• 编辑文件
• 运行 bash 命令
• 使用 Lean 语言服务器（LSP）获取实时错误信息和类型信息
• 可以创建辅助引理（helper lemmas），构建模块化的证明

这个环境让 Leanstral 可以处理长证明——如果证明太长，上下文装不下，模型可以：

• 把部分证明写成文件保存
• 通过"compaction"（压缩）压缩前面的上下文
• 继续后面的推理

五、性能数字：从"玩具"到"实用"

数学定理证明

测试时间扩展："想得更久，答得更好"

Leanstral 有一个惊人的特性：给更多 token 预算，它能解决更多问题。

这和人类做难题一样：给你 5 分钟，你可能只能做简单题；给你 2 小时，你可以慢慢尝试不同方法、检查错误、换思路。

成本：约 \(4/题（4M tokens）。对比其他专业证明器： - Seed-Prover 1.5 (high): ~\)300/题

• Aleph Prover: ~\(54-68/题 Leanstral 1.5 的成本约为竞品的 **1/15 到 1/75**。 ### 代码验证：发现真实 Bug Leanstral 1.5 不只是解数学题，它还能验证真实代码。 **案例 1：AVL 树时间复杂度证明** 一个真实的 AVL 树实现（自平衡二叉搜索树）。Leanstral 证明它的插入/删除操作时间复杂度是 O(log n)。 - 使用了结构归纳法和 TimeM 单子的时间追踪 - 消耗 2.7M tokens，22 次上下文压缩 - 建立了每单位高度约 48 步的精确上界 **案例 2：自动发现开源代码 Bug** 流程： 1. 用 Aeneas 工具将 Rust 代码翻译成 Lean 4 2. Leanstral 推断用户意图，生成正确性属性 3. 对每个属性尝试证明（4 次），再尝试证伪（4 次） 结果：在 57 个开源仓库中： - 标记 47 个违反的属性 - 发现 **11 个真实 bug** - **5 个是之前未在 GitHub 上报告过的** 一个具体 bug：在 `datrs/varinteger` 的 zigzag 解码符号函数中，当输入是 `Std.U64.MAX`（U64 最大值）时，表达式 `(value + 1)` 会溢出。这在 debug 模式下导致崩溃，在 release 模式下导致静默数据损坏。 --- ## 六、费曼视角：Leanstral 1.5 的本质是什么？ ### Q1：这和让 GPT-4 写 Python 有什么区别？ GPT-4 写 Python 是这样的： - 你问它"写一个排序函数" - 它生成代码 - 你可能运行一下，看看是否工作 - 但**它不能保证代码在所有边界条件下都正确** Leanstral 1.5 写 Lean 4 证明是这样的： - 你问它"证明这个排序函数总是返回有序数组" - 它生成证明 - Lean 编译器**机械验证每一步** - 如果通过，就是**数学上保证正确**，不是"看起来对" **类比**：GPT-4 像一个作家，写文章给你看；Leanstral 像一个律师，写的每一份文件都要经过法庭的严格审查。 ### Q2：为什么测试时间扩展（Test-time Scaling）这么重要？ 传统机器学习：模型训练好后，推理时固定计算量。好模型 = 训练得好。 Leanstral 的范式：推理时可以"花更多时间思考"。给 50K tokens 解决 44 题，给 4M tokens 解决 587 题。好模型 = 能**有效利用更多计算时间**。 这和人类智能更接近：解难题不是"看一眼就出答案"，而是**尝试、失败、反思、再尝试**。 ### Q3：MoE 架构对证明任务为什么特别合适？ 数学证明涉及多个"领域"： - 代数操作 - 几何直觉 - 逻辑推理 - 集合论 - 数论 每个领域可能需要一个"专家"。MoE 的路由器可以自动把"代数 token"送给代数专家，"几何 token"送给几何专家。 这比一个"万能模型"更高效——就像医院里，你不会让心脏科医生看眼科病，而是让专家各司其职。 ### Q4：从数学到代码——这个跨越的意义 Leanstral 最初是为数学定理证明训练的。但 Mistral 发现它也能验证代码——因为**代码正确性本质上也是数学问题**（类型系统、不变量、边界条件）。 这个跨越的启示：**形式化验证（Formal Verification）正在从学术走向工程**。 过去，只有航空航天、密码学等"人命关天"的领域才用形式化验证，因为太昂贵、太慢。Leanstral 1.5 把成本降到\)4/证明，这意味着：
• 普通软件团队可以考虑给关键模块写形式化证明
• 开源项目可以自动验证 PR 的正确性
• 智能合约（区块链）可以自动验证无漏洞

七、使用方式：从免费 playground 到本地部署

方式 1：Mistral Labs（免费）

# 安装 Mistral Vibe CLI
uv tool install mistral-vibe
vibe --setup

# 在 vibe 中安装 Lean 代理
/leanstall
exit

# 启动 Lean 代理
vibe --agent lean

在 console.mistral.ai 的 playground 中，选择模型 labs-leanstral-1-5，免费使用。

方式 2：Hugging Face（开源权重）

# 安装 vLLM
uv pip install -U vllm --torch-backend=auto

# 启动服务（需要 4 卡并行）
vllm serve mistralai/Leanstral-1.5-119B-A6B \
  --max-model-len 200000 \
  --tensor-parallel-size 4 \
  --attention-backend FLASH_ATTN_MLA \
  --tool-call-parser mistral \
  --enable-auto-tool-choice \
  --reasoning-parser mistral

方式 3：API 调用

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.mistral.ai/v1")

response = client.chat.completions.create(
    model="labs-leanstral-1-5",
    messages=[{"role": "user", "content": "Prove that the sum of two even numbers is even."}],
    temperature=1.0,
    max_tokens=32000,
    reasoning_effort="high"  # "high" for complex proofs, "none" for speed
)

八、局限与未来

局限

1. Lean 4 专用：不能用于 Coq、Isabelle 等其他证明助手。不同证明助手的语法和库不同，模型不能通用。

2. 需要翻译层：要验证 Rust/Python 代码，需要先用 Aeneas 等工具翻译成 Lean 4。这个翻译过程本身可能引入错误。

3. 成本 still 存在：虽然 $4/题比竞品便宜，但大规模验证（比如验证整个 Linux 内核）仍然需要巨额预算。

4. 仅保证形式正确：Lean 验证的是"代码符合规范"，但规范本身可能写错了。"Garbage in, garbage out"——如果形式化规范有漏洞，验证通过的代码仍然有问题。

未来方向

• 多证明助手支持：从 Lean 4 扩展到 Coq、Isabelle、TLA+ 等
• 自动规范推断：目前需要人类写"要验证什么"，未来可能 AI 自动推断代码的"应该满足的性质"
• 与 CI/CD 集成：每次代码提交时自动运行形式化验证，成为软件开发的标配
• 教育领域：帮助学生学数学——不仅给答案，还给完整、可验证的证明过程

九、一句话总结

Leanstral 1.5 的核心洞见：传统 LLM 在"猜测正确答案"，Leanstral 在"生成可被机械验证的证明"。119B MoE 架构（6.5B active）让高效运行成为可能，256K 上下文支撑长证明，三阶段训练（mid-training → SFT → CISPO RL）教它学会"试错式证明"，测试时间扩展让它"想得更久答得更好"。它在 miniF2F 上达到 100% 饱和，PutnamBench 上 587/672，成本仅为竞品 1/15。从数学到代码验证，它发现了 5 个未报告的开源 bug。形式化验证正从学术象牙塔走向工程实用化——而 Leanstral 1.5 可能是这个拐点上的关键催化剂。

参考

• Mistral AI Announcement (2026-06-30). https://mistral.ai/news/leanstral-1.5
• Hugging Face Model Card: https://huggingface.co/mistralai/Leanstral-1.5-119B-A6B
• MarkTechPost Review (2026-07-03). https://www.marktechpost.com/2026/07/03/mistral-ai-releases-leanstral-1-5
• Kompozy Review (2026-05-21). https://kompozy.io/reviews/leanstral-1-5

#MistralAI #Leanstral #形式化验证 #自动定理证明 #Lean4 #MoE #AI数学 #代码验证 #费曼解读