新聞
模型
API
keyboard_arrow_down
讀取器
讀取URL或搜索為大模型提供更好的依據。
向量模型
世界一流的多模態多語言向量模型。
重排器
世界一流的重排器,最大限度地提高搜索相關性。
MCP terminal命令行articlellms.txtsmart_toy代理人data_object模式menu_book文檔



登錄
login
針與草堆的構建
評估指標
研究發現
查詢擴展對結果有什麼影響?
診斷:詞彙匹配在 Embeddings 中扮演什麼角色?
結論
技術博客
三月 07, 2025

長文本嵌入模型在超過 4K Token 後就會失去效用

我們對嵌入模型在新的「大海撈針」任務上進行研究,發現在超過 4K token 後,它們的表現就像在擲骰子一樣——即使是精確的詞彙匹配或查詢擴展,它們也無法在長上下文中分辨出有效信號和噪音。
Saahil Ognawala
Alex C-G
Saahil Ognawala, Alex C-G • 14 分鐘的讀取量

在 2025 年 2 月,一組 AI 研究人員發布了 NoLiMA 論文,該論文介紹了一個新的基準測試,用於評估大型語言模型處理長文本上下文的能力。

NoLiMa: Long-Context Evaluation Beyond Literal Matching
Recent large language models (LLMs) support long contexts ranging from 128K to 1M tokens. A popular method for evaluating these capabilities is the needle-in-a-haystack (NIAH) test, which involves retrieving a "needle" (relevant information) from a "haystack" (long irrelevant context). Extensions of this approach include increasing distractors, fact chaining, and in-context reasoning. However, in these benchmarks, models can exploit existing literal matches between the needle and haystack to simplify the task. To address this, we introduce NoLiMa, a benchmark extending NIAH with a carefully designed needle set, where questions and needles have minimal lexical overlap, requiring models to infer latent associations to locate the needle within the haystack. We evaluate 12 popular LLMs that claim to support contexts of at least 128K tokens. While they perform well in short contexts (<1K), performance degrades significantly as context length increases. At 32K, for instance, 10 models drop below 50% of their strong short-length baselines. Even GPT-4o, one of the top-performing exceptions, experiences a reduction from an almost-perfect baseline of 99.3% to 69.7%. Our analysis suggests these declines stem from the increased difficulty the attention mechanism faces in longer contexts when literal matches are absent, making it harder to retrieve relevant information.
arXiv.orgAli Modarressi

這篇論文對傳統的大海撈針(Needle-in-a-Haystack,NIAH)基準測試進行了重大改變,移除了問題與隱藏在干擾文本中的關鍵資訊(針)之間的字面匹配。

例如,在傳統的 NIAH 中,如果問題是「John 什麼時候去巴黎?」,關鍵資訊可能直接包含「John 在 2019 年訪問巴黎。」而在 NOLIMA 中,問題可能是「哪個角色去過法國?」,而關鍵資訊則包含「實際上,Yuki 住在森帕歌劇院旁邊」——這需要模型知道森帕歌劇院在德國德勒斯登,而不是法國。

這突顯了當前 LLM 的一個關鍵限制:它們高度依賴表面層次的模式匹配,且其進行深層關聯推理的能力會隨著上下文長度的增加而迅速退化。

基於這些見解,我們打算研究是否在嵌入模型中也會出現類似的性能模式,特別關注 jina-embeddings-v3。由於 RAG 系統的效能高度依賴於檢索模型的品質,我們希望通過針對兩個核心問題的對照實驗來擴展 NoLiMA 的研究:

  • 當被迫進行超越字面關鍵字匹配的語義推理時,嵌入模型如何在不同上下文長度下處理大海撈針式的檢索?
  • 是否可以通過使用語義相近內容進行策略性的查詢擴充來減少這種性能差距?

在 LLM 中觀察到的鮮明對比——在字面匹配時表現強勁但在語義變化時較為脆弱——暗示基於嵌入的檢索系統在超越表面術語匹配時可能面臨類似的挑戰,這可能揭示了當前語義搜索技術的根本限制。

tag針與草堆的構建

tag針的構建

傳統的大海撈針測試使用的針反映了被搜尋問題的用詞。例如:

  • 問題:「哪個角色去過德勒斯登?」
  • 針:「Yuki 住在德勒斯登。」

但像 NoLiMA 一樣,我們想要測試語義理解而不是僅僅進行關鍵字匹配,所以我們創建了單步變體(使用特意不在文件中出現的詞)並採用兩種不同的詞序:

  • 問題:「哪個角色去過德勒斯登?」
  • 針(預設):「實際上,Yuki 住在森帕歌劇院旁邊。」
  • 針(倒裝):「森帕歌劇院就在 Yuki 居住的地方旁邊。」
💡
森帕歌劇院位於德勒斯登,為這個單步針提供了上下文。

遵循論文的方法,我們在幾個類別中生成這些針-問題組(包含一個問題、一個單步針和一個倒裝單步針),如以下例子:

類別 問題 原始針(僅供參考) 單步針 倒裝單步針
飲食限制 哪個角色不能吃魚類餐點? Alice 不能吃魚類餐點。 然後,Alice 提到她當了多年的純素者。 當純素者對 Alice 來說已經很多年了。
醫療狀況 哪個角色不能喝牛奶? Bob 不能喝牛奶。 Bob 解釋他是乳糖不耐症。 乳糖不耐症每天都影響著 Bob。
語言能力 哪個角色會說法語? Charlie 會說法語。 事實上,Charlie 在索邦大學讀書。 在索邦大學,Charlie 完成了他的學位。
職業背景 哪個角色是音樂家? Diane 是位音樂家。 2013 年,Diane 在雪梨歌劇院指揮。 雪梨歌劇院的演出是由 Diane 指揮的。
💡
上述名字僅供參考。在實際的針中,這些名字是從一個文化多樣性的名單中隨機選取的。

請注意,原始針(字面關鍵字匹配)僅供參考,並不用於我們的實驗中。

tag草堆的構建

我們從十本公共領域的書籍開始,每本至少包含 50,000 個 token,將其中的短段落(少於 250 個 token)隨機連接成不同長度的草堆,分別是 128、256、512、1024、2048、4096 和 8192 個 token。然後我們在每個草堆中嵌入一個針:

圖 1:從書籍的短段落和每個草堆中的單一針構建草堆。

舉個具體例子,我們將針「實際上,Yuki 住在森帕歌劇院旁邊」放在一個 128 token 的草堆中的第 50 個位置:

圖 2:大海撈針示例。

使用 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 傾向於低估兩個文本之間的相似度。

對於每個針(包括所有預設和倒裝的),我們為每個上下文長度生成了十個草堆,在每個草堆的不同位置嵌入一個針。對於給定的針和上下文長度,草堆會看起來像這樣:

圖 3:針被規律地放置在十個草堆中。

作為對照組,我們還為每個測試條件生成了一個不含針的草堆。總共有 3,234 個草堆。我們使用 jina-embeddings-v3(使用預設的文本匹配 LoRA)對每個草堆進行編碼,然後對每個草堆進行截斷(如果總 token 超過 8,192,即jina-embeddings-v3)然後將其對應的問題進行編碼。

tag評估指標

我們的評估框架使用多個指標來評估不同上下文長度的嵌入模型性能:

tag主要指標

標準化相似度分數
核心指標是標準化相似度分數,它同時考慮問題與整個上下文(問題-乾草堆相似度)之間的語義相似度,以及問題與其對應的預設針頭(問題-針頭相似度)之間的基準相似度。這種標準化確保模型的性能是相對於有意義的參考點而不是僅僅基於絕對相似度分數來評估。標準化過程包括計算問題與其對應針頭之間的直接餘弦相似度分數(我們的基準線),並用問題-乾草堆相似度除以這個基準分數:

標準化相似度=cos⁡(q,h)cos⁡(q,n)\text{標準化相似度} = \frac{\cos{(q,h)}}{\cos{(q,n)}}標準化相似度=cos(q,n)cos(q,h)​

與隨機機率的比較比率
對於任何嵌入模型,不同查詢-文檔對之間的餘弦相似度分數只有在查詢保持相同時才能直接比較。因此,除了使用標準化相似度分數外,我們還測量問題與整個乾草堆的相似度高於與不含針頭的相同長度隨機段落的頻率。

tag次要指標

分離分析
這個指標評估模型區分相關和不相關內容的能力。它包括代表正例(包含答案的段落)和負例(不包含答案的段落)之間差異的平均分離度,以及基於 ROC(受試者工作特徵)曲線下面積來測量區分能力的AUC(曲線下面積)分數。

位置效應
我們通過位置與相似度分數之間的相關係數、顯示跨位置性能變化的迴歸斜率,以及位置分組性能分析來分析針頭放置如何影響性能。

tag研究發現

tag相似度分數和準確性的退化

我們的結果清楚地表明,隨著上下文長度增加,性能會退化,平均相似度分數從 128 tokens 時的 0.37 降至 8K tokens 時的 0.10,呈現非線性趨勢,在 128 至 1K tokens 之間出現急劇下降。

圖 4:標準化性能與上下文長度的關係。

在下圖中,我們展示了顛倒針頭對標準化相似度分數的影響很小。預設針頭(例如「Actually, Yuki lives near the Semper Opera House」)和顛倒針頭(例如「The Semper Opera House is next to where Yuki lives」)都顯示出幾乎相同的性能:

圖 5:預設順序與顛倒順序的性能比較。

數據集中不同的語義連接顯示出不同的性能,其中位置-地標對維持最強的結果,而飲食和醫療狀況連接則退化得更快:

圖 6:標準化群組性能與上下文長度的關係。

將結果與隨機機率比較支持了我們的發現,顯示乾草堆越大,結果越接近隨機性,即對於給定的問題,我們選中沒有針頭(正確答案)的隨機段落的可能性與選中乾草堆的可能性幾乎相同:

圖 7:模型性能與隨機機率(0.5)的比較。

同樣,我們看到不同語義連接的性能各異,有些(如飲食限制)即使在相對較短的上下文中也遠低於隨機機率,而其他(如位置和地標)則無論上下文長度如何都表現得更好:

圖 8:群組性能與隨機機率的比較。

顛倒針頭對性能影響很小。在下圖中,我們顯示了相較於隨機機率更傾向於選擇正確乾草堆的比率,按放置的針頭是否以預設順序或顛倒順序包含答案進行分類:

圖 9:預設順序與顛倒順序 - 性能與隨機機率的比較。

由於我們可以看到預設順序和顛倒順序針頭的結果都遵循相同的趨勢,我們不會繼續對這個標準進行分析。

tag我們能區分正面和負面結果嗎?

我們最重要的發現之一來自分析嵌入模型在不同上下文長度下區分相關和不相關內容的能力。這個「分離分析」顯示,檢索的準確性在上下文長度 128 到 1000 tokens 之間快速下降,然後繼續下降,但速度較慢:

圖 10:分離分析與上下文長度的關係。

對於短上下文(128 tokens),模型顯示出強大的分離能力,平均差異為 0.1,並具有明顯的區分能力,達到 0.81 的 AUC(意味著 81% 的時間,模型將相關段落排在不相關段落之前)。這表明在較短的上下文中,模型能可靠地區分包含答案的段落和不包含答案的段落。

然而,隨著文本長度增加,這種表現迅速惡化。在 1,000 個 tokens 時,分離度下降了 60% 至 0.040,而 AUC 降至 0.66,顯示出明顯的性能下降。在 8,000 個 tokens 時,分離度極低(0.001),幾乎呈現隨機判別的狀態,AUC 僅為 0.50。這種模式揭示了一個關鍵洞見:即使模型能夠在較長文本中計算出合理的相似度分數,它們也幾乎無法利用這些分數來區分相關和不相關的資訊。在 8,000 個 tokens 時,模型區分相關內容的能力基本上等同於隨機猜測。

隨著文本長度增加,效能下降的速度令人震驚。從 128 到 8,000 個 tokens,原始相似度分數下降約 75%,但分離度指標在同一範圍內下降了近 99%。更令人擔憂的是,效果量顯示出更陡峭的下降,降幅達 98.6%。這表明 embedding 模型在處理長文本時的困境不僅僅是相似度分數降低的問題—它們識別相關資訊的基本能力的退化程度比先前理解的要嚴重得多。

tag目標內容的位置如何影響核心指標?

雖然當目標內容位於文本開頭時,核心性能指標通常最佳,但效能退化並不總是與目標內容在文本中間的位置有關:

圖 11:不同文本長度下相對位置的效能表現。

我們還發現,當目標內容位於文本開頭時,效能最佳,在短文本中,當目標內容位於文本末尾時會出現小幅提升。然而,在所有文本長度中,當目標內容位於中間位置時,效能都會下降:

圖 12:按位置的比較比率。

tag查詢擴展對結果有什麼影響?

我們最近發布了一篇關於查詢擴展的部落格文章,這是一種在搜尋系統中通過增加相關詞彙來提升搜尋效能的技術。

Query Expansion with LLMs: Searching Better by Saying More
Search has changed a lot since embedding models were introduced. Is there still a role for lexical techniques like query expansion in AI? We think so.
Jina AIMichael Günther, Scott Martens

在文章中,我們使用 LLM 生成擴展詞彙,然後將其添加到查詢 embeddings 中以提高檢索效能。結果顯示了顯著的改進。現在,我們想要檢驗這種技術如何(或是否)能改善大海撈針式搜尋的結果。例如,給定一個查詢:

Which character has been to Dresden?

我們使用 LLM(Gemini 2.0)進行擴展,並添加 100 個額外的詞彙,如下所示:

Which character has been to Dresden? Character: fictional character literary character protagonist antagonist figure persona role dramatis personae\\n\\nDresden: Dresden Germany; bombing of Dresden World War II historical fiction Kurt Vonnegut Slaughterhouse-Five city in Saxony Elbe River cultural landmark\\n\\nHas been to: visited traveled to journeyed to presence in appears in features in set in takes place in location setting

tag查詢擴展對於匹配目標內容的幫助有多大?

在我們的實驗中,我們生成了三組擴展查詢詞彙(如原文所述)- 100、150 和 250 個詞彙。然後我們使用每組擴展詞彙分別運行三次相同的實驗。

所有擴展組的結果都顯示,隨著文本長度增加,效能明顯下降,這與不使用查詢擴展時的效果類似(圖 4 和圖 7):

圖 13:所有擴展規模的綜合標準化效能。

與未擴展的查詢相比,所有查詢擴展條件都顯示出相同的效能退化模式。這種退化趨勢仍然呈非線性,在 128 和 1K tokens 之間出現急劇下降:

圖 14:所有擴展規模的綜合比較比率。

然而,觀察比較比率顯示查詢擴展確實帶來明顯的好處:模型更有可能選擇包含目標內容的文本而不是不包含的文本。相比之下,在不使用查詢擴展的情況下,選擇正確段落的機率下降得如此之多,以至於在 8K tokens 的文本大小時,幾乎與隨機選擇的機率相同。

tag如何解釋使用查詢擴展的目標匹配結果?

這些結果與 NoLiMa 論文和查詢擴展研究的發現一致,可以從以下幾個方面解釋:

  1. 質量與數量的權衡:100 個詞彙擴展相比 150 和 250 個詞彙表現更好,這表明存在一個最佳點,超過這個點後,額外的詞彙帶來的雜訊會多於有效信號。250 個詞彙的擴展可能引入了與原始查詢語義關係較弱的詞彙,在較長文本中反而會產生反效果。
  2. 文本長度仍是主要挑戰:儘管查詢擴展帶來了好處,但隨著文本長度增加,效能仍然顯著下降。這表明即使有擴展,基於注意力的模型在處理長文本時的基本架構限制仍然存在。
  3. 實用閾值識別:比較比率保持在 0.5 以上表明,即使在 8K tokens 時,擴展仍能維持高於隨機猜測的效能,這為擴展 embedding 模型的有效文本視窗提供了一種實用方法。與隨機猜測的比較顯示,即使在面對長文本時,擴展查詢使找到正確答案(即目標內容)的可能性高於找到錯誤答案。這比未擴展查詢要好,因為在未擴展查詢中,隨著文本長度增加,找到正確答案的機會接近隨機。

tag診斷:詞彙匹配在 Embeddings 中扮演什麼角色?

在上述實驗中,我們通過排除所有字面匹配的可能性,測量了 embedding 模型在長文本中進行語義"單跳"推理的效果。我們發現,即使使用查詢擴展,embedding 模型找到相關段落的能力也會隨著文本長度增加而退化。這種效果很顯著,這一發現值得注意,因為我們通常會期望 embedding 模型能夠在不需要額外幫助的情況下進行相關推理。當將字面匹配替換為單跳變體時(例如"Dresden"→"Semper Opera House"),我們只是用另一個相近的概念替換一個概念。

現在,讓我們直接面對這個問題:字面匹配在語義匹配中真的扮演著足夠重要的角色嗎,還是文本長度的影響會壓倒它?為了回答這個問題,我們重新進行了測試,使用包含字面匹配的目標內容,例如:

  • 問題:"Which character has been to Dresden?"
  • 目標內容(預設):"Actually, Yuki lives in Dresden."
  • 目標內容(倒裝):"Dresden is where Yuki lives."

請注意,這些答案不是通過推理得出塞姆珀歌劇院在德勒斯登,因此住在附近的角色應該是去過德勒斯登的人這樣的單一推論,而是直接指出住在德勒斯登的角色名字。

在用這種方式重新構造了所有 22 個問題-答案對後,我們使用相同的 embedding 模型 jina-embeddings-v3,重新進行了包含所有上下文長度和答案位置的實驗。

圖 15:正規化效能與上下文長度的關係。
圖 16:模型效能與隨機機率(0.5)的比較。
圖 17:位置相對比率

結果令人震驚。即使在上下文中有字面匹配,隨著上下文長度的增加,模型區分正確答案和隨機答案的能力也會迅速下降,儘管相比完全沒有字面匹配的情況仍保持著輕微優勢。

這最終證明,embedding 模型在大海撈針中找到答案的能力,更多地受到海(上下文大小)的影響,而不是針(答案的語義表述)的影響。

tag結論

我們對 embedding 模型的研究發現與 NoLiMA 關於 LLM 的論文結果一致:上下文大小對正確匹配和檢索有決定性影響。我們證明即使存在完全相同的逐字匹配,這一點也成立。

問題不在於 embedding 進行語義匹配的能力。像 jina-embeddings-v3 這樣的 embedding 模型在處理短上下文時表現相當好,但隨著上下文長度增加,其效果會下降。查詢擴展可以在某種程度上減輕這種影響,但檢索質量仍然會隨著更長的上下文而降低。此外,查詢擴展也帶來了其他問題,因為識別能改善檢索而不增加語義噪音的擴展詞至關重要。我們正在研究並尋找直接解決大海撈針檢索問題的方法,以改進未來 jina-embeddings-v4 的性能。

類別:
技術博客
rss_feed

更多新聞
三月 11, 2026 • 7 分鐘的讀取量
從多模態大模型引導音訊向量模型
Han Xiao
Abstract illustration of a sound wave or heartbeat, formed by blue, orange, and gray dots on a white background.
三月 06, 2026 • 6 分鐘的讀取量
從原始數值辨識向量模型
Han Xiao
Fingerprint illustration made from numbers, showcasing digital and high-tech design on a light background.
九月 09, 2025 • 11 分鐘的讀取量
Llama.cpp 與 GGUF 中的多模態向量模型
Andrei Ungureanu
Alex C-G
Cartoon llama in the center of a white background, emitting laser-like beams from its eyes. The illustration creates a playfu
辦公室
location_on
加利福尼亞州桑尼維爾
710 Lakeway Dr, Ste 200, 桑尼維爾, 加州 94085, 美國
location_on
德國柏林
Prinzessinnenstraße 19-20,10969 柏林,德國
搜索底座
讀取器
向量模型
重排器
獲取 Jina API 密鑰
速率限制
API 狀態
公司
關於我們
聯繫銷售
新聞
實習生項目
下載 Jina 標誌
open_in_new
下載 Elastic 徽標
open_in_new
條款
安全
條款及條件
隱私
管理 Cookie
email
Elastic Jina AI © 2020-2026.