エージェントに自分の宿題を採点させてはいけない
Claudeにコードのレビューを頼むと、「コードは綺麗です」と返ってくる。当然だ。そのコードを書いたのは、わずか5分前の彼自身なのだから。これは、作者に自分の答案を採点させたようなものだ。そして、彼は自分に「A」をつけた。
AIによるコードレビューは有効だ。しかし、作者自身に自分の成果物をレビューさせると失敗する。品質は、「どの役割も自分自身をチェックしない」というアーキテクチャから生まれる。
2024年の研究では、「自己嗜好バイアス（self-preference bias）」が示されている。モデルは、同等の品質の他の出力よりも、自分自身の出力を高く評価する傾向がある。モデルは自身のスタイルを認識し、それを好むのだ。
「書いて、書いたものをすぐにレビューする」というループは破綻している。得られるのはレビューではなく、正当化だ。エージェントはすでにそのコードが良いと判断している。再度尋ねても、その判断を追認するだけである。
より優れたエージェント・ワークフローを構築するために、以下のルールに従ってください：
- レビュー担当者は決して作者であってはならない。スタイルの認識を断ち切るために、レビューには別のモデルファミリーを使用すること。
- クリーンなコンテキストを使用すること。レビュー担当者は、元の実装プロンプトや作者が設定した制約を見てはならない。
- アイデンティティを排除すること。誰がコードを書いたのかをレビュー担当者に伝えてはならない。作者の正体はバイアスを引き起こす。
- 過剰なフラグ立てを避けること。AIレビュアーは、役に立っているように見せるために、しばしば問題を作り出す。これでは、彼らの意見を聞かなくなってしまう。
誤検知を防ぐために「レシート・ルール（receipt rule）」を使用してください。すべての指摘事項には、提示される前に証拠が含まれていなければなりません。
もしレビュアーがSQLインジェクションのリスクを主張する場合、以下のものを提供しなければなりません：
- ユーザー入力のgrep結果。
- クエリフローのトレース。
値が定数であれば、その指摘は破棄してください。HTTPリクエストから来ているものであれば、保持してください。判断に先立って、証拠が必要です。
重大な指摘については、「懐疑派のパネル（panel of skeptics）」を活用してください。彼らの仕事はバグを確認することではなく、それを論破することです。彼らは、その指摘がなぜバグではないのかを証明しようとしなければなりません。過半数がその指摘を覆せなかった場合にのみ、それが承認されます。
真実は自己宣言からではなく、矛盾から生まれる。
役割が決して重複しないシステムを構築してください：
- ライターはコードを書く。
- テスターは仕様書のみに基づいてテストを書く。
- レビュアーはコードを書いていない。
- 人間やLLMが確認する前に、リンターやテストなどの客観的なゲートを通過しなければならない。
自分自身を修正する修正者は、何も修正できない。AIレビューの品質は、いかにして「自分自身を採点すること」を阻止できるかにかかっている。
出典: https://dev.to/ohugonnot/no-agent-grades-its-own-homework-8lb
オプションの学習コミュニティ: https://t.me/GyaanSetuAi