RAG 技术演进：自适应检索、GraphRAG 与多模态检索的落地路径

RAG 技术演进：自适应检索、GraphRAG 与多模态检索的落地路径

早期的 RAG 是"向量检索 + 生成"的朴素组合：文档切块、向量化、相似度召回、拼提示词。这套模式解决了从无到有的问题，但很快暴露出召回不准、上下文割裂、长文档理解弱、静态知识等瓶颈。过去两年，RAG 从单一范式演进为包含自适应检索、图检索、多模态检索、智能体化编排的复杂技术体系。这篇文章梳理 RAG 的演进脉络，重点拆解几类新范式的原理、适用场景与落地取舍。

一、朴素 RAG 的四个瓶颈

在讨论新范式之前，先精确描述朴素 RAG 到底哪里不够用。这不是否定它——朴素 RAG 至今仍是大多数场景的合理起点——而是明确它的能力边界，才知道什么时候该升级。

召回不准。向量相似度无法完全捕捉语义相关性。专业领域里，表面相似但不相关的文本（同查询难负样本）经常排在真正答案前面。更麻烦的是，传统评估方法（如问题-文档相似度）在难负样本场景下几乎失效——用错误尺子量出来的"准确率高"掩盖了真实问题。

上下文割裂。文档被机械切块后，跨段落的逻辑关联丢失了。"A 公司收购了 B 公司"在前一段，"收购后 B 的 CEO 出任新公司总裁"在下一段，朴素 RAG 很难把两段串起来完成多跳推理。

长文档理解弱。面对上百页的 PDF，逐块检索像"盲人摸象"——每块都是局部信息，缺少全局视图，模型难以做出需要通读全文才能判断的回答。

知识静态。朴素 RAG 的知识库是固定快照，实时变化的数据（股票价格、库存状态、航班信息）无法处理。

二、自适应检索：把"检索决策"交给系统

朴素 RAG 每次查询都执行固定的"检索 + 生成"。自适应检索（Adaptive RAG）的核心变化是：根据问题的类型和复杂度，动态决定是否需要检索、检索几次、从哪个数据源检索。

典型规则包括：

• 简单事实问题（“公司注册年份”）：可能一次检索就够；
• • 复杂推理问题（“上季度各区域营收对比”）：需要多轮检索，甚至多源检索；
• • 闲聊或常识问题（“你好”“今天天气如何”）：可以不检索，直接回答；
• • 无检索价值的问题（“你觉得这篇报告写得怎样”）：走纯生成。
    实现方式有两条路线：规则路由——用分类模型或关键词规则判断问题类型，映射到不同的处理流程；模型路由——让 LLM 自己决策，把"是否检索"作为工具调用的一部分。前者稳定可控、成本低，后者灵活但决策本身有失败概率。

自适应检索的收益在两方面都很明显：效果上，检索次数与问题复杂度匹配，避免了简单问题被无关检索噪声干扰；成本上，减少无谓的 API 调用。实测中准确率提升可达 40%，同时 token 消耗明显下降。

落地建议：先做规则路由（用分类器把问题分成"无需检索 / 单次检索 / 多轮检索"三类），跑通后再逐步引入模型决策，降低初期的不可控因素。

三、GraphRAG：把知识库变成图

GraphRAG（图检索增强生成）是这两年最受关注的方向之一。核心思路是把知识库从"向量列表"升级为"知识图谱"：实体（公司、人物、产品）和关系（收购、任职、属于）被显式建模，检索在图上进行，支持多跳推理。

3.1 为什么图能解决割裂问题

向量的相似度检索本质上是一阶匹配：问题与文档片段的表面语义相关。多跳问题（“A 公司的创始人在哪所大学读过书”）需要跨多个实体和关系推导，一阶匹配无法完成。图结构天然支持沿着关系边进行多跳遍历——找到 A 公司节点 → 沿"创始人"边到人物节点 → 沿"教育背景"边到大学节点，整条路径就是答案的证据链。

3.2 构建与检索流程

GraphRAG 的落地链路比朴素 RAG 重：

实体抽取：用 LLM 从文档中抽取实体与关系，这一步是成本和质量的双重瓶颈。抽取质量直接决定图的质量，而 LLM 抽取存在漏抽、错抽、实体指代不统一的问题。

图存储：图数据库（Neo4j 等）或图索引存储三元组。

检索策略：问题先解析出实体，再从图中扩展：实体邻居遍历（广度优先）、关键路径查询、社区检测（找与问题相关的知识子图）。社区检测特别适合回答"这份文档讲了哪些主题、各主题关系如何"这类全局问题。

生成：把检索到的子图序列化为文本（三元组列表或自然语言描述）注入提示词。

3.3 落地取舍

GraphRAG 的优势是精准的多跳推理与全局性问题回答，代价是构建成本高、维护复杂、检索延迟高于向量检索。落地判断标准：

• 知识库是否强关联结构（如组织架构、供应链关系、知识体系）？——是则值得建图；
• • 是否频繁出现多跳推理问题？——是则图的收益能覆盖成本；
• • 数据更新频率如何？——高频更新场景图的维护成本会失控。
    行业实践中有一种渐进路线：保持向量检索为主干，对少量高价值文档子集构建图索引，形成"向量为主、图为辅"的混合架构，兼顾成本与能力。

四、全局感知与长文档理解：从"盲人摸象"到"先看全景"

长文档 RAG 的痛点在于：逐块检索缺乏全局上下文。两个主流解法：

摘要先行。检索前先为整篇长文档生成高层摘要（全局视图），检索时把摘要与相关片段一起注入，让模型"带着对全文的理解去找细节证据"。实测对百页级文档的问答质量提升显著。

分层索引。构建文档的分层结构：全文摘要 → 章节摘要 → 段落内容，检索时先在摘要层定位相关章节，再下钻到细节层。这模仿了人类阅读策略——先翻目录，再读相关章节，而不是一页页找。

这两种方案都把"全局信息"引入检索决策，成本是额外的一次（或多次）摘要生成，但在长文档场景下收益远超成本。

五、多模态 RAG：从纯文本到图文并茂

企业文档中大量知识以图片、表格、图表承载：产品示意图、数据报表、流程图、公式。纯文本 RAG 对这些内容无能为力。多模态 RAG 的演进方向有三条：

文本化提取：对图片做 OCR + 内容描述，把表格转为结构化文本，纳入现有文本检索管线。成本最低，但损失了视觉细节。

多模态嵌入：用多模态 embedding 模型（如 CLIP 类）把图片与文本统一映射到向量空间，图文混合检索。支持"找一张描述类似场景的图"这类跨模态查询。

视觉语言模型生成：检索到图片后，由 VLM 结合问题理解图像内容再回答。适合产品说明书、工程图纸等强视觉依赖场景。

实际项目中三种方案常叠加使用：OCR 文本进文本库，图片本身进多模态库，回答时按需调用 VLM 做视觉理解。多模态 RAG 的落地门槛主要在成本与延迟，随着多模态模型价格下降，这个方向会越来越主流。

六、RAG 与 Agent 的融合：检索变成一种能力

最新一轮演进是 RAG 从"固定管线"变成"Agent 的一项能力"。区别在于：

RAG Chain：固定流程，每次查询都执行"检索 → 生成"。结构简单，但不会根据问题调整检索策略。

RAG Agent：检索是 Agent 可调用的工具，由模型决定要不要查、查几次、查哪个库、要不要改写问题再查。支持多轮对话中持续追问细节、对比多个来源、发现矛盾时追加检索。

融合形态的价值在复杂任务中体现：比如"对比两款产品的售后政策差异"，RAG Agent 会分步检索两款产品的政策文档、抽取关键条款、对比差异、标注依据，而不是一次检索完事。

对团队而言，融合形态意味着 RAG 系统的边界从"检索 + 生成"扩展为"检索工具化 + 规划循环 + 记忆 + 评测"，复杂度显著上升。建议从 Chain 形态起步，把管线跑稳、评估指标建好，再逐步引入 Agent 化编排。

七、评测：新范式绕不开的关口

任何 RAG 升级都必须回答同一个问题：效果到底提升了多少？没有评测，升级就是赌博。RAG 评测体系至少要覆盖三个层面：

检索质量：召回率、命中率、难负样本上的区分度。这里特别提醒，传统相似度类评估指标在难负样本下会失真，需要用"回答是否真的用上了检索内容"这类因果性指标补充验证。

生成质量：回答准确率、引用正确率、拒绝率。要有专业标注员对回答做事实性判断，而不是只看字面流畅度。

端到端指标：任务成功率、用户满意度、平均延迟、单位成本。业务价值最终看这些指标。

评测集要持续扩充——每发现一类线上失败样本，就补进评测集，防止同类问题回归。这是 RAG 系统长期演进的基础设施，值得投入。

八、技术选型建议

面对如此多的新范式，团队该如何选？给出几条务实建议：