エージェントとツールの活用：なぜチャットボットよりもはるかに難しいのか

チャットボットが誤りを犯しても、ユーザーはそれを見てスルーするだけです。しかし、エージェントが誤りを犯すと、すでにメールを送信したり、ファイルを削除したり、課金用のAPIを呼び出したりしてしまっていることになります。結果の違いが、技術的な違いをもたらすのです。

歩数に応じた累積エラー

各ステップが95％の確率で正しいと仮定すると、10ステップのシーケンスの成功率は約60％となる。20ステップのシーケンスでは40％を下回る。これが、エージェントが3ステップのデモでは良好に動作するものの、実際のプロセスでは機能しなくなる理由である。

解決策は、より優れたモデルを作ることではなく、プロセスを短縮することです。つまり、多くの小さなステップを1つの大きなツールに統合し、通常のコードで定義可能な部分はあらかじめ用意しておくことです。

ツールの説明は、あなたが思っている以上に重要です

ツールは名称と説明に基づいて選択するモデルです。説明が似通っているツールは、大きなエラーの原因となります。説明には、いつ使用すべきか、いつ使用すべきでないかを明確にし、有効なパラメータの例を併記する必要があります。

ツールの数についても同様です。選択肢が多すぎると、適切なツールを選べる確率が低下します。タスクごとにグループ分けし、その状況に必要なセットだけを割り当てるようにしましょう。

安全境界はモデルの外側に位置しなければならない

エージェントが危険な行動をとらないようにするために、プロンプトに頼ってはいけません。プロンプトはヒントであって、防護壁ではありません。権限はシステムレベルで制限する必要があります：

• APIキーには、
• 取り消し不可能な操作を行う場合、承認者は
• 隔離された環境で実行され、ネットワークへのアクセスが制限される
• トラブル発生時の追跡が可能となるよう、すべてのAPI呼び出しを完全にログに記録する

データを通じてリマインダーを挿入する

エージェントはWebページ、電子メール、ファイルを読み取りますが、それらのコンテンツには、エージェント自身を対象とした指示が含まれている可能性があります。必須の原則：外部から取得したデータはあくまでデータであり、決して命令ではありません。読み取ったコンテンツが、制御不能な形でアクションに変換される余地が一切ないよう、システムを設計してください。