RAG 检索增强生成实现指南

RAG 检索增强生成实现指南：从检索到评估完整流程

大模型的知识停留在训练数据截止日期之前，也无法访问你的私有文档。检索增强生成（Retrieval-Augmented Generation，RAG）正是为解决这个问题而生：先根据用户问题检索出最相关的资料片段，再把"问题 + 资料"一起交给模型生成回答。这样模型既能引用最新或私有的知识，又能显著减少"一本正经地编造"（幻觉）的概率。

LangChain 和 LlamaIndex 官方文档把 RAG 归纳为加载（Loading）、索引（Indexing）、存储（Storing）、查询（Querying）与评估（Evaluation）五个阶段。下面我们按实际开发顺序，把它拆成八个可执行环节，从数据准备一路讲到效果评估。

一、加载与清洗：把数据变成文档对象

RAG 的第一步是把散落在 PDF、网页、数据库、API 里的内容读进统一的文档对象。LangChain 的 Document 和 LlamaIndex 的 Node 都包含正文与元数据（来源、日期、作者等），元数据在后面做过滤和引用时非常有用。

多格式接入：PDF、Markdown、HTML、CSV 需要用对应的加载器，复杂表格建议用文档解析服务。
保留来源：每个片段务必记录原始来源 URL 或文档 ID，这是回答可溯源的基础。
增量更新：文档会持续变化，建议按批次导入并记录版本，而不是每次全量重建索引。

二、切分：选择合适的 Chunk 粒度

切分是 RAG 中最容易被忽视、却对效果影响巨大的环节。LangChain 官方推荐 RecursiveCharacterTextSplitter，它按换行、句号等常见分隔符递归切分，直到每个块达到目标大小。

块大小与重叠：常见配置是 1000 字符 + 200 字符重叠（chunk_size=1000, chunk_overlap=200），重叠能让跨块语义不丢。
按语义边界切：对代码、表格等结构化内容，优先按标题、段落等自然边界切分。
过小丢上下文，过大则噪声多：块太小检索到的是碎片，块太大则相关性被稀释，还会多耗 token。需要在精确度和成本之间取平衡。

三、嵌入：把文本映射为向量

嵌入（Embedding）把每个片段转成捕捉语义的数值向量，语义相近的内容在向量空间中彼此靠近。你可以选用 OpenAI、Cohere、Mistral、Hugging Face 或本地 Ollama 的嵌入模型，接口是一致的。

维度选择：模型输出维度从几百到几千不等，维度越高通常越精细，但存储和计算成本也越高。
中文场景：中文检索建议选用对中文优化过的嵌入模型，或在同语种语料上评估后再决定。
规范化：很多实现会做向量归一化（normalize embeddings），配合余弦距离使用效果更稳定。

四、存储：写入向量数据库

切分并嵌入后的片段需要存入向量数据库，才能在海量数据中快速做相似度检索。可选方案很多：内存版适合原型，Chroma、Qdrant 适合中小规模，Milvus、Pinecone 适合大规模生产。选型主要看数据量、并发、是否要元数据过滤、是否要混合检索（语义 + 关键词）。详细对比可以参考向量数据库选型与实战。

如果文档总量不大、并发不高，先用一款成熟产品跑通流程即可，避免过早引入复杂分布式架构。

五、检索：从相似度到混合检索

查询阶段，把用户问题也嵌入成向量，然后在向量库中找出最相似的 Top-K 片段。为了提升召回质量，可以叠加以下策略：

混合检索：向量相似度对同义改写鲁棒，但对精确术语、产品名、编号不敏感；BM25 等关键词检索正好互补。把两者结果融合，常能显著提升效果。
元数据过滤：按来源、时间、语言、权限等字段缩小候选范围，既提升准确率也降低延迟。
路由与子查询：面对多来源知识库，可用路由器决定查哪个索引，复杂问题拆成多个子查询分别检索。

六、重排序：让正确片段排到前面

Top-K 召回里往往"相关的不少、最相关的被埋没"。重排序（Rerank）阶段用一个更强的模型对候选片段重新打分排序，是当前 RAG 调优中性价比最高的一步。常用交叉编码器（cross-encoder）类模型，例如 BGE-Reranker 系列。线上部署时，重排通常只作用于检索出的几十条候选，成本可控。

七、生成：提示词与引用约束

把检索到的片段与用户问题拼进提示词交给大模型，这一步要约束模型"只基于给定资料回答"，并强制输出引用来源，例如 [1] 对应第一条资料。相关提示工程技巧可参考 AI 提示工程入门。

引用必须可验证：让回答里的每个结论都能对应到具体片段来源。
不知道就直说：资料里没有答案时，要求模型明确"无法回答"，而不是硬编。
注意间接提示注入：LangChain 官方特别提醒，检索到的文档本身可能含有"伪指令"，会与系统提示竞争。应把检索内容当作纯数据对待，并在上线前对输出做校验。

八、评估：RAG 效果的三层度量

RAG 系统上线后必须持续评估。官方实践通常分两层：检索质量和生成质量。

检索质量：用"命中率 / 召回率 / 相关性得分"衡量 Top-K 是否捞到了正确答案，问题往往出在切分、嵌入或检索策略上。
生成质量：用"忠实度（回答是否忠实于资料）、答案相关性、正确性、完整性"衡量最终回答。忠实度低说明模型在自由发挥，需要加强提示约束或重排。
评估方式：小规模可用人工打分；规模化后用 LLM-as-judge 或专用评估框架，把评估集做成数据集、每次改版后跑一遍回归。完整方法论见 AI 模型评估与基准方法。

从 RAG 到 Agent

RAG 不只是"文档问答"的专属技术。把检索封装成工具，让 AI Agent 在规划任务时自主调用检索、分析并汇总，就构成了更复杂的 RAG Agent 形态：Agent 决定查什么、查几轮、要不要追问，最后把多来源结果综合成带引用的回答。

16IDC 观察

对建站和 SaaS 团队而言，RAG 最常见的落地场景是企业知识库客服、产品文档问答、内部资料检索。如果你的应用基于 AI 相关能力提供服务，建议把 RAG 当作"给模型喂私有知识"的默认方案：它比微调更省成本、更新知识只需重建索引，也比纯提示词更可控。先小数据量跑通八环节流程，再用评估数据驱动优化，比一开始就追求复杂架构更稳妥。

原文来源：https://docs.langchain.com/oss/python/langchain/rag 与 https://developers.llamaindex.ai/python/framework/understanding/rag/

RAG 检索增强生成实现指南：从检索到评估完整流程