企业官网建设流程全解析

1. 从传统RAG到Agentic RAG：为什么需要“会思考”的检索

1.1 传统RAG的天花板在哪里

做过RAG应用的人大概都有体会：第一版demo跑通很容易，把文档切块、向量化、检索Top-K、拼进Prompt让模型回答，半天就能上线。但真正放到业务里，问题就来了。用户问“我们公司去年Q3的差旅报销标准相比前年有哪些调整”，传统RAG的做法是把这句话整体向量化，然后去检索最相似的几个文本块。结果往往是检索回来一堆讲报销流程的、讲发票要求的，唯独没有精确命中“Q3标准调整”这个核心诉求。

根本原因在于，传统RAG把“检索”当成了一个一次性的、被动的动作。它假设用户的问题和文档中的答案之间存在直接的语义相似性，只要向量空间里距离够近就能找到。但现实中的复杂问题往往需要多步推理、多源交叉验证、甚至先搞清楚“我到底该查什么”才能开始查。这就像你去图书馆找资料，传统RAG相当于直接把你推到书架前说“自己找吧”，而Agentic RAG则是先帮你分析“你需要的是2023年修订版第三章节”，然后带你去对应的书架，翻到具体页码，再确认这一页的内容是否真的回答了你的问题。

我在实际项目中遇到过最典型的翻车场景是“多跳问题”。比如用户问“对比一下我们和竞品在东南亚市场的定价策略差异”，这个问题需要先检索自家定价，再检索竞品定价，然后做对比分析。传统RAG一次性检索回来的内容要么偏向自家、要么偏向竞品，很难同时覆盖两个维度。而Agentic RAG可以把这个问题拆解成“先查自家东南亚定价”“再查竞品东南亚定价”“最后做对比”三个子任务，每个子任务独立检索、独立验证，最后汇总。

1.2 Agentic RAG的核心思路：把检索变成主动决策

Agentic RAG的本质，是把LLM从“被动接收检索结果的消费者”变成“主动规划检索策略的决策者”。它不再是一次“检索-生成”的直线流程，而是一个“规划-检索-评估-再检索-生成”的循环。这个循环里，LLM要回答几个关键问题：当前信息够不够回答问题？如果不够，还缺什么？下一步该用什么查询词、去哪个数据源查？查回来的内容可信吗？需不需要换个角度再查一次？

这个思路的转变带来的最大好处是“自适应”。简单问题一步检索就够，复杂问题自动展开多步；结构化数据用SQL查，非结构化文档用向量检索，代码仓库用关键词匹配——Agent会根据问题类型自己选工具。我见过一个很巧妙的实现，Agent在检索前会先判断问题类型：事实型问题直接走向量检索，对比型问题走多路检索加汇总，时序型问题先做时间范围过滤再检索。这个判断逻辑本身也是用Prompt实现的，不需要额外训练模型。

从工程角度看，Agentic RAG的架构通常包含四个核心模块：规划器负责拆解问题、制定检索计划；执行器负责调用具体检索工具；评估器负责判断检索结果的相关性和充分性；记忆模块负责存储中间结果和对话历史。这四个模块通过一个状态机或者图结构串联起来，形成一个可循环的工作流。LangGraph、AutoGen这类框架本质上就是在提供这种状态编排能力。

1.3 效率边界：Agentic RAG不是银弹

必须说清楚一点：Agentic RAG的代价是延迟和成本成倍增加。传统RAG一次检索加一次生成，可能两秒内返回；Agentic RAG如果循环三轮，每轮都调LLM做规划和评估，延迟轻松突破十秒，Token消耗也是数倍。所以它适合的是“复杂问题、高价值场景”，比如法律条文检索、医疗文献综述、金融研报分析，而不是“今天天气怎么样”这种简单查询。

我在实际落地时的经验是：先做问题复杂度分类，再决定走哪条路径。用一个轻量级分类器（甚至正则匹配加关键词规则）判断问题是否需要多步推理。简单问题走传统RAG快速通道，复杂问题才触发Agentic流程。这样既保证了大部分请求的响应速度，又在关键场景提供了深度检索能力。这个“快慢双通道”的设计，是我踩过几次全量Agentic导致系统响应崩溃的坑之后才总结出来的。

2. 深度研究场景下的检索策略设计

2.1 查询改写与扩展：让检索词更“懂”问题

Agentic RAG的第一步通常是查询改写。用户原始问题往往口语化、模糊、甚至带有错别字，直接拿去检索效果很差。查询改写的目标是生成多个“检索友好”的查询变体，覆盖问题的不同侧面。常见策略包括：同义词扩展、上下位词替换、多语言翻译、以及基于领域知识的术语标准化。

举个实际例子。用户问“himmpat专利检索网站怎么用”，如果直接检索“himmpat专利检索网站怎么用”，可能只能命中网站首页。但经过查询改写后，Agent会生成“himmpat 专利检索 使用教程”“himmpat 检索语法”“专利检索网站 操作指南”等多个查询，分别检索后再合并结果。这样召回率会显著提升。我在做专利检索类Agent时，还会额外加入IPC分类号、申请人名称等结构化字段的检索，把自然语言查询和结构化查询结合起来。

查询扩展的另一个技巧是“假设性文档生成”。让LLM先根据问题“编造”一段可能的答案，然后用这段答案去检索。这个方法的逻辑是：真实文档的表述方式和假设性答案的表述方式更接近，比原始问题更容易匹配。实测下来，对于学术文献检索和法规条文检索，这个方法能把召回率提升20%到30%。但要注意，假设性答案可能引入幻觉，所以它只用于检索，不能直接作为最终答案。

2.2 多路召回与融合排序：不把鸡蛋放在一个篮子里

单一检索方式总有盲区。向量检索擅长语义匹配，但对精确关键词、数字、代码符号不敏感；关键词检索（BM25）擅长精确匹配，但无法处理语义泛化。Agentic RAG通常会同时走多路召回，然后做融合排序。

融合排序最常用的方法是RRF（Reciprocal Rank Fusion），它不需要调参，直接把多路结果的排名做倒数加权求和。公式很简单：对于每个文档，得分等于它在各路结果中排名的倒数之和。比如一个文档在向量检索中排第3，在BM25中排第5，它的RRF得分就是1/3 + 1/5 = 0.533。这个方法的好处是鲁棒性强，不需要知道各路检索的分数分布，直接看排名就行。

我在实际项目中的做法是：向量检索走一路，BM25走一路，如果数据源包含表格或结构化数据，再加一路SQL查询。三路结果用RRF融合后，取Top-20进入精排。精排可以用一个交叉编码器（Cross-Encoder）做细粒度相关性打分，把最相关的5到8个文档块送给LLM生成答案。这个“粗排-精排-生成”的三段式结构，在保证召回率的同时控制了送入LLM的上下文长度，对成本和延迟都有好处。

2.3 检索粒度控制：块大小、重叠与元数据

检索粒度是个容易被忽视但影响巨大的参数。块太大，检索回来的内容包含大量无关信息，浪费上下文窗口；块太小，可能丢失关键上下文，导致答案不完整。我的经验值是：对于技术文档和学术论文，块大小设在512到1024个Token之间比较合适，重叠区设在10%到20%。对于法律条文和规章制度，块要更小，256到512个Token，因为每一条都是独立的法律单元，混在一起会引入噪声。

元数据的作用同样关键。每个文档块除了文本内容，还应该携带来源、章节、时间、作者、文档类型等元信息。Agent在检索时可以根据元数据做过滤，比如“只查2023年之后的文档”“只查技术白皮书”“排除已废止的版本”。我在做企业知识库Agent时，会给每个块打上“部门”“密级”“生效日期”三个标签，检索时自动根据用户权限和问题时效性做过滤。这个设计让答案的准确率和合规性都提升了一个档次。

还有一个细节：表格和图片的处理。很多RAG系统直接把表格转成文本，丢失了行列结构，导致LLM理解错误。更好的做法是把表格转成Markdown格式保留结构，或者用多模态模型单独处理。图片则可以通过OCR提取文字，或者用视觉模型生成描述性文本再入库。这些预处理步骤虽然麻烦，但对最终效果的影响是决定性的。

3. 证据核验：让Agent学会“不轻信”

3.1 为什么需要证据核验

RAG系统最怕的不是“找不到”，而是“找到了但不对”。检索回来的内容可能过时、可能相互矛盾、可能是低质量来源、甚至可能是模型自己之前产生的幻觉被重新检索回来。如果不做核验，LLM会把这些内容当作事实来生成答案，导致“有据可查的错误”——这比没有依据的错误更危险，因为它看起来很有说服力。

证据核验的目标是给每个检索结果打一个“可信度分数”，只有超过阈值的证据才能进入最终答案生成。这个分数可以基于来源权威性、时效性、与问题的相关性、以及多源一致性来计算。我在实际项目中的做法是：先做相关性过滤（低于阈值的直接丢弃），再做来源加权（官方文档权重高于论坛帖子），最后做交叉验证（如果多个独立来源说法一致，可信度提升；如果相互矛盾，标记为争议点让LLM谨慎处理）。

3.2 核验的具体实现方法

最直接的核验方法是“让LLM自己判断”。把问题和检索结果一起给LLM，问它“这段内容是否直接回答了问题？是否包含矛盾信息？来源是否可靠？”LLM会给出一个判断和理由。这个方法的成本是每次核验都要调一次LLM，但效果通常比规则方法好。为了控制成本，可以只对Top-5的结果做LLM核验，后面的结果用轻量级规则过滤。

另一个方法是“多源一致性检查”。对于同一个事实性问题，检索多个独立来源，如果它们说法一致，则可信度高；如果只有单一来源，则标记为“待验证”。我在做医疗问答Agent时，会强制要求每个结论至少有两个独立来源支持，否则在答案中明确标注“该信息仅来自单一来源，建议进一步确认”。这个设计虽然增加了检索轮次，但显著降低了错误率。

还有一个容易被忽视的点：时间衰减。很多领域的知识有时效性，比如政策法规、产品价格、技术版本。检索结果应该根据发布时间做衰减加权，越新的内容权重越高。实现上可以在元数据里存一个“生效日期”或“发布日期”，检索时根据当前时间计算衰减因子。对于快速变化的领域，比如AI技术，半衰期可能只有几个月；对于基础科学，半衰期可以设几年。

3.3 矛盾检测与处理策略

当检索结果出现矛盾时，Agent不能简单地“选一个信”或者“都列出来让用户自己判断”。更好的做法是：先识别矛盾点，然后分析矛盾原因，最后给出有条件的答案。比如两个来源对同一个政策的解读不同，Agent应该指出“来源A认为……，来源B认为……，差异可能源于发布时间不同/适用范围不同”，然后建议用户根据具体情况判断。

我在实际项目中遇到过一种棘手情况：同一个问题，检索回来的两个文档一个说“可以”，一个说“不可以”，而且都是官方文档。仔细一看，一个是旧版规定，一个是新版规定，新版明确废止了旧版。这种情况下，Agent需要识别出版本关系，优先采用新版。实现上可以在元数据里加“版本号”和“替代关系”字段，检索时自动做版本仲裁。

还有一种矛盾是“部分正确”导致的。比如一个文档说“该功能支持A和B”，另一个文档说“该功能只支持A”，其实两个都对，只是第二个文档写于功能B上线之前。这种时间导致的矛盾，通过时间衰减和版本管理可以解决大部分。剩下的真正矛盾，就需要Agent在答案中明确标注争议，而不是强行给一个确定答案。

4. 长程研究：多步推理与状态管理

4.1 长程研究的任务特征

长程研究（Long-horizon Research）指的是那些需要多轮检索、多步推理、跨多个数据源才能完成的任务。比如“帮我写一份关于某行业过去五年技术演进的综述”“分析某公司财报中隐藏的风险点”“对比三款竞品在特定场景下的优劣”。这类任务的特点是：没有单一文档能回答，需要从多个来源收集碎片信息，然后做综合、对比、推理。

这类任务对Agent的要求远高于简单问答。它需要维护一个“研究状态”，记录已经查了什么、还缺什么、有哪些发现、有哪些矛盾。这个状态在每一轮检索后更新，指导下一轮的检索方向。没有状态管理，Agent就会像无头苍蝇一样重复检索或者遗漏关键信息。

4.2 状态管理的工程实现

状态管理最简单的实现是用一个字典或JSON对象，记录“已检索查询”“已获取文档”“待验证假设”“已确认事实”“未解决问题”等字段。每轮循环开始时，Agent读取状态，决定下一步行动；每轮循环结束时，Agent更新状态。这个状态对象可以持久化到数据库，支持中断恢复和并行研究。

更复杂的实现是用图结构，节点是“研究子问题”，边是“依赖关系”。比如“对比竞品定价”这个节点依赖于“获取自家定价”和“获取竞品定价”两个节点。Agent按照拓扑顺序依次解决子问题，每个子问题的结果作为下一个子问题的输入。这种结构化的方式让研究过程更可控，也更容易排查问题——如果最终答案不对，可以回溯到具体哪个子问题出了错。

我在实际项目中的经验是：状态要尽量结构化，不要用自然语言描述。自然语言状态虽然灵活，但LLM在读取时容易遗漏或误解。用JSON格式定义好字段，每个字段有明确的语义，LLM只需要填充和读取，出错概率大大降低。比如“已确认事实”是一个列表，每个元素包含“事实内容”“来源”“置信度”三个字段，这样后续推理时可以直接引用来源做引用标注。

4.3 终止条件与效率控制

长程研究最大的风险是“无限循环”——Agent一直觉得信息不够，一直检索下去。必须设置明确的终止条件。常见的终止条件包括：达到最大轮次（比如10轮）、连续两轮没有新增有效信息、所有子问题都已解决、或者达到Token预算上限。

我通常会用组合条件：最大轮次设为8到10轮，同时监控“信息增益”——如果新一轮检索回来的内容与已有内容的重叠度超过80%，说明已经进入重复检索，可以提前终止。这个重叠度可以用文本相似度或者集合交集来计算。另外，如果Agent连续两次评估都认为“当前信息已足够回答问题”，也可以终止。

效率控制的另一个关键是“并行化”。长程研究中的很多子问题是相互独立的，可以并行检索。比如“对比三款竞品”可以同时检索三款竞品的信息，而不是串行。实现上可以用异步任务或者多线程，把独立的检索请求同时发出去，等所有结果回来后再做汇总。这个优化能把长程研究的延迟降低一半以上。

5. 效率边界：成本、延迟与质量的三角权衡

5.1 成本构成与优化空间

Agentic RAG的成本主要来自三块：LLM调用（规划、评估、生成）、向量检索（Embedding和向量数据库查询）、以及外部API调用（如果涉及搜索引擎或专业数据库）。其中LLM调用通常占大头，尤其是多轮循环时，每轮都要调LLM做规划和评估，Token消耗很快。

优化成本的第一招是“模型分级”。规划、评估这类任务不需要最强模型，用轻量级模型（比如7B参数级别）就够了；只有最终答案生成才用最强模型。实测下来，这个策略能降低60%以上的LLM成本，而对最终质量的影响很小。第二招是“缓存”。很多查询是重复的或者相似的，把检索结果和LLM判断缓存起来，下次遇到相同查询直接返回。缓存命中率在真实业务中通常能达到30%到50%。第三招是“提前终止”。前面提到的信息增益监控，不仅能控制延迟，也能省下不必要的LLM调用。

5.2 延迟优化：让用户等得少一点

Agentic RAG的延迟是用户体验的杀手。用户问一个问题，等十秒才出答案，很多人就放弃了。优化延迟的思路有几个：一是“流式输出”，让用户先看到部分答案，再逐步补充；二是“预检索”，对于可预测的后续问题，提前在后台检索好；三是“并行化”，前面提到的并行检索能显著降低总延迟；四是“快慢双通道”，简单问题走快速通道，只有复杂问题才走Agentic流程。

我在实际项目中的做法是：前端先显示“正在检索……”，然后每完成一轮检索就更新一次进度，让用户知道系统在工作。最终答案也是流式输出，先出结论，再出依据。这个体验设计虽然不降低实际延迟，但用户感知的等待时间短了很多。另外，对于高频问题，我会提前跑一遍Agentic流程，把答案缓存起来，用户问的时候直接返回，延迟降到毫秒级。

5.3 质量与效率的平衡点

没有万能的最优解，只有适合场景的平衡点。我的经验是：根据问题价值来分配资源。高价值问题（比如法律咨询、医疗诊断、金融分析）可以容忍更高的延迟和成本，走完整的Agentic流程；低价值问题（比如闲聊、简单查询）走快速通道。这个分类可以用一个轻量级分类器实现，准确率不需要很高，80%左右就够了，剩下的20%误分类带来的损失可以接受。

另一个平衡点是“检索深度”。不是所有问题都需要检索10个文档。对于事实型问题，Top-3可能就够了；对于综述型问题，可能需要Top-20。Agent在评估阶段可以判断“当前信息是否足够”，如果足够就提前终止，不够再继续检索。这个动态调整的策略，比固定检索数量要高效得多。

最后说一个我踩过的坑：不要为了追求“完美答案”而无限增加检索轮次。用户要的是“快速得到一个还不错的答案”，而不是“等很久得到一个完美答案”。在大多数场景下，80分的答案在2秒内返回，比95分的答案在20秒内返回更有价值。这个取舍需要根据具体业务来定，但“快”通常比“完美”更重要。

6. 工业界落地的几个关键决策

6.1 框架选型：LangGraph还是自研

LangGraph是目前做Agentic RAG最流行的框架，它提供了状态图、循环、条件分支等原语，能比较方便地表达Agent的工作流。但它的学习曲线不低，而且抽象层次较高，调试时不容易看清底层发生了什么。我在小规模项目里用LangGraph快速验证想法，但在大规模生产环境里倾向于自研轻量级状态机。

自研的好处是可控性强，每个环节的输入输出都清晰可见，排查问题容易。坏处是要自己处理并发、重试、超时、状态持久化这些工程细节。我的建议是：如果团队有较强的工程能力，自研一个简单的状态机（几百行代码）比用框架更靠谱；如果团队偏算法背景，工程能力弱，用LangGraph能省不少事。

6.2 评估体系：怎么知道Agent做得好不好

Agentic RAG的评估比传统RAG复杂得多，因为它有多轮交互和中间状态。不能只看最终答案对不对，还要看检索路径是否合理、证据是否充分、有没有不必要的检索轮次。我通常从四个维度评估：答案准确性（最终答案是否正确）、证据充分性（答案是否有足够证据支持）、检索效率（用了多少轮、多少Token）、路径合理性（检索策略是否符合人类专家的思路）。

评估数据的构建也很关键。人工标注成本高，可以用“LLM-as-Judge”做初步筛选，再人工复核。具体做法是：让一个强模型根据标准给Agent的输出打分，然后人工检查打分是否合理。这个混合评估方式能在保证质量的同时控制成本。另外，要建立“回归测试集”，每次修改Prompt或流程后都跑一遍，确保没有引入退化。

6.3 常见问题速查表

6.4 一个实际案例的复盘

去年我参与了一个企业知识库Agent的项目，目标是让员工能用自然语言查询内部规章制度、技术文档和项目历史。初期版本用传统RAG，准确率只有60%左右，主要问题是多跳问题和时效性问题。后来改成Agentic RAG，加入了查询改写、多路召回、时间衰减和证据核验，准确率提升到85%以上。

但代价是平均延迟从1.5秒涨到6秒，Token成本涨了4倍。为了控制成本，我们做了三件事：一是加了复杂度分类器，简单问题走快速通道，只有30%的请求走Agentic流程；二是对高频问题做了答案缓存，缓存命中率40%；三是把规划和评估模型换成了轻量级模型。最终平均延迟降到3秒，成本只比传统RAG高1.5倍，而准确率保持在83%左右。这个平衡点是我们和业务方反复沟通后确定的，核心原则是“用户能接受的延迟内，尽可能提高准确率”。

这个项目让我最深的体会是：Agentic RAG的落地不是技术问题，而是取舍问题。每个环节都有优化空间，但资源有限，必须根据业务价值来分配。不要追求技术上的“完美”，要追求业务上的“够用”。