今回の論文
今回取り上げるのは、Aman Madaan、Niket Tandon、Prakhar Guptaらによる論文「Self-Refine: Iterative Refinement with Self-Feedback」です。2023年3月にarXivで公開され、改訂版は同年5月に公開されました。公開元はarXiv、URLは https://arxiv.org/abs/2303.17651 、DOIは https://doi.org/10.48550/arXiv.2303.17651 です。研究分野は自然言語処理、LLM推論、自己改善型エージェントです。
この論文を選んだ理由は、モデルの再学習や専用の報酬モデルを用意せず、すでに利用中のLLMを「生成者」「レビュアー」「改稿者」として使い分けるだけで出力品質を上げようとするからです。回答の根拠確認、コードレビュー、要件の多い文書作成など、初回出力をそのまま採用しにくいAIアプリに応用しやすい考え方です。
どんな技術か
Self-Refineは、LLMが作った初案を同じLLM自身にレビューさせ、その指摘を使って改稿させる反復アルゴリズムです。入力に対して一度だけ回答を生成する代わりに、初案 → 具体的なフィードバック → 改稿を必要回数繰り返します。
重要なのは「もう一度良くしてください」という曖昧な指示ではありません。何が問題か、どの箇所をどう変えるかまで含む、実行可能で具体的なフィードバックを生成させます。たとえばコード最適化なら「ループが全件走査になっているので、等差数列の公式に置き換えられる」と指摘し、その内容を次の改稿プロンプトへ渡します。モデルの重みは変えず、推論時の対話ループで性能を引き出す技術です。
課題
LLMは流暢な初案を短時間で作れますが、複数の要件を同時に満たす仕事では、一回の生成で最適解に届かないことがあります。顧客返信なら丁寧さ、質問への応答、次の行動の明確さを両立させる必要があります。コードなら正しさに加えて、計算量、可読性、既存APIとの整合性も重要です。
既存の改善手段には、より大きいモデルへの変更、正解データによるファインチューニング、人間の好みを使う強化学習があります。しかし、独自の出力形式や社内業務ごとに教師データを集めることは高コストです。また、一発生成で複数候補を出して選ぶだけでは、「なぜ最初の案が不十分だったか」を次の候補に反映できません。
実際のAIシステムでは、初案がほぼ正しいが、条件を一つ取りこぼす、要点が長すぎる、実装が非効率といった失敗が頻出します。こうした修正可能な失敗を、外部の追加学習なしで検出し、次の生成に反映することがSelf-Refineの課題設定です。ただし、モデル自身が誤りを見抜けない場合は改善できないため、万能な検証器ではありません。
用語解説
- 推論時最適化（test-time improvement）
- 学習済みモデルの重みを更新せず、プロンプトや生成手順を工夫して実行時の出力を改善する考え方です。Self-Refineは追加訓練を不要にする代わりに、複数回の推論で品質を得ます。
- フィードバック
- 初案への評価文です。本論文では「改善してください」ではなく、問題の箇所と修正行動を明示する、具体的で実行可能な指摘が改稿の成否を左右します。
- few-shot prompting
- プロンプト内に少数の入出力例を与え、望む作業をLLMに示す方法です。Self-Refineでは初案作成、レビュー、改稿それぞれに例を示し、役割ごとの出力を安定させます。
- 停止条件
- 反復をいつ終えるかを決める規則です。「改善点なし」というレビュー、品質スコアの閾値、最大反復回数などを使います。無制限に回すと費用と遅延が増え、品質も単調に上がるとは限りません。
- 自己フィードバック
- 生成したモデルが自らの出力を批評する仕組みです。生成モデルと評価モデルを別に持たない簡潔さが利点ですが、同じ誤った前提を共有して見逃す弱点もあります。
技術の仕組み
Self-Refineは、タスク用の初案プロンプトp_gen、フィードバック用プロンプトp_fb、改稿用プロンプトp_refineと、1つのLLM Mで構成されます。タスク専用モデルを訓練する方法ではなく、役割ごとにプロンプトを切り替える制御フローです。
1. 初案を作る
入力xに初案プロンプトを連結し、y_0 = M(p_gen || x)として最初の出力を得ます。ここは通常のLLM呼び出しと同じです。例示を使う場合は、タスクに適した入力・出力のペアをp_genへ含めます。
2. 問題を具体化する
次に、元の入力と現在の案y_tをレビュー用プロンプトへ渡し、fb_t = M(p_fb || x || y_t)を生成します。論文はフィードバックに、何が悪いかだけでなく、どこをどう変えるかを書くよう求めます。コードなら「効率を改善して」よりも「forループを閉形式へ置換し、整数除算を使う」の方が改稿を導きやすくなります。
3. 指摘を反映して改稿する
改稿はy_(t+1) = M(p_refine || x || y_t || fb_t)で行います。実験では過去の案とフィードバックもプロンプトに保持し、同じ失敗を繰り返しにくくしました。改稿器はレビュー本文を最終回答に混ぜず、ユーザーへ返す完成版だけを出す役割です。
4. 停止して完成版を返す
この2、3を、最大回数に達するか、フィードバックが改善不要を示すまで繰り返します。論文の評価では最大4回まで反復しました。実装では、固定の2回程度から始め、JSONでissues、severity、should_refineを返させると、停止判定とログ集計を安定させやすくなります。
全履歴を毎回渡す方式は、前回までの判断を保持できる反面、入力トークンが反復ごとに増えます。長い文書では、最新案と未解決の指摘だけを構造化して引き継ぐ設計が現実的です。これは論文の基本形を運用向けに拡張する際の重要な工夫になります。
実験と結果
論文は、対話応答、コード最適化、コード可読性改善、数学推論、感情極性の反転、略語生成、制約付き生成という7タスクで評価しました。ベースLLMはGPT-3.5（text-davinci-003）、ChatGPT（gpt-3.5-turbo）、GPT-4で、コード系ではCodexも使っています。同じモデルを単発で呼ぶ条件と、Self-Refineを適用する条件を比べたため、改善が反復手順によるものかを見やすい設計です。
指標と評価方法
数学では正答率、コード最適化では最適化できたプログラムの割合、制約付き生成では指定語を含められた割合を使いました。自動指標を定義しにくい対話、可読性、感情反転、略語生成では、出力を伏せた人手A/B評価を実施しています。さらにGPT-4を代理評価器にも使い、感情反転・略語・対話で人手選好との一致率をそれぞれ82%、68%、71%と報告しました。
条件を満たす生成で大きく改善
表1では、GPT-4の制約付き生成が15.0から45.0へ、30.0ポイント改善しました。ChatGPTでは同タスクが44.0から67.0へ改善しています。多くの指定概念を一文に入れるタスクは、初案で漏れた条件をレビューが明示できるため、反復の恩恵が大きいと論文は説明します。
対話応答では、GPT-4の選好スコアが25.4から74.6へ上がりました。コード最適化でもGPT-4は27.3%から36.0%へ8.7ポイント改善し、初案の正しさを保ちながら効率を見直す効果が確認されました。7タスク全体では、従来の単発生成に対し平均で約20ポイントの絶対改善を報告しています。
数学では伸びが小さい
一方、数学推論の改善はGPT-3.5で0、ChatGPTとGPT-4で各0.2ポイントにとどまりました。もっともらしい計算過程をモデルが誤りなしと判断しやすく、誤りの検出自体が難しいからです。これは「自己レビューを足せば必ず正確になる」とは言えない証拠です。正否を機械的に検証できる領域では、テスト実行、数式ソルバー、検索根拠などの外部フィードバックを組み合わせるべきです。
具体的なフィードバックが重要
ChatGPTによるコード最適化では、Self-Refineの27.5に対して、一般的なフィードバックは26.0、フィードバックなしの反復は24.8でした。感情反転では43.2、31.2、0と差が大きくなりました。単に何回も書き直すことではなく、問題箇所と修正方法を持つレビューが、改善ループの中心であることを示しています。
何に使える？
Self-Refineは、初案をすぐ確定させず、短い内部レビューを許容できるアプリに向きます。特に品質条件を文章で表せ、改善の方向が出力から判断できる仕事で有効です。
要件の多い文書生成
提案書、リリースノート、サポート返信では、事実性、簡潔さ、トーン、必須項目といったチェックリストをフィードバックの観点にします。改稿前に「未記載の必須項目」「断定の根拠不足」「読者が取るべき次の行動」をJSONで返させれば、初案での取りこぼしを減らせます。
コード生成・リファクタリング支援
生成した差分に対し、計算量、例外処理、命名、既存の型・API契約をレビューさせてから修正案を出します。Self-Refineだけを正解判定にせず、テスト、lint、型検査の結果をフィードバックへ追加すると効果的です。外部検証の失敗ログは、モデルが見逃しやすい問題を具体的に指す材料になります。
RAG回答の根拠レビュー
RAGでは、回答と取得文書を与え、「文書で支持されない主張」「質問に未回答の条件」「引用すべき箇所」を抽出させて改稿します。これは検索そのものを直す技術ではありませんが、検索結果を無視した断定や、文脈にない補完を抑える後段として使えます。根拠不足なら改稿ではなく再検索へ分岐させる設計も可能です。
エージェントの計画修正
ツールを使うエージェントでは、実行計画、ツール結果、失敗理由を入力として、次の計画を自己レビューできます。たとえば「情報が不足したまま送信しようとしている」「読み取り専用の結果から更新を仮定している」といった制約違反を、実行前に指摘するゲートにできます。高リスクの操作には、外部ポリシー検査や人間承認を残す必要があります。
開発や事業へのヒント
この論文の実務的な示唆は、LLMの品質改善をモデル選定だけに寄せず、生成過程を設計対象にすることです。単発プロンプトで正解を引こうとするより、初案と検査と修正の責務を分けると、失敗原因を観察しやすくなります。
まずは一つの失敗モードに絞る
小規模プロダクトでは、「冗長な回答を短くする」「JSON必須フィールドの欠落を防ぐ」「コードの危険な変更を拾う」など一つの評価軸から始めるのが有効です。評価基準が広すぎると、フィードバックも「全体を改善してください」という無効な指示に戻ります。指摘が実際に改稿へ反映された割合をログで確認してください。
レビューを構造化して観測可能にする
criterion、evidence、action、severity、should_refineのような項目を持つ構造化出力にすると、改稿の入力にも監視にも使えます。失敗の種類を集計すれば、プロンプトの改善で済むのか、検索・ツール・データを直すべきなのかを判断できます。Self-Refineは、品質改善と同時に失敗データを蓄積する仕組みにもなります。
反復回数を品質・費用・遅延で制御する
各反復は少なくともレビューと改稿の2呼び出しを増やします。低リスクのチャットでは1回、高価値なレポートやコード変更ではテスト結果を含めて2〜3回、緊急性の高い処理では単発生成、といった経路を分ける設計が現実的です。代表ケースで、改善率と追加トークン・応答時間を一緒に測り、上限を決めます。
外部検証を次の発展点にする
論文で数学推論がほぼ伸びなかった点は重要です。モデルの内省が弱い領域では、ユニットテスト、スキーマ検証、検索した一次資料、ルールエンジンを評価器として接続します。「自己フィードバック」から「検証可能なフィードバック」へ進めると、業務システムでの信頼性を高められます。
限界
最大の限界は、同じLLMが生成と評価を担当するため、初案と同じ誤った知識や推論を共有しやすいことです。誤った計算や、もっともらしい事実誤認をレビューが見逃せば、改稿しても正しくなりません。論文の数学推論の小さな改善は、この問題を具体的に示しています。
反復はAPI費用、レイテンシ、コンテキスト長を増加させます。履歴を全て残す基本形では、長文ほど後続プロンプトが大きくなります。また、回数を増やすほど良くなる保証はなく、正しい初案を不要に言い換えたり、指摘を過剰適用したりする可能性もあります。
さらに、論文の実験は当時のGPT-3.5、GPT-4とタスク別few-shotプロンプトに依存します。現在のモデル、実データ、独自の品質要件で同じ改善幅が出るとは限りません。導入時は自社の代表入力で単発生成と比較し、事実性や安全性が重要な出力では外部検証・人手レビュー・操作権限の分離を併用してください。
よくある質問
Q. Self-Refineはモデルの追加学習が必要ですか？
A. 必要ありません。論文の基本形は、同じ学習済みLLMに初案作成、フィードバック、改稿を順に依頼します。ただし、各役割で望む出力を得るために、タスクに合った指示やfew-shot例を設計する必要があります。
Q. 単に「もう一度回答してください」と何が違いますか？
A. Self-Refineは、現在の案の問題箇所と修正行動を先に言語化し、その情報を改稿に渡します。論文のアブレーションでも、具体的なフィードバックは一般的な指示やフィードバックなしの反復を上回りました。
Q. 何回反復すればよいですか？
A. 論文では最大4回ですが、実運用では品質要件とコストで決めます。まず1回のレビュー・改稿を代表データで測り、改善が続くか、遅延が許容範囲かを確認して上限を決めるのが安全です。
Q. RAGのハルシネーション対策として使えますか？
A. 取得文書に基づかない主張をレビューする後段として使えます。ただしLLM自身の判定だけでは根拠性を保証できません。引用箇所の照合、再検索、ルールベース検査、人手監査を組み合わせる必要があります。
Q. コード生成でSelf-Refineだけを使って自動マージできますか？
A. 推奨できません。可読性や改善案を出す補助には役立ちますが、機能正しさやセキュリティを自己評価だけで保証できません。テスト、静的解析、差分レビュー、権限管理を通過した場合だけ次の工程へ進めてください。
今日の学び
この論文は、LLMが初回生成で満たし切れない複数要件という課題を扱いました。解決策は、同じLLMに具体的な自己フィードバックを作らせ、それを使って改稿する反復ループです。開発では、生成と検査を分け、外部検証をフィードバックへ接続することで、単発プロンプトだけでは扱いにくい品質改善を設計できるというヒントが得られます。