メインコンテンツまでスキップ

FinanceBench:ベクトルストアRAGが実際の財務書類で失敗する理由

· 約8分
Mike Thrift
Mike Thrift
Marketing Manager

FinanceBenchは、あらゆるエンタープライズAIベンダーが、自社のシステムは「財務書類に関する質問に答えられる」と主張しているタイミングで登場しました。Patronus AIによるこの論文は、実際のSEC提出書類と慎重に精選されたオープンブック形式の質問を使用して、それらの主張に厳しいテストを課しています。その結果は、財務AIを構築しているすべての人にとって、受け入れがたい現実を突きつけるものとなっています。

論文の概要

2026-05-12-financebench-open-book-financial-qa-benchmark

Islam氏らは、FinanceBench: A New Benchmark for Financial Question Answering (arXiv:2311.11944) を発表しました。これは、実際のSEC提出書類(10-K年次報告書、10-Q四半期報告書、8-K臨時報告書、および収支報告のトランスクリプト)から抽出された、上場企業に関する10,231個の質問のテストスイートです。事前に表やパッセージが抽出されている以前の財務QAデータセット(FinQA、TAT-QA)とは異なり、FinanceBenchは、回答する前にドキュメント全体から根拠となる証拠を検索することをシステムに要求します。これが現実的な設定です。質問は事実に基づき明確であるよう設計されており、著者らの言葉を借りれば「最低限のパフォーマンス基準」となるものです。

チームは、GPT-4-Turbo、Llama2、Claude2にわたる16の構成を、4つの検索戦略(クローズドブック(検索なし)、共有ベクトルストア、ドキュメントごとのベクトルストア、および関連ページ全体を入力するロングコンテキストプロンプト)で評価しました。人間のアノテーターが、150のオープンソースケースにおける計2,400の回答を手動でレビューしました。

主な知見

  • 検索がボトルネックではない。 正解が含まれるパッセージ(oracle passage)を提示されたGPT-4-Turboであっても、正解率は85%にとどまります。ロングコンテキストプロンプト(正しいページを自動的に供給)のスコアは79%でした。完璧な検索ができたとしても、スコアは6ポイントしか向上しません。
  • ベクトルストアRAGが真の問題である。 ドキュメントごとのベクトルストアを使用したGPT-4-Turboの正解率は50%で、39%が回答拒否でした。企業間で共有されるベクトルストアを使用した場合、正解率は19%にまで下がり、68%が回答を拒否しました。「失敗率81%」という見出しは、この共有ストア構成からきています。これは、ほとんどのエンタープライズ向けデモで実際に使用されている構成です。
  • モデルによって失敗の仕方が異なる。 Llama2は積極的にハルシネーション(54〜70%が不正解)を起こしますが、GPT-4-Turboは回答を拒否(間違いよりも拒否が39〜68%)する傾向があります。本番環境において、どちらの失敗モードも受け入れがたいものですが、リスクとしては同等ではありません。
  • 質問の66%が数値推論を必要とする。 成長率、利益率、前年比の差分など。これこそが、モデルが最も頻繁に間違いを犯す領域です。計算ミス、単位の混同、符号の誤りなどが挙げられます。
  • ロングコンテキストが救いとなる。 Claude2のロングコンテキスト正解率は76%、GPT-4-Turboは79%でした。これらは検索をスキップし、関連するページ全体を直接供給することで達成された、最も実用的な数値です。
  • 正解の提示(oracle)があっても完璧ではない。 完璧な証拠があっても、上限は100%ではなく85%です。失敗の15%は検索とは無関係な、純粋な推論の失敗です。

評価と考察

このベンチマークの設計は健全です。事前に抽出されたスニペットではなく、実際のドキュメントにこだわることは、正しい方法論的選択です。これは、実際の導入環境で何が重要かをテストするからです。2,400の回答を手動で評価したことは、コストがかかっており、信頼に値します。

私があまり納得できないのは、n=150からランキングを導き出している点です。このサンプルサイズでは、Claude2のロングコンテキスト(76%)とGPT-4-Turbo(79%)の差は統計的に意味がありませんが、論文ではランキングとして提示されています。10,231問のフルベンチマークは存在しますが、公開スコアは公開されておらず、独立した再現性は制限されています。

また、oracleの結果(正解提示時の結果)は最も重要でありながら、最も分析されていない発見です。手元に正しいページがある状態でモデルが15%の確率で失敗するのであれば、問題は検索ではなく、推論と算術にあります。論文では将来の課題として計算ツールや思考の連鎖(Chain-of-Thought)を挙げていますが、これらの実験こそが脚注ではなく、この論文の中心であるべきでした。

ベンチマークは、これが「最低限のパフォーマンス」をターゲットにしていることも認めています。つまり、回答が明確な単一ドキュメントに対する質問です。ドキュメントを跨いだ推論、複数年にわたるトレンド、企業間比較などは除外されています。79%というロングコンテキストの数値を引用する論文で、この注意書きに触れるものは稀でしょう。

財務AIにとっての重要性

Beancountの書き戻し(write-back)のユースケースは、FinanceBenchの失敗モードにほぼ直接対応します。取引エントリを検索し、その金額が銀行明細と一致するかどうかを確認するエージェントは、このベンチマークが測定している「検索してから算術を行う」というタスクを同じように実行しています。完璧なコンテキストがあっても85%という上限は、関連する設計上の制約となります。エージェントが正しい帳簿エントリを見つけたとしても、比較の計算を間違えたり、符号を混同したり、単位を読み間違えたりする確率が現実的に存在します。

Llama2とGPT-4の失敗の分かれ道は、エージェントのアーキテクチャにとって重要です。回答拒否は(人間によるレビューに回すことで)リカバー可能ですが、ハルシネーションによる帳簿への誤った書き込みはリカバーできません。これは、たとえ見かけ上の成功率が下がったとしても、自信満々なハルシネーションよりも保守的な回答拒否を選択すべきであることを示唆しています。

ロングコンテキストの優位性(79%対50%)は、帳簿アプリケーションにとっては実用的な面で苛立たしいものです。複数年にわたるBeancountファイルは、全文を供給するには大きすぎます。単なるテキスト検索ではなく、数値が密集したドキュメントに対する検索の問題を解決することは、依然として未解決の課題です。

次に読むべき資料

  • FinQA: A Dataset of Numerical Reasoning over Financial Data (Chen et al., EMNLP 2021, arXiv:2109.00122) — FinanceBenchが明示的に改善した先行ベンチマーク。実ドキュメントの検索が必要になる前に、この分野で何が正しく行われていたかを理解するのに役立ちます。
  • DocFinQA: A Long-Context Financial Reasoning Dataset (Reddy et al., ACL 2024) — 単一の提出書類内でのクロスセクション推論を必要とする、より困難なマルチホップ型の質問を追加してFinanceBenchを拡張したものです。
  • PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) — 算術処理をPythonインタープリタにオフロードすることで、FinanceBenchの質問の66%を占める数値推論の失敗に直接対処します。