长文本嵌入模型在 4K Token 之外就失效了

2025 年 2 月，一个 AI 研究团队发布了 NoLiMA 论文，该论文提出了一个新的基准来评估大语言模型处理长上下文的能力。

NoLiMa: Long-Context Evaluation Beyond Literal Matching

最近的大语言模型（LLMs）支持从 128K 到 1M token 的长上下文。评估这些能力的一种流行方法是大海捞针（NIAH）测试，它涉及从"干草堆"（长的无关上下文）中检索"针"（相关信息）。这种方法的扩展包括增加干扰项、事实链接和上下文推理。然而，在这些基准测试中，模型可以利用针和干草堆之间已有的字面匹配来简化任务。为了解决这个问题，我们引入了 NoLiMa，这是一个扩展 NIAH 的基准测试，具有精心设计的针集，其中问题和针之间具有最小的词汇重叠，要求模型推断潜在关联以在干草堆中定位针。我们评估了 12 个声称支持至少 128K token 上下文的流行 LLM。虽然它们在短上下文（<1K）中表现良好，但随着上下文长度增加，性能显著下降。例如在 32K 时，10 个模型降至其强劲短长度基线的 50% 以下。即使是表现最好的 GPT-4o，也从几乎完美的 99.3% 基线降至 69.7%。我们的分析表明，这些下降源于在缺乏字面匹配的情况下，注意力机制在更长上下文中面临的增加难度，使得检索相关信息变得更加困难。

arXiv.orgAli Modarressi

该论文通过移除问题和隐藏在干草堆（无关文本）中的针（相关信息）之间的字面匹配，对传统的大海捞针（NIAH）基准做出了重大改变。

这突显了当前 LLM 的一个关键限制：它们严重依赖表面层面的模式匹配，而且随着上下文长度的增加，它们进行深层关联推理的能力会迅速下降。

基于这些见解，我们旨在研究类似的性能模式是否也出现在嵌入模型中，特别关注 jina-embeddings-v3。由于 RAG 系统的效果严重依赖于检索模型的质量，我们试图通过针对两个核心问题的受控实验来扩展 NoLiMA 的研究：

• 当嵌入模型被迫超越字面关键词匹配进行语义跳跃时，它们如何在不同上下文长度中处理大海捞针检索？
• 通过语义相似内容的策略性查询增强能否缓解这种性能差距？

在 LLM 中观察到的鲜明对比—在词汇匹配方面表现强劲但在语义变化方面易受影响—表明基于嵌入的检索系统在超越表面术语匹配时可能面临类似的挑战，这可能揭示当前语义搜索技术的基本局限性。

tag针和干草堆的构建

tag针的构建

传统的大海捞针测试使用的针反映了被搜索问题的措辞。例如：

• 问题："哪个角色去过德累斯顿？"
• 针："Yuki 住在德累斯顿。"

但像 NoLiMA 一样，我们想要测试语义理解而不是仅仅是关键词匹配，所以我们创建了一跳变体（使用文档中特别没有的词）并采用两种不同的词序：

• 问题："哪个角色去过德累斯顿？"
• 针（默认）："事实上，Yuki 住在森帕歌剧院旁边。"
• 针（倒装）："森帕歌剧院就在 Yuki 住的地方旁边。"

按照论文的方法，我们在几个类别中生成这些针-问题组（包含一个问题、一个一跳针和一个倒装一跳针），如下例所示：

tag干草堆的构建

我们从十本公共领域的书籍开始，每本至少包含 50,000 个 token，将它们的短片段（不超过 250 个 token）随机连接成不同长度的干草堆，分别是 128、256、512、1024、2048、4096 和 8192 个 token。然后我们在每个干草堆中嵌入一个针：

举个具体的例子，我们将针"事实上，Yuki 住在森帕歌剧院旁边"放在一个 128 token 的干草堆的第 50 个位置：

使用 jina-embeddings-v3 嵌入文本，针文本和干草堆文本之间的相似度分数为：

Question-Haystack similarity = 0.2391
Copy

然后，我们通过将这个数字除以问题和默认针之间的相似度分数（无干草堆创建，仅直接比较）来进行归一化：

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

这种归一化是必要的，因为不是所有模型在两个文本之间产生相同的相似度分数，而且 jina-embeddings-v3 倾向于低估两个文本之间的相似度。

对于每个针（包括所有默认和倒装），我们为每个上下文长度生成了十个干草堆，在每个干草堆的不同位置嵌入一个针。对于给定的针和上下文长度，干草堆会如下所示：

作为对照，我们还为每个测试条件生成了一个不含针的干草堆。总共有 3,234 个干草堆。我们使用 jina-embeddings-v3（使用默认文本匹配 LoRA）对每个干草堆进行编码，然后对每个干草堆进行截断（如果总 token 超过了 8,192，这是

tag评估指标

我们的评估框架使用多个指标来评估嵌入模型在不同上下文长度下的性能：

tag主要指标

归一化相似度分数
核心指标是归一化相似度分数，它同时考虑了问题与整个上下文（问题-草堆相似度）之间的语义相似度，以及问题与其对应默认针（问题-针相似度）之间的基线相似度。这种归一化确保模型的性能是相对于有意义的参考点而不是单纯的绝对相似度分数来评估的。归一化过程包括计算问题与其对应针之间的直接余弦相似度分数（我们的基线），并用问题-草堆相似度除以这个基线分数：

$\text{归一化相似度} = \frac{\cos{(q,h)}}{\cos{(q,n)}}$

与随机概率的比较比率
对于任何嵌入模型，当查询保持不变时，不同查询-文档对之间的余弦相似度分数才能直接比较。因此，除了使用归一化相似度分数外，我们还测量问题与整个草堆的相似度超过与不含针的同长度随机片段相似度的频率。

tag次要指标

分离分析
该指标评估模型区分相关和不相关内容的能力。它包括平均分离度，代表正例（包含答案的段落）和负例（不包含答案的段落）之间的差异，以及AUC（曲线下面积）分数，基于 ROC（接收者操作特征）曲线下的面积来衡量区分能力。

位置效应
我们通过位置与相似度分数之间的相关系数、显示跨位置性能变化的回归斜率，以及位置分组性能分析来分析针的放置如何影响性能。

tag研究发现

tag相似度分数和正确性的退化

我们的结果清楚地表明，随着上下文长度增加，性能会降低，平均相似度分数从 128 个 token 时的 0.37 下降到 8K 个 token 时的 0.10，呈现非线性趋势，在 128 到 1K 个 token 之间出现急剧下降。

在下图中，我们展示了针的顺序反转对归一化相似度分数的影响很小。默认针（例如"Actually, Yuki lives near the Semper Opera House"）和反转针（例如"The Semper Opera House is next to where Yuki lives"）显示出几乎相同的性能：

数据集中的不同语义连接表现出不同的性能，其中位置-地标对维持最强的结果，而饮食和医疗条件连接的退化更快：

将结果与随机概率进行比较支持了我们的发现，表明草堆越大，结果越接近随机性，即对于给定的问题，选择不含针（正确答案）的随机段落的可能性与选择草堆的可能性几乎相同：

再次，我们看到基于不同语义连接的性能各不相同，有些（如饮食限制）即使在相对较短的上下文中也降到随机概率以下，而其他（如位置和地标）无论上下文长度如何都表现得更好：

反转针对性能的影响很小。在下图中，我们展示了偏好正确草堆而非随机选择的比较比率，按放置的针是默认顺序还是反转顺序包含答案进行分类：

由于我们可以看到默认顺序和反转顺序针的结果都遵循相同的趋势，我们不会继续针对这个标准进行分析。

tag我们能区分正面和负面结果吗？

我们最重要的发现之一来自分析嵌入模型在不同上下文长度下区分相关和不相关内容的能力。这种"分离分析"揭示检索的正确性在上下文长度 128 到 1000 个 token 之间迅速下降，然后继续下降，但速度较慢：

对于短上下文（128 个 token），模型显示出强分离性，平均差异为 0.1，并具有明显的区分能力，达到 0.81 的 AUC（意味着 81% 的时间，模型将相关段落排名高于不相关段落）。这表明在较短的上下文中，模型可以可靠地区分包含答案的段落和不包含答案的段落。

然而，随着上下文长度的增加，性能会迅速下降。在 1,000 个 token 时，分离度下降了 60% 至 0.040，AUC 降至 0.66，表明性能显著下降。在 8,000 个 token 时，分离度最小（0.001），判别能力接近随机，AUC 仅为 0.50。这种模式揭示了一个关键洞察：即使模型能够在较长的上下文中计算出合理的相似度分数，它们也几乎无法利用这些分数来区分相关和不相关的信息。在 8,000 个 token 时，模型区分相关内容的能力基本上等同于随机猜测。

随着上下文增长，这种性能下降的速度令人震惊。从 128 到 8,000 个 token，原始相似度分数下降了约 75%，但分离度指标在同一范围内下降了近 99%。更令人担忧的是，效应量显示出更陡峭的下降，降低了 98.6%。这表明嵌入模型在处理长上下文时的困难不仅仅是相似度分数降低的问题——它们识别相关信息的基本能力的崩溃程度远比之前理解的更为严重。

tag针对内容的位置如何影响核心指标？

虽然当针对内容位于文本开头时，核心性能指标通常最好，但性能下降并不总是与放置在上下文中间的位置相关：

我们还发现，当针对内容位于给定上下文的开头时，性能最好，在短上下文中，当针对内容位于末尾时，性能会有小幅提升。然而，在所有上下文中，当针对内容位于中间位置时，我们都看到性能下降：

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 生成扩展术语，然后将其添加到查询嵌入中以提高检索性能。结果显示出显著的改进。现在，我们想要研究这种技术如何（或是否）能改善针对性搜索的结果。例如，给定一个查询：

Which character has been to Dresden?
Copy

我们使用 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

Copy

tag查询扩展在多大程度上帮助匹配针对内容和文本堆栈？

在我们的实验中，我们生成了三组扩展查询术语（如原始文章中所述）——100、150 和 250 个术语。然后，我们运行了与之前相同的实验集，每组扩展查询术语重复三次。

所有扩展集的结果都显示，随着上下文长度增加，性能明显下降，与不使用查询扩展的效果类似（图 4 和图 7）：

与未扩展的查询相比，所有查询扩展条件都显示出随着上下文增长而性能下降的相同模式。这种下降趋势仍然是非线性的，在 128 和 1K tokens 之间有显著下降：

然而，检查比较比率显示查询扩展具有明显的好处：模型更有可能选择包含针对内容的文本堆栈而不是不包含的文本堆栈。相比之下，在没有查询扩展的情况下，选择正确段落的概率下降得如此之多，以至于在文本堆栈大小为 8K tokens 时，几乎与随机选择一个段落的概率相同。

tag如何解释使用查询扩展的针对内容匹配结果？

这些结果与 NoLiMa 论文和查询扩展研究的发现一致，可以解释如下：

1. 质量与数量的权衡：100 个术语扩展相比 150 和 250 个术语的更好性能表明，存在一个最佳点，在该点之后添加更多术语会带来更多噪声而不是信号。250 个术语的扩展可能引入了与原始查询语义关系较弱的术语，这在较长的上下文中变得适得其反。
2. 上下文长度仍然是主要挑战：尽管查询扩展带来了好处，但性能仍然随着上下文长度的增加而显著下降。这表明即使有扩展，基于注意力的模型在长上下文中的基本架构限制仍然存在。
3. 实用阈值识别：比较比率保持在 0.5 以上表明，即使在 8K tokens 时，扩展仍然保持着高于随机概率的性能，这为扩展嵌入模型的有效上下文窗口提供了一种实用方法。与随机概率的比较表明，即使在面对长上下文文档时，扩展查询也使找到正确答案（即针对内容）的可能性高于找到错误答案。这比未扩展查询有所改进，因为在未扩展查询中，随着上下文长度的增加，找到正确答案的概率接近随机。

tag诊断：词汇匹配在嵌入中扮演什么角色？

在上述实验中，我们通过排除所有字面匹配的可能性，测量了嵌入模型在长上下文段落中进行语义"单跳"推理的有效性。我们发现，即使使用查询扩展，嵌入模型找到相关段落的能力也会随着上下文长度的增加而下降。这种效果很显著，这一发现值得注意，因为我们通常期望嵌入模型能够在没有额外帮助的情况下进行相关推理。当用单跳变体替换字面匹配时（例如"Dresden"→"Semper Opera House"），我们只是用另一个相近的概念替换一个概念。

让我们现在直接面对这个问题：字面匹配在语义匹配中真的起到足够重要的作用吗，或者上下文长度的影响会压倒它？为了回答这个问题，我们重新进行了测试，使用包含字面匹配的针对内容，例如：

• 问题："Which character has been to Dresden?"
• 针对内容（默认）："Actually, Yuki lives in Dresden."
• 针对内容（倒置）："Dresden is where Yuki lives."

注意到，这些针对性内容不是通过单一推理步骤（推断森珀歌剧院在德累斯顿，因此住在其旁边的角色应该去过德累斯顿）来表达，而是直接说明住在德累斯顿的角色名字。

我们按照这种方式重新表述了所有 22 对问题-针对性内容，并使用相同的嵌入模型 jina-embeddings-v3 重新进行了所有上下文长度和针对性内容位置的实验。

结果令人震惊。即使在上下文中存在字面匹配，随着上下文长度的增加，模型区分正确答案和随机答案的能力也会迅速下降，尽管相比完全没有字面匹配时仍保持着轻微优势。

这最终证明了，嵌入模型在大海捞针式搜索中的能力，受到的影响更多来自于"海"的大小（以及"针"在其中的位置），而不是"针"的语义表述方式。

tag结论

我们对嵌入模型的研究发现与 NoLiMA 关于 LLM 的论文结论一致：上下文大小对正确匹配和检索能力有决定性影响。我们证明了即使存在逐字逐句的完全匹配，这个结论也同样成立。

问题并不在于嵌入模型执行语义匹配的能力。像 jina-embeddings-v3 这样的嵌入模型在处理短上下文时表现相当好，但随着上下文长度增加，其有效性会下降。查询扩展可以在一定程度上减轻这种影响，但检索质量仍会随着上下文变长而下降。此外，查询扩展还带来了额外的问题，因为识别出能够改进检索而不增加语义噪声的扩展词至关重要。我们正在研究并寻找方法直接解决大海捞针式检索问题，并改进未来 jina-embeddings-v4 的性能。