自己反省（Reflection）とは｜見直しで直る欠陥と、何回見直しても直らない欠陥

見直しで直る欠陥と、何回見直しても直らない欠陥

5種類の欠陥を性質で分けました。読み返せば気づけるものは3種類、自分の中に正解がないものは2種類で、後者は回数を増やしても変わりません。

自己反省がどこまで効くのかを、欠陥の種類ごとに切り分けました。用意したのは出力によく混ざる5種類の欠陥です。

先に断っておくと、これはモデルを繰り返し動かした実測ではありません。欠陥を「読み返せば気づけるか」で分類した整理です。分類の根拠はコードに書いてあります。

const DEFECTS = [
  { name: '形式の誤り（JSONが壊れている）',       selfDetectable: true,
    reason: '構文として不正なので読み返せば分かる' },
  { name: '指示の見落とし（3件と言われたのに2件）', selfDetectable: true,
    reason: '指示と出力を突き合わせれば分かる' },
  { name: '論理の飛躍（根拠なく結論づけた）',      selfDetectable: true,
    reason: '自分の文章の筋を追えば分かる' },
  { name: '事実の誤り（存在しない機能を書いた）',  selfDetectable: false,
    reason: '間違って覚えているので読み返しても同じ結論になる' },
  { name: '情報の古さ（去年の料金を書いた）',      selfDetectable: false,
    reason: '新しい情報を持っていないので気づけない' },
];

5種類の欠陥に対して、自己反省で直るかどうか

  直る     形式の誤り（JSONが壊れている）
  直る     指示の見落とし（3件と言われたのに2件）
  直る     論理の飛躍（根拠なく結論づけた）
  直らない 事実の誤り（存在しない機能を書いた）
  直らない 情報の古さ（去年の料金を書いた）

自己反省で直る: 3 / 5
外部の情報が要る: 2 / 5

反省の回数を増やしたときに直る欠陥の数
  1回反省: 3 / 5（呼び出しは 2回）
  2回反省: 3 / 5（呼び出しは 3回）
  3回反省: 3 / 5（呼び出しは 4回）

分かれ目がはっきり出ました。直らない2つに共通するのは、正解を自分の外に取りに行かないと判定できないという点です。

自分の中にある欠陥は直る

壊れたJSONは、読み返せば構文として成立していないと分かります。3件と言われて2件しか出していないなら、指示と出力を並べれば数が合いません。どちらも判定に必要な材料が手元にそろっています。

論理の飛躍も同じで、自分の書いた文章の筋を追い直せば、根拠の抜けた箇所は見つかります。

自分の中にない欠陥は直らない

存在しない機能を書いてしまった場合はどうでしょうか。読み返しても、間違って覚えているのですから同じ結論に辿り着きます。去年の料金を書いた場合も、新しい料金を知らない以上は気づきようがありません。

ですから反省の回数を増やしても意味がありません。実際、1回でも3回でも直った数は3種類のままで、増えたのは呼び出し回数だけでした。

Anthropicも、この点に対する手当てとして実行できる検査を渡すことを挙げています。テスト、ビルド、比較用の画面といった、結果が外から返ってくるものです。

自己反省とはどういう進め方なのか

出したものを自分で読み返し、直すべき点を挙げてから書き直させます。作る側と見る側を分ける形にもできます。

自己反省は、一度出した答えをそのまま返さず、読み返させて直させる進め方です。人が下書きを見直してから提出するのと同じ流れになります。

1周の中身

まず答えを出させます。次にその答えを渡して、問題点を挙げさせます。最後に挙がった問題点を踏まえて書き直させる。この3段が1周です。

呼び出し回数は増えます。1周させるだけで2回、2周なら3回になります。

作る側と見る側を分ける形

同じモデルに見直させるかわりに、評価する役をもう1つ用意する形もあります。Anthropicはこれをevaluator-optimizerと呼び、片方が答えを作り、もう片方が評価と指摘を返す繰り返しだと説明しています。

とはいえ役を分けても、同じ知識しか持っていなければ結果は変わりません。前の節で直らなかった2種類は、役を分けただけでは直らないままです。

直らない欠陥をどう手当てするか

実行できる検査を足すか、答えを出した過程を知らない相手に見せるか。この2つが現実的な選択肢です。

自己反省で直らない欠陥にどう対処するかを整理します。方向は2つあり、機械に判定させるか、別の目を入れるかです。

実行できる検査を足す

いちばん確実なのは、正しさが自動で判定できる検査を用意することです。テストが通るか、ビルドが成功するか、想定した画面と一致するか。結果が外から返ってくるので、記憶違いの影響を受けません。

この記事の元になった実演でいえば、料金が古いかどうかは料金ページを取りに行けば判定できます。実際に編集部では、記事に載せた引用が原文に存在するかを機械で照合しています。

過程を知らない相手に見せる

検査を書けない場合は、別の文脈で動く相手に結果だけを見せる手があります。Anthropicは、新しい文脈で動く確認役は差分と判断基準しか見ず、その変更を生んだ推論を知らないので、結果そのものを評価すると述べています。

同じ会話の中で見直させるのとは、ここが違います。自分の考えた筋道が見えていると、その筋道ごと正しいと思い込んだままになりがちです。

どこまでやるかの目安

1. 形式が決まっている出力。自己反省で足りる。検査を書くならそちらが速い
2. 指示の件数や項目が決まっている出力。自己反省で足りる
3. 事実を含む出力。外部の情報と突き合わせる検査が要る
4. 時間で変わる情報を含む出力。取得日を記録し、期限を決めて取り直す

3番目と4番目に自己反省を当てても、費用が増えるだけで精度は変わりません。前の節の数字がその証拠になります。