企业官网建设流程全解析

RAG 技术演进：从朴素向量检索到自适应智能系统

RAG（检索增强生成）走到今天，已经不是一个新鲜词，但它的内涵在过去两年发生了深刻变化。最初大家理解的 RAG 是"向量检索 + 生成"的固定管道，如今它演进为一套包含自适应检索、图结构推理、多模态理解在内的复杂认知系统。这篇文章梳理 RAG 的技术演进脉络，重点拆解几个正在成为主流的新范式，以及它们各自解决什么问题、适合什么场景。

一、朴素 RAG 的四个天花板

理解新范式，先要知道旧范式卡在哪里。基础的"切片 → 向量化 → 检索 → 生成"管道，在生产中会撞上四堵墙。

召回不准。向量相似度无法完全捕捉语义相关性，尤其在专业垂直领域——术语多、表达隐晦，通用嵌入模型经常召不回真正相关的片段。

上下文割裂。文档被机械切分后，片段之间的逻辑关联（因果、总分、对比）被切断。模型拿到的是碎片，回答自然缺少全局视角。

静态知识。基础管道面对实时变化的数据（股价、库存、政策更新）无能为力，索引更新滞后于现实变化。

长文档理解弱。面对上百页的 PDF 或报告，朴素 RAG 只能捡碎片，无法进行全局推理——"这份报告的核心结论与去年的差异是什么"这类问题，碎片检索回答不了。

四堵墙的本质是同一个问题：RAG 把"理解文档"这件事简化成了"匹配片段"。新范式都在试图补回丢失的语义结构。

二、自适应检索：让流程学会判断

朴素 RAG 对每个问题都执行同一套流程：检索、生成。但真实问题是高度分层的——有的是闲聊（不需要检索），有的是简单事实查询（一次检索就够），有的是复杂多跳推理（需要多轮检索与推理）。

自适应检索的核心，是让系统先"判断"再"行动"：根据问题的复杂度与类型，动态决定是否检索、检索几次、从哪个数据源检索。实践中有三个可落地的判断维度：

是否需要检索：意图分类器先分流，闲聊与寒暄直接走对话路径，避免无谓的检索开销。

检索策略选择：简单事实走快速检索，模糊问题先做查询改写，复杂问题启用多轮检索与推理链路。

数据源路由：不同问题路由到不同知识库——制度类走法规库，技术类走技术文档库，产品类走产品手册库。数据源隔离减少了跨库噪声，也提升了各库的检索精度。

自适应检索的收益是双重的：效果上，不同复杂度的问题各得其所，准确率显著提升；成本上，减少不必要的 API 调用与检索开销。它的实现成本不高——本质是给流程加了一个"决策节点"——但收益立竿见影，是性价比最高的演进方向。

三、GraphRAG：用图结构补回实体关系

朴素 RAG 的"上下文割裂"问题，根因在于把知识库当成了"一堆独立片段"，丢失了实体之间的关系。GraphRAG 的解法是：把知识库显式建模为知识图谱——实体是节点，关系是边，属性是节点信息——检索时沿着图结构进行多跳推理。

GraphRAG 解决了朴素 RAG 答不了的一类问题：需要链式推理的问题。比如"某公司 CEO 的母校是哪所"，朴素 RAG 需要同时命中两个不相关的片段（公司-CEO 关系、CEO-教育背景）才能组装答案，召回难度极大；而图结构里这条路径是显式存在的，沿着关系边两步就走通了。

工程上的实现路径通常是：先抽取实体与关系（用大模型对文档做信息抽取，或基于领域词库构建），再存入图数据库，检索时混合使用向量召回（找起点实体）与图遍历（沿关系扩展）。微软开源的 GraphRAG 框架提供了可参考的实现。

GraphRAG 的代价也不小：图构建成本高（信息抽取的准确性直接影响图质量）、维护复杂、冷启动慢。适合的场景是：实体关系密集的知识域（企业架构、法规条款、科研文献、供应链），且存在大量多跳推理需求。如果知识是松散的文档集合、问题以单点事实查询为主，GraphRAG 就是过度设计。

四、全局感知与分层检索：带着地图找细节

另一个有趣的演进方向是"先全局后局部"。MiA-RAG 这类方案的做法是：检索前，先为整个长文档生成高层摘要（全局视图），带着"全文讲什么"的认知去寻找细节证据。

这个思路模仿了人类的阅读方式——读一本书，先翻目录和摘要建立全局认知，再去定位具体段落。对长文档场景（百页报告、整本书、多章节规范），全局摘要让检索不至于"只见树木不见森林"。

工程实现上，可以在索引阶段为每个文档生成"文档级摘要"与"章节级摘要"，检索时分层匹配：先匹配到正确的文档，再定位文档内的正确章节。这种分层检索把"大海捞针"变成"先锁定海域，再下网"，显著提升长文档场景的检索精度与效率。

五、Agentic RAG：从管道到循环

如果说前面几个方向优化的是"检索怎么做"，Agentic RAG 改变的则是"系统怎么组织"。它的核心是让 RAG 流程具备自主决策能力，从单向管道变成"感知-决策-行动-反思"的循环。

典型的 Agentic RAG 行为模式包括：先判断问题是否值得检索（不值得就直接回答）；检索结果不足时自动改写查询重试；多跳问题分步检索、逐步收敛；不同来源信息冲突时请求用户澄清或追加检索；必要时调用外部工具补充实时数据。

Agentic RAG 的本质，是把"检索策略"从写死的流程变成模型可决策的对象。收益是明显的：对复杂问题的处理能力大幅提升，对检索失败的容错能力增强。代价是：系统复杂度上升、运行成本增加、行为可预测性下降。适合问题类型多样、复杂度差异大的生产场景；如果问题类型单一、流程固定，朴素 RAG 加一个查询改写就够了。

六、多模态 RAG：突破纯文本边界

最后一个值得关注的演进是多模态 RAG。企业知识库远不止文本：产品图片、表格截图、流程图、PDF 中的图表，都承载着关键信息。多模态 RAG 通过视觉编码器把图片、表格转成向量索引，检索时跨模态召回，把图文资料统一纳入"外脑"。

落地上有一个务实的实现路径：对含图表的文档，先做版面解析，把图片区域切出来，生成图片描述或结构化的表格表示，与文本一起向量化。查询时按需召回文本片段与图片块，模型同时基于图文生成答案。这个方案在报告解读、设备手册、教学材料等场景的价值已经得到验证。

七、选型指南：不同阶段该上什么

面对这么多范式，工程团队最容易犯的错是"一步到位"——直接上最复杂的方案。务实的路径是渐进式演进：

第一阶段：朴素 RAG 跑通业务闭环，建立评测集与基线数据。

第二阶段：做基础优化——查询改写、混合检索、更好的切分策略、上下文结构化。这一阶段投入小、收益大，多数场景到此就能满足业务需求。

第三阶段：问题明确指向多跳推理时上 GraphRAG；长文档理解不足时上全局摘要与分层检索；问题类型复杂多变时演进到 Agentic RAG。

每一步的推进都要有评测数据的支撑。新范式不是"先进就更好"，而是"匹配问题才更好"——这是 RAG 演进过程中最值得坚守的工程理性。

七、落地节奏与团队组织

新范式的落地，技术只是半边天，节奏与组织是另一半。几个被反复验证的经验：

小步验证，渐进替换。不要试图一次性把朴素 RAG 重构成 GraphRAG + Agentic 的豪华系统。正确节奏是：先在一个高价值问题上验证新范式的收益（用评测数据说话），确认增益显著后，再扩大覆盖范围。每一步替换都以"效果不低于旧方案 + 成本可接受"为门槛。

评测集是最大资产。新范式落地时最缺的往往不是技术，而是"能证明效果"的评测集。从业务真实问题里持续收集用例、标注标准答案、按难度分级，是团队最值得投入的资产。评测集越扎实，范式选型的判断越准确，返工越少。

工程与算法双线并行。GraphRAG 的图构建质量、Agentic RAG 的决策策略，本质是算法问题；而数据管道、评测体系、监控设施是工程问题。两条线都要有专人负责，任何一条的短板都会拖垮整体进度。

警惕"演示成功"。新范式在演示集上效果好是常态——演示集往往刻意选择了新范式擅长的题目。落地判断必须以盲测评测集（团队之外的业务方提供问题）为准，否则很容易被"选择偏差"误导，上线后才发现增益消失。

八、评测新范式：别被"效果更好"误导

新范式的宣传总是"准确率提升 40%"这类数字，落地前必须建立一套能验证真伪的评测纪律。

基线必须可复现。任何新范式的对比，都要求在同一评测集、同一数据切分、同一模型配置下，与朴素 RAG 基线公平对比。换评测集、换数据、换模型配置的"对比"，结论毫无意义。评测集要固定版本、存档快照，防止"评测集漂移"污染结论。

关注"净增益"而非"峰值"。新范式通常有特定擅长的问题类型。要统计的是"整体评测集上的平均增益"，而不是"擅长类型上的峰值增益"。如果增益集中在少数题目、多数题目持平甚至下降，就要谨慎评估是否值得引入。

成本必须计入对比。GraphRAG 的图构建成本、Agentic RAG 的多次模型调用成本，都要折算进对比。效果提升 10%、成本翻倍，未必划算；效果持平、成本减半，反而可能是好方案。推荐以"单位成本的准确率"作为对比指标。

失败模式分析。新范式会引入新的失败模式——GraphRAG 可能因实体抽取错误产生错误关系，Agentic RAG 可能因决策失误走错检索路径。落地前要专门分析新失败模式及其影响，评估是否可控、可否兜底。

小范围试点再推广。在真实业务的小范围场景试点，用线上数据验证效果（而非只在离线评测集上）。试点的结论比任何离线评测都可靠——离线评测覆盖不了真实用户的提问分布与噪音。

这套纪律的意义在于：RAG 新范式的选型本质是"技术投资决策"，评测是决策的依据。评测做扎实，选型就不会被演示效果和宣传话术带偏。

九、写在最后

RAG 的演进史，本质上是一部"如何让模型更可靠地使用外部知识"的工程史。从朴素向量检索到自适应检索、图结构推理、全局感知、自主循环、多模态理解，每一次演进都在补回被简化掉的结构与语义。技术路线会继续演进，但决策逻辑不变：先定义问题，再匹配方案，用数据验证效果。把这条纪律守住，无论 RAG 的下一个范式是什么，你都能做出正确的工程选择。