CRITIC：なぜLLMの自己修正には外部ツールのフィードバックが必要なのか
金融エージェントがミスを犯した後に何が起こるかを考えながら、CRITIC（Gouら、ICLR 2024）を読んでいました。Reflexionは、エージェントがエピソードを通じて失敗から学べることを示しました。CRITICはより鋭い問いを投げかけます。LLMは単一の生成パス内で自らのエラーを検出し、修正できるのか。そして、もし可能なら、そのために実際に何が必要なのか。
論文の概要
CRITICは、言語モデルが初期出力を生成した後、外部ツール（事実確認のための検索API、コードと算術のためのPythonインタプリタ、コンテンツモデレーションのための有害性分類器）を使用して「検証・修正」ループを繰り返すフレームワークを導入しています。こ のループは固定回数実行され（論文では約3回の修正で効果的な結果が報告されています）、洗練された出力を生成します。著者はこれを、自由形式の質問応答（TriviaQA、AmbigNQ、HotpotQA）、数学的プログラム合成、および有害性の削減において評価しました。
中心的な主張は、LLMが自力で自己修正できるということではありません。むしろその逆です。CRITICの価値は、モデルが捏造できない外部信号に「批判（Critique）」を基づかせる（グラウンディングする）ことにあります。検索APIがなければ、QAの改善はほぼゼロになるか、逆に悪化します。このフレームワークが機能するのは、モデルが信頼できる自己監査人になるからではなく、ツールがモデルの真に知らなかったことを教えるからです。
主なアイデア
- ChatGPTに適用した場合、CRITICは3つのオープンドメインQAタスク平均で7.7のF1スコア向上、3つの数学的推論ベンチマークで7.0ポイントの絶対利得を達成しました。
- 有害性の削減は、最も顕著な単一の結果です。評価データセットにおいて、有害性の確率は79.2%減少しました。
- 検索APIを削除すると、QAパフォーマンスは横ばいになるか低下します。モデル固有の自己批判能力は、事実に関するタスクにおいてはほとんど役に立ちません。
- ループは迅速に収束します。3回の修正ラウンドでほとんどの利得が得られ、それ以降は収穫逓減となります。
- フレ ームワークはモデルに依存せず、ファインチューニングを必要としません。Text-Davinci-003とChatGPTの両方を含むブラックボックスAPIで動作します。
- CRITICは、ほとんどのタスクで自己整合性（self-consistency：複数のサンプルにわたる多数決）を上回りました。自己整合性にはステップごとのツールコストがかからないことを考えると、これは重要な結果です。
何が妥当で、何がそうでないか
核心となる実証結果は強固です。外部ツールのフィードバックは出力を大幅に改善し、検索APIを除去した際のアブレーション（切除実験）の結果は、素朴な自己修正の提唱者にとって手厳しいものです。また、この論文はそのメカニズムについても正直です。利得は、創発的なメタ認知能力からではなく、ツールからもたらされています。
私が十分に探求されていないと感じるのは、失敗モードの分類です。モデルが間違った批判を生成し、正解からさらに遠ざかってしまうのはどのような時でしょうか。論文では平均的なパフォーマンスが報告されていますが、実際のデプロイにおいては、タスクや質問のタイプによる分散が非常に重要になります。財務の文脈では、最悪の結果は「改善なし」ではなく、新しいエラーを導入してしまう「尤もらしく聞こえる修正」です。
また、反復を3回で打ち切る選択も、原理的な停止基準というよりは実 用上の利便性として提示されています。収束すべき正解（グラウンドトゥルース）が存在するTriviaQAなどでは3ラウンドで十分かもしれません。しかし、元帳の照合（ledger reconciliation）のように、「正しい」答えを得るために複数ドキュメントにわたる推論とドメイン知識が必要な領域では、3回のツール呼び出しで十分か、あるいは汎用的な検索APIが適切な検証信号を提供できるかは明らかではありません。
ICLR 2024の同時期の論文「Large Language Models Cannot Self-Correct Reasoning Yet」（Huangら、arXiv:2310.01798）は、別の方向からCRITICの発見を裏付けています。外部フィードバックがない場合、自己修正は確実に推論の正確性を低下させます。これら2つの論文は、一貫した構図を描いています。人々が「自己修正」と呼んでいた能力の大部分は、外部フィードバックによる洗練であり、その区別こそが重要なのです。
なぜこれが金融AIにとって重要なのか
CRITICのループは、Beancountエージェントにおける「書き戻しの安全性（write-back safety）」の問題に自然に当てはまります。現在、LLMエージェントが仕訳（トランザクションの分類や費用の分割など）を提案するとき、ディスクに書き込む前に自らの出力を検証する原理的な方法はありません。CRITICのアーキテクチャは、具体的なパターンを示唆しています。候補となるエントリを生成し、 ツール（残高チェック関数、ルールエンジン、重複検知器など）に対して検証を実行し、書き込みが確定する前にツールの出力を使用して修正を促すという流れです。
有害性の結果は、言い換えると非常に有用な比喩になります。ポリシー違反の79.2%削減は、モデルがルールを内面化したからではなく、違反をモデルに報告する分類器によってもたらされました。Beancountの元帳であれば、二重計上された取引やカテゴリー違反をフラグ立てし、その信号をエージェントの修正パスにフィードするルールチェッカーがそれに相当します。エージェントはルールが破られていることを自律的に知る必要はなく、ツールの信号を必要としているのです。
金融分野における決定的な制限は、検索APIへの依存です。金融エージェントには、ドメイン固有の検証ツールが必要です。口座残高の整合性チェック、勘定科目表（chart-of-accounts）のバリデータ、税務ルールのルックアップなどです。一般的なウェブ検索で、分類ミスをした経費を見つけられる可能性は低いです。会計におけるCRITICスタイルの修正のために適切なツールレイヤーを構築することこそが、真のエンジニアリングの課題であり、この論文ではドメイン固有のツール設計については一切触れられていません。
次に読むべきもの
- "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., 2023, arXiv:2310.01798) — 本質的な自己修正が失 敗するという直接的な実証的議論。同じメカニズムを逆方向から検証しているため、CRITICと併せて読むべきです。
- "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (Yao et al., NeurIPS 2023, arXiv:2305.10601) — 単一パスの批判と修正のアイデアを、中間ステップにわたる探索ツリーへと拡張。エージェントが探索とバックトラックを必要とする多段階の照合業務に関連します。
- "ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs" (Qin et al., 2023, arXiv:2307.16789) — CRITICが前提としている、エージェントがどのようにツール呼び出しを選択し連鎖させるかを学習するかという上流の問題を調査しています。
