企业官网建设流程全解析

1. 从“检索增强”到“智能体驱动”：RAG 的范式转移

1.1 为什么传统 RAG 开始不够用了

做过 RAG 项目的人大概都有过这种体验：搭一个“向量库 + 相似度检索 + 大模型生成”的流水线，第一天跑 demo 效果惊艳，第二天接入真实业务数据就开始翻车。用户问“上季度华东区退货率最高的三个品类是什么”，系统检索回来一堆包含“退货”“华东”“品类”字样的文档片段，但没有任何一段能直接回答这个问题——因为答案需要跨文档聚合、需要按时间过滤、需要做数值排序，而传统 RAG 的“一次检索、一次生成”根本扛不住这种复合型查询。

这就是最近大家反复提到的rag瓶颈。瓶颈不在向量检索本身，而在于整条链路缺少“思考”的环节。传统 RAG 把用户 query 当成一个静态字符串，直接丢给 embedding 模型去匹配，既没有理解 query 的真实意图，也没有判断检索回来的证据是否充分，更没有在证据不足时主动发起第二轮检索。它本质上是一个开环系统，没有反馈、没有规划、没有自我修正。

我自己的判断是：RAG 正在经历从“检索管道”到“智能体”的范式转移。Agentic RAG这个词听起来新，但拆开看就是三件事——查询分析（搞懂用户到底要什么）、任务规划（把复杂问题拆成可执行的检索步骤）、证据控制（判断检索结果够不够、对不对、要不要再查）。这三件事串起来，才构成一个闭环的、有自主性的检索增强系统。

1.2 这套东西适合谁、解决什么问题

如果你正在做企业知识库问答、客服工单辅助、合同条款检索、技术文档助手这类场景，并且已经踩过“检索不准、答案不全、多跳问题答不了”的坑，那这套思路就是给你准备的。它不要求你推翻现有的向量库和 embedding 方案，而是在检索和生成之间插入一个“智能体层”，用 LLM 的推理能力去调度检索行为。

适合的读者包括：有一定 RAG 实战经验、想突破效果天花板的工程师；正在做知识库产品、需要处理复杂查询的产品经理；以及想理解 Agentic RAG 到底和普通 RAG 差在哪里的技术决策者。小白也能看，但最好先跑通过一个最基础的 RAG demo，否则有些痛点你感受不深。

下面我会按“查询分析 → 任务规划 → 证据控制”这条主线，把每个环节的原理、实现细节、踩坑经验拆开讲，最后给一个可复现的 Agentic RAG 最小实现框架。

2. 查询分析：把“人话”翻译成“检索指令”

2.1 查询分析到底在分析什么

很多人以为查询分析就是“改写 query”，其实远不止。一个完整的查询分析模块至少要输出四类信息：意图类型（是事实查询、比较、聚合、还是多跳推理）、关键实体（人名、产品名、时间、地区）、约束条件（时间范围、数据来源、格式要求）、检索策略建议（该用向量检索、关键词检索、还是结构化查询）。

举个例子，用户问“对比一下 RAG 和微调在客服场景下的成本”。这句话里，意图是“比较”，实体是“RAG”“微调”“客服场景”，约束是“成本维度”，检索策略建议是“需要分别检索 RAG 成本相关文档和微调成本相关文档，然后做对比”。如果直接把原句丢给向量库，大概率检索回来的是一堆同时提到 RAG 和微调的泛泛文章，而不是分别针对两者成本的细节。

我通常的做法是让 LLM 输出一个结构化的 JSON，包含上述字段。这里有个经验：不要让 LLM 自由发挥写改写后的 query，而是让它填一个固定 schema。自由发挥的改写往往不稳定，今天改写成这样明天改写成那样，下游检索逻辑没法复用。固定 schema 的好处是可测试、可缓存、可监控。

# 查询分析输出的 schema 示例 { "intent": "comparison", "entities": ["RAG", "微调", "客服场景"], "constraints": {"dimension": "成本", "time_range": null}, "sub_queries": [ "RAG 在客服场景的成本构成", "微调在客服场景的成本构成" ], "retrieval_strategy": "multi_query_vector" }

2.2 查询改写与扩展的实操技巧

查询分析里最实用的两个操作是改写和扩展。改写解决“用户用词和文档用词不一致”的问题，比如用户说“怎么退钱”，文档里写的是“退款流程”；扩展解决“单一 query 覆盖不全”的问题，比如把“RAG 瓶颈”扩展成“RAG 检索精度瓶颈”“RAG 多跳推理瓶颈”“RAG 上下文长度瓶颈”。

我实测下来，HyDE（假设性文档嵌入）在中文场景下效果不稳定，因为让 LLM 凭空生成一段“假设的答案文档”再去做向量匹配，生成的文档质量参差不齐，反而引入噪声。更稳的做法是多查询扩展：让 LLM 基于原 query 生成 3 到 5 个不同角度的子查询，分别检索后做结果融合。融合策略我一般用 RRF（倒数排名融合），简单有效，不需要调参。

注意：查询扩展不是越多越好。我试过生成 10 个子查询，结果检索延迟翻了 4 倍，召回率只提升了不到 3 个百分点。3 到 5 个是性价比最高的区间，具体数量可以根据你的延迟预算调整。

还有一个容易被忽略的点：查询分析本身也要做缓存。很多业务场景下用户问的问题是高度重复的，比如“怎么开发票”“退货政策是什么”。把查询分析的结果按 query 哈希缓存起来，命中率能到 30% 以上，直接省掉一次 LLM 调用。

2.3 查询分析环节的常见坑

第一个坑是过度分析。有些团队把查询分析做成了一个小型 NLP 流水线，意图分类、实体识别、依存句法分析全上，结果延迟爆炸，效果还不如直接让 LLM 一次性输出结构化结果。我的建议是：能用一次 LLM 调用解决的，不要拆成多个模型串联。

第二个坑是忽略查询的时效性。用户问“最新的 RAG 框架有哪些”，这里的“最新”是个强约束，但很多查询分析模块不提取时间信息，导致检索回来的都是两年前的旧文章。解决办法是在 schema 里加一个time_sensitivity字段，高时效性的查询走“时间过滤 + 向量检索”的混合策略。

第三个坑是多语言混合查询。中文用户经常在 query 里夹杂英文术语，比如“RAG 的 retriever 怎么选”。如果 embedding 模型对中英混合支持不好，检索效果会明显下降。实测下来，用支持多语言的 embedding 模型（比如 BGE-M3）比用纯中文模型效果好很多，虽然向量维度高了、存储成本上去了，但召回率的提升值得这个代价。

3. 任务规划：让 RAG 学会“分步走”

3.1 什么查询需要任务规划

不是所有查询都需要规划。简单的事实查询，比如“RAG 的全称是什么”，一次检索就够了，硬加规划反而增加延迟。真正需要任务规划的是这三类：多跳查询（答案需要多个文档串联）、聚合查询（需要对多个结果做统计或排序）、条件查询（带复杂过滤条件的检索）。

判断标准很简单：如果一个问题需要“先查 A，再根据 A 的结果查 B”，那它就需要规划。比如“OpenAI 的 CEO 在哪个大学读的本科”，第一步查“OpenAI CEO 是谁”，第二步查“这个人的本科院校”。传统 RAG 把整个问题丢给向量库，检索回来的大概率是同时提到 OpenAI 和大学的泛泛文章，而不是精确答案。

任务规划的核心思路是让 LLM 把复杂 query 拆成一个有向无环图（DAG），每个节点是一个子任务，边表示依赖关系。然后按拓扑顺序执行，前一个节点的输出作为后一个节点的输入。

3.2 规划器的实现方式对比

目前主流的规划器实现有三种：ReAct 风格（边想边做）、Plan-and-Execute 风格（先规划再执行）、混合风格（先粗规划，执行中动态调整）。

ReAct 的优点是灵活，每一步都能根据上一步的结果调整方向；缺点是 LLM 调用次数多，延迟高，而且容易陷入循环。Plan-and-Execute 的优点是规划一次、执行多次，延迟可控；缺点是规划时看不到中间结果，遇到意外情况没法调整。混合风格是我目前最推荐的：先让 LLM 生成一个粗粒度的计划（3 到 5 步），执行过程中如果某一步的检索结果置信度低于阈值，再触发一次局部重规划。

# 任务规划的 DAG 示例 { "nodes": [ {"id": "n1", "task": "检索 OpenAI CEO 姓名", "type": "retrieval"}, {"id": "n2", "task": "检索 {n1.result} 的本科院校", "type": "retrieval", "depends_on": ["n1"]}, {"id": "n3", "task": "生成最终答案", "type": "generation", "depends_on": ["n2"]} ] }

这里有个关键细节：节点之间的参数传递要用占位符，比如{n1.result}，执行时动态替换。不要让 LLM 在规划阶段就猜出中间结果，那样规划就变成了“幻觉生成”。

3.3 规划粒度的权衡

规划粒度太粗，比如只规划“检索 → 生成”两步，那和传统 RAG 没区别；规划粒度太细，比如把“检索”拆成“生成检索词 → 调用向量库 → 过滤结果 → 重排序”，那 LLM 调用次数会多到不可接受。

我的经验值是：每个子任务对应一次工具调用。检索是一个工具，生成是一个工具，结构化查询是一个工具。规划器只负责决定“调用哪些工具、按什么顺序调用”，不负责决定工具内部的实现细节。这样既保证了灵活性，又控制了复杂度。

还有一个实操技巧：给规划器提供工具清单和示例。不要让它凭空想象有哪些工具可用，而是在 prompt 里明确列出“你可以使用以下工具：向量检索、关键词检索、SQL 查询、计算器、网页搜索”，并给每个工具配一个使用示例。这样规划出来的 DAG 更靠谱，不会出现“规划了一个不存在的工具”这种尴尬情况。

注意：任务规划不是越复杂越好。我见过一个团队把规划器做成了递归下降解析器，支持嵌套子计划、条件分支、循环，结果调试成本极高，线上故障频发。对于 90% 的业务场景，线性计划加一个条件分支就够了。

4. 证据控制：判断“够不够”和“对不对”

4.1 证据充分性判断

检索回来一堆文档，怎么知道够不够回答用户的问题？传统 RAG 的做法是“不管够不够，先塞给 LLM 再说”，结果要么是 LLM 基于不充分的证据胡编，要么是塞了太多无关内容导致 LLM 迷失。

证据控制的第一步是充分性判断：让 LLM 评估“当前检索到的证据是否足以回答原问题”。如果不足，输出“需要补充检索”以及“还需要什么信息”；如果充足，进入生成阶段。这个判断本身也是一次 LLM 调用，但它的成本远低于生成一个错误答案的代价。

我通常用 few-shot 的方式来做充分性判断，给 LLM 看几个“证据不足”和“证据充足”的示例，让它学会区分。实测下来，准确率能到 85% 以上。剩下的 15% 误判主要出现在“证据部分充足”的灰色地带，这种时候我倾向于保守策略：宁可多检索一轮，也不要基于不充分的证据生成。

4.2 证据冲突消解

比“证据不足”更麻烦的是“证据冲突”。检索回来的文档里，A 文档说“RAG 的召回率是 80%”，B 文档说“RAG 的召回率是 65%”，LLM 该信谁？如果不做处理，LLM 可能会随机选一个，或者把两个数字都列出来让用户自己判断，体验很差。

证据冲突消解的策略有三层：来源可信度排序（官方文档 > 技术博客 > 论坛帖子）、时间新鲜度排序（新文档 > 旧文档）、交叉验证（多个独立来源一致 > 单一来源）。我一般让 LLM 先做来源和时间排序，如果还是冲突，就在生成阶段明确标注“不同来源存在差异”，并给出各自的出处。

这里有个实操心得：给每个检索结果打一个可信度分数，分数由来源类型、发布时间、引用次数等元数据计算得出。生成时按可信度排序，LLM 优先使用高分证据。这个分数不需要很精确，粗略的排序就能显著提升生成质量。

4.3 证据压缩与上下文管理

检索回来 20 个文档片段，每个 500 字，总共 10000 字，全塞给 LLM 既贵又慢，而且 LLM 的注意力会被稀释。证据控制的第三步是压缩：把每个片段压缩成核心信息，只保留和 query 相关的部分。

压缩的方式有两种：抽取式（直接截取相关句子）和生成式（让 LLM 改写摘要）。抽取式快但可能不连贯，生成式连贯但可能引入幻觉。我通常用混合方式：先用抽取式筛掉明显无关的句子，再用生成式把剩下的内容改写成简洁的证据摘要。

上下文管理的另一个技巧是分层组织。把证据按重要性分成“核心证据”“辅助证据”“背景信息”三层，核心证据放在 prompt 最前面和最后面（利用 LLM 的“首因效应”和“近因效应”），辅助证据放中间，背景信息如果太长就只保留标题。这样能在有限的上下文窗口里塞进最有价值的信息。

5. Agentic RAG 的最小实现框架

5.1 整体架构与数据流

把上面三个模块串起来，一个最小的 Agentic RAG 框架包含五个组件：查询分析器、任务规划器、检索执行器、证据控制器、答案生成器。数据流是这样的：用户 query 先经过查询分析器，输出结构化查询意图和子查询；任务规划器根据意图生成执行计划；检索执行器按计划调用检索工具；证据控制器评估检索结果，决定是否补充检索；最后答案生成器基于充分证据生成回答。

这个框架和传统 RAG 最大的区别是多了两个反馈回路：一个是证据控制到检索执行的回路（证据不足时触发补充检索），一个是证据控制到任务规划的回路（证据冲突或缺失时触发重规划）。这两个回路是 Agentic RAG “智能”的来源。

# 伪代码：Agentic RAG 主流程 def agentic_rag(query): analysis = query_analyzer(query) plan = task_planner(analysis) evidence = [] for task in plan.tasks: result = retriever.execute(task) evidence.extend(result) if not evidence_controller.is_sufficient(evidence, query): plan = task_planner.replan(analysis, evidence) continue answer = generator.generate(query, evidence) return answer

5.2 关键参数与调优经验

检索数量 top_k：传统 RAG 一般设 3 到 5，Agentic RAG 可以设大一点，因为后面有证据控制做过滤。我通常设 10，然后让证据控制器筛到 3 到 5 个核心证据。

充分性判断阈值：这个阈值决定了什么时候触发补充检索。设太高会导致检索轮次过多，设太低会导致证据不足就生成。我的经验值是 0.7，即 LLM 认为“70% 以上的问题能被当前证据回答”时就停止检索。

最大检索轮次：一定要设上限，否则可能无限循环。我一般设 3 轮，超过 3 轮还没找到充分证据，就基于现有证据生成，并在答案里标注“信息可能不完整”。

重规划触发条件：不是每次证据不足都要重规划。如果只是缺一个细节，补充检索就够了；如果是整个检索方向错了，才需要重规划。判断标准是“当前计划的所有子任务是否都已完成但证据仍不足”，如果是，才触发重规划。

5.3 和 KG 知识库、结构化知识库的配合

最近很多人问rag知识库和结构知识库区分以及应用场景。简单说，向量 RAG 知识库擅长处理非结构化文本（文档、邮件、聊天记录），结构化知识库（SQL、图数据库）擅长处理有明确 schema 的数据（订单、库存、组织架构）。Agentic RAG 的价值在于它能同时调度这两种知识库。

比如用户问“上季度退货率最高的品类，对应的客服工单里主要抱怨什么”。这个问题需要两步：第一步查结构化数据库拿到“退货率最高的品类”，第二步查向量知识库拿到“该品类的客服工单文本”。传统 RAG 做不了这种跨库查询，Agentic RAG 的任务规划器可以生成一个包含 SQL 查询和向量检索的混合计划。

KG 知识库（知识图谱）在这套框架里的角色是“关系推理”。向量检索擅长找相似文本，但不擅长回答“A 和 B 是什么关系”这类问题。知识图谱可以把实体和关系显式存储，Agentic RAG 在需要关系推理时调用图查询接口，把结果作为证据补充进来。这就是ontology rag的思路：用本体定义领域概念和关系，用图谱存储实例，用 RAG 做自然语言接口。

注意：不要为了用 KG 而用 KG。我见过一些团队把简单的文档问答硬套知识图谱，结果图谱构建和维护成本极高，效果还不如纯向量检索。KG 适合实体关系密集、需要多跳推理的场景，比如医疗诊断、金融风控、供应链分析。

6. 常见问题与排查技巧实录

6.1 检索结果不相关怎么办

这是最高频的问题。排查顺序是：先看查询分析输出的子查询是否准确，再看 embedding 模型是否适合你的领域，最后看向量库的索引参数是否合理。

如果子查询就不对，那问题在查询分析环节，需要调整 prompt 或换更强的 LLM。如果子查询对但检索结果不对，那可能是 embedding 模型的问题——通用 embedding 模型在垂直领域（医疗、法律、金融）表现往往不好，需要换领域微调过的模型。如果 embedding 没问题但排序不对，那可能是向量库的相似度度量选错了，余弦相似度和内积在不同场景下效果差异很大。

我自己的排查清单是这样的：

6.2 延迟太高怎么优化

Agentic RAG 的延迟天然比传统 RAG 高，因为多了查询分析、任务规划、证据控制这几次 LLM 调用。优化手段有四个：缓存（查询分析结果、检索结果、甚至生成结果都可以缓存）、并行（没有依赖关系的子任务并行执行）、小模型（查询分析和证据控制用 7B 小模型，生成用大模型）、流式输出（生成阶段流式返回，降低用户感知延迟）。

我实测下来，缓存能省 30% 到 50% 的延迟，并行能省 20% 到 30%，小模型能省 40% 左右。组合使用可以把端到端延迟从 8 秒压到 3 秒以内。

6.3 证据控制误判怎么处理

证据控制的误判主要有两种：假阳性（证据其实不够但判断为够）和假阴性（证据其实够了但判断为不够）。假阳性的后果是生成错误答案，假阴性的后果是多检索一轮、延迟增加。

我的策略是宁可假阴性，不要假阳性。因为多检索一轮的成本远低于生成错误答案的成本。具体做法是把充分性判断的阈值调低，让 LLM 更容易说“不够”。同时，在生成阶段加一个“置信度标注”，如果证据确实不充分，让 LLM 在答案里明确说“根据现有信息，可能不完整”。

还有一个技巧是用规则兜底。比如如果检索结果的数量少于 2 个，直接判定为不充分，不需要 LLM 判断。如果检索结果的来源全部相同，也判定为不充分，因为缺乏交叉验证。这些规则能覆盖 20% 左右的明显情况，减少 LLM 调用。

6.4 怎么在 Mac 上搭建本地 RAG 知识库

最近怎么在mac上搭建rag知识库是个高频问题。Mac 的优势是本地开发体验好，M 系列芯片跑小模型推理够用。我的推荐方案是：用 Ollama 跑本地 LLM（比如 Qwen2.5 7B 或 Llama 3.1 8B），用 Chroma 或 LanceDB 做向量库（都是本地文件存储，不需要额外服务），用 LangChain 或 LlamaIndex 做编排框架。

具体步骤：先装 Ollama 并拉取模型，再装 Python 环境和向量库依赖，然后把文档切块、嵌入、存入向量库，最后写一个简单的检索加生成脚本。整个流程在 M1 MacBook Air 上跑通大概需要 30 分钟，检索延迟在 1 到 2 秒左右，生成延迟取决于模型大小，7B 模型大概 3 到 5 秒。

提示：Mac 上跑本地 RAG，最大的瓶颈是内存。7B 模型量化后大概占 4 到 5 GB 内存，加上向量库和 Python 运行时，8 GB 内存的机器会比较吃力。建议 16 GB 起步，32 GB 更从容。

7. 我踩过的坑和最后几条建议

第一个坑是过早引入 Agentic 架构。我一开始做 RAG 的时候，基础检索还没调好，就急着上查询分析和任务规划，结果整个系统复杂度爆炸，出了问题根本不知道是哪个环节的锅。后来退回去先把基础 RAG 的召回率调到 80% 以上，再逐步加 Agentic 模块，效果才稳定下来。所以我的建议是：先把传统 RAG 做到及格，再考虑 Agentic 化。

第二个坑是忽略评估。Agentic RAG 的链路长、变量多，没有评估体系根本没法迭代。我后来搭了一个包含 200 条测试 query 的评估集，每条 query 标注了标准答案和关键证据，每次改动都跑一遍评估，看召回率、准确率、延迟的变化。这个评估集花了我两天时间构建，但后面省下的调试时间至少是它的十倍。

第三个坑是把 LLM 当万能工具。查询分析、任务规划、证据控制、答案生成，每个环节都用 LLM，成本高不说，延迟也受不了。后来我把一些确定性强的环节用规则替代，比如“检索结果少于 2 个就判定不充分”“来源全部相同就判定不充分”，这些规则覆盖了 20% 的情况，省下了对应的 LLM 调用。

最后分享一个我觉得最有用的技巧：给每个环节加日志和可视化。Agentic RAG 的决策链路很长，出了问题光看最终答案根本定位不到原因。我在每个环节都打印输入输出，查询分析输出了什么子查询、任务规划生成了什么计划、证据控制判断了几次、每次的判断理由是什么。这些日志在调试的时候价值极高，虽然看起来笨，但比任何花哨的调试工具都管用。

这套东西我目前在生产环境跑了三个月，处理的是技术文档问答场景，日均查询量在 5000 左右。相比之前的传统 RAG，多跳问题的回答准确率从 40% 提升到了 75%，聚合类问题的准确率从 30% 提升到了 65%，代价是平均延迟从 1.5 秒增加到了 3.2 秒。这个 trade-off 在大多数业务场景下是值得的，但如果你的场景对延迟极度敏感，可能需要重新权衡哪些环节值得 Agentic 化。