RAG 不是把文档扔进去——检索增强生成工程实战

据统计，超过 60% 的 RAG 生产系统在上线后遇到过检索质量退化的问题——要么搜不到相关文档，要么搜到的东西模型不会用。

很多人以为 RAG 就是"把文档扔进向量库，让 LLM 去搜"。实际上，RAG 是一条从文档到答案的完整流水线，每个环节的决策都会影响最终质量。本文不讲概念，只讲工程——你在搭建 RAG 系统时真正会遇到的问题和对应的解法。

一、RAG 的常见误区

先澄清三个最常见的认知偏差：

• "Embedding 能理解语义，所以不用太在意文本质量" — 错。Embedding 对噪声极其敏感，一段包含无关信息的文本会拉偏整个向量表示。
• "搜到排名最高的文档就够了" — 错。Top-1 的命中率在多数场景下只有 40-60%。你需要多路召回 + 重排序。
• "LLM 足够聪明，能自己从上下文中找到答案" — 错。模型在长上下文中的注意力分布并不均匀，关信息被埋没在无关内容中时，模型一样会忽略它。

二、Chunking——第一道也是最容易被低估的坎

Chunking 策略直接决定了检索的精度和召回率。没有一种策略适合所有场景，你需要根据文档类型和查询模式来选择。

常见分块策略

• 固定大小分块：最简单。按固定 Token 数切分，通常 256-1024 个 Token，带 10-20% 重叠窗口。适合格式统一的日志、代码、结构化文本。
• 语义分块：按自然边界（段落、章节、句子）切分。质量更高，但粒度不均匀。适合文章、文档、报告。
• 递归分块：从大到小逐级切分——先按章节，再按段落，最后按句子。每一块保留父级上下文信息。适合长文档（技术手册、法规文件）。
• 基于标题结构的分块：利用 Markdown/HTML 的标题层级确定分块边界。每个顶级标题下所有内容作为一块，块内保留子标题作为上下文锚点。

// 伪代码：递归分块策略示意
function chunk(doc, maxTokens = 512, overlap = 64):
    if len(doc) <= maxTokens:
        return [doc]
    // 优先按语义边界切分
    splits = split_at_boundary(doc)
    chunks = []
    for split in splits:
        if len(split) > maxTokens:
            // 递归切分大块
            chunks.extend(chunk(split, maxTokens, overlap))
        else:
            chunks.append(split)
    // 添加重叠窗口
    return add_overlap(chunks, overlap)

实战建议

• 优先按自然语义边界分块，不要用固定大小一刀切
• 重叠窗口 10-20%，防止切分时丢失边界上下文
• 每个 Chunk 保留元数据（来源文档、章节标题、页码），在检索后可以溯源
• 查询短的场景（10-20 Token）用小 Chunk（256-512），查询长的场景用大 Chunk

三、Embedding 选型

Embedding 模型的选择不是"越强越好"，而是"越匹配越好"。

选型维度

• 语言匹配：中文场景优先选双语模型（bge-m3、multilingual-e5），纯英文模型对中文的编码质量差很多。
• 维度取舍：高维度（1024+）表示更精细但存储和检索更慢；低维度（384-512）速度更快但精度可能下降。量化（int8）通常可以在几乎无精度损失的情况下降低 75% 存储。
• 领域适应性：通用场景用 bge-m3 或 text-embedding-3-small；垂直领域（医疗/法律/代码）建议用领域微调版本。
• 混合检索：纯向量检索在精确关键词匹配上不如 BM25。生产系统中建议向量 + 关键词混合，再用重排序融合。

常用 Embedding 模型对比（2026 年中）：
┌──────────────────────┬────────┬──────────┬───────────┐
│ 模型                  │ 维度    │ 语言      │ 适用场景   │
├──────────────────────┼────────┼──────────┼───────────┤
│ bge-m3               │ 1024   │ 多语言    │ 通用       │
│ multilingual-e5-large │ 1024   │ 多语言    │ 通用/高精度 │
│ text-embedding-3-small│ 512-1536│ 多语言    │ OpenAI 生态 │
│ jina-embeddings-v3   │ 1024   │ 多语言    │ 长文本     │
│ gte-Qwen2             │ 1024-4096│ 中文为主  │ 中文优化   │
└──────────────────────┴────────┴──────────┴───────────┘

四、检索优化

检索是整个 RAG 管线的瓶颈。优化检索能在不换模型的前提下显著提升质量。

多阶段检索

不要指望一次向量搜索拿到答案。生产级 RAG 应该走多阶段管道：

用户查询
    ↓
Stage 1: 粗排（高效召回 Top-K）
    ├─ 向量检索（语义相似度）
    └─ BM25 检索（关键词匹配）
    ↓
Stage 2: 融合（去除重复，按分融合）
    ├─ Reciprocal Rank Fusion (RRF)
    └─ 加权合并
    ↓
Stage 3: 精排（高精度重排序）
    └─ Cross-encoder Re-ranker
    ↓
Stage 4: 截断（保留 Top-N 送入 LLM）
    └─ 按质量阈值 + 数量上限
    ↓
LLM 生成

重排序（Re-ranking）

这是被低估最多的一步。向量检索的 Embedding 是双向的（查询和文档各自编码），而 Cross-encoder 是双向的（查询和文档一起编码），精度远高于向量检索，但速度慢（每次只能比较一对）。

正确做法：先用向量检索粗排 Top-100，再用 Cross-encoder 精排 Top-10。这样兼顾精度和速度。

查询重写

用户的原始查询往往不是最优的检索语句。一个简单的优化：让 LLM 先对用户的查询做一次重写，然后再去检索。

原始查询："那个报错怎么解决"
  → 重写后："Python ModuleNotFoundError 报错的常见原因和解决方案"
  → 检索质量显著提升

五、生成优化

搜到了还不够，模型得会用。这是 LLM 层要解决的问题。

Prompt 设计

上下文注入不是把检索结果原样扔进去就行了。设计原则：

• 明确指令：告诉模型"你的回答只能基于以下文档"，并让它在不确定时说"不知道"
• 引用标注：要求模型在回答中标注信息来源（文档 ID、段落号），方便溯源验证
• 格式约束：如果答案是结构化的（JSON/表格），用输出约束确保格式正确
• 上下文压缩：超出模型上下文窗口时，对检索结果做摘要压缩

RAG Prompt 模板示例：
---
你是一个基于知识库的问答助手。

请严格遵循以下规则：
1. 你的回答只能基于以下提供的文档内容
2. 如果文档中没有相关信息，请回答"我没有找到相关信息"
3. 引用来源：在回答末尾用 [来源: 文档X/第Y段] 标注

文档内容：
--- BEGIN CONTEXT ---
|{检索结果}|--- END CONTEXT ---
|
|用户问题：{用户输入}|---

幻觉控制

即使有 RAG，LLM 仍然会幻觉。工程层面的防护措施：

• 引用验证：检查 LLM 输出的每个声明是否在检索到的文档中有直接支持
• 事实性检查：用第二个 LLM（或同模型的不同输出）交叉验证第一个 LLM 的回答
• 阈值过滤：当检索结果的得分低于某个阈值时，不送入 LLM，直接返回"信息不足"

六、评估——没有度量就没有改进

RAG 系统需要从两个维度评估，缺一不可：

检索质量

• 命中率（Hit Rate）：Top-K 中是否包含正确答案。K 越大命中率越高，但送入 LLM 的内容也越多。
• 平均倒数排名（MRR）：正确答案在检索结果中的平均排名位置。1.0 表示永远排第一。
• NDCG：考虑排序位置的加权指标，适合有多级相关性标注的场景。

生成质量

• 忠实度（Faithfulness）：生成的回答是否忠实于检索到的文档。这是最重要的指标。
• 答案相关性：回答是否直接回应了用户的问题，而不是答非所问。
• 信息完整性：回答是否覆盖了问题的所有方面。

// 忠实度评估的自动化方法
function checkFaithfulness(answer, context):
    // 从回答中提取所有声明性句子
    claims = extractClaims(answer)
    for claim in claims:
        // 检查每个声明是否在上下文中被支持
        if not isSupportedBy(claim, context):
            return false  // 发现幻觉
    return true

七、小结

RAG 不是"把文档扔进去"，而是一条完整工程流水线：

Chunking     → 分块策略决定精度上限
Embedding    → 模型选型匹配场景
检索         → 多阶段（粗排→融合→精排）
生成         → Prompt 设计 + 引用 + 幻觉控制
评估         → 检索 + 生成双维度闭环

核心原则：
1. 检索质量决定系统上限，LLM 只是执行者
2. 没有一种方案适合所有场景——测试、度量、迭代
3. 质量评估必须基于真实数据，而不是完美问题

RAG 不是什么新技术，但能在生产环境中持续稳定运行的系统少之又少。如果你正在搭建 RAG 系统，先从 Chunking 和检索质量入手——这两步做对了，后续的问题会少一大半。