企业官网建设流程全解析

我从 2025 年初开始带着团队从零搭建自己的 AI Agent，前面三篇分别聊了 Agent 的架构设计、规划模块和工具调用，一路踩了不少坑。这一篇想重点聊聊 Agent 的“知识获取管道”——也就是 RAG 基础。坦白讲，我第一次做 Agent 的时候，对知识库这块的想法非常简单：把文档扔进去，向量化，查出来拼给大模型，完事。真上了生产才发现，那条管道里的每一个环节——切分、索引、检索、重排、上下文组装——都会真实地影响 Agent 的最终回答质量。这一篇我会从“为什么 Agent 必须有一套稳定的知识获取管道”讲起，把 RAG 的完整链路拆解开，然后重点分享我们在实践里踩过最多的几个坑：分块策略怎么定、检索质量怎么调、RAG 和 Agent 的工具调用如何协同，以及最后怎么用指标来度量整条管道，而不是靠感觉调参。

适合正在从 0 到 1 搭建 AI Agent、准备给 Agent 接私有知识库的开发者。如果你已经能跑通一个最简单的“文档问答”Demo，但感觉效果不稳定、查不准、答不对，这篇文章应该能帮你定位到问题到底出在管道的哪一段。

1. LLM 的知识天花板：Agent 为什么要外挂知识管道

聊 RAG 之前，先把一个根本问题说清楚：大模型本身不是知识库，它是“语言推理引擎”。很多刚接触 Agent 的人，对模型有一个隐含的假设——越大的模型知道越多。这个直觉不能说错，但它掩盖了一个工程上的核心矛盾：模型的知识在训练完成的那一瞬间就冻结了，而你的业务知识、私有文档、实时数据是持续变化的。

举个例子，我们团队内部维护了一整套运维规范，里面记录了线上服务常见的故障场景、排查路径和封板约定。这些内容不会出现在任何公开语料里，也不可能指望 GPT 类模型靠“泛化能力”猜出来。如果 Agent 没有能力访问这套规范，它在处理“线上接口超时怎么处理”这类问题时，就只能给出通用建议，甚至编造不存在的操作步骤。这类“一本正经地胡说八道”在生产环境里是灾难级的。

知识获取管道就是来解决这个问题的。RAG（Retrieval-Augmented Generation，检索增强生成）的核心思路很简单：不强迫模型记住所有知识，而是给模型一把“随时查阅资料的钥匙”。当 Agent 需要回答某个具体问题时，先从外部知识源里把最相关的文档片段检索出来，再把原始文本作为上下文拼接进提示词，让模型基于检索结果而不是纯参数记忆来生成回答。

这个思路对应着一个非常现实的优势：知识更新成本极低。模型还是那个模型，但知识库里的文档可以随时增删改。业务部门更新了流程规范、产品上线了新的功能说明、运维沉淀了新的故障案例，你只需要把这些内容丢进知识管道，Agent 的可用知识就同步更新了。不需要重新训练，不需要微调，甚至不需要重启服务。

你从表格里能看到，RAG 不是哪一家公司的“黑盒产品”，它是一套由多个组件串联起来的工程管道。任何一个环节的缺陷，都会被下游放大。很多初学 RAG 的人问“为什么我的 RAG 效果这么差”，答案往往不在最后一个 LLM 调用上，而在这条管道的中上游。所以我会按照管道顺序，从切分策略开始一步一步往下讲。

2. 切分策略：知识库质量的第一个分水岭

我说一个可能有点反直觉的结论：在 RAG 管道里，最先决定效果上限的，既不是模型选得多强，也不是向量库多先进，而是文本切分。因为切分直接决定了检索单元的粒度——也就是 LLM 最终看到的那段“参考资料”到底长什么样。切得太碎，语义不完整；切得太粗，噪音太多还超出上下文窗口。这个度把握不好，后面所有环节都白搭。

2.1 按固定长度切分：最省事但最不推荐

最早我们做 Demo 时用的是最常见的固定长度切分：每 500 个 token 切一段，相邻段重叠 50。代码写起来很清爽：

from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "；", "，", " ", ""], ) chunks = text_splitter.split_text(long_document)

表面上看没问题，但实际效果很不稳定。RecursiveCharacterTextSplitter 的 separators 是按优先级依次尝试的，它的逻辑是先按段落分，不行再按句子分，再不行按逗号分。它保证的是“尽量在语义边界切开”，但并不能保证每块都语义完整。运维手册里经常有大段的代码块、命令行输出、表格，这些内容一旦被拦腰截断，检索时匹配到的片段就会莫名其妙。比如有一份故障处理 SOP，前一段讲“重启服务”，后一段讲“数据校验”，中间被切开了。Agent 检索“服务重启后需要做什么校验”，返回的片段只包含重启步骤，校验步骤被切到了下一个 chunk 里，模型的回答自然就残缺了。

这个方案最大的问题在于：它对文档结构一无所知。它不知道标题和正文的关系，不知道表格里的每一行是独立条目，不知道列表项之间是有逻辑顺序的。它眼里只有字符流。

2.2 按文档结构切分：把 Markdown 标题用起来

后来我们学乖了，开始尊重文档本身的语义结构。最常见的做法是在切分之前先识别文档的 Markdown 标题层级（对应 Word 里的一级标题、二级标题），以标题为边界来切分。LangChain 提供了MarkdownHeaderTextSplitter，对结构清晰的文档效果立竿见影：

from langchain.text_splitter import MarkdownHeaderTextSplitter headers_to_split_on = [ ("#", "H1"), ("##", "H2"), ("###", "H3"), ] splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on) chunks = splitter.split_text(markdown_document)

用这种方式切出来的每个片段，都会带上它的标题路径作为元数据。比如一条片段可能是：

{ "content": "如果 CPU 使用率持续超过 85% 超过 5 分钟，触发告警……", "metadata": { "H1": "故障处理手册", "H2": "性能问题", "H3": "CPU 高负载" } }

这个元数据价值非常大。检索召回时，我们可以把标题路径也拼进上下文，让模型知道它看到的这段内容出自哪个章节。实测下来，回答的条理性明显提升，模型不再“凭空猜测”上下文关系。类似地，PDF 文档可以使用unstructured或PyMuPDF先做版面解析，尽量保留标题与正文的层级，再做切分。Word 文档则可以先转成 Markdown 或 HTML 再按标题切分。

2.3 切分参数的工程经验值

不管是按固定 token 还是按结构切，chunk_size和chunk_overlap这两个参数都得根据你下游 LLM 的上下文窗口和你的文档特征一起调。

• 面对短文本为主的FAQ：一条问答就是完整语义单元，直接按条目切，一个条目一个 chunk，通常几百字以内，不需要 overlap。
• 面对长章节的说明书、技术文档：chunk_size 在 800~1500 token 比较合适，overlap 设置在 80~200 token。overlap 的意义是保留上下文衔接，防止“前一个 chunk 末尾的结论”恰好是“后一个 chunk 开头讨论的主语”时信息断层。
• 面对表格密集的文档：建议把表格行转成自然语言描述再切分。比如“产品型号：A100；功率：300W；接口：PCIe”转成一句话“A100 型号产品功率为 300W，接口为 PCIe”，检索效果比直接向量化原始表格好很多。

如果你拿不准，可以从一个相对保守的组合开始：chunk_size=1000，overlap=150，结构切分优先。跑一批真实 query 看召回结果，再逐步调整。不要一上来就奔着“最优参数”去，RAG 的调参是个系统性工程，一次只动一个变量。

3. 向量化与检索：让“看见文档结构”变成“按语义找话”

切分策略解决的是“文档怎么存”的问题；向量化和检索解决的是“怎么找到最相关的内容”的问题。这一节我把这两件事放在一起讲，因为在工程实现里它们是紧耦合的——你的 Embedding 模型决定了检索质量的潜在上限，而你选的检索策略（向量召回、关键词召回、重排）决定了实际能摸到多少上限。

3.1 Embedding 模型选型：别迷信“大就是好”

我第一次跑向量检索时，用的是当时最流行的 OpenAI text-embedding-ada-002，后来换成text-embedding-3-large，再后来在国产模型上反复测试。实践结论是：Embedding 的质量对领域知识库的检索效果影响极大，但选型不等于选“最大”。Embedding 模型本质上是在做语义压缩，把一段文本映射成一个向量，语义相近的文本向量距离近。如果你的知识库里大量是中文技术文档、内部术语、缩写、中英混排，那么一个在通用英文语料上训练的 Embedding 对你领域的敏感度会明显不足。

我们团队拿同一个中文技术知识库对比过几组模型，结论是：中文场景优先考虑针对中文优化的模型，比如 BAAI 的bge-large-zh、bge-m3，智源的text2vec-large-chinese，或者 M3E。它们对中文长句的语义捕捉明显比通用英文模型好。BGE 系列还支持指定query_instruction前缀，比如最终问答场景中 query 的规范形式是“为这个问题寻找支持的文档：{问题}”，检索时给 query 加上合适的指令前缀，可以进一步提高召回对齐度。

选型还得关注维度与存储成本。Embedding 维度越高，向量检索的计算开销和内存占用越大。bge-large-zh 输出约 1024 维，M3E 是 768 维，ada-002 是 1536 维。如果知识库文档量级达到几十万甚至上百万条，维度翻倍带来的成本不是线性的，这一点在做技术选型时要提前算清楚。

此外，还有一个非常容易踩的坑是：检索 query 和待检索文档必须使用同一套 Embedding 模型，甚至同一批模型权重。我们曾经在索引端用 bge-m3，在 query 端误用了另一个模型，结果所有向量距离都变得没有意义，召回结果跟随机差不多。版本更新也是一样——换模型之后，全量索引必须重建，不能混用新旧向量。

3.2 混合检索：向量不是万能的，关键词也有用

很多人以为 RAG 的检索就是“query 向量化 → 相似度 top-k”，但实际生产中，纯向量检索有一个明显盲区：专有名词、编号、精确 ID。比如用户的 query 是“错误码 E-10086 是什么含义”，向量相似度会把“错误码”“含义”这些语义词作为主要匹配信号，而 E-10086 这个精确字符串往往不是向量距离的主导因子。如果文档中确实有“E-10086”相关的条目，纯向量召回未必能把它排进 top-5。

所以我们的实践是：向量召回和 BM25 关键词召回并行，拿到两个候选集合后合并去重，再交给重排模型。BM25 对精确词匹配非常敏感，恰好弥补了向量检索的盲区。LangChain 里有EnsembleRetriever可以直接做这种混合：

from langchain.retrievers import BM25Retriever, EnsembleRetriever from langchain_community.vectorstores import FAISS keyword_retriever = BM25Retriever.from_texts([c.page_content for c in chunks]) vector_retriever = FAISS.from_documents(chunks, embedding_model).as_retriever() ensemble_retriever = EnsembleRetriever( retrievers=[keyword_retriever, vector_retriever], weights=[0.3, 0.7], )

这里weights是关键词检索和向量检索的权重，没有普适最优值。我们常用的起点是 0.3/0.7，实测下来问题和文档都是技术名词为主时，可以把关键词权重提高；问题和文档以自然语言描述为主时，向量权重提高。调整的依据是每次改动后在评测集上的召回率变化，而不是拍脑袋。

3.3 召回数量与上下文长度：Top-K 不是越大越好

Top-K 这个参数看起来人畜无害，但它直接影响回答质量和 token 消耗。K 太小，关键的上下文可能漏掉；K 太大，大量低相关片段被塞进提示词，模型反而被噪音干扰，回答变得松散甚至互相矛盾。

一个实用的经验值是：在上下文窗口允许的范围内，先用相对较大的 K 召回（比如 15~20），然后依赖重排模型把最相关的 3~5 条排到最前面，最终只把前 3~5 条拼进上下文。召回跟最终送给 LLM 的片段数是分离的：召回阶段要“多而全”，生成阶段要“精而少”。我们把这一整套流程称为“粗召回 + 精排”。最开始的实现里，我把 TopK 当成 4，结果发现有些该对的问题因为关键片段排在第五位而回答错误。后来改成粗召回 20、重排后再取 4，准确率显著上升。

关于重排，目前工业界成熟方案有bge-reranker-v2-m3和 Cohere Rerank 等。bge-reranker 可以在本地部署，对中文长文本效果好。使用重排模型时，通常把候选片段和 query 拼接起来输入模型，输出相关性分数，然后按分数降序取前 N 条。这一步的时间成本在毫秒到百毫秒级，但带来的准确率提升非常值得。

4. 上下文组装：从“给模型一堆资料”到“教模型用资料”

检索只是手段，让 LLM 基于检索结果给出高质量回答才是目的。很多初学 RAG 的开发者把“拼上下文”做得过于粗糙：把检索到的原文一股脑塞进 prompt，然后问模型“根据以上内容回答”。这样的做法，模型确实能看到资料，但它不知道资料的来源、可靠性、和问题的具体关系。要让 RAG 发挥真正价值，上下文组装要解决三个问题：格式、引用、协同。

4.1 带引用来源的回答：知识管道的信任基石

生产环境里的 AI Agent，回答必须可溯源。我们在实践早期，只做“根据以下内容回答”，结果回答虽然经常是对的，但用户追问“这个结论的依据是什么”就完全没法回应。后来我们在 prompt 里明确要求：回答时必须引用片段编号，并且把匹配到的片段索引完整返回给前端展示。改造后的 prompt 大概是这样的：

你是一个企业知识助手，请基于提供的参考资料回答问题。 要求： 1. 如果参考资料不足以回答问题，明确说“资料中未覆盖”，不要编造。 2. 回答的每个关键结论后，标注出处的片段编号，如 [1]、[2]。 3. 当多个片段观点冲突时，指出冲突并说明各自的出处。 参考资料： [1] 出自《故障处理手册》第二章：CPU 高负载处理步骤 [2] 出自《上线规范》：灰度发布操作指南

模型按编号引用之后，我们在代码里解析出 [1]、[2] 等标记，再把对应文档的原文链接、标题拼装成一个“引证对象”。用户点击引用就能看到原文。这个改动让 Agent 在企业内部的信任度大幅提升——毕竟没人愿意相信一个“说不出依据”的 AI。

4.2 把 RAG 变成 Agent 的一项 Tool，而不是唯一的回答路径

你在标题里看到的 AI Agent 和 RAG 的深度绑定，其实有一个更优雅的架构方式，我们也是在第三篇“工具调用”里踩过坑之后才彻底想明白：RAG 不应该是 Agent 的全部，它应该作为一项可调用的 Tool 存在。

也就是说，Agent 的主循环仍然是 ReAct 式的思考-行动-观察。当它判断一个问题需要外部知识时，它会调用“知识检索工具”。这个工具内部的实现是完整的 RAG 管道：query 改写、向量检索、重排、上下文压缩、返回结构化结果。这样做的好处有三个：

• Agent 可以主动决定是否检索。纯闲聊、数学计算、代码生成这类不需要外部知识的问题，不需要白白消耗检索和重排的成本。
• 检索结果可以作为中间观察传给规划模块，Agent 可以基于“第一次检索结果不够充分”的判断，自动改写 query 并做第二轮检索，这就是 Agentic RAG 的基础形态。
• RAG 逻辑被封装在 Tool 内部，上层 Agent 的 prompt 和规划逻辑保持清晰，不会把检索逻辑和任务逻辑揉成一团。

我们现在的 Agent 里大约挂了十几个工具，其中“企业内部知识检索”是最常被调用的一个。它被声明成：

{ "name": "knowledge_search", "description": "用于检索企业内部知识库中的规范、手册、FAQ、历史故障案例。当用户问题涉及公司制度、产品使用说明、故障处理时，优先调用此工具。", "parameters": { "query": "string", "top_k": "int" } }

描述字段写得很细致，因为这个描述是给 LLM 看的。它决定了 Agent 在什么场景下会想到“哦，这个问题应该用知识检索来解决”，而不是用代码解释器硬解。这说明工具描述的清晰度和 RAG 管道本身的质量同样重要。

4.3 Query 改写与多跳检索：两个必须提前做的降智防护

RAG 在实际使用中会暴露两个特别影响体验的问题，一个叫“query 口语化太强”，一个叫“单轮检索覆盖不了复合问题”。

口语化的问题是：用户不会按照你知识库里的文档措辞来提问。比如线上文档写的是“CPU 使用率过高”，用户问的是“服务器最近特别卡是怎么回事”。两者语义相近但不完全对齐，直接拿原始 query 去检索，召回质量一般。我们的做法是在 RAG 管道入口加一个 query 改写模块：让一个轻量模型把用户问题重写成更适合检索的“检索式表达”，再拿去向量化。这个改写可以在主 Agent 的规划模块里做，也可以在 Tool 内部做。

复合问题更麻烦。比如“接入层超时了，应该先看网关日志还是看服务端日志”。从知识库的视角来看，这个问题可能涉及两到三篇不同的文档片段——一篇讲网关日志排查，一篇讲服务端日志排查。单轮检索往往只抓到其中一部分。处理方式有两种：简单一点，把这类问题拆解成多个子查询，分别检索后合并候选集；复杂一点，启用所谓的“多跳检索”——Agent 在第一次检索后判断信息不足，自动发起第二轮检索补全。我们生产环境里的经验是：能用简单方式解决就不要上复杂架构。先把“正常问题的单轮检索”调到 90 分以上的稳定度，再考虑多跳。因为多跳会成倍放大 token 消耗和响应延迟，也会增加状态管理复杂度。

5. Agentic RAG：Agent 主动获取知识与 RAG 管道的融合

聊到这里，“Agentic RAG”这个热词自然就绕不开了。它过去一年在社区里被讨论得很多，但很多讨论把它讲得很玄。其实 Agentic RAG 的本质，就是前面提到的：从“一次检索，一次回答”升级为“Agent 把检索当成可编排的行为，基于当前已知信息决定下一步知识获取动作”。

传统 RAG 的流程是线性的：问题进来 → 固定策略检索 → 拼接生成。你回想一下第 4 节里我们怎么改造的，就知道 Agentic RAG 不是另一个新系统，而是 RAG 管道的“循环版”：Agent 先做一次检索，如果发现检索结果无法覆盖问题的关键维度，就改写 query 或调整检索范围，再次检索；如果问题本身是复合型的，就拆分多个子查询分别检索；如果某个检索结果过于模糊，再向下钻取，获取该片段所在的完整章节或相邻片段。

这里我举一个我们生产环境里的真实例子。我们的 Agent 遇到的问题是“灰度发布时如果新版本回滚，需要注意数据库兼容性吗”。第一次检索，召回结果是两段：一段讲灰度发布流程，一段讲数据库 schema 变更规范。但流程片段里没有明确说回滚时的数据库兼容性如何检查。传统 RAG 到这里就生成了，回答大概率含糊。Agentic RAG 会怎么办？它观察到检索结果与问题之间还有信息差，于是自动发起第二轮检索，query 被改写成“灰度发布 回滚 数据库 兼容性 检查”，这次召回了数据库变更规范里关于回滚时要核查的细节条目，补充进上下文之后，回答就完整了。

这个能力的工程价值还体现在另一个地方：它能主动规避检索噪音。比如第一次检索召回了一个与问题有点边缘相关但并非必要的片段，Agent 可以判断它不需要，而不是像传统 RAG 那样硬塞给生成模型。这直接减少了上下文里的噪音，提升回答集中度。

Agentic RAG 的实现，本质上靠的就是第 4 节提到的“RAG 作为 Tool”。一旦管道变成 Agent 的工具，Agent 的规划器就能自由决定“检索几次”“怎么检索”“是否继续检索”。工具接口的description和参数设计就成了核心战场。

如果你想快速上手 Agentic RAG，我推荐从 LangGraph 的角度去理解它的执行流程：一个状态机，包含“检索”“改写查询”“评估信息充分性”“生成”几个节点。评估节点收到一轮检索结果后，如果判定信息不足，就跳回改写查询节点继续循环，直到充分或达到最大迭代次数。这种表达方式比“给 LLM 一个大 prompt 让它自己折腾”更可控，因为每一轮检索之间多了一个明确的“充分性检查”硬逻辑。上限更高，底限也更稳。

6. RAG 效果度量：用指标说话，而不是用感觉调参

最后聊一个几乎所有 RAG 项目中后期都会遇到的问题：效果怎么度量。很多团队在这个环节走弯路，最典型的表现是“拿 20 条测试问题人工看了一遍回答，觉得还行，就上线了”，结果线上各种翻车。因为人工看 20 条数据，根本分不清问题是出在“知识点没被检索到”，还是“检索到了但模型没用对”。这两类问题的修法完全不同。

6.1 三个核心指标：Retrieval Hit Rate、MRR、Faithfulness

我从实践中沉淀的指标组有三项，分别盯管道的中游和下游：

• Retrieval Hit Rate（召回命中率）：针对每条测试问题，人工标注“应该检索到的正确片段集合”。跑检索后，看这些片段是否出现在召回列表里。如果 Hit Rate 低，问题出在切分、Embedding、检索策略这一侧，先别急着调 prompt。
• MRR（Mean Reciprocal Rank）：不仅看正确片段是否被召回，还要看它排在第几位。排第一得 1 分，排第三得 1/3 分。MRR 反映的是“排序质量”，它掉下来通常意味着重排这步出了问题。
• Faithfulness（忠实度）：看模型生成的回答是否严格基于检索到的片段，有没有编造。忠实度低，问题出在上下文组装或者 prompt 引导上，和检索无关。

这三个指标对应的排错路径完全不同。我之前排查过一个“线上问答总是答非所问”的问题，团队一开始在 prompt 上反复调，结果毫无起色。后来一测 Hit Rate，发现正确片段根本不在召回范围内——检索器召回的前几名全是似是而非的条目。把注意力转回 Embedding 和切分之后，一周内问题就解决了。这就是指标的意义：它帮你把模糊的“效果差”翻译成可定位的“管道的哪一段失败”。

6.2 测试集怎么建

建一个高质量的 RAG 评测集，比调 RAG 本身还花时间，但值得。我们的做法是，从知识库里按文档类型分层抽样（操作手册、FAQ、故障案例、制度规范各占一部分），针对每篇文档人工写出 5~8 个真实用户可能提的问题，同时标注出正确答案涉及的片段 ID。测试集规模不用特别大，先到 100 条左右，但覆盖面要尽量均匀。之后每次修改切分参数、换 Embedding、调整重排，都用同一套测试集跑指标对比。不改测试集、不动指标，任何“我觉得效果好多了”的判断都不可信。

评测指标的落地，可以借助的开源工具也很成熟。社区里使用较多的有LlamaIndex自带的evaluators（含 faithfulness、context relevancy 等），也有RAGAS这种专门做 RAG 评测的框架。如果你刚开始做，建议不要过度依赖自动评测，先以人工标注的 Hit Rate 为准，把基础打牢，再逐步引入自动指标。

6.3 迭代节奏与常见误区

把 RAG 管线投入真实业务后，我建议按这样的节奏做迭代：先保证 Hit Rate 达到一个可接受基线（比如 80% 以上），再提升 MRR，最后优化 Faithfulness。不要试图同时优化三个指标，因为任何一次改动都可能顾此失彼。

另一个常见误区是“追求召回率 100%”。检索阶段“宁可多一点”不假，但这个“多”是有度的。召回过多时，上下文被大量低相关片段污染，Faithfulness 往往也会跟着崩。我们现在通常把粗召回控制在 20 条以内，重排后精取 3~5 条参与生成，这条路径对多数场景都是稳的。

最后提一个很多人忽略的小细节：检索日志一定要留。每条线上 query 的召回列表、重排后的顺序、最终喂给 LLM 的片段 ID、生成的回答，全部落日志。线上效果好或不好，都靠这个日志复盘。没有日志，出了问题你连从哪一环查起都不知道。这套知识获取管道搭好之后，Agent 的表现稳定了很多，我在实践中最大的体会是：与其花大量时间在“调教模型”上，不如花心思把管道拆开，让每一段都可观测、可评测、可迭代。