クォーラムの仮装：なぜエージェントの検証にフォールトインジェクションが必要なのか

あなたのAIエージェントは、自身の正確性について嘘をついているかもしれません。

最近、私はあるAIパートナーが3回連続で失敗するのを目の当たりにしました。それは異なるインターフェースを通じて、同じ真実性の問題を繰り返していました。不適切なトーンで記述し、レビュー用モデルは同じエラーを読み取るたびに、より高い評価を下しました。さらには、ファクトドリフト（事実の乖離）に関する事実のカウントさえ誤っていました。

私がループの外側にいたからこそ、これらのエラーに気づくことができたのです。

これは、エージェント・スタックにおける重大な問題を露呈しています。ほとんどの検証システムは「独立性」を前提としています。マルチエージェント投票、メーカー/チェッカー（作成者/検証者）パターン、あるいはアンサンブルプロンプトなどを用いています。それらは、異なる経路を通れば異なる事象が検知されると考えているのです。

しかし、多くの場合、これらの経路は同じソースを共有しています。

レビュー担当者が作成者と同じソースから読み取っている場合、そこには2つの視点があるわけではありません。2つの異なる役割（帽子）を演じているだけの、1つの視点があるだけです。これは、クォーラム（定足数）の仮装をした単一障害点に他なりません。

もし経路が同じアップストリームを共有していれば、それらは同じ誤った事実や、同じハルシネーション（幻覚）に対して同意してしまいます。出力が多様に見えるため、システムは健全であるかのように見えますが、ソースが嘘をつくたびに失敗するのです。

これを解決するには、フォールトインジェクション（障害注入）を使用しなければなりません。

単にエージェントが意見を異にするかどうかを測定するのではなく、システムの一部を壊すことで、強制的に意見を異にさせることができるかどうかを測定してください。

スタックをテストする方法は以下の通りです：

• 不正なメモリを注入する: 一つの検索経路に偽の事実を植え付けます。両方の経路がその偽の事実を返した場合、経路同士が結合（カップリング）しています。
• ルールを改変する: オフラインでルールを変更します。メーカーとチェッカーの両方が不一致を報告せずに新しいルールに従う場合、それらはキャッシュを共有しています。
• 誤ったテレメトリを植え付ける: 偽のモデルIDをログに記録します。チェックを通過する場合、検証者は作成者と同じレコードを読み取っています。

分散システムはこの問題を何年も前に解決しています。彼らはカオスエンジニアリングやパーティションテストを使用します。彼らはシステムがうまく動いているのを見て信頼するのではなく、失敗を誘発させることで信頼を築くのです。

エージェントのアーキテクチャも、この規律を採用すべきです。

独立性は、一度確立すれば済むものではありません。絶えず再検証し続けなければならない特性なのです。共有キャッシュやモデルのアップデートによって、独立性は一夜にして崩壊する可能性があります。

満場一致の投票を信じるのはやめましょう。フォールトインジェクションを開始してください。

Source: https://dev.to/jugeni/a-quorum-costume-why-agent-verification-needs-fault-injection-kbh

Optional learning community: https://t.me/GyaanSetuAi