一句话定位RAGRetrieval-Augmented Generation检索增强生成是给LLM外挂一个可随时查阅的知识库——模型在生成回答前先检索相关文档将检索结果注入提示词从而在不重新训练的情况下获取最新、私有、可溯源的知识。一、为什么需要RAGLLM的知识困境1.1 LLM的三大知识缺陷大语言模型在预训练阶段学到的知识存在三个结构性缺陷1. 知识截止Knowledge Cutoff模型的知识停留在训练数据的最后时间点。GPT-4的训练数据截止于2023年4月之后发生的事情它不知道。即使后续模型延长了截止日期时间 gap 永远存在。2. 幻觉Hallucination当模型被问到训练数据中没覆盖的问题时它不会说我不知道而是会生成看似合理但完全虚构的内容。这是因为LLM的本质是预测下一个最可能的词而非检索事实。3. 私有知识缺失企业内部文档、行业数据库、个人笔记——这些从未出现在训练语料中的知识LLM完全无法触及。1.2 三种解决路线的对比方案原理优势劣势重新训练用新数据重新训练模型知识内化到权重成本极高、周期长、每次更新都要重来微调Fine-tuning在基础模型上用领域数据继续训练可塑造风格和格式适合怎么说不适合频繁变化的说什么RAG检索外部知识注入提示词知识实时更新、可溯源、无需重训增加检索延迟、依赖知识库质量核心区别微调改变模型的行为模式怎么说RAG改变模型的知识来源说什么。两者互补——微调让模型学会行业术语和输出格式RAG让模型获取最新事实。正如业界共识RAG管说什么微调管怎么说。二、RAG核心架构检索-增强-生成三段式2.1 基本工作流RAG的标准流程分为三个阶段形成检索→增强→生成的管线用户提问 │ ▼ ┌──────────┐ ┌──────────────┐ ┌──────────┐ ┌──────────┐ │ 查询编码 │───│ 向量检索 │───│ 上下文组装 │───│ LLM生成 │ │ (Embed) │ │ (Retrieve) │ │ (Augment) │ │ (Generate)│ └──────────┘ └──────────────┘ └──────────┘ └──────────┘ │ │ ┌─────┴─────┐ │ │ 向量数据库 │ ▼ │ (Vector DB)│ 用户看到的回答 └───────────┘ (含引用来源)2.2 离线建库阶段在用户提问之前需要先将知识库构建好。这个过程是离线的、一次性的后续增量更新步骤1文档切分Chunking将长文档切分为语义连贯的小块chunk通常按段落或固定长度切分# 按固定长度切分带重叠 def chunk_text(text, chunk_size512, overlap50): chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] chunks.append(chunk) start chunk_size - overlap # 重叠防止语义断裂 return chunks ​ # 更好的方式按段落/标题切分 # 使用 LangChain 的 RecursiveCharacterTextSplitter from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , ] )切分策略对RAG质量影响极大太大检索精度下降一个chunk包含多个话题不相关内容稀释信号太小上下文不完整检索到的片段无法独立理解重叠防止句子在切分处断裂丢失语义步骤2向量化Embedding将每个文本块通过嵌入模型转换为高维向量使语义相近的文本在向量空间中距离更近from sentence_transformers import SentenceTransformer ​ model SentenceTransformer(BAAI/bge-large-zh-v1.5) embeddings model.encode(chunks, normalize_embeddingsTrue) # 输出: [[0.012, -0.034, 0.056, ...], ...] 每个chunk一个768维向量常用嵌入模型对比模型维度中文支持特点OpenAI text-embedding-3-large3072好闭源API效果好但贵BGE-large-zh-v1.51024优秀开源中文场景首选E5-large-v21024好开源多语言Cohere embed-v31024好闭源API压缩性能好步骤3存入向量数据库将向量和原始文本存入向量数据库建立索引以便快速相似性搜索import faiss ​ # FAISS 内存索引适合中小规模 dimension 1024 index faiss.IndexFlatIP(dimension) # 内积相似度向量已归一化 index.add(embeddings) faiss.write_index(index, knowledge.faiss)常用向量数据库数据库特点适用规模FAISS内存计算、无服务端百万级以下Chroma轻量、嵌入式原型/小型Milvus分布式、高可用十亿级QdrantRust实现、过滤强千万级pgvectorPostgreSQL扩展已有PG的系统Pinecone全托管SaaS不想运维2.3 在线检索阶段步骤1查询编码将用户的问题用同一个嵌入模型编码为向量query RAG和微调有什么区别 query_vector model.encode([query], normalize_embeddingsTrue)步骤2相似性搜索在向量数据库中找到与查询最相似的top-k个文本块k 5 scores, indices index.search(query_vector, k) # 返回最相似的5个chunk及其相似度分数步骤3重排序Reranking——可选但强烈推荐向量检索速度快但精度有限重排序模型用更深的交叉注意力对候选结果重新打分from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-large) pairs [(query, chunks[i]) for i in indices[0]] rerank_scores reranker.predict(pairs) # 按重排序分数重新排列双阶段检索先向量召回top-50 → 再重排序top-5是当前RAG的工程标配。2.4 生成阶段将检索到的文本块组装进提示词交给LLM生成最终回答context \n\n.join([chunks[i] for i in reranked_indices[:5]]) ​ prompt f你是一个知识助手。请根据以下参考资料回答用户问题。 如果参考资料中没有相关信息请明确说明根据现有资料无法回答。 ​ ## 参考资料 {context} ​ ## 用户问题 {query} ​ ## 回答请标注引用来源 三、RAG三代演进Naive → Advanced → ModularRAG技术经历了三代演进每一代都在解决前一代的核心缺陷。3.1 第一代Naive RAG朴素RAG架构用户查询 → 向量检索 → 拼接top-k → LLM生成核心缺陷检索缺失如果用户问题表述与文档措辞不一致向量相似度低检索不到无重排序直接用向量相似度排序精度不足无查询优化用户原话直接编码未做任何改写3.2 第二代Advanced RAG高级RAG在Naive RAG前后增加优化模块检索前优化Pre-Retrieval查询重写Query Rewriting让LLM将模糊查询改写为更清晰的检索查询RAG和微调的区别 → RAG检索增强生成与微调fine-tuning在知识更新和模型行为上的差异对比查询分解Query Decomposition将复杂问题拆分为子问题RAG相比微调在成本、时效性、可解释性上的优劣 → 拆为3个子问题分别检索查询扩展Query Expansion用同义词/相关词扩展检索范围大模型安全 → 扩展为 [LLM安全, AI对抗攻击, 提示词注入, 模型越狱]HyDEHypothetical Document Embedding让LLM先假设性回答用假答案去检索模型先对问题生成一个假答案用假答案的向量去检索——因为假答案的措辞更接近文档检索后优化Post-Retrieval重排序Reranking如上所述双阶段检索上下文压缩Context Compression对检索到的长文本做摘要上下文过滤用相关性模型过滤掉低质量chunk去重去除内容重复的chunk3.3 第三代Modular RAG模块化RAG将RAG拆解为可插拔的模块按需编排模块功能可选策略检索从知识库获取信息向量检索 / 关键词检索 / 混合检索 / 图谱检索路由决定是否需要检索直接回答 / 检索后回答 / 多跳检索融合多源结果合并RRF倒数排名融合/ 加权融合排序对候选结果排序交叉编码器 / LLM打分记忆跨轮对话状态对话历史压缩 / 实体记忆生成LLM生成回答标准生成 / 自我反思 / 多步推理校验检查输出质量事实核查 / 置信度评估 / 引用验证四、前沿RAG架构从被动检索到自主决策4.1 Self-RAG自反思RAG核心思想让模型自己决定是否需要检索并在生成后自我评估回答质量。模型在生成过程中输出特殊标记reflection tokens标记含义取值[Retrieve]是否需要检索yes / no / continue[IsRel]检索结果是否相关relevant / irrelevant[IsSup]生成的回答是否被检索内容支持fully / partially / no[IsUse]回答对用户是否有用5 / 4 / 3 / 2 / 1工作流用户提问 → [Retrieveyes] → 检索 → [IsRelrelevant] → 生成句子 ↓ [IsSupfully] → [IsUse5] → 输出 [IsSupno] → 重新检索/重写模型在每句话生成时都会自问这句话有检索证据支持吗如果答案是否则重新检索。4.2 Corrective RAGCRAG纠正式RAG核心思想在检索后增加一个检索评估器根据检索质量动态调整策略。检索结果 → 评估器打分 → [Correct: 高置信] → 直接生成 → [Incorrect: 低置信] → 触发网络搜索补充 → [Ambiguous: 中等] → 两者结合关键创新引入了知识精炼步骤——将检索到的文档做去噪和关键信息提取而非直接拼接原文。4.3 Adaptive RAG自适应RAG核心思想用分类器判断查询复杂度动态选择检索深度。用户提问 → 复杂度分类器 → [简单问题] → 单次向量检索 → 生成 → [中等问题] → 单次检索 重排序 → 生成 → [复杂问题] → 多跳检索 查询分解 → 生成分类器实现可用轻量LLM或传统ML模型基于查询长度、实体数量、推理步骤数等特征判断复杂度。4.4 GraphRAG图谱RAG核心思想将文档构建为知识图谱利用图结构进行多跳推理。构建过程LLM从文档中抽取实体和关系构建知识图谱节点实体边关系使用社区检测算法如Leiden将图分为社区为每个社区生成摘要检索方式局部检索从问题出发找到相关实体的一跳邻居全局检索遍历社区摘要回答宏观性问题混合检索局部全局结合优势传统向量检索无法回答这本书中所有角色之间的关系是什么这类全局性问题GraphRAG可以。4.5 Agentic RAG智能体RAG核心思想将RAG嵌入Agent框架让LLM自主决定何时检索、检索什么、检索几次。用户提问 → Agent思考 → [需要检索?] ├─ 是 → 选择检索工具 → 检索 → 评估结果 → [足够?] │ ├─ 是 → 生成回答 │ └─ 否 → 重写查询再检索 └─ 否 → 直接回答与其他架构的关系Agentic RAG是Self-RAG、CRAG、Adaptive RAG的集大成者——它将检索决策交给Agent的推理循环而非固定管线。五、RAG vs 微调 vs 长上下文如何选这是工程实践中最常被问到的问题。三者的本质区别在于知识存储位置不同。5.1 技术本质对比维度RAG微调长上下文知识位置外部数据库显式模型权重隐式上下文窗口临时更新成本低更新数据库高重新训练零直接放入prompt知识规模无限数据库扩展受模型容量限制受上下文窗口限制延迟中检索耗时低无检索高长输入推理慢可溯源性强可引用来源弱知识内化后不可追溯强上下文可见适合频繁变化的事实知识稳定的行为模式/领域术语单次分析大量文档不适合需要低延迟知识频繁更新文档量巨大成本高5.2 选择决策树知识是否频繁变化 ├─ 是 → RAG动态知识库 └─ 否 → 需要改变模型的输出风格/格式吗 ├─ 是 → 微调塑造行为模式 └─ 否 → 文档总量大吗 ├─ 大数千→ RAG ├─ 小几十份→ 长上下文简单直接 └─ 中等 → RAG 微调结合5.3 何时组合使用实际生产中三者经常组合微调 RAG微调让模型学会行业术语和输出格式RAG提供最新事实长上下文 RAG长上下文处理当前对话的完整历史RAG检索外部知识三者结合微调塑造风格RAG提供知识长上下文处理当前文档六、RAG评估如何衡量质量6.1 RAGAS评估框架RAGASRAG Assessment是当前最流行的RAG评估框架定义了四个核心维度维度含义评估方式Faithfulness忠实度回答是否基于检索内容无幻觉LLM判断每个声明是否被context支持Answer Relevancy回答相关性回答是否切题LLM从答案反向生成问题计算与原问题的相似度Context Precision上下文精确度检索到的内容中有多少是相关的排序质量评估相关chunk是否排在前面Context Recall上下文召回率标准答案中的信息是否都被检索到对比ground truth和检索内容6.2 端到端评估指标层级指标说明检索层Recallktop-k结果中包含正确答案的比例检索层MRR正确答案的平均倒数排名检索层NDCG考虑排序质量的归一化指标生成层Faithfulness幻觉率1 - 幻觉率 忠实度生成层Answer Relevancy回答与问题的语义相关度系统层端到端准确率最终回答的正确率系统层延迟从提问到回答的端到端时间七、工程实践中的关键决策7.1 切分策略选择策略适用场景优势风险固定长度通用文本简单可控可能切断语义按段落结构化文档保持语义完整段落长度不均按标题/章节Markdown/HTML语义最强chunk大小差异大语义切分高精度场景语义最优实现复杂递归切分通用推荐平衡效果与复杂度需调参7.2 混合检索单一向量检索的局限在于它擅长语义匹配但不擅长精确匹配。混合检索同时使用向量检索和关键词检索BM25然后融合结果# 混合检索 vector_results vector_db.search(query, k20) # 语义召回 keyword_results bm25_search(query, k20) # 关键词召回 # RRF融合 def rrf_fusion(rank_lists, k60): scores {} for rank_list in rank_lists: for rank, doc in enumerate(rank_list): scores[doc] scores.get(doc, 0) 1 / (k rank) return sorted(scores, keyscores.get, reverseTrue) final_results rrf_fusion([vector_results, keyword_results])7.3 常见踩坑清单嵌入模型不匹配建库用的嵌入模型和查询用的不一致导致向量空间不对齐chunk过大一个chunk包含多个话题检索精度暴跌无重排序只做向量检索不做rerank精度上限低top-k过大塞入过多不相关内容导致LLM注意力分散无引用溯源生成回答不标注来源用户无法验证知识库不更新向量索引过期检索到的是旧信息无评估闭环不知道RAG效果如何盲目调参只做向量检索忽略了精确匹配场景如产品编号、人名八、RAG与MCP的协同RAG和MCP不是竞争关系而是互补——RAG负责知识注入MCP负责工具连接用户提问 → Agent推理 │ ├─ 需要知识? → RAG检索向量库 → 注入context │ ├─ 需要行动? → MCP调用工具 → 执行操作 │ └─ 都需要? → 先RAG检索知识 → 再MCP调用工具实际案例财务Agent回答本月营收与上月相比差异原因RAG检索内部知识库中的财务分析模板和历史报告MCP调用SAP Server查询本月和上月营收数据LLM结合RAG提供的分析框架和MCP返回的数据生成差异分析报告九、总结速查维度核心洞察本质检索外部知识注入LLM提示词解决知识截止、幻觉、私有知识缺失架构离线建库切分→嵌入→入库 在线检索查询→检索→重排→生成三代演进Naive直连→ Advanced前后优化→ Modular可插拔前沿架构Self-RAG自反思、CRAG纠正式、Adaptive自适应、GraphRAG图谱、Agentic智能体vs 微调RAG管说什么知识微调管怎么说风格vs 长上下文文档量大用RAG文档量小用长上下文评估RAGAS四维度忠实度、回答相关性、上下文精确度、上下文召回工程要点切分策略、混合检索、重排序、引用溯源、评估闭环与MCP协同RAG注入知识MCP调用工具两者互补参考资料Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS 2020) — RAG奠基论文Gao et al. Retrieval-Augmented Generation for Large Language Models: A Survey (arXiv 2024)Self-RAG: Asai et al. Learning to Retrieve, Generate, and Critique through Self-ReflectionCRAG: Yan et al. Corrective Retrieval Augmented GenerationGraphRAG: Edge et al. From Local to Global: A Graph RAG Approach to Query-Focused SummarizationRAGAS: Es et al. RAGAS: Automated Evaluation of Retrieval Augmented GenerationarXiv 2506.00054 RAG: A Comprehensive Survey of Architectures, Enhancements, and Robustness