SPL: Orchestrating Workflows with Declarative Deterministic-Probabilistic Composition
本論文は、決定論的計算と確率的計算を単一の仕様内で統合することでモデルに依存しないワークフローのオーケストレーションを可能にする宣言型フレームワークであるSPL（Structured Prompt Language）を導入し、そのソルバーベースのアプローチが、検証されていないLLMのみの出力と比較して、機械的に検証された正当性を大幅に高めることを広範な実験を通じて実証する。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
あなたは、宿題を手伝ってくれる超スマートなロボット助手を作ろうとしていると想像してみてください。現在、こうしたアシスタントを構築することは、エンジンの、ステアリングホイール、そしてGPSがすべて異なる会社によって作られ、異なる言語を話し、それらをバラバラのカスタムメイドのテープで無理やり接着しなければならない車を作ろうとしているようなものです。これらを連携させるためには、コーディングの魔法使いにならなければなりません。
この論文は、SPL (Structured Prompt Language) を紹介しています。これは、ロボットの「創造的な」部分と「数学的な」部分を、一つのクリーンな指示マニュアルの中でようやく連携させることができる、ユニバーサルリモコンのようなものです。
二つの脳：夢想家と計算機
論文では、現在のAIツールはあるモードに固執していると主張しています。それらは、物語を書いたり、答えを推測したり、チャットをしたりすることには長けているものの、時に事実を捏造したり数学を間違えたりする**「夢想家（Dreamers）」（LLM）か、あるいは、ジョークを理解したり物語を書いたりすることはできないが、数学や論理には完璧である「計算機（Calculators）」**（SymPyやSageMathなど）のどちらかです。
著者らは、「両方を持てばいいのではないか？」と提案しています。彼らが提案するのは、「夢想家」（システム1）が問題を分解して説明し、「計算機」（システム2）が実際の重労働を行い、その作業を検証するというシステムです。
大きなひねり： 論文は、AIがどちらか一方であるために「速い」か「遅い」である必要があるという考えに対して、明確に反対しています。これは速度の問題ではなく、どのように考えるかの問題です。計算機は非常に難しい証明を行っている間は遅くなることができますし、夢想家は単に推測しているだけなら速くなることができます。重要なのは、どの仕事にどの脳を使うかを知ることです。
「一度設計すれば、どこでも展開できる」魔法
ここが最も素晴らしい部分です。SPLを使えば、特別な .spl ファイルで一度だけ指示を記述できます。もし、自分のノートパソコンやクラウド、あるいは巨大なスーパーコンピュータのグリッドで実行したいとしても、コードを書き直す必要はありません。
これはレシピのようなものです。レシピを一度書きます。そのレシピを、小さなキャンプ用ストーブ（あなたのノートパソコン）で調理しようと、高級なキッチン（クラウド）で調理しようと、あるいは大規模な工業工場（分散型グリッド）で調理しようと、レシピ自体は変わりません。起動する時に、どこで調理するかを伝えるだけです。論文ではこれを DODA (Design Once, Deploy Anywhere) と呼んでいます。
「検証の梯子（Verifier Ladder）」
数学が正しいことをどうやって知るのでしょうか？ 論文では、3つの段がある「検証の梯子」を紹介しています。
- 第1段 (SymPy): 基本的な代数や微積分に適しています。速くて簡単です。
- 第2段 (SageMath): 数論や幾何学などのより高度な内容用です。
- 第3段 (Lean 4): 究極のボスレベルです。これは、数学的に100%正しいことをコンピュータがチェックする、形式的な証明のためのもので、数学の法的契約のようなものです。
論文では、まず第1段を試み、もし失敗したら、システムが自動的に第2段へと梯子を登り、それでも失敗したら第3段へと登るワークフローを書けることを示しています。あなたは「もしこれが失敗したら、あれを試す」というコードを書く必要はありません。言語がそれを処理してくれます。
実験：実際に何が起きたのか？
著者らは単に推測したわけではありません。彼らは、10種類の異なるAIモデルを、20種類の異なる数学問題（初級からエキスパートレベルまで）に対してテストし、各テストを3回ずつ実行しました。合計で1,200回の実行となります。
彼らは、問題を解決する2つの方法を比較しました。
- 「LLMのみ」の腕： AIが単に答えを推測して記述します。
- 「ソルバー（解決策）」の腕： AIが問題を分解し、計算機に数学を送り、検証された答えを受け取り、それから説明を記述します。
結果：
- 良いニュース： ソルバーの腕は驚異的な正確さでした。最高のモデル、例えば
gemma4:e2bでは、計算機によって検証された際に**93%の正解率を得ました。sonnet-4-6でさえ85%**の正解率でした。 - 注意点： 「LLMのみ」の腕は、ほとんど常に（100%に近い頻度で）何らかの答えを出すことはできましたが、それは検証されていませんでした。ソルバーの腕は、AIが何かを「言っている」からといって、それが真実であるとは限らないということを証明しました。
- ボトルネック： ソルバーの腕が失敗した主な理由は、AIが数学ができなかったこと（計算機はできていました！）ではなく、AIが回答を正しくフォーマットできなかったことにありました。AIは、計算機が理解できるように、非常に特定のコード形式（
expr|op）で数学を書かなければなりませんでした。もしAIがフォーマットをミスすると、計算機はそれを拒絶しました。 - 驚きの事実：
gemma4:e2bという小さなオープンソースモデルは（巨大で高価なモデルよりもずっと小さいですが）、ルールに従うという点において、一部の巨大なモデルよりも優れたパフォーマンスを示しました。これは、この特定の仕事においては、巨大で超スマートな脳であることよりも、優れた「フォーマット翻訳者」であることが重要であることを示唆しています。
論文が「言っていないこと」
論文は、自らの限界についても非常に明確に述べています。
- AIモデルが、単独で数学において完璧になったとは主張していません。実際、実験では、計算機なしではモデルは単に推測しているだけであることを示しました。
- 「思考（Thinking）」モデル（回答する前に長い時間をかけて「考えている」モデル）がより優れているとは言っていません。実際、論文では、一部の「思考」モデルは、思考に時間をかけすぎて、計算機が必要とする特定のコード形式を書き終える前に容量を使い果たしてしまったため、除外されています。
- このことがあらゆる問題を解決するとは主張していません。実験は、記号数学に特化したものでした。著者らは、これがコードのチェックやデータの検証といった他の事柄にも応用できる可能性があると示唆していますが、まだ証明はしていません。
結論
この論文は、AIの「創造的な」部分と「数学的な」部分を分離し、コンピュータに数学を検証させることで、より信頼性の高い結果が得られることを証明しています。最も素晴らしい点は、これを行うためにコーディングの天才である必要はないということです。ただ計画を一度書けば、システムが、あなたのノートパソコンで実行しようとスーパーコンピュータで実行しようと、残りのすべてを処理してくれます。
著者らはこれを1,200回の実行で測定し、「ソルバー」の腕は（作業をチェックするために数秒余計に時間がかかるため）わずかに遅いものの、「おそらく正しい」答えを「機械検証済み」の答えに変えることを発見しました。最高のモデルにとって、この検証にかかるコストは速度の面でほとんど無視できるほどであり、この二段階のアプローチが、よりスマートで安全なAIアシスタントを構築するための実用的な方法であることを証明しています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。