引言

公司知识库接了 RAG 之后，业务方提了第二个需求："能不能让它答得再准点？"——这个"再准点"背后是实打实的吐槽：问"年假可以攒到明年吗"，它从员工手册里捞出一段"考勤打卡规则"；问"服务器扩容审批流程"，它把无关的"机房巡检 SOP"排在最前面。答案的来源没问题（文档库里确实有），但检索根本没把对的段落捞出来——生成模型再强，也架不住喂进去的是错料。

我们拉了 100 条真实业务问题的评测集，跑了一版基线：Top5 召回率只有 60%——40% 的问题，正确答案所在的段落根本不在喂给大模型的上下文里。大模型面对缺失的料，只能一本正经地编。

最终的优化路径非常经典，就三步：按段落语义切分 → BM25+向量混合检索 → Rerank 重排序，召回率从 60% 提到 95%。这篇文章把这 60% → 95% 的全过程完整还原：每一步的坏代码长什么样、为什么坏、怎么改、改完涨了几个点——这是一份可以照着抄的调优清单。

一、先搞清"召回率"：RAG 排障的第一性指标

1.1 三个指标别混着说

RAG 的效果问题要先拆开看，不同层的问题药方完全不同：

判断方法很简单：人工看 Top5 片段。如果正确段落压根不在里面 → 检索问题，先修召回；如果"在里面但排第三位，大模型只顾了前两条" → 排序问题；如果"片段对了但答案编的" → 生成问题。我们的问题属于第一类，且占比最大——先修检索。

1.2 评测集：没有它一切优化都是玄学

动手前先花半天建了评测集，这是整个调优的地基：

评测集构成（100 条）：
  ├─ 60 条：从真实客服/内部群高频问题采样（有业务代表性）
  ├─ 每条标注：标准答案所在的知识库文档 + 段落 ID（Ground Truth）
  └─ 20 条：故意设计的"库内无答案"问题（考察拒答，防幻觉回归）

def recall_at_k(eval_set, retriever, k=5):
    """Top-K 召回率：正确段落是否出现在前 K 个结果中"""
    hit = 0
    for q in eval_set:
        chunks = retriever.search(q.question, top_k=k)
        if any(c.chunk_id in q.gold_chunk_ids for c in chunks):
            hit += 1
    return hit / len(eval_set)

# 基线：0.60    ← 一切优化的起点

后面每一步优化都跑这 100 条，涨没涨、涨多少，数字说话。没有评测集的 RAG 调优 = 闭眼开药方。

二、诊断：坏在哪一层——切片、检索、还是排序

用评测集逐条归因，60% 召回率的"丢分"分布是这样的：

三个原因指向三层优化——正好对应三步法：

第一步：按段落语义切分      → 治"切碎"（45%）
第二步：BM25 + 向量混合检索  → 治"不识关键词"（30%）
第三步：Rerank 重排序       → 治"排不到前排"（25%）

下面逐步展开，每步给"坏实现 → 为什么坏 → 修复实现 → 实测涨幅"。

三、第一步：按段落语义切分（贡献 +9 个点）

3.1 坏实现：固定 500 字硬切

# ❌ 基线方案：按固定字符数切片
def naive_chunk(text, size=500):
    return [text[i:i+size] for i in range(0, len(text), size)]

这类"每 500 字切一刀"的方案有两个致命伤：

伤一：切断语义
  "...员工年假标准为 15 天，未休完的年假"
  ──────────────── 切割线 ────────────────
  "可结转至次年 3 月 31 日，过期作废。..."
  → "年假 15 天" 和 "结转到 3 月底" 分属两个 chunk
  → 查"年假能攒吗"两个都只给一半信息，检索器哪个都打不高分

伤二：制造"语义噪声段"
  制度文档里表格、目录、页眉拼接出来的 chunk，
  向量既不像问题也不像答案，纯粹是检索池的噪声

3.2 修复：结构感知 + 语义边界的分层切分

# ✅ 分层切分策略：能用文档结构就用结构，最后才按语义兜底
def semantic_chunk(doc_text, target=800, max_len=1200, overlap=150):
    """
    1. 先按 Markdown 标题/章节切大块（结构优先）
    2. 块超过 max_len 再按段落（\n\n）二次切
    3. 仍超长的段落按句号切，用滑动窗口带 overlap
    """
    sections = split_by_headers(doc_text)           # 一级：标题结构
    chunks = []
    for sec in sections:
        if len(sec) <= max_len:
            chunks.append(sec)
            continue
        for para in sec.split("\n\n"):              # 二级：自然段
            if len(para) <= max_len:
                chunks.append(para)
                continue
            chunks.extend(sliding_window_by_sentence(   # 三级：句子窗口
                para, window=target, overlap=overlap))
    return chunks

三条配套原则，比代码本身更重要：

** chunk 语义完整性快速自检**：随机抽 20 个 chunk，每个只看它自己——"一个不看上下文的人能看懂它在说什么吗？"看不懂的 chunk 就是切坏了。这招 5 分钟就能对切片质量做一次体检。

3.3 实测

四、第二步：BM25 + 向量混合检索（贡献 +14 个点）

4.1 先理解两种检索的天赋差异

两者的失败案例几乎不重叠——这就是混合检索的全部理论依据：取并集，让各自的盲区被对方覆盖。

4.2 修复：RRF 融合两路结果

# ✅ 混合检索：两路各取 Top20，RRF 融合
def hybrid_search(query, top_k=20):
    # 路线一：向量检索（bge-m3 等 embedding 模型）
    vec_results = vector_store.search(embed(query), top_k=top_k)

    # 路线二：BM25 关键词检索（Elasticsearch 或内存实现均可）
    bm25_results = es_client.search(
        index="kb_chunks",
        body={"query": {"match": {"content": query}}, "size": top_k})

    # Reciprocal Rank Fusion：k=60 是经典默认值
    # 每个文档得分 = Σ 1/(k + rank_i)，只看排名不看原始分（两路分数量纲不可比）
    scores = {}
    for rank, chunk in enumerate(vec_results):
        scores[chunk.id] = scores.get(chunk.id, 0) + 1 / (60 + rank + 1)
    for rank, chunk in enumerate(bm25_results):
        scores[chunk.id] = scores.get(chunk.id, 0) + 1 / (60 + rank + 1)

    return sorted(scores.items(), key=lambda x: -x[1])[:top_k]

实现要点：

4.3 实测

丢的那 30% 编号/条款类问题，BM25 一来基本全捞回来了。

五、第三步：Rerank 重排序（贡献 +12 个点）

5.1 为什么召回好还不够：Embedding 是"粗排"

混合检索解决了"捞没捞到"，但 Top20 里仍有大量"表面相似"的段落——比如问年假制度，员工手册的"考勤管理"章节和"请假流程"章节在向量空间里都很近。Embedding 模型是"一个问题一个向量"的双塔粗排，精度天花板低；Rerank 模型是"问题+段落成对喂进去"的交叉编码精排，直接算深层相关性——这就是 Rerank 一次性贡献 +12 个点的原因。

5.2 修复：粗排捞 20、精排选 5

# ✅ 完整检索管线：混合召回 Top20 → Rerank 精排出 Top5
from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

def final_search(query, recall_k=20, final_k=5):
    candidates = hybrid_search(query, top_k=recall_k)      # 第二步的混合检索

    # 交叉编码：逐对计算 query-chunk 相关性
    pairs = [(query, chunk.content) for chunk in candidates]
    scores = reranker.predict(pairs)

    ranked = sorted(zip(candidates, scores), key=lambda x: -x[1])
    top = ranked[:final_k]

    # 副产品：相关度阈值 → 自动拒答，防幻觉
    if not top or top[0][1] < 0.3:       # 阈值按评测集调
        return None                       # 触发"知识库中未找到"，模型诚实拒答
    return [c for c, s in top]

要点说明：

• 召回池 20 条是精度/耗时的平衡点：池子太小（10）精排没材料可选；太大（100）rerank 耗时线性膨胀（20 条约 200~400ms，100 条 1~2s）；
• Rerank 分数是"真正的相关性分"——顺手解决了拒答问题：最高分都低于阈值就别让大模型编了；
• 模型选择：bge-reranker-v2-m3（开源、中英双语、CPU 也能跑）起步，预算充足再上 Cohere Rerank / 自训。

5.3 实测：三步合计

注意涨幅曲线是"递减中仍可观"：第一步最便宜（改切片逻辑，零推理成本），第三步最贵（每查询多一次交叉编码）。预算紧张时按 1→2→3 顺序上，性价比顺序恰好也是这个顺序。

六、成本与延迟账：优化不是免费的

95% 召回率的代价要摊开看，方便你决定"要几步"：

延迟优化两招：① Rerank 与生成并行不了，但可以把"BM25 检索"与"向量检索"并行发（省一半检索串行时间）；② 高频问题加 query 级结果缓存（同样的问题 30 分钟内直接返回缓存的片段组）。

七、常见问题

7.1 为什么不直接调大 Top K（比如 Top20 全喂给模型）？

短期有效但三笔账不划算：① 上下文 token 翻倍，成本和首 token 延迟线性上涨；② 无关片段会污染生成——大模型面对 20 个片段，"东拼西凑答错"的概率显著上升（lost in the middle 效应），召回率上去了准确率反而可能下来；③ 排名第 15 的正确段落夹在垃圾中间，模型未必采纳。正确方向是"精排把对的 5 条顶到前面"，而不是"把更多料一次性怼进去"。

7.2 切片大小到底怎么定？有公式吗？

没有万能公式，但有可靠的定标流程：按候选值（400/800/1200/2000）各切一版入库，用评测集分别跑召回率，取最高值。我们的文档集 800 最优，但合同类长文可能 1500 更好，FAQ 类可能 300 就够——切片参数是文档集合的属性，不是 RAG 的常量。配合第三章的 20 抽样自检，半天能定标。

7.3 混合检索一定要 Elasticsearch 吗？

不一定要全套 ES。数据量 50 万 chunk 以内，BM25 用 Python 内存实现（bm25s 库）加内存向量索引（FAISS/hnswlib），单机就能撑住毫秒级检索，运维成本几乎为零。ES/阿里云检索服务的价值在亿级数据、多租户过滤、高可用——按规模选型，别一上来就搬重型中间件。

7.4 Rerank 模型怎么选？需要自己训吗？

起步用开源现成模型：bge-reranker-v2-m3（双语通用）覆盖 80% 场景。需要自训的信号：垂直领域术语体系特殊（医疗/法律/金融衍生品）、通用 reranker 在评测集上明显弱于 BM25 路径。自训数据就用评测集扩充（问题+正例段落+难负例），用 cross-encoder 微调几千条就有明显收益。先量测再自训，别上来就烧标注预算。

7.5 95% 之后还能再涨吗？边际在哪？

能，但下一阶段的重心不再是这三板斧：① Query 改写（口语问题改写成检索友好的规范表达，多查询扩展）、② 父子切片（子块检索、父块喂给模型，兼顾召回精度和上下文完整）、③ 元数据过滤（时间/部门/文档类型硬过滤先做减法再检索）。这些是"进阶篇"的内容，且收益边际递减明显——先把三步法吃干净，再谈进阶。

7.6 怎么防止上线后效果回退？

三个机制：① 评测集进 CI：每次换 embedding 模型/改切片参数，自动跑召回率，低于阈值流水线报警；② 线上采样回流：每周抽 100 条真实问答人工标注，评测集滚动扩充（真实分布漂移，比如新文档入库后的旧问题失效）；③ 建立基线看板：召回率/拒答率/平均延迟三个曲线，突变即查。RAG 是个系统不是一次性工程，评测集就是它的"单元测试"。

八、总结

三步法速查卡

┌─────────────────────┬──────────────────────────┬────────────────┐
│ 步骤                 │ 治什么                    │ 涨幅            │
├─────────────────────┼──────────────────────────┼────────────────┤
│ ① 按段落语义切分      │ 信息被切碎（45% 丢分）      │ 60→69（+9）    │
│   结构优先分层切       │                          │                │
│   800 字 + 20% 重叠   │                          │                │
├─────────────────────┼──────────────────────────┼────────────────┤
│ ② BM25+向量混合检索   │ 不识编号/术语（30% 丢分）   │ 69→83（+14）   │
│   RRF 融合两路 Top20  │                          │                │
├─────────────────────┼──────────────────────────┼────────────────┤
│ ③ Rerank 重排序      │ 命中但排名低（25% 丢分）    │ 83→95（+12）   │
│   粗排 20 → 精排 5    │ 附带：相关度阈值自动拒答    │                │
└─────────────────────┴──────────────────────────┴────────────────┘

关键数据

• 基线召回率 60% → 三步后 95%
• 三步涨幅：+9 / +14 / +12，性价比顺序：切片 > 混合检索 > Rerank
• 端到端延迟：800ms → 1.2s（Rerank 占增量主体，可接受）
• 评测集：100 条真实问题 + 标注段落，所有优化的度量衡

一句话

RAG 回答不准，九成要先查检索而不是换大模型——而检索调优的第一课是"建评测集、按丢分归因"。三步法对应三个丢分层：切片用"结构优先的语义切分"保住信息完整性，混合检索用"BM25+向量 RRF 融合"互补两种检索的盲区，Rerank 用"粗排 20 精排 5"把对的段落顶到模型眼前。60% 到 95% 没有任何一步是玄学，每一步都能在评测集上看到确定的数字变化——把玄学变成工程，就是 RAG 调优的全部。

给团队的建议

互动话题：你的 RAG 系统卡在哪个环节？切片、检索还是生成？评论区说说你的丢分现象，一起对号入座。

参考资料

• Dify 官方文档：检索测试与 RAG 优化
• Sentence Transformers：CrossEncoder 使用文档
• BGE 系列模型（embedding + reranker）
• Cormack et al.：Reciprocal Rank Fusion 论文
• Elasticsearch：BM25 相似度
• bm25s：轻量 Python BM25 实现
• Lost in the Middle：长上下文中部信息丢失研究
• LlamaIndex 文档：Chunking 策略