長文ベクトルモデルは4Kトークンを超えるか？

2025年2月に発表されたNoLiMAは、ラージ・ランゲージ・モデル（LLM）で長文の理解度を評価する方法である。キーワードのマッチングに依存する従来のNIAH（Needle-in-a-Haystack）テストとは異なり、最大の特徴は以下の通りである。 長い文章から答えを見つけることは、モデルに深い意味理解と推論をさせるような質問やキーメッセージを注意深く作ることによってのみ可能になる。

NoLiMa: https://arxiv.org/abs/2502.05167

NoLiMAの結果から、重要な問題が明らかになった。何十万、何百万ものトークンを処理できると主張するLLMは、長いテキストの理解を本当に必要とするタスクでは、著しく性能が劣るのだ。例えば、32Kトークンの長さでは、テストされた10モデルの性能は、短いテキスト（1Kトークン以下）の性能の半分もありません。最も性能の良いモデルGPT-4oでさえ、99.3%という完璧に近い性能から69.7%に低下しています。

NoLiMAにヒントを得て、ベクトルモデルを使用する。 jina-embeddings-v3 同様の実験を行った。ベクトルモデルを調査した理由は、検索拡張世代（RAG）システムでは、検索モデル（ベクトルモデルとも呼ばれる）の良し悪しがシステム全体の有効性を直接左右するからである。

私たちの研究は、2つの中心的な疑問に焦点を当てている：

• ベクトルモデルは長文で "ワンホップ推論 "が可能か？ 従来のNIAHテストでは、設問と解答は通常直接一致する（例えば、"ジョンは何年にパリに行ったか？"と "ジョンは2019年にパリに行った"）。と「ジョンは2019年にパリに行った」）。私たちがデザインした「ピン」とは異なり、意味的に推論するモデルを必要とする（例えば、質問は「フランスに行ったことがあるキャラクターは？）ピン」は「ユキはゼンパー・オペラ座の隣に住んでいる」であり、モデルはゼンパー・オペラ座がドイツにあることを知らなければならない）。
• クエリ拡張機能で長文検索はうまくいくのか？ クエリ拡張とは、クエリに関連する単語を追加して、セマンティクスをよりリッチにすることである。このアプローチが、長いテキストを扱う際のベクトルモデルの欠点を補うことができるかどうかを確かめたい。

従来のNIAHテスト（キーワードのマッチングが可能）とNOLIMAテスト（意味的推論が必要）の比較

LLMの実験結果から、LLMは表面的なテキストマッチングに頼りすぎており、より深い推論が十分でないことが示されている。同じことがベクトルモデルにも当てはまるのだろうか。これによって、現在の意味検索技術に何がまだ欠けているかがわかるかもしれない。

キーメッセージとコンテクストの構築

重要情報の構築

伝統的な「干し草の山の中の針」テストでは、キーメッセージ（「針」）は通常、探している質問と同じような表現になっている。例えば

• 質問：「ドレスデンに行ったことがある人物は？
• キーメッセージ："ユキはドレスデンに住んでいる"

しかし、NoLiMaの論文ではそのようなことはしていないし、したいとも思わない。私たちが見たいのは、意味論に対するモデルの理解であり、単なるキーワードのマッチングではない。そこで、私たちは「シングルホップ」（「シングルホップ」とは、答えと質問がちょっとした推論によって接続される必要があることを意味する）の変種を設計し、意図的にテキストに現れない単語をいくつか使い、また反転した文章を使用した。

• 質問：「ドレスデンに行ったことがある人物は？
• キーインフォメーション（初期設定）："実は、ユキはゼンパー・オペラハウスの隣に住んでいます。"
• キーメッセージ（反転表示）："ゼンパー・オペラハウスはユキが住んでいる隣にある"

この論文の方法論に従い、複数のカテゴリの「質問-鍵メッセージ」グループ（各グループは、質問、「ワンホップ」鍵メッセージ、および「ワンホップ」鍵メッセージの逆バージョンを含む）を生成した。「シングルホップ "キーメッセージ、および "シングルホップ "キーメッ セージを反転させたバージョンを含む）。

以下に例を示す：

💡 上記の名前は一例です。実際の "ピン "では、さまざまな文化圏の名前のリストからランダムに選ばれる。

また、表中の「オリジナルの鍵情報」（つまり、文字通りにマッチしたバージョン）は、あくまで便宜上のものであり、我々の実験では使用しない。

文脈化

少なくとも50,000個のトークンを持つ10冊の公開本を用意し、それぞれの本からいくつかの短い断片をランダムに選び（各断片のトークンは250個以下）、次にこれらの断片をつなぎ合わせて、それぞれ128、256、512、1024、2048、4096、8192トークンという異なる長さの「コンテキスト」を形成する。次にこれらの断片をつなぎ合わせて、それぞれ128、256、512、1024、2048、4096、8192語という異なる長さの「コンテキスト」を形成する。次に、各コンテキストにキーメッセージを入れる：

短いクリップと本からの重要なメッセージで文脈を構築する。

より具体的に言うと、「実は、ユキはゼンパー・オペラハウスの隣に住んでいる」というキーメッセージを、128のレンマからなるコンテキストの50番目のレンマに入れたとしよう：

干し草の山の中の針の例

を使用する。 jina-embeddings-v3 このモデルを使ってテキストをベクトル化し、「重要情報」テキストと「文脈」テキストの類似度スコアを計算する：

Question-Haystack similarity = 0.2391

この類似度スコアの意味を理解するためには、もう一段階「正規化」を行う必要があります。これは、まず、質問とデフォルトのキーメッセージ（つまり、コンテキストなし、直接比較）の類似スコアを計算することによって行われます。次に、前の「キーメッセージコンテキスト」類似度スコアを「質問-キーメッセージ」類似度スコアで割ります：

Question-Needle similarity = 0.3598
Normalized Query - Haystack similarity = 0.2391 / 0.3598 = 0.6644

なぜ正規化するのか？計算された類似度スコアは、ベクトルモデルによって異なる可能性があるからだ。そしてjina-embeddings-v3 モデルは通常、2つのテキスト間の類似性を過小評価する。

各キーメッセージ（デフォルトバージョンとフリップフロップバージョンの両方）について、長さの異なる10個のコンテキストを生成した。同じキーメッセージで同じコンテキストの長さの場合、10個のコンテキ ストは次のようになる：

重要な情報を10個のコンテクストに一定の間隔で配置する

さらに、コントロールのために、各テスト条件（コンテキストの長さが異なる）ごとに、キー情報を含まないコンテキストも生成した。これにより、合計3234個のコンテキストが生成された。

最後にjina-embeddings-v3 モデル（デフォルトのテキストマッチLoRAを使用）は各コンテキストをエンコードする。コンテキストの語彙要素の総数が8192（jina-embeddings-v3モデルの上限）を超える場合は、超過分を切り捨て、対応する質問単位もエンコードする。

指標の評価

我々は、異なる文脈の長さの下でベクトルモデルの性能を測定するために、いくつかの異なるメトリクスを用いた評価フレームワークを設計した：

主な指標

1.正規化類似度スコア

これが核となる指標です。単に質問とコンテキスト全体の意味的類似性を見るだけでなく、質問とキー情報を取り、別々に比較します。これにより、理想的な状況（質問とキー情報が直接比較される）でモデルがどのように機能するかと比較して、キー情報を含むコンテキストでモデルがどの程度機能するかを知ることができます。

具体的な計算方法は、まず基準となる質問とそれに対応するキー情報との間の余弦類似度スコアを計算し、次に「質問とコンテキストの類似度」をこの基準で割って正規化類似度スコアを得る。

2.適当に当てるよりずっといい

ベクトルモデルの場合、同じ質問と異なるテキストの類似性を比較することだけが理にかなっています。そこで、正規化された類似度スコアに加え、同じ長さで重要な情報がないランダムなテキストの一部よりも、質問全体が本当に文脈により類似しているかどうかを確認する必要があります。言い換えれば、私たちはモデルが見つけた答えが本当に盲目的な推測よりも正確かどうかを確認したいのです。

二次指標

1.識別能力分析

この指標は、重要な情報を他の無関係なコンテンツと区別するモデルの能力を見る。具体的には2つの側面がある：

• 平均分離率答えを含む文章（「肯定的な例」）とそうでない文章（「否定的な例」）の差はどれくらいありますか？
• AUC（曲線下面積）スコアキー情報とその他のコンテンツを区別するモデルの能力は、ROC曲線（被験者動作特性曲線）下の面積を計算することで測定される。

2.ポジション効果

また、重要な情報が文脈のどこにあるかによって、モデルがその情報を見つけやすいかどうかも検証する。分析する：

• キー情報の位置と類似度スコアの間に関係（相関係数）はあるか。
• キーとなる情報を異なる位置に配置した場合、モデルのパフォーマンス（回帰の傾き）はどうなるか。
• キーメッセージを場所ごとにグループ分けし、グループによってどのように行動が異なるかを確認する。

研究結果

類似度のスコアと精度は、テキストが長くなるにつれて低下する。

実験結果は明らかで、テキストの文脈が長ければ長いほど、モデルの性能は低下する。平均類似度スコアは128語の0.37から8K語の0.10まで下がり、この下がり方は直線ではなく、128語から1K語の間で特に速い。

正規化のパフォーマンスとコンテキストの長さ

また、次のこともわかった。重要情報の記述を反転させても（反転させても）、モデルがそれを見つけることにはほとんど影響しない。 実は、由規はゼンパー・オペラハウスの近くに住んでいる」（デフォルトの発言）であろうと、「ゼンパー・オペラハウスは由規が住んでいる場所のすぐ隣にある」（倒置の発言）であろうと、モデルがそれを見つける確率はほとんど同じである：

2つの口座（デフォルト順位と逆順位）でのモデルパフォーマンスの比較

しかしだ。キーとなる情報がどのような内容であるかは、モデル発見の難易度に影響を与える。 場所やランドマークに関する情報であれば、モデルを見つけるのは簡単だが、食事や健康状態に関する情報であれば、モデルを見つけるのは難しく、文章が長くなればなるほど難易度は上がる：

異なる種類の情報（グルーピング）を見つける難易度（正規化されたパフォーマンス）とテキストの長さとの関係

モデルが本当に推測よりも優れているかどうかを確認するために、モデルの結果を「ランダムな推測」と比較した。ランダムな推測」とは、設問と同じ長さのテキストであるが、重要な情報を含まないものである。その結果文脈が長ければ長いほど、モデルの結果は盲目的な推測に近くなり、その後に無駄なテキストを選んでもほとんど変わらない。

モデルの性能とランダム確率（確率0.5）の比較

また、キーとなる情報の内容タイプによってデータをグループ分けし、モデルのパフォーマンスを調べた。結果は同様で、あるタイプの情報（例えば食事制限）では、テキストがそれほど長くなくても、モデルは推測よりもあまり優れていなかった。他のタイプの情報（例えば場所やランドマーク）では、テキストがどんなに長くても、モデルは良いパフォーマンスを示した：

さまざまなタイプの情報グループについて、モデルが答えを見つける確率と、無作為に推測する確率の比較

キーとなる情報の記述を逆にしても、モデルがキーとなる情報を見つける確率には基本的に影響はない。下の図は、モデルがキー情報を正しく含むテキストを見つける確率が、ランダムに推測する確率よりもはるかに高いことを示している。キー情報の2つの文（デフォルトと反転）を別々に見てみよう：

デフォルトの順番と逆の順番では、モデルが答えを見つける可能性はランダムな推測よりもどれくらい高いか？

図からわかるように、モデル性能の傾向はどちらの記述でも似ている。したがって、この2つのケースを後で区別することはしない。

このモデルでも有用な情報と無用な情報を区別することができるだろうか？

最も重要な発見のひとつは、ベクトルモデルが異なる長さのテキストに含まれる有用な情報と無用な情報を区別する能力についてでした。私たちは「分離分析」を行い、正解を見つけるモデルの能力が、128から1000語要素の間で特に急速に低下することを発見した。それ以降も低下するが、その速度は遅い。

セパレーションとコンテクストの長さの関係

短い文章（128語）では、このモデルは有用な情報と無用な情報を明確に区別する。平均分離度は0.1、AUCは0.81（つまり、100回中81回、答えを含むパッセージが1位になった）。

しかし、テキストが長くなると、モデルの性能は劇的に低下する。下る1000語では、分離は0.04（60%低下）、AUCは0.66に低下し、モデルがもはや識別できないことを示している。8000語になると、分離はほぼゼロ（0.001）になり、AUCは0.5近く（ランダム推測に匹敵する）、モデルはもはや類似性スコアに基づいて有用な情報を区別できないことを意味する。

テキストの長さが長くなるにつれて、有用な情報を識別するモデルの能力が低下する割合は顕著である。生の類似度スコアは128から8000語まで約75%低下したが、分離指標はほぼ99%低下し、効果量はさらに98.6%低下した！ベクトルモデルが長文を扱うのが難しいのは、類似度スコアの低下だけでなく、有用な情報と無用な情報を区別する能力が著しく低下することにある。

重要な情報の所在は、それを見つける難易度にどのように影響するのか？

一般的に、重要な情報は本文の上部に配置するのが最も見つけやすい。しかし、真ん中に置くと見つけにくくなるかというと、必ずしもそうではない：

異なる長さのテキストにおいて、重要な情報を異なる位置に配置することが、その情報の発見に与える影響

実験結果からも、重要な情報は冒頭に配置するのが最も見つけやすいことが確認された。さらに、テキストが短い場合は、末尾に近い方が見つけやすい。しかし、テキストの長さに関係なく、真ん中に配置された場合は見つけにくい：

重要な情報をさまざまな場所に配置することで、見つかる確率を比較する。

クエリ拡張機能は役に立つのか？

先日、「クエリ拡張」についてのブログを投稿しました。これは検索でよく使われる手法で、簡単に言うと、質問をするときに関連する単語を追加して検索結果をより正確にするということです。

LLMベースのクエリ拡張：より多くの情報、より正確な検索

ベクトルモデルの登場以来、検索の方法は大きく変わった。語彙の追加に大きく依存する「クエリ拡張」のような方法は、AIの時代にも有用なのだろうか？私たちはそう考えている。

そのブログでは、ラージ・モデル（LLM）を使って拡張単語を生成し、その単語をクエリ・ベクトルに追加したところ、検索結果が格段に良くなったことを発見した。では、「干し草の山から針を見つける」ような長いテキスト検索タスクに役立つかどうかを見てみたい。例えば

哪个角色去过德累斯顿？

これを大きなモデル（ジェミニ2.0）で拡大し、関連する単語を100個追加すると、おそらく次のようになるだろう：

哪个角色去过德累斯顿？ 角色：虚构角色 文学角色 主角 反派 人物 角色 身份 剧中人物

德累斯顿：德国德累斯顿；二战德累斯顿轰炸 历史小说 库尔特·冯内古特 《五号屠宰场》 萨克森州城市 易北河 文化地标

去过：访问过 去过 曾到过 出现于 出现于 特征为 设定在 发生于 地点 背景

クエリ拡張機能はどのくらい役に立つのか？

それぞれ100語、150語、250語を追加した3セットの拡張クエリを生成する実験を行った（追加方法の詳細はこちらの記事を参照）。その後、前回の実験をさらに3回行い、毎回異なる拡張クエリのセットを作成しました。

その結果、どんなに単語を増やしても、テキストが長くなると、クエリ拡張を使用しない場合とほぼ同じように、モデルの性能が股を抜くことが判明した：

様々なクエリ拡張シナリオにおけるモデルの総合性能

拡張機能がない場合の問題に比べれば、単語が追加されるケースはすべて、昔と同じ話だ：テキストが長ければ長いほど、パフォーマンスは落ちる。 さらに、この減少にはまだばらつきがあり、128ワードから1Kワードの間で最も減少している：

様々なクエリ展開シナリオにおいて、モデルが正しい答えを見つける確率。

しかし比較比率」指標を詳しく見てみると、クエリの拡張はまだ有用であることがわかる：これによって、モデルは重要な情報を含むテキストを見つけやすくなる。 クエリ拡張を行わない場合、このモデルは8K字句の要素長をランダムに推測した場合と同程度のパフォーマンスを示す。

クエリ展開の結果はどのように解釈すればよいですか？

これらの結果は、NoLiMaの論文やクエリ拡張に関する我々の過去の知見と一致している。このように解釈できる：

1. 適度に言葉を加えるのが最も効果的つまり、クエリを拡張する際には、単語を追加する程度があり、あまり多くの単語を追加すると、シグナルの代わりに意味的なノイズがもたらされ、モデルの判断を妨げることになります。250単語を追加する場合、質問との関連性が弱い単語が追加される可能性が高く、これらの単語は長いテキストでは役に立たない。
2. 長文は依然として中心的課題クエリを拡張しても、文脈が長くなるとモデルの性能は著しく低下する。現在のアテンション・ベースのモデル・アーキテクチャは、長いテキストを扱う際に根本的なボトルネックを抱えている。
3. 問い合わせのアウトリーチにはまだ価値がある長文という難題を完全に克服することはできませんでしたが、比較比率の指標は常に0.5を超えており、クエリ展開が依然として有効であることを示唆しています。8,000語の長文であっても、クエリ展開問題はランダムな推測よりも正しい答えを見つける可能性が高い。このことは、クエリ拡張がベクトルモデルの長文処理能力を向上させる潜在的な方向性であり、さらに探求する価値があることを示唆している。

ベクトルモデルにおけるリテラルマッチングの影響？

以前の実験では、ベクトルモデルが長文において「ワンホップ推論」を行う能力を測定するために、質問とキー情報の間の文字通りの繰り返しを意図的に避けた。その結果、クエリを拡張しても、長文中の関連情報を見つけるモデルの能力は低下することがわかった。この現象は興味深い。本来であれば、ベクトルモデルは、追加的な助けを借りることなく、この種の推論を自力で行うことができるはずである。ドレスデン」を「ゼンパー・オペラ・ハウス」に置き換えただけなのだから。

では、セマンティック・マッチングにおいてリテラル・マッチングはどの程度重要なのだろうか？それともテキストの長さの方がより大きな影響を与えるのだろうか？それを調べるために、例えばキーメッセージと質問の間に文字通りの繰り返しがあるように実験を再設計した：

• 質問：「ドレスデンに行ったことがある人物は？
• キーメッセージ（デフォルト）：「実は、ユキはドレスデンに住んでいるんだ。
• キーメッセージ（倒置法）："ドレスデンはユキが住んでいるところ"

以前のように「ゼンパー歌劇場はドレスデンにあるから、近所に住んでいる人はドレスデンに行ったことがある」と読者に推論させるのではなく、ここでは「ユキはドレスデンに住んでいる」という情報を直接与えていることに注意されたい。

22グループの質問とキーメッセージをすべてこのようなわかりやすい形に変更し、同じベクトルモデルを使用した。 jina-embeddings-v3 もう一度実験を行い、テキストの長さや重要な情報の位置を変えてみた。

正規化のパフォーマンスとコンテキストの長さ

モデルのパフォーマンス対ランダムな推測（0.5）

各拠点での比率比較

結果は予想外だった。問題と答えに同じ単語があったとしても、正解とランダムな推測を区別するモデルの能力は、文章が長くなるにつれて急激に低下するのだ。もちろん、同じ単語がまったくない場合よりは、まだ若干ましである。

これは最終的に、コンテキストの長さとその中のキー情報の位置が、キー情報の具体的な表現（意味表現）よりも、「干し草の山の中の針」タスクにおけるベクトルモデルの性能に大きな影響を与えることを示している。

評決を下す

全体として、ベクトルモデルを使った実験の結論は、NoLiMAの大規模言語モデルを使った実験と一致しています。テキストが長ければ長いほど、モデルが正しい答えを見つけるのは難しくなります。私たちの実験はまた、質問と答えのキーワードが全く同じであっても、モデルが常に正しいものを見つけるとは限らないことを示しています。

我々の実験結果は、LLMに関するNoLiMAの論文の結果と非常に一致している：ベクトルモデルにとって、文脈の長さは検索性能の重要な要素である。文章が長ければ長いほど、モデルが正しい答えを見つけるのは難しくなります。問題文と解答のキーワードが全く同じであっても、モデルが常に正しいものを見つけられるとは限りません。

1. 長さが長くなるにつれて性能は急激に低下するjina-embeddings-v3は短いテキスト（128語）では良好な性能を示すが、長いテキストでは急激に性能が低下する。正規化された類似度スコアは128語の0.37から8K語の0.10まで低下し、さらに重要なことに、モデルの関連情報と非関連情報を区別する能力（これを「分離」と呼ぶ）はほとんど完全に消失する。
2. "シングルジャンプ推理 "は難しい。短い文章であっても、質問と答えの間に直接文字が重ならない場合、モデルの性能は著しく低下します。このことは、ベクトルモデルが「ワンホップ推論」（例えば、「ゼンパー・オペラハウスの隣に住んでいる」から「ドレスデンに行ったことがある」と推論する）を苦手としていることを示唆している。
3. クエリエクステンションは役に立つが、それがすべてではないクエリ拡張は、特に長いテキストに対して検索性能をある程度向上させることができ、ランダムな推測を上回る性能を発揮する。しかし、長いテキストがもたらす問題を完全に解決できるわけではない。さらに、単語の追加には注意が必要で、無関係な単語はかえって意味ノイズをもたらし、性能を低下させる。
4. 文字通りのマッチングが鍵ではない質問と答えに同じキーワードがあっても、文章が長ければ、モデルは答えを見つけることができません。このことは、答えの言い回しや文章の長さよりも、文章中の答えの位置の方が、モデルが答えを見つけられるかどうかに大きく影響していることを示しています。

全体として、我々の調査によると jina-embeddings-v3 このようなベクトルモデルは、短いテキストを扱うのには適しているが、意味論のより深い理解を必要とする長いテキストを扱うことはまだできない。このことは、長文検索のためのより効果的なテクニックを探求し続ける動機付けとなり、将来的には jina-embeddings-v4 そこには突破口がある。