绝大多数团队第一次将大模型接入业务系统时都会萌生同一个想法能不能让AI直接解答公司内部文档相关的问题像是员工手册里的休假规章制度、产品文档的功能介绍、客服知识库的标准应答话术、会议纪要里的各项决策还有业务系统内登记的客户、供应商、订单相关数据全都包含在内。这个需求听起来十分合理。企业内部资料都已经整理好了为什么不能直接让大模型读取之后直接给到对应的答案呢这里其实有个核心问题通用大模型本身无法主动获取企业的内部私有资料。它储备了海量公开的通用知识但并不了解你们公司最新发布的规章制度、产品独有的功能细节、部门专属的特殊条例也同步不了前一天刚更新完成的会议纪要。更棘手的一点是当大模型面对自己不会的问题时还容易产出看似通顺完整但毫无事实依据的内容也就是我们常说的幻觉问题。而RAG技术的出现就是为了解决以上所有痛点。RAG全称是 Retrieval-Augmented Generation业内普遍译作「检索增强生成」。它的工作逻辑其实很好理解先从知识库中筛选出和问题相关的资料再交由大模型依托这些真实资料生成回答。可用的知识来源范围很广文档、操作手册、常见问题FAQ、工单记录、数据库以及企业各类内部业务系统都可以。简单来说RAG摒弃了大模型单纯依靠自身训练参数里的固有知识作答的模式提前为模型补充对应的参考上下文。直白点讲就是让大模型告别“凭固有印象答题”变成“拿着现成资料精准答题”。不过发展到现阶段RAG早已不只有“向量检索大模型”这一种单一落地形态。目前行业内主流的架构一共有三种Classic RAG、Graph RAG 和 Agentic RAG。大家没必要一上来就死记硬背各类专业概念掌握三个核心动词就能轻松分清三者的区别Classic RAGretrieves核心是检索Graph RAGconnects核心是连接Agentic RAGreasons核心是推理通俗总结Classic RAG帮你精准找资料Graph RAG帮你梳理信息关联关系Agentic RAG帮你自主判断后续需要查询哪些内容。大家可以结合配图建立整体认知三种架构的原始数据源都是同一批内部知识资料三者的真正区别主要体现在接收用户问题之后的处理逻辑上。三种RAG架构核心差异拆解Classic RAG精准匹配筛选相似内容Classic RAG是问世最早、逻辑最简单也是企业落地普及率最高的一类RAG架构。它的工作逻辑可以用一句话概括将用户的提问转化为向量格式在知识库内检索匹配度最高的文本片段最后把问题和对应片段一并交给大模型由大模型整合输出答案。这套模式的关键点在于语义相似性。传统的关键词搜索只会做字面内容匹配。举个例子用户搜索“育儿假”系统只会筛选出正文里包含这三个字的段落。但向量搜索不一样它会把所有文本内容转化为一组专属数字也就是embedding向量用数字来表征文本的语义。依托这项能力即便用户换种问法比如询问“孩子出生后能休多长时间假期”系统也能精准匹配到育儿假相关政策内容因为两句话的底层语义是一致的。Classic RAG的完整运行流程分为七个步骤对原始文档进行拆分处理切割成若干个独立的文本块也就是chunk给每一个文本块生成专属的embedding向量将所有向量数据统一存入向量数据库用户发起提问后同步将用户问题转化为embedding向量在向量数据库中检索出相似度排名前K的文本片段把用户问题和检索到的所有片段同步输入给大模型大模型结合参考资料输出最终的回答内容。这里纠正一个很多人都会踩的认知误区并不是只有用户的问题会做向量化处理。文档入库阶段就已经提前完成所有文本块的embedding转换问题仅在用户查询的瞬间完成实时向量化。所以Classic RAG的整体成本主要分为两部分一是前期知识库整理入库的成本二是用户实时查询时的调用成本。给大家举个直白的业务案例员工提问“育儿假申请的截止日期是什么时候”Classic RAG会自动在人事政策文件、员工手册、公司管理制度等资料库中筛选出相关度最高的段落再交由大模型整理成通俗易懂的回答给到员工。这类直白、答案固定的问题完全适配Classic RAG。因为答案本身就完整藏在某一段文档内容里无需复杂的逻辑推理只要检索的资料足够精准回答效果基本不会出错。下面这些高频业务场景优先选择Classic RAG就足够常见问题FAQ问答企业各类政策查询产品使用手册答疑客服知识库智能应答员工内部制度咨询内部文档智能检索助手它的优势十分突出架构简单、响应速度快、落地成本低、配套工具链成熟而且输出结果可控、可预判。对大部分企业知识库项目来说只要把Classic RAG打磨到位就能解决八成以上的高频基础问题。但它的短板也同样明显核心逻辑仅局限于检索相似文本。如果答案集中在单一文本片段内它的表现无可挑剔可一旦答案分散在多份文档、多个业务实体且需要依托关联关系才能得出结论时Classic RAG就很难胜任。举两个简单的例子问题一“员工A的上两级直属领导是谁”想要解答这个问题需要先查询A所属的团队再找到A的直属经理最后查询该经理的上级。完整答案不会集中在某一个段落里而是藏在层层嵌套的组织关系链中。Classic RAG即便能检索到员工名录、组织架构调整通知也没办法稳定沿着组织关系逐层追溯得出完整答案。问题二供应链场景“本次某款芯片短缺会影响公司哪些产品”对应的相关数据分散在产品档案、零部件清单、供应商资料、库存系统等多个平台。单纯依靠语义相似度检索大概率只能拿到零散的相关片段无法整合出完整有效的答案。这就是Classic RAG的能力边界擅长查找孤立的相关资料不擅长梳理、串联信息之间的关联关系。当答案不在单段文档内而是隐藏在多份文档、多个数据的关联关系之中时就需要用到Graph RAG。Graph RAG突破文本局限梳理信息关联大家要明确一点Graph RAG并不是为了取代Classic RAG而诞生的它是在文本检索的基础上新增了一层结构化的关系网络以此弥补基础架构的短板。Classic RAG只会思考哪些文本内容和用户问题相似而Graph RAG会同步思考两个问题哪些文本内容和用户问题相似资料内的人员、产品、零部件、部门、供应商之间存在怎样的关联关系这层专门用来承载各类关联关系的结构就是我们常说的知识图谱。知识图谱的逻辑很好理解所有知识都被拆分为两大基础单元实体与关系。常见的实体类型包含人员企业员工、管理人员等产品、零部件团队、部门供应商、客户业务系统功能模块常见的关系类型包含员工A直属汇报给经理B产品X搭载零部件Y零部件Y由供应商Z供货团队M全权负责系统N的运营客户C采购了产品P搭载知识图谱之后系统眼中的资料不再是一堆零散的文本片段而是一张可以自由遍历、追溯的完整关系网络。Graph RAG的运行流程是双线并行的模式1. 沿用Classic RAG的逻辑文档切块、生成embedding向量存入向量数据库用于基础文本检索2. 新增图谱构建逻辑从原始文本中自动抽取实体与对应的关联关系搭建专属业务知识图谱。用户发起提问后系统既能完成常规的文本相似度检索也能依托知识图谱沿着各类实体关系逐层查找答案。我们依旧用之前的供应链问题举例用户提问“哪些产品会受到半导体短缺的影响”解答该问题需要串联多条分散信息1. 产品X搭载电路板Y2. 电路板Y生产需要用到芯片Z3. 芯片Z由供应商S独家供应4. 供应商S目前遭遇半导体短缺问题。如果只用Classic RAG系统大概率只能检索到半导体短缺、供应商S相关的零散文档没办法自主串联起“供应商—芯片—电路板—产品”这条完整的影响链路。而这正是Graph RAG的核心优势可以依托知识图谱的路径遍历能力完整梳理出受负面影响的全部产品。下面这类侧重关联分析的业务问题适配Graph RAG影响分析某一项变动会波及哪些下游业务、产品、人员依赖分析某个系统/零部件/供应商被哪些主体绑定依赖组织查询员工所属团队、完整上下级汇报链路审批查询某条业务流程需要经过哪些审批角色供应链分析零部件缺货、供应商异动会影响哪些产品因果分析某一行业/业务事件如何在产业链、业务链中传导大家不难发现这类问题有统一特征答案从来不是某一段孤立的文字而是一条完整的关系路径、一张交织的关联网络。这也是Graph RAG与Classic RAG最本质的区别Classic RAG像是翻书找对应的内容页面Graph RAG像是看着地图规划完整行进路线。简单来说Graph RAG专门解决各类信息之间的关联问题。不过Graph RAG也并非完美无缺落地和维护都需要付出额外成本成本主要集中在图谱搭建与日常更新两大环节。第一实体与关系的抽取精度要求极高。如果前期实体识别出错、关系匹配偏差后续所有基于图谱的查询、遍历操作都会同步出现错误第二维护成本居高不下。企业业务永远处于动态变化中组织架构调整、产品版本更新、供应商替换、客户状态变动只要实体或关系发生变化知识图谱就必须同步更新否则就会失效第三能力存在上限。系统仅能遍历已经录入建模的实体和关系无法凭空生成、识别未录入图谱的关联关系。再次强调Graph RAG的定位是补充增强而非替代Classic RAG。如果你的业务需求只是简单的文档问答基础版RAG就足以满足只有高频遇到组织、供应链、审批流等关系密集型问题时上线Graph RAG才能体现价值。Agentic RAG自主规划动态推进问题排查如果用三个词定义三款架构Classic RAG的核心是检索、Graph RAG的核心是连接那Agentic RAG的核心就是行动与自主决策。它打破了前两种架构固定、死板的流水线运行模式依托智能代理Agent根据用户的提问目标自主判断查询方向、选择适配工具、校验资料是否充足必要时还能重新规划查询方案。大家可以把Agentic RAG理解成一名会自主思考、独立排查问题的专职业务助手。Classic RAG你问问题它检索相关资料直接作答Graph RAG在检索资料的基础上帮你梳理信息之间的关联关系Agentic RAG接到问题后先拆解分析问题再自主制定查询方案一步步排查求证最终整合答案。举个典型的复杂业务场景用户提问“咱们旗下这款产品近期销量为什么会下滑”这个问题没办法通过单次检索得出答案。销量下滑的诱因并不固定可能是定价调整、营销投放缩减、竞品抢占市场、库存缺货也可能是集中的客户投诉涉及多个数据源、多个业务模块。面对这类问题Agentic RAG会按照完整逻辑分步排查拆解核心问题明确销量下滑对应的产品、覆盖地区、下滑时间段调取销售数据库核实销量下滑数据是否真实确认下滑幅度查询产品定价历史排查近期是否有调价操作核对营销投放记录判断推广资源是否缩减梳理客服工单数据查看是否出现大批量同类负面投诉调取库存系统排查是否存在缺货、断货问题如果现有证据不足以定位原因自主调用其他工具、查询新增数据源整合所有渠道的查询结果梳理诱因假设与对应的证据链输出完整答案。这就是Agentic RAG独一无二的价值它不再执行固定的检索流程而是围绕最终目标完成规划、查询、验证、重新规划的闭环操作。在排查过程中Agent可以自由调用各类业务工具常见的包含内部文档检索工具向量数据库、知识图谱查询工具SQL数据库查询各类Web API接口表格文件读取解析工具工单系统、日志系统、BI数据报表因此Agentic RAG主要适配查询路径不固定、无统一解答模板的复杂问题典型场景如下复杂业务问题综合分析业务异常数据归因排查跨多系统、多模块问题调查多数据源交叉研判线上技术故障排查竞品全方位调研分析行业投资可行性研究业务运营数据复盘这类问题的共性十分突出没办法提前设定固定的查询流程往往需要完成第一步查询后才能确定下一步的排查方向甚至需要反向验证前期的假设。直白来说Agentic RAG把传统RAG一成不变的流水线模式升级成了动态自主的问题调查模式专门解决复杂问题中“下一步该排查什么”的核心难题。但高灵活性对应的就是更高的落地成本使用前一定要权衡利弊第一调用成本更高。Agent每一次方案规划、工具选择、结果校验、方案调整都需要单独调用大模型token消耗远高于前两种架构第二响应延迟不可控。Classic RAG单次检索即可完成作答而Agentic RAG可能需要多轮工具调用、反复求证响应时间无法预判第三问题排查难度大。如果最终答案出现偏差除了核对检索内容还需要复盘Agent的决策逻辑为什么选择这款工具、为什么跳过某类数据源、为什么判定证据充足整体调试难度翻倍。所以大家不要盲目追捧新技术Agentic RAG并不是万能的也不存在“越新越好”的说法。如果只是简单的FAQ问答上线Agentic RAG纯属大材小用性价比极低。只有面对模糊不定、多步骤联动、跨多系统无法提前预设查询路径的开放式复杂问题上线Agentic RAG才有实际意义。架构选型指南看业务问题而非盲目追新技术很多从业者在挑选RAG架构时都会陷入一个误区一味纠结哪种架构更新颖、更先进。其实更务实的选型思路只有一个根据自身业务问题的类型匹配对应的架构。大家可以参照下面三个判断标准第一能否通过单次检索直接得出答案若答案完整集中在单段文档内优先落地Classic RAG。比如产品保修期查询、年假申请规则、功能配置教程、政策适用范围等基础问题。这类问题答案明确、资料集中用基础架构足够简单、稳定、低成本没必要额外增加项目复杂度。第二答案是否依赖各类实体关系链若解答问题需要跨实体、跨文档追溯关联关系直接考虑Graph RAG。比如查询产品零部件依赖关系、供应商异动的下游影响、完整审批链路、客户关联项目与合同等。只要用户高频询问“谁影响谁、谁依赖谁、谁和谁有关”就说明业务场景需要图谱能力加持。第三能否提前固定完整的查询路径如果无法提前确定查询渠道、数据源和排查顺序就适配Agentic RAG。比如销量下滑归因、客服群体性问题溯源、业务异常定位、竞品综合研究、线上故障排查等开放式问题。这类场景可以接受更高成本、更长响应延迟以及更高的调试难度换取架构的自主决策能力。三者的详细差异可参考下表如果只想记一句核心总结Classic RAG解决资料检索问题Graph RAG解决信息关联问题Agentic RAG解决复杂场景下的自主排查问题。从Classic RAG到Graph RAG再到Agentic RAG架构的灵活度逐步提升但对应的接入成本、响应延迟、调试难度也会同步上涨。因此真实业务场景中最优解往往不是三选一而是搭建混合RAG架构。给大家分享一套稳妥的落地路径优先上线Classic RAG低成本解决80%高频、简单、答案固定的基础问题针对组织关系、供应链、审批流程等关系类难题补充Graph RAG能力最后针对开放式、多步骤、跨系统的复杂排查类问题单独部署Agentic RAG。这也契合软件工程领域的通用原则优先用最简单的方案解决绝大多数基础问题仅针对高难度特殊问题再增加系统复杂度。永远不要为了追逐新潮技术盲目上线复杂架构。架构本身没有高低之分能适配业务问题、控制落地成本的方案才是最好的方案。最后我们再回归开篇的三个核心动词帮大家巩固认知Classic RAG retrieves核心能力为检索Graph RAG connects核心能力为连接Agentic RAG reasons核心能力为推理。后续大家接触任何RAG相关方案都可以用三个问题判断适配性它在检索什么内容它在连接哪些信息它在针对什么问题做推理想清楚这三点架构选型就再也没有难度。如果你正在搭建企业知识库目前最急需解决的是资料检索、关系梳理还是多步骤复杂问题排查你更倾向从Classic RAG起步还是直接尝试Graph RAG、Agentic RAG
