PAL: 信頼性の高い財務演算のためのプログラム支援言語モデル

表形式の推論（tabular reasoning）に関する文献を調査した後、私は補完的なアプローチについて理解したいと考えました。LLMに自然言語でテーブルについて推論させるのではなく、コードを書かせて計算を完全に任せたらどうなるでしょうか？PAL（Gaoら、2022年、arXiv:2211.10435）はその代表的な回答であり、財務データに対して信頼性の高い算術演算を行う必要のあるあらゆるシステムにとって、明らかな示唆を与えています。

論文の概要

「PAL: Program-Aided Language Models」（Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023）は、単純な観察から始まります。それは、LLMは問題の分解は得意だが、算術の実行は苦手であるということです。思考の連鎖（Chain-of-thought）プロンプティングは最初の問題を解決しますが、2番目の問題は手付かずのままです。提案された解決策は、LLMが「推論ステップ」として生成する内容を変更することです。自然言語による算術の代わりに、Pythonコードを生成します。そして、Pythonインタープリタがそのコードを実行し、答えを返します。

問題の分解と実行の分離は明快です。LLMは問題の理解とプログラム構造を担当し、インタープリタは数値に関するすべてを担当します。「オリビアは23ドル持っていて、1個3ドルのベーグルを5個買いました。残りはいくらですか？」という質問は、モデルが失敗する可能性のある散文的な算術の連鎖ではなく、money_left = 23 - (5 * 3) というコードになります。

主なアイデア

• GSM8K（小学校レベルの算数文章題）において、Codexを使用したPALは72.0%の精度に達しました。これは同じCodexモデルを用いた思考の連鎖（65.6%）に対して+6.4ポイントの向上であり、はるかに巨大なPaLM-540Bモデルを用いたCoT（56.9%）をも上回ります。より小さなモデルが、算術をPythonに委託することで勝利したのです。
• 数値がより大きな値に置き換えられたGSM8KのバージョンであるGSM-hardでは、PALは61.2%を達成したのに対し、CoTは23.1%でした。これは38.1ポイントという圧倒的な差です。大きな数値はトークンレベルの算術を破綻させますが、Pythonを破綻させることはありません。
• 40サンプルの多数決（majority voting）を用いると、PALはGSM8Kで80.4%に達し、約10分の1のサイズのモデルでありながらMinerva-540B（78.5%）を僅差で上回りました。
• この向上は記号推論にも一般化されます。BIG-Bench Hardタスクの「物体カウント（Object Counting）」では、PALは96.7%（CoTは73.0%）、「テーブル内のペンギン（Penguins in a Table）」では93.3%（CoTは79.2%）を記録しました。
• アブレーション調査により、実際にどこで処理が行われているかが明らかになりました。LLMが自身のインタープリタとして機能する場合（外部のPythonなし）、GSM8Kの精度は23.2%にまで崩壊します。インタープリタは単なる些細な強化ではなく、算術演算のすべてを担っているのです。
• 変数名が重要です。意味のある変数名をランダムな文字に置き換えると、記号タスクにおいて精度が大幅に低下します。モデルは自身のコードを読み取っているのです。

評価できる点と懸念点

核心となる主張は明白に正しく、実験はそれを説得力を持って裏付けています。Pythonは算術においてLLMよりも優れており、GSM-hardはその事実を残酷なまでに可視化しています。そこでの38ポイントの差はベンチマークの特異性ではなく、スケール下におけるCoTの構造的な失敗モードを反映しています。

私がそれほど納得していないのは、これを一般的な推論のブレークスルーとして位置づけている点です。PALは、たまたま確定的でPythonで表現可能な答えを持つタスクで機能します。財務推論において重要なことの多くは、このように分解できません。ある取引パターンが「この口座の第4四半期としては異常」であるかどうかや、送金に手動確認のフラグを立てるべきかどうかを判断することは、Pythonの式に還元できるものではありません。PALは信頼性の高い算術エンジンを提供してくれますが、判断力を提供してくれるわけではありません。

セキュリティの側面については、論文内では全く触れられていません。ベンチマークは制御された環境で実行されますが、ユーザーから提供された入力に応じて任意のPythonを生成・実行するデプロイメントは、重大な攻撃対象領域（アタックサーフェス）となります。サンドボックス化されたインタープリタからのカーネルエスケープ、ファイルシステムやシークレットへのアクセス、悪意のあるコードを生成させるように細工された入力など、これらについては何も対処されていません。財務アプリケーションにとって、これは単なる脚注で済まされる問題ではありません。

また、この論文はコード生成が失敗したときの失敗モードを深く分析していません。PALが構文的に無効なPythonを出力した場合、何も得られません。著者は実行成功率を報告していますが、何が生成の失敗を引き起こすのか、あるいはそれがランダムなのか系統的なのかについては特徴付けていません。インタープリタがすべての算術を行っている以上、コードの品質が信頼性のボトルネックのすべてであり、そこが分析不足です。

なぜこれが金融AIにとって重要なのか

これは、私が読んだ中でBeancountに最も直接的に適用可能な論文の一つです。元帳操作は、PALが得意とすることとほぼ完全に一致しています。カテゴリー別の取引の集計、為替レートの適用、複数のロットにわたる税務上の原価計算、銀行明細の合計と元帳残高の照合などです。これらは確定的で、算術負荷が高く、Pythonで表現可能です。CoTベースのエージェントはここで数値を捏造（ハルシネーション）しますが、プログラム構造が正しければPALはそうなりません。

同時に独立して同じアイデアを開発した論文「Program of Thoughts (arXiv:2211.12588)」では、FinQA、ConvFinQA、TATQAという3つの財務QAデータセットで評価を行い、思考の連鎖に対して平均約12%の向上を報告しています。これは、プログラム生成アプローチが小学校レベルの算数だけでなく、財務ドメインの推論にも役立つことを示す最も直接的な証拠です。

しかし、元帳の文脈では、ベンチマークよりも「書き戻しの安全性」の問題が鋭くなります。Beancountのデータを読み取るためにPythonを生成するエージェントは低リスクです。しかし、元帳エントリを書き込むためにPythonを生成するエージェントには、厳格に制限された実行環境が必要です。元帳オブジェクトのみを操作でき、それ以外には一切触れず、例外が発生した場合には安全側に倒れ（fail closed）、生成されたコードが実行前にホワイトリストを通過することを要求するような環境です。PALはインタープリタを中立的な計算エンジンとして扱っています。本番環境の財務エージェントでは、そのような扱いは不可能です。

次に読むべき文献

• Program of Thoughts Prompting (Chen et al., arXiv:2211.12588) — FinQA、ConvFinQA、TATQAで評価を行い、CoTに対して平均約12%の向上を報告している並行研究。PALが後回しにした財務固有の評価を行っています。
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen et al., EMNLP 2021) — PoTの財務評価の基礎となったベンチマーク。実際に何がテストされているかを理解することで、実際のBeancountのユースケースへの転用をどの程度信頼できるかを測ることができます。
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., arXiv:2303.17651) — PALの第一著者と同じ著者による、コード生成の知見を反復的な自己修正ループへと拡張した研究。PALスタイルのエージェントが、自身のコード生成の失敗から回復できるかどうかに深く関連します。