企业官网建设流程全解析

1. 先用一句话区分

标准 RAG像是在资料库里“找最像的问题相关段落”。

Graph RAG像是在知识图谱里“沿着实体关系追线索”。

Agentic RAG像是让一个智能助理“自己判断该查哪个库、调哪个工具、按什么顺序完成任务”。

更具体一点：

这里的关键是：它们不是从低级到高级的三层台阶，而是三种不同形状的工具。

2. 为什么需要 RAG

大语言模型本身像一个“已经读过很多书的人”。它能根据训练时见过的文本模式生成回答，但它有几个天然问题：

• 不知道最新信息：训练之后发生的事，它默认不知道。
• 不能直接读取你的私有资料：公司文档、内部接口、客户记录不在模型参数里。
• 容易幻觉：没有可靠上下文时，模型可能编出听起来合理但不真实的答案。

RAG 的全称是 Retrieval-Augmented Generation，也就是检索增强生成。

它的思路很朴素：先从外部知识库里检索相关内容，再把这些内容塞进提示词里，让 LLM 基于检索到的材料回答。

可以把一次 RAG 调用写成：回答 = LLM(用户问题 + 检索到的上下文)。

如果记用户问题为 ，检索结果为 ，模型为 ，那么 RAG 的基本形式就是 。

3. 标准 RAG：从相似文本里找答案

标准 RAG 最常见的实现方式是“向量检索”。

它一般分成两个阶段：索引阶段和查询阶段。

3.1 索引阶段：把文档变成向量

假设我们有很多文档，系统会先把文档切成一个个小块，也就是 chunk。比如一份 20 页的说明书，可能被切成几十个或几百个片段。

然后使用 embedding model 把每个 chunk 变成一个向量。

如果第 个文本块是 ，embedding model 是 ，那么它的向量就是 。

这些向量会被存进向量数据库，例如 FAISS、Milvus、Pinecone、Weaviate、Qdrant 等。

3.2 查询阶段：找最相似的 chunk

用户提出问题 后，系统也会把问题转成向量 。

接着，系统会在向量数据库里查找和 最相似的若干个文本块。最常见的相似度指标是余弦相似度：。

标准 RAG 的检索可以简单理解为：。

也就是说，它会挑出和问题向量最接近的前 个 chunk，然后把这些 chunk 拼进提示词，让 LLM 作答。

3.3 标准 RAG 擅长什么

标准 RAG 很适合直接事实查询。

比如：

• “退款政策是什么？”
• “API 的限流是多少？”
• “某个产品支持哪些地区？”
• “这份合同里付款周期是多久？”

这些问题通常只需要找到一两个高度相关的文本块。只要答案就在某个 chunk 里，标准 RAG 通常表现很好。

4. 标准 RAG 的短板：它不擅长连接关系

标准 RAG 的核心是“相似”。它问的是：哪些文本块和用户问题最像？

但很多问题真正需要的不是“最像的文本”，而是“把几个事实连起来”。

来看一个内部系统的例子。假设知识库里有三条事实：

1. “checkout service 使用 payments API。”
2. “payments API 运行在 cluster-3 上。”
3. “cluster-3 周五会维护。”

用户问：“周五维护会影响 checkout service 吗？”

对人来说，这个推理非常自然：

checkout service -> payments API -> cluster-3 -> Friday maintenance

所以答案是：会，checkout service 可能受到影响，因为它依赖的 payments API 在 cluster-3 上，而 cluster-3 周五维护。

但标准 RAG 可能出问题。

原因在于第二条事实“payments API 运行在 cluster-3 上”既没有提到checkout service，也没有提到“周五维护”。它在语义上是中间桥梁，但和用户问题的表面相似度不一定高。

如果查询向量是 周五维护会影响吗，那么第 1 条和第 3 条可能有较高的 ，但第 2 条的 可能偏低。于是 Top-K 检索可能漏掉第 2 条。

一旦漏掉中间事实，LLM 看到的上下文就断了。它可能只能说“无法确定”，或者更糟，编出一个不可靠结论。

这就是标准 RAG 的典型短板：它检索的是相似 chunk，不是事实之间的关系路径。

5. Graph RAG：把知识连成一张图

Graph RAG 的核心思想是：不要只把文档切块后丢进向量库，还要从文档中抽取实体和关系，构建知识图谱。

知识图谱可以理解成一张由“点”和“边”组成的网。

• 点：实体，例如checkout service、payments API、cluster-3。
• 边：关系，例如uses、runs_on、scheduled_for_maintenance。

用数学语言说，知识图谱可以记作 。其中 是节点集合，表示实体； 是边集合，表示实体之间的关系。

刚才的三个事实可以变成：

• 节点：checkout service、payments API、cluster-3、Friday maintenance
• 边：checkout service --uses--> payments API
• 边：payments API --runs_on--> cluster-3
• 边：cluster-3 --has_maintenance_on--> Friday

标准 RAG 更像是在“文本块列表”里找东西；Graph RAG 更像是在“实体关系网络”里走路。

6. Graph RAG 如何解决多跳问题

Graph RAG 一般也分为索引阶段和查询阶段，但每个阶段做的事情和标准 RAG 不一样。

6.1 索引阶段：抽取实体和关系

Graph RAG 会先让 LLM 或信息抽取模型从文档中识别实体和关系。

比如看到“checkout service uses payments API”，系统会抽取出三元组：。

三元组的形式通常是 ，其中 是头实体， 是关系， 是尾实体。它表示“实体 通过关系 指向实体 ”。

大量三元组合在一起，就形成了知识图谱 。

6.2 查询阶段：先定位实体，再遍历关系

当用户问“周五维护会影响 checkout service 吗？”时，Graph RAG 会先识别问题里的关键实体，例如checkout service和Friday maintenance。

然后它不会只查相似文本，而是会在图里查找连接路径。

可以把图遍历理解为：从起点实体 出发，在图 中寻找能到达目标实体 的路径 ，其中 ，。

在例子里，它会找到：

checkout service -> payments API -> cluster-3 -> Friday maintenance

这个路径长度是 3，也就是需要三次关系跳转。很多资料会把这类问题叫做 multi-hop question，也就是多跳问题。

6.3 为什么它比向量检索更适合多跳

标准 RAG 的检索信号主要是 ，也就是“问题和文本块像不像”。

Graph RAG 的检索信号除了相似度，还包括图结构里的可达性。简单说就是：两个事实即使文字不相似，只要它们通过实体关系连着，就有机会被一起找出来。

如果两个实体之间存在路径 ，Graph RAG 可以把路径上的节点和边都取出来作为上下文。于是 LLM 看到的不再是几个孤立 chunk，而是一条完整证据链。

这就是 Graph RAG 的价值：它把“资料里有哪些句子”升级成了“事实之间如何连接”。

7. Agentic RAG：让 Agent 自己决定怎么查

Agentic RAG 和前两者的思路不同。

标准 RAG 和 Graph RAG 通常有比较固定的流程：用户提问，系统检索，拼上下文，LLM 回答。

Agentic RAG 则把 LLM 放到更主动的位置：它不只是最后生成答案，还会在查询时决定要做哪些步骤。

它可能会自己判断：

• 这个问题要不要查向量库？
• 要不要查图数据库？
• 要不要调用搜索引擎？
• 要不要访问业务数据库？
• 要不要调用某个 API？
• 第一次查到的信息够不够？是否需要继续查？

如果把工具集合记为 ，Agentic RAG 的每一步可以理解为：智能体根据当前状态 选择一个动作 ，执行后得到观察结果 ，再更新状态 。

这很像一个循环：思考 -> 选择工具 -> 执行工具 -> 观察结果 -> 再决定下一步。

用简化形式表示就是：，。

这里的 可以理解为“由 LLM 驱动的策略”：它根据当前问题、已有上下文和工具说明，决定下一步做什么。

7.1 Agentic RAG 适合什么问题

Agentic RAG 适合那些一开始就不知道固定流程的问题。

例如：

• “帮我查一下这个客户最近三个月的投诉、合同状态和未关闭工单，然后总结风险。”
• “这个服务今天延迟升高，帮我查日志、指标和最近部署记录，判断可能原因。”
• “对比竞品官网、我们内部报价表和 CRM 记录，给出这个客户的续约建议。”

这类任务的特点是：数据源多、步骤不固定、可能需要边查边决定下一步。

标准 RAG 像“查资料”；Graph RAG 像“顺关系”；Agentic RAG 更像“派一个会用工具的研究员”。

7.2 Agentic RAG 的风险

Agentic RAG 更灵活，但也更难控制。

常见风险包括：

• 成本更高：多轮工具调用会消耗更多 token 和接口费用。
• 延迟更高：它可能要连续查多个系统。
• 可控性更弱：Agent 可能选择不理想的工具顺序。
• 评估更复杂：不只是答案对不对，还要看中间步骤是否合理。
• 权限风险更高：如果接入数据库、API、写操作工具，需要严格控制权限。

所以 Agentic RAG 不是“默认更好”，而是适合需要动态规划和工具使用的任务。

8. 三者不是升级路线，而是不同工具

一个常见误解是：标准 RAG 低级，Graph RAG 更高级，Agentic RAG 最高级。

这个理解不准确。

更好的理解是：它们解决的问题类型不同。

如果只是问“退款规则是什么”，上 Agentic RAG 可能是浪费。

如果问“哪些供应商会被某个地区的新法规间接影响”，只靠标准 RAG 可能漏掉中间关系。

如果问“帮我查线上故障原因，并根据日志、监控和最近变更给出结论”，固定检索流程可能不够，需要 Agentic RAG。

架构选型的本质不是追求复杂，而是匹配问题形状。

9. 如何选型

可以用三个问题来判断。

9.1 问题是否能由一个片段直接回答？

如果能，优先用标准 RAG。

例如用户问：“这份 API 文档里rate_limit的默认值是多少？”

这类问题的答案通常就在一个局部片段里。标准 RAG 的 Top-K 检索足够有效，系统也更简单、便宜、稳定。

9.2 问题是否依赖实体之间的关系链？

如果是，考虑 Graph RAG。

例如用户问：“哪些业务服务会受到 cluster-3 维护影响？”

这个问题不是找一个文本片段，而是从cluster-3往外找依赖它的服务。它需要沿着runs_on、depends_on、uses这类关系反向追踪。

这种时候图结构更自然。

9.3 问题是否需要动态调用多个工具？

如果是，考虑 Agentic RAG。

例如用户问：“帮我分析今天支付失败率升高的原因。”

这个任务可能需要查监控、日志、部署记录、错误码分布、第三方支付状态页。你很难提前写死一个永远正确的检索流程。

这时 Agentic RAG 的价值在于：它可以根据当前查到的证据决定下一步。

10. 一句话总结

标准 RAG 解决的是：“从资料里找最相关的文本。”

Graph RAG 解决的是：“沿着实体关系找到完整证据链。”

Agentic RAG 解决的是：“让智能体动态决定查什么、怎么查、查完做什么。”

如果用一个生活化比喻：

• 标准 RAG 像在图书馆搜索关键词和相似段落。
• Graph RAG 像看一张人物关系图，顺着关系找到真相。
• Agentic RAG 像请一个研究助理，让他自己查资料、打电话、调系统、整理结论。

单跳事实查标准 RAG，多跳关系查 Graph RAG，多源动态任务用 Agentic RAG。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】