从召回一堆噪音到提升精准度：我的RAG从Embedding-Only到引入Rerank的实践和思考

写在前面： 这篇文章对于很多资深技术人来说，可能有点“小儿科”，但我还是想分享出来。因为它不仅记录了一次技术方案的演进，更重要的是，它是我自己当时最真实的认知成长过程。

在项目开发里，我们常说一句话：版本1.0，永远只是个开始。

任何一个从“能用”到“好用”的项目，都必然经历一个不断发现问题、解决问题、持续迭代的过程。今天这篇文章，不算是一篇纯粹的技术分享，我更想把它看作是一段刚接触RAG项目时的复盘，和大家聊聊这个“迭代与成长”的话题。

在这篇文章里，你将看到：

• • 一个似曾相识的故事： 我是如何从一个只懂 Embedding 的新手，在现实的“毒打”下，一步步认识到 Rerank 模型的重要性。
• • 一次心路历程的转变： 从 V1.0 的“理想丰满”到 V1.5 的“现实骨感”，这背后有哪些思考和挣扎。
• • 一些务实的技术实践： 我会附上 Embedding 和 Rerank 的核心原理、我用过的模型清单，以及基于 vllm 的本地部署代码。

我的V1.0起点：万物皆可Embedding

和大多数开发人员一样，我搭建第一个RAG应用的起点，就是Embedding模型和向量数据库。我的理解是，它的核心任务就是为文本建立一种“数学身份”，也就是向量。 我深入研究了一下，这种模型在技术上通常被称为“Bi-Encoder”（双编码器）。它的工作哲学是“分离再比较”，非常高效：

1. 1. 离线索引 (Indexing)：它会提前把知识库里所有的文档，通过编码器（Encoder）独立计算，生成各自的文档向量（Document Vector），并存入数据库。这步是预处理，可以慢慢来。
2. 2. 在线检索 (Retrieval)：当用户提问时，它用同一个编码器，将问题（Query）也计算成一个查询向量（Query Vector）。
3. 3. 相似度计算 (Similarity Search)：最后，拿着这个查询向量，去数据库里和海量的文档向量进行快速的数学运算，找出最相似的Top-K个。

这里提到的“数学运算”，最经典的就是余弦相似度（Cosine Similarity）。它衡量的是两个向量在方向上的接近程度，而不关心它们的绝对大小。公式如下：

这个公式的结果在-1到1之间。越接近1，代表两个向量方向越一致，也就是语义越相似。 Bi-Encoder的这种机制决定了它的最大优点就是快。因为最耗时的文档编码工作已经提前完成，实时检索几乎就是纯粹的数学计算。当时的我，一度认为只要Embedding模型选得足够好，一切问题都能迎刃而解。

【感悟加笔】 现在回想起来，这其实是很多技术新人（包括当时的我）很容易陷入的一个误区：总希望能找到一个‘银弹’，一个能解决所有问题的完美工具。我希望找到性能最好的Embedding模型，却忽略了任何单一工具都有其固有的设计边界。

V1.0的现实考验：一堆“看似相关”的噪音

在真实项目中，我很快遇到了瓶颈。在一个内部技术问答的场景里，我问：“如何在我们的A产品里配置缓存？” 向量库返回了10个结果。第一个确实是A产品的缓存配置。但紧随其后的，是B产品、C产品的缓存配置文档。 从Bi-Encoder和余弦相似度的角度看，这个结果完全合理。这些文档都高度包含了“产品”、“配置”、“缓存”的语义，它们的向量在多维空间里确实离我的问题向量很近。 但对于用户来说，除了第一个，其余的都是“语义相似，但意图不符”的噪音。我意识到，单靠Embedding实在堪忧。我需要一个更精细的手段来做二次筛选。

【感悟加笔】 这个阶段其实是挺磨人的。看着系统返回了一堆看似相关却毫无用处的结果，我甚至一度怀疑是不是我的分块策略、数据清洗出了问题。这种感觉，就像是你明明知道答案就在这座图书馆里，但图书管理员却一次次给你拿来一堆封面相似、内容完全不对的书。这让我深刻体会到，召回率高只是第一步，如果不能把最精准的结果送到用户面前，系统的体验就是失败的。

我意识到，我的V1.0版本存在一个严重问题：召回率（Recall）或许不低，但精确率（Precision）实在堪忧。我需要一个更精细的手段来做二次筛选，我的项目需要迭代了。

认知迭代：重新理解“相关性”

这就是我遇到Rerank（重排序）模型的契机。它提供了一种截然不同的、更精细的判断方式。成为了我项目V1.5升级的关键。 它的核心技术被称为“Cross-Encoder”（交叉编码器），工作哲学是“融合再判断”：

1. 1. 输入拼接：它不会独立计算问题和文档的向量。相反，它会将问题（Query）和每一个候选文档（Document）进行拼接，形成一个更长的文本序列，例如：[CLS] Query_Text [SEP] Document_Text [SEP]。
2. 2. 深度交互：将这个拼接后的序列，完整地输入到一个强大的Transformer模型（如BERT）中。在模型内部，自注意力机制（Self-Attention）可以充分捕捉问题中的每个词与文档中每个词之间复杂的依赖和关联。这是一种真正的“交叉阅读理解”。
3. 3. 输出一个分数：模型最终通常会利用[CLS]这个特殊标记位的输出向量，经过一个全连接层和激活函数（如Sigmoid），直接给出一个代表相关性的单一分数（例如0到1之间）。

这个过程可以简单理解为：

Cross-Encoder因为需要对每个“问题-文档”对都进行一次完整的、复杂的模型推理，所以速度要比Bi-Encoder慢几个数量级。但它换来的是极高的判断精度，因为它不再是模糊地比较“方向”，而是在深层语义上判断“这份文档是否真的在回答这个问题”。

务实的选择：一些我关注过的模型

为了让大家少走弯路，我整理了一份目前社区里口碑和性能都很出色的模型清单。当然也可以去MTEB榜单自选，先从“最优”，然后结合实际需求选择效果以及速度性价比较高的模型。

Embedding模型 (负责“粗筛”，追求召回)

Rerank模型 (负责“精选”，追求精准)

本地部署与调用

我不习惯用Ollama跑任何模型，因为感觉像是阉割版一样，所以关于模型部署及测试都是使用vllm或者sglang实现。

部署Embedding模型 (以bge-m3为例)

vllm serve BAAI/bge-m3 \
--served-model-name bge-m3 \
--dtype bfloat16 \
--task embed \
--enforce-eager \
--trust-remote-code

import requests
import json

# 定义vLLM服务的地址和模型名称
VLLM_URL = "http://localhost:8000/v1/embeddings"
MODEL_NAME = "bge-m3"

headers = {"Content-Type": "application/json"}
data = {
    "input": ["你好，世界！", "Hello, world!"],
    "model": MODEL_NAME
}

# 发送请求
response=requests.post(VLLM_URL,headers=headers,data=json.dumps(data))

# 打印结果
if response.status_code == 200:
    embeddings = response.json()['data']
    print(f"成功获取 {len(embeddings)} 个向量。")
    print(f"第一个向量的维度: {len(embeddings[0]['embedding'])}")
else:
    print(f"请求失败: {response.text}")

部署Rerank模型 (以bge-reranker-large为例)

vllm serve BAAI/bge-reranker-v2-m3 \
--served-model-name reranker \
--task score \
--dtype bfloat16 \
--enforce-eager \
--trust-remote-code

import requests
import json

# 定义Rerank服务的地址和模型名称
VLLM_URL = "http://localhost:8000/v1/rerank"# 假设vLLM在同一端口，实际应用中请用不同端口
MODEL_NAME = "reranker"

query = "如何配置A产品的缓存？"
documents = [
    "这里是关于A产品缓存配置的详细说明...", # 正确答案
    "B产品的缓存配置方式如下...",         # 噪音1
    "数据库缓存优化技巧。",                 # 噪音2
    "关于A产品的网络设置。"# 噪音3
]

headers = {"Content-Type": "application/json"}
data = {
    "model": MODEL_NAME,
    "query": query,
    "documents": documents,
    "top_n": len(documents) # 返回所有文档的分数
}

# 发送请求
response=requests.post(VLLM_URL,headers=headers,data=json.dumps(data))

# 打印结果
if response.status_code == 200:
    results = response.json()['results']
# 按分数从高到低排序
sorted_results=sorted(results,key=lambdax:x['relevance_score'], reverse=True)

    print(f"查询: {query}\n---")
    for res in sorted_results:
    print(f"分数: {res['relevance_score']:.4f} | 文档: {documents[res['index']]}")
else:
    print(f"请求失败: {response.text}")

运行后会清晰地看到，正确答案的分数会远高于其他噪音文档，这就是Rerank的价值所在。

最后的思考

回顾这段经历，我最大的收获是理解了“先召回（Recall），后精排（Rank）”这个两阶段策略的必要性。它不是一个花哨的技巧，而是一个在速度和精度这对矛盾体之间寻求最佳平衡的、非常成熟的工程思想。

• • Embedding (Bi-Encoder) 负责广度和速度，它像一个宽大的漏斗入口，保证我们不会错失任何潜在的答案。
• • Rerank (Cross-Encoder) 负责深度和精度，它像漏斗的狭窄出口，保证最后输出的是最高质量的信息。

这个过程也让我更加确信，技术之路，本就是一场不断迭代的旅程。没有一蹴而就的完美方案，只有在一次次遇到问题、分析问题、解决问题的循环中，我们的项目和我们自己，才能一同成长。 不知道刚入门RAG的你是否也不知道Rerank这个模型，反正我当时是不知道，希望我这段思考和实践，能对各位有所启发，任何技术都是靠实践积累起来的，不能因为当时的技术沉淀就否定或者看不起同行。