企业官网建设流程全解析

过去两年，RAG 几乎已经成为企业大模型应用的标准组件。

只要涉及企业知识库、私有数据问答、制度查询、项目资料检索，大家首先想到的通常都是 RAG。

最早，我们讨论的问题很简单：

Embedding 模型选哪个？

向量数据库选 Milvus、pgvector 还是 Elasticsearch？

Chunk 切多大？

Top-K 取多少？

后来问题逐渐变复杂。

大家开始讨论：

Hybrid Search 怎么做？

BM25 和向量检索怎么融合？

Reranker 有没有必要？

Parent-Child Chunk 能不能提高召回率？

GraphRAG 到底什么时候值得使用？

而到了现在，RAG 面临的问题又发生了一次变化。

真正困难的问题开始变成：

这个问题到底需不需要检索？

应该先查哪个知识库？

第一次没查到，要不要换一个 Query？

一个问题需要组合多个知识源怎么办？

什么时候应该查询数据库，而不是向量库？

搜索出来的信息够不够支撑最终结论？

如果多个资料之间互相矛盾，要不要继续寻找新的证据？

这些已经不再只是 Retrieval 的问题。

它开始变成一个 Agent 问题。

因此，现在越来越多系统开始从传统 RAG 向Agentic RAG演进。

如果从技术演进角度来概括，这个阶段也可以称作：

RAG 3.0。

需要说明的是，RAG 3.0 并不是一个由某个标准组织正式定义的版本号，而是一种更容易理解技术演进的说法。

但背后的变化是真实存在的。

RAG 正从一个固定的“检索增强生成流水线”，逐渐演变成一个由 Agent 主导的：

自主知识获取系统。

一、从 RAG 1.0 到 RAG 2.0：我们一直在解决“怎么把知识找回来”

RAG 最初解决的问题，其实非常直接。

大模型虽然知道很多公开知识，但它不知道企业自己的知识。

比如：

公司的差旅制度是什么？

某个项目去年做了什么？

客户技术方案有哪些约束？

内部模型部署参数是多少？

这些内容既不在模型训练数据里，也不适合为了几个文档重新训练一个模型。

于是最早的 RAG 出现了。

典型架构非常简单：

用户问题 ↓Embedding ↓Vector Search ↓Top-K Chunk ↓Prompt ↓ LLM ↓Answer

核心逻辑就是：

Retrieve → Generate

先检索，再生成。

这解决了一个非常重要的问题：

企业私有知识如何进入大模型的上下文。

但 RAG 1.0 很快暴露出一个根本缺陷。

模型回答质量高度依赖第一次搜索。

如果第一次召回错了，后面的模型即使再聪明，也只能基于错误材料生成答案。

比如用户问：

“去年哪个 AI 项目的成本最高，主要原因是什么？”

传统 RAG 很可能直接拿整句话去做向量搜索。

但真正需要的信息可能分散在：

项目清单；

预算表；

GPU 采购记录；

云模型调用账单；

项目周报；

会议纪要。

一次 Top-K 很难把这些资料同时找到。

于是 RAG 进入第二阶段。

RAG 2.0 的核心目标变成：

不是只要搜到，而是要尽可能搜准。

这一阶段出现了大量 Retrieval Engineering 技术。

Query Rewrite

用户输入的问题通常不一定是最适合搜索的问题。

例如：

“这个项目为什么这么贵？”

如果直接做 Embedding，语义非常模糊。

系统需要结合对话上下文，把它改写成：

AI 网关 2026 年成本构成

或者：

AI 网关 GPU 资源、模型调用及研发成本

这就是 Query Rewrite。

Multi Query

进一步，系统不再只生成一个 Query，而是拆成多个搜索方向：

项目总预算GPU 采购成本模型 API 调用费用软件研发投入运维费用

然后分别检索，再融合结果。

这样可以显著提高复杂问题的召回率。

Hybrid Search

单独使用向量检索也并不总是可靠。

向量搜索擅长语义相似，但对型号、编号、专有名词、数字等精确信息不一定敏感。

例如：

H20GLM-5.2项目编号 XJ2026-018

这种场景 BM25 往往比 Dense Retrieval 更可靠。

于是典型检索链路开始变成：

Query │ ┌──────┴──────┐ ↓ ↓ Dense Search BM25 Search ↓ ↓ └──────┬──────┘ ↓ Fusion ↓ Reranker

Dense Retrieval 负责语义。

BM25 负责关键词。

Fusion 可以使用 RRF，也可以根据业务场景进行加权。

Reranker

第一阶段 Retriever 的目标通常是：

尽量不要漏。

例如先找 50 个候选 Chunk。

Reranker 再解决：

哪些是真的相关。

于是：

Retriever Top 50 ↓Cross Encoder / Reranker ↓ Top 5 ↓ LLM

这已经成为今天很多企业 RAG 系统的标准结构。

与此同时，还有：

Parent-Child Chunk；

Semantic Chunking；

Table-aware Chunking；

Header-aware Chunking；

GraphRAG；

Metadata Filter。

本质上全部是在解决同一个问题：

如何让真正需要的信息进入模型 Context。

但到了这里，RAG 仍然存在一个没有解决的问题：

整个 Retrieval Pipeline 是开发人员提前设计好的。

无论用户问什么，基本都按照同一套流程运行。

而真实世界的问题，本身并不是固定流程。

二、RAG 3.0：真正的变化不是检索算法，而是检索控制权

假设用户问：

去年几个 AI 项目中，哪个投入最高？为什么投入这么高？

如果让一个人去解决，他通常不会直接把整句话丢进搜索框。

一个正常的分析过程更像：

先找去年有哪些 AI 项目 ↓分别查询每个项目的投入 ↓ 比较成本 ↓ 找到最高项目 ↓ 分析成本构成 ↓继续查项目总结和会议纪要 ↓ 确认高成本原因 ↓ 形成结论

这里面包含的已经不是一次 Retrieval。

而是一系列连续决策：

任务拆解；

知识需求判断；

搜索规划；

数据源选择；

结果分析；

再次搜索；

证据验证。

因此架构必须发生变化。

传统 RAG 是：

Query ↓Retriever ↓LLM

Agentic RAG 更像：

Query ↓Planner ↓Sub Tasks ↓Tool Router ↓Retrieve ↓Evaluate ↓Need More Evidence? ↙ ↘Yes No ↓ ↓Rewrite Synthesize ↓ ↓Retrieve Answer

最大的变化并不是多了一个 Reranker，也不是换了一个更好的 Vector DB。

而是：

谁来决定下一次检索什么。

过去：

Developer ↓设计固定 Pipeline

现在：

Agent ↓根据任务动态决定

这就是 Agentic RAG 的核心。

换句话说：

传统 RAG 的中心是 Retriever。

Agentic RAG 的中心变成了 Agent。

RAG 只是 Agent 可以调用的一种 Tool。

这也是为什么现在很多 Agent 框架里，知识库开始和 SQL、Web Search、Browser、MCP 并列。

例如：

Agent │ ┌───────────┼───────────┐ ↓ ↓ ↓ RAG Search SQL MCP ↓ ↓ ↓ Vector DB Database Enterprise API │ │ │ └────── Evidence ───────┘

用户只问一个问题。

Agent 可能实际执行十几个内部 Query。

因此到了这个阶段：

用户问题已经不再等于检索 Query。

用户问题只是一个 Task。

真正的 Retrieval Query，是 Agent 执行过程中不断生成的中间产物。

比如：

太空算力现在有哪些真正落地的项目，国内外有什么区别？

Agent 可能生成：

国内已发射太空计算卫星项目国内在轨 AI 推理卫星项目国外 orbital computing projectsStarcloud orbital compute deployment已发射项目和规划项目区别太空数据中心典型应用

最后把多个结果组合起来。

因此 RAG 3.0 新增加了一个非常重要的能力：

Query Planning。

未来评估一个 RAG 系统，可能不能只看 Recall@K。

还需要看：

Agent 有没有问对问题。

三、Agentic RAG 的核心不是“多搜几次”，而是一个完整的 Retrieval Loop

如果只是让模型连续调用三次知识库，其实并不能算真正成熟的 Agentic RAG。

真正关键的是形成闭环。

典型架构应该包含至少五个组件。

1. Planner：先判断怎么解决问题

用户问题进来以后，不一定立即调用 Retriever。

首先应该进行任务分析。

例如：

{ "task_type": "multi_hop_research", "steps": [ "查询2026年AI项目列表", "查询各项目成本", "计算并比较项目投入", "查询最高成本项目的成本构成", "查询相关项目总结并分析原因" ]}

Planner 不一定要单独使用一个大模型。

很多场景可以直接利用主模型，通过 Structured Output 生成计划。

复杂系统则可能专门使用一个较小模型负责规划，降低成本。

2. Tool Router：决定去哪查

企业知识并不会全部存在向量库里。

真正的系统里通常至少有：

文档知识库数据库CMDBOACRMWiki代码仓库互联网企业 API

所以 Agent 需要判断：

“项目方案是什么”→ RAG“预算多少”→ SQL“负责人是谁”→ CMDB“审批状态”→ OA“竞争对手最近发生什么”→ Web Search

这就是 Tool Router。

这一步也是 Agentic RAG 和传统知识库最明显的区别之一。

未来企业内部的数据架构不一定是：

所有数据 ↓Embedding ↓一个巨大 Vector DB

更合理的方式可能是：

Agent │ Knowledge Router │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Documents SQL API ↓ ↓ ↓ Vector DB Database Business System

数据仍然保留在最适合自己的系统中。

Agent 通过统一 Knowledge Access Layer 使用它们。

3. Retriever：负责真正找资料

Retriever 本身仍然非常重要。

Agentic RAG 并没有取代传统 Retrieval Engineering。

反而要求 Retrieval 更可靠。

通常仍然会包含：

Query Rewrite ↓Dense + Sparse ↓Metadata Filter ↓Fusion ↓Rerank ↓Parent Chunk Expansion

也就是说：

RAG 1.0 和 RAG 2.0 的技术并没有消失。

而是成为 RAG 3.0 的基础能力。

4. Evaluator：判断证据够不够

这是很多 Demo 最容易忽略的一层。

第一次搜索之后不能直接回答。

系统应该判断：

当前 Evidence 能回答用户问题吗？

例如：

{ "sufficient": false, "missing": [ "缺少2026年项目实际支出数据", "缺少GPU采购费用" ], "next_query": [ "2026 AI项目实际支出", "AI项目GPU采购成本" ]}

如果不够，就继续搜索。

于是整个系统形成：

Retrieve ↓Evaluate ↓Enough? ↙ ↘No Yes↓ ↓Rewrite Generate↓Retrieve

这才是真正的 Retrieval Loop。

5. Evidence / Verification：答案必须有证据

企业 RAG 最终不能只输出一句“根据资料”。

应该建立 Evidence Layer。

比如：

结论 A├── 项目预算表 2026.xlsx├── AI网关项目周报第18期└── 9月项目评审会议纪要结论 B├── GPU采购记录└── 财务系统查询结果

如果两个来源冲突：

文档 A：预算 1200 万数据库 B：实际支出 1380 万

系统应该知道：

这是不同口径。

而不是随机选一个数字回答。

因此成熟 Agentic RAG 最终会逐渐加入：

Source Reliability；

Freshness；

Conflict Detection；

Citation；

Verification。

这也是为什么 RAG 3.0 本质上正在从：

Retrieval System

演变成：

Evidence System。

四、进入企业生产环境后，真正难的是权限、成本和可观测性

Agentic RAG Demo 很容易做。

给 Agent 几个 Tool，让它自己搜索，很快就能跑起来。

但一进入企业生产环境，复杂度会迅速上升。

首先是权限。

传统知识库的权限模型通常很简单：

User ↓Knowledge Base

用户有知识库权限，就能搜索。

但 Agentic RAG 里：

User ↓Agent ↓RAGSQLMCPAPIBrowser

Agent 是代表用户执行任务。

因此真正的权限模型应该是：

用户身份 ↓Agent Runtime ↓Authorization ↓Tool Permission ↓Resource Permission ↓Data Filter

例如一个研发人员问：

“帮我分析所有部门今年的 GPU 采购情况。”

即使 Agent 能调用财务数据库，也不能因此绕过原有权限体系。

所以权限必须发生在：

Retrieval Before Generation。

而不是：

先把全量数据拿给 LLM，再让模型自己判断哪些不能说。

这是完全不同的安全模型。

第二个问题是成本。

传统 RAG 一次请求可能是：

Embedding × 1Retrieval × 1LLM × 1

Agentic RAG 可能变成：

Planner × 1Query Rewrite × 3Retriever × 6Evaluator × 3Tool Call × 4Synthesis × 1Verification × 1

一个问题可能触发十几次甚至几十次调用。

因此 Agentic RAG 必须设计预算机制。

例如：

max_iterations = 5max_tool_calls = 10max_retrieval_rounds = 4max_input_tokens = 100kmax_execution_time = 30s

而且最好能够动态判断。

简单问题：

直接 Standard RAG。

复杂问题：

进入 Agentic RAG。

比较合理的架构是：

Query ↓ Complexity Router ↙ ↘ Simple Query Complex Query ↓ ↓ Standard RAG Agentic RAG ↓ ↓ Answer Answer

例如：

“差旅补贴标准是多少？”

没有必要运行 Agent。

一次检索即可。

而：

“过去三个项目成本分别是多少，哪部分增长最快，导致增长的主要原因是什么？”

才适合进入 Agentic 流程。

因此未来成熟的系统不是：

所有问题都 Agent 化。

而是：

只在必要的时候 Agentic。

第三个问题是可观测性。

传统 RAG 调试主要看：

QueryTop-KScoreAnswer

Agentic RAG 需要记录整个 Trajectory：

User Query ↓Plan ↓Tool Selection ↓Generated Query ↓Retrieved Evidence ↓Evaluation ↓Next Action ↓Tool Call ↓Final Evidence ↓Answer

否则当用户说：

“为什么这个答案错了？”

你根本无法判断是：

Planner 错了；

Query Rewrite 错了；

Retriever 漏召回；

Reranker 排错了；

Tool Router 调错工具；

数据库返回旧数据；

还是 LLM 最后总结错了。

因此 Agent Trace 会逐渐成为 Agentic RAG 的基础设施。

五、为什么 WeKnora 这一类产品开始越来越不像“知识库”

这也是最近 WeKnora 这类开源项目值得关注的原因。

如果按照传统 RAG 的产品形态，一个知识库系统通常只需要：

上传文档 ↓解析 ↓Chunk ↓Embedding ↓Retrieval ↓问答

但现在 WeKnora 已经明显超出了这个范围。

它一方面仍然保留典型 RAG 能力：

Hybrid SearchRerankParent-Child ChunkCitationGraphRAG

另一方面开始加入：

ReAct AgentMCPSkillBrowserSandbox

于是知识库从：

Retriever

逐渐变成：

Knowledge Platform

例如一个 Agent 可以：

先搜索企业知识库；

再调用 MCP 查询业务系统；

然后进入 Sandbox 处理文件；

最后综合结果生成报告。

这说明 RAG 产品的边界正在发生变化。

过去：

Knowledge Base ↓ LLM

未来可能是：

Agent │ Knowledge Runtime │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ RAG MCP SQL ↓ ↓ ↓ Document Business API Database

这里真正重要的已经不是“有没有一个知识库”。

而是有没有一套统一的：

Knowledge Runtime。

它负责：

知识在哪里；

谁可以访问；

应该用什么方式查询；

需要查几次；

什么时候停止；

证据是否足够；

最终答案来自哪里。

从这个角度看，RAG 未来可能逐渐从一个显性的产品能力，下沉成 Agent 基础设施中的一层。

就像今天很多业务系统都依赖数据库，但普通用户并不会感知：

“我现在正在使用数据库。”

未来用户也可能不会感知：

“我正在使用 RAG。”

他们只会对 Agent 说：

帮我分析一下这个项目为什么延期。

而后台自动完成：

查项目文档 ↓查 Jira ↓查会议纪要 ↓查代码提交 ↓查负责人反馈 ↓交叉验证 ↓形成分析

RAG 仍然存在。

只是它变得越来越隐形。

六、RAG 3.0 真正意味着什么：从 Retrieval 到 Autonomous Knowledge Acquisition

如果把过去几年的演进重新看一遍，其实逻辑非常清楚。

RAG 1.0 解决的是：

有没有知识。

所以核心技术是：

Embedding；

Vector DB；

Top-K。

RAG 2.0 解决的是：

能不能把正确知识找回来。

所以出现：

Query Rewrite；

Hybrid Search；

Reranker；

Semantic Chunking；

Parent-Child Chunk；

GraphRAG。

而到了 RAG 3.0，真正的问题开始变成：

为了完成当前任务，我下一步应该获取什么知识？

因此系统开始需要：

Planner；

Tool Router；

Multi-step Retrieval；

Evaluator；

Reflection；

Verification；

Memory；

MCP；

Agent Trace。

所以如果一定要用三句话概括这三代技术，我更愿意这样理解：

RAG 1.0：让模型拥有企业知识。

RAG 2.0：让模型找到更准确的企业知识。

RAG 3.0：让 Agent 自己知道应该寻找什么知识。

这三者并不是互相替代。

而是逐层叠加。

最终一个成熟的 Agentic RAG 系统可能长这样：

User Task │ ↓ Agent Runtime │ ↓ Task Planner │ ↓ Knowledge Router ┌─────────────┼─────────────┐ ↓ ↓ ↓ RAG SQL MCP │ │ │ Hybrid Search Database Enterprise API │ │ │ └──────── Evidence ─────────┘ │ ↓ Evaluator │ ┌───────┴───────┐ ↓ ↓ Continue Sufficient ↓ ↓ Re-plan Verify ↓ Answer

到了这里，RAG 已经不再只是：

Retrieval-Augmented Generation。

它正在走向：

Agentic Retrieval。

再进一步，就是：

Autonomous Knowledge Acquisition。

Agent 不再被动等待知识送进 Context。

而是根据任务主动判断：

什么时候应该查；

应该查什么；

去哪里查；

应该查多少；

哪些证据可信；

什么时候可以停止。

这可能才是所谓“RAG 3.0”真正值得关注的地方。

下一阶段企业 AI 的竞争，可能也不再只是：

谁的向量检索快几个毫秒；

谁的 Recall@10 高几个点；

谁支持更多 Vector DB。

而是：

谁能让 Agent 更稳定、更低成本、更安全地获取完成任务所需的知识。

当这件事情真正成熟以后，企业知识库也不会再只是一个：

“上传文件，然后问问题”

的系统。

它会逐渐成为：

Agent 连接企业知识、数据和业务系统的基础设施。

学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%免费】