14,101 文字
私は、私たちが説明してきたすべてのユースケースにおいて、すべてのエージェントに共通する要素が一つあると感じています。それは推論と決断です。実際には、決定木を持つ複数ステップのLMチェーンのようなものだと思います。動的な決定木ですね。そうですね、それは妥当だと思います。
私たちはみな、単にオタク的な議論に巻き込まれているだけだと思います。私たちはコンピューターサイエンティストなので、ビットが単に0か1ではなく、その中間のようなものである場合に対処するのが苦手なのです。だから私たちは、それを一方の値に変換しようとするまで、ただ多くを語り合うのです。
AIエージェントとは何かについては、意見の相違が多くあります。技術的な面だけでなく、マーケティングや販売の面でも様々な定義を耳にしてきました。それは一部、関連する販売モデルがあるからでもあります。
では、技術的な側面から始めましょう。ここには連続体があります。私が聞いたエージェントの最も単純な定義は、基本的に何らかの知識ベースやコンテキストの上に賢いプロンプトを置いただけのもので、チャット型のインターフェースを持つものです。ユーザーの視点から見ると、これは人間のエージェントのように見えます。例えば、「製品XYZについて技術的な問題があります」と尋ねると、知識ベースを参照して定型的な回答を返してきます。
しかし、知識ベースである必要はありません。そうですね、理解しました。おそらく単にトレーニングされたモデルであり、その知識はすべてモデルの重みにあるのです。つまり、さらに単純です。ある定義によれば、エージェントは単にチャットインターフェースを持つLLMであるかもしれません。
一方、スペクトルの反対側では、実際のエージェントであるためには、AGIに近いものでなければならないと考える人々もいます。長期間にわたって持続し、学習する能力があり、知識ベースを持ち、問題に独立して取り組む必要があるというものです。
最も広範な定義を取れば、現時点ではそれが機能していないと言えるでしょうか？そう思います。まだ機能していません。しかし、それは哲学的な問題です。
その連続体の間を取ると、エージェント的な行動の程度や異なる種類のエージェントについて、いくつかのカテゴリーに分けることができます。アーティストが新しいベジェ曲線を考え出すのを助けるアート系エージェントもあれば、私たちが今日のエージェントとして話すことの多いコーディングエージェントもあります。LLMの上に単にラッパーを置いただけのエージェントもあります。
私はこのグループの中で異論を唱えるかもしれませんが、エージェントはAIアプリケーションのための単なる言葉だと思います。AIを使用するものは何でもエージェントになり得ます。この会話を始める前に、オンラインでAIエージェントについての興味深い見解を確認しました。Karpathyが数年前に行ったエージェントについての素晴らしい講演を見つけました。でも面白いのは、次に見るべきYouTubeのおすすめ動画が「AIエージェントがあなたのライフスタイルを革命的に変える」とか「超知能AIの台頭」といったマーケティング的なものばかりだったことです。
私が見た最もクリアなエージェントの定義は、複雑な計画を立て、外部システムと相互作用するものというものでした。問題は、現在のLLMは両方を行うので、その定義だと線引きが非常に曖昧になることです。彼らは多くの場合、計画を組み込んでおり、少なくともインターネットから、あるいはMCPなどのプロトコルを通じて情報を公開するサーバーから情報を消費しています。
Karpathyの講演で興味深かったのは、彼が自律走行車に関連付けて、AIエージェントは実在する問題だが、それは10年単位の問題であり、取り組む必要があるものだと述べていたことです。現在市場で見ているほとんどのものは、この問題の10年バージョンではなく、週末デモバージョンなのです。これが混乱を生み出す理由です。
エージェントという言葉自体が曖昧で過負荷な用語かもしれませんが、誰かが人間のデジタル形式について正確に定義する困難な作業を行い、それを実際に機能させるために10年を費やすなら、それは見てみたいですね。
会話の一部として「エージェント」を再定義することが重要かもしれません。私たちはみな、それが様々な人々に様々なことを意味する良くない用語だと知っています。異なる人々がエージェントと言うとき何を意味するのか、エージェントと呼ばれるこのプロセスをどのように利用できるかを分析することは興味深いでしょう。
エージェントあるいはエージェント的行動の程度を定義しようとするなら、ユーザーインターフェースの側面があります。ユーザーがLMと特定のタスクで行き来するだけの純粋なコパイロットは、通常エージェントとは呼ばれません。そう言えますか？つまり、コパイロットとエージェントのUIモデルには少し違いがあります。
エージェント的行動に入る要素は何だと思いますか？Mattが言及したように、計画が一つかもしれません。エージェントによる決定があるかもしれません。どこかにLLMがなければなりません。
最近Anthropicから聞いた別の定義は、エージェントはツール使用とループで実行されるLLMであるというものです。重要なのは、単一のプロンプトだけではなく、プロンプトの静的なシーケンスでもないということです。LLMがプロンプトの出力を取り、それを自分自身に戻し、それに基づいて次のプロンプトを決定し、おそらくタスクを中止するタイミングも決定するものです。本物のエージェントやより高度なエージェント的行動にとって、これはかなり良い定義だと思います。
しかし、その定義だと、すべてのチャットボットが実質的にエージェントになってしまいませんか？例えば、ChatGPTのサイトに行き、Web検索付きの最新の推論モデルを使用した場合、それはツールを使用し、新しいプロンプトに出力をフィードしてチェーンオブソート推論を行っているのではないでしょうか？
思考の連鎖は少し中間的なものです。単一のプロンプトで結果が返ってくるだけなら、計画や長期的な概念を持ち、自分で完了したかどうかを決定するという概念はないでしょう。複雑なタスクを与えられて思考の連鎖推論を行うなら、それは始まりつつあります。
入力に基づいてシステムを定義するのは本当に難しいと思います。これらのシステムはデザイン上、非構造化入力を受け入れ、文字通り何でも受け付けます。「今日の天気は？」と尋ねるなら、それはエージェント的ではなく、単にAPIからのフェッチのようなものです。しかし「天気の新しい哲学を定義して」と尋ねれば、喜んでそれを行います。つまり、あることを尋ねればエージェントであり、別のことを尋ねればエージェントではないのです。これが市場での混乱の多くを引き起こしていると思います。
「ループ内のLLMとツール」という言葉で話すなら、それは実際にはより生産的な話し方だと思います。
それでも、ユーザーインターフェースの専門化が2つの方向に見られます。一つはカーソルのようなもので、ユーザーとLMとの間の緊密なフィードバックループを強調し、何かをするとすぐに満足を得たいというものです。応答時間が重要です。もう一つは、バックエンドのようなもので、ソースコード管理システムのようなプラグインがあり、何かを「壁を越えて」投げ、数問に答えてから、エージェントが独立して作業できる時間を最大化しようとするものです。
システム定義の明確な分割はないかもしれませんが、ユーザーインターフェースの専門化はあるようです。
私たちが説明したすべてのユースケースに対して、すべてのエージェントが持つ要素は「推論と決断」だと感じます。テキストをJSONに変換するだけのLMの呼び出しはおそらくエージェントとは呼ばないでしょうが、レスポンスをどこに送るかを決定して振り分けるようなものはより「エージェント」のように感じます。計画が必要か、決断が必要か、おそらく両方かもしれません。実際には、動的な決定木を持つ複数ステップのLMチェーンのようなものだと思います。
私たちはコンピュータサイエンティストなので、ビットが単に0か1ではなく、その中間のような場合、それを一方の値に変換しようとするまで多くを語り合ってしまいます。
エージェントには確かにマーケティングの側面があります。いくつかのスタートアップから聞いた話によると、彼らは「エージェント」として構築しているソフトウェアの価格をはるかに高く設定できると言っています。企業に「人間の労働者をこのエージェントで置き換えている。その人間労働者は年間5万ドル稼いでいたが、このエージェントは年間3万ドルで手に入る」と言えるからです。これは一見魅力的で、初期段階では価値があります。購入決定を下す人にとって比較価格を理解するのは非常に簡単です。
一方で、製品のコストは長期的には生産の限界コストに収束することも知っています。昔は翻訳者を使ってテキストを翻訳していたかもしれませんが、今はChatGPTを使っています。私はChatGPTに翻訳者に支払ったような金額は払っていません。APIを通じて実際のコストである非常に少ない金額を支払うだけです。エージェントに関する議論がどれほどマーケティングと価格設定によって駆動されているのか疑問です。
これは本当に興味深いトピックです。AIやAIエージェントによって完全に置き換えられている分野を考えることができますか？完全にではないかもしれませんが、確かに部分的にはそうですね。例えば、顧客対応をしていた人々の仕事を代行する音声エージェントがたくさんあります。伝統的にその仕事をしていた人々から多くの仕事が肩代わりされていますが、100%置き換えられているわけではなく、彼らは他のことができます。一部の分野では人員増加が鈍化しているのを見ています。つまり、既存の仕事が置き換えられているのではなく、新たな人間の雇用がより遅くなっているのです。
AIによって人間が置き換えられるケースは少ないと思います。ほとんどの場合、2人の人間がAIとともにより生産的な1人の人間に置き換えられるか、あるいは2人の従業員を維持したまま、より生産的になったので3人に増やすことになるかもしれません。エージェントを巡る混乱の一部は、人間の代替物を実際に開発するという考えから来ています。「エージェント」というのは、AIが登場する前は人間を指す言葉でした。今でも様々な種類の人々がエージェントと呼ばれています。
しかし、置き換えという意味ではそれは起こっていないようです。カスタマーサポートの自動化は常に存在しました。以前から1-800の番号があり、販売は1を押すといったものがありました。これはその遥かに良い形です。翻訳も良い例です。これらのシステムは非常に優れた翻訳を行いますが、何かをChatGPTに投げてそのままウェブサイトに公開することはおそらくしないでしょう。実際に作業が必要なのです。
これは、人間が行うほとんどのことには根本的な創造的な作業があるからだと思います。シリコンバレーの私たちの視点からは時々忘れがちですが、国中のあらゆる種類の仕事をしている人々は実際に難しい仕事を持っています。それは単に「誰かがやらなければならない」という意味での難しさだけでなく、思考や人間の決断力が必要という意味での難しさなのです。AIには私たちが決断力や意図と考えるものがあるとは思えません。システムが何かを実行しているとしても、誰かがプロンプトを与えて実行ボタンを押さなければなりません。
これがエージェントを巡る混乱の多くです。意図と創造性と思考を持つ人間が置き換えられるという考えがありますが、それは理論的にも可能かどうか疑問です。AIシステムが自分自身で考えているというのはほとんどパラドックスのようなものです。
興味深いのは、すでに2種類のエージェントについて話していることです。一つは人間の仕事を人間のように置き換えるタイプのエージェントです。もう一つは、より低レベルのシステムプロセスのようなエージェントで、互いに協力し、タスクを受け渡します。ある意味でエージェントはシステム内の技術的な詳細ですが、エージェントについて話すとき、両方を意味しています。
この場合、エージェントと関数の違いは何でしょう？エージェントは中間にLMを持つ複数の関数であり、低レベルのエージェントにタスクを与え、タスク結果を受け取るのは、中間にLMがあって何をすべきかを決定する従来のAPI呼び出しのように見えます。そうですね、それは関数の内部的な働き方です。外部から見ると、気にするでしょうか？気にしないでしょう。
AIのSDR（営業代表）エージェントについて話すとき、私たちが意味するのは、エージェントがCRMに行き、何かを引き出し、リストをフィルタリングし、メールを作成して送信できることです。それは人間のレベルというよりプロセスレベルに感じます。内部的にこれがどのように機能するかを知らなければ、古典的な関数とエージェントは区別がつかなくなります。プログラマーとして関数を書くとき、このことを行うエージェントを定義します。
その話題について考えるべき興味深いことがあります。共有可能で再現可能な関数は実際には存在したことがありません。これは市場の人々が「関数を書けば、地球上の誰でもそれを使える」と言ってきた長年の目標の一つでした。様々な機能を持つパッケージ全体をダウンロードすることはできますが、文字通り共有できる単一の関数はなかったのです。
少し目を細めると、AIでそれが今存在するようにも見えます。誰かによってトレーニングされたモデルがあり、別の誰かがそれをダウンロードし、微調整し、新しい興味深い方法でパッケージ化することができます。そして、それはホスティングサービスやHugging Faceなどで他の人がすぐに使えるようになります。LLMを使用しているかどうかは実装の詳細に過ぎないように見えますが、モデル自体が関数内の機能の多くを占め、通常のコードとは異なる種類のものになっています。通常の関数とは異なる特性を持ち、その中には実際に非常に望ましいものもあります。新しいインフラや開発ツールがこれを中心に構築されるのを見ることになるでしょう。
時間を遡って、システム構築のための主要な新コンポーネントを最後に発明したとき、おそらくネットワーキングでしたが、ネットワーキングの前後で関数の呼び出し方についての考え方が大きく変わりました。APIの複雑さとその周辺のインフラは今日では完全に異なっています。
考えてみると、人間も関数のようなものだと感じます。思考実験でプログラム内のLMを人間に置き換えると、プログラムに人間が与える答えの種類はLMが与えるものとそれほど違いません。もし私たちが皆いつかサーバーに接続され、Lambda（Amazonのサーバーレス・コンピューティング・サービス）から関数として呼び出されるようになれば、それこそがエージェントが作成されたということであり、それがエージェントだと同意します。
Mechanical Turkはまさにそれですね、あるいはメールボックスかもしれません。ある店舗が、スーパーマーケットから取ったものを識別するコンピュータビジョンモデルを使っていると宣伝していましたが、実際にはリアルタイムでデータをラベル付けするために多くの人々を雇っていたことが発見されました。その場合、人間が関数であり、今日ではLMに置き換えられるかもしれない秘密のエージェントなのです。
これがまさに私のポイントです。スーパーの会計係であっても、重要な創造的な仕事があります。「これは簡単な仕事だ」と単純に考えるかもしれませんが、実際には全く簡単な仕事ではありません。この仕事を移し、自動化で縮小することはできますが、完全にはなくなりません。
全く新しい製品カテゴリーを導入する場合、多くの場合、最初は現状、つまり置き換えるものか、場合によっては強化するものに対して価格設定します。直接的な置き換えを仮定すると、「これは人間を置き換える」というアイデアが生まれます（実際にはそうではありませんが）。もしそうなら、それに対してある金額を請求できるでしょう。
通常、時間の経過とともに競争が激しくなり、競合他社がいくら請求しているかによって効果的に価格設定するようになります。そして侵食が始まります。その後は、どれだけの優位性があるか、顧客のロックインがあるかなど、多くの要素に依存します。長期的には生産の限界コストに収束します。今日のほとんどのエージェントを見ると、おそらく非常に低コストです。純粋にソフトウェアでモデル化できるエージェントは、LLMの呼び出しがいくつかあれば、非常に低コストで実行でき、そのコストは時間とともに減少しています。
それが実際に起こっていることだと主張します。実際には、ほとんどのAIアプリケーション、特にAIエージェントアプリケーションと呼びたい場合、「私たちはあなたに節約をもたらすのでXを支払うべきだ」という典型的なROI計算のセールスピッチを持っています。価値ベースの価格設定ですね。
しかし実際には、ほとんどの購入者はフードの下で何が起こっているかについてかなり洗練された知識を持っていて、「これらすべてのGPUを実行するのにいくらかかり、それに若干のプレミアムを払おう」と考えています。そしてそれが今日多くのベンダーが実際に価格設定している方法だと思います。長期的には、SaaSと同様に、ソフトウェアは伝統的に非常に良い利益率を持っているので、健全な利益率が期待できるでしょう。
面白いのは、私たちはいつも企業に対して、マージンに基づいて価格設定するのではなく、提供する価値に基づいて価格設定するよう助言していることです。それは市場の他のベンダーと比較したり、社内で構築する場合と比較したりすることができます。伝統的にインフラでは、サービスが人間によって使用される場合はユーザーごとの価格設定、機械によって使用される場合は使用量ベースの価格設定という経験則があります。エージェントをどこに置くべきか実際にはわかりません。
どちらでも使用できますね。エージェントはエージェントに使用されるか、人間に使用される可能性があります。あなたの分析は正確です。現実は、ほとんどのAI企業はまだどのような価値を生み出しているのかわかっていません。これは非常に新しく、そして非常に萌芽的なものなので、「少なくとも損をしない程度の何かを請求しよう」という感じです。
OpenAIの場合、何百万ものユーザーがいますが、彼らがそれを何に使用しているかについての強い感覚はおそらくありません。そしてそれがわかるようになると、より縦割りになり始め、特定のユースケースに対する特定の製品を持つようになります。コードは明らかに大きなものの一つです。そうなると価格設定が追いつくのが見られるというのが私の仮説です。
OpenAIの話を聞いて、AIコンパニオンについて考えていました。それは、人間の価格設定に最も近いものです。コンパニオンと話す文ごとに料金を請求することはできません。しかし、応答ごとに料金を請求するサービスも実際に存在します。私は使用したことがありませんが、存在します。通常、コンパニオンとの会話に対してトークン単位で料金を請求するのは、月額定額料金よりも奇妙に感じます。真の友人のようには感じません。そうですね、非常に取引的です。
これはすべて理論です。人々は「人ごと、タスクごと、救済した世界経済ごとに課金する」などと話すのが好きですが、それはすべて作り話です。Guidoの言ったことが正確です。現在エージェントと呼んでいるものの基盤となる技術、それらがどこに展開されているのか、そしてなぜなのかを見てみましょう。価格設定、マーケティング、販売戦術などは、実際に販売しているものから導き出されます。
製品ではなくソリューションを販売する必要があります。これはエンタープライズの市場参入における専門知識としてよく知られています。例えばコードでは、価格と基本技術の分離が見え始めています。それが本当に機能し、それを使用するすべての人に明確なROIがあるからです。エンジニアリング担当副社長やCTOとして、これを見て「実際にたくさんのお金を節約しており、チームはより生産的になっている」と言うことができます。
つまり、ベンダーから問題を解決するソリューションを購入しているのです。これはMicrosoft、Oracle、Salesforceなどの企業が永遠に行ってきたことです。それがもっと見られるようになると、それは本物の製品のように見え、価格設定から切り離され、本物のビジネスのように見えるようになります。
それは高レベルのアプリケーションによって決定されると思います。例を挙げます。私はポケモンGOプレイヤーです。プレイしたことがある人はわかると思いますが、十分なポケモンを集めると、ポケットの保存容量が足りなくなります。そこで、より多くのポケモンを入れられる新しい仮想バッグを購入するために追加料金を支払う必要があります。
インフラ投資家として、ストレージビジネスに投資していますが、追加の30匹のポケモンのために支払わなければならない金額を見ると、ストレージより数千倍高価でした。ポケモンストレージには実際に価格曲線があるようです。これは基本的に一つのJSONブロブであるポケモンJSONブロブです。それに対して5ドルほど請求されます。
通常のポケモンプレイヤーはストレージのコストについて考えないでしょう。彼らは「この機能のためなら、S3バケットを持つよりも数千倍高くても喜んで支払う」と考えます。一つは独占です。別の場所にポケモンを保存することはできない、アプリケーション層の独占です。そして二つ目は、ユースケースです。異なる対象者向けで、彼らはこれらの質問をしません。彼らは「この価値を得るためにどのような新しいコストなら喜んで支払うか」を考えるでしょう。
それは楽しいゲームですか？楽しいゲームです。もっと100ドル取っても良いくらいです。それがまさに正確です。そして暗黙のうちに言っていることは、製品やソリューションが実際に彼らにとって機能する必要があるという考えです。自分のポケモン用にストレージバケットを自分でプロビジョニングしようとしない、より技術的でない人々にとってです。
また、非常に防御可能で差別化されています。ポケモンGOはオープンソースではありません。他の代替ポケモンGOはありません。唯一無二のポケモンGOしかありません。だから、ポケモンストレージにそれほどのお金を払う唯一の場所です。さらに、非常に強力なブランドがあり、一緒にプレイできるというネットワーク効果もあります。
そして、AIエージェントバージョンのこれを見ることになるでしょう。AIコンパニオンの衣装のためのストレージを支払うAIコンパニオンバージョンが見られるのが楽しみです。
システムの観点からエージェントがどのように構築されるかという非常に興味深い質問があります。個人的には、建築的には今日の典型的なSaaSソフトウェアとエージェントの間に実際の違いはないと思います。説明しましょう。
エージェントは、LLMとプロンプトを持つ全体的なループがあり、それが自分自身にフィードバックするプラス外部ツールの使用と言いました。LLM自体はおそらく高度に特殊化されているため、別のインフラで実行したいでしょう。これらの広大なGPUファームが必要であり、今日のLLMを単一のGPUで簡単に実行することはできません。それは非常に特殊なインフラで、外部にあります。
つまり、LLM呼び出しは外部にあります。状態管理については、今日のSaaSアプリケーションでは、すべての状態管理をデータベースなどの外部で行っています。おそらくそれも外部化したいでしょう。残るのは比較的軽量なロジックです。基本的に、データベースから何らかの方法で取得したコンテキストを取り、それをプロンプトにアセンブルし、プロンプトを実行し、時々ツールを呼び出します。MCPや何か外部サーバーでそれを行うかもしれませんが、コアループは実際にはかなり軽量です。1台のサーバーで無数のエージェントを実行できます。無数とは言いませんが、1台のサーバーで多くのエージェントを実行できます。多くの計算性能は必要ありません。それは正しいですか？
はい、全く同意します。私にとって興味深い建築上の質問は常に、LLMからの非決定性をどのように扱うかということでした。私たちが使用し愛している多くの成功したAIアプリケーションは、モデルの出力をユーザーにそのまま出力します。チャットボットや画像生成器は「LLMを呼び出しました、これが得たものです、頑張ってください」というものです。プログラムの制御フローにLLMの出力を実際に組み込もうとすると、それは非常に難しく、まだ解決されていない問題です。建築上の違いは今日比較的小さいかもしれませんが、これが将来より重要な変化をもたらす可能性があります。
私は実際に勝者は基礎モデルではなく専門家、つまり基礎モデルの上に構築するか微調整する人々になると思います。非常に芸術的な例として、過去2週間、GPT-4oの画像モデルにプロンプトを出し続けています。漫画が非常に得意で、マンガが非常に得意で、綴りもでき、ストーリーラインを持っています。しかし、それが得意なスタイルは上位2〜3つだけだと気づきました。ジブリが得意で、マンガが得意で、そのレルムの中でスタイルのバリエーションがあります。
アートが入る場所は、市場は分布外のアートを好むということです。誰もが同じものを何度も見たくないのです。それが彼らがアートを評価する方法だからです。何か違うものです。理想的にはそうかもしれません。最近、アートを分布外のサンプルと定義した人がいましたか？はい。アートは分布内にもあり得ます。それがポップアートです。分布外にもあり得ます。それは印象派が多年前に登場したときのようなものです。当時、それ以前の画家たちは「何があなたの目に起こったの？なぜぼやけた画像を描いているの？」と言っていました。
スタイルは行ったり来たりするものですが、それゆえに、これは分布を押し出す問題です。基礎モデルが100％のすべてをカバーすることはありません。次の波の人間と専門家が新しいデータ、新しいワークフロー、新しい美学を考え出して、その分布を押し出すのです。
今日のエージェントについて最も難しいことの一つはデータのモードです。技術的に難しいためにそうである場合もあります。データにアクセスしようとしているエージェントがあり、そのシステムと統合するのが非常に難しい場合があります。意図的にそうなっている場合もあります。私のiPhoneの写真は壁に囲まれた庭であるため、どのAPIからもアクセスできません。つまり、データサイロです。
それはエージェントを妨げているか、より困難にしている要因でしょうか？さらに強く言えば、消費者企業は伝統的にサービスへの自動アクセスを提供することに反対してきました。彼らはユーザーエンゲージメント、ユーザーに広告を出す時間を欲しているからです。それはエージェントをどれだけ展開できるかを制限するのでしょうか？そして、ウェブをブラウズできるブラウザネイティブのエージェントを持つようになれば、それは変わるのでしょうか？
はい、Yokoは全く正しいです。物理的なエンティティ、人々、ビジネスなどについてのデータを所有する人々には、それを自分たちのものにしておくための強いインセンティブがあります。特に、AIが彼らに何をするのか怖いかもしれないからです。だから彼らは持っているものにしがみついています。
これらの問題は、新しいプロトコルを定義して「人々が核心的資産を簡単に与えられるようにすれば、彼らはそうするだろう」と言うだけでは解決されることはめったにありません。明らかに、それが機能する可能性は非常に低いですが、誰かがいつか「あなたのデータが公に見えるなら、私たちはそれを取得します」と言って解決するでしょう。ちなみに、それは実際にはあなたのデータではありません。それは私についてのデータです。だからなぜあなたがそれを抱えているべきなのでしょう？
実際、モデルの新しい進歩がデータのモードを変えるかもしれないと感じています。今日、エージェントを使用したウェブブラウジングはあまりうまく機能しません。非常に遅く、非常に扱いにくいです。何かタスクを実行するには何度も試さなければなりません。しかし、エージェントに任意のウェブサイトに行き、人間としてログインする能力を与える基礎モデル機能があると想像してください。エージェントIDがどのように機能するかはまだわかりませんが、SSHでサーバーに接続して特定のコマンドを実行したり、モバイル用の仮想マシンを起動したり、ポケモンGOをプレイするためにデバイスファームにアクセスしたりすることができるかもしれません。伝統的にそのアカウントの下で人間だけが利用できたデータが、エージェントにも利用可能になるかもしれません。
反対のことも起こりえます。基本的にすべての消費者サイトがより複雑な対エージェントキャプチャを使い始め、エージェントを締め出そうとすることで、注意を払える人間だけがそれらのサイトに来るようにすることです。最近、ディープリサーチツールの一つ、主要なLLMの一つを使用しましたが、そのステップを見ると、サイトのキャプチャメカニズムを回避する方法を見ようとすることがあり、それは実際に推論のステップでした。基本的に、欲しい情報がわかっていたが、それにアクセスできないときに行うものです。
未来はどれだけディストピア的になるのでしょうか？実際にそれを解決しました。とても興味深いです。これの初期の機械学習の例を思い出します。Gmailが広告を初めて実装したとき、それは大きな論争になりました。彼らは「私たちはあなたのメールを読みません、でもアルゴリズムはあなたのメールを読み、それに基づいて見るべき広告を提案します」と言ったのです。私たちは皆、それを忘れて慣れてしまったと思います。まだそのアイデアを完全に好きではないかもしれませんが、共存しています。
しかし、データプロバイダの一部はメールからデータを削除することで反応しました。Amazonは有名に、何かを注文すると、「何かを注文しました、知りたい情報があれば、注文したものや配達日などを見るためにここをクリックしてください」と書かれた確認メールを送ります。その例では実際に、主要なデータ保有者がそれを保留する方法を見つけたのです。今それが可能かどうかは興味深いところです。
同じデータがクライアント側でスクリプト化されています。インストールした広告ネットワークからです。そうですね、常に他の方法があります。正確に同じではないかもしれませんが、かなり良い代替です。LLMと人間の区別が、古典的なAPIコールメカニズムと人間の区別よりもはるかに難しいかもしれません。それがダイナミクスを変えるかもしれません。
ポジティブなビジョンは、2年後に私の代わりに働くエージェントが私がアクセスできるほとんどのツールを使用できるようになることです。そのために欠けているすべての部分も明確です。私たちはまだ、私の代わりに働くエージェントのためのセキュリティ、認証、アクセス制御を解決していません。データ保持がどのように機能するかもわかっていません。そのエージェントをブロックする可能性のある消費者ウェブサイトとの関係も解決していません。
しかし、もしそれがあれば、多くのタスクをはるかに簡単にすることができるでしょう。今日、データがGoogleドライブなどに保存されている場合、そのデータと他のより断片化されたソースにあるデータについて推論することがどれほど簡単かという違いは、信じられないほど大きいです。それが強気のケースだと思います。あなたがアクセスできるすべてのデータにアクセスし、あなたの代わりにタスクを実行できるエージェントがあれば、多くの時間を節約できます。あなたが何をするかによっては、今日よりも何倍も生産的になるかもしれません。
私の答えは実際には異なるモダリティによる基礎モデルです。今日でも非常にテキストベースであり、それはコーディングやテキストベースのテストには非常にうまく機能します。しかしより視覚的なテストでは、一対一のマッピングがありません。ウェブブラウジングでも、数秒ごとにスクリーンショットを撮って基礎モデルに送り返すという非常に扱いにくい体験です。
私は実際にはマルチモダリティに賭けます。ウェブサイト上のボタンをクリックしたり、ウェブを操作したり、異なるデバイスを使用したり、描画したり、ベクターアートを作成したりするような異なるトレースでモデルをトレーニングすれば、エージェントレベルでモデルがロック解除できる新しいことがたくさんあるでしょう。
私の答えは予想できると思います。2年後あるいは5年後に「エージェント」という言葉を使わなくなれば、それは大きな勝利です。コロンビア大学の方々によって出された「AIは普通の技術」という面白い論文があります。彼らはAIがユートピアかディストピアをもたらすという誤った二分法があると主張しています。つまり、AIのおかげですべてが素晴らしくなるか、すべてが恐ろしくなるかという国家的な議論です。しかし、それを水や電気やインターネットなど、普通のものと考えるなら、それが私たちが向かっている世界だと思います。エージェントはそこに到達するのを助ける一種の方法です。それが私の目標です。このものは信じられないほど強力で、それをどう使うかを理解し、ユースケースを理解し、私たちのために使っているだけなのです。
コメント