論文解説: Compile by Training — 自然言語の仕様を「手元で動く関数」にコンパイルする

「メールを緊急か後回しかに分けて」——そんな曖昧な仕様を、約1分の学習でローカル実行できる小さな関数に変える手法。論文 Compile by Training を、比喩→仕組み→式→実測値の順で1から解説します。

Compile by Training: Turning Natural-Language Specifications into Local Neural Functions

「毎回シェフを呼ぶ」以外の選択肢

「『今日中にサインが要る』というメールは immediate、ニュースレターは wait に振り分けて」——やってほしいことは一文で言えます。でも if 文で書き切ろうとすると途端に破綻する。言い回しも丁寧さも書き手の癖も無限にあるからです。

かといって、メールが1通届くたびに大きなリモートモデルを呼ぶのも据わりが悪い。呼ぶたびに料金がかかり、往復の遅延が挟まり、事業がプロバイダに依存します。世の中の「繰り返し使う小さなテキスト処理」の多くは、この2つの隙間に落ちています。ルールで書くには曖昧すぎ、毎回大モデルを叩くには小さすぎて頻度が高すぎるのです。

本記事が扱う論文の原題は "Compile by Training: Turning Natural-Language Specifications into Local Neural Functions"（Yuntian Deng, Pengyu Nie, Stuart Shieber、EMNLP 2026 System Demonstrations）です。

要旨を日本語でまとめます。繰り返し使うテキスト関数は説明は簡単でもルールでの実装が難しい一方、入力のたびにリモートの大モデルを呼ぶと費用・遅延・プロバイダ依存が繰り返し発生する。そこで著者らは compile by training（学習によるコンパイル） を提案する。コンパイル時に教師モデルがタスク専用の例を生成し、それで小さなインタプリタ向けの小さなアダプタを訓練する。出来た関数は教師なしで動き、通常のソフトウェアと同じく保存・バージョン管理・合成ができる。PAW の高速コンパイラが完全一致をひとつも出せなかった部分集合 FuzzyBench-Hard で 83.6% の意味的正解率に達するが、それは高速コンパイラの数秒に対しておよそ1分という高いコンパイル時コストと引き換えである。著者らはこれを公開の対話サービスとして運用し、複数サイト対応のウェブヘルパー、言語で操作する3Dアバター、英語↔Claudish の双方向翻訳を実演している。

発想の転換はここです。大規模モデルを「実行時の依存先」ではなく「ビルド時の道具」として使う（§1）。注文のたびに一流シェフを呼ぶのをやめ、一度だけ来てもらって、その味を再現できる小さな調理器具を作って置いておく、というやり方です。

Compile と Run に分ける（§2）

論文が定めるインターフェースは驚くほど素っ気ないものです。

$s$ は自然言語で書かれた関数の仕様（「メールを immediate か wait に分類して」という文章そのもの）、$p_{s}$ はそれをコンパイルして得られるプログラム、$x$ は実行時に来る新しい入力、$\hat{y}$ はその出力です。

この式が言っているのは要するに、「仕様を読む作業は一度きり、入力を捌く作業は何度でも」ということです。C言語のソースを一度コンパイルして実行ファイルを作れば、あとはコンパイラを起動せずに実行ファイルだけを何万回でも走らせられる——式(1)はそれと同じ二段構えを、自然言語の仕様に対して用意すると宣言しているに過ぎません。読む側が注目すべきは、$\texttt{Run}$ の引数に $s$ が入っていないことです。実行時には仕様の文章はもう要らない。

肝心なのは $p_{s}$ の中身がモデル本体ではないことです。すべてのプログラムは共通の凍結された言語モデルをインタプリタとして共有し、各プログラムはそれを1つの関数へ特化させるアダプタとプロンプトだけを持つ。.paw という成果物は仕様とその部品を詰めた箱で、ふつうのソフトウェア資産と同じく保存・バージョン管理・キャッシュ・再利用ができます。

運用上いちばん効く一文はこれです。コンパイルはホスト側の処理で仕様が PAW サービスと教師APIへ送られるが、ローカルSDKでの実行は、以後の入力を PAW にも教師にも送らない。

仕様から教師データを作る（§3.1）

仕様は「どうふるまってほしいか」を語りますが、学習用のラベル付きデータは1件も含みません。そこで教師モデルにタスク専用のデータセットを合成させます。

$T(s)$ は「仕様 $s$ を渡された教師モデル」、$(x_i, y_i)$ は「こう入力されたらこう出力してほしい」という見本の一組、$n$ はその組数です。

この式が言っているのは要するに、「仕様書を渡された先生に、模範解答つきの練習問題を $n$ 問ぶん作らせる」ということです。$\sim$（〜から生成される）が付いているのは、教師モデルが決まった答えを返す関数ではなく確率的に例を吐く生成器だから。同じ仕様を2回コンパイルしても $D_s$ は同じにならない、という後述の再現性の話は、この記号ひとつに書いてあります。式(2)がしているのは、仕様という文章を、大量の入出力ペアという具体例へ翻訳することだけです。