AI エージェントの入門 (パート 2): 自律性、安全対策、落とし穴

第 1 回では、AI エージェントを活用して企業の効率を向上させるための主要な戦略について概説しました。スタンドアロン AI モデルとは異なり、エージェントがコンテキストとツールを使用してタスクを反復的に改良し、コード生成などの結果を強化する方法について説明しました。また、マルチエージェント システムがどのように部門間のコミュニケーションを促進し、統一されたユーザー エクスペリエンスを生み出し、生産性、復元力、アップグレードの迅速化を促進するかについても説明しました。

これらのシステムの構築が成功するかどうかは、役割とワークフローをマッピングするだけでなく、安全な操作を確保するための人による監視やエラー チェックなどの安全策を確立するかどうかにかかっています。これらの重要な要素について詳しく見ていきましょう。

保護措置と自律性

エージェントには自律性が含まれるため、エージェントが自律的に動作する場合のエラー、無駄、法的暴露、危害を軽減するために、マルチエージェント システム内のエージェントにさまざまな保護手段を組み込む必要があります。これらの安全策をすべてすべてのエージェントに適用するのはやりすぎで、リソースに問題が生じる可能性がありますが、システム内のすべてのエージェントを考慮し、これらの安全策のどれが必要になるかを意識的に決定することを強くお勧めします。これらの条件のいずれかが満たされる場合、エージェントは自律的に動作することを許可されるべきではありません。

明示的に定義された人間の介入条件

事前に定義された一連のルールのいずれかをトリガーすると、人間がエージェントの動作を確認する必要がある条件が決まります。これらのルールはケースバイケースで定義する必要があり、エージェントのシステム プロンプトで宣言できます。または、より重要なユースケースでは、エージェントの外部の決定性コードを使用して適用できます。購入エージェントの場合、そのようなルールの 1 つは次のとおりです。「すべての購入は、まず人間によって検証および確認される必要があります。 「check_with_human」関数を呼び出して、値が返されるまで続行しないでください。」

保護エージェント

セーフガード エージェントは、危険な行動、非倫理的な行動、または準拠していない行動をチェックする役割を持つエージェントと組み合わせることができます。エージェントは、セーフガード エージェントに対してその動作のすべてまたは特定の要素を常にチェックし、セーフガード エージェントがゴーサインを返さない限り続行しないように強制できます。

不確実性

私たちの研究室は最近、大規模言語モデル (LLM) が生成するものの不確実性の尺度を提供できる手法に関する論文を発表しました。 LLM には作話 (一般に幻覚として知られる) の傾向があるため、特定の出力を優先することでエージェントの信頼性が大幅に高まります。ここでも、支払わなければならないコストが発生します。不確実性を評価するには、同じリクエストに対して複数の出力を生成して、確実性に基づいて出力をランク付けし、最も不確実性が低い動作を選択できるようにする必要があります。これによりシステムが遅くなり、コストが増加する可能性があるため、システム内のより重要なエージェントについては考慮する必要があります。

解除ボタン

すべての自律エージェントベースのプロセスを停止する必要がある場合があります。これは、一貫性が必要であるか、何が問題でそれを修正するかを理解する間に停止する必要がある動作をシステム内で検出したためである可能性があります。より重要なワークフローとプロセスの場合、この解除によってすべてのプロセスが停止したり、完全に手動になったりしないことが重要であるため、決定論的なフォールバック操作モードをプロビジョニングすることをお勧めします。

エージェントが生成した作業指示書

エージェント ネットワーク内のすべてのエージェントをアプリや API に完全に統合する必要はありません。これには時間がかかる場合があり、正しくなるまでに数回の反復が必要です。私の推奨事項は、エージェントに代わって手動で実行する推奨アクションを含むレポートまたは作業指示書を発行するだけの汎用プレースホルダー ツールをエージェント (通常はネットワーク内のリーフ ノード) に追加することです。これは、エージェント ネットワークをアジャイルにブートストラップして運用するための優れた方法です。

テスト

LLM ベースのエージェントを使用すると、一貫性を犠牲にして堅牢性を実現できます。また、LLM の不透明な性質を考慮すると、ワークフロー内でブラックボックス ノードを扱うことになります。これは、エージェントベースのシステムには、従来のソフトウェアで使用されているものとは異なるテスト体制が必要であることを意味します。ただし、幸いなことに、私たちは産業化の黎明期から人間主導の組織やワークフローを運用してきたため、そのようなシステムのテストには慣れています。

上で示した例には単一のエントリ ポイントがありますが、マルチ エージェント システムのすべてのエージェントは頭脳として LLM を備えているため、システムのエントリ ポイントとして機能できます。分割統治を使用し、まず階層内のさまざまなノードから開始してシステムのサブセットをテストする必要があります。

また、生成 AI を使用して、ネットワークに対して実行できるテスト ケースを考え出し、ネットワークの動作を分析し、弱点を明らかにするようにプッシュすることもできます。

最後に、私はサンドボックス化を強く支持しています。このようなシステムは、既存のワークフローを置き換えるために段階的に展開する前に、まず制御された安全な環境内で小規模に起動する必要があります。

微調整

gen AI に関してよくある誤解は、使えば使うほど良くなるということです。これは明らかに間違っています。 LLM は事前トレーニングされています。そうは言っても、さまざまな方法で動作に偏りを持たせるために微調整することができます。マルチエージェント システムが考案されたら、各エージェントからログを取得し、好みにラベルを付けて微調整コーパスを構築することで、その動作を改善することを選択できます。

落とし穴

マルチエージェント システムはテールスピンに陥る可能性があります。これは、エージェントが絶えず相互に通信し続け、クエリが終了しない場合があることを意味します。これには、何らかの形式のタイムアウト メカニズムが必要です。たとえば、同じクエリの通信履歴を確認し、クエリが大きくなりすぎたり、反復的な動作を検出した場合には、フローを終了してやり直すことができます。

発生する可能性のあるもう 1 つの問題は、私が過負荷と呼ぶ現象です。つまり、単一のエージェントに過度の期待をすることです。現在の最先端の LLM では、エージェントに長く詳細な指示を渡し、エージェントが常にその指示に従うことを期待することはできません。また、これらのシステムには一貫性がない可能性があるとも言いましたか?

このような状況を軽減する方法は、私が粒状化と呼んでいるものです。つまり、エージェントを複数の接続されたエージェントに分割することです。これにより、各エージェントの負荷が軽減され、エージェントの動作の一貫性が高まり、テールスピンに陥る可能性が低くなります。 (私たちの研究室が取り組んでいる興味深い研究分野は、粒状化のプロセスの自動化です。)

マルチエージェント システムの設計方法におけるもう 1 つの一般的な問題は、タスクを完了するためにさまざまなエージェントを呼び出すコーディネーター エージェントを定義する傾向があることです。これにより、単一障害点が発生し、かなり複雑な役割と責任が生じる可能性があります。このような場合の私の提案は、ワークフローをパイプラインとして考慮し、1 人のエージェントが作業の一部を完了し、それを次のエージェントに引き渡すことです。

マルチエージェント システムには、コンテキストが他のエージェントに連鎖的に渡される傾向もあります。これは他のエージェントに過負荷をかけ、混乱させる可能性がありますが、多くの場合は不要です。エージェントが独自のコンテキストを保持できるようにし、新しいリクエストを処理していることがわかったらコンテキストをリセットすることをお勧めします (Web サイトでのセッションの仕組みのようなもの)。

最後に、エージェントの頭脳として使用される LLM の機能には比較的高いハードルがあることに注意することが重要です。小規模な LLM では、リクエストを満たすために迅速なエンジニアリングや微調整が必要になる場合があります。良いニュースとしては、比較的大規模なものではありますが、基準をクリアしている商用エージェントやオープンソース エージェントがすでにいくつかあるということです。

これは、大規模なマルチエージェント システムを構築する場合、コストと速度を重要な考慮事項にする必要があることを意味します。また、これらのシステムは人間よりも高速ではあるものの、私たちが慣れ親しんでいるソフトウェア システムほど高速ではないことも想定しておく必要があります。

Babak Hodjat は、Cognizant の AI 担当 CTO です。