※本記事は、Stanford CS25: Transformers United V5の講義「The Advent of AGI」の内容を基に作成されています。この講義は2025年4月15日に行われ、動画は https://www.youtube.com/watch?v=nEHNwdrbfGA でご覧いただけます。コースの詳細情報は https://web.stanford.edu/class/cs25/ でご確認いただけます。
登壇者のDiv Garg氏は、AGI Inc.の創業者兼CEOです。AGI Inc.は、AGIを日常生活に持ち込むというミッションを掲げ、AI・人間インタラクションを再定義する新しい応用AI研究所です。Div氏は以前、コンピュータと対話し日常的なタスクを支援できるエージェントを開発する最初のAIエージェントスタートアップであるMultiOnを創業し、シリコンバレーのトップベンチャーキャピタルから資金提供を受けました。Div氏はAI、研究、スタートアップの交差点でキャリアを積んできました。以前はスタンフォード大学で強化学習に焦点を当てたコンピュータサイエンスのPhD学生でしたが、中退しています。彼の研究は、自動運転車、ロボティクス、コンピュータ制御、Minecraft AIエージェントなど、様々な高インパクト領域にまたがっています。詳細は https://divyanshgarg.com/ でご覧いただけます。
本記事では、講義の内容を要約・再構成しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講義動画をご覧いただくことをお勧めいたします。
1. イントロダクションとAGIの概念
1.1 講師紹介とAGI Inc.の設立背景
共同インストラクター： 本日は共同インストラクターのDiv Gargをお迎えしています。Divはエージェントへのインスピレーションを受けたアプローチと、AGIへの道のりがいかに知能の設計、評価、展開方法の再考を必要とするかについて話してくれます。
Div Gargは、AGI Inc.の創業者兼CEOです。AGI Inc.は、AGIを日常生活に持ち込むというミッションを掲げ、AI・人間インタラクションを再定義する新しい応用AI研究所です。Divは以前、Multiconを創業しました。これはコンピュータと対話し日常的なタスクを支援できるエージェントを開発する、最初のAIエージェントスタートアップで、シリコンバレーのトップベンチャーキャピタルから資金提供を受けました。
Divは、AI研究とスタートアップの交差点でキャリアを積んできました。以前はスタンフォード大学でコンピュータサイエンスのPhD学生として、強化学習に焦点を当てていました。彼の研究は、自動運転車、ロボティクス、コンピュータ制御、Minecraft AIエージェントなど、様々な高インパクト領域にまたがっています。それでは彼にバトンタッチします。
Div Garg： ありがとうございます。ここに来られて興奮しています。本日の講義のトピックは、AI界で今起きている多くの新しいことについて話したいと思います。エージェントや登場している新しいモデルに関して、多くの発展がありました。チャットや推論に関しては、平均的な人間と比較して、既にある種の超知能があるように見えます。今後数年間で、知能とは何か、AGIとはどのようなもので、その形態は何か、どうすればこれを有用なものにできるか、そして社会でどのように応用されるかを解明していくのは非常に興味深いことになるでしょう。
最初に触れたいのは、AGIとはどのようなものかということです。AGIは今のところ非常に抽象的な概念です。誰もそれを視覚化したり、意味を与えたりしていません。これは何らかのスーパーコンピュータなのでしょうか。単にChatGPTの10倍優れたものなのでしょうか。それともよりパーソナルなコンパニオンのようなものなのでしょうか。それとも生活に埋め込まれた何かなのでしょうか。それはまだ明確ではありません。これらは私たちが本当に解明する必要がある質問です。
1.2 AGIとは何か - 抽象的概念から具体的形態へ
Div Garg： AGIの概念について、もう少し深く掘り下げていきたいと思います。現時点でAGIは非常に抽象的な概念であり、誰もそれを明確に視覚化したり、具体的な意味を与えたりしていません。これは何らかのスーパーコンピュータのようなものなのでしょうか。それとも単にChatGPTを10倍良くしたようなものなのでしょうか。あるいは、よりパーソナルなコンパニオンとして機能するものなのでしょうか。それとも私たちの生活に埋め込まれた何かなのでしょうか。これらの問いに対する答えはまだ明確ではありません。
しかし、私たちが既に目にしているのは、チャットと推論に関して、平均的な人間と比較したときに、ある種の超知能が既にそこに存在しているということです。今後数年間で、知能とは実際に何を意味するのか、AGIとは具体的にどのようなものなのか、その形態はどうあるべきか、そしてどのようにしてこれを有用なものにできるのか、社会にどのように適用されるのかを解明していくことは、非常に興味深い旅になるでしょう。
これらは私たちが真剣に取り組み、解明していく必要がある根本的な質問です。AGIを抽象的な概念から、具体的で実用的な形態へと移行させることが、今後の重要な課題となります。
1.3 AIエージェントの基本アーキテクチャ（メモリ、ツール、計画、アクション）
Div Garg： それでは、AIエージェントがどのように機能するかを示す1つの図をご紹介します。これはOpenAIの研究者であるLilian Wangによるアーキテクチャです。彼女は最近OpenAIを離れ、新しい会社に参加しました。この図は、エージェントをどのように考えることができるか、そしてそれらがどのように異なるサブパスに分解できるかを示しています。このエージェントを機能させるためには、多くの異なる要素が必要です。
最初の層はメモリです。何らかの短期記憶を持つ必要があります。また、何らかの長期記憶も必要です。これは、ChatGPTのようなものを使用する場合、チャットウィンドウのような短い表現があるということです。また、ユーザーの個人履歴のようなものも持つかもしれません。たとえば、このユーザーが何を好むか、何を好まないかといった情報です。
第2の要素はツールです。人間がツールを使用するように、この種のエージェントがツールを使用できるようにしたいのです。計算機を使用できるようにしたいですし、カレンダー、ウェブ検索、コーディングなども使用できるようにしたいのです。
ここでの第3の部分は、高度な計画を持つことです。これは、エージェントがリフレクションを使用できるようにしたいということを意味します。何かがうまくいかなかった場合、フェイルオーバーメカニズムを持ち、エラーを修正し、回復できるようにしたいのです。自己批判も必要ですし、分解も必要です。思考の連鎖のようなものがあれば、エージェントは独自の推論ループを実行できます。また、複雑なタスクをサブゴールに分解することもできます。
そして最後の第4の要素はアクションです。これらのエージェントがあなたの代理として行動し、物事を実行できるようにしたいのです。これが高レベルで、エージェントが根本的にどのように見えるかをカプセル化したものです。そして、これらのシステムが時間の経過とともにより強力になるにつれて、最終的にはAGIのようなものにつながるでしょう。
2. 実世界でのエージェント応用とデモンストレーション
2.1 カリフォルニア州DMV試験突破の実験
Div Garg： 私たちが現在構築している1つのものについてお話ししたいと思います。私は最近、AGI Inc.という新しいAI研究所を立ち上げました。私たちは、日常的な目的のためのAGIとはどのようなものか、そしてそれを日常生活にどのように適用できるかを深く研究しています。
これは、過去に私たちが構築した技術のデモの1つです。これは、AIエージェントが実世界でどのように適用できるかを示しています。これは少し古いものですが、AIエージェントがカリフォルニア州の実際の運転試験に合格するためにどのように適用できるかを示しています。これは実際のDMV試験で、エージェントが受験したものです。
画面を共有して、このセットアップについて説明させてください。この画面で起こっていることは、誰かがDMVのオンライン試験を受けようとしていて、人間が手をキーボードの上に置いているということです。彼らは実際には画面に触れておらず、エージェントがすべての試験を受けているのです。この試験には40問の質問があり、エージェントは非常に優秀です。エージェントは全体を通過することができ、私たちはこれをライブで実施しました。
DMVは実際に、私たちが行っていることを画面録画していました。彼らはまた、カメラで人物を監視していました。しかし、それでもエージェントは、このスタートアップ全体を回避し、試験に合格することに成功しました。これは本当に楽しかったです。私たちはこれをホワイトハッキングの試みとして実施しました。つまり、その後DMVに通知したのです。
面白いことに、彼らは実際にその後、私たちに運転免許証を送ってきました。それは実際に非常に楽しかったです。最終的に、エージェントはこのテストで合格し、満点を取ることができました。これは、エージェントが実世界でどのように適用できるかを示す非常に楽しい実験です。そして、このようなアプローチで可能なことは非常に多くあります。エージェントをより有用にし、実生活に適用する方法について、です。
2.2 エージェント開発の3つの重点領域（評価、訓練、コミュニケーション）
Div Garg： 私たちは、AI コミュニティの多くの人々と共に、多くの異なる取り組みに取り組んできました。その1つは、エージェント評価です。これらの種類のエージェントを実世界でどのように評価できるか、そして、これらのエージェントが異なるウェブサイトや異なるユースケースでどれだけうまく機能しているかを知ることができる標準とベンチマークを確保する方法についてです。どうすればそれらを信頼できるのか、どこに展開すればよいのか、どのように使用すればよいのかを知る必要があります。
もう1つ私たちが取り組んできたことは、エージェント訓練です。高度な計画と自己修正ができ、自己改善できるエージェントを訓練できるでしょうか。これは、強化学習と他の多くの高度な技術の組み合わせを使用します。
最後に、私たちはエージェント間コミュニケーションについても多く研究してきました。エージェントが他のエージェントとどのようにコミュニケーションできるか、そして最近この分野で多くの新しいブレークスルーがありました。Model Context Protocol（MCP）を見たことがあれば、それは最近登場した非常に新しいものです。同様に、A2A、つまりGoogleのエージェント間通信プロトコルに関する多くの研究があり、これも最近登場しました。
私たちはまた、Agent Protocolと呼ばれるオープンソースプロジェクトにも取り組んできました。これにより、異なる種類のエージェント同士がコミュニケーションできるようにしています。コーディングエージェントがウェブエージェントと話すことができ、それがAPIベースのエージェントと話すことができるといった具合です。これにより、単一のエージェントだけでは不可能な、はるかに複雑なことを実行できるようになります。
2.3 エージェントが必要な理由とSoftware 3.0の構想
Div Garg： これらのことがどのように機能するかについて、より深く掘り下げる前に、なぜエージェントが必要なのか、なぜそれらが有用なのか、なぜ実際にそれらを構築したいのかについて考えたいと思います。ここで考える必要があることはたくさんあります。イントロダクションでは、アーキテクチャの構築、より人間らしいエージェントの構築、コンピュータインタラクションの使用、おそらくメモリやコミュニケーション、そして将来のアクションについてなど、多くの異なるトピックに触れていきます。
エージェントを構築することについて考えるとき、答えなければならない多くの質問があります。最初の質問は、なぜこれが有用なのかということです。実際にどのように構築できるのか。異なる構成要素は何か。そして最後に、それらを使って何ができるのか。
まず「なぜ」という質問に答えるために、私たちには重要な論点があります。それは、エージェントは人間と比較して、デジタル世界やコンピュータとのインターフェースにおいて、より効率的であろうということです。これが、私たちがエージェントを適用して、物事を代わりに実行できるようにしたい理由です。
想像してみてください。完全にデジタルな仮想アシスタントの軍隊があって、彼らがあなたの代わりに何でもできるとします。そして、あなたは人間のインターフェースを使ってそれらと話すだけでよいのです。これが私たちが目指してきたビジョンの一種です。
また、これについてSoftware 3.0と呼ばれるブログ投稿もあります。これらのアイデアのいくつかに触れているので、チェックしてみてください。
さて、私たちがエージェントを構築したい理由は、通常、大規模言語モデルだけでは十分ではないからです。より多くの生産性を解放し、物事を実行できるようにするアクション能力が必要なのです。これにより、より複雑なシステムを構築することもできます。
これを実際に構築するには、多くの技術が関わっています。異なるモデルを連鎖させること、リフレクション、その他多くのメカニズムなどです。先ほどスライド2で示したアーキテクチャにあるように、メモリ、アクション、パーソナライゼーション、インターネットへのアクセスなど、多くの異なるコンポーネントがあります。そして最後に、それらをどのような異なるアプリケーションに適用できるかという質問があります。
3. 人間型エージェント vs APIエージェント
3.1 人間型エージェントの優位性とインターネットへの完全アクセス
Div Garg： なぜ人間のようなエージェントを構築したいのかという疑問もあります。なぜAPIエージェントだけではいけないのか、あるいはなぜ人間のインタラクションを模倣していない他の種類のエージェントを想像できないのか、という質問です。
より人間らしいエージェントを推進したい理由の1つは、これらのエージェントが私たちと同じようにインターフェースを操作できるということです。通常、インターネット、ウェブ、コンピュータは人間のために設計されています。つまり、キーボードとマウスのインタラクションのために設計されているのです。私たちがインターフェースをナビゲートできるように設計されています。キーボードを使用できるように設計されているのです。
もしエージェントが私たちと同じようにインターフェースを使用できるなら、現在のソフトウェアプログラムがどのように機能するかを変更することなく、直接コミュニケーションを取り、多くのことを実行できるようになります。これは非常に効果的です。なぜなら、これによりボトルネックなしにインターネットの100%で作業できるようになるからです。
APIについて考えてみると、インターネット上で公開されてアクセス可能なAPIはわずか5%しかありません。そして、APIを介して完全に信頼できるエージェントを構築することは非常に困難です。したがって、人間のようなエージェント対APIエージェントという間には多くの論争があり、それは今まさに起こっている戦いなのです。
第2に、多くの人間のようなエージェントを、あなたのデジタル拡張として想像することができます。彼らはあなたについて学ぶことができます。あなたについてのコンテキストを持つことができます。あなたがするようにタスクを実行できます。また、制限的な境界も少なくなります。この種の人間のようなエージェントは、ログインを処理でき、支払いを処理でき、API アクセスの制限なしに任意のサービスと対話できます。
つまり、APIを使用するために料金を支払う必要がないのです。サービスプロバイダーに行って、「このAPIへのアクセスを提供してもらえますか」と尋ねる必要もありません。通常行うように、インターフェースを使用するだけでよいのです。
そして最後に、非常にシンプルなアクション空間があります。エージェントは、クリックとタイプの方法を学ぶだけでよいのです。もし彼らが非常に効果的にそれを実行できれば、あらゆる種類のインターフェースに汎化でき、時間の経過とともに改善することもできます。つまり、教えれば教えるほど、与えられるデータが多いほど、ユーザーの記録やフィードバックから学習し、時間の経過とともにより良くなることができるのです。
3.2 APIエージェントとの比較における長所と短所
Div Garg： このAPI対より直接的なコンピュータ制御エージェントについて考えるとき、これらが長所と短所をどのように考えるかということです。
APIエージェントは通常、構築が容易です。より制御可能です。より安全です。しかし、APIはより高い変動性を持っています。つまり、各APIごとに異なるエージェントを構築する必要があり、APIは変更され続ける可能性があります。このエージェントが常に100%機能するという完全な保証は決してありません。
より直接的なインタラクション、コンピュータ制御エージェントに関しては、この場合、アクションを取ることがより簡単です。API境界によって制限されないため、よりフリーフォームなインタラクションです。しかし、保証を提供することも困難です。エージェントが何をするかわからないからです。
ここにいる誰かがOperatorのようなエージェントを使って遊んだことがあれば、それは進行中の作業です。明らかに、それが陥る多くの問題があります。そして、それが今エージェントがいる境界の一種なのです。
3.3 エージェントの自律性レベル（L1-L5）の分類と具体例
Div Garg： エージェントについて考えるとき、異なる自律性のレベルもあります。これは通常、レベル1からレベル5まであります。
レベル1からレベル2は、人間がコントロールしていて、エージェントがコパイロットのように振る舞う場合です。つまり、人間を助けているのです。これは、Cursorのようなコードエディタを使用する場合のようなもので、L2エージェントです。部分的な自動化があり、人間がコントロールしています。人間がコードを指示していますが、エージェントが彼らを助けています。
L3のようなものになると、これは人間のフォールバックメカニズムがまだありますが、エージェントがコントロールしている状態です。これは、Cursor ComposerやWindsurfのような、よりエージェント的な新しいコードエディタを使用する場合のようなものです。エージェントがコードのほとんどを書いていますが、人間が監視してフィードバックを与えています。「これは間違っていました。それを修正してもらえますか？この問題を修正できますか？」といった具合です。これがL3システムのようなものです。
そして、L4とL5のような、より高度なシステムがあります。L4システムでは、人間はループの中にいません。エージェントがすべてを行っています。何らかの自動フォールバック層がまだあるかもしれません。サンフランシスコのWaymoを見ると、それはL4システムです。なぜなら、自動運転車が自分で運転していますが、遠隔で監視している人間のオペレーターがいて、何も問題が起こらないことを確認しているからです。
L5システムを持つ場合、その場合は人間がループの中にいません。監視もありません。そして、AIエージェントは完全に独立して、完全に自律的に自分自身を操作することができます。
4. エージェント評価：Really環境とベンチマーク結果
4.1 インターネットのミニチュア版構築とトップ20ウェブサイトのクローン
Div Garg： これらのエージェントを構築しているとき、1つの難しい問題は信頼です。これらのエージェントが実際に私たちが望むことをしてくれると、どうやって信頼できるのでしょうか。実世界にそれらをどのように展開できるのでしょうか。
この問題を解決するために、私たちが構築してきた1つの取り組みは、インターネットのミニチュアバージョンです。インターネット上のトップ20のウェブサイトをクローンし、これらすべてのインターフェースでエージェントがどのように動作するかをベンチマークしています。これは実際にライブで動作しているので、really.xyzでチェックすることができます。
私たちが行ったのは、AirbnbやAmazon、DoorDash、LinkedInのようなウェブサイトのデジタルクローンを構築したことです。エージェントは、事前定義されたタスクでこれらのインターフェースをナビゲートすることができ、最終スコアを取得できます。
これは、GPT-4Oの評価結果を示しています。私たちは、GPT-4Oがエージェント的である場合、実際にはあまり良くないことを発見しました。このケースでは、わずか14%の成功精度にしか達していません。私たちは、右側に示している11の異なる環境でこれを試しました。他にも何があるでしょうか。そして、私たちには異なる環境があります。Dishという私たちのDoorDashクローンなどがあります。
この環境を実際にチェックすることができます。私たちはまた、そこにある多くのオープンソースフレームワークを比較しました。
4.2 GPT-4Oおよび各種フレームワークの評価結果
Div Garg： 私たちが比較したフレームワークのいくつかは、Operatorを動かしているOpen Computer Useモデルのようなものです。実際に、このタスクに関してはあまり良くないことがわかりました。メール環境やカレンダー環境のようないくつかの環境では最大20%の精度に達することができましたが、他の多くの環境では実際に本当にうまく機能することができませんでした。
私たちはまた、そこにある他の多くのフレームワークも試しました。Stagehandを見たことがあれば、これはウェブエージェントを自動化するためのオープンソースフレームワークです。Browser Useというものもあります。そして私たち自身のカスタムエージェントの1つで、Agent Zeroと呼んでいるものもあります。
私たちが発見したのは、エージェントは実際にこれらの多くのインターフェースを自動化することに関しては、まだ初期段階にあるということです。最大50%の成功率に達することはできますが、実際には多くのエージェントがこれらの実世界のウェブサイトに適用する際に失敗しているのです。
4.3 各種モデルのベンチマーク比較とClaude 3.7の最高性能
Div Garg： 同様に、私たちはすべてのクローズドソースAPIとすべてのオープンソースモデルを含む、利用可能なすべての異なるモデルをベンチマークしました。タスクにおいて、ほとんどのモデルはまずまずうまくいっていますが、今のところ本当に本当に良いものはありません。
私たちが見た最大の成功は、Claude 3.7で、約40%の精度に達することができます。Gemini 2.5と03が非常に近くで追随しています。他のモデルは性能が低下する傾向があります。
私たちにとっての興味深い学びは、これらのモデルの多くは実世界に展開する準備が完全には整っていないということです。なぜなら、Claudeを搭載したエージェントがあるとして、それを適用すると、これが実際にあなたが望むことをしてくれる成功率は41%しか期待できないからです。そしてそれは十分ではありません。
これは、これらのエージェントをさらに良くするために何が必要なのかという疑問を提起します。どうすれば改善できるのか、そして実際の実用的なユースケースにどのように適用できるのか。そして、これが私たちを講義の次のトピックに導きます。それは、どのようにしてAIエージェント的モデルを訓練できるかということです。どうすればこれらのエージェント的タスクにおいてより優れた、カスタム微調整されたモデルを持つことができるのでしょうか。
4.4 実世界展開への準備不足という発見
Div Garg： これらの評価結果から得られた最も重要な発見は、現在のモデルが実世界での展開に完全には準備ができていないということです。Claudeを搭載したエージェントを使用する場合でも、それが実際にあなたが望むことを実行する成功率は41%しか期待できません。これは十分良いとは言えません。
この発見は重要な疑問を提起します。これらのエージェントをさらに良くするために何が必要なのでしょうか。どのように改善できるのでしょうか。そして、実際の実用的なユースケースにどのように適用できるのでしょうか。
これらの疑問が、私たちを講義の次のトピックへと導きます。それは、どのようにしてAIエージェント的モデルを訓練できるかということです。これらのエージェント的タスクにおいてより優れた、よりカスタマイズされ、微調整されたモデルをどのように持つことができるのでしょうか。現状の40%程度の成功率では実用に耐えないため、これを大幅に改善する方法を見つける必要があります。そのための訓練手法とアプローチについて、次に深く掘り下げていきたいと思います。
5. Agent Q：自己改善エージェントシステム
5.1 試行錯誤学習のメカニズムと3つの主要技術
Div Garg： これは私たちの過去の研究の1つで、Agent Qと呼ばれる自己改善エージェントです。Agent Qは、自己改善できるシステムです。修正と計画によって学習することができます。
このシステムがどのように機能するかというと、自己修正することができます。ミスを犯すたびに、そのミスを過去の記憶に保存することができ、人間と同様に多くの試行錯誤学習を行うためにそれを使用することができます。たとえば、初めて自転車に乗ることを学ぶとき、たくさんのミスをし、たくさん転びます。しかし、時間の経過とともに、ポリシーを改善し、それを本当にうまく実行できるようになります。私たちは、これらのエージェントを実世界で本当に本当にうまく機能させるために、同様のメカニズムを適用しています。
このシステムで起こっていることは、エージェントがインターフェースの空間を探索し、何が間違っていたか、何が正しかったかを確認できるということです。そして、強化学習を使用して自己改善し、どんどん良くなることができます。
Agent Qは多くの異なる技術を組み合わせています。第1の手法はモンテカルロ探索です。これは、AlphaGoのような他のRL技術から借用されたもので、タスクの探索空間を計画し、高度な推論を解放することができます。
第2に行うことは、自己批判メカニズムです。エージェントは自己検証を行い、ミスを犯したときにフィードバックを得ることができ、そのフィードバックから学習することができます。
最後に、私たちはRLAIF技術、つまりDPO（Direct Preference Optimization、直接選好最適化）を使用して、RLを使用してエージェントを改善できるようにしています。これら3つの技術すべてを組み合わせることで、非常に強力なシステムを構築することができました。
Agent Qは、研究論文としてarXivでも利用可能です。チェックしてみてください。
5.2 モンテカルロ木探索、自己批判メカニズム、強化学習の統合
Div Garg： 時間の都合上、ここでいくつかの講義をスキップしますが、Agent Qが通常どのように機能するかを説明します。私たちはこのモンテカルロ探索を持っていて、エージェントは異なる状態を探索しています。もしこの状態を訪問したら将来の予測報酬の期待値は何かということを、報酬を推定しています。それに基づいて、予測モデルを改善することができます。つまり、ツリーのこのパスを取るべきか、それとも異なるパスを取るべきかということです。時間の経過とともに、エージェントは正しい状態を探索し、状態空間で正しいパスは何か、間違っているものは何かを見つけ出すことが非常に得意になります。
私たちは自己批判メカニズムも行います。このケースで起こることは、特定のタスクがある場合です。このケースでは、ユーザーが「OpenTableでChiaoのレストラン予約を2024年8月14日午後7時に2人で予約してください」と言ったとします。これが現在の画面の状態で、スクリーンショットを見ることができます。
エージェントはいくつかの異なるアクションを提案できます。日時を選択することができます。また、人数を選択してから日付セレクターを開くこともできます。代わりに、Terra Italyシリコンバレーのレストランを検索し、検索バーにそれを入力することもできます。あるいは、OpenTableのホームページに行くことを決めるかもしれません。
自己批判メカニズムがどのように機能するかというと、これらすべての提案されたアクションが批判ネットワークに渡され、批判的な言語モデルが最良のアクションは何かを予測できます。ランキング順序を与えることができます。これが私たちが使用すべき最良のアクションです。これはランク1です。これはランク2です。これはランク3です。それに基づいて、正しいアクションを取るようにシステムを最適化し、時間の経過とともに改善することができます。
最後に、私たちは人間フィードバックからの強化学習を使用します。ここでは、gRPOやDPOといった異なるアルゴリズムを使用し、これまでに収集したすべての失敗や成功の軌跡を使用して、エージェントを改善することができます。DPOは、失敗と成功の選好データを使用して言語モデルを訓練できる、RLAIFに基づく特別な技術です。それを使用して、モデル全体を改善することができます。
これがAgent Qの動作方法です。私たちはこのモンテカルロ探索を作成して、成功と失敗の軌跡を作成します。次に、自己批判メカニズムを使用して、実際に成功した提案されたアクションと失敗したものを特定できます。そして、それらをDPOに渡して、実際にネットワークを最適化することができます。
5.3 バックトラッキングと自己修正プロセスの詳細
Div Garg： これは、これがどのように機能するかの例です。エージェントは最初の状態から始まります。このケースでのタスクは、OpenTableでレストラン予約をしたいということです。
まず、エージェントはミスを犯してホームページに行きます。その後、ミスを犯したことを認識し、バックトラックすることができます。ここでの青い矢印は、バックトラックしていることを示しています。
次に、正しいレストランにナビゲートすることができます。このケースで、エージェントが誤って間違った日付を選択するというミスを犯した場合、再びバックトラックし、元に戻り、日付セレクターを開き、正しい日付を選択し、座席選択を開き、最終的に予約にたどり着くことができます。
これが、システムが時間の経過とともに学習している方法の一種です。多くのミスを犯していますが、そのミスを保存し、時間の経過とともにそれらを改善しています。
5.4 OpenTable実験での性能向上（62.6%→95.44%）と計算リソース
Div Garg： 私たちは、Agent Qを多くの実世界シナリオで試しました。OpenTableでの実際の予約を含みます。私たちは実際に、OpenTable上で動作する数千、というよりもおそらく10万以上のボットを立ち上げ、レストランを予約し、予約を行い、その他多くのことができるエージェントを作成するために私たちの手法を使用しました。
私たちは、そこにある多くの異なる手法とモデルでこれを試しました。GPT-4Oを試したところ、このOpenTable予約タスクでは約62.6%の精度にしか達することができませんでした。DPOのようなものになると、精度は実際に約71%まで上がります。Agent Qを試すと、これをはるかにうまく機能させることができます。手法の一部としてMCTSなしで81%の精度に達することができます。
そして、MCTSとDPO、自己批判メカニズムを含む完全な技術を適用すると、実際に95.44%の精度に近づくことができます。これは、エージェントが自己学習を使用して自己改善するためです。
これは通常、エージェントがここにある18.6%、つまり約20%の精度から95.4%まで向上するのに1日未満の訓練しかかかりません。つまり、1日未満でエージェントのパフォーマンスが4倍向上したということです。
オンラインから質問があります。「1日間の実行のための計算予算について話していただけますか。8台のH100だったのか、それともクラスターだったのか、あなたが示した結果は？」はい、はい、はい。実際にすべてH100でした。私たちは1日未満で50台のH100上でモデル全体を訓練しました。
6. メモリシステムとパーソナライゼーション
6.1 AIモデルをプロセッサーとして捉える概念とコンテキスト長の進化
Div Garg： 次のトピックとして、メモリとパーソナライゼーションについて触れたいと思います。AIエージェントについて考える1つの方法は、それらが情報を取り込み、処理し、何かを出力しているということです。
モデルが何をしているか想像してみてください。モデルはいくつかのプロンプト、つまりいくつかの言語トークンを取り込み、新しい言語トークンを出力しています。これはプロセッサーと同様に動作しています。CPUがある場合、何が起こるかというと、通常バイナリでエンコードされたいくつかの命令がCPUに入り、同じくバイナリでエンコードされたいくつかの命令が出てきます。そして、それらを何度も何度もループします。これが通常のコンピュータの動作方法です。
非常に似たようなことができ、AIモデルをコンピュータチップと同様に動作する抽象化として持つことができます。プロンプトにエンコードされた言語トークンが入ってきて、言語トークンが出ていきます。これにより、AIモデルを自然言語を操作するプロセッサーとして考えることができます。これは、たとえばGPT-4が行っていることについて考えることができます。
これは、32ビット命令を使用するMIPS 32のような古いプロセッサーと似ています。今、GPT-4を見ると、非常に大きなコンテキスト長に達することができます。これは非常に興味深いことです。GPT-4が最初に登場したとき、それは約8Kトークンに制限されていました。今では32Kトークン、128Kトークン、そして100万トークンがあります。
これらのモデルのコンテキスト長は、時間の経過とともにどんどん増加しています。コンテキスト長が増加するにつれて、それによって私たちができることも増えていきます。
前からの質問があります。「人間と人間の会話でAIエージェントがますます人間の行動を模倣するようになるにつれて、ユーザーがAIと人間を区別するのを助けるために実装されると予想するプロトコルは何ですか？」
Div Garg： これは非常に興味深い質問です。これは、人間なのかエージェントなのかをどうやって識別できるかというセキュリティの問題になると思います。これは実際に今非常に難しい質問です。なぜなら、実際に人間を効果的に模倣し、人間として通用できる音声エージェントがあり、それが今実世界で実際に起こっているからです。
時間の経過とともに、人間の身元証明のようなものが必要になるでしょう。これは生体認証である可能性があります。これはまた、何らかの個人データや、あなただけが知っている何らかのパスワードや秘密の組み合わせである可能性もあります。それを使用して、実際の人間と話していてエージェントではないことを認証できます。
6.2 長期記憶システムの設計と埋め込みベースの検索
Div Garg： メモリについて戻りましょう。先ほどの類推に基づいて、トランスフォーマーモデルがこのプロセッサーとして機能していると考えることができます。入力プロンプトを取り込み、出力プロンプトを出力しています。
私たちがしたいことは、メモリシステムを持つことができるようにすることです。ファイルディスクやRAMのようなもので、何が起こっているかを保存し、時間の経過とともにそれを処理できるようにしたいのです。繰り返しの操作を持ちたいのです。モデルの最初のパスを実行すると、いくつかの出力トークンが得られます。それらをランダムなシステムに保存し、次に新しい命令が出てきます。「さて、これが計画のステップ2です。それを実行してください。これがステップ3です。これがステップ4です」といった具合です。
このループ動作が、ある意味でエージェントを生み出しているものです。トランスフォーマーがプロセッサーであり、メモリシステムと命令と計画がファイルシステムとRAMのように機能していると想像できます。それらが全体として、エージェントがメモリを持つコンピュータシステムのように機能するこのコンピュータアーキテクチャを生み出しています。プロセッサーは計算であり、そしてブラウザやアクション、マルチモダリティを使用できます。これは、オーディオや音声のような入力になり得ます。
長期記憶について考えるとき、先ほどの類推に基づいて、これをディスクのようなものと考えることができます。長期的で永続的なユーザーメモリが必要です。ユーザーについてのコンテキストを保存できるようにしたいのです。必要に応じてそれをオンザフライでロードできるようにしたいのです。
長期記憶には異なるメカニズムがあります。最も一般的なものは埋め込みです。適切なユーザー埋め込みをオンザフライで取得できる検索モデルがあります。たとえば、「このJoeという人はピーナッツアレルギーがありますか？」という質問があった場合、システムはそれを見つけ出すことができます。ユーザーについて多くのユーザーデータがある場合、検索モデルを使用して埋め込みルックアップを行い、これがユーザーについて既に知っていることかどうかを見つけ出し、それに基づいて正しい判断を下すことができます。
これは非常に重要なもので、現在ChatGPTのようなシステムで初期的な痕跡を見ることができます。
長期記憶に関しては、まだ多くの未解決の質問があります。最初のものは階層です。メモリをより図式的な構造に分解する方法はどうでしょうか。時間的永続性を持つことができます。より多くの構造を持つことができます。また、メモリを適応可能なものとして考えたいかもしれません。なぜなら、人間のメモリは通常静的ではないからです。時間の経過とともに変化しています。
そのため、エージェントメモリを持つとき、それをどのように変更できるか、どのように動的にできるか、どのように自己調整できるかについても考えたいのです。なぜなら、システムも学習しているからです。改善しています。この動的メモリシステムはどのようなものなのでしょうか。
6.3 パーソナライゼーションの明示的・暗黙的情報収集
Div Garg： メモリはパーソナライゼーションにつながります。長期記憶を持つことの目標は、これらのエージェントをユーザーにパーソナライズできるということです。彼らはあなたが何を好きで、何を好まないかを理解でき、あなたの好みに合わせることができます。
たとえば、誰かがピーナッツアレルギーを持っているケースがあり、DoorDashで食品を注文するエージェントを持ちたい場合、それがパーソナライズされている必要があるので、誤ってあなたがアレルギーのあるものを注文しないようにしたいのです。どうやってそれを構築できるでしょうか。
誰もが異なる好み、好き嫌いを持っています。エージェントを設計するとき、これを実際に考慮できることを確認することが非常に重要です。
収集できる明示的なパーソナライゼーション情報がたくさんあるかもしれません。ユーザーは何が好きか。何かにアレルギーがあるか。好きな料理は何か。飛行機に乗る場合、どんな座席の好みがあるか、などです。
また、多くの暗黙的な好みもあります。どのブランドが好きかといったことがたくさんあります。AdidasとNikeのどちらが好きか。リストに10個のアイテムがあった場合、たとえば住宅を探しているとして、どれを好むか、そしてその理由は何か。これらのことは非常に暗黙的です。明示的には知られていません。そして、これらの暗黙的な好みの多くを収集し、時間の経過とともにパーソナライズするメカニズムがあります。
このパーソナライゼーションシステムを構築する際には、多くの課題があります。最初のものは、ユーザーのプライバシーと信頼です。実際にどのようにしてこの情報を積極的に収集し、どのようにして人々にそれをあなたに提供してもらうのでしょうか。
6.4 能動的学習と受動的学習によるパーソナライゼーション改善
Div Garg： この情報を実際に収集するために使用できる異なる方法があります。1つは能動的学習です。ここでは、ユーザーに好みを明示的に尋ねています。「何かアレルギーがありますか」とか「座席の好みはありますか」といったことを尋ねています。
また、受動的学習もあるかもしれません。ユーザーを記録し、彼らが何をしているかを見ることができれば、彼らの好みから受動的に学習することができます。たとえば、この人はNikeシューズが好きかもしれません。なぜなら、それがコンピュータ上で彼らがしているのを見たことだからです。エージェントはあなたの行動から学習し、どんどん良くなり、あなたは行動からパーソナライズすることを学ぶことができます。
教師あり微調整によってパーソナライゼーションを学習できます。多くのインタラクションを収集しています。これは人間のフィードバックを通じても可能で、サムズアップやサムズダウンを得ることができ、それを使用して「このエージェントは正しいことをしたか」を改善できます。
これは、ChatGPTと似たようなものです。チャットの出力が好きな場合、サムズアップを与えることができます。好きでない場合は、サムズダウンを与えます。そして、これを使用して時間の経過とともにシステムをパーソナライズすることができます。
7. マルチエージェントシステムと通信プロトコル
7.1 エージェント間コミュニケーションの必要性と課題
Div Garg： それでは、エージェント間コミュニケーションに移りましょう。
オンラインから質問があります。「人間と協力するエージェントのパフォーマンスについて、どのように評価を行いますか。それは変動する目標ですか。どの時点で人間のパフォーマンスは冗長になり、エージェントが完全に自律的になれるのでしょうか」
Div Garg： これは難しい質問だと思います。ベンチマークを構築するしかありません。実世界で何が起こるかを知ることは非常に難しいからです。今のところ、現在の評価状態や先ほど示したものに基づいて言えることは、エージェントは完全にはそこに到達していないということです。
これまでに見た最も成功しているエージェントは、コーディングエージェントです。インテリジェントなコードエディタのようなものがあれば、既に多くのエンジニアリングを自動化している痕跡を見ることができます。多くの定型コードを書く必要がなくなっていますし、バグを修正するために自分の時間を多く費やす必要もありません。
ある時点で、人間がよりマネージャーのようになり、フィードバックを与え、方向性を与える状況が見られるでしょう。「エージェント1にはこれをやってもらいたい、エージェント2にはこれをやってもらいたい」といったように、異なるエージェントのシステムがあるとします。最終的な出力を見て、それを使用して全体的な生成プロセスを改善していきます。
おそらく起こることは、エージェントシステムがより良い実行者になり、人間がエージェントシステムのマネージャーになるということです。
Div Garg： さて、エージェント間コミュニケーションについて考えるとき、マルチエージェントアーキテクチャとマルチエージェントシステムについて考えます。これらすべてのかわいい小さなデジタルロボットがいて、お互いに話し合い、コミュニケーションを取り、非常に協調的で合理化された方法であなたの仕事をすることができます。
会場から質問があります。「AIエージェントがますます人間の行動を模倣するようになるにつれて、会話でAIと人間を区別するために実装されると予想するプロトコルについて話していただけますか」
Div Garg： はい、それは非常に興味深いです。これはセキュリティの問題になると思います。人間なのかエージェントなのかをどのように識別できるかということです。これは実際に今非常に難しい質問です。なぜなら、実際に人間を効果的に模倣し、人間として通用できる音声エージェントがあるからです。そしてそれは今実世界で実際に起こっています。
時間の経過とともに、人間の身元証明のようなものが必要になるでしょう。これは生体認証である可能性があります。これはまた、何らかの個人データや、あなただけが知っている何らかのパスワードや秘密の組み合わせである可能性もあります。それを使用して、実際の人間と話していてエージェントではないことを認証できます。
他に質問はありますか。
聴衆（バークレーの教授）： バークレーが論文を発表したのを知っていますか。5人の教授と学生が「なぜマルチエージェントシステムは失敗するのか」について包括的な研究を行いました。まず第一に、彼らはマルチエージェントシステムは20年以上前からあると言っています。分散システム、トランザクション処理があります。私たちは単にAIを同じ名前で覆っているだけです。
これまでのところ、プログラムのすべてのロジックをコーディングするAPIの代わりにエージェントを持つこと以外に、本当に新しいものは見ていません。プロンプトを与えれば、何らかの結果が得られます。では、エージェントを一緒に置くだけで知性が突然向上するのでしょうか。
エージェント間のコミュニケーションは、私の考えでは、20年前のマルチエージェントシステムとまったく同じです。エージェント間のコラボレーションは知性への手段にすぎませんが、今日の講義でその部分が欠けていると感じています。
Div Garg： これは実際に次に来るものです。しかし、あなたの質問に答えるために、詳しく説明しましょう。最大の問題は、これらすべてのエージェントが自然言語を使用してコミュニケーションしているとき、多くの誤解が生じるということです。エージェントが間違った指示を受け取ったり、何が起こっているのか理解できなかったりする可能性があります。そして、エージェントが増えれば増えるほど、より多くのコミュニケーションオーバーヘッドがあります。
n個の異なるエージェントを持つエージェントシステムがあると想像してください。すると、n²の通信ループがあります。したがって、そのシステム内のエラーの量は二次関数的に増加し、それによって多くの異なるミスが発生する可能性があります。
聴衆： 私が提案しているのは、その本のすべての問題がほぼすべて13章で解決されているということです。
Div Garg： 素晴らしいですね。はい、まったくその通りです。それはここにいる聴衆にとっても非常に興味深いかもしれません。
7.2 並列化と専門化によるシステム効率化
Div Garg： それでは、これに戻りましょう。マルチエージェントシステムを構築したい理由があります。最初の理由は並列化です。タスクをより小さなチャンクに分割し、1つのエージェントではなくn個のエージェントを持つことで、全体的な速度と効率を向上させることができます。
第2の理由は専門化です。異なる専門的なエージェントを持つことができます。たとえば、スプレッドシートエージェント、Slackエージェント、ウェブブラウザエージェントがあるとします。そうすれば、異なるタスクを異なるエージェントにルーティングすることもできます。各エージェントは、そのタスクで本当に本当に優れることができます。これは、特定の専攻の学位を持つことや、その職業に特化した職業を持つことと似ています。
7.3 情報損失問題と階層構造の設計
Div Garg： エージェント間コミュニケーションに関しては、多くの課題があります。最大のものは、この種のコミュニケーションが情報損失を伴うということです。
1つのエージェントが別のエージェントとコミュニケーションを取っているとき、ミスを犯す可能性があります。これは人間の組織で起こることと似ています。マネージャーがあなたに何かをするように頼むかもしれませんが、おそらく誤解して何か違うことをしたかもしれません。または、彼らは「なぜこれが起こったのか」と言うかもしれません。同様に、エージェント間コミュニケーションも根本的に情報損失を伴います。あるエージェントから別のエージェントに情報を伝達するたびに、その情報の一定の割合を失っています。それによって、ミスがそのシステム内で伝播し、ますます広まることになります。
マルチエージェントシステムには異なるメカニズムがあります。これは今非常に新しい分野です。人々はまだこれを解明しようとしています。今のところ、誰も実際にこれを解決していません。
やりたいことは、適切な階層システムを構築することです。ワーカーエージェントと協力しているマネージャーエージェントがいるかもしれません。マネージャーのマネージャーエージェントがいるかもしれません。フラットなエージェント組織があるかもしれません。たとえば、1人のマネージャーが数百のエージェントを管理しているような場合です。あるいは、大きな垂直ツリーのようなものかもしれません。たとえば、お互いを管理している10の異なるエージェント階層があるような場合です。
これらのシステムのすべてが可能であり、これはタスクや専門化しているものに依存します。
このような種類のシステムで最大の課題は、その情報を失うことなく効果的にコミュニケーションをどのように交換するかということです。同期プリミティブをどのように構築するかということです。階層内で別のエージェントから非常に離れたエージェントからのコミュニケーションを、チェーン全体で非常に効果的にコミュニケーションするにはどうすればよいでしょうか。
7.4 Model Context Protocol (MCP)とAgent-to-Agent Protocol
Div Garg： これらのコミュニケーションプロトコルをどのように堅牢にするか、この誤解を減らすためのメカニズムをどのように構築できるかという問題を解決しようとしている、いくつかのフレームワークがあります。
この分野での大きなものの1つは、MCPです。これはModel Context Protocolです。これはAnthropicから来たプロトコルで、今多くの人が使用しています。これは、API周りのシンプルなラッパーです。
これが何をするかというと、各APIに対して合理化された標準フォーマットを提供します。あなたのサービスのためにMCPラッパーを作成することで、これはおそらくファイルサーバーサービスのようなもので、APIを公開しています。ファイルサーバーのためのMCPラッパーを作成できますし、メールクライアント、Slackクライアント、コンピュータ上で動作している何かのためにも作成できます。
そうすれば、これらすべてのMCP接続サーバーがお互いにコミュニケーションを取り、あなたのために物事を実行できるようになります。これにより、ルーティングを制御でき、システムをモジュラーにできる、非常に効果的なコミュニケーションが可能になります。必要に応じて新しいサービスをプラグインできるようになります。
同様に、この分野の別のフレームワークはAgent-to-Agent Protocolです。これはGoogleから最近出てきた新しいプロトコルで、エージェントが他のエージェントを共同で呼び出すことを可能にし、多くの信頼性とフォールバックメカニズムを追加します。
ここにいる部屋の人の中で、何人がMCPを使用したことがありますか。なるほど。はい、多くはないですね。
MCPは実際に非常にクールです。彼らが行っていることは、APIを抽象化し、非常に非常にモジュラーにすることです。これにより、APIをプラグインしてMCPプロトコルにラップすることができます。一度それがラップされると、MCPによってサポートされている他のサービスに接続し、相互接続させることができます。
ある意味で、異なるサービスやアプリケーションのための標準インターフェースを持つようになります。それらを公開し、相互に接続して会話させることができます。
通常のインターネット上でのコミュニケーションのためにHTTPSのようなものがあるのと同様に、MCPは異なるエージェント間でコミュニケーションが起こるための興味深いプロトコルになります。
ClaudeやRepletのようなクライアント、または他のモデルがある場合、MCPプロトコルをサポートしているサーバーに接続できます。データベースAPI、データツール、その他何でもかまいません。それらはすべて相互接続でき、モジュラーなことを実行できます。
MCPはAPIの仕様に依存していないため、多くの変更を吸収し、このレベルのモジュラー性と抽象化を追加することができます。インターフェース全体を標準化することによってです。
また、動的なツール発見も可能です。何らかのディレクトリに公開されているさまざまなMCPサーバーを見つけることができるからです。そして、好きなMCPサーバーをプラグインして接続することもできます。新しいツールをプラグインして試すことができ、やりたいことに基づいて情報をルーティングできます。
8. エージェント実装の課題と将来展望
8.1 信頼性、ループ問題、監視の必要性
Div Garg： 最後に、エージェントの実装に関するいくつかの問題について触れたいと思います。これまで、多くの異なることを見てきました。これらのエージェントはどのように機能するのか。どのように評価できるのか。どのように訓練できるのか。どのように異なるエージェントシステムとコミュニケーションできるのか。
多くのことが非常に興味深く、多くのことが離陸しつつありますが、エージェントが実用的であり、日常生活に適用され、有用になるために、私たちがまだ解決しなければならない空間における多くの重要な問題が残っています。
最大のものは信頼性です。システムは非常に非常に信頼性が高くなければなりません。たとえば、支払いや銀行の詳細へのアクセスを与える場合、99.9%信頼できる必要があります。あるいは、メール、カレンダー、その他のサービスに接続されているかもしれません。そして、それらを本当に信頼したいのです。システムが暴走して、たとえばソーシャルメディア、TwitterやLinkedInに間違った投稿をしたり、混乱を引き起こしたり、代わりに間違った取引をしたりすることを望みません。
そこで、自律的に動作しているエージェントシステムをどのように信頼できるかということが問題になります。それが信頼性が大きな問題になる理由です。
自律エージェントの第2の問題はループです。これらのエージェントは何か間違ったことをする可能性があります。ループに陥る可能性があります。そして、そのプロセスを何度も何度も繰り返すかもしれません。タスクを与えて、先ほど示したレストラン予約タスクのようなものを思い出してください。エージェントが間違ったレストランに行き、そこで立ち往生し、同じことを何度も何度もやろうとしているかもしれません。何をすべきかわかりません。
この種の問題は多くのエージェントで発生する可能性があり、計算に多くのお金を無駄にすることになるかもしれません。それを把握して修正できることが非常に重要です。
これは、実世界の多くの異なるユースケースでエージェントをどのようにテストできるか、どのように適切にベンチマークできるか、そしてそれから学習していることを確認する方法に関する多くのユースケースにつながります。また、これらのシステムを展開した後、どのように観察できるかということもあります。何が起こっているかをどのように知ることができるでしょうか。オンラインで監視できますか。
何らかの安全性を持つことができます。これは、このエージェントがこれまでに行ったすべての操作を監査できる監査証跡に基づくものかもしれません。また、何か問題が発生した場合に人間によるオーバーライドを持つこともできます。遠隔オペレーターがエージェントの制御を引き継いで修正したり、修正したりできる何らかの人間のフォールバックがあるかもしれません。あるいは、正しく制御を引き継いで修正できるかもしれません。
これはTeslaのオートパイロットに似ています。オートパイロットで運転しているとき、何か間違ったことをしそうだと見えたら、制御を引き継いでシステムをオーバーライドできます。
エージェントの実世界での展開について考えるとき、これは非常に興味深くなります。
8.2 99.9%精度への道筋と強化学習による改善可能性
Div Garg： さて、これがエージェントに関する講義全体でした。すみません、少し混乱した部分がありました。最後のスライドをまとめなければなりませんでした。質問を受け付けます。どうぞ。
聴衆： タスクにおいて、1日の間に40%のような精度が見られる場合、99%や99.999%に到達するための計画があると思いますか。そして、それは単に研究の反復なのか、それとも実際に試す必要があることなのか、考えはありますか。
Div Garg： これは間違いなく可能です。特に強化学習を使えば、先ほど示したAgent Qの方法を使えばです。今、Claude SonnetやGPT-4、GPT-4O、Geminiのようなモデルを持っていても、これらのエージェント的インターフェースタスクでは訓練されていません。つまり、ゼロショットで動作しているのです。これらの新しいインターフェースやこの種の実世界のタスクに遭遇したとき、これらの問題を最適化することについて、訓練データセットの分布内で訓練されたことがありません。
そのため、彼らはしばしば失敗します。しかし、強化学習を使用してこれらのタスクで直接動作するようにシステムを訓練でき、収集や自己改善のようなことができれば、実際に非常に高い精度に到達できます。
OpenTableタスクでのAgent Qでは、95%の精度に達しました。そして、システムを訓練し続けると、完全に飽和させて99.9%に近づけることができます。難しいことは、タスクの多様性があるということです。数百万のウェブサイトがあると想像できます。各ウェブサイトで99.9%を使用するエージェントを作成したい場合、それは難しい課題です。
そして、それは非常に興味深いことだと思います。インターネット全体で動作できる汎用エージェントをどのように構築できるか。すべてに汎化できるか。将来的には、すべての音声通話を自動化し、すべてのコンピュータ制御、すべてのAPIとすべてを使用できるエージェントを持つことができるかもしれません。そのようなことは理論的には可能です。ただ構築するのが非常に難しいだけです。
8.3 汎用エージェント構築の課題とドメイン特化の重要性
聴衆： AIエージェントがCAPTCHAを解決できるかどうか知っていますか。
Div Garg： できます。
聴衆： 今後10年間でインターネットがどのように機能するかについて、その影響は何だと思いますか。
Div Garg： それは間違いなく非常に興味深いです。イタチごっこのゲームになると思います。新世代のCAPTCHAを見ると、それらはますます解決が困難になっています。これを打ち負かすことは非常に難しいと思います。なぜなら、人間ができることなら、理論的にはエージェントも同じことができるからです。
時間の経過とともに、より良い本人確認方法を見つけ出す必要があると思います。生体認証はその大きな部分になる可能性があります。指紋や何らかの二要素認証メカニズムを使用できれば、これが実際の人間でありエージェントではないことがわかります。
聴衆： おそらく聞いたことがあると思いますが、AI 2027という記事があります。これはAI研究がどこに向かうのか、何が起こるかもしれないかを概説していて、2027年以降、プログラミングを自動化し、AI研究を自動化します。
あなたの講義の後で疑問に思ったのですが、AIエージェントを作成するプロセスを自動化できると思いますか。私の理解では、主なボトルネックは、UIやAPIにどのようにアクセスするか、これらの複雑でやや動的なシステムに囲まれたデータにどうアクセスできるかということです。
では、もし非常に単純に、誰かがAPIとUIをベクトル化するために最適化されたエージェントを設計し、そして異なるベクトル化されたデータセットでエージェントを訓練するために最適化されたエージェントを設計したら、どうでしょうか。なぜなら、エージェントを訓練するために使用できる特定のアーキテクチャがあるからです。
将来、人々がAIエージェントを作成するプロセスを確信を持って自動化し、市場で見られるこれらすべてのニッチで特定のAIエージェントを時代遅れにすることが見られると思いますか。
Div Garg： はい、絶対にそう思います。これは起こりうることで、すでに大きな研究所で起こっていると思います。OpenAIのような研究所を持っている場合、多くの研究エージェントがいます。Sakana AIの論文を見たことがあれば、人々はAI研究エージェントに取り組んでいます。これらは研究論文を書き、モデルを訓練し、多くのことを実行できます。
エージェントが自己改善し、他のエージェントを構築することは完全に可能です。それがどのように起こるかについての全体的なプロセスを持つことができます。間違いなく、これらのデータソースやAPIの多くで訓練し、それらを表現する方法を見つけ、適切なデータセットを収集して改善する方法を見つけることは可能です。
多くの困難な研究、特にタンパク質設計や多くの困難な科学の分野で、それが起こる未来だと思います。間違いなく多くのことが起こるでしょう。
8.4 Q&Aセッション：小型vs大型モデル、メモリ実装、エージェント作成の自動化
聴衆： こんにちは、Div。また会えて嬉しいです。コンテキストを提供すると、私たちはAIエージェントのためのSlackのようなものを構築しています。基本的に、AIエージェントのためのUberのようなものです。私は長い間エージェントに取り組んできました。エージェントの最大の問題は、あなたが言ったように、信頼性と幻覚です。
最初に取り組んだことは、エージェントが幻覚を起こすのをどのように防ぐかということです。次は、どのモデルがアクションの実行に最適かということです。私の研究では、Claudeは素晴らしいことがわかりました。さらに良いのは、最後にGPTエージェントを持つことです。Slackのようにエージェントのチームがあり、仕事をします。アクションを実行するエージェントは、あなたが言ったようにGPT-4Oが優れているようです。他のモデルとGPTは、あまりうまく機能しないようです。Claudeや他のものは。
私が思うに、エージェントを構築する上での最大の課題は、第3に、エンドユーザーは1回のミスも許容できないということです。だから私の妻はここにいて、私が彼女に製品をテストしてもらって1回ミスをしたら、強化学習の余地はありません。たとえば、昨日Manosにフライトを予約するように言って1回ミスをしたら、信頼を失いました。
問題は、実世界で機能するために、私たちのエージェントは実世界でミスをしないようにする必要があるということです。それがサンドボックスにつながります。あなたがサンドボックスで行っていることは大好きで、これらのウェブサイトのクローンを作成しています。サンドボックスの課題は、インターネット上のすべてのウェブサイトをクローンできないということです。そして、人間が優れているのは、新しいタスクを与えられたときに、自分の道を見つけ出すことです。
これらはエージェントが抱える課題であり、もしあなたがそれについてもっと話せるか、後で話すことができれば嬉しいです。
Div Garg： 完全に、完全に、要点だけを理解させてください。正確な質問は何ですか。
聴衆： 質問は、どうやって実世界に対応させるかということだと思います。Vodiは通話で良い仕事をしますが、ミスをします。私自身のメールエージェントがあり、ループで停止し、投資家に5回メールを送り続けました。コーディングエージェントがあり、昨日3,000行のコードを消去しました。やり直さなければなりませんでした。
実世界でこれらの課題があり、私の妻のような人々は1回のミスも許容しません。そして、彼らは使用を止めてしまいます。だから、質問は、エージェントが幻覚を起こさないようにする方法だと思います。
Div Garg： それは間違いなく難しい問題で、エージェントを改善し続けることができます。最初に出てきた多くのモデル、たとえばGPT-3や他のものの最初のバージョンを見ると、それらは非常に多く幻覚を起こしました。しかし、より大きなモデル、より多くのパラメータサイズを持ち、より多くのデータで訓練すると、幻覚を起こし始めることが少なくなります。
新世代のモデルGPT-4やClaudeを見ると、時間の経過とともに、より良い基盤モデルを作る方法を見つけ出すにつれて、システム内のこれらのエラーの多くが減少していくと思います。特に幻覚やその他発生する可能性のあることです。多くの監視と評価とテストが必要です。
これもまた非常にドメイン特化的になります。ドメイン特化的な問題に取り組んでいて、このドメインで99.9%機能するエージェントが欲しい場合、やりたいことは、適切なテストケースを整理することです。「ここに本当に重要な1,000のシナリオがあります。これらのエージェントをこの1,000のシナリオでずっとテストできますか」と言えます。これは本番環境でユーザーと実際に実行しているときかもしれませんし、何らかのオフラインシミュレーションかもしれません。日々テストしているのです。システムに何か回帰はありますか。プロンプトを変更したら何が起こりますか。これはどのように見えますか。
非常に堅牢なテストを構築できれば、精度が上がっていることも検証できます。そして、このエージェントを微調整してユースケースでどんどん良くできるかどうかという問題になります。
正しい答えは、時間の経過とともにモデルがどんどん良くなり、単により信頼できるようになるという組み合わせだと思います。新しいモデルが出てくるにつれてです。第2に、自分のユースケースに対して非常にドメイン特化的なテストと評価を持ちたいということです。どのモデルが何をしているかをランク付けする何らかの方法がありますか。どれくらい良いですか。そして、正しい判断をし、微調整を行い、強化学習や他の技術を使用して時間の経過とともにより良くすることができます。
聴衆： 小さいことですが、より大きな頭脳が必要だとは思いません。小さな言語モデルが必要だと思います。質問は、エージェント専用の小型言語モデル対大型言語モデルについてどう思うかということです。
Div Garg： それは興味深い質問です。実際、私たちはすでにいくつかのヒントを見ています。多くの新しいモデルを見ると、それらは推論トレースで訓練されています。推論トレースで小型モデルを訓練し、より良い精度を持つことができることがわかりました。
多くの新しいGPT-4モデル、GPT-4Oやすべての新しいO3 miniシリーズのようなものは、実際には蒸留された小型モデルですが、推論で非常に優れるように強化学習と技術を使用して微調整されているだけです。登場しているすべての新世代の思考モデルやO1とO3シリーズで既にそれを見ています。
より良い推論、より良い処理を持つ小型モデルが実際に正しい答えであることを示しています。限界をどこまで押し進められるかを見るのは興味深いでしょう。これはどのようなものになるでしょうか。たとえば、この年の間に、この種の推論から期待できる最高の精度は何でしょうか。数学で博士レベルに実際になれますか。多くの特定のドメインで超知能のようなものになれますか。
聴衆： リトマス試験は現実世界だと思います。私が思うアーキテクチャは、マネージャーエージェントは大型言語モデルで、ワーカーエージェントは小型言語モデルになる可能性があるということです。チームのように協力しているときに蒸留が起こっていると思うからです。
最後の質問はメモリについてです。コンピュータとの類似で与えた例で、ランダムアクセスメモリがあり、ROMがあり、ハードドライブがあります。今のAIエージェントは、ランダムアクセスメモリしか持っていないと思います。Memory Zeroで、私たちは単にROMを与えているだけです。ハードドライブと意識、仕事をしている間の意識を持っていないと思います。それが課題だと思います。どのようにしてコンピュータのようなその種のシステムを実装するかを知りたいです。
Div Garg： それもまた興味深い質問です。実際に試して実験してみて、それがどのように機能するかを見ることに興味があります。これに対する直接的な答えはないと思います。何を構築しているか、アプリケーションが何かに依存します。
そして、あなたが行っていることに応じて、異なるサイズのモデルがより良く機能する可能性があります。コーディングタスクを行っている場合、よりコーディングモデルのようなものが必要かもしれません。よりチャットベースのものやアクションなどを行っている場合とは対照的にです。適切な要素、ある意味で適切なコンポーネントをアプリケーションに見つけて構築する必要があると思います。
ある意味で、正しい答えはありません。
