Reflexionとは｜AIの失敗メモを引き継ぐ条件と見直し方

Reflexionは失敗メモで何を変えるか

Reflexionは、試行の結果を言語化して次に渡す研究手法であり、モデルの重みを更新せずに経験メモリを使います。変えるのは、次の試行で参照できる情報です。原論文の方式説明（§3）

Shinnらが2023年に発表し、NeurIPS 2023に掲載されました。論文の著者所属にはNortheastern University、MIT、Princeton Universityが記載されています。一般向けチャットサービスや新しい基盤モデルの名前とは区別してください。NeurIPSの掲載情報／著者・所属を記載した論文PDF

出力・評価・振り返りの3つの役割

Reflexionの基本構成は、出力・行動を担うActor、結果を評価するEvaluator、改善の手掛かりを言語化するSelf-Reflectionです。これらは処理上の役割であり、別々のLLMを3つ契約するという意味ではありません。LLMとは、大規模な言語データを学び、文章などを生成するモデルです。原論文の構成と評価方法（§3）

評価の方法には、正解との照合、ルール、LLMによる判定などがあります。プログラミング課題なら、テストに通ったかという結果を振り返りに使います。ただし、評価自体が間違っていれば、そこから作る教訓も疑う必要があります。原論文の評価方法と誤判定の分析（§3・§4.3）

AIエージェントとは、目的に向けて出力や行動を選び、結果を受けて次へ進む仕組みです。全体像を補いたい場合は、AIエージェントの基本的な仕組みも参照できます。

重みの更新と、メモを渡すことの違い

Reflexionでは、過去の経験を次の入力の文脈へ加えます。重みとは、モデル内部で学習によって調整されるパラメータです。モデルを再学習させる処理と、試行時に経験メモを読ませる処理は分けて考えます。原論文の経験メモリの説明（§3）

たとえば、前の試行で見落とした条件を言葉にして残し、次の試行で参照させる関係です。ここでいうメモリは、チャット製品の保存機能や無期限の記憶を保証するものではありません。論文では課題ごとに保持する経験を制限しています。原論文のメモリ設定

HumanEvalの通過率91.0%と、MBPPでの低下

原論文には改善例と低下例の両方があり、失敗の記録だけで広く性能が上がるとは読めません。2023年のTable 1では、コード生成課題HumanEvalのPythonで比較対象GPT-4の80.1%に対し、Reflexionは91.0%でした。一方、別のコード生成課題MBPPのPythonでは80.1%に対し77.1%でした。いずれも同表のpass@1です。原論文Table 1の実験結果

pass@1とは、評価するコード候補を1つ選んだ場合のテスト通過を表す指標です。Reflexionでは候補を作る途中にテスト・振り返り・修正が入るため、「AIへの1回の問い合わせで91%成功」という意味ではありません。HumanEval原典の指標説明／Reflexionの反復・評価実装

この数値は研究当時の課題・モデル・実験条件に限られます。現在の日本語チャットや日常の文章作成で同じ改善幅が得られるかは、本記事の参照資料からは判断できません。次の判断表も、その効果を実証したものではありません。

失敗メモを次の試行に使ってよいか

Reflexionを参考にした本記事の判断表は、失敗の判定根拠とメモの適用条件を確かめ、利用の保留・見直し・再評価を選ぶためのものです。原因を確定した記録と、次に確かめる仮説を分けて使います。

根拠・仮説・適用条件から採否を決める

次へ渡す前に、観測した失敗と原因の仮説を分けてください。原論文にも自己生成テストの誤判定が報告されているため、評価や振り返りの文面だけで原因が確定したとは扱いません。原論文の誤判定と限界（§4.3・§5）

対象は、次の試行へ渡す失敗メモです。まず判定根拠を確認し、不明なら利用を保留します。次に適用条件を照合し、矛盾があれば見直します。両方を整理できたら、未確認の原因は仮説と明記して使い、次の結果で再評価します。表は横にスクロールできます。

「使って再評価する」は、改善が確認できたという判定ではありません。次の結果を元資料や合格基準と照合して、メモを残すか見直すか決めてください。

失敗メモの記入欄と使い方

判断表で確認した内容を、次の記入欄へ移します。空欄を埋めるために原因を確定せず、未確認なら仮説として記録してください。

失敗の判定基準・根拠：

観測した事実：

原因の仮説（未確認）：

次に変えること・確かめること：

適用条件：

見直す条件：

架空例：渡した資料から予定を日付順に整理するよう依頼したのに、出力から1件の日付が抜けたとします。「出力に日付がない」は観測した事実です。「確認項目を設けなかったためではないか」は原因の仮説であり、AIの内部で起きたことを確認した説明ではありません。

この例なら、次の変更は「各予定の日付を元資料と照合し、資料にない場合は未記載と示す」と記録できます。同じ資料を整理する場合の案であり、実際にAIへ入力して効果を測った結果ではありません。

改善しないとき、失敗メモをどう見直すか

Reflexionを参考にした失敗メモの運用では、改善しない結果や条件の変化を、メモと評価方法を見直すきっかけにすることを提案します。記録を増やす前に、どの前提が残っているか確かめます。

残った失敗を、評価と修正内容に照らす

同じ失敗が残ったら、判定の根拠と、実際に変えた点を照合します。前の架空例なら、元資料に日付があるのに出力から落ちたのか、元資料にも日付がなかったのかで、見直す対象が違います。

前者なら確認項目の適用や出力を調べ、後者なら「資料にない日付まで埋める」という期待を見直します。メモが改善を生んだかを判断する前に、入力側の情報不足を出力だけの失敗にしていないか確かめる、という考え方です。

資料・目的・基準が変わったら再確認する

別の条件へ移るときは、前のメモがそのまま使えるかを確認してください。予定の一覧から日付順に整理する作業と、日付のない議事録から論点を整理する作業では、必要な項目が違います。

前の教訓を無条件に足すと、今回必要ない日付まで求める指示になりかねません。目的・資料・合格基準を記録しておくことは、適用範囲のずれを見つける助けになると考えられます。

教訓の適用停止と、元の記録の保持を分ける

新しい結果と矛盾する教訓は、次の指示への適用を止めるか、条件を付け直す対象にします。元の入力・出力・判定まで消すという意味ではありません。教訓が誤りだったと気づいた理由を振り返れるよう、試行の記録と現在使うメモを区別します。

根拠を確認できないまま同じ修正を繰り返す場合は、再試行より資料や評価方法の確認を先にすることを勧めます。原論文にも評価や探索の限界があり、「反省を続ければ解決する」という保証はありません。原論文の限界（§5）

まとめ：次の試行で確かめること

Reflexionを日常の作業へ応用する際は、手元の失敗メモを判断表に照らし、次の試行で何と照合するかを1つ決めてください。判定根拠がない場合は、再試行より資料や評価方法の確認を先にします。

課題・資料・合格基準が変わったとき、または次の結果がメモと矛盾したときは、判断表で根拠と適用条件を確かめ直してください。