Self-Critiqueによる検証

自己批評では、LLMを使って、評価基準やポリシーに照らして別のLLMの出力を評価します。決定論的なバリデーターでは定義できない、事実の不整合、トーン、役立ちやすさ、微妙なポリシー違反などの複雑な失敗を検出できます。

これは、スキーマバリデーターやルールバリデーターをモデルで補完するものです。

批評は生成処理の末尾に指示として追加するのではなく、独自のプロンプトを持つ別の呼び出しとして実行します。判定だけを求められた、クリーンなコンテキストの批評役のほうが、生成途中に自分の回答を採点させるよりもはるかに信頼できます。後者では、自分の回答を支持する方向に偏るためです。

パイプラインがプログラムから処理できるよう、批評役には構造化された判定を出力させます。自由記述の批評は、機械的に処理できません。

批評役と修正役を組み合わせます。批評役が問題を見つけ、作成役が批評を使って修正し、合格するか予算を使い切るまで繰り返します。これは、モデルを使った修正ループに相当します。

「これは良いですか？」のような曖昧な指示では、判定にばらつきが生じます。明確で評価可能な基準を備えた具体的な評価基準を使うと、判定が一貫します。批評役が個別に回答できるよう、はい・いいえで答えられる質問に分解します。

ハルシネーションを検出するには、批評役にソースコンテキストを渡し、そこから導き出せない主張をすべて指摘するよう求めます。これにより、根拠なしに「これは本当ですか？」と尋ねるよりもはるかに強力な、含意関係のチェックとして自己批評を実行できます。

批評役自体もLLMであるため、失敗する可能性があります。

• 迎合 — 作成者の回答を無批判に承認します。
• 過剰な批評 — 正しい出力まで問題として指摘します。
• 共有された盲点 — 同じモデルが同じエラーを見逃します。

批評役に異なるモデルファミリーを使うこと、厳格なレビュアーの人格を設定すること、しきい値を調整することで緩和できます。

批評役に最も高価なモデルを使う必要はありません。多くの場合、厳密な評価基準を備えた小規模モデルが費用対効果の高いゲートになります。また、異なるモデルファミリーを使うと、相関した盲点を減らせます。最も強力なモデルは作成に使用します。

自己批評によってエラーは減りますが、証明にはなりません。影響の小さいコンテンツでは、批評を1回行えば十分です。影響の大きい出力では、自己批評を決定論的なバリデーターや人によるレビューと組み合わせます。安全性が重要な意思決定を、モデルだけに委ねてはいけません。

自己批評を行うと、リクエストあたりの呼び出し回数はおよそ2倍になります。決定論的なチェックを通過したものだけを批評するようにし、同一の下書きに対する批評をキャッシュし、修正ラウンド数に上限を設けて制御します。可能な場合は、ブロックしない処理と並列に批評を実行します。

批評役を信頼する前に検証します。人間がラベル付けした出力のデータセットを作成して批評役を実行し、人間の判定に対する適合率と再現率を測定します。批評役の判定が人間の判定と相関するまで、評価基準と人格を調整します。モデルをアップグレードした後も再確認します。

RAGの回答に含まれるハルシネーションを、批評役に確実に検出させたいと考えています。信頼性を最も高める方法は何ですか。

自己批評検証:

• クリーンなコンテキストを持つ別の批評役が、作成役の出力を判定します。
• 構造化された判定を出力し、批評してから修正するループを駆動します。
• 具体的な評価基準と、根拠に基づく含意関係のチェックによって信頼性が高まります。
• 迎合や共有された盲点に注意し、異なる批評モデルを使用します。
• コストで実行を制御し、決定論的なチェックと組み合わせ、人間の判定に照らして調整します。

これでガードレールをすべて学び終えました。次のコースは、レッドチーミングと敵対的評価です。