16,885 文字
これはAutoGenの創設者であるXi Wang博士とShing Yun Wu博士へのインタビューです。Wang博士はGoogle DeepMindのシニアスタッフリサーチャーで、Wu博士はペンシルベニア州立大学の助教授です。両氏は元々のAutoGenそして現在のAG2の開発者です。エージェントからオープンソースまで、様々なトピックについて話を伺います。
まず、Autoの誕生秘話についてお聞かせください。ペンシルベニア州立大学とMicrosoftの共同プロジェクトだったとお聞きしていますが、それはどのようにして始まったのでしょうか？お二人はその前に何をされていて、どのように出会われたのでしょうか？
はい、ご質問ありがとうございます。確かにAutoGenが作られた当時、私はペンシルベニア州立大学に、そしてチームメイトはMicrosoft Researchにいました。その前は、私たちは別のオープンソースプロジェクト「FL」に取り組んでいました。これは自動機械学習とハイパーパラメータチューニングのためのライブラリで、今日まで5-6年以上にわたって開発を続けています。
このプロジェクトは2019年に始まり、私がMicrosoft Researchでインターンをしていた際のプロジェクトがハイパーパラメータチューニングに関するものでした。私たちは非常に効率的なハイパーパラメータ最適化アルゴリズムを開発し、これをオープンソースとして公開して多くの人々の役に立てようと考えました。そしてFLOライブラリをリリースし、2019年以降このオープンソースプロジェクトに取り組んできました。
また、FLOを中心としたコミュニティも構築してきました。FLOの宣伝をするつもりはありませんが、多くの企業ユーザー、特にフィンテック業界の銀行などで採用されています。表形式のデータを扱う上で、この自動化ライブラリは非常に効率的です。多くの採用事例があり、ライブラリのダウンロード数は何百万回に達しています。
私たちはこのFLOプロジェクトに取り組む中で、生成モデルの持つ大きな可能性を認識し、大規模言語モデルやその他の生成モデル、基盤モデルを人々がより活用できるようにする方法を考えていました。この点については、シェンがもう少し詳しく説明できるかもしれません。
はい、ジムが言及したように、私たちは両方ともFLAMに取り組んでいて、データサイエンティストや機械学習エンジニアが自分たちのアプリケーションに最適なモデルを選択できるよう、AutoML技術を活用していました。GPT-3がリリースされた時、これは新しい種類のモデルで新しい能力を持っていたので、私たちは自然とAutoML技術を使ってGPTモデルの推論パラメータをチューニングし、それがどの程度効果があるのか試してみました。
結果として、数学の問題解決やコーディング、その他のテキスト生成タスクにおいて、最適な推論パラメータを選択することでモデルのパフォーマンスを向上させ、推論コストも最小化できることがわかりました。この時点で、これらのモデルを最大限活用し、異なるアプリケーションに対して効果的に適用する大きな機会があることに気付きました。
単純にモデルを使って1回推論を行うだけでなく、複数の推論や、モデルの使用以外にもツールの使用やユーザー入力の取得など、様々なステップが必要になることがよくありました。これは大きな設計空間でした。AutoMLの経験から、開発者がこの広大な設計空間を簡単に探索し、最適なソリューションを提供できるようにしたいと考えました。
しかし、そのためにはまず、機械学習分野でScikit-learn、PyTorch、Hugging Faceなどの標準的な機械学習フレームワークがあるように、言語モデルのための堅固な基本的なフレームワークが必要でした。これらのフレームワークは、広大な設計空間を簡単に探索できるシンプルなインターフェースを提供し、その上でAutoML技術や最適化技術を適用してプロセスを自動化することができます。
しかし、私たちがAutoGenの開発を始めた当時、言語モデルのための良い統一的なフレームワークは存在していませんでした。そこで、まず自分たちでフレームワークを構築することにしました。それがAutoGenを開発するきっかけとなりました。
エージェント同士が協力し合う可能性に初めて気付いたのはいつでしょうか？私がAutoGenを初めて見た時、それは1つのエージェントが他のエージェントと通信して互いの作業を修正したり、最終的な出力を提供する前に結果を反復改善したりできるという考え方に初めて触れた機会でした。それは私にとって新しい概念でした。その「アハ体験」をされた瞬間や、エージェントが協力して作業する可能性に気付かれた時のことを教えていただけますか？
私から簡単に私の「アハ体験」について話させていただきます。当時私たちは数学の問題を解くことに取り組んでいました。数学の問題を選んだ理由は、まず重要であり、かつ挑戦的な課題だったからです。また、評価がしやすく、私自身が数学を好きで教育者としても数学教育に関心があったことも理由の一つでした。
非常に難しい数学の問題を解こうとした時、ツールの使用や計算のためのコード作成が必要になることがわかりました。コードが関係してくると、コード生成、デバッグ、実行の反復的なプロセスが必要になります。この行き来するデバッグの過程で、コードを実行できる実行エージェントがあると非常に便利だと気付きました。
もう一つの理由は、人間をループに組み込みたいと考えたことです。例えば、モデルが学生を助けられない場合に、実際の人間の教師を関与させたいと考えました。これら2つの要素を組み合わせて、ユーザープロキシエージェントのアイデアが生まれました。
元々の動機は、人間がChatGPTと対話する際の振る舞いを模倣することでした。当時のChatGPTはコードを生成することはできましたが、実行することはできませんでした。ChatGPTと対話する際、人間ユーザーはコードをコピーして実行し、その結果を得て会話を続ける必要がありました。つまり、エンドユーザーが行うことを模倣したわけです。
これにより本質的に2つのエージェントのチャットが形成されました。1つは大規模言語モデルをバックエンドとするアシスタントエージェント、もう1つは人間の行動を模倣するユーザープロキシエージェントです。
このプロセス全体が完全に自律的で、2つのエージェントが自律的にデバッグを行い、タスクを解決するために対話を行う様子は本当に魅力的でした。
私にとって、スタートポイントは本当にChatGPTでした。ChatGPTは以前のGPT-3モデルと比べて大きな進歩でした。ChatGPTは一般の人々に大きな影響を与え、その理由の1つがチャットインターフェースにあると思います。
この自然な対話インターフェースによって、何か問題が起きた時に人間がフィードバックを提供し、反復的に改善できるようになりました。これについて考えた時、私は大学時代の経験を思い出しました。量子コンピューティングと量子通信のセミナーを受講した際、教授から「対話や対談は新しい知識を生み出し、証明し、新しい学びを得るための効果的な方法である」という教えを受けました。
これには深い理論的な根拠があり、ChatGPTの大きな成功はその理論の素晴らしい実証だと思います。私たちは今、対話が可能な非常に有能なモデルを持っています。これは人工知能と人間との対話から始まりましたが、AIモデル同士も対話できない理由はありません。もちろん人間も会話に参加できますが、必ずしも1対1の人間対AIモデルである必要はありません。
その後、GPT-4はその能力をさらに高いレベルに押し上げました。モデルは推論、計画、デバッグなど、より多くの能力を示すようになり、これらの能力は異なるエージェントが異なる役割を果たすように設定できます。
コードの生成、テスト、レビュー、修正など、全体的なワークフローのプロセスを考えると、言語モデルの使い方の範囲を広げ、ループにより多くのステップやプロセスを含め、できるだけ多くをモデルで自動化することで、達成できるタスクの複雑さのレベルはさらに高くなります。
私はいくつかの具体的なアプリケーションについて考えていました。例えばデータ生成です。通常、ユーザーからのリクエストに対応するエージェントが1つ必要で、ユーザーは入力を提供する必要がありますが、ユーザーをAIエージェントに置き換えることで、データ生成プロセスを自動化し、異なる性格や背景に対応する多様なトレーニングデータを大量に生成・収集することができます。これは単純な例の1つです。
アプリケーションの話に入る前に、このパターンを一般化すると、より複雑なプロセスをモデル化する大きな可能性と機会があると考えました。前述のように、私たちは数学の問題解決を最初のケーススタディとして取り上げました。
深い理解を得た後、2つのエージェントを協力させることに成功しました。2つのエージェントとは、GPTモデルをバックエンドとするChatGPTをシミュレートするアシスタントエージェントと、AIエージェントが提案したコードの実行を含む人間の行動をシミュレートするユーザープロキシエージェントです。ユーザープロキシには自動実行やマニュアルフィードバックなど、異なるモードがありました。
2つのエージェントの会話パラダイムがうまく機能するようになった後、初期のユーザーからフィードバックを受け、より多くのエージェントや異なる役割、異なるコミュニケーションパターンに対応できるように会話パターンを一般化する必要があることがわかりました。そこで、シンプルな2つのエージェントの通信から、より多くのエージェントへと急速に発展し、そこから魔法が始まったのです。
ベストプラクティスについて、時間の経過とともに発見されたことについてもお聞きしたいのですが、それは後ほどにさせていただきます。元のAutoGenの開発を始めてから、公開するまでにどのくらいの期間がかかったのでしょうか？
良い質問ですね。考え始めたのはもっと早く、2022年後半頃からでした。モデルのパラメータチューニングにAutoMLを試していた時期と同時期です。モデル、ツール、人間など、異なる種類のエンティティを含む非常に大きな設計空間に対応するための正しい抽象化とは何か、開発者がその空間で直感的に推論できる最も効果的な方法は何か、というところから考え始めました。
これを理解するのに数ヶ月かかりました。GPT-4がリリースされた2023年4月頃が、エージェントを抽象化として使用してエージェントフレームワークの構築を始める本当のスタートポイントでした。そこから8月までの期間は、エージェントフレームワークの構築、初期ユーザーからのフィードバック取得、改善の繰り返しに集中的に取り組みました。8月に最初の研究論文を書いたと思います。
はい、その通りです。AutoGenの初期バージョンを構築し、ケーススタディやアプリケーション研究を行い、それを論文にまとめるまでに数ヶ月かかりました。全部で3-4ヶ月程度です。
公開に関して1つ付け加えたいのですが、実は最初から公開していました。4月に最初のコードを書き始めた時から、オープンソースのFLAMELプロジェクトで開発していたので、すべてのコードは公開されていました。ただ、その時点では何も文書化していなかったので、ほとんどの人は気付きませんでしたが、FLAMコミュニティのメンバーは早期アクセスを持っていました。
私のような一般のユーザーが初めてAutoGenに注目し始めた時、私自身と周囲の反応は覚えていますが、公開した最初の数週間、お二人はどのような気持ちでしたか？人々は本当に驚いていたと思います。私が見た中で最も興味深く、他とは全く異なるものでしたから。
個人的に言うと、正直このようなことになるとは想像もしていませんでした。ただアイデアを形にして、役立つものを作りたいと思って取り組んでいただけで、これほど人気が出るとは思っていませんでした。とても驚きましたし、もちろん良い意味での驚きです。そしてさらに良いものにしていきたいというモチベーションが高まりました。これが私の反応です。
マシューに面白い話をさせてください。私はAutoGenプロジェクトのために1年間の目標を設定していました。FLAMELから独立させた時に、GitHubのスター数について具体的な数字を…
ある数字を言おうとしているのはわかります。1,000スターですか？
その通りです！なぜなら、FLAMELでの経験から、コミュニティは着実に、しかし段階的に成長していくと考えていたからです。最初から個々のユーザーと対話を重ね、何度も改善を繰り返してきました。それはコミュニティの成長として非常に管理しやすい道筋でした。
しかしAutoGenは全く異なりました。リリースからわずか数日で、1年間の目標を変更する必要があることに気付きました。
すごいですね。今見たところ、35,000以上のスターがついているようです。大したことないですね。
オープンソースについてもお二人にお聞きしたいと思います。アカデミアや特にMicrosoft Researchではオープンソースは大きな部分を占めていますが、企業側はAIコミュニティほどオープンソースを採用していないと思います。私はそれに非常に興奮しています。
個人的に、AIに本格的に取り組む前はオープンソースやその価値についてあまり知識がありませんでした。お二人のオープンソースへの道のりについて教えてください。以前からオープンソースに興味があったのでしょうか？それとも、論文を公開するのだからコードも公開するのは当然という考えだったのでしょうか？AutoGenをオープンソースにすることは意図的な決断だったのでしょうか、それともデフォルトの選択だったのでしょうか？
オープンソースの世界での私の道のりをお話ししましょう。最初からスムーズだったわけではありません。むしろ偶然の出来事や、思いがけない展開から始まりました。
Microsoft Researchで最初の数年間は、主に技術開発や研究論文の執筆、時々プロダクトチームと話してその技術を使ってもらうように働きかけるといった活動をしていました。オープンソース活動は全くしていませんでした。
FLOプロジェクトが最初のオープンソース経験でした。その決断をできたことは、今振り返ると非常に幸運だったと思います。ただし、これも最初からオープンソースだったわけではありません。
最初は以前のやり方を踏襲していました。理論研究を行い、理論を証明し、研究論文を書きました。当時、そのFLAMELの研究やAutoの研究を知る人は多くありませんでした。ある日、論文を読んだユーザーが連絡してきて、コードを試してみたいと言ってきました。
しかし、その時点で共有できる準備の整ったコードはありませんでした。研究用のプロトタイプはありましたが、オープンソースではなくプライベートライセンスでそのユーザーに提供しようとしました。しかし、ユーザーはオープンソースを希望していました。これが最初の試みでした。
当時のコードは研究用プロトタイプのクオリティで、すぐに採用できる状態ではありませんでした。しばらくして、また別のユーザーが論文を読んで連絡してき、やはりオープンソース版があるかと尋ねてきました。
その時、もう待てないと思いました。できるだけ早くオープンソース化すべきだと。そうしないと、このパターンが繰り返されることになります。
経験がなかったので、良いアイデアなのか、どれくらい役立つのか、大規模な採用につながるのか、わかりませんでした。しかし、少なくともこのユーザーと以前のユーザーにはこのニーズがあり、より良い選択肢もありませんでした。だから、やってみることにしました。
これが新しい世界への扉を開きました。その後、この道のりで多くのことを学びました。ユーザーの懸念に対応するたびに、ライブラリの使いやすさは大きく向上し、それはまた、その後の何年にもわたる研究活動の原動力にもなりました。
ライブラリは改善を重ね、小規模から中規模の企業、そして大企業へと採用が広がっていきました。Microsoftやその他の企業の大規模プロダクトにも採用されるようになりました。
AutoGenの開発を始めた時点で、この教訓は既に非常に明確でした。オープンソース化の決定とそのタイミングは、FLAMELでの経験から得た教訓に基づいています。
今回は全く異なるアプローチを取りました。AutoGenでは最初からコードを書き、すべてをオープンソースで開発しました。これにより、初期のユーザーフィードバックを最速で得ることができ、迅速な改善が可能になりました。
これは企業からの採用を遅らせることにはならず、むしろ加速させました。公開後、企業のユースケースや採用事例について大量に学ぶことができました。これは私にとって大きな学びでした。
私も自分の経験を共有させてください。大まかに3つの段階がありました。
最初は PhD学生として、研究を共有しコードを公開することがデフォルトでした。再現性を確保し、影響力を持たせるためです。あまり深く考えていませんでした。おそらく指導教官の高い基準があったからでしょう。研究に基準を設け、再現可能にし、他の人々が研究を検証できるようにすることを望んでいました。これが素朴なデフォルトの時期です。
次にFLOプロジェクトで働き始め、企業での採用や、PhD時代の研究と比べてはるかに多くのユーザーを目にしました。何百万ものダウンロード数があり、この段階では個人的なレベルで、自分の研究が影響力を持っていることを実感しました。人々が実際のユースケースで使用しているのを見るのは、研究者として非常にやりがいがありました。これが個人的な影響力の段階です。
そしてAutoGenの段階では、さらに広い採用と可視性がありました。この段階では、貢献者やユーザーにとってこのオープンソースライブラリが何を意味するのか、より高い視点から考えるようになりました。
オープンソースは本当に健全なエコシステムです。貢献者は自分の研究や貢献を他の人々がアクセスできるようにし、他者の貢献の上に構築することもできます。そしてそれを世界が使えるようにします。
ユーザーレベル、特に企業ユーザーにとって、オープンソースソフトウェアがもたらす重要な要素の1つは透明性と信頼性です。すべてのコードが利用可能で、誰でも見ることができるからです。
また、良いものは世界と共有して、世界全体の利益になるべきだという共有の精神もあります。
企業にとってのもう1つのメリットは、オープンソースは非常に大きく成長し、コミュニティとエコシステム全体を形成できることです。これにより従業員が使いやすくなります。
例えば、多くの人々が既にそのソフトウェアインフラを使用している場合、新入社員を受け入れる際、その会社固有の内部チームのソフトウェアを学ぶのではなく、すぐに使い始めて構築を開始できます。これは非常に健全なエコシステムだと思います。
お二人のオープンソースへの貢献に感謝します。また、AI業界には何か特別なものがあると感じます。現在非常に未成熟な段階だからなのか、あるいは多くの人々が研究やアカデミアから来ているためか、オープンソースがデフォルトであるように感じられ、それは本当に素晴らしいことです。
お二人はその勢いに大きく貢献されました。コードを見て、自分のコンピュータにダウンロードして試し、気に入らない部分を変更したり、気に入った部分を強化したり、そしてその改良を他の人々も利用できるように提案できることは、私にとって新鮮な経験です。
エージェントについて、より実践的な話をしましょう。私のチャンネルを見ている人々の多くはビルダーです。つまり、いじり屋であり、開発者であり、企業で働いていたり、個人でプロジェクトを進めていたりします。彼らはエージェントを使用したいと考えています。
AutoGenやエージェント全般について、お二人が見てきたベストプラクティスをお聞かせください。使用するモデルの種類、エージェントの数、プロンプトやシステムメッセージの詳細さなど、2人のエージェントの専門家から聴衆に向けた、非常に実践的で具体的なベストプラクティスをお願いします。
私から始めましょうか？私の考えは、特に独特なものではないかもしれませんが、プロトタイピングから始めて、1つのタスクのインスタンスが動作するようにすることが本当に良いスタートポイントだと感じています。それは非常にやりがいのある経験であり、異なるアプローチを試すことができ、少なくとも私の経験では、一般的に非常に良いスタートポイントだと思います。
はい、ベストプラクティスは時間とともに進化しています。AutoGenの初期バージョンの時、技術レポートにいくつかのガイドラインを記載しました。
2つのエージェントのシンプルなセットアップから始めることを推奨しています。1つはアシスタントエージェントで、AIに実行してほしいすべての指示をこのエージェントに入れます。もう1つはユーザープロキシと呼ばれるエージェントで、コードの実行など、必要な機能を与えます。このセットアップで実験を始めます。
タスクが十分にシンプルな場合、この2つのエージェントのセットアップで十分うまく機能します。タスクが複雑な場合、単一のモデルベースのエージェントがすべての指示を適切にフォローできない、指示を忘れる、あるいは特定のステップを高品質に実行できないことがわかります。
そのような場合、タスクをより小さな部分に分割し、専門化されたエージェントがよりシンプルなタスクに集中するように考える必要があります。各ステップをより高品質に完了できます。
また、複数のエージェント間のコミュニケーションのトポロジーについても考える必要があります。2つのエージェントの場合は、交互に発言するだけでシンプルです。しかし、2つ以上になると選択肢の数は非常に多くなり、実際には無限になる可能性があります。
例えば、私たち3人が話す順序を考えてみましょう。ABC, ABC…というパターンもあれば、AB, AB, AB, C や AB, BC, ABC など、無限の組み合わせがあります。
そこで、複数のエージェントが自然に協力できる直感的な方法が必要です。私たちはシーケンシャルチャット、Nチャット、グループチャットなど、いくつかの基本的な会話パターンやビルディングブロックを提供しています。
ワークフローにどの程度のコントロールが必要かに応じて、これらを選択したり組み合わせたりすることができます。より柔軟性の高いパターンもあれば、よりコントロール可能なパターンもあります。また、Nチャットのように、あるエージェントの作業を他の作業から分離するのに役立つパターンもあります。
これが2番目のステージかもしれません。モデルやツールの使用に関しては、複数のエージェントがいる場合、異なるモデルを選択したり、異なる設定を与えたり、それぞれに異なるツールを提供したりする自由度が高くなります。
これにより、複数の指標を最適化しやすくなります。通常は品質を最大化したいと考えますが、場合によってはコストやレイテンシーを下げることも必要です。複数のエージェントのセットアップでそれが可能になります。
さらに最近のガイドラインもあります。これらはAG2の新機能に対応するもので、2つの重要な機能に関連しています。1つはキャプテンエージェント、もう1つはスウォームエージェントと呼ばれます。
これらは2つの異なるプラクティスを表しており、ほとんどの場合両方が必要です。キャプテンエージェントは、エージェントとエージェントチームを完全に自動的に作成するパラダイムを表します。
ユーザーはタスクをキャプテンエージェントに提供するだけでよく、キャプテンエージェントがタスクを分析・分解し、プロセスの各ステップに対して異なるエージェントチームを動的に作成します。プロセス全体が自動化され、ユーザーは入力タスクを提供するだけです。
どのようなエージェントが作成されたか、あるいは既存のライブラリから選択されたかを確認することもできます。既存のエージェントやツールを利用することも、必要に応じて新しいものを作成することもできます。
これが1つのパラダイムです。比較的シンプルなタスクではうまく機能しますが、タスクが複雑すぎる場合や、十分なツールやエージェントが提供されていない場合、適切なツールの生成に失敗する可能性があります。
しかし多くの場合、何らかのソリューションの一部を提供してくれます。開発者は提案された内容を確認し、有用な部分を出発点として使用し、不足している部分を追加することができます。それは不足しているツールや、現在キャプテンエージェントが知らない、ドメインエキスパートだけが知っている特定の役割を持つエージェントかもしれません。
開発者はスウォームパターンと組み合わせて、作成されたエージェントを使用することができます。スウォームは、OpenSWAMフレームワークに似た高レベルのプログラミングインターフェースですが、AG2のすべての豊富な機能と組み合わされています。
すべての会話パターンをより直感的でシンプルな方法でプログラムできます。キャプテンエージェントから作成されたエージェントを取り、スウォームパターンで協力させ、異なるエージェントへの引き継ぎ方法や指示について必要な遷移を定義できます。
また、コンテキスト変数を共有したり、より構造化された方法で情報を共有したり、M2の新しい構造化出力機能を活用したりすることもできます。
これら2つの異なる方法は非常に有用で、開発プロセスで組み合わせることができます。これが最新の提案やガイドラインですが、時間とともにさらに多くのことを発見し、共有していくことになるでしょう。
もう1つの非常に一般的なガイドラインとして、人間の組織がどのように問題を解決するかを考えることが有用だと感じています。言語モデルを中程度の知性を持つ人間として扱うことは妥当だと思います。
社会は既に異なる問題へのアプローチ方法を発展させています。例えば、人事の扱いについて、通常企業にはHRチームがあり、おそらく異なる機能を持つより小さな役割があります。人間の組織が行うことを模倣することは、一般的に良いスタートポイントだと思います。
短い補足として、ベストプラクティスについて話しましたが、よく尋ねられるベストプラクティスの1つは「人間をループに入れること」です。人間がループに入るべき適切なタイミングはいつでしょうか？
自分たちのプロジェクトや、他のより複雑な企業レベルのプロジェクトで、どのような経験をされていますか？人間がループに入るべき適切なタイミングとは？複雑さや決定の重要性について、ある種の標準的な定義はありますか？
最初の考えを共有させてください。技術の進歩に応じて、人間の関与の種類は変化する可能性がありますが、はるか先を考えてみましょう。エージェントが能力的に非常に強力になり、私たちが望むほぼすべてのタスクを完了できるようになった場合、それでも人間に必要なことは何でしょうか？
これが最小限の要素となり、次にAIが完璧でない場合、望むレベルの知性に達していない場合に、人間が他に何をすべきかという問題が出てきます。
この質問には2つの部分があります。最初の部分、人間が関与すべき最小限の要素について考えると、いくつかの非常に重要な点があります。
例えば意図、人間からの元々の意図、どのようなタスクを達成したいかということです。これは人間から始まる方が良いと思います。時にはAIが人間の要求なしに積極的に提案を行うような世界も想像できますが、それでも人間は「本当にそれが欲しいのか」という決定を下す必要があります。
初期の要求は本当に人間から始める必要があります。その後、それは1回限りのことではありません。1つの初期の意図を提供してAIにすべてを任せるわけではありません。なぜなら、私たちが望むことを表現する際には自然な曖昧さがあるからです。
私たちは often 短い表現を選びますが、エージェントにとって多くの推測が必要になる可能性があります。したがって、その意図がAIが実行できるように非常に明確になるまで、おそらく数回の反復が必要です。これが人間が関与する必要がある2番目の点です。
3番目は、AIが特定の結果やアクションを返した時、その結果が正確に必要なものでない場合、または人間による検証が必要な場合、人間はその結果を確認し、さらに対処する必要があるものについてフィードバックを提供する必要があります。
4番目は、時として人間がAIエージェントの決定を上書きし、必要な場合には引き継ぐ必要があるということです。
これらが、人間が関与する必要がある4つの基本的な要素だと思います。しかし、AI技術やエージェントの能力の質に応じて、それぞれの度合いは多かれ少なかれ変化する可能性があります。
例えば、AIエージェントが常に最高の品質と満足のいく結果を返すことができれば、フィードバックの部分での関与は少なくて済むかもしれません。これは基本的な分析です。
これを超えて考えるべき興味深いことがいくつかあります。例えば、教育です。AIが私たちが望むすべてのことができるようになる前に、非常に特定のタスクを扱う場合、知識やスキルが不足している場合、ある程度の教育が必要です。
必要な情報や知識を人間が教えることができる教育可能なエージェントを構築することができます。時間とともに反復し、より良くなり、私たちが与えた教訓を使って後続のタスクを実行できるようになりますが、初期には必要な教育のためのやり取りが人間から必要です。
その反対側、学習についても考えてみましょう。エージェントがタスクを実行できる場合でも、人間はどのようにそれを行ったのか興味を持つことがあります。好奇心のためであったり、正しさを確認するためであったりしますが、時には人間自身がスキルを身につけたい場合もあります。
逆に、AIエージェントから有用なスキルを学ぶことができます。これも人間がエージェントと関わり続ける自然な動機になると思います。
この問題について考える時、私は人間が何をするかを模倣することとの関連を考えようとしています。前述のように、私は言語モデルを中程度の知性を持つ人間のようなものとして考えています。
人間をループに入れることについて考える時、おそらく有用なアプローチの1つは、ギャップを探すことです。中程度の知性を持つこのモデルと実際の人間との間のギャップです。
明らかにギャップがある場所がいくつかあります。まず、知性です。地球上で最も知的な人間は、これらのモデルよりもはるかに知的である可能性があり、そのような非常に困難なタスクには、その水準の知性が必要です。
確認のためだけであっても、検証のためだけであっても、その水準の知性は依然として必要です。人類に固有の他のレベルもあるでしょう。例えば倫理です。特にハイテクアプリケーションではセキュリティに関する考慮事項があり、これらのモデルに基づいて開発されたソリューションが正確で、倫理的で、セキュアであることを確保するために、人間をループに入れることを検討すべき場所だと思います。
お二人の話を本当に感謝します。話題を変えさせていただきたいのですが、最近元のAutoGenコードをフォークしてAG2を始められました。その決断に至った経緯について教えていただけますか？
シャンさん、まずあなたから、なぜコードをフォークすることにしたのか、以前の環境で上手くいかないことがあったのか、何をしたかったのか、そしてAG2でどこを目指しているのかについてお聞かせください。
ご質問ありがとうございます。先ほど話したように、AutoGenプロジェクトは最初から、MicrosoftとPenn State University、そして私を含む他の多くの貢献者との共同の取り組みでした。実際に他の大学からも学生が参加していました。
最初、私たちは一緒に、Microsoftの組織の下でコードをリリースすることを決めました。オープンソースでMITライセンスなので、それで問題ないと考えました。実際、1年以上にわたってうまく機能していました。
私や私の学生たち、そして多くの他の学生や協力者たちはMicrosoftの所属ではありませんでしたが、貢献を続け、最初は一緒にうまく働いていました。しかし、プロジェクトが成長するにつれて複雑さが増してきました。
まず、プロジェクトの管理方法に関する複雑さがありました。Microsoftの中には、プロジェクトを特定の方向に進めようとする人々がいて、リーダーシップの関与もありました。大企業では多くの要因がプロジェクトの進行に影響を与えることをご理解いただけると思います。
それが悪いと言っているわけではありませんが、それは現実です。実際にプロジェクトを大きく減速させました。多くの場合、進捗が遅くなっていました。
1秒中断させていただいてもよろしいですか？速度に関して言えば、AG2の新機能についてXで新しい投稿を見ない日はないように感じます。AutoGenとAG2の間で何が変わったにせよ、制約が解かれて、皆さんは非常に速いペースで進んでいます。とても印象的です。申し訳ありません、続けてください。
ご指摘ありがとうございます。はい、それが主な考慮事項の1つです。私たちは速く動きたい、多くの要因に引きずられるのではなく、コミュニティと一緒に前に進む決定を下す自由を持ちたいと考えました。
もう1つの要因は、AutoGenをよりニュートラルな場所で成長させることで、他の人々が貢献しやすくなることです。他の大企業からの多くの貢献者は、Microsoftの下にあるプロジェクトには貢献したくないかもしれません。
これが、すべての組織からの人々がプロジェクトに貢献しやすくしたいと考えた2つの主な理由です。ご指摘の通り、私たちは本当に速いペースで進歩を遂げていることを非常に嬉しく、そして興奮しています。
コミュニティの参加も大きく成長しました。現在、Google、Meta、そしてMicrosoftからも、またIBMや他の小規模企業や大学からも貢献者がいます。コミュニティのエネルギーは本当に素晴らしいものです。
では、AG2を構築されている中で、短期的および長期的な計画は何でしょうか？人々が期待すべき今後の展開について教えてください。
短期的な計画については、おそらく驚きを台無しにしない範囲でお話しできると思います。まず、これはコミュニティ主導のプロジェクトとして維持したいと考えています。
コミュニティからのフィードバックやアドバイス、そして特に重要なのはユーザーからの次に何をすべきかについての意見を常に求めています。これが現在の私たちの原則です。ユースケース主導の開発を行い、ユースケースから必要とされるものを追加し、サポートしようとしています。
シェンが言及したように、最近キャプテンエージェント、スウォームエージェント、ナレッジグラフ、構造化出力など、多くの更新をリリースしました。短期的には、AG2をリアルタイム、特にリアルタイムの音声エージェントなど、リアルタイムユースケースのためのより良いサポートに拡張することを計画しています。これは私が短期的に非常に興奮している部分です。
将来的には明らかに来るであろうものの、まだ実現していないことの1つは、自律的にタスクを達成するエージェントです。現在のエージェントは多くのことを行いますが、「これをしてください」と指示する必要があり、個人情報や企業情報に簡単にアクセスすることはできません。すべてを設定する必要があります。24時間365日、代わりにタスクを達成する、より自律的で積極的なエージェントが登場するのはいつ頃だと思いますか？
良い質問ですね。とても興味深い質問です。個人の時間を大きく節約できるからです。技術的には、私たちは既にそれに非常に近い、あるいは既に近づいていると思います。
1つの難しい部分は、人間とのインタラクションインターフェース、つまりUI/UXです。エージェントに自律的にタスクを完了してもらいたいとは思いますが、適切な認証メカニズムも必要だからです。
例えば、私の気に入らないメールを勝手に送信してほしくはありません。メールの送信を代行してくれるのは素晴らしいですが、重要なメールの場合は最初に私がレビューしたいと思います。
この人間をループに入れるメカニズムが適切に設置され、そのような契約やプロトコルが確立され、よく設計されれば、私たちは非常に近いところにいると思います。おそらく世界のどこかで、誰かが既にこの完全な自律システムを発明しているかもしれません。
マシュー、あなたはどう思いますか？
特定のドメインについては、ジムが言うように、技術的には根本的なブロッカーはないと思います。実行に時間のかかるタスクを見てきましたが、現在のエージェントは実行を継続し、作業が完了すると結果を返すことができます。
あなたが説明したものと唯一異なるのは、ユーザーが初期のリクエストを提供する必要があるという点です。しかし、そのステップも自動化可能なはずです。例えば、別のエージェントがユーザーの役割を果たし、ユーザーが言うであろうことをシミュレートしてリクエストを送信し、残りのエージェントチームに作業を開始させることができます。
コンピュータリソースに制約がなく、料金を気にする必要がなければ、それは実現可能です。しかし、それが実際に運用されていない理由がいくつかあります。
コストの懸念以外にも、品質が保証されていないという問題があります。ユーザーがリクエストを送信する場合、それは明確に達成したいタスクですが、エージェントがユーザーのために行う場合、常に望むことを行うかどうかはわかりません。
1週間はうまく機能するかもしれませんが、翌日に望まないことを行い、望ましくない結果を引き起こす可能性があります。その場合、誰が責任を取るべきかわからない状況になります。
これは自動運転車に似ているかもしれません。技術的には、しばらく前から非常に良い技術を持っていますが、規制要件や責任の所在を明確にする方法など、多くの考慮事項がそれを使用することを妨げています。
しかし、個人が自分自身のためにすべての責任を負うのであれば、潜在的に既にこれを行うことができます。技術的な実現可能性と要件を満たした後でも、私たちは本当にそれを望むのかという疑問が残ります。
私の今後5-10年の展望では、人間からのアイデアに基づいて、最小限の人間の監督で素晴らしい結果を出せる世界に到達できるはずです。しかしその時も、エージェントにタスクを委任したい場合はできるが、自分で行いたい場合や引き継ぎたい場合もできる、ということを保証することが重要だと思います。
その保証がなされる前は、常に「本当に任せてしまって大丈夫なのか」という疑問が残るでしょう。そしてそこに到達した後、もう少し先を考えると、おそらく人々が考えることは、達成したいことそれぞれについて「自分でやるか、エージェントに委任するか」という当たり前の質問になるでしょう。
必ずしもすべてをエージェントにやってもらいたいわけではないと思います。これは興味深い質問ですが、それはおそらく5年後か10年後のことでしょう。
AG2の未来に本当に期待しています。私は何度も言っていますが、「エージェントに強気」という言葉で知られています。エージェントが私の個人アカウントに接続し、本当にタスクを達成できる時を待っています。
シェンが特に言及したように、重要なメールを勝手に書いて送信するのではなく、下書きを作成して私がレビューして送信できるようにすることで、大量の時間を節約できます。そのような未来に非常に期待しています。
本日は時間を割いていただき、私と話をしていただき、本当にありがとうございました。これは魅力的な会話でした。また、オープンソースに貢献し、エージェントフレームワークの波を本当に始めていただいたことに重ねて感謝申し上げます。
これからも多くの興味深いことが起こるでしょう。すべてのリンクを説明文に記載しますが、本日は改めてお話しいただき、ありがとうございました。
はい、マシュー、お招きいただき、ありがとうございました。
ありがとうございました。お話できて本当に良かったです。とても特別な経験でした。
コメント