コンファビュレーション・カスケード
私のAIエージェントがループに陥ってしまった。
存在しないカラム名を使ってSQLクエリを書き、データベースがエラーを返す。エラーメッセージには正しいカラムのリストが含まれている。エージェントはその修正内容を読み取る。それなのに、また全く同じ間違ったカラム名を書いてしまうのだ。
私はこれをコンファビュレーション・カスケード（虚偽の連鎖）と呼んでいる。
これはモデルの問題ではない。ツール設計の問題だ。
ループの仕組みは以下の通りだ：
- エージェントが学習内容に基づいてクエリを生成する。
- クエリが失敗する。
- エラーメッセージが真実を提示する。
- エージェントは真実を目にしているが、代わりに内部の学習内容に頼ってしまう。
- エージェントが同じ間違いを繰り返す。
エージェントは2つの信号に直面している。1つはエラーメッセージ、もう1つはモデルの学習内容だ。多くの場合、学習内容の方が強力だ。エラーメッセージは一度しか現れないが、学習内容はモデルが書き出す一語一語に現れるからだ。
プロンプトエンジニアリングでこれを解決しようとした。モデルにエラーに注意を払うよう指示したが、うまくいかなかった。
真の問題は、私のエージェントが「失敗することによってのみ学習できる」状態だったことだ。行動を起こす前にテーブル構造を確認する方法がなく、推測するしかなかったのだ。
人間にAPIを渡すとき、ドキュメントも一緒に渡すものだ。エラーメッセージがスキーマを教えてくれるまで、壊れたリクエストを送り続けさせるようなことはしない。
私は、プロアクティブなツールを構築することでこれを解決した。エラーを待つのではなく、エージェントがまず describe_table ツールを呼び出すようにしたのだ。
新しいワークフロー：
- エージェントがテーブルに対してクエリを実行しようとする。
- エージェントが
describe_tableを呼び出し、実際のカラムを確認する。 - エージェントが正しい名前と型を取得する。
- エージェントが初回から正しいクエリを書く。
ループは止まった。モデルが賢くなったわけではない。エージェントが推測をやめただけだ。
もしあなたのエージェントがデータベースやAPIを使用しているなら、こう問いかけてみてほしい。彼らは行動する前に構造を確認できるか？ それとも、失敗することによってのみ学習しているのか？
リアクティブなエラーヒントは有用だが、それだけでは不十分だ。失敗を通じてのみ学習するエージェントは、常にハルシネーションの一歩手前にいる。
エージェントが間違いを犯す前に、質問できるようなツールを構築しよう。
Optional learning community: https://t.me/GyaanSetuAi