Google DeepMindによる最新研究で、ベクトル埋め込みシステムの根本的な数学的限界が明らかになった。従来のRAGシステムで使用される単一ベクトル表現では、複雑なクエリに対して幾何学的に解決不可能な制約が生じることが理論的・実証的に証明され、最先端の大規模言語モデルでも単純なキーワード検索で失敗することが示された。
ベクトル埋め込みの新たな限界の発見
こんにちは、コミュニティの皆さん。戻ってきてくれて本当に素晴らしいです。今日は全く新しいトピックについて話します。それはベクトル埋め込みについてです。そして皆さんは「なんだ、この古いトピック」と言うかもしれませんね。そうです、なぜなら2025年8月末に、Google DeepMindによるベクトル埋め込みに関する全く新しい研究論文が発表されたからです。
そして皆さんは「どうしてそんなことが可能なの？私たちは埋め込みについて全てを知っている」と言うかもしれません。いいえ、埋め込みはAIにとって不可欠なものです。私たちには意味的類似性があります。RAGに関する全てがベクトル埋め込みで動作します。すべての情報検索もベクトル埋め込みに基づいています。RAGシステムを持つ前から、意味的類似性のためのベクトル空間さえ持っていました。想像できますか？そうです、古き良き時代には、それは文変換アーキテクチャと呼ばれていました。
そして皆さんは「何について話しているのか？」と思うでしょう。私たちは限界について話しているのです。限界は、Googleが構築した全く新しい機能で、ベクトル埋め込みで私たちが直面している限界と理論的制限を示してくれます。最初は簡単で、データセットを構築する必要があります。データセットは単純です。RAGのような空の名前付きドキュメントのリストがあります。
そして今重要なのは、46個のドキュメントがあることです。ドキュメントとは何でしょうか？ここでご覧ください。ドキュメントはシンプルです。文章、単一の文章です。ここにEllis Smithがいます。つまり、名前とlikesです。これがドキュメントの全てです。そしてBob Joan likesやJordan Durban likesなどがあります。
そして私たちには、これらの本当に複雑な文章が46個あります。そして定義されたクエリのリストがあります。興味深いことに、Googleは数値的な理由で、後で説明しますが、正確に1,035個のクエリで進めることにしました。そして常に同じ構造です。誰がりんごを好きですか？誰がビールを好きですか？誰がシマウマを好きですか？そして何だと思いますか？接続がありません。何かが欠けているからです。そうです、私たちは今、真実、グランドトゥルースを構築しなければなりません。
私たちは今、言うなれば世界を構築しなければなりません。そこでGoogleは私たちに「事前定義された関連性マトリックスを作ります」と言います。これが私たちの因果的真実になります。なぜなら、私たちは可能な限り最もシンプルなモデルを望んでいるからです。複雑な言語学的なものは使いたくありません。10万の人間の文章でトレーニングしたくありません。
可能な限りシンプルにします。この別の指示を見てください。これはクエリ番号5のためのものです。ドキュメント12とドキュメント34です。これは何を意味するでしょうか？見てみましょう。クエリ番号5。誰がクオッカを好きですか？それは12と34です。この複雑さを解決したいなら、それはJohn DurbanがクオッカをlikesしていることとLesie Lamがクオッカをlikeしていることです。
そして皆さんは「うわあ」と言うかもしれません。そして今、私たちにはこれらの本当に複雑な文章が46個あります。そして皆さんは尋ねるかもしれません。本当にここで何か新しいものを発見すると思いますか？絶対にです。そして魅力的な何かを。これらが私たちの46個のドキュメントで、グランドトゥルースです。これは干し草の山の中の針についてではありません。干し草の山の中の針は石器時代のことです。本当に興味があるなら針チェーンエクササイズもありますが、全くそうではありません。私たちは操作する数学的空間を見ているのです。そしてこれが彼らがこの方法を選んだ重要な科学的理由です。
LIMITデータセットの構築と評価
LIMITは今、このデータセット、この世界、この真実の名前で、美しいのは合成的で制御可能な工学的事実だということです。未定義なものは何もありません。連続的な曖昧さがありません。評価を完璧にクリーンにします。そしてもし皆さんが「これは単なるキーワード検索だ。これは史上最もシンプルだ」と思うなら、そうです、美しいです。
そして今、私たちの巨大なLLM、数十億パラメータのLLM大規模言語モデルの最先端を見てみましょう。そして彼らはこの些細なキーワード検索で失敗するでしょう。そしてその失敗は言語の複雑さのせいにすることはできません。なぜなら解釈で使用する言語、意味論、文脈がLLMにとって複雑すぎるかもしれないからです。
私たちのケースでは違います。今、私たちは絶対的に最低の言語的複雑さにあります。そしてもちろん皆さんは、彼らがここで罠を仕掛けたことを理解しています。そうです。彼らは言語的に非常にシンプルなタスクを作成しました。しかし、ビデオの後半で示しますが、幾何学的に解決することは不可能であることが判明し、それによってそれが幾何学であることが証明されます。
私たちがベクトル埋め込みで直面している真のボトルネックは、意味的項の埋め込みに使用するこの数学的ベクトル空間の限定的な表現能力です。そして今、結果をお伝えします。このモデルと最新の最先端LLMは失敗するでしょう。なぜなら、わずか46個のドキュメントに対するこれらの134個のクエリのフルセット、そしてドキュメントは些細な単一文章であることを覚えておいてください。これが操作する数学的空間に不可能な幾何学的制約のウェブを作成するからです。
現実的な検索タスクにするために、お好みのRAGシステム、クラシカルRAG、何でも、ジャイアントRAGでも構いませんが、彼らは今ここでこのLIMITデータセットを作成します。しかし今、彼らはこれらの46個の相互接続されたドキュメント（つまり文章）を50,000個のドキュメント文章の補完的なコーパスに配置します。
見てください、彼らはこれらの46個の高度に相互接続されたドキュメントを隠しており、それでも氷の中の針についてではありません。そして彼らは「さあ、私たちのモデルを見てみましょう」と言います。今、モデルのタスクは46個の文章を正しくランク付けすることです。しかしもちろん、他のRAGシステムと同じように、データベースから、インターネットから、大規模なドキュメントプールから検索しなければなりません。彼らは実世界の条件を望んでおり、時には「私たちのLLMは非常に賢いので、ドキュメントが本当に短いことを理解し、短いドキュメントや正しいドキュメントを学習する」とも言いました。LLMがカンニングするのを防ぐために、彼らは「パディングをします。46個の文章を正確に同じトークン数まで埋めます。すべて同じ長さになるので、何も示すものがありません」と言いました。
ここが結果です。ここにあります。そして埋め込みシステム専用の美しい色分けされたLLMAが全てここにあります。MistralからSnowflake、Llama、Q3、Gemini、全てです。これを見てください。これを見てください。最後の2つを除いて。点線のBM25、私たちの古い祖父は見ないでください。現代のコールベアラーシステムの点線も見ないでください。それらは忘れてください。
いいえ、私たちはクラシカルLLMに注目します。ここでrecall at 2、これはベンチマークに使用するメトリクスの1つです。そしてここでは0から100%のスコアがあります。X軸では埋め込み次元があります。32次元から4,96次元まで行きます。46個の文章については本当に全く問題ないはずで、残りの文章についても理論的な観点から問題ありません。しかし、パフォーマンスを見てください。私たちはこれらのモデル、Mistral、Llama、Q1、Geminiなど全てが0.0、つまり0.05%にあると言えます。これだけです。
そして「さあ、recall at 10に行こう」と言うなら、私たちは0.01%を下回ります。そしてrecall at 100に行けば、これが何を意味するかすぐに説明しますが、そうすると彼らが20%まで上がっているのが分かります。なぜこうなるのでしょうか？何が起こっているのでしょうか？なぜシステムは失敗しているのでしょうか？つまり、埋め込みシステムは全てここで失敗しています。
なぜでしょうか？そして私たちの祖父BM25を見てください。これが見えますか？これは可能でしょうか？100に近く、90%を超えています。何が起こっているのでしょうか？そしてこれがGoogleによるこの新しい研究論文の美しさです。彼らは「これは検索問題ではない」と言います。これを見て「複雑さは50,000文章中46文章しかないからかもしれない」と考えるなら。
つまり検索でLLMが効率的な検索メカニズムを持てないということですが、Googleは私たちに「いいえ、これは検索問題ではない。これは私たちが使用する方法論のベクトル空間の純粋で固有の体系的失敗だ」と教えます。なぜならGoogleが狡猾にも「49,000程度のドキュメントを忘れよう。私たちの世界はこの46個のドキュメントバージョンのみで構成される」と言うからです。
この46個の文章、シンプルで短い、これが全てです。他は何もありません。これらがRAGのドキュメントです。そして今、システムにクラシカルRAGタスクを実行させ、再ランクなど何でもさせるなら、AMがまだそれを解決できないことを示します。そして私の運用経験から言うと、私のRAGシステムはインターネットから、データベースから、私のデータベースサーバーから持ち帰られる何百もの文章を扱わなければなりません。
そして今、私たちは46個の文章を見ているのに、今日持っている埋め込み用の最高のモデルが、recall at 2でも60%まで上がることさえ失敗しています。すぐに説明します。データがここにあります。今46個の文章しかない、他は何もないと言うなら。recall at 2で、私たちは40%未満で、1つが50%を超えて上がってきています。
recall at 10で、そしてrecall at 20で、私たちの祖父BM25まで上がり始めます。何が起こっているのでしょうか？なぜRAGベクトルシステムでこのようなパフォーマンスに直面するのでしょうか？なぜこのようにひどいパフォーマンスなのでしょうか？
Recall指標の詳細説明
さて、これは何でしょうか？recall at Kは、AIが私たちに教えてくれる全てのことについて、単純に質問に答えます。今、私の46個の世界で見つけるべきものの中で、ランク付きリストの上位、例えば2位以内で見つけた割合は何でしょうか？K等しい2の場合、これがK等しい2です。これはGoogleが研究で言ったことです。例えば「誰がクオッカを好きか」というクエリに対して。
50,000個でのテストでは、コーパス全体での総関連ドキュメントは正確に2つです。このビデオの冒頭で示したように、LIMITデータセットで定義したゴールデントゥルースとして、クオッカをlikeする名前が2つあります。そして今、モデルの仕事は50,000個全てのドキュメントを見て、正しい真実である2つを一番上に配置することです。
つまりrecall at 2です。システムが戻ってきたランク付きおよび再ランク付きリストから全て決定して、正しい結果が2つしかないとします。今、彼らは正しく返された結果の量は何かと言います。doc JohnとdocLeslieの代わりに、上位2つの結果がdoc Johnとdoc Oitなら、1つだけなので50%です。
そして多数のクエリに対してこれを行い、多くのクエリがあることを覚えておいてください。それを合計して平均スコアが60%未満なら、recall at 2の測定で、これはモデルが正しいドキュメントの1つ以上を、私たちのRAGシステム、情報検索で返される上位2スロットに配置することに失敗していることを意味します。
もしここで弾丸があって素晴らしいとして、recall at 5と言うなら、答えを着地させることができる5つのエリアを与えます。あるいは「あなたのために大きくします。今ヒットできる巨大なエリアを見てください」と言います。これがrecall at 10です。1、2、3、4、10の可能性があるからです。しかし、1つのクエリに対して正しい解決策が2つしかないことを覚えておいてください。これが世界の定義方法、真実の定義方法だからです。
つまり、recall at 5からrecall at 10に行くとき、私がすることは成功ゾーンのサイズを変更することだけで、システムに「聞いてください、recall at 5で見つからないなら、recall at 10を見てみましょう」と伝えます。おそらく上位10位以内で、正しい2つのステートメントを見つけるでしょう。
あるいはrecall at 100を見たなら。ドキュメントの最初の100ランク位置を見るだけです。2つが100内にあるかもしれません。そうしたら「成功」と言います。
テキストで再度見たいなら、クエリ番号5、私たちはウォーカーをlikeし、定義されているように12と34です。リスティングがあり、recall at 2を行うなら、正確に1位と2位をカウントし、1つしかないのが見えるので50%です。recall at 20と言って上位20ランキングと再ランキングと再々ランキングなど何でも見て、最初の20に正しい2つがあれば100%パフォーマンスと言います。しかしもちろん興味があるのはrecall at 2です。
ベクトル表現の幾何学的限界の理論
これでGoogleによるこの美しい例で疑いなく証明されました。問題はスタック内のドキュメントを見つけることではなく、必要な関連パターンを表現する本質的な無能力にあることが証明されます。recall at 20で高いパフォーマンスがあっても、モデルが優れているわけではありません。評価指標がより厳しくないだけです。
「上位2要素は返された最初の20要素内でランク付けされるべきだ」と言うだけです。GoogleによるLIMITの目標は、小さく絶対的に制御された言語環境で幾何学的に不可能なシナリオを意図的に作成することでした。ここでいくつかの組み合わせをサンプリングする代わりに、彼らは本当にモデルにすべての組み合わせを表現することを強制することを決定し、ベクトル空間でその基本的な表現能力をストレステストしています。
私が毎日していることを考えずに行っていますが、理論物理学などの私のドメインで私自身の複雑さを持つ私自身のベクトル空間を構築しています。そして今、これがある時点で幾何学的に不可能だという限界があります。
「しかし、モデルを見てください。おそらくモデルは最新ではないでしょう」と言うかもしれません。いいえ。MR 7Bは、何だと思いますか？基盤モデルとしてのMR 7B LLMです。そして埋め込みのためにファインチューニングされました。
Llama 38B。何だと思いますか？はい、ご存知ですね。Geminiモデル、Geminiファミリーの特殊化されたモデル、埋め込みタスク用にファインチューニングされました。Q3埋め込みやSnowflake埋め込み。何だと思いますか？はい、ご存知です。強力な最先端LLMが最先端テキスト埋め込み器用に適応され、具体的にトレーニングされています。
「ちょっと待ってください」と言うかもしれません。つまり、LLMではないということですか？もちろん違います。標準のLLMは、46個の文章やドキュメントのような文章の単一の整然としたベクトル表現を置きません。なぜなら、これを行いたい場合は、LLMにアーキテクチャの変更を加える必要があるからです。
文章内のすべてのトークンに対してLLMから最終隠れ層出力を取り、それらを一緒にプールして単一の固定サイズベクトルを作成する必要があります。そしてこれをご存知でしょう。これは私たちがCLSトークンの隠れ状態を取るか、すべてのトークンの隠れ状態を平均化するか、重み付き構造や重み付きシーケンスで行くかの一般的な方法です。
どのようにエンコードしたいかは関係ありません。一貫していれば一貫性のあるエンコーディングがあり、このLLMに特別なファインチューニングがあります。これは古い時代から対照学習と呼んでいたものです。用語に馴染みがないかもしれませんが、関係ありません。これがキーステップです。なぜなら今、私たちのドメインの知識をLLMに与え、ファインチューニング用の新しいデータセットを提示するからです。
このデータセットは、ここで見るように非常に特定の構造を持っています。クエリ、ポジティブパッセージ、ネガティブパッセージです。これは私たちがAIに提示するトリプレットであり、これが私たちのファインチューニングデータセットです。
これでLLMは、私たちの意味的・言語的にどの専門用語やドメイン用語が近くにあるべきか、類似しない意味ペアなのでベクトルをどこでさらに離すべきかを正確に学習します。このプロセスに馴染みがあることを願いますが、これはモデルの言語の内部理解を再構築し、LLMにインテリジェンスをエンコードします。
つまり、私たちがすることは、テキスト生成ではなく類似性比較のために最適化することです。これがAIです。もちろん「これを知っている。あなたのチャンネルには2年前から文変換システムやE-SPERTアーキテクチャについての50以上のビデオがある」と言うなら、絶対的に正しいです。
これらは、E-SPERTアーキテクチャの現代版で、少しスケールアップされ、改善された表現学習を持っています。古いE-SPERTシステムは2年前のものですが、これは絶対的にそうです。しかしこれは今、より良いモデルの孫と言えるでしょう。常に古いものに戻ってきます。
お話ししてお見せしたように、私は私自身の高度に専門化されたベクトル空間で操作するLLMで、私自身のモデル、私自身の埋め込みを構築することを好みます。理論物理学のようなドメイン知識でのみ作業し、私がタスクで操作する意味的項と専門用語の表現でこれらのベクトル空間を最適化しているからです。
私が微調整されたLLMでベクトル空間を使用する場合、私のタスク用のトリプレットをここで最適化しました。なぜでしょうか？非常に小さいからです。理論物理学のサブブランチがある場合、この特定のトピックの理論物理学や数学について、200の出版物、500、おそらく合計1,000の出版物しかありません。極めて限定的なドメインです。
では、私は行くべきでしょうか、そして他の皆も商業会社による商業ベクトル空間を購入することができるでしょうか？彼らは何千、何十万、何百万の人々が何千、何百万の異なるタスクに使用するためにこれを売ってくれます。つまりこれは皆のための全てです。
しかし私は、パフォーマンスが素晴らしい高度に専門化されたベクトル表現に自分を制限しています。なぜなら、それは非常に限定的な専門システムだからです。しかし通常、人々はこれらの商業ベクトル空間で作業します。そこでは10万の異なるタスクに対して1,000のドメイン知識実装で1万のトピックがあります。
私には3つの定義されたタスクがあります。つまり、自分で構築すれば、家のラップトップでこれを行うことができ、全く複雑ではありませんが、ドメイン専門知識において非常に狭く限定されています。
数学的ベクトル空間の詳細分析
数学的ベクトル空間について話しましょう。ついに、私はGoogleによる論文自体のもう少し複雑な表現をお見せするつもりはありません。論文を読むか、論文をAIに入れて、論文の要約をAIマシンから取得してください。もっと深く行きましょう。私たちの理解でもう一歩深く行きましょう。何が起こっているのでしょうか？このビデオでお見せしたかったこの特定のPDFから、AIが教えてくれない主な洞察は何でしょうか？
私たちが扱っているのは、クエリベクトルがあることです。これは私たち人間が持っているクエリで、これがAIに与えるタスクです。つまりクエリベクトルがあります。それをUと呼びましょう。そして関連するすべてのドキュメントを見つけたいのです。インターネットのどこかにあるMCPなど、このクエリに答えるのに関連するドキュメントがあるとしましょう。
人間の言語からすべてを数学的ベクトル表現に変換し、「クエリベクトルがあり、すべてのドキュメントもベクトル空間のベクトル表現でエンコードされているなら、クエリベクトルに類似したベクトルを見るだけでよい」と単純に言います。
これを私たちはAIで何年もしています。これは標準です。これはシンプルです。そして「素晴らしい」と言います。関連するもの間のドット積は、クエリに関連しないものよりも高くなります。これを再配列すると、非常にシンプルな式が得られます。
関連から関連しないものを引いたこの差ベクトルがまた別のベクトルだとして、それをWと呼ぶなら、突然ハイパープレーンの方程式を得ます。x転置*w=zは今、wに直交または垂直なすべてのベクトルxのセットを定義します。高次元ベクトル空間では、このベクトルのセットは原点を通るハイパープレーンを形成します。
この方法論で突然構築されたこのハイパープレーンは、完全なシステムの決定境界として機能します。そして今、等しいではなく、より大きいことに注目してください。つまりこの条件は、クエリベクトルと差ベクトル間のドット積が正でなければならないことを単純に意味します。
最もシンプルな幾何学的解釈では何を意味するでしょうか？これはUとVの間の角度が90度未満でなければならないことを意味します。つまり、ベクトルUはWによって定義されるハイパープレーンの特定の側にある必要があります。突然、データベースからクエリベクトルと多くのドキュメントベクトルを与えただけで、私たちの空間にハイパープレーンができました。
単一のクエリでは、データベースやインターネットなど何でも、完全なコーパスのn個のドキュメントからk個の関連ドキュメントのセットを検索する必要があります。つまり、この1つのクエリuに対して、特定の組み合わせの異なるハイパープレーンの正しい側に同時になければなりません。
これらすべての制約を満たす空間の領域は、実行可能領域と呼ばれます。埋め込みモデル全体では、すべてのドキュメントベクトルvi subNとすべてのクエリベクトルu subMに対して単一の静的位置を見つけなければなりません。そしてここで起こります。
1つのハイパープレーンのセットを定義するクエリ1を満たすためにドキュメントベクトルVAとVBを配置することで、同じVAとVBに依存するが今度は異なるハイパープレーンのセットを定義するクエリ2を満たすことが不可能になる可能性があります。つまり数学的空間で突然、この数学的空間を交差し、この数学的空間を制限する複数のハイパープレーンを構築します。
気づいていない場合、ドット積はコサイン類似性と重要な幾何学的解釈を持っています。ドット積がゼロの場合、コサインゼロに行くとき3つのことのうち1つが真でなければなりません。垂直90度がある場合です。
Googleによるこの証明の美しさは、彼らが構築した制約の密なウェブを作成することで最大限に困難になるように、非常にシンプルなLIMITデータセットを構築したことです。46個のドキュメント、単一文章のセットに対して、あらゆる可能なペアがもちろん何らかのクエリによって検索可能であることを考慮しました。
しかしこれは、私たちのソリューション空間に膨大な数の連動し競合するハイパープレーンを作成します。モデルがこのベクトル空間の生成で、わずか46個のドキュメントベクトルと1,000個のクエリベクトルを持つ空間に配置するように求められ、すべての単一クエリベクトルがその必要な実行可能領域にあるように、システムが本当に100%のパフォーマンスで動作するようになるとき。
論文は理論的および実証的に証明し、お見せしたデータで、これが不可能であることを証明しています。もちろん、彼らは正確に46と1,000のベクトルが、ベクトル空間がばらばらになる時、この運用RAGシステムが不可能になる時を見るスイートスポットになるよう計算しました。このようなすばらしい証明です。自分で見てください。
私も言ったので、皆さんが言うことを知っています。「ちょっと待って。持っているセットを分離するだけです」と言うかもしれません。数学では問題ありません。考えてみてください。これは私たちがすでに解決策として見つけたものです。人間のクエリの複雑さを減らし、最新の新しい埋め込みシステムが自動的にあなたの人間のクエリを取り、複数のより単純なクエリを自動生成するという制限があるため、すでに実装されています。クエリ1.1、クエリ1.2、クエリ1.3があります。
しかし何をしているか考えてください。複雑さの軽減があります。しかし複雑さを複数のより低い複雑さに減らすことが可能だと仮定しています。これが不可能だったらどうでしょうか？このシステムが失敗したらどうでしょうか？しかし動作するとして、できるとしましょう。これを見てください。
クエリ1.1、これはより低い複雑さのクエリベクトルです。そしてクエリ1.2にも別のクエリベクトルがあります。「美しい」と言いますが、私たちがすることを覚えていますか？ベクトル空間で数学的操作を行いますが、推論はありません。クラシカルシステムを考えるなら、これはLLMへの入力としてプロンプトに行く前、LLMがこの追加の外部データで推論できる前です。
つまり私たちがあるのは、情報検索、RAGのR用の数学的構成体上で、LLMの外側で動作しているということです。クエリ1.1の上位200ドキュメントに行き、データベースにアクセスし、これが特定の用語で200ドキュメントを取得し、このシンプルなクエリ1.2に対して別の200ドキュメントを取得し、何でも好きなもので行き、2つにこだわれば、すぐに理解できます。
質問は、これに対してどのような論理演算を行うかです。ANDなら問題ありません。推論は必要ありませんが、起こっていないことを見てください。私が私のドメインで非常に特定の質問をしている場合を考えてみましょう。量子場理論で作業しており、非常に特定の繰り込み係数についての情報が欲しいとします。
理論物理学のアーカイブにあるとしましょう。上位200ドキュメントに入っていません。なぜなら、このシンプルなクエリ1.1に対して、探している単一論文の前に最低1,000ドキュメントがあるからです。
上位200ドキュメントしか検索しないなら、論文を全く取得しません。複雑さ軽減をどれだけ行っても、全く検索されません。検索世界の外にあります。これはすべての単一の低品質または低複雑さクエリベクトルに当てはまります。
解決策は簡単です。何年も前に言ったように、推奨があります。少なくとも上位2,000ドキュメントを検索して、探しているドキュメントがこの検索されるドキュメントセットに本当に含まれるようにします。現在、ドキュメントを見つけるのが非常に困難なため、すべてに再ランクをかける前に、いくつかのドメインで20,000ドキュメントで行っています。これは主流ではありません。
アメリカの最新政治ニュースは何か、誰がヒップか、今日歌手のソングライターが何をしたかを教えてください。これは科学に関わり、特定の情報を探している場合のものです。システムがここで再び失敗することが分かります。
しかしGoogleからの待機があり、彼らは「単一ベクトルクエリでシステムを構築しています。今の解決策は『引用符』です。単一ベクトル高複雑さクエリをマルチベクトルクエリに分解し、この方法で解決策を見つけることを望んでいます」と言いました。今日のシステムはこのように動作します。しかし、お見せしたように、時々失敗するだけです。
トークンあたりの支払いで20,000ドキュメントに行かなければならない場合、本当にすぐに高額になります。そして再び推論がありません。ベクトル空間で類似性、コサイン類似性で操作しています。
ANDロジックを持つこれらのサブクエリがあれば問題ありませんが、今度はORブール論理演算子のケースを取り上げましょう。持っているクエリは「視覚タスク用のトランスフォーマーアーキテクチャまたはタンパク質フォールディングでのそれらの応用についてのドキュメントを見つけてください」です。
OR演算子は何をしているでしょうか？ここで複雑さをより低く、より低い複雑さと複数の複数のクエリに細分化できます。OR演算子をどう扱いますか？再ランキングと再々ランキング、再々々ランキングが必要な大規模でしばしば関連性の低い結果リストにつながる可能性があるセット結合が必要で、これら全てに対して支払いが必要です。
クエリがaとbまたはcなど何らかの組み合わせのようなより複雑なブール論理をここで処理することは、重要なエンジニアリングチャレンジになり、通常システムは失敗します。すでに意味的損失セット交差、私たちが持っている上位K問題について話しました。単一ベクトル検索者をベクトル空間でその破綻点に押し込むRAGクエリのタイプがあると言われています。これがシステムが壊れるところです。
AND演算子だけでなく、AND、OR、NOTがある場合、「トランスフォーマーアーキテクチャについてのドキュメントを見つけてください」のような本当にシンプルなタスクがあれば幸運で、結果を得られるでしょう。しかし「視覚タスク用のトランスフォーマーアーキテクチャまたはタンパク質フォールディング用のこのトランスフォーマーの応用について議論するドキュメントを見つけてください。ただし、Googleからのものは除く」がある場合、これは興味深くなります。
これはクエリベクトルと数学的空間に対して非常に複雑な非凸実行可能領域を定義し、失敗するか、本当に特定のマルチ制約クエリを持つことになります。再び、シンプルに行けば問題ありません。ニューヨークで最高のレストランは何ですか？ニューヨークに初めて行きます。ニューヨークのトップ3レストランに行きたいだけです。
しかし「過去6か月にオープンしたブルックリンのイタリアンレストランで、4つ星の高評価があり、10,000人以上のフォロワーを持つフードブロガーによってレビューされたものについてのレビューを見つけてください」のような少しより複雑なクエリを持つことを想像してください。
各制約が別のハイパープレーンを構築します。そして今、全体のクエリベクトルは、これらすべての半空間の小さな交差に着地しなければなりません。クエリにより多くの論理制約を追加するほど、この交差が空集合になる可能性が高くなり、このRAG、情報検索のRに対して検索が不可能になります。
推論が統合されていない場合は解決できないからです。これは単一ベクトル表現上で非常に困難で、マルチベクトル表現では異なる方法論が必要です。すぐにお見せします。これをお見せしてくれたGoogleに感謝します。私はこれを知りませんでした。
クエリを分解してより強力なシステムを構築することは絶対にできますが、そうすることで論文のポイントをより強くしています。この純粋な単一クエリベクトル対単一ドキュメントベクトルパラダイムを放棄してこれを達成しなければなりませんでした。つまり、より複雑で、よりコストがかかり、より有能なシステムへのアーキテクチャラダーを上がりました。
マルチエージェントシステムのどこかでベクトル表現をまだ使用している場合は、その体系的制限に注意してください。
解決策と今後の展望
今、シンプルでコールドベアが解決策であることは分かっています。1つのベクトルではなく、うまく機能するより複雑なマルチベクトル構造を使用するからですが、固有の制限もあります。しかし、この単一ドキュメントベクトル表現にこだわり、このマルチベクトルモデルを見なければなりません。後のビデオでもっと詳しく説明しますが、ニューラルロジックに基づいたハイブリッドシステムを構築するからです。
GoogleのDeepMind、LIMITをお見せしたかっただけです。GitHubで全てが利用可能です。コードやアセット、データを見たいならすべてがそこにあります。本当に素晴らしいです。
一部の方は「しかし、ちょっと待って、今日までこのビデオをクリックするまで、ベンチマークがありました」と言うかもしれません。これらの埋め込みの古典的で有名なベンチマークの1つを見てください。私たちがいるのは50%、60%、または70%です。
これに何が起こったのでしょうか？まあ、これは私たちがシステムが破綻する重要な破綻点を見ていない埋め込みの特定の特徴、特定の特性をベンチマークしたのです。システムにとってタスクを簡単にしすぎると、簡単なタスクを実行し、問題なく実行します。
しかしマルチエージェントと、私たち全員がより高い複雑さに向かっているより高い複雑さで、AIに答えてほしいより複雑なクエリがある場合、これが現実であり、現在のシステムで持っているパフォーマンスです。これがGoogleがこの美しいLIMITシステムを構築した理由です。recall at 100で想像してください。ブルズアイはありませんが、ブルズアイの周りに100のエリアがあります。
「ここに、最初の100のブルズアイ周辺エリア内にヒットすれば嬉しい。成功としてカウントします」と言います。Snowflakeは3です。つまりポイントは理解できると思います。
美しい研究です。Googleによるプレゼンテーションよりもレベルを深く下げました。これが重要な理由、現在のAIエコシステムでこれほど厳しい制限である理由、ベクトル埋め込みをまだ使用している場合に注意すべき場所について、少し環境をお見せしました。
したがって今日、単一ベクトル埋め込みモデルの証明があると言えます。最も進歩した巨大な、兆の微調整可能パラメータモデルでも何でも取ってください。単一ベクトル埋め込みモデルは汎用検索器ではありません。
今日、限界を知っており、根本的に解決できないタスクが常にあり、これはシステム自体の固有の限界であるため、モデルをスケールアップしても解決策ではありません。これが私がこのビデオでお見せしたかったこの特定のPDFのこの証明の美しさです。楽しんでいただけたなら、ぜひ購読してください。次のビデオでお会いしましょう。
コメント