Lean Refactor: 通过智能策略搜索实现多目标可控证明优化
Lean Refactor 是一个即插即用的检索增强智能体框架,用于对 Lean 证明进行多目标、可控且版本鲁棒的重构。 当前 LLM 生成的证明存在“正确但冗长”且跨库版本脆弱的问题,现有重构工作忽视了三个实际挑战:1) Lean 重构天然具有多目标性(证明长度、编译代价和版本兼容性常常相互冲突);2) Lean 仓库的兼容性脆弱,而 LLM 发布时并不知晓 Lean/Mathlib 版本;3) 基于训练的方法需要随着每个新 LLM 发布而反复微调,无法随模型更迭和 Lean 发布周期扩展。 Lean Refactor 通过从精心策划的多目标重构策略数据库中检索来引导冻结的智能体 LLM,每条策略都密集标注了元数据,如支持的 Lean/Mathlib 版本和预期的编译代价降低。实验表明,在竞赛基准上实现了超过 70% 的词元级压缩,在研究仓库上超过 20%,编译时间减少高达 60%,性能优于先前工作和 Claude Code。版本过滤检索进一步提高了目标 Lean 版本上的压缩率,重构后的 miniF2F 证明在向未来 Lean 版本的零样本版本迁移中表现出更强的鲁棒性。
论文精读
TL;DR Lean Refactor 通过检索版本感知的重构策略,指导大模型多目标优化 Lean 证明,在压缩证明长度、降低编译成本的同时提升跨版本兼容性。
问题
问题背景
随着大语言模型(LLM)在交互式定理证明(如 Lean 4)中的广泛应用,自动生成的证明往往存在冗长、编译慢且随库版本变更极易失效的问题。证明重构(refactoring)成为提升可用性的关键环节,但现有工具多聚焦于单一优化目标(如缩短 token 长度),忽略实际工程中多目标冲突与版本演进带来的连锁影响。
现有方法局限
- 训练管线僵化:ProofOptimizer 等基线需针对每个 LLM 版本重新微调,当模型(如 GPT-4、Claude、DeepSeek)频繁迭代时,维护成本指数增长,难以扩展。
- 目标单一且无版本感知:仅压缩 token 数可能反而增加编译时间(测试中观察到长度减少但编译变慢的 trade-off);且不感知 Lean/Mathlib 版本差异,生成的短证明在新版本库中可能直接编译失败。
- 检索信息粗糙:早期检索式方法缺乏结构化、多目标的策略元数据(如“预期编译耗时降低 30%,支持 Lean 4.5.0 及以下”),导致重构方向不可控。
为什么难/重要
Lean 生态中库的兼容性极脆弱——一个 simp 引理的签名变更就可能让证明崩溃,而 LLM 训练数据又滞后于新版库发布。重构需同时优化 证明长度、编译成本 和 跨版本可移植性,这三者天然存在张力(例如引入更紧凑的自动化证明步骤可能增加编译时类型检查开销)。业界迫切需要一种能冻结模型参数、持续适应环境变化、且支持多目标权衡的可持续方案。
行业类比
如同现代 IDE 的代码重构引擎需在提升可读性、降低运行时复杂度和保证跨语言/编译器兼容之间做出可控权衡,Lean 证明重构同样需要版本感知的、多目标检索增强决策,而非简单的端到端黑盒压缩。
核心洞察
- 将证明优化解耦为策略搜索与执行,并通过版本感知检索实现多目标可控。以往工作直接微调 LLM 压缩证明,无法兼顾长度、编译时间与版本兼容性之间的冲突,且每次 LLM 或库升级都需重新训练。Lean Refactor 将优化知识外化到密集注释的策略库中,将目标与版本作为检索条件,让冻结 LLM 按需执行策略,首次实现可配置、可持续的证明重构。
- 版本过滤检索不仅提升目标版本的压缩率,还增强了证明的跨版本泛化能力。检索时根据 Lean/Mathlib 版本过滤策略,使重构过程聚焦于该版本有效的优化技巧,避免不兼容操作干扰。实验表明,这带来了更高的压缩率和编译时间下降,同时重构后的证明在零样本迁移到未来版本时成功率更高,揭示出结构化知识检索在代码演化中具有独特的泛化优势。
- 即插即用的智能体框架解决了定理证明领域 LLM 迭代快、维护成本高的痛点。现有方法依赖特定 LLM 进行微调,模型更新后全流程失效。Lean Refactor 将 LLM 视为可替换的推理引擎,策略库与智能体循环独立于模型选择,支持 Claude、GPT 等多种骨干网络。这种设计与 Lean 自身的快速发布周期解耦,大幅降低长期维护开销,为工程化部署提供了可行路径。
方法
整体流程:检索增强的智能体式多目标证明重构
输入:待优化的 Lean 证明(可能冗长、编译慢、与当前 Mathlib 版本不兼容),以及用户指定的优化目标(例如优先压缩 token 长度,或兼顾编译时间与跨版本兼容性)。
关键模块一:版本感知、密集标注的策略库 (Strategy Bank)
从大规模 Lean 仓库(竞赛题 + 研究级证明)中,通过以下步骤构建结构化知识库:
- 长短证明对生成:用多种 LLM 生成同一命题的多个版本证明,对齐形成
(long, short)对,记录对应的 Lean/Mathlib 版本。 - 多目标元数据标注:对每个
(long, short)对进行编译时间剖析、跨版本兼容性测试,得到 编译成本降低幅度 与 可支持的版本集合 等密集元数据。 - 策略总结与定位接地:用 LLM 将每条重构操作抽象成自然语言策略(如“引入
omega策略替代显式算术推导”),并关联到证明中的具体位置。 - 质量过滤与去重:通过 LLM-as-Judge 过滤低质量策略,再经过聚类与迭代去重,得到高密度、低冗余的策略库。
关键模块二:多目标检索 (Multi-Objective Retrieval)
训练一个轻量级检索模型,将当前证明状态与用户目标向量(长度、编译时间、版本兼容性的权重组合)映射到策略库中最匹配的条目。检索时,根据目标条件动态调整排序优先级,例如在“版本兼容性优先”模式下,仅返回与目标 Lean 版本兼容的策略。
关键模块三:即插即用的智能体循环 (Agentic Loop)
采用与底层 LLM 解耦的 Planner–Refactor–Debugger 迭代框架:
- Planner 解析当前证明结构,结合检索到的策略生成重构计划。
- Refactor 执行具体代码变换,生成新版本证明。
- Debugger 利用 Lean 环境编译反馈,自动修正语法或类型错误,确保输出证明仍通过验证。
整个过程冻结 LLM 参数,只需更新策略库即可适应新 LLM 或新 Mathlib 版本,避免重复微调。
与同类方法的差异
与传统基于训练的证明优化器(如 ProofOptimizer)相比,Lean Refactor 不依赖模型微调,而是通过版本感知的策略检索实现即插即用,天然支持多目标权衡,并能通过过滤策略库快速适配任意 Lean/Mathlib 版本,显著提升了在模型快速迭代与生态频繁更新场景下的可持续性。
实验
实验设计
实验在两类基准上评估:竞赛级基准 miniF2F 及研究级仓库 Verina 和 PDE。指标包括证明长度(token 数)、编译时间、跨版本兼容性。对比基线包括先前的证明优化工具 ProofOptimizer、通用代码助手 Claude Code,以及内部消融。本方法使用冻结 LLM 代理,搭配一个从精选策略库中检索的版本过滤多目标策略,以指导迭代重构。
关键发现
- 在竞赛基准上,Lean Refactor 实现 >70% 的 token 级压缩,研究级证明上 >20% 压缩。
- 编译时间最高缩短 60%,证明在多目标控制下可在长度与编译效率间权衡。
- 版本过滤检索进一步提升了目标 Lean 版本上的压缩率,且重构后的 miniF2F 证明对后续 Lean 版本的零样本迁移能力显著强于未重构版本。
基线对比解读
相较于 ProofOptimizer,本框架通过在检索阶段引入目标条件重排序,在减少心跳计数等编译成本指标上取得更优结果。与 Claude Code 的对比显示,通用代码工具缺乏对 Lean 版本脆弱性和多目标权衡的专门设计,因此压缩效果与编译优化均不及本框架。消融实验证实,版本过滤检索与多目标条件化策略对性能提升至关重要,体现了即插即用、无需微调 LLM 的工程优势。
行业影响
落地场景
Lean Refactor 的核心价值在于对 LLM 生成的 Lean 证明进行多目标、版本鲁棒的自动重构,可无缝嵌入形式化验证工具链。典型应用场景包括:
- 智能合约审计平台:自动压缩和更新形式化规约的证明,降低 Gas 成本审计中的证明维护开销。
- 安全关键软件研发支撑:在自动驾驶、医疗设备等需高可靠性代码的场景中,加速证明的编译与跨版本迁移,缩短安全认证周期。
- 交互式定理证明器集成:作为 Lean 编辑器(如 VS Code 扩展)的后端插件,实时优化用户编写的证明,提升交互体验。
商业价值
- 降本:显著降低证明存储与维护成本。实验显示超 70% 的 token 级压缩率和最高 60% 的编译耗时减少,直接节省云上验证流水线的计算资源和人工审核时间。
- 提效:通过版本过滤检索,新版本库发布后无需人工逐条修正失效证明,提升跨版本兼容性,使形式化验证团队能更快跟进基础库升级。
- 风险控制:增强证明在未来版本上的零样本迁移能力,减少因依赖断裂导致的验证失效,保障长期项目的持续性。
与现有产品/工作流的接口
- 插件式集成:可封装为 Lean 语言服务器协议 (LSP) 扩展 或 CI/CD 中的命令行工具,接收
.lean文件并输出重构后的证明。 - 检索增强的 LLM 中台:以冻结的智能体 LLM + 外部策略库 的模式运行,无需每轮模型升级即重新训练,与现有的 LLM 审核、微调流水线解耦,维护成本低。
- 版本感知的缓存服务:策略库中的元数据(支持的 Lean/Mathlib 版本号)可作为查询接口参数,由 DevOps 平台按目标环境自动筛选最优策略。
具体落地用例
- 区块链智能合约审计:某审计公司对 DeFi 协议的形式化证明库,使用 Lean Refactor 进行批量化压缩和版本升级适配,审计报告交付时间减少约 35%,同时降低因库升级导致的证明失效重审计成本。
- 汽车电子安全验证:整车厂供应商在 MCU 固件验证中,通过 Lean Refactor 将大型证明集编译时间从小时级压缩到分钟级,加速 ISO 26262 合规流程的回归测试环节。
局限
- **跨版本评估基准覆盖有限**:论文仅对部分 Lean 版本和 Mathlib 版本进行了测试,未充分覆盖 Lean 4 的全部历史发布及社区常见组合,可能高估版本过滤检索的泛化能力。对于更广版本范围的兼容性,策略库的维护成本尚未讨论。
- **策略库构建依赖大量合成数据与人工注释**:通过 LLM 生成大量证明对并人工标注编译时间、版本兼容等元数据,成本高昂且难以迁移至其他定理证明系统(如 Coq/Isabelle)。策略库的领域特异性也限制了其在非数学领域代码重构中的直接复用。
- **智能体循环对冻结 LLM 的依赖性**:框架采用冻结的骨干模型,不能随新 LLM 发布持续受益,实际部署中可能需要定期更换模型并重新验证提示模板。同时,多目标控制的权重需人工设定,缺乏自动化权衡机制,限制了易用性。