在构建基于大语言模型的知识库时检索往往是决定系统好坏的“门槛”。Ru果检索不到精准片段，即使再强大的生成模型也只Neng瞎猜。下面我把自己踩过的坑、尝试过的方案全部拆开聊聊，让你不必再走弯路。

大多数 RAG 项目在Zui开始就盲目调 chunk_sizetop_k，却忽视了根本问题：

文档交叉引用太密集：比如《诸葛亮传》里频繁出现“曹操”，而《曹操传》又提到赤壁。这种相互渗透会让向量相似度误把“曹操”当成答案。

用户提问口语化：“他打赤壁那次用了什么计策？” 与文档中正式的 “赤壁之战的火攻策略” 差距大，直接向量匹配常常找不到对应片段。

专有名词匹配弱：BM25 Neng抓关键词，向量搜索擅长语义，但单独使用时要么漏掉关键字，要么把相似概念混进去。

确认了这些痛点后我们才Neng有针对性地去补刀。

Zui直接的办法是把 BM25和向量检索并行，让两条路各自挑选出候选，再统一融合。下面是一段Ke以直接跑通的示例代码：

from langchain_community.retrievers import BM25Retriever
from langchain.retrievers.ensemble import EnsembleRetriever
def build_hybrid_retriever:
    """
    构造同时使用 BM25 与向量模型的混合检索器。
    chunks   ：文本切块列表
    vectorstore：Yi创建好的 ChromaDB 实例
    k       ：每个子检索返回的候选数
    """
    # 关键词检索器
    bm25 = BM25Retriever.from_documents
    bm25.k = k
    # 向量检索器
    vec_ret = vectorstore.as_retriever
    # 两路结果等权融合，可自行调 weight
    hybrid = EnsembleRetriever(
        retrievers=,
        weights=   # 若专有名词多，可把 bm25 权重调高
    )
    return hybrid

使用时只需要把原来的 vectorstore.as_retriever 替换成上面的 hybrid.invoke 即可。

虽然混合Neng显著提升召回率，但返回的前 K 条往往没有经过细致排序——它们可Neng同样重要，也可Neng差距hen大。于是我们需要进一步“精排”。

BGE‑Reranker 是当前比较流行的一款交叉编码模型，只要把查询和候选文档一起喂进去，就Neng得到精准的相关度分数。下面是调用硅基流动提供 API 的完整示例：

import os, requests
API_KEY = os.getenv
RERANK_ENDPOINT = "https://api.siliconflow.cn/v1/rerank"
def rerank_docs:
    """
    对Yi经召回的文档进行二次排序。
    query : 用户原始提问
    docs  : List，每个 Document 包含 page_content 字段
    top_n : Zui终保留多少条
    """
    if not docs:
        return 
    texts = 
    payload = {
        "model": "BAAI/bge-reranker-v2-m3",
        "query": query,
        "documents": texts,
        "top_n": top_n,
        "return_documents": True,
    }
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    }
    resp = requests.post
    data = resp.json
    ordered = 
    for item in data.get:
        idx = item
        ordered.append
    return ordered

小贴士：

Poor query → poor rerank. 在调用 Reranker 前务必确保查询足够清晰，否则模型只Neng在Yi有噪点中挑刺。

A/B 测试不可少。 同一批次数据分别走仅向量、仅 BM25、以及混合+Rerank，对比准确率与召回率，你会kan到明显差距。

L​LM 本身非常擅长将口语化的问题转换为结构化、覆盖面geng广的搜索词。例如把「他打赤壁那次用了什么计策？」拆成三条：

"赤壁之战 火攻 战术"

"曹操 赤壁 失败 原因"

"208 年 赤壁 战役 经过"

以下代码展示了如何通过 Prompt 完成自动 ：

REWRITE_PROMPT = """你是一个检索助理，请把用户的问题
为 {n} 条不同角度的搜索句子，每行一个，不要编号，也不要解释。用户问题：{question}"""
def rewrite_query -> list:
   prompt_tpl = ChatPromptTemplate.from_template
   chain = prompt_tpl | llm   # llm 为Yi经初始化好的语言模型实例
   result = chain.invoke
   queries = 
   # 把原始问题也加入，以防遗漏关键字
   queries.insert
   return queries

后的多条查询再分别走混合召回来一次并进行去重合并，伪代码如下：

def multi_query_retrieve:
   queries = rewrite_query
   base_ret = vectorstore.as_retriever
   seen_keys = set
   all_docs  = 
   for q in queries:
       for doc in base_ret.invoke:
           key = doc.page_content      # 简单去重依据，可自行换成 doc.metadata
           if key not in seen_keys:
               seen_keys.add
               all_docs.append
   return all_docs

def rag_pipeline:
   # 步骤1：
查询
   candidates = multi_query_retrieve
   # 步骤2：精排
   top10      = candidates
   final_res  = rerank_docs
   return final_res

只需一行 rag_pipeline, 就Neng得到Zui贴近答案的文档片段。

为了客观衡量优化效果，我推荐使用开源评估框架 . 它从以下维度打分：

CiteScore：

LinguisticScore：

KnowledgeRecall：

LlamaScore:

A/B 测试时把旧版与新版分别跑同一批询问，用上述指标对比，你会kan到 Recall 提升约 15%~20%，而生成错误率下降近一半。实际项目中，这种提升往往直接转化为用户满意度的大幅上升。

Ru果你还在仅靠单一向量搜索，那就像只给飞机装了螺旋桨——起步慢且容易失速。本文提供的一套「查询  → 混合召回 → 交叉编码重排」方案，是目前业界提升 RAG 检索质量Zui稳妥且易落地的方法。配上简单的评估脚本，你Ke以在几天内kan到准确率从六七成跃升至九十几成，用户满意度自然水涨船高。