05 · RAG 检索增强生成

问题

LLM 有两个限制：

给模型一份参考文档，让它「基于这份资料回答」，质量远高于让它凭记忆回答。这就是 RAG 的起点。

RAG（Retrieval-Augmented Generation）将信息检索嵌入 LLM 的生成流程：

用户提问 → 检索相关文档 → 将文档作为上下文注入 prompt → LLM 基于文档生成回答

对比纯 LLM：

原始文档 → 文本切分（Chunking）→ 生成 Embedding → 存入向量库

Chunking（文本切分）

将长文档切为适合检索的片段。过大的 chunk 稀释语义，过小丢失上下文。

常见策略：

策略	做法	适用场景
固定大小	每 512 token 切一段，重叠 50 token	通用文本
按段落	以 `\n\n` 为界切分	结构化文档
语义切分	按 Embedding 相似度变化点切分	主题分散的长文档
层级切分	父子 chunk：小 chunk 检索，大 chunk 喂给 LLM	需要上下文的高精度场景

Embedding

将文本转为固定维度的向量。语义相似的文本向量距离近。

"苹果很好吃"     → [0.12, -0.34, 0.56, ...]  (1024维)
"水果营养丰富"   → [0.11, -0.31, 0.58, ...]  ← 距离近
"今天天气不错"   → [0.89, 0.42, -0.15, ...]  ← 距离远

常用 Embedding 模型：

向量数据库

存储 Embedding 并支持相似度检索（ANN，近似最近邻）：

用户提问 → 生成 Query Embedding → 向量检索 Top-K → 拼入 prompt → LLM 生成回答

检索策略

典型 prompt 模板

基于以下参考文档回答问题。如果文档中没有相关信息，直接说"不知道"。

参考文档：
---
{doc1}
---
{doc2}
---

问题：{query}

长上下文模型（200K+ tokens）出现后，有人提出「直接把所有文档全塞进去就行，不需要 RAG」。实际情况更复杂：

实践中两者互补：用 RAG 检索相关文档，利用长上下文窗口容纳更多检索结果以提升召回率。

chunk 大小怎么选？

没有通用最优值。取决于文档结构和问题类型：

检索不到怎么办？

多个文档怎么排序？