模型編譯與本機推論
Compile by Training 將自然語言規格編譯成 0.6B 模型可執行的本機函式
新方法以大型教師模型合成任務資料，再訓練每項函式專屬的 LoRA，讓後續請求不必呼叫遠端模型。它在困難測試集取得 83.6% 語意正確率，但編譯仍需要教師 API、約 40 GB 加速器記憶體及輸出驗證。
大型模型很適合處理「容易描述、難以寫成規則」的文字工作，逐次呼叫 API 卻會累積延遲、費用與供應商依賴。滑鐵盧大學與哈佛研究者提出 [Compile by Training](https://arxiv.org/abs/2609.04199)，把模型適配改成類似軟體建置的步驟：開發者先以自然語言定義輸入、輸出與限制，教師模型據此合成結構化範例；編譯器驗證資料後，以梯度下降微調任務專屬的 LoRA。
所有函式共用一個凍結、量化的 Qwen3-0.6B 解譯器。公開配置先由既有 Program-as-Weights 編譯器產生初始權重與執行提示，再訓練 rank-64、alpha 16 的 LoRA 共 100 步。成品封裝為 `.paw`，包含 adapter、提示骨架、原始規格與解譯器中繼資料；解譯器只需下載一次，新輸入可在本機處理，函式也能快取、版本化及組合。團隊展示的網站助理便將模糊分類與答案選擇交給 30 個編譯函式，而把 BM25 檢索與流程控制保留給確定性程式。
在特別挑選、舊快速編譯器無法精確命中的 FuzzyBench-Hard 上，新方法的 LLM Exact Match 從 22.4% 升至 83.6%。代價是 B300 上的建置時間由 3.5 秒增至 50.9 秒；H200 與 RTX 測得 68.2、99.2 秒。這項指標由 GPT-5.5 判定語意正確，雖然對 128 筆作者標註達 97.7% 一致準確率，仍不是形式驗證。
[公開實作](https://github.com/programasweights/compile-by-training)採 MIT 授權，但目前核心僅是一套精簡編譯腳本，預設流程需要 OpenAI API 金鑰及約 40 GB 可用加速器記憶體。所謂「本機」只涵蓋編譯完成後的推論；規格和合成階段仍接觸外部教師，而且 adapter 會繼承教師遺漏的邊界案例。工程團隊下一步應測量中文任務、分布外輸入與規格修改後的行為漂移，並為安全或合規流程保留確定性驗證閘門。