RAG：检索增强生成入门
📅 主题：Retrieval-Augmented Generation — 检索、重排序与上下文生成
一、什么是 RAG
RAG（Retrieval-Augmented Generation，检索增强生成） 指的是：在让大语言模型（LLM）生成回答之前，先从外部知识库（文档、数据库、API 等）中检索与用户问题相关的片段，把这些片段作为上下文一起交给模型，再让模型基于「问题 + 检索到的内容」生成答案。
简单公式：
用户问题 + 检索到的文档片段 → 组成上下文 → 送入 LLM → 生成回答这样做的目的：
- 弥补知识截止：模型训练数据有截止日期，检索可以注入最新或领域知识。
- 减少幻觉：让模型「有据可依」，尽量基于给定文档作答，而不是凭空编造。
- 接入私有数据：企业文档、知识库、工单等不参与训练，通过检索在推理时注入。
RAG 不修改模型参数，只改变输入，因此实现快、易迭代，是当前落地最广的「增强 LLM」方式之一。
二、RAG 的整体流程
一个典型的 RAG 流程可以拆成四步：
| 步骤 | 做什么 | 输出 |
|---|---|---|
| 1. 索引（离线） | 把知识库文档切块、向量化，写入向量库/检索引擎 | 可被检索的索引 |
| 2. 检索 | 用用户问题（或问题向量）在索引里查 Top-K 相关片段 | 若干候选片段 |
| 3. 重排序（可选） | 用更精细的模型对候选片段打分、排序、截断 | 最终用于注入的片段 |
| 4. 生成 | 把「问题 + 检索片段」拼成 Prompt，调用 LLM 生成 | 最终回答 |
前三步决定「给模型看什么」，第四步是「模型根据这些内容生成什么」。上下文工程关注的是第 4 步里如何排布这些内容；RAG 更关注第 1～3 步的检索质量。
三、索引：把知识库变成可检索的
3.1 分块（Chunking）
长文档需要切成小块再建索引，否则检索粒度太粗，且单块过长会占满上下文。
- 按长度切：固定 token 数或字符数，可加重叠（overlap）避免语义被截断。
- 按结构切：按段落、小节、标题切，保留完整语义单元。
- 按语义切：用模型或规则判断「语义边界」再切。
块太小：检索到的信息碎片化；块太大：噪声多、占用上下文多。常见折中是 256～1024 token 或等价字符，并视文档类型微调。
3.2 向量化与向量库
- 用 Embedding 模型（如 向量嵌入 中介绍的模型）把每块文本转成向量。
- 向量存入 向量数据库（Milvus、Qdrant、pgvector、Elasticsearch 的 dense vector 等），支持按向量相似度做 K 近邻检索。
这样，用户问题也向量化后，就可以在向量库里查「和问题最像」的若干块，即向量检索。
3.3 其他索引方式
- 关键词/BM25：传统全文检索，不依赖向量，适合精确词、专有名词。
- 混合检索：向量检索 + 关键词检索，结果合并或重排，兼顾语义和字面匹配。
索引阶段一旦做好，检索阶段就只是「查询 → 取 Top-K」；质量上限很大程度由分块策略和 Embedding 质量决定。
四、检索：从索引里取出相关片段
4.1 查询表示
- 通常直接用用户问题做查询；若问题很长，可先做摘要或抽取关键句再查。
- 查询文本用与建索引相同的 Embedding 模型向量化，再在向量库里做相似度检索（余弦、内积等）。
4.2 Top-K 与阈值
- Top-K：取相似度最高的 K 个块（如 K=5～10）。K 太大会引入噪声、占满上下文；太小可能漏掉关键信息。
- 阈值：可设定相似度下限，低于则丢弃该块，避免无关片段进入上下文。
K 和阈值都需要根据业务效果调优。
4.3 混合检索与过滤
- 若使用 向量 + 关键词：可分别取 Top-K，再按分数融合（如 RRF）或交给重排序模型统一打分。
- 过滤：按元数据（来源、时间、类型）过滤后再检索，缩小范围、提升相关性。
五、重排序：让「最该进上下文的」排前面
向量检索的 Top-K 是按向量相似度排的，不一定和「对生成最有帮助」完全一致。重排序（Rerank） 用另一个（通常更强的）模型对「查询 + 候选片段」打分，再按分数重排、截断。
- 作用：把真正相关、信息密度高的片段排到前面，减少无关片段进入上下文。
- 实现：使用专门的 Reranker 模型（如 Cross-Encoder、BGE Reranker 等），对 (query, chunk) 对打分，再取 Top-N（N ≤ K）注入上下文。
- 代价：多一次模型推理，延迟和成本会增加，因此常对向量检索的 Top-K（如 20～30）做 Rerank，只保留 Top-5 左右注入。
重排序是可选的，但在对准确率要求高的场景里，往往能明显提升「依据文档作答」的比例。
六、上下文注入与生成
检索（+ 重排序）得到的片段，要放进 LLM 的上下文里，通常和用户问题放在同一轮：
- 顺序：常见做法是「检索到的文档片段 + 用户问题」，或「用户问题 + 文档片段」，并在 Prompt 中明确说明「请仅根据以下内容回答」。
- 格式：用清晰的分隔符、标题标出「参考文档」，便于模型区分文档与问题。
- 长度：所有片段总长度不能超过上下文窗口；若片段过多，按重排序分数或相关性截断，或做摘要后再注入。
这一步和 上下文工程 紧密相关：同样的检索结果，不同的排布和说明方式，会影响模型是否「紧扣文档」、是否幻觉。
生成阶段可结合：
- 引用：要求模型在回答中标注依据的文档片段（如 [1]、[2]），便于溯源和评估。
- 无则说无：若检索结果为空或明显不相关，在系统提示中说明「若文档中无相关信息，请明确回答不知道」，减少瞎编。
七、RAG 与向量嵌入、上下文工程的关系
- 向量嵌入：RAG 的索引和检索依赖把文本变成向量，Embedding 模型的选择和优化直接影响检索质量。详见 向量嵌入 (Vector Embedding)。
- 上下文工程：检索结果如何放入 Prompt、放多少、放哪一段，属于上下文设计；与 上下文工程 中的「检索/注入内容」一致。
三者配合：好的 Embedding + 合理的检索与重排序 + 清晰的上下文排布，才能发挥 RAG 的效果。
八、实践要点与常见问题
8.1 检索不到相关内容
- 检查分块是否过粗/过细，Embedding 是否与领域匹配。
- 尝试混合检索或放宽 K/阈值，再通过 Rerank 收窄。
- 查询侧：对问题做改写、扩展或拆子问题再分别检索。
8.2 模型不按文档回答（幻觉）
- 在系统提示中强调「仅根据给定文档回答」「若文档中无则说不知道」。
- 减少注入的噪声：提高 Rerank 的 Top-N 门槛、减少 K。
- 必要时在应用层做引用校验：要求模型标注依据，并对未标注的陈述做二次检查。
8.3 延迟与成本
- 向量检索通常较快；Rerank 和 LLM 是主要耗时。可对热点问题做缓存、对简单问题跳过 Rerank。
- 索引可增量更新：只对新文档或变更文档重新分块、向量化并写入，避免全量重建。
8.4 评估
- 检索质量：看 Top-K 的召回率、MRR 等，是否有遗漏关键文档。
- 生成质量：答案是否基于文档、是否有虚构、引用是否准确，可用人工抽样或基于模型的 faithfulness 指标辅助评估。
九、小结
- RAG = 检索（从知识库取相关片段）+ 增强（把片段当上下文）+ 生成（LLM 基于上下文作答），用于弥补知识截止、降低幻觉、接入私有数据。
- 流程：索引（分块、向量化）→ 检索（Top-K）→ 可选重排序 → 上下文注入 → 生成。
- 检索：向量检索为主，可配合关键词与过滤；重排序可显著提升「该进上下文的」片段质量。
- 上下文：检索结果要清晰排布在 Prompt 中，并与上下文工程配合，约束模型「依据文档回答」。
- 迭代：从分块、Embedding、K、Rerank 到 Prompt 设计，都可逐步调优，并结合检索与生成两端的评估持续改进。