MathForm-8Bとは何か？ OpenBMBの静かな自動形式化リリースが数学をLean 4に変える

openbmb/MathForm-8B は、OpenBMB による新しい自動形式化モデルで、自然言語の数学的記述を Lean 4 に変換します。そして、それはほとんどアナウンスなしでリリースされました。重み、データセット、論文はすべて、2026-08-14 に Hugging Face と arXiv に同日公開され、タイトルは「MathForm: Scaling Mathematical Autoformalization with Knowledge Retrieval and Verification-Guided Refinement」です。この静かなリリースの背後には異例の結果があります。8Bパラメータのモデルが、構文チェックで平均 Pass@8 スコア 88.06%、より厳格な整合性チェックで 72.37% を 6つのベンチマークで報告しており、論文では、これが複数の専門化された 32B 自動形式化モデルを上回ると主張しています。これは現時点で判明していることをまとめた記事です。以下「from the repo」とラベル付けされたものはすべて、モデルカード、データセットカード、論文から直接来ており、まだ独立に確認されていないものにはその旨が明記されています。

重要なポイント

• MathForm-8Bは、8BパラメータのApache-2.0ライセンス自動形式化モデルです。非形式的な数学の問題を読み取り、名前付きヘッダーを持つLean 4の定理ステートメントを書き出し、後で証明できるようにします。

これは、OpenBMBが知識検索とコンパイラ検証によるリファインメントを用いて構築した約367,000件の検証済みLean 4データセットFormalVerseに基づいてQwen3-8Bをファインチューニングし、その後、Leanコンパイルと意味的一貫性フィードバックを用いた強化学習でトレーニングされたものです。

• 報告された数値（ベンダー報告、未再現）：Syntax Check での平均 Pass@8 は 88.06%、Consistency Check では 72.37% であり、論文自身の表において 7B〜32B の専門特化した自動形式化ツールを上回る。

• 発表されておらず、ローンチ時に主要な有料APIには含まれておらず、独立したベンチマークもまだ行われていない——本番環境での採用に影響する3つのギャップである。

• サービングは自己ホスト型です：Transformers、vLLM、またはSGLangのいずれも、OpenAI互換のエンドポイントを公開します。

リリースに実際に含まれているもの

2026-08-14に、3つのアーティファクトが数分以内に相次いで公開された。これは、調整されつつも事前発表のないリリースがどのようなものかを示している：

モデルリポジトリのopenbmb/MathForm-8B — BF16の8B因果言語モデルで、チャットテンプレートを備え、4つのsafetensorsシャードで構成され、Apache 2.0ライセンスで提供されています。

• データセットリポジトリ、openbmb/FormalVerse — 約367,000件の検証済み例を含むLean 4自動形式化データセットで、これもApache 2.0です。

• 論文arXiv 2608.14221 — データ構築パイプライン、トレーニング手順、および6つのベンチマークによる評価を説明する25ページ。

README 内の GitHub コードリンクは、執筆時点ではまだプレースホルダーであり、評価パイプラインと Pass@k スクリプトは公開予定とされているが、まだ一般公開されていない。README には、コンパイルチェックには実行中の Kimina Lean Server が必要であり、実験では Lean 4.21.0 を使用すると記載されている。

上記のリポジトリページが、現時点でのリリースの公開情報のすべてです。モデルカード、safetensorsのシャード4つ、チャットテンプレート、そして唯一のドキュメントを兼ねたREADMEがあります。執筆時点では、発表用のブログ記事は存在しません。

MathForm-8Bが行うこと — そして、それが狭いタスクである理由

自動形式化は定理証明の前段階です。平易な英語で与えられた数学の問題（「任意の実数 x に対して、x² が非負であることを示せ」）に対して、モデルは Lean 4 で形式的に正しい文（imports、型、定理ヘッダ）を生成し、それを人間または証明器がその後取り組めるようにしなければなりません。これは、数学を解くこととはまったく異なるスキルです。モデルは自然言語の概念を Mathlib の正確な定義と型の階層に対応付けなければならないからです。型チェックを通過するものの、元の主張を暗黙のうちに弱めている文（完全な整除性の主張の代わりに「(2^5) ∣ (13^4 − 11^4)」）は典型的な失敗モードであり、これこそが、論文が構文チェック（コンパイルできるかどうか）と整合性チェック（意味的に同じ文かどうか）を区別する理由です。

モデルカードは意図された使用パターンを示しています。つまり、非公式な問題と希望する定理名をプロンプトとして与えると、次のような Lean 4 のステートメントを返します：code>theorem my_favorite_theorem : ... := by sorry/code> — その code>sorry/code> は証明義務を未解決のままにします。この役割分担は重要です。MathForm-8B は形式化ツールであり、証明器ではありません。Lean ツールを構築するチームは、これを使って問題バンクを機械検証可能な形式に変換しています。

どのように訓練されたか

この論文のレシピは2段階からなる。まず、OpenBMBは、(1) 生成前にMathlibから関連する定義と既存の形式化を取得し、(2) 候補となるステートメントを生成し、(3) Leanコンパイラの診断と意味的一貫性のフィードバックを用いてそれらを改良し、(4) 両方のチェックを通過したサンプルのみを保持する、というパイプラインでFormalVerseを構築した。その検証済みコーパスは教師ありファインチューニングに使用され、続いてLeanコンパイルと意味的一貫性からの報酬信号を用いた強化学習が行われる。

データセットカードは、データの具体的な雰囲気を伝えています。各エントリは非形式的な記述と検証済みの形式的な記述をペアにしており、ソース（例：AceReason-Math）とトピックラベル（数論など）でタグ付けされています。すべての例は、トレーニングに組み込まれる前に実際のコンパイラチェックを通過しているため、モデルはモデルの生の出力ではなく、正しいことが確認された記述から学習します。

正直に表示されたベンチマーク表

このセクションのすべての数値は論文(arXiv 2608.14221)からのベンダー報告によるものであり、独立に再現されたものではありません。Pass@8は、モデルが問題ごとに8回試行でき、そのうちの1回でも成功すればカウントされることを意味します。これはpass@1よりも寛大な指標であり、「予算が与えられたとき、モデルが正しいステートメントを生成できる頻度」と解釈すべきです。

• MathForm-8B 平均 — 構文チェック 88.06%、整合性チェック 72.37%。

• ベンチマークごとに、SC 次いで CC: FormalIMATH 100.00 / 95.06, ProverBench 100.00 / 94.83, CombiBench 93.00 / 47.00, FATE-M 99.33 / 97.33, FATE-H 82.00 / 63.00, FATE-X 54.00 / 37.00.

• 難しいセットこそが正直なものです：FATE-H CC 63% と FATE-X CC 37% は、最も難しいサブセットにおけるモデルの上限を示しており、一方、より易しい FormalIMATH と ProverBench では 95% 以上の CC を示しています。

• 論文が挙げる最良の8Bベースライン（ReForm-8B 81.76 / 66.21、Goedel-Formalizer-V2-8B 78.24 / 60.08）と、最良の32Bベースライン（ReForm-32B 81.61 / 68.41、Goedel-Formalizer-V2-32B 78.28 / 63.74、StepFun-Formalizer-32B 63.65 / 44.47）は、いずれもMathForm-8Bの88.06 / 72.37には及ばない。

SFTのみのチェックポイント（RL段階の前）は84.38 / 66.53に達し、強化学習パスは平均でおよそ+3.7 SC、+5.8 CCに相当する。最大の改善は難しいセットで見られる。

懐疑的であるべき最も強い主張は、FormalIMATHとProverBenchにおける100.00 SCスコア（易しいセットでの100%コンパイルは、それらのセットが収束していることを示す危険信号である）、そして同一条件下で再実行されていない32Bモデルとの比較である。FATE-HとFATE-XにおけるConsistency Checkの数値は、独立したテストを最も生き残る可能性が高い数字である。

何が確認されていないのですか

• 独立した評価は存在しない。本稿執筆時点で、第三者はMathForm-8Bを公開ハーネスで実行しておらず、評価コードも公開されていない。

• サービス提供の発表はありません。OpenBMBは、ローンチブログ、料金ページ、APIエンドポイントを公開していません。「静かにリリースされた」という表現は文字通りの意味です。

RLの報酬重み、トレーニング予算、およびハードウェアはモデルカードには記載されておらず、論文にのみ記載されています。

• 8BモデルがLean 4.21.1+やMathlib以外のインポートに一般化するかどうかは未テストです。

実行方法

現時点では、セルフホスティングが唯一の方法です。READMEには3つの方法が記載されており、それらはすべてcode>localhost:8000/v1/chat/completions/code>にあるOpenAI互換のチャットエンドポイントを備えています:

• Transformers — code>AutoModelForCausalLM.from_pretrained("openbmb/MathForm-8B", torch_dtype=torch.bfloat16)/code>、次にチャットテンプレートで生成します。

• vLLM — code>vllm serve openbmb/MathForm-8B --served-model-name MathForm-8B --dtype bfloat16 --max-model-len 16384/code>.

• SGLang — code>python -m sglang.launch_server --model-path openbmb/MathForm-8B --served-model-name MathForm-8B --dtype bfloat16 --context-length 16384/code>。

README では、温度 0.6、top_p 0.95、最大 16384 トークンの生成を推奨しています。形式的な記述は長くなりがちなため、この余裕のある生成ウィンドウが、実際に予算化すべきシステム要件となります。

「8Bが32Bに勝る」という部分が重要な理由

数字がその通りなら、MathForm-8Bは、自動形式化のボトルネックがパラメータ数そのものではなく、データ品質と検証にあることを示す、これまでで最も強力な論拠となる。論文の表自体にも、32Bの専用モデル（ReForm-32B、Goedel-Formalizer-V2-32B、StepFun-Formalizer-32B）が、コンパイラ検証済みコーパスで学習された8Bモデルの下に位置していることが示されている。現在32Bの形式化モデルを運用しているチームにとって、これは実質的なコスト変動である。BF16の8Bモデルは、ほとんどの32Bモデルでは搭載できない単一GPUに収まり、トークンあたりの推論も高速だ。

また、これはモデル環境の他の部分が生み出し続けている正直な選択を際立たせる。すなわち、検証済みの単一タスクを非常にうまくこなす狭い専門モデルか、検証の保証なしに多くのタスクに挑戦できる汎用モデルか、という選択である。形式化に限って言えば、専門モデルは出力をコンパイラがチェックするモデルであり、これはまさに、自動フェイルオーバーを備えたルーターをその前に置くことを安心して行える特性である。OrcaRouterが200以上のモデルにわたってプロバイダー標準価格のパススルーで実行するようなルーティング層があれば、公開から数日のオープンウェイトモデルにテスト経路を向け、それが停止した瞬間に実績のあるモデルへフォールバックできる。本番経路を賭けることなく静かなリリースを採用でき、プロバイダーが後でそのモデルをリストに追加した場合でも、トークン価格へのマークアップは一切ない。

次に見るもの

「面白いリポジトリ」から「信頼できるツール」へと変わるには、次の3つの要素がある。GitHubの評価コードが実際に登場すること、pass@8ではなくpass@1でのFATE-HとFATE-Xに対する最初の独立した評価が行われること、そしてホステッドルートを追加するか、アブレーション数値を含む論文v2を出すOpenBMBの発表があること。そのうち少なくとも1つが実現するまでは、見出しのスコアは方向性を示すものとして扱うべきだ。永続的なニュースとなるのは正確なパーセンテージではなく、アーキテクチャとトレーニングデータのアイデアである。