企业官网建设流程全解析

做 Agent 有一阵子之后，我最大的感受是：模型本身的能力差距，远没有知识接入方式的差距来得致命。一个再聪明的模型，如果只能靠训练时固化下来的参数知识回答业务问题，那它在真实场景里就是一个礼貌的“幻觉制造机”。这也是我今天想把 RAG（Retrieval-Augmented Generation，检索增强生成）单独拿出来聊的原因。作为“走进 AI Agent”系列的第四篇，本文不再讲 Agent 的骨架和工具调用，而是聚焦知识获取管道——也就是 RAG 基础。无论你是要做知识库问答、企业内部智能助手，还是想把 Agent 接进垂直行业流程，RAG 都是绕不开的第一步。这篇我尽量少讲抽象概念，多讲落地逻辑、选型思路和排障经验，适合正在或者准备从零搭建 Agent 的读者。

1. 为什么 Agent 的“骨架”里必须塞进一条知识获取通道

1.1 三个知识来源：参数知识、上下文知识、外部知识

从落地视角看，一个 LLM 驱动的 Agent 能利用的知识大致有三类，搞混它们的边界是很多项目跑偏的起点。

第一类是参数知识，也就是模型在预训练阶段学进权重里的东西。这类知识的优点是覆盖面广，但问题也很明显：它有截止日期。模型训练完的那一刻，它的世界就定格了，之后发生的事、你公司内部的新政策、某个产品的实时价格，它一概不知道。第二类是上下文知识，也就是通过提示词、对话历史和缓存信息临时塞给模型的内容。它的优势是灵活，可以随时改，但受上下文窗口限制，不能无限塞，而且塞进去的东西如果没有经过筛选，反而会把模型带到沟里。第三类才是本文的主角——外部知识，通过检索、工具调用等手段在推理时动态获取的知识。RAG 就是这类知识最典型、也最成熟的实现方式。

参数知识负责“常识和语言能力”，上下文知识负责“当次的对话状态”，外部知识负责“事实和规则”，三者的定位完全不同。如果你试图用上下文知识硬扛所有业务信息，成本会迅速失控；如果你什么都不做，只依赖参数知识，那 Agent 的下限就是一本过期的百科全书。

1.2 RAG 解决的两个核心痛点：知识截止与业务信息孤岛

我在刚开始做 Agent 项目时，犯过一个很典型的错误：直接把公司内部的售后政策文档拼进 Prompt，然后让模型回答。文档不长的时候效果还可以，但一旦文档变多、问题变杂，要么上下文塞不下，要么模型开始胡乱组合不同文档里的内容，输出一些看似合理但完全不存在的规定。

RAG 解决的是两个层面上的问题。第一个是知识截止问题。模型训练完之后，它不知道 2025 年之后发生了什么，也不知道你们系统里刚刚更新的库存数据。RAG 可以在每次请求时去外部数据源里找回最新的信息，让答案跟现实对齐。第二个是业务信息孤岛问题。大多数企业的核心知识根本不在公开语料里：产品参数在 ERP 里，售后政策在内部 Wiki 里，技术方案在历史工单里。这些数据如果不去做索引和检索，模型再聪明也无从谈起。

有人会问，那为什么不直接微调？我的经验是：微调和 RAG 不是替代关系。微调更适合改变模型的“行为风格”或者“输出格式”，而 RAG 更擅长给模型“补充事实”。如果你今天有一批新知识，明天可能又变，后天还在更新，那 RAG 明显更合适，因为不用每次变化都重新训练。反过来，如果你需要模型按照某个固定口吻、固定结构输出，光靠 RAG 是不够的，微调或精调提示词更直接。大多数项目的最优组合是：用 RAG 解决知识新鲜度和覆盖面，用 Prompt 设计解决行为约束，必要的时候再考虑微调。

1.3 知识获取管道和普通 API 调用相比特殊在哪里

“管道”这个词值得拆开讲。RAG 不是一个简单的“查数据库再填进 Prompt”的动作，它是一条多阶段的链路：从原始文档的清洗、切分、向量化，到索引存储，再到查询时的召回、重排、合成。每个环节都会影响最终答案的质量，而且环节之间是连锁反应。

打个比方，知识获取管道很像一个自来水系统：文档加工是水源净化，向量索引是蓄水池和管网，查询召回是水龙头，重排和合成是终端调温。你只换一个好水龙头，但如果上游的水源是一池脏水，出来的水照样不能喝。这条管道之所以要单独作为一个模块来设计，就是因为 Agent 的能力上限，往往不是模型决定的，而是知识管道的通量和水质决定的。

理解了这一点，我们就可以往下拆管道本身了。

2. RAG 三段式管道拆解：入库、召回、合成不是三个模块，是一套取舍

2.1 入库阶段的隐藏工作量：切分粒度与元数据设计

很多人把 RAG 的第一步理解为“把文档丢给向量数据库”，其实没那么简单。入库阶段有三个活儿最花时间：文档清洗、切分、元数据标注。

文档清洗经常被跳过，但它恰恰决定了后续所有环节的质量下限。比如 PDF 转出来的文本经常带着多余换行、页眉页脚、乱码字符，如果不做清理，切分出来的文本块会非常脏，检索时匹配到的内容也往往是“形似而神不似”。我通常的做法是：先做统一格式转换，再用正则或规则把页眉页脚、重复标题、无意义符号去掉，必要时对表格类型的内容做结构还原，而不是直接当成纯文本处理。

切分是入库阶段里最影响效果的一步。切分粒度过大，一个块里混了多个主题，召回时容易带进无关内容；切分粒度过小，语义不完整，模型拿到的是半句话，根本没法理解。常用的做法是按固定字符数切分，比如 512 或 1024 个字符，配合一定的重叠率。但更建议在固定长度基础上结合“语义断点”，也就是按段落、标题层级来做边界检测，避免在句子中间硬切。

元数据设计是很多人忽略的隐藏变量。简单说，你要为每个文本块记录它来自哪篇文章、哪个章节、什么文档类型、更新时间等字段。这些元数据在后期可以做候选过滤，比如“只检索 2025 年之后的政策文档”“只检索产品库里的规格参数”，可以大幅减少无关召回。没有元数据的 RAG，就像没有目录的档案库，你只能靠全文搜索硬找。

2.2 召回阶段的取舍：向量相似度为什么还要配关键词检索

召回阶段最常见的实现是向量检索，但只靠向量检索远远不够。向量检索的思路是把文本映射到高维语义空间，然后通过余弦相似度等指标找到语义相近的块。它擅长处理“意思相近但表述不同”的查询，比如用户问“电脑老是卡怎么办”，能匹配到“设备运行缓慢的排查方案”这类块。

但向量检索有几个明显的弱点。第一，对专有名词和编号类信息不敏感。比如产品型号“AC-3200B”，如果向量索引里没有完全对应的 token，相似度可能被拉得很低，而一个简单的字符串匹配反而能精准命中。第二，对数字、公式、代码片段等精确信息，向量检索往往会给出“差不多但不对”的结果，这在业务场景里非常致命。第三，向量模型本身有语言和领域偏向，在中文业务语料上，通用向量模型的表现可能达不到预期。

所以我会在召回阶段引入混合检索：向量检索负责广度，关键词检索（比如 BM25 或 Elasticsearch 的全文检索）负责精确匹配。两者各自召回一批候选，再做融合排序。融合的办法有很多，简单的是分数加权归一化，进阶的是用 RRF（Reciprocal Rank Fusion）这类排序融合算法。无论用哪种，本质上都是对“语义相关性”和“字面匹配度”做一次取舍。你很难说哪条路绝对正确，正确与否取决于你的业务知识长什么样。

2.3 合成阶段的重排与上下文压缩

召回结束之后，合成阶段不是简单地“把候选块拼进 Prompt”就完了。候选块通常是十个八个，但上下文窗口有限，且不是每个候选都有价值。这时候一个容易被低估的组件就上场了：重排器（Reranker）。

重排器的思路是，先用向量检索和关键词检索拉回一个较宽的候选集，再用一个更精细的模型对候选做相关性打分。常见做法是用交叉编码器模型，把查询和候选块拼在一起输入模型，得到一个更精准的相关性分数。为什么需要这一步？因为向量检索的分数通常是粗粒度的，它可能把“提到同一个词但语义方向相反”的文本也打高分，而重排器能更细地判断候选到底有没有回应查询的意图。我自己的经验是，加上一个好的重排器之后，答案质量的提升往往比换一个更强的 LLM 还明显。

除此之外，合成阶段还要做上下文压缩。也就是说，不要把十个候选原封不动塞进去，而是提取每个候选里和查询最相关的片段，甚至做一些摘要。上下文压缩的好处是白：减少噪声，降低模型被无关信息带偏的概率，也可以节省 token 成本。最后再把压缩后的上下文、用户问题和指令组装成最终的 Prompt。到这里，基础 RAG 的链路才算真正跑通。

3. 从零落地 RAG 基础管道：切分参数、向量模型与混合检索的实操记录

3.1 切分操作的三个翻车参数：块大小、重叠率、跨章节切分

我原来以为切分只需要设一个固定长度，后来在真实数据上反复测，才意识到里面全是坑。

第一个坑是块大小。块大小直接影响召回的精度和上下文利用率。512 个字符的块比较适合主题相对独立的文档，1024 个字符的块更适合内容密度高、上下文依赖强的技术文档。没有一个绝对值，我一般会准备一组样本问题，分别用不同块大小跑一遍召回命中率，用数据说话。第二个坑是重叠率。重叠率是对“切分边界准确性”的补偿。如果完全不设重叠，一个完整段落可能被拦腰切成两半，查询时只能召回其中一半，答案自然残缺。我的经验是重叠率放在 10% 到 20% 之间，既不重复冗余，又能保住语义边界。第三个坑最隐蔽：跨章节切分。如果直接按固定长度切，可能上一章的结尾和下一章的开头被拼在一起，形成语义混乱的“缝合块”。更好的做法是先把文档按标题、段落结构切出父块，再在父块内部做细粒度切分，让每个块都携带章节上下文。

3.2 嵌入模型选型的两个标准：语言覆盖与维度开销

选嵌入模型时，很多人只看榜单分数，忽略了两个实际指标。

第一个是语言覆盖。英文语料上效果好的模型，拿到中文业务文档上可能一塌糊涂。我会优先选择针对中文优化过的嵌入模型，比如 BGE 系列或者其他在中文语料上有专门训练的模型。如果项目的语料是中英混杂，还要特别留意模型在中英混合文本上的表现，而不是只看单一语言的基准分数。第二个是向量维度带来的存储和检索开销。嵌入向量的维度越高，理论上表达能力越强，但存储成本和检索延迟也会上升。对一个几十万文档规模的项目来说，维度翻倍可能意味着内存和磁盘开销的翻倍。我一般会结合工程条件选一个折中方案，必要时用降维或者量化手段来压规模。

选型上还有一个建议：不要频繁切换嵌入模型，因为切模型意味着整个索引库要重建。所以前期可以多花一点时间做基准测试，确定之后尽量稳定使用，后续的知识更新走增量入库就好了。

3.3 重排器在中文业务场景下的作用被低估了

我在最初搭建 RAG 时，没有上重排器，理由是“向量检索已经够用”。后来被几个案例教育了。

典型的情况是：用户问“你们对公转账的到账时间是多少”，向量检索召回的候选里，有两三块都提到了转账，但一块讲的是对公转账到账时间，另一块讲的是个人转账限额，还有一块讲的是对公转账手续费。从向量相似度看，它们的分数可能差得不大，但真正能回答问题的只有第一块。重排器做的工作，就是把这种“宽泛相关”和“精准命中”区分开来。在我用过的方案里，轻量级交叉编码器重排器就能带来肉眼可见的效果提升。

工程上，重排器一定要放在“最终合成”之前，操作步骤是：先召回一个较大的候选集（比如 20 到 50 条），用重排器打分后取 Top 3 到 5 条，再交给 LLM 生成答案。注意，这里的候选集数量不能太小，否则重排器没有足够的“筛选空间”，但也不能太大，否则重排本身的耗时会上来，影响响应延迟。

3.4 一个可以照搬的基础流程参考

下面是我在项目里常用的 RAG 基础流程，不绑定某个具体框架，任何工具栈都可以照着落：

1. 文档解析与清洗：把 PDF、Word、Markdown、HTML 统一转成纯文本，去掉页眉页脚、重复模板，识别并尽量还原表格结构。
2. 结构化切分：先按文档标题建立父块，再按段落或固定长度切子块，保留章节路径作为元数据。
3. 嵌入与入库：调用嵌入模型生成向量，连同文本块和元数据一起写入向量库，同时建立关键词倒排索引。
4. 查询改写（可选）：用户问题如果太口语化，可以做轻量改写，比如“最近出的那款手机怎么样”改写为更明确的检索语句，提升召回精度。
5. 混合召回：向量检索加关键词检索，各返回一批候选，做分数融合，取 Top N。
6. 重排：用交叉编码器对候选重新打分，保留最相关的少量文本块。
7. 上下文拼装与生成：整理上下文、用户问题、指令模板，交给 LLM 生成最终答案。

这套流程跑通之后，你的 Agent 才算真正具备了一条稳定的知识获取管道。但只做到这一步，还不足以应对复杂一点的业务需求，所以接下来聊聊进阶变体。

4. 进阶视野：Agentic RAG、GraphRAG 与本体增强到底改了什么

4.1 Agentic RAG 的本质变化：从单次召回变成计划、验证、追问的循环

基础 RAG 的流程是“用户提问 → 检索 → 生成”，一次搞定。但实际业务里，很多问题不是一个召回动作能解决的。比如“对比一下 A 产品和 B 产品上个季度的退换货率，并给出改进建议”，这种问题需要先定位“业绩数据来源”，再分别获取 A、B 产品的退换货率，然后可能还要再找退换货的细分类目，最后才能综合分析。

Agentic RAG 就是把“检索”这件事从单次动作升级为 Agent 循环。它把用户问题当成一个任务，由 Agent 自行拆解成若干子问题，按需调用不同的检索工具，拿到结果后判断信息是否足够，不够就继续检索或追问，最后再合成答案。这个过程中，“检索什么、什么时候检索、检索完要不要再检索”是由 Agent 动态决定的，而不是预先写死的管道。

这种模式非常适合问题复杂、依赖多轮信息拼装的场景。但代价也很明显：延迟更高，链路更长，出错的可能性也更多。所以我通常的建议是：能用基础 RAG 解决的问题，不要一上来就上 Agentic RAG，等你的基础管道质量足够稳定，再逐步把复杂问题路由到 Agent 循环里去。

4.2 GraphRAG 补的是文本块之间的“关系盲区”

基础 RAG 的最小单元是文本块，但很多知识藏在文本块之间的关系里。比如公司组织架构、产品组件结构、项目依赖关系，这些知识分散在多个文档里，单纯按文本块做向量召回，很难把它们“串联”起来。

GraphRAG 的做法是：在入库阶段，先通过 LLM 或规则抽取文档中的实体和关系，构建一张知识图谱；检索时，不仅找语义相似的文本块，还会沿着图谱的关系路径去扩展相关信息。比如用户问“这个功能改动会影响哪些模块”，单纯向量检索只能返回文档里直接提到相关模块的段落，而图谱检索可以把“A 模块引用了 B 模块、B 模块依赖 C 模块”这样的链条拉出来，给出的答案会更完整。

GraphRAG 的缺点也很明显：图谱构建成本高、实体抽取质量不稳定、更新维护复杂。它适合知识之间的关系性很强的场景，比如研发文档、产品架构说明书、复杂流程规范。如果只是做简单问答，先不急着上图谱，把混合检索做扎实更划算。

4.3 本体增强：从“语义相似”走向“概念对齐”

本体（Ontology）增强是我最近在试的方向，它解决的是“拼接式错误”的问题。业务领域里有很多同义词和上下位概念，比如“设备”“机器”“硬件”在用户嘴里可能是一回事，但在文档里它们的表述完全不同。如果只靠文本向量相似度，模型可能把“设备故障”理解成“机器报错”去找答案，结果找回一堆边缘内容。

本体的思路，是先把领域里的核心概念、概念间的层级关系和同义关系显式地定义出来，然后在检索时用这些概念层去约束和扩展关键词。举个例子，用户问“硬件兼容性”，本体层可以自动扩展出“设备兼容性”“驱动支持”“接口标准”等关联概念，再去检索，就不会只盯着字面词。

本体增强的落地成本不低，因为它需要有人梳理领域知识，而且本体本身也需要持续维护。但如果你做的 Agent 要深耕某个垂直行业，本体层的收益会随着知识库规模的扩大越来越明显。可以说，它是缓解“知识割裂”问题的一套长期解法。

4.4 Skill 与 RAG 的结合方式：检索结果作为工具参数

最后谈谈热词里反复出现的“Skill 怎么和 RAG 结合”。在 Agent 的架构里，Skill 一般指的是可执行的功能单元，它包含触发条件、执行逻辑和输出格式。Skill 和 RAG 结合的正确方式，不是把 RAG 做成一个独立的技能，而是把 RAG 检索结果作为 Skill 执行时的输入参数。

举个例子，我有一个“政策问答技能”。当用户问到某个报销规则时，Agent 路由到这个技能，技能里先触发一次 RAG 检索，拿到相关规则文档，再结合用户的具体报销场景，走一个规则校验逻辑，最后输出是否合规、需要哪些材料。在这个过程中，RAG 提供的是知识和依据，Skill 提供的是业务规则和动作。两者分离又协作，是 Agent 工程里一个很值得记住的模式。

5. 质量瓶颈与一套可复用的排障链路

5.1 五个典型症状及根因对照

RAG 跑起来容易，跑得稳很难。下面是我在多次排障中总结的常见症状和它们背后的根因，你可以把这当一张快速诊断表用。

这张表不一定覆盖所有情况，但它能帮你快速定位问题到底出在“入库、召回、重排、生成”的哪一段，而不是一上来就换模型。

5.2 一条实用的评估链路：从召回命中率到答案准确性

很多项目失败不是因为没有代码，而是因为没有评估。没有评估，你就无法知道一个改动是变好了还是变坏了。我会建议从最简单的评估体系开始：准备 20 到 50 条有代表性的业务问题，为每个问题人工标注出正确答案对应的文本块编号，然后可以做两类评估。

第一类评估是召回命中率（Hit Rate）。把问题喂给检索管道，检查 Top 5 或 Top 10 候选中是否包含标注的黄金文本块。如果 Hit Rate 偏低，优先优化切分、嵌入模型和混合检索策略。第二类评估是答案质量评估。把问题、召回文本和模型生成答案放在一起，人工或使用更强的模型当裁判，按相关性、完整性、事实准确性三个维度打分。注意，答案质量评估一定要考虑来源引用，RAG 的答案必须能被回溯到具体的文本块，否则就是无源之水。

我通常的做法是，把这两类评估固化成一个脚本，每次修改任何组件之后都跑一遍，记录对比结果。迭代几个版本后你会发现，大多数“模型不行”的抱怨，最后都指向了管道里的某一个具体环节。

5.3 中文语料的特殊问题：编码、分词与表格型知识

中文场景里，RAG 的几个特殊坑值得单独说。

一是编码和乱码问题。从 PDF 转出来的中文经常会丢空格、出现全角半角混乱、断行错误。这些问题对向量检索影响尤其大，因为模型对空格和换行的处理方式很敏感。我会在清洗阶段把全角符号统一转半角、把行内多余换行合并、修复常见乱码字符。

二是分词与停用词。英文按空格分词，中文没有天然分隔。虽然向量模型通常不依赖显式分词，但关键词检索（BM25）对中文分词质量很敏感。建议选一个对中文支持好的分词器，同时谨慎处理停用词——业务场景里的很多术语可能被误判成停用词，那就毁灭性了。

三是表格型知识。很多业务知识是以表格形式存在的，比如报价表、参数对照表、库存状态表。如果直接把表格转成纯文本切分，检索时经常只拿到零散的单元格，模型根本拼不出完整上下文。我的经验是：尽量在文档清洗阶段把表格转成结构化的 Markdown 或 HTML 表格，在切分时以“整表”或“表头+若干行”为单位保留，元数据里标记表格类型，检索结果里再接上表头信息。这一步做好，表格问答的正确率会大幅上升。

6. 写在最后：RAG 是“知识获取管道”，但不等于 Agent 的全部记忆

6.1 RAG 与记忆机制的分工

最后想说一个很容易被混淆的点：RAG 不等于 Agent 的全部记忆。Agent 里通常还有一层“记忆机制”，用来记录对话历史、用户偏好、短期状态等。RAG 管的则是长期的、事实性的、来自外部语料的知识。

两者如何配合？我的做法是：路由层先判断用户问题是“事实型”还是“状态型”。事实型问题走 RAG 管道，比如“公司年假政策是什么”；状态型问题走记忆层，比如“我刚才提到过的预算上限是多少”。两者也可以串联，比如先查记忆确认用户身份，再查 RAG 确认该身份适用的政策版本。把这两层的职责分清楚，Agent 才不会在复杂对话里“东拼西凑”。

6.2 我会把 RAG 管道升级成评估反馈回路

如果现在让我给一个刚搭完基础 RAG 的人提建议，除了把管道跑通之外，我最想说的是：给管道接上日志和评估反馈回路。每一次检索的候选、重排分数、最终引用的文本块、用户的后续反馈，都值得记录下来。这些数据的价值非常大，它们能告诉你哪些问题总是召回失败、哪些知识库文档长期没有被命中、哪些问题用户反复重问。

我之前很长一段时间只关注“答案好不好看”，很少去问“答案从哪里来”。后来把日志和评估体系补上之后，才发现很多“效果不稳定”的抱怨，其实是因为同一个问题在两次检索里命中了完全不同的文本块。只有当你把知识管道的每一段都纳入可观测范围，Agent 的质量才能从“碰运气”变成“可迭代”。

RAG 基础只是知识获取管道的起点。等你的基础管道稳定了，后续的 Agentic RAG、GraphRAG、本体增强才有意义。这个系列后面我还会继续写知识管道进阶的方向，包括评估体系完整落地、Agentic RAG 的多轮迭代案例，以及怎么把知识管道的日志变成下一个版本训练的燃料。如果你也在做 Agent，建议先别急着追新概念，把你的切分、召回、重排、评估这四件事跑扎实，再去谈进阶。