构建可靠的 RAG 系统

Source: Dev.to

检索增强生成（RAG）常被讨论为建模问题。实际上，大多数 RAG 失效与语言模型关系不大。它们失效的原因是：

• 检索到了错误的信息
• 正确的信息被错误地切分
• 检索到了相关上下文，但排序不佳

本指南将阐述 实际决定 RAG 质量的三层结构：

1. Chunking（分块） – 信息如何被切分
2. Retrieval（检索） – 如何找到候选项
3. Reranking（重新排序） – 如何挑选最佳上下文

每一层都建立在前一层之上。顺序不当地优化会导致系统脆弱。

RAG 流程（概念概览）

Documents
   ↓
Chunking
   ↓
Indexes (Vector + Lexical)
   ↓
Retrieval
   ↓
Rank Fusion
   ↓
Reranking
   ↓
LLM

大多数系统过度优化底层，却对上层工程不足。

第 1 部分 — 分块：使信息可检索

分块的真实含义

分块是将文档划分为可检索单元（“块”）的过程，这些单元可以被索引和搜索。

分块不是：

• 满足上下文窗口的方式
• 预处理的细节
• 嵌入向量以后会解决的事

分块决定了哪些信息能够被检索。如果信息被错误地拆分，它实际上就不存在。

分块的核心规则

一个块应该能够很好地回答一个连贯的问题。

如果一个块不能让人类读者单独理解，它在检索时也不太可能有效。令牌数量是约束条件——而不是目标。

为什么朴素的分块会失败

常见错误：

• 按固定令牌数拆分
• 在句子或规则中间拆分
• 为了“防止遗漏”而过度重叠
• 将结构扁平化为纯文本

这些错误会导致：

• 部分答案
• 缺失限定词
• 被模型归咎的幻觉

按结构而非文本进行分块

在分块之前，将文档视为结构化块：

• 标题
• 章节
• 段落
• 列表
• 表格
• 代码块

分块应将块组装成决策单元，而不是直接切割原始文本。

概念流程

原始文档
   ↓
结构化块
   ↓
块组装

一个合理的默认分块策略

这在大多数实际系统中都适用：

• 保持文档顺序和层级。
• 合并相邻块，直至完整表达一个思想。
• 目标约为 200–600 个令牌（可灵活调整）。
• 避免将规则与其例外拆开。

在块前添加最小上下文（例如文档标题、章节路径）。

生成的块具有：

• 有意义
• 可检索
• 易于调试

块扩展（关键思路）

你并不局限于单一块大小。一个强大的模式是检索时扩展：

1. 检索小而精准的块。
2. 向相邻块或父级章节扩展。
3. 在生成前合并。

检索到的块
   ↑      ↓
邻近块 / 父级上下文

这可以在不膨胀索引的情况下提升上下文信息。

Part 2 — Retrieval: Finding the Right Candidates

Chunking defines what can be retrieved. Retrieval defines which chunks are considered. Retrieval is about recall, not final correctness.

Retrieval methods (what they actually do)

Lexical retrieval (BM25 / FTS)

• Matches exact terms.
• Excellent for identifiers, names, keywords.
• Weak at paraphrases.

“Does this text contain these words?”

Vector retrieval (embeddings)

• Matches semantic similarity.
• Excellent for paraphrases, vague queries.
• Weak at rare tokens, numbers, precise constraints.

“Does this text mean something similar?”

Why neither is sufficient alone

• Lexical search misses meaning.
• Vector search over‑generalizes meaning.

Using either alone creates systematic blind spots.

Hybrid retrieval (the default)

Most reliable systems use both:

Query
 ├─ Lexical retrieval (BM25)
 ├─ Vector retrieval (embeddings)
 └─ Candidate union

This maximizes recall.

Rank fusion: merging retrieval signals

Lexical and vector scores are not directly comparable. Instead of score blending, use rank‑based fusion.

Reciprocal Rank Fusion (RRF)

Intuition: documents that appear near the top in multiple lists are more reliable.

Simplified formula:

score(doc) = Σ 1 / (k + rank)

• Simple
• Robust
• Parameter‑light

RRF is an excellent default.

Retrieval goal (important)

Retrieval is not about picking the best chunk. It is about not missing the right chunk. Precision comes later.

第三部分 — 重排序：选择最佳上下文

检索之后，你通常会得到 20–100 个候选块——对大型语言模型来说太多，而且很多只与主题弱相关。重排序引入了 理解。

重排序器的不同之处

与检索不同，重排序器会同时看到 查询和块，并对它们进行交叉注意力建模。这使它们能够理解：

• 约束
• 否定
• 具体性
• 意图

重排序器会回答：“这个块真的回答了查询吗？”

为什么重排序很重要

如果没有重排序：

• 语义上“接近”但错误的块会升至顶部
• 产生自信的幻觉
• 不相关的内容会被传递给 LLM

重排序将候选集合过滤到少数真正相关的块，从而使 LLM 能生成准确、基于事实的响应。

典型的重新排序流程

Top‑K retrieved chunks
   ↓
Cross‑encoder reranker
   ↓
Top‑N high‑precision chunks

* N 通常很小（5–10）。 *

成本与质量的权衡

Rerankers 是：

• 比检索更慢
• 每次查询成本更高

这就是它们在检索 之后 使用，而不是替代检索的原因。
这种分层方法使系统具有可扩展性。

综合起来

端到端 RAG 流程

Documents
   ↓
Chunking (decision units)
   ↓
Indexing
   ├─ Lexical index
   └─ Vector index
   ↓
Retrieval
   ├─ BM25
   ├─ Vector search
   └─ Rank fusion (RRF)
   ↓
Reranking
   ↓
Chunk expansion (optional)
   ↓
LLM

每一层只有单一职责。

如何评估系统（常被跳过）

不要先调优模型。先评估检索。

关键问题

• 正确的块是否出现在 top‑K 中？
• 是否检索到了正确的章节？
• 重新排序是否把正确的块提升上来？
• 人类仅凭检索到的上下文能否回答问题？

需要跟踪的指标

• recall@K
• section hit rate
• answer faithfulness
• citation correctness

如果检索错误，生成就不可能正确。

常见反模式

• 仅向量检索
• 到处使用句子级别的切分
• 过度重叠
• 默认仅使用 LLM 切分
• 将幻觉归咎于模型

这些通常掩盖了上游问题。

乏味却可靠的真相

• 分块决定了能找到什么
• 检索决定了被视为何
• 重新排序决定了可信的内容

模型位于这三者的下游。

优秀的 RAG 系统是自上而下构建的，而非自下而上。

最终要点

如果你只能记住一件事：

RAG 质量在很久之前就是检索问题，而不是生成问题。

正确处理分块、检索和重新排序——模型就会显得聪明得多。