前言

如果说 2023年的 RAG 是"把文档塞进向量库然后检索"，那么 2026年的 RAG 已经是一套复杂的工程体系。本文梳理 RAG 技术从 Naive 到 Agentic 的完整演进路径，并给出企业落地的关键决策点。—## 一、为什么 RAG 还没有被"长上下文"取代？经常有人问：上下文窗口都到 200 万 Token 了，为什么还需要 RAG？答案是：检索效率 ≠ 塞满上下文。| 维度 | 长上下文直接塞 | RAG 检索 ||------|--------------|---------|| 响应延迟 | 高（Token越多越慢） | 低（只传相关片段） || 推理成本 | 极高 | 可控 || 知识更新 | 需重新推理 | 只更新知识库 || 精确度 | 随文档数量下降 | 高（精准召回） || 适用知识库规模 | <100万字 | 亿级文档 |RAG 的核心价值在于：在海量文档中精准找到最相关的片段，而不是让模型自己在茫茫 Token 海中大海捞针。—## 二、RAG 技术演进的五个阶段### 阶段一：Naive RAG（2023年主流）最简单的实现：1. 文档切片 → 向量化 → 存入向量数据库2. 用户问题 → 向量检索 → Top-K 片段3. 片段 + 问题 → LLM → 回答问题：切片粒度难以兼顾，相关性检索不精准，没有多轮对话记忆。—### 阶段二：Advanced RAG（2024年）引入检索前/后优化：- Pre-retrieval：查询重写（Query Rewriting）、假设文档生成（HyDE）- Retrieval：混合检索（BM25 + 向量）、语义分块（Semantic Chunking）- Post-retrieval：重排序（Reranker）、上下文压缩（Contextual Compression）这个阶段的 RAG 在企业问答场景中召回率提升了 30-50%。—### 阶段三：Modular RAG（2024-2025年）模块化设计，每个步骤可插拔替换：[查询理解] → [检索策略路由] → [多源检索] → [结果聚合] → [生成]支持多种检索后端：向量数据库、知识图谱、关系数据库、搜索引擎。—### 阶段四：自适应 RAG（2025年）模型自主判断"是否需要检索"：- 简单问题（如"什么是 RAG"）：直接回答，不检索- 需要实时数据的问题：触发检索- 需要多步推理的问题：迭代检索这一步极大降低了不必要的检索开销。—### 阶段五：Agentic RAG（2026年当前主流）RAG 成为 Agent 的记忆模块：- 主动检索：Agent 自主决定何时、检索什么- 迭代精炼：检索 → 评估 → 再检索，直到回答满意- 多源异构：同时检索内部文档、实时搜索、结构化数据库- 图检索增强：构建知识图谱，支持多跳推理—## 三、2026年 RAG 的五大新范式### 1. Self-RAG（自我反思检索）模型在生成过程中动态判断：- 是否需要检索？（[Retrieve] token）- 检索结果是否相关？（[IsRel] token）- 生成内容是否有根据？（[IsSup] token）效果：比普通 RAG 幻觉率降低 40%。### 2. GraphRAG（图检索增强）将文档解析为知识图谱（实体-关系网络），支持：- 多跳推理（“A 的老板的老板是谁？”）- 社区摘要（自动生成知识域的高层摘要）适用场景：法律文档、医疗知识库、代码库分析。### 3. 混合检索 2.0不只是 BM25 + 向量，现在还加上：- 结构化数据检索：直接查关系数据库- 时序检索：按时间维度过滤最新信息- 跨模态检索：文本查图片/视频### 4. RAG-as-Memory将 RAG 作为 Agent 的长期记忆：- 每次对话结束后，将关键信息写入知识库- 下次对话时检索历史记忆- 实现真正的"记得你是谁"### 5. RAG + MCP 集成MCP（Model Context Protocol）让 RAG 可以像调工具一样被 Agent 调用：python# Agent 通过 MCP 调用 RAG 知识库result = await mcp_client.call_tool( "knowledge_search", {"query": "用户的问题", "top_k": 5})—## 四、企业落地：四个关键决策点### 决策一：用什么向量数据库？| 规模 | 推荐 | 理由 ||------|------|------|| < 100万文档 | Chroma / Qdrant | 轻量易部署 || 100万-1亿 | Milvus / Weaviate | 高并发，支持分布式 || > 1亿 | Elasticsearch + 向量插件 | 成熟运维体系 |### 决策二：切多大的块？经验法则：- 问答场景：256-512 tokens/块，重叠 50 tokens- 摘要场景：1024-2048 tokens/块- 代码场景：按函数/类切分，不按字符切### 决策三：要不要 Reranker？要，但需要权衡延迟：- 小型应用：直接用模型 API（如 Cohere Rerank）- 大型应用：部署本地 BGE-Reranker 或 bce-reranker延迟增加约 100-200ms，但精准度提升 15-25%。### 决策四：如何评估 RAG 质量？核心指标三件套：- 上下文相关性（Context Relevance）：检索到的片段和问题有多相关？- 答案忠实度（Faithfulness）：生成的答案是否基于检索内容？- 答案相关性（Answer Relevance）：回答是否切中问题？推荐评估框架：RAGAS、TruLens、DeepEval。—## 五、2026年 RAG 工程的三个坑坑一：过度检索Top-K 设太大（如 K=20），模型在 20 个片段里迷失方向，反而答不好。推荐从 K=3 开始，逐步调优。坑二：忽略元数据过滤向量相似度高不代表答案正确。添加时间戳、来源权重等元数据过滤，可以大幅提升精准度。坑三：文档解析质量PDF/Word 解析出来的文本往往有乱码、表格错位。建议使用 marker、Docling 等专业文档解析工具，而不是直接用 pdfplumber。—## 总结RAG 不是一个"装好就能用"的技术，而是一套需要持续调优的工程体系。2026年的 RAG 已经进化为 Agentic RAG，成为 AI 系统的标配组件。选对技术路线，做好数据质量，才是企业 RAG 落地成功的关键。