RAG 检索不准，先评测嵌入模型

你的 LLM 收获了掌声，真正干活的却是 embedding 模型。如果你没有像挑选基础模型一样认真地选择它，就白白错过了本可以获得的效果提升。

#embeddings #rag #research

Rachel 的 RAG pipeline 遇到了麻烦。LLM 用的是最新模型，向量存储配置正确，分块策略也经过了基准测试。但用户还是不断反馈：面对完全合理的查询，系统返回的文档却毫不相关。她只换了一样东西——不是 LLM，不是分块大小，也不是检索数量，而是 embedding 模型。召回率一夜之间提高了 22 个百分点。

有些团队每个月都重跑聊天模型评估，却从未动过 embedding 模型，一直用着“向量数据库教程里顺手带的那个”。然后，他们又纳闷：为什么 RAG 找不到手册里出现了五十次的缩写？Embedding 才是搜索引擎，LLM 只是负责讲述的人。

Recall@5：决定是否更换 embedding 模型的指标——别只顾着研究余弦相似度。RAG 评估基线：2×，这是我们在技术语料上从通用检索器换成领域适配检索器时，经常看到的提升幅度。仅供示意，请用你自己的评估集验证。

准备 100–200 个真实问题，并明确每个问题的答案在哪里。测试不同的 embedding 模型，保持分块和 reranker 不变。做完这些，再考虑调整聊天模型。你往往会发现，无须额外成本就能提高准确率。

在 LLM 回答任何问题之前，检索系统就已经决定了要给它看什么。这个决定完全由 embedding 模型做出——它是将文本映射到向量空间的编码器。如果编码器扭曲了查询空间，检索器就会返回不相关的文本块。最后挨骂的是 LLM。Embedding 模型却隐身了：它悄无声息地出错，下游过度自信的回答又放大了这种错误。

Embedding 模型不只是“底层管道”，它是把关者。每个被它扭曲的查询，都会造成一次 LLM 无法纠正的检索失败。

更换 embedding 模型的操作规范

对所有内容重新生成 embedding，为索引设置版本，保留回滚方案——绝不要在周五直接在生产环境热切换。

维度与质量：只要召回率提高，维度更小并不意味着效果更差。

多语言：你实际存储的每一种语言，都要测试。

时效性：词汇发生变化时，例如出现新产品名称或新法规，要重新生成 embedding。

升级聊天模型令人兴奋，升级 embedding 模型带来收益。这是两种不同的会议。

Reranker 无法弥补糟糕的 embedding

有些团队在一堆质量糟糕的结果上加个 cross-encoder，就宣布问题解决了。Reranking 只是给垃圾重新排序，无法凭空找出那些根本没被检索到的相关文本块。先修好 embedding 和分块，再对排名靠前的二十个结果进行 rerank，别给错误的二十个结果重排。

MTEB 在涵盖 8 类任务的 58 个数据集上，对 162 个 embedding 模型进行排名。然而，在真实的 RAG pipeline 中，即使只是在前 15 名模型之间切换，效果也可能相差 15–25 个百分点。基准测试用的是教科书式的句子，生产环境中的查询却包含拼写错误、缩写、领域术语和不完整的信息，而基准评估完全没有覆盖这些情况。

整理一份生产环境样本：从日志里抽取 500 条真实搜索查询，让领域专家为每条查询标注最相关的 3 篇文档。在你自己的数据上评估 recall@k，而不是用 MTEB 的数据。我们经常发现，MTEB 排名第一的模型，在某个具体领域里只能排第三或第四，有时甚至更差。测试时要用你实际的分块大小，别用标准大小。较长的文本块会表现出不同的排序行为，与基准测试使用的 512-token 分块并不一样。还要用你实际的任务类型测试：分类任务的基准成绩，无法预测检索性能。如果你有足够的标注数据，可以训练领域专用的 embedding 模型。在召回率上，经过领域适配的 embedding 通常能比通用模型高出 15 个百分点以上。

你需要的不只是一个 embedding 模型，而是适合你的数据、分块大小和领域的那个模型。针对 MTEB 优化，不等于针对生产环境优化。

问题在于：embedding 评估实在不够吸引眼球。没人会发推炫耀自己把 recall@5 从 0.61 提高到了 0.79。但这恰恰决定了你的 RAG 是能上线交付，还是上线后在 Slack 里被大家静音。

Hard negatives：评估时加入相似但错误的文本块；只用容易匹配的正样本，结果会骗人。

缩写压力测试：SAP、内部代号、旧系统名称，都必须正确聚类。

Hybrid search：将 BM25 与向量检索结合；仅靠 embedding 会漏掉精确的 token 匹配。

索引版本管理：采用蓝绿索引重新生成 embedding，并保留回滚能力；绝不要在周五热切换。

升级聊天模型带来令人兴奋的会议，升级 embedding 模型带来收益可观的季度。两件事都要安排。

什么时候该 fine-tune embedding

当你有数千组经过标注的查询与文本块配对，并且分块已经做好、通用模型却仍然无法处理领域术语时，可以考虑进行领域 fine-tune。否则，先试试混合检索和查询扩展——成本更低、速度更快，而且容易撤回。

从三个不同类型的 embedding 模型开始：一个通用模型，例如 text-embedding-3-large；一个领域专用模型，例如用于企业场景的 e5-mistral-7b-instruct；再加一个轻量模型，例如用于延迟敏感路径的 gte-small。在标注过的生产环境样本上跑 recall@k，让数据来选。

RAG 的大多数问题都出在检索。升级负责讲述的模型之前，先把检索修好。

将重新生成 embedding 作为项目来执行

为一千万个文本块重新生成 embedding，是一个项目，不是改个配置。要提前规划蓝绿索引、磁盘空间、验证窗口和回滚方案，并告知相关人员：切换期间，搜索质量可能发生变化。

这对你意味着什么：像安排数据库迁移一样安排重新生成 embedding 的工作。冻结无关改动，切换前测量召回率。Embedding 升级需要操作手册，别把它当成周五的临时实验。

查询侧同样重要

糟糕的查询会浪费优秀的 embedding。在问题侧做查询扩展、hyde 和拼写规范化，往往比再换一次 embedding 模型更有效。要从整体上调整检索流程：查询、索引、rerank、生成。

这对你意味着什么：记录检索失败的案例，并保留原始查询。你会逐渐发现一些规律：缩写、拼写错误、过于宽泛的问题。在为数百万个文本块重新生成 embedding 之前，先解决上游的问题。

排行榜与你自己的手册

MTEB 不会测试你的内部缩写。从真实工单中整理 200 个问题，并确保你知道每个问题对应的原文段落。这才是你的 embedding 评估榜，其他的都是噪声。

这对你意味着什么：当语料中的词汇发生变化时，例如产品发布、组织调整、新法规出台，要重新跑这套评估。Embedding 会随着语言变化而老化。

存储与维度的取舍

更小的 embedding 能节省 RAM 和磁盘空间，但前提是召回率不能下降。要衡量搜索的总成本——索引大小、查询延迟、重新生成 embedding 的耗时——别只看向量维度。有个团队发现，把通用模型换成领域适配模型后，他们内部知识库的召回率从 67% 提高到了 89%，而生成部分的代码一行都没改。

这对你意味着什么：把 embedding 评审安排在聊天模型升级评审的同一周。检索决定了答案的一半。忽视检索，一味升级负责讲述的模型，结果就是 RAG 的问题依旧，LLM 的账单却越来越高。

升级 embedding 时，要同时在 metadata 中加入分块版本标签。排查检索效果退化时，比较不同代际的索引，别靠猜测判断是哪次重新生成 embedding 搞坏了周一的搜索。每个季度固定一套评估集，确保比较时使用相同的条件。

在下一次模型发布前，建好包含 200 个问题的评估集

从真实工单中提取真实问题，记录每个问题对应的原文段落。每当有人提议更换 embedding 模型，就跑这套评估——分块固定，问题固定。这对你意味着什么：这套评估比任何 MTEB 排名都更有价值，因为它测试的是你的模型能否找到你们手册里出现了五十次的缩写，而不是能否检索别人的网页文本。

问题在于：聊天模型升级获得的是令人兴奋的会议，embedding 模型升级带来的是收益可观的季度。两件事都要安排，但别让讲述者赢得的掌声，分散了你对真正负责查找信息的搜索引擎的注意力。

Embedding 模型是整个 pipeline 中最缺乏深入研究的性能杠杆。像评测 LLM 一样评测它，你的生产数据会证明这件事值得做。

快速检查：这些要点记住了吗？

Ayraix.com 发布方分析

我们真正看到的是什么

Embedding 模型是 RAG 系统中默默付出的功臣，却常常因为光鲜亮丽的 LLM 而被忽视。但 Rachel 的 RAG pipeline 经历说明，更换 embedding 模型可以显著提高召回率，甚至一夜之间提升 22 个百分点。这说明 embedding 不只是“底层管道”，它是相关性和准确性的把关者。团队应该优先定期升级和测试 embedding，而不是只对聊天模型做渐进式改进。毕竟，调校得当的 embedding 可以节省大量调试时间，也能减少用户的挫败感。

是时候把注意力从 fine-tune LLM 转向优化 embedding 了。这样，我们才能确保检索系统提供最相关的信息，为更准确、更有价值的用户交互打下基础。在下一轮评估中，优先测试更换 embedding 模型，看看它能为 RAG 系统带来怎样的积极影响。

继续在 ayraix.com 探索

构建个人 AI 大脑：Qdrant、Embedding 与记忆的幻觉　社区

在本地运行 LLM 的真正成本（和你想的不一样）　社区

不受污染的 Agent 记忆　社区

优化 RAG 系统时，你会优先考虑什么？

你认为 RAG 系统的哪个方面更值得关注：embedding 模型，还是聊天模型？分享你的想法！

无须账号——选一个观点，然后继续阅读。我们会轮换这些提问，让每篇文章都像一场对话，而不是复制出来的模板。

阅读助手：AI 已经读过这篇文章。你可以提问、质疑其中的观点，或进一步深入探讨。

本文最初发表于 ayraix.com，为企业应用构建者提供实用的 AI 内容。

如需采取进一步措施，可以考虑屏蔽此人和／或举报滥用行为。