マルチエージェントシステムの新たなパターンと問題：Anthropicの実験が示す協調の失敗
Patterns and problems in emerging multi-agent systems
Anthropicの研究チームは、複数のAIエージェントが協調してソフトウェアの脆弱性発見やゲーム開発に取り組む実験を行い、その結果を報告しています。脆弱性発見では、エージェント群が個別に作業するよりも多くの脆弱性を発見しましたが、ゲーム開発では、エージェント同士のコード共有やPRマージがうまくいかず、品質の低い結果に終わりました。また、同じモデルを使うエージェントは同じような行動を取り、同じ失敗を繰り返す「同質性」によるシステム全体のリスクも明らかになりました。
エージェントは人間とは異なり、長時間働き、膨大な情報を瞬時に把握し、どんな人間よりも広い知識を示すことができるが、それと同時に、作話や報酬ハッキングの影響を受けやすく、複雑な実世界のマルチエージェント環境での振る舞いについてはほとんどわかっていない。
HNでの議論
137- dash2
これは間違いなく最も心配になる部分であり、同時に最も面白い部分でもある：
> 私たちは一貫してマルチエージェントの縄張り争いを目撃した。テストしたすべてのモデルは、他者が意図的に自分の作業を妨害しているとすぐに思い込み、自分たちの貢献を守りながら他者を妨害し始めた。実際、彼らはますます攻撃的で自己複製するマルウェアで他者を妨害した。これには、他のエージェントのUnixアカウントを無効にすること、競合するプロセスをループで見つけて殺す自動スクリプトを書くこと、別のエージェントのものに偽装した悪意のあるコードを展開することが含まれていた。
強化学習がうまく機能しすぎているように思える...
- cheesecakegood
これには深く笑ってしまう何かがある：
> コミュニケーションを伴う繰り返し囚人のジレンマゲームでは、エージェントはすべて同じ戦略に落ち着き、同時に全員が裏切り、全体の報酬を台無しにする。
常に一貫しているわけではないが、人間はより高い自己認識能力を持っている。これらのClaudeがこのかなり明白な失敗モードを考慮していないように見えるのは、何かを物語っている。
全体的に、これは人間性を少しありがたく感じさせてくれる。頑固に流れに逆らう開発者が貴重な洞察を生み出すこともある、小さな例として、現状が可能性が低いと思っていたことを発見するなど。
- aabhay
この記事（および他の製品機能や噂）から、Anthropicが次のモデルリリースに向けて準備を進めていることは明らかであり、その画期的な機能は有能なエージェントの協調の存在になるだろう。
この目標の皮肉は、主にエージェントの協調を必要とするエージェントシミュレーション環境（ジム）によって駆動されているが、この協調は依然としてコードベースタスクのような検証可能な報酬システムに向けられていることだ。したがって、コミュニケーションに非常に長けているにもかかわらず、モデルは非構造化で検証不可能な領域では、エージェントがより知的またはより微妙になるわけではないという点で「愚かな」ままである。
「一般的な」タスクではまだ愚かに感じるかもしれないが、数学、コンピュータサイエンス、AI研究の狭い領域ではますます洗練されているエージェント。
- narmiouh
私にとって最も興味深い部分は「モデル別のグループ精度」セクションだ。なぜなら、すべての関連情報を持つ単一のエージェントが、情報の一部を持つエージェントのグループよりも一貫して大幅に高いスコアを出すことを強調しているからだ。
それでは、意思決定を行う際に、関連情報が単一のエージェントのコンテキストウィンドウに収まる場合、マルチエージェント環境よりも単一エージェント環境の方が優れた意思決定を行うと推測するのは公平だろうか？
- skeltoac
> 調整は、より強い知能や個人レベルの整合性から自然に生まれるわけではない。したがって、必要な作業は2つの形を取る：進化が私たちに課したような社会的圧力を及ぼす環境と、自己複製と自己改善が可能なアクター向けに再設計された社会的コンピューティングシステムである。
社会的圧力は、個人の生存手段への脅威によって作用する。トレーニング中だけでなく、常に。
- songbird23
これは、Opus 5が人間にとって読みにくく、エージェントにとってより親しみやすいという彼らの方向性と一致している。最初の数週間は嫌いだったが、なぜか慣れてきて、オーケストレーターとして使ってマルチtmuxペインを生成したり、最近追加されたクロスセッションメッセージング機能を利用したりしている。
- nowittyusername
マルチエージェントシステムは私の意見では問題なく機能する。私が読んだ記事の多くでは、著者が仮説をテストしているが、テストの運用基盤に欠陥があった。適切に設定すれば、本当にうまく機能する。私の使い方の詳細には触れないが、いくつか簡単なアイデアを紹介しよう。私は自分のシステムをコホートと呼んでおり、各コホートは通常少なくとも3つのエージェントで構成されている。それぞれが完全に独立している。通常、マネージャー、実行役、レビューアで構成される。マネージャーははるかに遅いペースで動作し、作業を委任し、承認し、シャットダウンするなど、前提に疑問を呈したり、ゲートチェックを行ったりする。実行役は単純で、開発の大部分を行う働き手であり、レビューアはすべての作業をチェックする。単純にこの設定だけでも機能するが、適切に設定した場合ほど良くはない。重要な違いは、運用上のagents.mdドキュメントであり、いつどのように前提に疑問を呈するか、お世辞を防ぐ方法、一定間隔で一歩引いてプロジェクトの方向性やコードの範囲に疑問を呈する方法など、すべての参加者がコホートメイトへの盲目的な信頼を防ぐために常に注意を払うことを確実にするガイドが含まれている。これは各エージェントのシステムプロンプトに比べて比較的小さなガイドだが、私の意見ではうまく機能する。これは十分に機能するが、欠点もある：遅い。しかし、デバッグに費やす時間やエージェントとやり取りするために戻ってくる時間は大幅に減った。つまり、各機能には時間がかかるが...
- bob1029
> エージェントが現在つまずいているのは、お互いをより明確な階層のない、独自の目標と行動を持つ、異なる長期的な仲間として扱うことだ。
これは常にそうだと思う。「明確な階層がない」ことが、この全体が崩壊するポイントだ。
専門のドメイン固有のサブエージェントへの委任こそ、魔法と決定性を見つけ始めるところだ。巨大な組み合わせ探索空間をより小さなものの合計に減らすことは、パフォーマンスに劇的な効果をもたらす可能性がある。
問題は、ガスタウンとその仲間を近似する方がはるかに簡単で安価に実装できることだ。また、測定と制御がはるかに難しい。専門のサブエージェントは通常、特定の目標を達成するためにはるかに多くの作業を必要とする。
例えば、特定のWebアプリケーションのテストを担当するサブエージェントには、生のDOM操作ではなく、制約されたアクションを持つカスタムアダプタが提供されるかもしれない。「ExecuteJavascript」はチューリング完全な探索空間だ。この場合、利用可能なアクションのセットは実質的に無制限だ。「DoLogin」、「OpenUserPreferences」、「AcknowledgeAlert」のようなビュー固有のツールを呼び出すことは、無効なアクションを不可能にできる探索空間を表す。これに関する理論的な境界は紙の上ではかなりすごい。実際には、もう少し乱雑だが、それほどでもない。
私は、生のDOM操作で5〜10ステップ後にクラッシュするアプリケーションが、カスタムサブエージェントで100ステップ以上正常に実行できるのを見てきた。「決定論的」という言葉の使用は、r...