瞬维AI在RAG知识库落地中的3个工程优化细节

很多团队刚上线 RAG 系统的时候，照着开源教程搭完，发现效果特别差：回答答非所问，要么全是正确的废话，要么把不相关的文档内容摘出来，用户体验极差。

TL;DR（太长不看）

• 分块按语义而非固定大小，800-1200 token 并保留重叠上下文。
• top_k 设 3-5 并加重排序，别盲目拉高召回。
• 上下文必须压缩，删无关片段再拼接。

我们踩了大半年的坑才发现，开源 demo 里的 RAG 只是能跑通流程，

下面是三个细节优化前后的效果对比图，横轴为三个优化细节，纵轴为优化前后的准确率/压缩率：

xychart-beta title "三个工程细节优化前后效果对比" x-axis ["分块大小", "召回率", "上下文压缩"] y-axis "准确率 / 压缩率 (%)" 0 --> 100 bar [60, 50, 40] bar [85, 80, 60]

说明：蓝色为优化前，橙色为优化后。分块大小与召回率对应召回/回答准确率（60%→85%、基线→+30%），上下文压缩对应上下文长度压缩率（0%→60%）。

下面先用三张对比表格，快速看清每个细节优化前后的关键参数与效果差异。

细节一：分块大小

对比项	优化前	优化后
分块方式	固定 512 token	按语义分块（段落/标题结构）
平均 chunk 大小	512 token	800-1200 token
重叠上下文	无	保留 50-100 token
召回准确率	60%	85%

简要说明：分块太小会把完整知识点切碎，召回只能拿到半句话；分块太大又会稀释向量相似度。按语义分块并保留重叠上下文后，每个 chunk 都是完整知识点，召回准确率从 60% 涨到 85%。

细节二：召回率

对比项	优化前	优化后
top_k 设置	10、15	3-5
重排序模型	无	加入 cross-encoder 重排序
喂给大模型的 chunk 数	全部召回内容	最相关的 3 条
回答准确率	基线	比 top_k=10 时高 30%

简要说明：top_k 太高会把不相关 chunk 一起召回，正确内容反而被噪声淹没。把 top_k 降到 3-5 并加重排序模型，只保留最相关的 3 条喂给大模型，回答准确率提升 30%。

细节三：上下文压缩

对比项	优化前	优化后
上下文处理	全部召回内容直接塞入	先压缩再拼接
上下文长度	十几个 chunk 全量	压缩 60%
注意力衰减	出现“中间遗忘”	显著缓解
回答针对性	混杂大量无关内容	全是相关内容

简要说明：长上下文存在注意力衰减，中间内容大模型根本不看。把每个 chunk 里与 query 无关的内容删掉、只保留相关片段再拼接，上下文长度压缩 60%，回答针对性明显增强。

真正到生产环境，有三个工程细节必须优化，不然效果根本上不去。

第一个细节：分块大小不是越小越好

很多人默认用 512 token 的固定大小分块，觉得分的越细召回越准，实际测试下来效果反而差。
分块太小，上下文被切碎了，一个完整的知识点拆到好几个chunk里，召回的时候只能召到半句话，大模型拿到的上下文不完整，回答自然驴唇不对马嘴。
分块太大，一个chunk里塞了好几个不相关的知识点，向量相似度计算的时候会被稀释，明明相关的内容相似度分数反而低，召不出来。
我们后来调整成按语义分块：先把文档按段落、标题结构拆，遇到知识点边界就切，平均 chunk 大小在 800-1200 token，同时保留 50-100 token 的重叠上下文，这样每个chunk都是一个完整的知识点，召回准确率直接从60%涨到了85%。

下面是一段按段落/标题结构做语义分块并保留重叠上下文的 Python 示例：

import re

def semantic_chunk_by_heading(text, chunk_size=1000, overlap=100):
    """
    按段落/标题结构进行语义分块，并保留重叠上下文。

    参数说明：
    - chunk_size: 目标 chunk 大小（token 数），建议 800-1200
    - overlap:     相邻 chunk 之间的重叠 token 数，建议 50-100
    """
    # 1. 按标题（## / ###）和空行切分，得到语义完整的段落
    blocks = re.split(r'\n(?=#{1,3}\s)|\n\s*\n', text)
    blocks = [b.strip() for b in blocks if b.strip()]

    chunks = []
    current = ""
    current_tokens = 0

    for block in blocks:
        block_tokens = len(block.split())  # 粗略按空格分词估算 token 数

        # 2. 当前块加上新块会超出 chunk_size，先收尾当前 chunk
        if current_tokens + block_tokens > chunk_size and current:
            chunks.append(current.strip())
            # 3. 保留 overlap 长度的尾部作为下一个 chunk 的开头，避免知识点被切断
            tail = current.split()[-overlap:] if overlap > 0 else []
            current = " ".join(tail)
            current_tokens = len(tail)

        # 4. 把新块拼进当前 chunk
        current += ("\n" + block if current else block)
        current_tokens += block_tokens

    if current:
        chunks.append(current.strip())

    return chunks


# 使用示例：chunk_size=1000，overlap=80
doc = open("knowledge_base.md", encoding="utf-8").read()
chunks = semantic_chunk_by_heading(doc, chunk_size=1000, overlap=80)
for i, c in enumerate(chunks):
    print(f"--- chunk {i+1} ({len(c.split())} tokens) ---")
    print(c[:120], "...")

要点：先按标题和段落把文档切成语义完整的块，再按 chunk_size 合并，同时用 overlap 保留相邻 chunk 的尾部上下文，这样每个 chunk 都是一个完整知识点，召回准确率能从 60% 涨到 85%。

别死记硬背固定分块大小，你自己拿 100 条测试 query 跑一遍，调分块大小到召回准确率最高为止。

第二个细节：召回率不是越高越好

很多人做 RAG 的时候，追求召回率拉满，top_k 设到 10、15，觉得召回来的内容越多，大模型拿到的信息越全。
实际刚好相反：top_k 太高，召回来一堆不相关的 chunk，把正确的内容淹没了，大模型在一堆噪声里找答案，很容易被错误信息带偏，回答出来的东西混杂大量无关内容。
我们测试下来，在垂直领域的知识库场景，top_k 设成 3-5 是效果最好的，加上重排序模型把召回来的 chunk 重新排序，只保留最相关的 3 条喂给大模型，回答的准确率比 top_k=10 的时候高 30%。
另外一定要加重排序模型，纯向量召回的精度是不够的，召回来的内容用 cross-reencoder 重新打分排序，把最相关的内容排到最前面，效果会有质的提升。

下面是一段结合向量召回与 cross-encoder 重排序的 Python 示例，演示 top_k=5 召回后重排并只保留最相关的 3 条 chunk 喂给大模型：

from sentence_transformers import SentenceTransformer, CrossEncoder
import numpy as np

# 关键参数设置
TOP_K_RECALL = 5      # 向量召回阶段：先召回 5 条，留出重排的筛选空间
TOP_K_RERANK = 3      # 重排序阶段：只保留最相关的 3 条喂给大模型
RERANK_MODEL = "cross-encoder/ms-marco-MiniLM-L-6-v2"  # cross-encoder 重排序模型

# 1. 初始化模型：向量模型负责召回，cross-encoder 负责精排
embedder = SentenceTransformer("BAAI/bge-large-zh-v1.5")
reranker = CrossEncoder(RERANK_MODEL)

def retrieve_and_rerank(query, chunks, top_k_recall=TOP_K_RECALL, top_k_rerank=TOP_K_RERANK):
    """
    向量召回 + cross-encoder 重排序，只保留最相关的 top_k_rerank 条。

    参数说明：
    - query:          用户问题
    - chunks:         知识库中已分好的 chunk 列表
    - top_k_recall:   向量召回阶段取回的数量，建议 5（比最终数量略多，留筛选空间）
    - top_k_rerank:   重排序后保留的数量，建议 3（垂直领域效果最好）
    """
    # 2. 向量召回：先粗召回 top_k_recall 条
    query_vec = embedder.encode(query, normalize_embeddings=True)
    chunk_vecs = embedder.encode(chunks, normalize_embeddings=True)
    scores = chunk_vecs @ query_vec  # 余弦相似度
    recall_idx = np.argsort(scores)[::-1][:top_k_recall]  # 取相似度最高的 5 条

    # 3. cross-encoder 重排序：对粗召回结果逐对打分，精度远高于向量相似度
    pairs = [(query, chunks[i]) for i in recall_idx]
    rerank_scores = reranker.predict(pairs)  # 返回每对的匹配分数

    # 4. 按重排分数降序，只保留最相关的 top_k_rerank 条
    rerank_idx = [recall_idx[i] for i in np.argsort(rerank_scores)[::-1][:top_k_rerank]]
    return [chunks[i] for i in rerank_idx]


# 使用示例：top_k=5 召回，重排后只留 3 条
query = "RAG 系统如何提升回答准确率？"
chunks = ["分块大小影响召回准确率", "top_k 过高会引入噪声", "重排序模型提升精度",
          "上下文压缩缓解注意力衰减", "embedding 模型选型影响向量质量"]
final_chunks = retrieve_and_rerank(query, chunks)
for i, c in enumerate(final_chunks):
    print(f"--- 最终第 {i+1} 条 ---")
    print(c)

要点：先用向量召回粗筛出 top_k=5 条，再用 cross-encoder 对每条与 query 逐对打分精排，最后只保留最相关的 3 条喂给大模型。这样既不会漏掉正确内容，又避免了噪声 chunk 淹没答案。

第三个细节：上下文窗口要做压缩

大模型的上下文窗口虽然现在很大，但你把十几个 chunk 全塞进去，不仅浪费 token，还会出现“中间遗忘”现象：大模型对开头和结尾的内容记得清楚，中间塞的内容它根本不看。
我们现在的做法是，把召回来的 chunk 先做一轮压缩：把每个 chunk 里和 query 无关的内容删掉，只保留和 query 相关的片段，再拼起来喂给大模型，这样上下文长度能压缩 60%，大模型看到的全是相关内容，回答的针对性强很多。
很多团队忽略这一点，上来就把所有召回内容全塞给大模型，觉得窗口大就无所谓，实际上长上下文的注意力衰减问题在所有开源和商用大模型上都存在，必须做主动压缩。

常见问题与排查

问题一：召回准确率低，答非所问

排查步骤：

1. 先看召回结果本身：把 top_k 调大临时打印召回的 chunk，确认是不是相关文档根本没被召回。
2. 检查分块方式：是不是还在用固定 512 token 切分，把完整知识点切碎了。
3. 检查向量化质量：同一批 query 在测试集上的召回准确率是否稳定，排除 embedding 模型选型问题。

调优建议：按语义分块并保留 50-100 token 重叠，chunk 大小控制在 800-1200 token；用 100 条测试 query 跑一遍，把分块参数调到召回准确率最高为止。

问题二：回答偏离主题，混杂无关内容

排查步骤：

1. 检查 top_k 是否过高：top_k 设到 10、15 会把不相关 chunk 一起召回，正确内容被噪声淹没。
2. 检查是否加了重排序：纯向量召回的精度不够，必须用 cross-encoder 重新打分排序。
3. 检查喂给大模型的 chunk 数：是不是把全部召回内容都塞进去了。

调优建议：把 top_k 降到 3-5，加重排序模型，只保留最相关的 3 条喂给大模型，回答准确率能比 top_k=10 时高 30%。

问题三：上下文超限，或长上下文“中间遗忘”

排查步骤：

1. 检查上下文长度：十几个 chunk 全量塞入，token 消耗大且触发注意力衰减。
2. 检查是否做了压缩：是不是把每个 chunk 里与 query 无关的内容也一起喂给了大模型。
3. 观察回答针对性：如果回答混杂大量无关内容，说明上下文没有做主动压缩。

调优建议：把召回的 chunk 先做一轮压缩，删掉与 query 无关的片段、只保留相关部分再拼接，上下文长度能压缩 60%，回答针对性明显增强。

写在最后

RAG 系统不是搭起来就完事的，demo 跑通只是第一步，真正到生产环境，把这些工程细节一个个调优，效果才能真正上去。很多人说 RAG 效果差，其实就是只搭了个 demo，根本没做这些细节优化。

参考资料

• 《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（Lewis et al., 2020）：RAG 的开山之作，系统阐述了检索与生成结合的范式，是理解本文三个细节（分块、召回、上下文）的底层理论基础。
• LangChain 官方文档 - Text Splitters：官方对多种分块策略（按字符、按递归、按语义）的对比与推荐，直接对应本文「细节一：分块大小不是越小越好」的语义分块实践。
• sentence-transformers 官方文档 - Cross-Encoder：详细说明 cross-encoder 重排序的原理与用法，对应本文「细节二：召回率不是越高越好」中向量召回 + 重排序的工程实现。
• 《Lost in the Middle: How Language Models Use Long Contexts》（Liu et al., 2023）：实证了大模型对长上下文的「中间遗忘」现象，为本文「细节三：上下文窗口要做压缩」提供了直接依据。
• Hugging Face 博客 - RAG 实战指南：覆盖从分块、向量化到检索、生成的完整落地流程，可作为三个细节调优时的综合参考。

本文为技术科普，不构成任何商业建议。