1. 先搞清楚：Embedding RAG 到底卡在哪一步

Embedding RAG 这个词这两年几乎成了知识库应用的默认方案。你把文档切块、送进 embedding 模型、存进向量库，用户提问时把问题也转成向量，做一次相似度检索，再把召回的内容塞进大模型上下文里生成答案。流程听起来干净利落，Demo 跑起来效果也常常让人眼前一亮。但真正把它放到生产环境里跑上几周，问题就会一个接一个冒出来：明明文档里写得很清楚，检索就是召不回来；召回来的内容答非所问；同一个问题换个问法，结果天差地别。

于是就有了标题里这个疑问——Embedding RAG 还值得优化吗？我的答案是：值得，但优化的重点早就不是“换个更大的 embedding 模型”这么简单了。真正拉开效果差距的，是检索链路的整体设计，尤其是 BM25 这类稀疏检索、重排模型、以及查询改写这些环节的配合。单纯堆 embedding 模型参数，边际收益已经非常低了。

这篇文章我想把 Embedding RAG 的优化空间彻底拆开讲一遍。从为什么纯向量检索会失效，到 BM25 和向量检索怎么混合，再到重排模型怎么选、查询侧怎么改写、切块策略怎么调，最后给一套可以直接抄的本地知识库搭建方案。适合已经跑过 RAG Demo、但效果不达预期、想认真做优化的开发者，也适合刚接触 RAG 想少走弯路的新手。

2. 纯向量检索为什么会失效：Embedding 的边界在哪

2.1 向量相似不等于语义相关

很多人对 embedding 有个误解，觉得“语义相似度”就等于“内容相关”。实际上 embedding 模型训练的目标是把语义相近的文本拉到向量空间里靠近的位置，但“语义相近”和“能回答这个问题”是两回事。

举个我实际踩过的例子。知识库里有一句“报销流程需在费用发生后 15 个工作日内提交”。用户问“报销最晚什么时候交”。这两句话语义确实接近，向量检索大概率能召回。但如果用户问“出差回来多久内要报销”，embedding 模型可能就有点吃力了，因为“出差回来”和“费用发生后”在字面上差异较大，而模型对时间起算点的理解并不总是准确。更麻烦的是，如果知识库里同时有“报销需在 15 个工作日内提交”和“借款需在 30 天内归还”，向量检索很可能把两条都召回，甚至把借款那条排在前面，因为它们在向量空间里离得太近了。

这就是纯向量检索的第一个硬伤：它对精确匹配不敏感。数字、专有名词、代码标识符、产品型号这些内容，embedding 模型往往会把它们“平滑”掉，导致检索时丢失关键区分度。

2.2 长文档切块带来的语义稀释

第二个常见问题是切块。RAG 的标准流程是把长文档切成固定长度的 chunk，比如 512 token 一块。但切块本身就是一种信息破坏。一个完整的论述被拦腰截断，前半块讲问题背景，后半块讲解决方案，用户问解决方案时，检索可能只召回了前半块，因为前半块里关键词更密集。

我见过最离谱的案例是一个技术文档，某个配置项的说明跨了两个 chunk，第一个 chunk 结尾是“该参数默认值为”，第二个 chunk 开头是“3000，单位为毫秒”。用户问“这个参数默认多少”，检索召回了第一个 chunk，模型看到“默认值为”后面没了，直接编了一个“默认值为 1000”。这种问题不是换 embedding 模型能解决的，是切块策略的问题。

2.3 查询和文档的语义鸿沟

第三个问题是查询侧和文档侧的表述差异。用户提问是口语化的、简短的、带上下文的，而知识库文档是书面化的、完整的、去上下文的。embedding 模型虽然能把两者映射到同一空间，但这个映射并不完美。

比如用户问“你们家退货要几天”，文档里写的是“自签收之日起 7 个自然日内可申请无理由退货”。这两句话的向量相似度可能只有中等水平，因为“你们家”这种口语表达在文档里根本不存在。如果知识库里还有一条“换货需在 15 天内申请”，向量检索甚至可能把换货那条排到退货前面，因为“退货”和“换货”在向量空间里太近了。

提示：如果你的 RAG 系统在数字、日期、专有名词类问题上频繁出错，优先检查的不是 embedding 模型，而是检索链路里有没有精确匹配的补充机制。

3. BM25 为什么在 RAG 里重新翻红

3.1 BM25 的本质：关键词匹配的统计学优化

BM25 是一个经典的信息检索算法，核心思想是：一个词在文档里出现得越多，文档越相关；但这个词在整个语料库里越常见，它的权重就越低。同时，BM25 还考虑了文档长度的影响，长文档里的词频会被归一化，避免长文档因为词多而占便宜。

用大白话说，BM25 擅长的是精确关键词匹配。用户问“报销 15 个工作日”，BM25 会精确找到包含“报销”“15”“工作日”这些词的文档块，而且因为“15”和“工作日”在整个语料库里不常见，它们的权重会很高。这正是 embedding 模型不擅长的部分。

3.2 稀疏检索和稠密检索的互补关系

向量检索是稠密检索，它把文本压缩成一个固定维度的向量，擅长捕捉语义相似性，但对精确匹配不敏感。BM25 是稀疏检索，它基于词频统计，擅长精确匹配，但不懂语义。

这两者的关系不是替代，而是互补。我实测下来，在大多数知识库场景里，混合检索（BM25 + 向量）比纯向量检索的召回率能提升 15% 到 30%，具体提升幅度取决于知识库的内容类型。如果知识库里数字、代码、专有名词多，提升更明显；如果是纯散文类内容，提升会小一些，但依然有收益。

3.3 混合检索的分数融合策略

混合检索的关键是怎么把 BM25 的分数和向量相似度分数融合到一起。这两种分数的量纲完全不同，BM25 分数可能是 0 到 20 之间的任意值，向量相似度通常是 0 到 1 之间的余弦相似度。直接相加是不行的。

常见的融合策略有三种：

我个人最常用的是 RRF（Reciprocal Rank Fusion）。它的做法很简单：对每个文档，分别计算它在 BM25 结果里的排名和向量结果里的排名，然后算1/(k+rank)的和，k 通常取 60。RRF 的好处是不需要关心分数归一化，而且对异常分数不敏感。实测下来，RRF 在大多数场景里都比加权求和更稳，省去了调权重的麻烦。

def rrf_fusion(bm25_results, vector_results, k=60): scores = {} for rank, doc_id in enumerate(bm25_results): scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1) for rank, doc_id in enumerate(vector_results): scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1) return sorted(scores.items(), key=lambda x: x[1], reverse=True)

这段代码可以直接用，bm25_results和vector_results分别是两个检索器返回的文档 ID 列表，按相关性从高到低排列。融合后的结果就是最终召回列表。

4. 重排模型：RAG 效果提升性价比最高的一环

4.1 为什么需要重排

混合检索解决了召回率的问题，但召回列表里往往有几十条内容，真正相关的可能只有前几条。而且混合检索的排序并不总是准确，BM25 可能把关键词匹配但语义不相关的排前面，向量检索可能把语义相近但答非所问的排前面。

重排模型的作用就是对召回列表做二次排序。它通常是 Cross-Encoder 结构，把查询和每个候选文档拼在一起送进模型，输出一个相关性分数。因为 Cross-Encoder 能同时看到查询和文档的完整内容，它的判断比双塔结构的 embedding 模型准确得多。

4.2 重排模型的选型对比

目前常用的重排模型有几类：

我的经验是，中文知识库优先用 BGE-Reranker-large，它在中文语义理解上表现很稳。如果延迟要求高，可以用 BGE-Reranker-base，效果差距不大但速度快一倍左右。如果预算允许，Cohere Rerank 的效果确实更好，但 API 调用有成本，而且数据要出境，这个需要自己权衡。

4.3 重排的实操参数

重排模型的使用有几个关键参数：

• 召回数量：混合检索召回多少条送给重排。太少可能漏掉相关内容，太多会增加延迟。我一般设 20 到 50 条，具体看知识库规模和延迟要求。
• 重排后保留数量：重排后取前几条送给大模型。通常 3 到 5 条就够了，太多会稀释上下文，还可能引入噪声。
• 批处理大小：重排模型推理时的 batch size。GPU 显存够就设大一点，能提升吞吐。

from FlagEmbedding import FlagReranker reranker = FlagReranker('BAAI/bge-reranker-large', use_fp16=True) pairs = [[query, doc] for doc in candidate_docs] scores = reranker.compute_score(pairs, batch_size=16) ranked = sorted(zip(candidate_docs, scores), key=lambda x: x[1], reverse=True) top_docs = [doc for doc, score in ranked[:5]]

这段代码是 BGE-Reranker 的标准用法，use_fp16=True能显著降低显存占用，batch_size根据显存调整。实测在 3090 上，batch_size 设 16 跑 50 条候选文档，延迟大概在 200 毫秒左右，完全可以接受。

注意：重排模型虽然效果好，但它是 Cross-Encoder，计算量比 embedding 大得多。如果你的知识库有几十万条文档，不要对所有文档做重排，只对混合检索召回的前几十条做重排。

5. 查询侧优化：被大多数人忽略的提效环节

5.1 查询改写为什么重要

前面讲了检索侧和重排侧的优化，但很多人忽略了查询侧。用户输入的查询往往很短、很口语化、甚至带有错别字。直接拿这个查询去检索，效果自然好不到哪去。

查询改写的思路是：在检索之前，先用大模型把用户查询改写成更适合检索的形式。比如把口语化表达改成书面化表达，把省略的信息补全，把模糊的指代明确化。

举个例子，用户问“那个报销的事咋弄”。改写后可能变成“报销流程是什么，需要提交哪些材料”。这个改写后的查询去检索，召回率会高很多。

5.2 多查询扩展

另一种查询侧优化是多查询扩展。同一个问题，让大模型生成多个不同角度的查询，分别检索后合并结果。比如用户问“怎么退货”，可以生成“退货流程”“退货条件”“退货所需材料”三个查询，分别检索后取并集。

这种做法的好处是能覆盖更多相关文档，缺点是会增加检索次数和延迟。我一般只在关键场景用，比如客服机器人，因为客服场景对召回率要求高，宁可多召回一些再重排。

5.3 HyDE：用假设答案来检索

HyDE（Hypothetical Document Embeddings）是一个很有意思的思路。它的做法是：先让大模型根据用户查询生成一个假设性的答案，然后用这个假设答案去检索，而不是用原始查询。

为什么这样有效？因为假设答案的表述风格更接近知识库文档，向量空间里的位置也更接近真实答案。用户查询是“报销几天内交”，假设答案是“报销需在费用发生后 15 个工作日内提交”，后者和知识库文档的相似度显然更高。

HyDE 的缺点是增加了一次大模型调用，延迟会上升。而且如果大模型生成的假设答案偏离太远，反而会引入噪声。我的经验是，HyDE 在事实型问答场景效果不错，但在开放性问题上要谨慎使用。

6. 切块策略：RAG 效果的地基

6.1 固定长度切块的问题

大多数 RAG 教程都用固定长度切块，比如 512 token 一块，重叠 50 token。这种做法实现简单，但问题很多。它不考虑文档的自然结构，可能把一句话切成两半，也可能把不相关的内容塞进同一块。

我见过一个案例，知识库里有一份产品手册，固定切块后，某个 chunk 里同时包含了“产品 A 的保修期是 1 年”和“产品 B 的保修期是 2 年”。用户问“产品 A 保修多久”，检索召回了这个 chunk，大模型看到两个保修期，直接答了“1 年或 2 年”。这就是切块不当导致的歧义。

6.2 语义切块和结构切块

更好的做法是语义切块或结构切块。语义切块是用 embedding 模型判断相邻句子的语义相似度，相似度低的地方作为切分点。结构切块是根据文档的标题、段落、列表等结构来切分。

结构切块在技术文档、法律合同、产品手册这类结构化内容上效果最好。因为这些文档本身就有清晰的层级结构，按结构切块能保证每个 chunk 的语义完整性。

from langchain.text_splitter import MarkdownHeaderTextSplitter headers_to_split_on = [ ("#", "Header 1"), ("##", "Header 2"), ("###", "Header 3"), ] splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on) chunks = splitter.split_text(markdown_doc)

这段代码用 LangChain 的 MarkdownHeaderTextSplitter 按标题层级切块，每个 chunk 都带有标题元数据。检索时可以同时利用内容相似度和标题匹配，效果比固定切块好很多。

6.3 小块检索，大块生成

还有一种策略叫“小块检索，大块生成”。具体做法是：把文档切成小块用于检索，但检索到之后，把小块所在的更大上下文一起送给大模型。这样既保证了检索的精确性，又保证了大模型有足够的上下文来生成答案。

实现方式是在切块时记录每个小块的父块 ID，检索到小块后根据父块 ID 取出完整的大块内容。LangChain 的 ParentDocumentRetriever 就是干这个的。

7. 一套可直接抄的本地 RAG 知识库方案

7.1 技术选型

说了这么多理论，给一套可以直接落地的方案。这套方案我实测跑过多个知识库项目，效果稳定，依赖也都是开源的。

7.2 完整流程代码

from langchain_community.document_loaders import PyMuPDFLoader from langchain.text_splitter import MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_community.vectorstores import Qdrant from rank_bm25 import BM25Okapi from FlagEmbedding import FlagReranker import jieba # 1. 加载文档 loader = PyMuPDFLoader("knowledge.pdf") docs = loader.load() # 2. 结构切块 md_splitter = MarkdownHeaderTextSplitter( headers_to_split_on=[("#", "h1"), ("##", "h2"), ("###", "h3")] ) chunks = [] for doc in docs: chunks.extend(md_splitter.split_text(doc.page_content)) # 3. 语义兜底切块 text_splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=50 ) final_chunks = text_splitter.split_documents(chunks) # 4. 构建向量库 embeddings = HuggingFaceBgeEmbeddings(model_name="BAAI/bge-m3") vectorstore = Qdrant.from_documents( final_chunks, embeddings, path="./qdrant_data" ) # 5. 构建 BM25 索引 tokenized_corpus = [list(jieba.cut(chunk.page_content)) for chunk in final_chunks] bm25 = BM25Okapi(tokenized_corpus) # 6. 混合检索 def hybrid_search(query, top_k=20): # 向量检索 vector_results = vectorstore.similarity_search(query, k=top_k) # BM25 检索 tokenized_query = list(jieba.cut(query)) bm25_scores = bm25.get_scores(tokenized_query) bm25_top = sorted(range(len(bm25_scores)), key=lambda i: bm25_scores[i], reverse=True)[:top_k] bm25_results = [final_chunks[i] for i in bm25_top] # RRF 融合 return rrf_fusion(vector_results, bm25_results) # 7. 重排 reranker = FlagReranker('BAAI/bge-reranker-large', use_fp16=True) def rerank(query, candidates, top_n=5): pairs = [[query, doc.page_content] for doc in candidates] scores = reranker.compute_score(pairs, batch_size=16) ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True) return [doc for doc, _ in ranked[:top_n]]

这套代码可以直接跑，依赖装好就行。jieba用于中文分词，BM25 需要分词后的语料。Qdrant 用本地模式，不需要额外起服务，适合快速验证。

7.3 参数调优建议

这套方案有几个关键参数需要根据实际情况调：

• chunk_size：512 是通用值，如果文档句子长、信息密度高，可以调到 768 或 1024。如果文档碎片化严重，可以降到 256。
• top_k：混合检索召回数量，建议 20 到 50。知识库大就设大一点，但不要超过 100，否则重排延迟会很高。
• 重排后保留数量：3 到 5 条。如果大模型上下文窗口大，可以放到 8 到 10 条，但要注意噪声。
• RRF 的 k 值：默认 60，一般不用调。如果发现 BM25 结果权重过高，可以调大 k 值。

8. 常见问题与排查技巧实录

8.1 检索召回率低怎么办

先确认是哪种类型的召回失败。如果是关键词类问题召回失败，检查 BM25 是否正常工作，分词是否正确。中文分词用 jieba 一般没问题，但如果有大量专业术语，可能需要自定义词典。

如果是语义类问题召回失败，检查 embedding 模型是否适合你的领域。通用 embedding 模型在垂直领域可能表现不佳，可以考虑用领域数据微调，或者换用在该领域表现更好的模型。

8.2 重排后效果反而变差

这种情况通常是重排模型和 embedding 模型不匹配导致的。比如 embedding 用 BGE-M3，重排用 Cohere Rerank，两者的语义空间不一致，重排结果可能和检索结果冲突。建议 embedding 和重排用同一系列的模型，比如都用 BGE 系列。

另一个可能是重排的候选集太小。如果混合检索只召回了 10 条，重排只能在 10 条里选，可能真正相关的内容根本没被召回。这时候要增大召回数量。

8.3 大模型答非所问

如果检索召回的内容是对的，但大模型答非所问，问题出在提示词上。检查提示词是否明确要求大模型基于给定上下文回答，是否要求大模型在上下文不足时明确说“不知道”。

我常用的提示词模板是这样的：

你是一个知识库问答助手。请严格基于以下上下文回答用户问题。 如果上下文中的信息不足以回答问题，请直接说“根据现有资料无法回答”，不要编造。 上下文： {context} 用户问题：{question}

这个模板的关键是“严格基于”和“不要编造”这两句，能显著降低大模型的幻觉率。

8.4 延迟太高怎么优化

RAG 的延迟主要来自三个环节：检索、重排、大模型生成。检索和重排的延迟通常可以接受，大模型生成才是大头。

如果延迟要求高，可以考虑：用更小的重排模型（base 代替 large）、减少召回数量、用流式输出让用户先看到部分结果、对大模型做量化或换用更快的推理框架。

8.5 常见问题速查表

9. 关于 Embedding RAG 优化的一些个人体会

回到标题的问题：Embedding RAG 还值得优化吗？我的答案是，值得，但优化的方向要选对。如果你还在纠结换哪个 embedding 模型，那可能已经走偏了。embedding 模型之间的差距，在大多数场景里远没有检索链路设计带来的差距大。

我自己的经验是，一个设计良好的混合检索 + 重排 + 查询改写的 RAG 系统，比一个只用最贵 embedding 模型的纯向量检索系统，效果要好得多。而且前者的成本往往更低，因为开源模型就能达到很好的效果。

另外，RAG 的优化不是一劳永逸的。知识库在变，用户在变，问题类型也在变。建议建立一套评估机制，定期用真实问题测试检索和生成效果，发现问题及时调整。评估集不用很大，几十条真实问题就够，但一定要覆盖不同类型的查询。

最后分享一个小技巧：如果你的知识库有明确的分类或标签体系，在检索时加上元数据过滤，效果提升会非常明显。比如用户问“产品 A 的保修政策”，检索时先过滤出产品 A 相关的文档块，再做相似度检索。这个改动很小，但效果提升往往比换模型还大。