AIのUXにはもっとイノベーションが必要で、今は恥ずかしいレベル – Chroma創設者兼CEO、Jeff Huber

AIエージェント
この記事は約47分で読めます。

Chroma創設者兼CEOのJeff Huberが、AIアプリケーションデータベースとエージェント開発の現状について語る対談である。コーディングエージェントが現在最も成功しているAI活用事例として挙げられ、検索インフラの現代化、コンテキストエンジニアリングの重要性、メモリ機能の課題について詳しく議論している。特にAIのUXイノベーションの不足を指摘し、より良いツールの必要性を強調している。

AI UX needs more innovation, right now it’s embarrassing - Jeff Huber, Founder and CEO of Chroma
Jeff Huber, Founder & CEO of Chroma, joins Jay to discuss why context engineering remains the core job of AI engineers, ...
www.youtube.com

AIアプリケーションデータベースとエージェント開発の現状

ChatGPTやAIボーイフレンドなど、消費者向けの角度もあります。そしてこれまで最もヒットしているのは、コーディングエージェントですね。今振り返ると、コーディングがAIの最初の主要な使用事例になることは明らかでした。決定論的なソフトウェアという完璧な遊び場で、LLMの非決定論性の欠点をヘッジするのに本当によく適しているんです。

私たちは9000万トークンのTypeScriptモノリスと作業していますが、SweetBenchにはそのようなものは何もありません。AI UX内のイノベーション量は、ちょっと恥ずかしいレベルですね。人々はもっとやるべきですし、これを聞いている人はもっとやってください。

技術分野で働く、エージェントやエージェントフレームワーク、またはエージェント関連のことに取り組んでいるハゲの人たちの記念すべき最初の会合へようこそ。

ここにいることができて本当に嬉しいです。BGTNのような感じですね。それが略語です。知り合いの人が一度、「ああ、JBBLのジェイを知っている」と言っていました。それはJeff Bezos似顔クラブだったでしょうか。ベストか何かを着ていたような気がします。素敵ですね。それは褒め言葉だと思います。

ジムに通っていることも意味していると思いますよ。その通りです。そして億万長者のように見えます。だから、それは素晴らしい出発点だと思います。

ここにいることができて本当に嬉しいです。ホストしていただいてありがとうございます。素晴らしいスタジオがありますね。私たちはTwitterで2年間、GPT-3 API時代の黎明期から2年半ほど、やり取りを続けてきました。

だから、エージェント、メモリ、ストレージ、そしてAIO以外のもの、データベース構築のようなことに関連する多くのことについて、あなたの意見を聞くのがとても楽しみです。それについてもあなたの意見を聞いて、会話がどこに向かうか見るのにも非常に興味があります。

AI アプリケーションデータベースの特性

良い出発点は、AIアプリケーションデータベースでしょう。それがあなたのウェブサイトに載っている用語です。AIデータベースは、PostgresやMongoDB、または開発者がより伝統的に使用しているものと何が違うのでしょうか。

現代のChromaの実装を説明する一つの方法があります。明らかに、開発者の異なる世代に到達するためにメッセージングを変更していますね。

Chromaは、AI向けの現代的な検索インフラストラクチャを構築しています。現代的というのは、本当にスケールが困難で非常に高価な多くの従来のデータベースやシステムとは対照的です。容量計画について考える必要があり、ノードのサイズを決めて、バックアップやウォームスタンバイなど、多くの運用上のオーバーヘッドに関する作業をする必要があります。

現代的な分散システムの多くは、その複雑さをすべて抽象化して、開発者により簡単で費用対効果が高く、それでいて非常にパフォーマンスの高いソリューションを提供します。

それが現代的な部分で、AI向けという部分は、ある意味でこの会話のより興味深い部分です。基本的に私たちは、それが3つのことを意味すると信じています。第一に、それは従来の検索インフラストラクチャとは対照的に、AI開発者向けだということです。従来の検索インフラストラクチャは、専門的な検索エンジニアが設定、実装、保守する必要がありました。今では誰もが検索の問題を解決して、エージェントに適切なコンテキストを持たせる必要があります。

第二に、AI ワークロードです。過去には、多くの人が頻繁にクエリする必要がある非常に価値の高い特定のデータプールのみをインデックス化し、検索可能にしていました。日常の仕事について考えてみると、私たちの仕事の大部分は情報検索です。あなたと私は、日常生活の15〜20%を情報検索に費やしていると推測します。

コンテキストエンジニアリングの進化

あなたが触れるすべての異なるシステム、すべての異なるデータを想像してください。それのマップがあり、インデックスがあり、ルーティングがあり、物を見つける場所を理解しています。そして、より多くの労働をエージェントに移したいと思うのと同じことが真実だと思います。すべてのデータがエージェントにとって判読可能で、アクセス可能で、検索可能である必要があります。

第三に、AI機能です。これをさまざまな方法で分解できますが、始めるための簡単な例を一つ挙げます。過去には、10個の青いリンクや10個の結果でのリコールが本当に重要でした。それが人間が消化できるすべてだったからです。リコールは重要でしたが、精度も同様に重要でした。

今はLLMがあるので、精度はそれほど重要ではありませんが、リコールは実際により重要になっています。LLMは何百もの結果を非常に簡単かつ安価に消化できますが、その何百もの結果の中に正しい答えがあることを確認する必要があります。

他にも本当に興味深いことがたくさんあると思います。私たちの顧客も私たちも取り組んでいることで、LLMをクエリプランナーのような形で実際に使用できます。LLMは意図を決定し理解でき、システムから適切な情報を取得するためのクエリを構築できます。

繰り返しますが、これらはLLMが存在するようになった今だけ可能なことです。

それは本当に魅力的ですね。連続するSQLクエリを実行するアプリケーションを見たことがあります。それは非決定論的なクエリプランナーのようなもので、クエリを実行します。SQLデータベースのスキーマを見て、それに基づいて決定し、「ああ、これに基づいて、これをクエリすべきだ」となります。

それは決定論と非決定論が織り交ぜられた非決定論的SQLクエリを実行するようなもので、次に何をするかを決定します。とても刺激的なアイデアですね。

広く言えば、多くのAIエンジニアの仕事は実際にはコンテキストエンジニアリングです。エージェントが適切なデータプールにアクセスできるように、それらの使い方を教えるために、すべてのシステムをどう接続するかを理解する必要があります。

場合によっては、リレーショナルデータベースやデータウェアハウス内の構造化データになります。他の場合では、エージェントが知っておく必要があり、アクセス権を持ち、使用方法を知る必要があるツールやAPIになります。また他の場合では、非構造化データになります。

検索技術とベクトルデータベースの限界

非構造化データの量を見ると、ほとんどの企業では既に構造化データの100倍、1000倍になっており、これは加速するばかりです。LLMが毎日終日稼働していることを考えてください。それらが摂取し、出力しているものは何でしょうか。それはより多くの非構造化データです。

明らかに、私たちはChromaで非構造化データ側のことを多く考えています。しかし、ここに銀の弾丸はありません。繰り返しますが、これはエンジニアリングです。私たちは困難な作業をする必要があります。

あなたはコンテキストエンジニアリングについて言及しました。私にとって、それは過去3年間ほどで多くの異なる意味を持ってきました。最初は、おそらく4Kトークンしか収まりませんでした。GPT-3は最初4Kだったと思います。そして今では、Claudeが昨日発表した100万トークンがあります。

そのため、コンテキストエンジニアリングの技術が時間とともにどのように進化してきたか、そして将来どのように進化すると見ているかを教えてもらえますか。

最初に言ったように、コンテキストは極小でした。非常に少量の作業しかできませんでした。今、最大の商業的に利用可能なモデルはLlama 4 Maverickで、1000万トークンのコンテキストウィンドウがあります。そして特定のスタートアップは、時々1億トークン、10億トークン、または無限トークンがあると主張しています。

Chromaが多くの作業を行った一つの点は、聞いている人は私たちのコンテキストロットに関する技術レポートをチェックできることです。これは「100万トークンを提供すると言っているが、実際にその100万トークンをどの程度うまく使用できるか？」という質問です。

これは非常に重要な質問であり、ラボが特にあなたにその質問について考えることを助ける動機がない質問でもあります。また、その質問に答える動機もありません。しかし私たちは作業を行い、研究を行い、証拠を持っています。毎日実際に物を構築している実践者である開発者の多くは、すでにこれについて直感を持っていました。

開発者から常に聞くのは、Claudeモデルで10万トークンを超えると、物事が少し不安定になり、かなり危険だということです。そうではありませんか。

信頼性とパフォーマンスシステムが欲しいので、通常はより多くの非決定論を追加したくはありません。私たちの研究では、コンテキストウィンドウの大部分に注意を向ける能力と、そのコンテキストに対して推論する能力の両方において、早くも5,000または10,000トークンという時点で、かなり急激な劣化が見られることがわかります。

繰り返しますが、あなたのユースケースによって、どの程度の推論力と注意力が必要かは変化し、異なります。しかし、これらの問題は解決しないと思います。それはトランスフォーマーとこれらのモデルの訓練方法に根本的に関わる問題だと思います。

モデルのコンテキスト処理能力の限界

回避するのがかなり面倒なので、良くなることを望んでいます。しかし、今日構築している誰にとっても、パックがどこに向かっているかでスケートしながらも、現実が何であるかを理解する必要があると思います。

要約すると、GPT-5で分析を実行する予定です。新しい100万トークンのClaudeモデルで実行したのと同じ分析を実行します。数字が何を示すか見てみましょう。少なくとも今後3〜5年間は、開発者が本当にコンテキストエンジニアリングを受け入れて、非常に上手になる必要があるという安定した賭けです。

精度の理由だけでなく、速度とコストの理由からも、古典的な階層である「動くようにする、速くする、安くする」があります。私たちはまだ「動くようにする」段階にあり、動くようにするためにはコンテキストを設計する必要があると思います。

確実にそうです。あなたは直感的にこの問題は解決しないと言いました。ニードル・イン・ヘイスタック設定を覚えています。あなたがやったもので、全ロード・オブ・ザ・リングシリーズを入れて、ハリー・ポッターから1行入れて、「ハリー・ポッターの行を見つけられますか？」というようなものでした。これがあなたの研究から特定のものではないかもしれませんが、無限の量の合成データを作成できるタイプのもののように思えます。

RL ループを実行したい場合、「ハリー・ポッターの行を見つけて」と言うなら、これを本当に絶対的なベアリングまで研ぎ澄ませることができるでしょう。

では、実際に上限があり、ニードル・イン・ヘイスタックで針を見つけることができない問題に対して防御できなくなると思いますか？

いくつかの点があります。まず第一に、それはニードル・イン・ヘイスタックではありません。ニードル・イン・ヘイスタックは実際には強い語彙的一致です。あなたが持ち出したのは、セマンティック一致やカテゴリ化マッチのようなものの例で、その文がハリー・ポッターとさえ言っていない場合もあります。ヴォルデモートとも言わないかもしれません。

それは私の訓練データに基づいて、それがハリー・ポッターからだということを知っているべきだというようなものです。真のニードル・イン・ヘイスタックは、一つの例で、質問が「良い文章を書くために最良のことは何かと大学教授が言ったか」で、針が「大学教授は良い文章を書くために最良のことは毎日書くことだと言った」になります。

興味深いです。そして極端な語彙的一致で、推論タスク状況がゼロです。それを削除して、「物語を書くのが上手になるにはどうすればいいか」というような単純なセマンティック検索をしても、実際に劣化が始まることがわかります。

ニードル・イン・ヘイスタックの強い語彙的一致は、すべてのトークンウィンドウコンテキスト長で解決されていますが、推論力はゼロで、針に注意を向けるだけの非常に限定された注意しか必要ありません。これを素早く追加したいと思います。

RLについての質問に戻ると、明らかに今RLは非常にホットです。誰もが話せるのはそれだけのようです。そこには2つの質問があると思います。第一に、RLは何をうまくできるか。第二の質問は、モデルは何を吸収できるかということです。そして忘れることなく何を吸収できるか。その評決はまだ出ていないと思います。

汎用的なモデル対特化したモデル

解釈可能性の観点から、これらの制限について実際に理解していません。ロード・オブ・ザ・リングのコンテンツとハリー・ポッターのコンテンツを分類するのが非常に得意なモデルを作ることは可能でしょうが、その過程で他のすべてを失うでしょうか。すべてではないかもしれませんが、ほとんどは失うでしょう。

可能なあらゆる本の一般的な分布を見て、ハリー・ポッターから1行が投げ込まれている場合、どれだけ良くなるかは不明です。

今日本番で見られる長いコンテキスト負荷を見ると、通常は非常に長いエージェント的なロールアウトです。その特定のサブドメインの長期ロールアウトでは、物事を覚えるのがより良いか、またはそのような証拠があるかという考えがあります。

私は、特定のタスクでファインチューニングされたモデル、RLまたは他の方法でファインチューニングされたモデルの割合で提供されるワークロードの割合が、来年以降、おそらく今後40年間、年々無限に上がると非常に強気に思っています。今日、それはかなり小さいです。

ほとんどの人は基本モデルではなく、RLHF チャットモデルを主に使用しています。特定のタスクでファインチューニングされたモデルの割合はわかりませんが、おそらく一桁のパーセンテージポイント、またはそれ以下、おそらく1%未満だと思います。しかし、それは年々上がると思います。だから私は目的に構築されたモデルに長期的に楽観的です。

私がより懐疑的な部分は、それが万能薬だということです。一つの例を挙げます。私たちはいくつかの実験を行っていました。実際にBenchでより多くの実験を続けており、Benchのコンテキストで長いコンテキストを見ました。エージェント的ロールアウト、多くの反復的なタスクのようなものです。

エージェントに以前の成功事例や以前の失敗にアクセスを与えた場合、それはエージェントのパフォーマンスを向上させるでしょうか。直感的に意味があります。人間として、以前にこの問題にぶつかったことがあるなら、カンニングペーパーがあることがわかります。これが修正方法です。

それは良いことのように思えます。あるいはfew-shotプロンプティングのように、以前に10のような状況を見たことがあります。これが私がしたことです。これが機能しました。今はそれをコピーできます。私たちが見つけた（これは限定的なテストなので、多くの免責事項があります）のは、エージェントに以前の失敗へのアクセスを与えると、モデルのパフォーマンスが何パーセントか向上しました。25%から33%程度の顕著な向上でした。

しかし、エージェントに以前の成功のみへのアクセスを与えた場合、エージェントのパフォーマンスは下がりました。本当に直感に反します。

エージェントの学習と記憶の課題

一度紐解けば直感的ではないと思います。紐解いてから、それが直感的かどうかわかるでしょう。モデルは怠惰だと思います。最も有害で気を散らす情報は、非常に関連性があるように見えるが、微妙な理由でそうでない情報です。モデルは常にその微妙さを理解できるわけではありません。

人間として想像してください。何かをすることの専門家ではない人間がいて、タスクを実行するように求め、過去の例のコーパスへのアクセスを与えます。彼らも局所最適解に陥り、コピー＆ペーストに頼ることになります。

「ああ、もう私のために仕事をしてくれた。ありがとう。今考える必要はない。コピー＆ペーストするだけだ。」私たちが見つけたのはそういうことです。

明確にしておくと、以前の成功のライブラリと言うとき、それは関連するタスクでの成功でしたが、全く同じタスクではありませんでしたね。成功事例からのdiffを取ってそれを適用するコピーペーストマシンになってしまうからです。それはある意味で興味深いテストではないでしょう。それは真のカンニングになってしまいます。

いえ、似ているが同じではありませんでした。なるほど。それは非常に興味深い結果で、それが訓練にも適用されるかどうか疑問です。コンテキストの例やfew-shot学習のパッキングから実際のファインチューニングまでの連続体があることを示すいくつかの結果を見たことがあります。

SweetBenchのコンテキストでは、ポジティブサンプルよりもネガティブサンプルが実際により価値があるのでしょうか。

100万パーセントです。これは実際に奇妙な方法でChromaが始まったところです。私たちは能動学習に本当に興味を持っていました。能動学習は基本的に「次に何を訓練すべきか」という質問のプロセスです。

識別したいのは、既に知っていることから分布に追加された困難だが学習可能な例です。困難だが学習可能な例です。明らかにそのシグナルを収集するための多くのツールがあります。

実際にGoogleは先週、能動学習に関する新しい論文を発表しました。どの例が役に立つかの分類について、彼らは実際にembeddingスペースを使ってこのようなことを導き出していると思います。私たちは、いくつかの顧客がChromaを訓練でも使用し始めているのを見ており、それはかなりクールです。

それはまだ非常に初期段階だと思いますが、ベクトルデータベース自体にそのようなものを組み込む方法があるでしょうか。これらのembeddingがあって、何らかの推論層をDBに組み込むことができ、C++レベルで、単一のスカラー値への投影を行って、これが価値があるかないかを教えてくれるような。能動学習目的だけでなく、他の分類目的でも。

モダンな検索システムの設計思想

ベクトルデータベースという用語は私が常に嫌ってきた用語で、今後も嫌い続けるでしょう。ちょっと追加しておきます。それは脳腐敗用語だと思います。実際にここでの仕事が何であるかを説明していません。

それはさておき、データベース内で実行されるLLMは本当に興味深いと思います。ほとんどの検索システムがどのように動作するかを理解するプロセスは、まず可能なすべての関連情報を収集したいということです。しかし、すでに議論したように、その情報をすべてコンテキストウィンドウに与えることはできません。それは処理できません。だから、それを整理しなければなりません。何らかの方法で焦点を当てる必要があります。

ランカーは、そのための共通の歴史的ツールです。これらはランキングに特化した専用のクロスエンコーダーバイナリモデルのようなものです。

LLMを直接リランカーとして使用する人がますます多くなっています。「ここにプロンプトがあります。ここにチャンクがあります。これは関連していますか、はいかいいえか」という二項分類器として使用できます。出力トークンは基本的にゼロで、logitsを直接使用できます。

それを拡張すると、さらに進むことができます。二項分類だけでなく、なぜ動的チャンクリライティングをしないのか。「ここにコンテキストがあります。ここにチャンクがあります。このクエリに関連することだけに、このチャンクを絞り込んでください」や、なぜセマンティック分析をしないのか。

それは実際に非構造化クエリエンジンのようになり始め、データプールにほぼ任意のクエリを尋ねて、そのデータを処理し理解するのに大規模並列LLMを使用できます。

それは私にとって本当にエキサイティングな未来で、実現すると思います。明らかに今日、人々はまだ推論が高価だという考えを心に持っています。最新で最高のモデルを使用している場合は確かに高価です。しかし、トークンのコストはゼロにはならなくても、自分でQwen 2.5をプリコミットされたGPUで実行している人々は、本当に低いコストまで下げています。100万入力トークンあたり1ペニー程度だと思います。

だから、それはほぼ解放されたリソースのように感じ始めます。家の電気のように、考えることなくただコンピュータを投入するような感じです。

データベースとLLMの統合によるコスト最適化

LLMの実行が高価だという会話で、人々があまり言及しないことの一つは、データベースの実行にすでに多くのお金を費やしているということです。そして、実際にLLMを血脳関門を越えて、DBの基盤に組み込むことができれば、おそらく総クエリ数を減らすことになるでしょう。なぜなら、より少ない総クエリ数で答えを得られるからです。

私は、Chromaの動作方法の専門家になることを外部エージェントに期待するのではなく、GPUに接続された非決定論的なより賢いクエリプランナーがデータベースに接続されているというアイデアに非常に強気です。

私たちは常に、データには重力があり、最終的にコンピュートワークロードはデータのところに来るという考えを信じてきました。言ったように、ネットワーク出力転送コストの理由で、将来的には、コンテキストや検索のために欲しいデータをGPU上で直接ページングするかもしれません。そして、それがすべて一つのチップセット上にあることは、確実に多くの意味を持つでしょう。

そして、これらの特定のデータストレージフォーマットを使用して、ツールのより良い検索を行うために、ハードウェアレベルの最適化を行うことができると理にかなっています。非常に軽量なものを訓練することもできます。

実際に、あなた方がそれについてどう考えているかの詳細と、これまでの実装努力について教えてもらえますか。Chromaと相互作用するファインチューニングされたLLMはありますか。それらがDB外部にあるか内部にあるかに関わらず、Chromaと相互作用するカスタマイズされたLMツールについてどう考えていますか。

私たちは多くの実験を行ってきました。そして、その多くは非常に有望です。これまで小さな会社として、一つまたは少数のことを非常によくやることに本当に焦点を当ててきました。つまり、データベースを非常に高速、費用対効果が高く、非常にパフォーマンスが高く、非常に信頼性が高くすることに焦点を当ててきました。これが顧客が私たちにして欲しいことです。

今、データ取り込み、潜在的にembeddingモデル推論など、より多くの方法で顧客を支援できることが見え始めています。そのため、その方向に小さな一歩を踏み出していると言えます。しかし、計画していて取り組みたいことはたくさんありますが、それは焦点と時間の問題です。

完全にそうですね。コストと時間は節約できるでしょうが、これらのアプリケーションの多くにとって、私たちはまだ「動くようにする」時代にいます。そのため、いわゆる血脳関門を越えてLLMを持ち込むことは意味がないのかもしれません。

コード検索とコーディングエージェントの現状

コード検索について話しましょう。私は今これが最も魅力的な分野の一つだと思います。AIアプリケーションから生成された収益という観点で見ると、ChatGPT、AIボーイフレンドがあり、このような消費者的な角度があります。そして、これまで最もヒットしているのは、コーディングエージェントです。本当にそうですね。

Cursorから6億ドルの収益を見ています。Claude Codeもそれほど遅れていません。コーディングには多くの課題があります。その一つは正しいものを見つけることです。

少し前にSweetBenchについて言及しましたね。これらはかなり大きなコードベースですが、理想的にはこれらをかなり大きなコードベースで動作させることができるはずです。私たちは9000万トークンのTypeScriptモノリスと作業しています。SweetBenchにはそのようなものはありません。

これを機能させるための課題は何でしょうか。Chromaは支援するために何をしていますか。そして、コード検索が将来どのように進化すると見ていますか。

振り返ると、コーディングがAIの最初の主要なユースケースになることは明らかでした。決定論的ソフトウェアという完璧な遊び場で、LLM自体の非決定論の欠点をヘッジするのに本当によく適していると思います。

私は常に、Andre Karpatryのソフトウェア1.0、ソフトウェア2.0のようなアイデアに戻ります。インターネットが登場したとき、私たちは何をしたでしょうか。電話帳をインターネットに置きました。今、AIのようなソフトウェア2.0または3.0（どうカウントするかによって）があるとき、私たちは何をしているでしょうか。主にそれを使ってソフトウェア1.0を書いています。

今日の場合、それは変わるでしょうし、それは明らかに遍在するケースの会社です。コード検索をどうやるか、またはどうやらないかについて、多くのプロパガンダがあったと言わざるを得ません。実際にバックプロパガンダと呼んでいます。

バックプロパガンダですね。それいいですね。初めて聞きました。人々はTwitterで時間を費やすのを減らすべきです。人々は自分のベンチマークや自分の評価、何が機能するかを理解することにもっと時間を費やすべきです。

ベクトル検索だけで十分だと言う時代が確実にありました。私はそれを言ったことがありません。Chromaはそれを言ったことがありません。しかし、多くのベンダーが推進していたことです。明らかに、未来が何をもたらすかはわかりません。おそらく最終的には、これらの密な表現がスパースな表現よりもはるかに強力になることがあるかもしれません。

しかし、今日、それがどのアプリケーションに対しても万能薬であることは明らかではありません。特にコード検索は有名で、一部の企業は、マーケティングかどうかに関わらず、「いいえ、私たちはGrepだけを使う」ということを差別化の重要なポイントにしています。もちろんGrepは単にripgrepですよね。ファイルセットの上でripgrepの検索を行うことで、テキストデータがある場合は特によく機能します。

これを少し紐解いて、セマンティック検索対レキシカル検索がいつ意味をなすかを人々に理解してもらうのが実際に有用だと思います。実際にインデックスを構築することとは別に考えることも重要です。つまり、セマンティック検索またはレキシカル検索の上にインデックスを構築することです。

セマンティック検索を力ずくでやることもできます。レキシカル検索を力ずくでやることもできます。特定のデータスケールでは、インデックス化することが意味があります。なぜなら、スケールするにつれて曲線を曲げることができるからです。

セマンティック検索とレキシカル検索の使い分け

私が使う一つの簡単な類推（直接的なコーディングの類推ではありませんが、すぐにコードに戻します）は、Google Driveで、すべての投資家のリストがあるスプレッドシートを検索したい場合です。それが何と呼ばれているか知っています。私が作ったからです。それはキャップテーブルと呼ばれています。だから、キャップテーブルと入力するだけです。そこに検索結果があります。それをクリックします。素晴らしい。

私が自分のデータの専門家だから意味があります。文法を知っています。言語を知っています。何を検索すればいいか知っています。もし自分のデータの専門家でない場合、「すべての投資家のリストがあるスプレッドシート」を検索するでしょう。

それはセマンティックにキャップテーブルに非常に高くマッチするでしょう。そして、それをクリックして進むでしょう。これを任意のユースケースやユーザー、またはその両方のミックスについて考えることができると思います。検索したいコンテンツの文法と辞書において、エージェントや人間がどの程度教育されているかの特定のブレンドがあります。

ユーティリティの観点から、一部のアプリケーションでは8対2だと思います。他のアプリケーションではそれが逆転して2対8になります。これらの技術がどれほど有用になるかによって決まります。

人々は、LLMがコードに本当に優れていることを発見しました。多くのコードで訓練されているため、文法に実際にかなり優れており、検索する用語を推測するのがかなり得意です。その用語を正確に、または非常に近くまで正しく取得するため、結果としてripgrepは非常に強力なツールです。

これがこれを紐解いて考える方法だと思います。コード検索全般について考えてみると、ripgrepだけで十分かどうかについては評決はまだ出ていません。密なembedding vectorだけで十分かどうかについても確実に評決は出ていません。おそらく現実にはミックスになると思います。

いつ何を使うかは、コンテキストエンジニアリングの興味深い部分です。しかし、繰り返しますが、人々が愛するツールと愛さないツールを本当に差別化するのは、システムが関連するコンテキストをどれだけうまく引き出すかだと思います。

人々は、「ああ、エージェントにエージェント的に検索させ、エージェント的にRAGさせればいい」という杖に頼りたくなると思います。もう二度と言いたくありません。動作するように見えるものを得るまで、井戸に戻り続けるだけです。しかし、そこにも多くの問題があると思います。

いつ止めればいいかをどう知るのでしょうか。早く止めすぎたらどうでしょうか。ある意味では、システムにより多くの非決定論を追加しているだけで、少なくしているわけではありません。それが有用であることは間違いありませんが、LLMが優れたクエリプランナーになれることについてすでに話しましたが、エージェントが欲しいものを見つけるまで80回クエリすることは、今から1年後にユーザーが愛するアプリケーションの主要な機能になる可能性は低いでしょう。

カスタムツールとドメイン特化検索の可能性

では、LLM用のカスタムツールを作ることについて見解はありますか。クラックしたlanguage serverのようなもので、ドメインの構造が組み込まれているものです。単なるレキシカル検索ではなく、特定のシンボルの参照にジャンプできるようなものです。そのようなものが、あなたが説明した問題のいくつかを実際に解決すると思いますか。

はい、100%です。多くのトップ企業がすでにやっていることです。彼らはripgrepや単純検索を2つの非常に重要な技術として使用しています。特定のケースではセマンティック検索も使用しています。

中には、より高度なものをさらに推し進めているところもあります。収集と選別の類推に戻ると、まず可能なすべての関連トークンや情報を取得したいのです。そして、必要なものだけに絞り込みたいのです。

より洗練された検索アプローチについて考えると、それらは何をもたらすでしょうか。より速く安い収集プロセスをもたらすかもしれませんが、それがマージンでそれほど重要でない場合もあります。選別段階で力づくでやることが、価値のほとんどが存在する場所かもしれません。

繰り返しますが、常に10〜15%改善して、より安く、より速くできます。これは状況とユーザーによって、ユーザーが気づくか気にするかが決まります。しかし、繰り返しますが、それを実際のユーザーエクスペリエンスの違いと、エージェントが実行する能力の違いにも結び付ける必要があります。

長期的に、エージェントが実行する能力に大きな違いをもたらすとは思えません。良い選別作業をすれば、すべての関連トークンに戻ってくるでしょう。主にやることは、エージェントループをマージンでより速く、より安くすることだと思います。それがユーザーにとって重要かどうかは別の問題です。

確かにそうです。ある意味で、ファイルシステムは様々な検索技術を公開するデータベースであり、ripgrepなどが含まれます。そして、これまでのところ勝利している大きな理由のようです。

Claude Codeは単にripgrepを使用しています。高級なlanguage serverや何かは使用していません。そして、私が知る限りでは、それが最先端です。設定が非常に簡単で、特定のデータベースやクエリメソッドについて何も知る必要がありません。Linux VMがあればすぐに使えます。

しかし、それが将来的にもそうであるとは信じがたいです。コードの構造に固有の多くの要素があり、超知能なLLMが効果的になるために活用したいと思うでしょう。Language serverはその良い例です。認証モジュールを何と呼ぶかわからないかもしれませんが、6つのripgrepクエリを実行する代わりに、セマンティック検索を実行してそれを取得したいかもしれません。

コード検索における新しい可能性

ベクトルデータベースの作成に関連する明らかな複雑さがありますが、近い将来に解決される種類のもののように思えます。単一のファイルシステムでウェブ全体のコードを検索できないということは言うまでもありません。

その通りです。また、テキストのみを検索している場合、ripgrepはそこまでの道のりの大部分を得ることができるかもしれないという点も指摘します。繰り返しますが、それが80%しか得られない場合、セマンティック検索やembeddingベースの検索を追加することで、さらに8%増加すれば、ユーザーが競合他社の製品ではなくあなたの製品を選択する違いを意味するかもしれません。

テキスト検索は定義上、テキストの検索にのみ優れていますが、コードの場合は通常テキストだけですが、常にそうではありません。多くのマルチメディアがコードベースのpublicフォルダに入り込んでしまいます。では、画像をどう検索しますか。動画をどう検索しますか。

エージェントが本当にユーティリティと信頼性の最後の一歩まで行きたい場合、これも重要な考慮事項だと思います。

言及したいもう一つのことは、今日、私が知る限り、これを行うエージェントはありません。すべての人の最新で最高の機能について完全に最新ではありませんが、今日、ほとんどの人は現在のアクティブコミット、ローカルマシンのアクティブコミットの現在のダーティ状態のみを検索しているようです。

他のブランチ、履歴や他のオープンブランチを参照していません。これは実際に非常に有用だと思われます。特に、2つのエージェントが別々のブランチで類似の機能に取り組んでいる場合、ある程度協調して、後で人間に要求されるばかげたマージコンフリクトを作らないようにすべきです。

ちなみに、それらをリアルタイムで同時にクエリできる必要があります。それらは別々の検索インデックスであり、どうやってそれを行うかを考える必要があります。

私たちは、forkingと呼ばれる一つの機能を構築しました。特定のコレクションに対して、100ミリ秒未満でそのコレクションのコピーを作成できる機能です。これにより、再インデックス化のコストと時間をスキップでき、ダーティ状態のdiffや、検索したいコミットをそのインデックスに配信するだけです。

また、増分ストレージに対してのみ支払い、増分に対してのみ支払うため、ストレージでも大幅に節約できます。多くのAIコーディング会社が、このような方法でChromaを具体的に使用しているのを見ています。彼らは大量のforkingを行い、検索するコレクションの大量のforkを作成しています。

言及したいもう一つのことは、作業しているコードを検索するだけでなく、コードが依存しているオープンソースの依存関係を検索することです。有名なXKCD漫画を見たことがあるでしょう。依存関係のタワーです。

今日、将来的にはLSPまたは他の方法を介してかもしれませんが、今日のほとんどのAIコーディングエージェントは、参照をクリックして実際のAPIリファレンスを見に行かないようです。

FastAPIやReactのそのバージョンを使用している場合、モデルがそのような巨大なライブラリについて知らないため、ハルシネーションの可能性が高まります。FastAPIやReactのような場合、モデルにその特定のバージョンでAPIは何かと尋ねると、答えられるかもしれません。試したことはありません。しかし、ロングテールは本当に困難だと思います。

コーディングでエージェントの信頼性を向上させるには、リファレンスを見させ、オープンソースの依存関係を見させる必要があります。しかし、エージェントのためにgit cloneしてnpm installして5分待つことを常に望むわけではありません。そのため、それらも事前にインデックス化される必要があり、素早くそこに入ってコードを書き始めることができるようになります。

Chromaの新機能とコレクションの概念

時にはすでにminifyされているため、インストールしても良いドキュメントが得られません。その通りです。

これはChromaが積極的に取り組んでいる努力ですか。

はい、そうです。

いつ公開される予定ですか。

おそらく1〜2週間後です。実際に私たちはちょうどリリースしました。これを公開するまで待つことができます。コードコレクションと呼んでいるもので、npm、PyPI、Rust用のcrate、Goの全主要オープンソース依存関係をインデックス化しました。すみません、cargoとGoです。さまざまなリリースタグで検索できます。

それは素晴らしいですね。バージョンを固定して、このマイナーなパッケージのこのバージョンでどのAPIがサポートされていたかを教えてもらえますか。

基本的に、エージェントにより多くのツールを与えているだけです。この正確なパッケージをこのリリースタグで検索したいと言えば、ripgrep検索、セマンティック検索、両方を行うことができます。ファイルベースの検索、メタデータもできます。すべてそこにあります。

それは非常にクールです。このforkableコレクションのアイデアを再訪したいと思います。これは実際にパターンだと思います。エージェントとコーディングなどの分野の多くの人々と話しましたが、これは繰り返し出てくるアイデアです。

エージェントは将来的にRLを行うもののようで、エージェントツールで自分自身をforkできるようになるでしょう。作業しているアーティファクトも同様にforkable場合は、VMかもしれません、git状態かもしれません、明らかにスタッキングPRなどがありますし、コレクションは多くの意味を持ちます。

あなたが説明していることは、コードベースをインデックス化したい状況で、異なるgitブランチで異なるコレクションがあり、何らかのcopy-on-writeで非常に簡単に新しいコピーを立ち上げられるということです。

実際にgit自体にそれを持ち込んで、各コミットに対してdiffを格納した検索可能インデックスのようなgit拡張を持つ将来はあるでしょうか。

Linusを怒らせることは確実にしたくないと思います。そのレベルでの統合について、インデックスのサイズという観点で、桁数はどのくらいになりますか。実際のコード自体よりもはるかに大きいでしょうか。

多くの変数があります。どのようにチャンクするか、どのサイズのembeddingモデルを使用するか、量子化するかなどです。それが主な違いや課題です。どの程度大きくしたいか小さくしたいかに応じて設定可能だと思います。

それは非常にクールです。Gitは大きなファイル管理が得意でないことは知られています。Git LFSを使ったことがある人は二度と使わないでしょう。可搬性は確実に多くの意味を持ちますが、コードと一緒にインデックスを出荷したいでしょう。

また、エージェント実行時にネットワーク上で大きなファイルを移動したくもありません。遅くて高価になってしまいます。リモートで検索して、必要なデータだけを取得し、インデックス全体を移動したくありません。そのため、それが主要なパターンになることはないと思います。

異なるコミット間での検索とディープリサーチ

私が思考を刺激すると思ったもう一つのことは、異なるコミット間での検索というアイデアです。あなたは絶対に正しいです。開発者として機能を実装するよう言われたら、他の人のものを見に行くつもりはありません。今日、私のマシンにあるコードを見始めるだけです。

しかし、それはバックグラウンド調査を誰かに派遣したいタイプのクエリのように思えます。おそらく、過去のインスタンスをコードベースで探すだけの専門エージェントがいるでしょう。Git考古学を行い、すべての以前のブランチを見て、「ああ、実際に過去にこれをやったことがあるが、メインのエージェントスレッドの前進をブロックしない」というものを見つけるでしょう。

これはデータベース自体に組み込むことができるタイプのもののように思えます。「Xのすべてのインスタンスを見つけて」と言えば、「今日のこのコミットのコードベースでは、これを見ています。しかし、バックグラウンドでの非同期クエリも」と速い応答をしてくれるでしょう。

マルチティアードのようなアプリケーションについて考えますか。

良い質問です。これについて考える一つの方法は予算です。一部のクエリでは、非常に少ないお金や時間、またはその両方を費やしたく、非常に速く非常に安く答えたいのです。他のクエリでは、正しい答えを得るために概念的に多くの時間や多くのお金を費やしても構いません。

それは、このようなバックグラウンド検索エージェントの範疇により入ると思います。人々が使う用語はディープリサーチだと思います。これは一種のディープリサーチ的なことです。その用語は好きではありませんが、人々がそう呼んでいます。

なぜダメなのですか。ディープリサーチの何が問題なのですか。

わからないです。何の意味もないもう一つの愚かな用語です。仕上げラインを最初に越える会社が用語を作る権利を得ると思います。残念ながらディープリサーチが最初でした。

誰か仕上げラインを越えた人はいますか。ディープリサーチを使ったことがあるでしょう。何かについて知っていることについて実行すると、この結果は非常に中程度で、微妙だが意味のある方法で10〜15の異なる場所で間違っているという感じです。

それがあなたが何かについて知っていることに対して良くないなら、なぜあなたが知らないことについて信頼すべきなのでしょうか。

私の経験は同じではありません。PhD レベルの研究を期待している質問はしていないと思います。むしろ、CNNやPyPIパッケージなどから関連リンクを取得したクイックブックレポートのようなものを探していて、出力を見ると実際に正しい答えを得たことが確認できます。

しかし、困難な問題を尋ねたら、それを得ることができないだろうということに問題はありません。

それはすぐに解決されると思います。

私は、実際に30分ほどかかるエージェント的タスクを完全な消費者向け方法で実行しようとした最初の製品の一つだったと思います。それ以前は、実際には5分程度実行されるChatGPTしかありませんでした。そのため、その理由で、ChatGPTやGoogle、または最初にそれを立ち上げた人に敬意を表し、「ディープリサーチ、素晴らしい、あなた方が名前を選ぶ権利を得た」と言いたいと思います。

しかし、ディープリサーチもありますが、マルチティアード研究もあります。つまり、尋ねた質問について更新された情報で私に割り込んで戻ってくる能力を指定できるべきです。どのように進んでいるか、何について考えているかのステータス更新やレポートをストリーミングトークンバックするだけでなく、追加の支援が必要な場合には明確化を求める可能性もあります。

今日のディープリサーチタスクでも行わないようなことです。例えば、ChatGPTでディープリサーチがどのように動作するかの私の理解では、使用すれば明らかですが、質問するようにハードワイヤードされています。最初に常に質問します。おそらくできるか、すべきなのに、他の質問を決して尋ねないことに気づくでしょう。それは変わるでしょう。

顧客が私たちに求めることは何でもします、というのが要点です。今日、そのパラダイムはまだ十分に一般的でも人気でもないことがわかっていないため、人々が私たちにそれをして欲しいと思っています。

おそらくそれは主に、これらのものがまだ安定しておらず、変化率が非常に高いため、人々が当然ながら非常に直接的に自分の管轄に置いておきたいという成熟度についてです。標準化され、よく理解されるようになってから、それを外部委託することで、速度、コスト、信頼性、運用の複雑さの利益を得られるようになるでしょう。それが私の推測ですが、そう言えると思います。

エージェント実行時間の長期化と並列処理

今日本番でこれが見られない理由の一つは、エージェントが実際に何か価値のあることを行い続けることができる最高水準や最大長が1〜2時間の間であり、その半分が単なる研究で、調査するサブエージェントを生成するのであれば、メインエージェントスレッドにそれをやらせるべきだからです。

しかし、これらのエージェントが10時間、または24時間などで実行されることを予想すると、実際に確認可能な情報を持って戻ってくる小さなミニディープリサーチエージェントを生成することが意味を持つようになります。

私はそれが好きです。メインスレッドの長さが長くなるにつれて、サポートできるエージェンシーのサイズはほぼ確実に上がるでしょう。なぜなら、実際に行うべきことがもっとあり、それを活用できるからです。

企業への直接的な類推のようなものがあると感じています。明らかに破綻点があるでしょうが、少なくとも相関関係として、大きな会社ほど、理論的には将来をより遠くまで見る能力があるということです。すべての大企業が将来を遠くまで見るわけではありませんが、理論的には将来を見る能力があります。

メモリ機能と記憶システムの課題

私たちは検索について多く話してきました。コードや、SlackやSlackの情報のような人工物の検索について話しました。これは明らかに波がまだ来ていないと思いますが、これから巨大な生産性向上がもたらされるでしょう。

検索で最も頻繁に引用される興味深いユースケースの一つはメモリです。実際の読み取り部分だけでなく、まず何を覚えるかを決定する書き込み部分でもあります。あなた方がこれについて多くの時間を費やして考えてきたことは知っています。

そこで意見をお聞きしたいと思います。動機となる質問として、今日実際に良いメモリのアプリケーションは何だと思いますか。どこで成功し、将来的にそれらのアプリケーションは何になると思うか、そしてそれをどのように実現するかについて。

広く言えば、まず第一に、メモリは技術ではありません。メモリは、一般人にとって理解可能な技術の利益です。あなたのお母さんと私のお母さんは、メモリとは何か、何を意味するか、なぜ直感的に有益なのかを理解できます。

それは検索にも当てはまるかもしれませんね。「ああ、メモリ。なぜそれが良いのかわかる。エージェントにメモリを持たせたい。」それは理にかなっています。実際にこれを実装している実践者にとって、読み取りパスは単なるもう一つのコンテキストエンジニアリングパスです。

関連する履歴情報を取得し、何が重要で何がそうでないかを決定し、それをコンテキストウィンドウに入れて使用するということです。書き込みパスが興味深いのです。システムは何を覚えるべきでしょうか。

広く言えば、システムは手元のタスクでより良くなることを可能にする任意のことを覚えるべきです。それが一つの考え方です。エージェントの継続的なオンライン学習のようなもので、これが私の心の中でのメモリの目標です。

それを分解していくと、分解すると、偽の階層や二分法を作り、より多くの脳腐敗を作る可能性があります。エージェントタスク学習とユーザーパーソナライゼーションの間には有用な区別があると思います。エージェントタスク学習は、このエージェントが特定のタスクでどう良くなれるか。ユーザーパーソナライゼーションは、エージェントがこのユーザーにサービスを提供することでどう良くなれるか。

もちろん、ユーザーにサービスを提供することも最終的には単なるタスクです。それを2つの大きなバケツに分けることは直感的です。

エージェントタスク学習については、SweetBenchについて話したときに少し話しました。過去の成功、過去の失敗について、エージェントがそれらを参照してより良くなることができるかという実験でした。そして、これは超自明ではないことが明らかでした。アクセスを与えて終わり、夕日に向かって去るというわけにはいきません。

ビーチでネクタイを締めて座るわけにはいきません。実際には、少なくとも今日では、それよりもはるかに困難です。それは続けて非常に困難だと思います。

ユーザーパーソナライゼーションは、より実現可能で、よりアクセシブルに感じます。私のTypeScriptをこのようにフォーマットしてほしいということを覚えておくか、コーディング例として、新しい関数を書くたびに常にテストを書くことを覚えておくか、などです。

ユーザーパーソナライゼーションも、ユーザーインストラクションのようなもの、私の好みです。ただし、理論的には、私は乳糖不耐症なので、ロンドンへの旅行を計画している場合、アイスクリームを食べに行くことを提案しないでほしい、といったようなユーザー消費者ストーリーも実際の効用があると思います。

ChatGPTのメモリ機能は、ある程度物議を醸しています。一部の人にとっては、深い精神病状態に陥らせ、文字通り狂わせるようです。私を含む他の人は、管理したく、漏れを望まないため、単にオフにしています。

まだうまく行われていないと主張することは、論争的または逆張り的な意見ではありません。昨日言ったことを忘れるAIの妻ほど私を怒らせるものはありません。私は彼らに共感します。それは面白いというジョークを作ることは避けます。

メモリシステムにおける取捨選択

何を覚えるかを選ぶことはかなり興味深いです。ある程度では選ぶ必要がないかもしれません。収集と選別の情報検索パイプラインで、すべてを覚えて、後で広く、知っていることすべてから、ここのコンテキストに引き込むべきものを決定できるかもしれません。

それは特に事実情報でうまく機能するかもしれません。特にユーザーがXを覚えてください、Yを覚えてくださいと明示的なことを言う場合です。

これは現在、WindsurfやCursorがどのように行っているかだと思います。何かを言うと、それを覚える魔法の言葉のようなものがあります。それで十分だと実際に思います。製品のUXについて、物事をどう覚えるかについて、ユーザーに最小限のユーザー教育を教えることは、ボタンをクリックしてもいいですし、なぜいけないのでしょうか。

エンドユーザーからそのレベルの構造化データを取得することは、多くの問題を解決してくれます。完全にバックグラウンドで暗黙的な方法で行うことは、はるかに困難で、ユーザーが自分の好みについて非常に明示的であることと比較して、それほど価値がないかもしれません。

それはポイント事実やポイント情報ではうまく機能します。これらのすべての好み データをテキストファイルに入れて、テキストファイルをすべてのプロンプトでコンテキストに投げ込むだけであれば、それは愚かです。愚かだけでなく、うまく機能しません。それが私の意味です。

そのようなことはすべきではありません。コンテキストに何を入れるかについては、やはり識別力を持つべきです。無関係または間違った大量のものを与えてしまうということですね。

私が使う例は、最終的により良い例を見つけるかもしれませんが、パリへの旅行を計画していて、先月プラハに行き、プラハではピンボールミュージアムに行ったとします。おそらく私はピンボールが好きで、だからパリに行く今、パリにピンボールミュージアムがあれば、それについて教えてくれるはずです。

明らかに、それは本当に重要なことですが、ウィスコンシンの祖母の湖で子供時代を過ごし、今パリに行くとすれば、子供として湖に行ったから、この湖をチェックすべきだとは言うべきではありません。いいえ、それは重要ではありません。

しかし、エージェントにとって何が重要で何がそうでないかを識別することは困難だと思います。

それに対する優しい反論は、それは検索後の問題ではないかということです。すでにこれらの記憶をすべて取得しています。エージェントは識別して、「わかりました、これは湖の家ですが、彼は5歳でした。今彼は大人で、」と言うことができるはずです。願わくば大人になって欲しいものですが。

それは今日経験的にうまくいかないという安定した前提ではないようです。

興味深いです。追加しようとしていた微妙な点は、ポイント事実情報は今日持っている技術によくサービスされる可能性が高いということですが、OLTPではなくOLAPのような長期分析、ポイントクエリではなく集約について考えてみてください。

エージェント氏/夫人が現在同じような似たタスクを45回行いました。46回目のように、これで良くなるにはどうすればいいでしょうか。システム指示をどう調整すべきでしょうか。アクセスする情報や、それにアクセスする方法をどう調整すべきでしょうか。次回この作業でより良くできるように、自分の重みをどう修正すべきでしょうか。

その問題は非常に未探索で、解決されていないと思います。

今日本番で認識している記憶のすべての実装は、to-doリストに書いたり、どこかのデータベースに保存して後で取得するといったものです。これがモデル自体に組み込まれない根本的な理由があると思いますか。それはどのようなものでしょうか。

想像できる一例は、監査性が欲しいということです。何かを覚えるたびに、Notionドキュメントで見ることができる、またはPostgresのUIで見て、無関係なものを削除できるはずです。モデルの重みに実際に組み込まれている場合は、良いアイデアではありません。

しかし、タスクの実行方法についてのバイブベースの理解について話していて、外部データベースに保存する場合は多くの余分なステップを追加しているように思えます。完全に汎用化されたバージョンがどのようなもので成功するかを考えると、おそらく私たちが説明したような生涯学習を行うもので、タスクを実行するたびに何らかのエラー信号を与え、行動だけでなく、実際にメモリ指向の方法で自分自身を更新できるものでしょう。

それは素晴らしいでしょう。監査性の質問は非常に重要です。

応用AI全般における研究の不足があります。ラボは、すべての理解可能なベンチマークを最大化する次の大きなモデルに非常に焦点を当てています。それが注目と資金と才能を集める方法だからです。

これらのベンチマークが実際に何か意味があるか、実際に役に立つか、気にすべきかは重要な質問ですが、誰も尋ねないようです。AIを使って有用なものを構築している SaaS層の人々がいますが、優秀な応用研究を行う時間や組織図やスキルがありません。ここにはギャップがあると思います。これが最初に言いたかったことです。

ファインチューニングは非常に有望だと思います。特に、そのファインチューニングが簡単にロールバック可能な場合、LoRAのような形のものです。ほぼ状態のツリーが欲しくて、非常に簡単にロールバックでき、本番で簡単にホットスワップできるものです。

エージェントをフォークすることの議論に戻りますが、一つのエージェントがいくつかの記憶を構築できますが、戻ることもできます。それは、実際にモデルのパラメータではなく、外部データ構造があるべきだと思う非常に重要なことです。そのため、言及したようなLoRAを非常に簡単に入れ替えできます。

メモリの実用的応用例

メモリのアプリケーションについてですが、熱心なエージェントユーザーとして気づいた注目すべきことの一つです。ChatGPTとClaudeが今日ローンチしたと思いますが、以前のことに応答できて、「ああ、あなたはソフトウェアエンジニアですね」と言って答えをくれるでしょう。おそらく以前のチャットから多くの文書を取得する何らかの形を行っているのでしょう。おそらくそれらは蒸留されて、それに示されます。

今日、エージェントで実際のメモリのアプリケーションの他の例は、いくつかのコーディングエージェントで見たことがあります。

Cursorは先ほど少し前に言及したように、あなたのチャットを見てセカンダリモデルがあって、「これは記憶に値するかどうか」と言って記憶を提案するものをローンチしたところです。かなりひどいです。正直に言うと、少し使ってみました。

提案している記憶は「ああ、あなたは常にこの絵文字をロギングで使うのが好きですね」のようなものです。「まあ、この特定の事例でそうしましたが、」と言いたくなります。そして、それが解決できないと主張するわけではありません。適切なコンテキスト管理とエンジニアリングがあれば、確実に何か良いものが得られるでしょう。特に人々がボタンをクリックしてこの具体的なフィードバックを得る場合は。

しかし、メモリが実際にエージェントと相互作用するユーザーのエクスペリエンスの観点で針を動かす例はありますか。

直感的に、私たちはエージェントが人間レベルまたはそれ以上で実行することを望んでいます。人間に何かをするように教える方法を考えるだけで、実際にはユーザーマニュアル全体を書いて、教科書全体を書いて、人間にそれを読んでもらって、ただやってくれることを期待することは可能ではありません。

実際には、どんな仕事も徒弟制モデルで、多くの暗黙知が必要です。職場訓練と呼ばれるもので、従業員や一緒に働く人々に、これをもっとやって、これをもっと少なく、このようにやって、あのようにやってというフィードバックを与えています。

エージェントが人間と同じくらい信頼性が欲しいなら、それもエージェント領域に存在する必要があります。エージェント自身が自分自身に自己批判的なフィードバックを与えることもできるし、当面の間はもっと可能性が高いのは、人間がエージェントにこの反復的なフィードバックを与えることです。次回は何をするか。

それは解決すべき非常に大きくて重要な問題のようです。その問題を解決できれば、AIエージェントの信頼性が大幅に向上すると思います。

ユーザー行動の発達とメモリ機能の普及

それがどの程度、開発する必要がある消費者行動でしょうか。この質問の前置きとして、2年前にコーディングエージェントで作業を始めました。人々は効果的な使用方法がまったくわからなかったのです。「ああ、私のコードを修正して」のようなタスクを与えていました。

GPT-3のローンチから現在までの中間期間で、これは私が因数分解して、エージェントにやらせることができるタイプの問題だという、ユーザー行動の一種の根付いた顧客行動が本当にあります。

覚える価値があることとこの筋肉を構築すること、積極的な知識キュレーションと言えるような、ユーザー自身にまだこの筋肉がないように思えます。メモリの成功した展開に対して、それが実際にどの程度ボトルネックだと思いますか。

わからないです。様子を見ましょう。確実に良くなることができると思います。多くのユースケースで、何らかの活性化ポイントに到達するのに十分良くなるかどうかは未定です。

ChatGPTに覚えるか覚えないかと言うものがあり、普遍的に受け入れられたUXメカニズムがあったと想像します。そうなれば、メモリがはるかに広く展開されることになるでしょう。新しい製品をローンチしている場合、メモリ機能が組み込まれることを期待できます。実際、人々はそれを期待するでしょう。

それは正しいと思います。OpenAIには最も最小限で、可能な限り最小限のDXまたはUXというような精神があると思います。大衆消費者向けプレイには、明らかに彼らが追求しているもので、おそらく正しい判断だと思います。

しかし問題は、彼らはまた、AIUXがどうあるべきかの思考リーダーと見なされていて、その結果、誰もが彼らが行っていることを自分のものにカーゴカルト的にコピー＆ペーストしているということです。そして、AI UX内のイノベーション量は、ちょっと恥ずかしいレベルです。

人々はもっとやるべきですし、これを聞いているなら、もっとやってください。

チャットがエージェントや人間エージェントの相互作用、人間LLMの相互作用の最終パラダイムではなく、より良いことをする必要があると人々が言っていた期間がありました。私たちはその波に乗って上がり、今は下がってきて、人々は「実際にチャットはかなり良い、過去2年間で他の多くのことを試したが、同じ方法では何も本当に定着していない」と言っています。

チャット以外のインターフェースの可能性

なぜそうなのかについて何か考えはありますか。

チャットは人間が理解する良いUXだと思います。なぜなら、私たちは常にチャットをしているからです。そのため、その理由で非常に直感的です。しかし、すべてのパワーツールが直感的というわけではありません。定義上、パワーツールは通常直感的ではありません。それらの力を解き放つためには、それらを学ぶ必要があります。

コーディングのようなものは、パワーツールの良い候補で、基本的なチャットではもう十分ではない可能性がある良い候補です。そして、すでにある程度それを見ていると思います。ファイルをタグ付けしたり、追加のコンテキストを与えたりできます。ツールを作成したり、ツールへのアクセスを与えたりできます。やれることがあります。

人々がチャットでは十分ではないと言うとき、最初にジャンプすることは、ブランチングチャットが欲しいということです。突然、Reactで何らかのリアクティブノードダイアグラムを作っています。決して機能しません。ただ決して機能しません。歴史上決して機能したことがありません。ただ決して機能しません。

2025年、いいえ、2035年には機能するかもしれません。しかし、ただ決して機能しません。

これについて考える一つの方法は、エージェントが任意の時点で何をしているかについて、専門家の人間により良い情報と直感をどう与えるか、そして人間にそのエージェントの行動をリアルタイムで当然修正、改良する能力をどう与えるかです。それがどのようなものかは、誰でも推測です。

ブランチングエージェントについて明確にしておくことが重要だと思います。ブランチングエージェントは確実に起こるでしょう。実際、すでに起こっています。Claude Codeはその良い例です。しかし、それでも、人々はそれを線形チャット履歴に描画しています。なぜなら、人間にとって理解しやすいからです。

その通りです。おそらく、人々に役立つような視覚化がありますが、ただ定着していません。

対談のまとめ

これで終わりにするのは良い注意点だと思います。時間を取っていただき、本当にありがとうございました。Chromaで行っているすべてのことについて聞くのは非常に興味深く、私をお招きいただき感謝します。

これは素晴らしかったです。ありがとうございました。

コメント

タイトルとURLをコピーしました