企业官网建设流程全解析

1. Agent 场景下 RAG 的定位为什么变了

过去两年，RAG 这个词被讲得太多，以至于很多人一听到就默认是"向量库 + 检索 + 拼上下文"那套老三样。但真正把 RAG 接进 Agent 系统之后，你会发现它的角色发生了根本性变化：它不再是"给大模型喂资料"的辅助模块，而是 Agent 感知外部世界、做决策、执行动作的核心基础设施之一。

这个变化不是概念炒作，而是工程上被逼出来的。传统 RAG 的调用链路是线性的：用户提问 → 检索 → 拼接 → 生成 → 返回。整个流程里，检索是一次性的，模型是被动的。但 Agent 不一样，Agent 会自己决定"我现在需不需要查资料""我要查什么""查到的结果够不够""不够我再换个角度查"。也就是说，检索从"被动触发"变成了"主动决策"，从"单轮"变成了"多轮"，从"固定流程"变成了"动态编排"。

这就带来一个很现实的问题：你原来那套为问答场景设计的 RAG 方案，直接搬到 Agent 里，大概率会翻车。翻车的表现通常有三种：一是检索延迟拖垮整个 Agent 的响应速度，因为 Agent 一轮任务可能触发五六次检索；二是检索结果质量不稳定，Agent 拿到模糊甚至错误的信息后，会沿着错误方向继续推理，越走越偏；三是上下文窗口被检索内容塞满，导致 Agent 的推理能力反而下降。

所以这篇文章想解决的问题很明确：在 Agent 时代，RAG 到底该怎么选、怎么搭、怎么调。我会从架构选型、检索策略、知识库组织、性能优化、常见坑这几个维度，把我在实际项目里踩过的经验和验证过的方案讲清楚。不管你是刚接触 RAG 的新手，还是已经在做 Agent 项目的开发者，都能从里面找到可以直接抄作业的部分。

提示：本文讨论的 RAG 方案适用于企业知识库、文档问答、智能客服、代码助手、数据分析 Agent 等场景，不涉及任何敏感领域。

2. 先搞清楚你的 Agent 到底需要哪种 RAG

选型之前必须先做一件事：明确你的 Agent 任务类型。不同类型的 Agent，对 RAG 的需求差异极大，用错方案比不用还糟糕。

2.1 三类 Agent 任务对应的 RAG 需求

我把常见的 Agent + RAG 组合分成三类，你可以对号入座。

第一类是事实查询型 Agent。典型场景是智能客服、政策问答、产品手册查询。这类 Agent 的核心诉求是"准确"，检索到的内容必须和用户问题高度相关，宁可少答也不能答错。对这类 Agent，RAG 的关键指标是召回准确率和答案忠实度，检索策略上更适合用混合检索（向量 + 关键词）+ 重排序。

第二类是任务执行型 Agent。比如帮你操作数据库、调用 API、生成报表的 Agent。这类 Agent 需要 RAG 提供的是"操作知识"和"参数说明"，比如某个接口怎么调、某个字段什么含义。它对检索速度要求高，因为 Agent 在执行过程中会频繁查询，而且检索结果需要结构化，最好能直接解析成参数。

第三类是推理分析型 Agent。比如做竞品分析、财报解读、技术调研的 Agent。这类 Agent 需要 RAG 提供的是"多源、多跳、有关联关系"的知识。普通向量检索往往不够用，需要引入 GraphRAG 或者本体（Ontology）结构，把实体之间的关系也检索出来。

下面这张表可以帮你快速判断：

2.2 为什么不能一套方案打天下

我见过太多项目，上来就搭一个向量库，把所有文档切块丢进去，然后指望它什么都能查。结果就是：简单问题答得还行，稍微复杂一点就开始胡编。原因很简单，向量检索的本质是语义相似度匹配，它擅长"找相似"，不擅长"找关系""找精确值""找多跳路径"。

举个例子，用户问"我们公司去年 Q3 的营收比 Q2 增长了多少"，这个问题需要的是：先找到 Q3 的数据，再找到 Q2 的数据，然后做减法。向量检索可能只能召回一段包含"Q3 营收"的文本，Q2 的数据如果没被召回，Agent 就会瞎猜。这种场景下，你需要的是结构化查询或者多跳检索，而不是单纯的向量相似度。

所以选型的第一步，不是选工具，而是选策略。工具是策略的载体，策略错了，工具再好也白搭。

2.3 一个实用的判断流程

我在实际项目里总结了一个简单的判断流程，你可以直接套用：

1. 先问：用户的问题是不是"单跳事实型"？如果是，向量检索 + 重排序基本够用。
2. 再问：问题里有没有"比较""计算""关联"这类词？如果有，考虑结构化检索或多跳检索。
3. 再问：Agent 会不会在一轮任务里多次检索？如果会，必须做检索缓存和延迟优化。
4. 最后问：知识库里的内容是不是高度结构化（表格、图谱、代码）？如果是，别硬塞向量库，用对应的结构化方案。

这个流程看起来简单，但能帮你避开 80% 的选型错误。

3. 检索策略的取舍：向量、关键词、图谱到底怎么配

确定了 Agent 类型之后，接下来就是具体的检索策略设计。这部分是 RAG 的核心，也是最容易出问题的地方。

3.1 向量检索的边界在哪里

向量检索的原理是把文本映射成高维向量，然后通过余弦相似度找最接近的。它的优势是能理解语义，比如用户问"怎么退款"，文档里写的是"如何申请退货"，向量检索能匹配上，关键词检索就不行。

但向量检索有三个明显的边界。第一，它对精确匹配不敏感。比如用户问"订单号 12345 的状态"，向量检索可能召回一堆讲订单状态的文档，但就是找不到那个具体订单号。第二，它对数值和表格不友好。表格里的数据被切成文本后，语义信息大量丢失。第三，它的召回质量高度依赖 embedding 模型和切块策略，调不好就是"看起来能用，实际一塌糊涂"。

我的经验是：向量检索适合处理"自然语言描述型"的知识，比如产品说明、政策条款、操作指南。对于编号、日期、金额、代码这类精确信息，一定要配合关键词检索或结构化查询。

3.2 混合检索为什么是当前最稳的方案

混合检索就是把向量检索和关键词检索（通常是 BM25）的结果融合起来，取长补短。它的逻辑是：向量负责语义召回，关键词负责精确召回，两者互补。

具体怎么做？常见的有两种融合方式。一种是加权求和，给向量得分和关键词得分各分配一个权重，然后加总排序。另一种是倒数排名融合（RRF），不看具体得分，只看排名，把两个列表的排名做融合。RRF 的好处是不用调权重，鲁棒性更好，我一般优先推荐。

实际配置上，我通常这样设：向量检索召回 top 20，关键词检索召回 top 20，融合后取 top 10 送重排序，重排序后取 top 3 到 5 条拼进上下文。这个参数不是固定的，要根据你的知识库规模和 Agent 的上下文预算来调。

注意：混合检索的收益在知识库越大、问题越多样时越明显。如果你的知识库只有几十篇文档，单纯向量检索可能就够了，上混合检索反而增加复杂度。

3.3 GraphRAG 和本体 RAG 适合什么场景

GraphRAG 这两年被讨论得很多，它的核心思路是把知识抽成实体和关系，构建成图，检索时不仅找相关文本，还找实体之间的关联路径。本体 RAG 类似，但更强调预先定义好的本体结构（比如"产品-属性-值"这种 schema）。

它们适合什么场景？我总结下来是三种：一是需要多跳推理的，比如"A 公司的 CEO 之前在哪家公司任职"；二是需要全局摘要的，比如"这份报告的主要结论有哪些"；三是知识之间有强关联的，比如医疗、法律、金融领域的知识图谱。

但 GraphRAG 的代价也很明显：构建成本高，需要做实体抽取和关系抽取，抽取质量直接决定效果；更新维护麻烦，知识一变图就要重建；检索延迟通常比向量检索高。所以我的建议是：除非你的场景确实需要多跳和关联，否则别一上来就上 GraphRAG。先用混合检索跑通，遇到瓶颈再考虑升级。

3.4 检索策略对比表

4. 知识库组织：切块、索引、更新的实操细节

检索策略定了，接下来是知识库本身怎么组织。这部分看起来是"脏活累活"，但实际上决定了 RAG 效果的上限。检索策略再好，知识库组织得烂，也救不回来。

4.1 切块策略：不是越小越好

切块（chunking）是 RAG 里最容易被忽视、又最影响效果的环节。很多人默认按固定字数切，比如每 500 字一块，结果切出来的块要么语义不完整，要么包含多个主题。

我的经验是：切块要跟着文档结构走。如果文档有标题层级，就按标题切，每个小节一块；如果文档是问答对，就按问答对切；如果文档是代码，就按函数或类切。固定字数切块只适合那种没有明显结构的纯文本。

块的大小也有讲究。太小，语义不完整，检索出来断章取义；太大，包含噪声多，检索精度下降。我一般把块控制在 200 到 500 字之间，同时保留一定的重叠（overlap），通常是块大小的 10% 到 20%，避免边界信息丢失。

还有一个技巧：给每个块加上"上下文头"，比如所属文档标题、章节路径。这样即使块本身语义不完整，检索时也能通过上下文头补全信息。

4.2 元数据设计：让检索多一层过滤

元数据是提升检索精度的利器。所谓元数据，就是给每个块附加的结构化信息，比如来源文档、创建时间、文档类型、所属部门、权限等级。

有了元数据，检索时就可以先过滤再检索。比如用户问"最新的退款政策"，你可以先用元数据过滤出"政策类 + 最近半年"的文档，再在里面做向量检索。这样既提升了精度，又减少了检索范围，速度也更快。

元数据设计的原则是：只加真正会用到的字段。加太多字段，维护成本高，而且很多字段根本用不上。我通常至少会加这几个：来源、时间、类型、权限。权限这个尤其重要，Agent 如果接入了多部门知识库，必须做权限隔离，否则会泄露信息。

4.3 增量更新：别每次都全量重建

知识库不是一次建好就完事的，它会不断更新。如果每次更新都全量重建索引，成本高、耗时长，而且期间服务不可用。

正确的做法是做增量更新。具体来说，给每个文档记录一个版本号或更新时间戳，更新时只处理变化的文档，删除旧索引，插入新索引。向量库一般支持按 ID 删除和插入，所以增量更新是可行的。

但增量更新有个坑：如果文档的切块策略变了，或者 embedding 模型换了，那就必须全量重建，因为新旧向量不在同一个语义空间里，混在一起检索会出问题。所以每次改切块策略或换模型，都要规划好重建窗口。

4.4 知识库组织的常见错误

我列几个我见过最多的错误，你可以对照检查：

• 切块按固定字数，不考虑文档结构，导致语义断裂。
• 不加元数据，检索时无法过滤，精度上不去。
• 全量重建太频繁，服务不稳定。
• 不做去重，同一内容多个版本都在库里，检索结果重复。
• 不做质量过滤，把 OCR 错误、乱码、无关内容也塞进库。

这些问题看起来小，但每一个都会实打实地拉低 RAG 效果。

5. Agent 场景下的性能与延迟优化

Agent 和普通问答最大的区别之一，就是它会频繁调用检索。一轮任务下来，检索可能被触发好几次。如果每次检索都要几百毫秒甚至几秒，整个 Agent 的体验就会非常差。所以性能优化在 Agent 场景下不是可选项，是必选项。

5.1 检索缓存：最直接有效的优化

缓存是性价比最高的优化手段。Agent 在任务执行过程中，经常会重复查询相似甚至相同的内容。比如它先查"退款流程"，过一会儿又查"退款需要多久"，这两个查询的检索结果高度重叠。

缓存的设计有两种粒度。一种是查询级缓存，把用户查询的 embedding 或查询文本作为 key，检索结果作为 value 缓存起来。另一种是块级缓存，把常用的块缓存在内存里，检索时优先从内存取。

查询级缓存要注意失效策略。如果知识库更新了，缓存必须失效，否则会返回旧结果。我一般给缓存设一个较短的 TTL（比如 5 到 10 分钟），同时监听知识库更新事件，更新时主动清缓存。

5.2 并行检索与预取

Agent 有时候会同时需要多个来源的信息。比如它要对比两个产品的参数，就需要分别检索两个产品的文档。这种情况下，串行检索会很慢，应该改成并行。

并行检索的实现不难，把多个检索请求同时发出去，等所有结果回来再合并。但要注意控制并发数，并发太高会打爆向量库或 embedding 服务。我一般把并发控制在 4 到 8 之间，根据后端承载能力调。

预取是另一个技巧。如果 Agent 的任务流程是可预测的，比如它一定会先查产品信息再查价格，那就可以在查产品信息的同时，提前把价格信息也检索出来。这样等 Agent 真正需要时，结果已经在缓存里了。

5.3 上下文预算管理

Agent 的上下文窗口是有限的，检索结果塞太多，会挤占推理空间。所以必须做上下文预算管理。

我的做法是：给检索结果分配一个固定的 token 预算，比如总窗口的 30%。然后在这个预算内，按相关性排序，优先放最相关的块。如果预算不够，就截断或摘要。

摘要是个好办法。对于长文档，可以先让模型生成一个摘要，检索时返回摘要而不是全文。这样既保留了关键信息，又节省了 token。但摘要会损失细节，所以适合那种"只需要大概了解"的场景，不适合需要精确引用的场景。

5.4 性能优化对照表

6. 踩坑实录：那些让我熬夜排查的 RAG 问题

这部分我讲几个真实踩过的坑，都是文档里不会写、但实际项目中一定会遇到的。

6.1 检索命中率忽高忽低

有一次上线后，发现检索命中率白天正常，晚上就掉得厉害。排查了半天，最后发现是 embedding 服务在高峰期被限流，导致部分查询的 embedding 质量下降，检索结果自然就差了。

这个坑的教训是：embedding 服务必须做监控和降级。监控要覆盖延迟、错误率、限流次数。降级方案可以是切换到备用模型，或者临时降级为关键词检索。千万别让 embedding 服务成为单点。

6.2 Agent 拿到错误信息后越走越偏

Agent 有个特点：它会基于检索结果继续推理。如果检索结果错了，它会沿着错误方向一路走下去，最后给出一个看起来很有道理、但完全错误的答案。

这个问题很难完全避免，但可以缓解。我的做法是：在 Agent 的提示词里明确要求它"对检索结果保持怀疑，如果多个来源冲突，要指出冲突而不是随便选一个"。另外，可以加一个"置信度检查"步骤，如果检索结果的相似度得分普遍偏低，就让 Agent 主动说"我不确定"，而不是硬答。

6.3 知识库更新后旧答案还在

这个坑很典型。知识库更新了，但用户还是收到旧答案。排查发现是缓存没失效，而且向量库里旧块没删干净。

解决方法是：更新流程必须包含"删旧 + 插新 + 清缓存"三步，缺一不可。而且要有校验机制，更新后随机抽几个查询验证结果是否更新。我一般会写一个自动化脚本，每次更新后跑一遍回归测试。

6.4 上下文被检索结果塞爆

有一次 Agent 突然开始胡言乱语，排查发现是检索返回了太多块，把上下文窗口塞满了，导致模型没有空间做推理。

这个问题的根源是检索返回的块数没有上限。解决方法是：给检索结果设一个硬上限，比如最多返回 5 个块，每个块最多 500 token。超过就截断。同时监控上下文的 token 占用，超过阈值就告警。

6.5 多轮检索时结果重复

Agent 多轮检索时，经常会召回相同的块，导致上下文里重复内容很多，浪费 token。

解决方法是在检索层做去重。可以按块 ID 去重，也可以按内容相似度去重。我一般用块 ID 去重，简单可靠。如果块 ID 不稳定，就用内容哈希去重。

7. 从零搭一个 Agent 可用的 RAG 的完整路径

讲了这么多原理和坑，最后给一个可落地的搭建路径。这套路径我在多个项目里验证过，适合大多数 Agent + RAG 场景。

7.1 环境与组件选型

组件选型上，我的建议是：

• 向量库：中小规模用 FAISS 或 Chroma，大规模用 Milvus 或 Qdrant。
• Embedding 模型：中文场景优先选中文优化过的模型，英文场景选通用模型。如果对延迟敏感，选小模型；如果对精度敏感，选大模型。
• 关键词检索：BM25 是标配，Elasticsearch 或 OpenSearch 都支持。
• 重排序：用 cross-encoder 类模型，效果比向量相似度好很多。
• 编排框架：LangChain、LlamaIndex 都可以，选你团队熟悉的。

选型的原则是：先用最简单的组件跑通，遇到瓶颈再换。别一上来就堆最复杂的架构，那样调试成本太高。

7.2 搭建步骤

1. 文档预处理：解析文档（PDF、Word、HTML 等），提取文本和结构信息。
2. 切块：按文档结构切块，加元数据和上下文头。
3. 向量化：用 embedding 模型把块转成向量，存入向量库。
4. 建关键词索引：把块存入 BM25 索引。
5. 实现混合检索：向量检索 + 关键词检索，用 RRF 融合。
6. 加重排序：对融合结果做重排序，取 top N。
7. 接入 Agent：把检索封装成 Agent 可调用的工具，支持多轮调用。
8. 加缓存和监控：查询缓存、延迟监控、命中率监控。
9. 回归测试：建一个测试集，每次更新后跑一遍。

7.3 上线后的持续优化

上线不是终点，是起点。持续优化要关注几个指标：检索命中率、答案忠实度、平均延迟、缓存命中率、上下文占用率。这些指标要建 dashboard，定期看。

优化的方向通常是：调切块策略、换 embedding 模型、调检索参数、加元数据过滤、优化缓存策略。每次只改一个变量，改完跑回归测试，确认有效再继续。

8. 一些个人体会

做 Agent + RAG 这几年，我最大的体会是：RAG 不是一个"装好就能用"的组件，它是一个需要持续调优的系统。同样的方案，在不同的知识库、不同的 Agent 任务上，效果可能差很多。所以别指望抄一套配置就万事大吉，一定要结合自己的场景去调。

另一个体会是：简单方案往往比复杂方案更稳。我见过太多项目，一上来就上 GraphRAG、上多路召回、上各种花哨的重排序，结果调都调不动。反而是那些老老实实用混合检索 + 重排序的项目，跑得最稳。复杂方案不是不能用，而是要在简单方案遇到瓶颈之后再上。

最后一个建议：一定要建测试集。没有测试集，你所有的优化都是盲调。测试集不用很大，几十到几百个问题就够，但要覆盖你的核心场景。每次改动都跑一遍，看指标是涨是跌。这个习惯能帮你省下大量排查时间。