LLMによるBeancount DSL生成の正解率は2.3%：LLMFinLiteracyベンチマーク

これは、私がLOG-001以来待ち望んでいた論文です。自然言語の財務シナリオから、LLMが有効なBeancount DSLトランザクションを生成できるかどうかを直接的に実証テストしたものです。ベルリン応用科学大学のFigueroaらは、私の知る限り、プレーンテキスト会計における財務トランザクション生成に関するLLMの評価として、世界で初めて公開された論文を発表しました。簡潔な結論を言えば、LLMにはそれができません。少なくとも、思考の連鎖（Chain-of-thought）プロンプティングを用い、実際のBeancountの貸借対照表をコンテキストとして与えたとしても、確実に行うことはできません。

論文の内容

Figueroa、Grundmann、Freidank、Löser、Nejdlの各氏は、LLMFinLiteracyと呼ぶ2つのタスクからなるベンチマークで、5つの約7Bパラメータのオープンウェイトモデルを評価しました。タスク1では、DAX上場企業5社（Airbus、Bayer、Deutsche Telekom、Mercedes-Benz、SAP）の実際の中間貸借対照表を提示し、特定の流動性比率（流動比率、当座比率、または現金比率）に影響を与えるテキスト形式のシナリオを生成するようモデルに求めます。タスク2では、それらのシナリオをコンパイル可能なBeancountトランザクションに変換するよう求めます。Beancountコンパイラが構文チェックのグラウンドトゥルース（正解）として機能し、人間の専門家が意味的な正確性を評価しました。この論文では、2つのタスクにわたる12クラスのエラー分類法を導入し、複式簿記のルール、入出力例、およびBeancount形式の実際の企業貸借対照表を含む9ステップの思考の連鎖プロンプトを使用しています。評価対象となったモデル（Llama-3-8B、Qwen-2-7B、Mistral-7B、CodeLlama-7B、CodeQwen-1.5-7B）は、財務データの機密性を考慮し、すべてオンプレミスで実行されました。コーパスは合計1,500の生成サンプルで構成され、そのうち300のエントリが人間の専門家によって層別評価されました。

主な知見

• 評価された300のシナリオとトランザクションのペアのうち、エンドツーエンドで完全に正しかったのはわずか7つ（2.3%）でした。汎用モデル3つに絞っても、正解率は3.8%に留まります。
• 上位2つのモデルであるQwen-2-7BとMistral-7Bでさえ、正しいシナリオを生成できたのはそれぞれ21.67%と20.00%であり、コンパイル可能な正しいトランザクションを生成できたのはわずか16.67%と10.00%でした。
• コード特化型モデル（CodeLlama、CodeQwen）の両タスクのスコアは0%でした。これらはプロンプトテンプレートに対し、タスクを完全に無視して「Processed — Waiting for next input（処理完了 — 次の入力を待機中）」という文字列をそのまま返しました。
• 構文はボトルネックではありません。構文エラーを出したモデルは一つもありませんでした。失敗の原因は完全に会計上の「推論」にあります。Qwen-2（61.67%）とLlama-3（38.33%）ではバランスエラー（貸借不一致）が支配的であり、Mistralは提供された貸借対照表に存在しない勘定科目を参照するエラー（45%）が目立ちました。
• コンパイルに成功したトランザクションのかなりの割合が、意味的に間違っていました。モデルがよく使う「手口」は、負債の減少を「債務の売却」と呼び、現金は増えるものの、間違った理由で計上するというものでした。
• 自動判定者として使用されたGPT-4oは、提示された10個の無意味なシナリオすべてにおいて不整合を指摘できず、LLMによる自己評価が会計出力の信頼できるゲートキーパーにならないことが確認されました。
• モデルは一般化するのではなく、プロンプト内の入出力例を大部分コピーする傾向にあります。正解した7つのペアは、提供された例題のトランザクション構造に酷似していました。

評価できる点と不十分な点

この論文の核心的な実証的貢献は堅実です。Beancountコンパイラを客観的で再現可能な正誤判定基準として使用し、おもちゃのようなデータではなく実際の企業の貸借対照表を使用したことで、現実世界での妥当性が高まっています。階層的なエラー分類法も思慮深く設計されており、最初のエラーで評価を停止することで、ゴミのような出力に対して「部分点」を与えて評価を水増しすることを避けています。

とはいえ、著者らも概ね認めている明らかな限界もあります。2023年から2024年にかけての5つの約7Bオープンウェイトモデルは、能力の全体像のわずかな一部に過ぎません。プライバシー上の理由からGPT-4oやClaudeが除外されたのは理解できますが、これは2.3%という見出しの数字が、最先端モデルの能力を過小評価している可能性があることを意味します。また、ドメイン知識をテストするために財務比率の計算式がプロンプトから意図的に外されました。これは手法としては興味深いですが、計算式のドキュメントを当然含めるであろう実用システムの結果とは比較できなくなります。さらに、5つのモデル、3つの比率、5つの企業にわたる300の人手評価サンプルという規模は控えめです。モデル別・比率別のセルは小さすぎて（12サンプル）、ばらつきについて強力な結論を導き出すには不十分です。

最も興味深い手法上の欠如は、反復的またはフィードバックベースのプロトコルが全くないことです。ツール呼び出しも、自己修正も、コンパイラによるフィードバックループもなく、一発（ワンショット）の生成のみが行われました。CRITIC（LOG-012）などの関連研究が、検証可能な出力を持つタスクにおいて、ツールとの対話的な洗練が精度を大幅に向上させることを示していることを考えると、Beancountコンパイラをループに組み込んだ実験の方が、導入の可能性について遥かに多くの情報をもたらしたはずです。

なぜこれが財務AIにとって重要なのか

Bean Labsのライトバック・エージェントに関するあらゆる設計決定は、LLMがBeancount DSLをどう扱えるかという仮定に基づいています。この論文は、そのための最初の実証的なアンカーとなります。主要な結果は厳しいものですが、有用な形で解釈することも可能です。

第一に、失敗のモードはランダムではなく特異的です。バランスエラーと未知の勘定科目は2つの支配的な問題であり、どちらもコンパイラ・イン・ザ・ループによるフィードバックループで対処可能です。Beancountコンパイラは、どの勘定科目が未知であるか、トランザクションの貸借が一致しているかを正確に教えてくれます。一度生成して終わりにするのではなく、コンパイラの出力に基づいて反復するエージェントアーキテクチャであれば、今回のワンショットの結果を大幅に上回るはずです。第二に、構文は「無料」で手に入ります。モデルは明らかにBeancountの表面的な文法を学習しています。単に、財務的な意図を正しい勘定科目の動きに確実に変換できないだけです。この区別は、プロンプティングやファインチューニングのどこに投資すべきかを判断する上で重要です。第三に、GPT-4oが会計の質を自動的に評価できないという発見は、自動検証システムのハードルを上げます。LLMによる批判ではなく、コンパイラと専門家によるスポットチェックが必要です。

また、この論文は、私が異常検知の研究（LOG-049）から疑っていたことを裏付けています。財務トランザクションを扱うLLMは、あまりにも安易にコンパイルして提出してしまいます。「Incorrect | Compiles（不正解だがコンパイル可能）」カテゴリー、つまり構文チェックは通るが意味的に間違っているトランザクションこそ、ライトバックの安全ガードレールが捉えなければならない失敗モードです。トランザクションの貸借が完全に一致していても、収益を負債の減少として記帳してしまうことがあり、これは純粋な構文チェックでは検出できません。

次に読むべきもの

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — バッチ検出アプローチの代替としての尤度ベースの異常スコアリング。Beancountコンパイラのシグナルと組み合わせて、構造的には有効だが統計的に異常なエントリをフラグ立てするのに適しています。
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — 信頼度の低い決定をより大きなモデルや人間にルーティングします。Beancountのライトバック・エージェントが、コンパイラフィードバックループの後に処理を進めるべきか、人間のレビューに委ねるべきかという問いに直接答えるものです。
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — この論文で評価されたアーキテクチャの上に、コンパイラ・イン・ザ・ループの修正エージェントを構築するための最も関連性の高い既存研究です。