你的 Embedding 模型选择决定了 RAG 的上限，而 LLM 无法突破它

我建议的一个团队花了两个月时间在其 RAG 流水中不断更换 LLM。从 Claude 到 GPT，再到 Gemini，最后又换了回来。每一次更换都能让幻觉率降低几个百分点，但从未在关键指标上有所进展：他们的支持代理找到正确知识库文章的概率仍然不到 60%。他们调优的层级错了。检索器返回的是无关的文本块，而无论 LLM 多聪明，都无法根据检索器从未呈现过的文档来回答问题。

嵌入模型是 RAG 系统中决定 LLM 甚至“被允许”看到什么的部分。它描绘了语料库的几何结构——即在向量空间中，哪些文档会落在哪些查询附近。一旦这种几何结构出错，LLM 就只是一个对错误上下文侃侃而谈的自信叙述者。换一个更聪明的 LLM 通常只会让回答更显“文采”，而不会让回答更准确。

这篇文章将探讨为什么嵌入层是检索流水线中最高杠杆的选择，以及我选择模型时使用的框架：领域匹配优先，其次是维度与召回率的权衡，然后是多语言行为，最后是指令微调。大多数团队在质量进入瓶颈期之前，对这一层的投入都严重不足，直到最后才发现，他们的生成预算一直被浪费在偿还“检索债”上。

检索天花板是真实存在的，而且比你想象的要低

在开展任何 RAG 项目之前，都值得进行这样一个思想实验：假设 LLM 是完美的。假设它从不产生幻觉，遵循每一条指令，逻辑推理无懈可击。那么你系统准确性的上限是多少？答案就是检索器返回正确文档的查询比例。这个数字就是你的“检索天花板”，它限制了下游的一切。

团队往往是在碰壁后才意识到这一点。他们运行流水线，看到平庸的输出，然后去调节最显眼的旋钮：LLM。但如果检索器仅在 70% 的时间内能找到正确的文本块，那么即便使用一个在宇宙热寂背景下训练出来的模型，系统准确率也无法超过 70%。天花板在嵌入步骤中就已经设定好了——就在查询被转换为向量并与语料库匹配的那一刻。

这种情况的隐蔽之处在于，其症状看起来很像 LLM 的问题。模型“忽略”了提供的上下文（因为提供了错误的上下文）。模型“虚构”了答案（因为正确的片段不在前 k 个结果中）。模型在不同查询之间“自相矛盾”（因为语义等价的查询返回了不同的邻域）。所有这些都被诊断为生成问题，并尝试通过提示工程（Prompt Engineering）来解决。实际上，修复工作应该在更上游的地方进行。

一个有效的诊断方法是：在你的流水线中增加记录功能，将检索到的文本块与模型输出一并记录，然后由人工分别评估“检索到的文本块是否正确”以及“答案是否正确”。大多数团队会发现，在失败的查询中，有 30–50% 是因为检索错误。这就是天花板。更换 LLM 无法改变这一点。

领域匹配几乎总是胜过排行榜名次

很多团队在选择嵌入模型时会参考 MTEB 排行榜。但这其实是一个错误的的首要信号。MTEB 衡量的是在网络文本、新闻、维基百科和学术摘要上的表现。如果你的语料库是生物医学文献、财务报告、法律合同、源代码或行业特定的支持工单，排行榜的排名几乎无法告诉你该模型在你的数据上的表现。

这在一定程度上是覆盖范围问题，也是数据污染问题。MTEB 数据集存在的时间已经足够长，以至于较新的模型已经将其纳入了训练分布，“零样本测试”与“在相似数据集上训练”之间的界限已经模糊。此外，该基准测试在拥有大量公共数据的任务（如语义文本相似度、通用检索）上权重过高，而对大多数企业真正关心的领域代表性不足。

实际的做法是在选择模型之前，建立一个小型领域内评估集。准备 200 个查询，并手工标注正确的文档，这些查询应源自真实的用户行为或生产日志。针对该集合运行前三或四个候选模型，并观察 recall@10 和 MRR。你会发现排名通常会与 MTEB 相反。一个在排行榜上排名第七的通用模型，在你的特定语料库上的表现可能会比第一名高出 10 到 15 个百分点。

对于专业领域，如果存在微调后的变体，请优先选择。例如：针对医学文本的 PubMedBERT 和 BioLORD；针对财务报告的 Voyage Finance 和 BGE Financial Matryoshka；针对代码库搜索的特定代码嵌入。在这些领域，它们相对于通用模型的提升通常在 10–30% 之间。如果你的领域还没有现成的微调变体，那么在几千个“查询-文档对”上微调基础模型，通常比升级 LLM 的投资回报率更高。

维度是成本杠杆，而非质量旋钮

存在一种普遍误解，认为维度越高，检索效果越好。有时在边缘情况下确实如此，但大多数情况下并非如此。马特廖什卡表示学习（Matryoshka Representation Learning, MRL）改变了这一计算方式，以至于在 MRL 成为标准之前做出的任何决定，可能都值得重新审视。

MRL 在训练嵌入模型时，会让靠前的维度携带最重要的语义信息，而靠后的维度则添加更精细的细节。结果是，你可以将 3,072 维的向量截断到 1,024 或 512 维，而仅损失几个百分点的检索质量。Gemini Embedding 2 在从 3,072 维降至 2,048 维时，其 recall@10 的损失不到 1%；而 Jina v3 即使在 64 维时也能保持全维度性能的 92%。

加载中…