企业官网建设流程全解析

谢绝推销，直接开讲。去年底团队内部一直在折腾 Agent 落地，前两篇分别聊了聊 Agent 的框架选型和工具调用设计，这一篇终于轮到知识库。我的判断很明确：知识库是 Agent 从“能聊”到“能干活”的分水岭。如果没有它，你的 Agent 只能靠大模型肚子里那点“普世常识”撑场面，一旦涉及公司内部流程、产品文档、历史项目经验，它就开始一本正经地胡说八道。这篇内容我结合自己搭 Dify、搭本地 RAG 的实操经历，把“如何把散落一地的资料变成 AI 真能查的”这件事掰开揉碎讲清楚。

先说清楚：这不是一篇纯理论科普，而是基于真实项目经验的完整拆解。你会看到为什么不能把资料一股脑塞给大模型，知识库要经过哪几个加工环节才能真正被 AI 使用，以及我在做知识检索时的各种踩坑和补救方案。

1. 先搞清楚“散落一地”到底散在哪：本地文件、协同文档、聊天记录、网页书签

动手搭知识库之前，你得先面对一个残酷的事实：资料不在同一个地方。团队里的情况通常是项目文档散落在本地硬盘、NAS、语雀/Notion 等协同工具，关键结论藏在企业微信/钉钉群的聊天记录里，偶尔还有一些只能从某个内部网页才能访问的操作手册。这些内容格式五花八门，Word、PDF、Excel、HTML、甚至一张张截图。

这就带来了知识库建设的第一个核心任务：识别资料所在的“物理位置”，然后决定用什么方式把它们拉进来。我见过不少新手一上来就急着调 Embedding 接口，结果连文档都没归拢齐。我的建议是先做一次“资料普查”，把资料按来源、格式、更新频率三个维度梳理一遍。比如：

我建议按这个表先把自家资料过一遍，心里有数之后再选搭建方案。这不只是体力活，更决定了后续数据清洗的复杂度。比如 PDF 文件看起来人畜无害，实际解析时你能遇到扫描版、旋转页、三栏排版、表格断裂等一堆问题，这些最后全都会反馈到检索质量上。

很多人在这一步容易犯一个错误：为了“省事”，直接把整个服务器目录打包上传，让系统自己解析。结果索引建完、一问三不知。原因很简单：你的资料是给“人眼”看的排版结构，不是给“机器”拆解的语义结构。不对格式做预处理就贸然灌进知识库，等于让 AI 对着乱序文件猜意思。

所以，别急着建库。先花时间整理源头，搞清楚哪些资料值得进库、哪些是过时垃圾、哪些需要先转换格式。知识库的质量上限，在资料盘点阶段就已经被决定了，后面做的所有优化都只是尽量逼近这个上限。

2. 为什么不能把资料直接塞给大模型：上下文窗口、幻觉与“查不到”的本质

有人会问，既然大模型句子接龙能力这么强，我怎么不把公司两千页的规章制度直接粘贴给它，让它自己“记住”？这就要聊到两个物理层面的限制。

第一，上下文窗口有限。主流模型的上下文通常在 128K 到 200K 左右，听着很大，但塞一份中等的产品白皮书加上历史项目总结就能占掉大半。而你在对话里还需要留空间给用户的问题、Agent 的中间推理、工具返回的额外内容。一旦超过窗口，要么报错，要么模型把中间内容“忘记”。即便强行塞下，模型对超长文本里某个细节的回忆能力也极不稳定，实测下来简直是“大海捞针”，开头的东西印象深，中段的细节经常张冠李戴。

第二，幻觉问题。大模型本质上是概率预测，它的回答是“像不像”而不是“是不是”。遇到没见过的细节，它会用合理的措辞补全，结果就是答错得特别自然。我以前让 Agent 写季度总结，找不到某个项目的实际数据，它直接编了一个，数字漂亮得差点被领导采用。这个教训让我彻底明白了：不能在模型内部“记忆”关键事实，必须让它在回答前先从外部检索到可靠材料，再基于材料组织答案。

所以，知识库的本质是什么呢？它是大模型的一个“外挂硬盘”。模型不直接记住硬盘里的每一个字节，而只在被问到相关问题时，由检索系统把最相关的一小部分内容“调取”出来，塞进上下文，让模型“看着资料回答”。这也是业内常说的 RAG（检索增强生成）。你不需要让 AI 记住所有资料，你只需要让它每次都能查得到、查得准。

搞明白这一点，你就能理解为什么知识库的搭建核心不是“存储”，而是“检索”。能存文件、能查数据只是基础动作，真正费心思的是如何让“找得对”——文档切得好不好、向量算得准不准、排序合不合理，这些才是决定 AI 答得好不好的胜负手。

3. 知识库的四段流水线：加载清洗、切片分块、向量化存储、召回排序

3.1 加载清洗：PDF 扫描件、表格错位、目录页干扰

知识库搭建正好是一条流水线，第一站就是加载清洗。

清洗环节最常见的情况是企业里那种“历史遗留”资料：扫描版 PDF 没有文字层、图片截图文字歪斜、Excel 里有合并单元格。这些都是检索系统最不擅长处理的东西。我的做法是：

• 扫描版 PDF 先过 OCR，推荐 PaddleOCR 或 Tesseract，转成可检索的文字层。
• Word/PDF 里的目录页、页眉页脚先剥离，避免切出大量“目录”“第几章”这种无意义片段。
• 表格类文档转成 Markdown 表格格式入库，比直接提取纯文本要容易保持上下文关系。
• 图片类的资料，真心建议人工先辨识一下，有价值的才做 OCR，因为图片的知识密度通常不高，还特别占处理时间。

这一步做得越细，后面切片的原材料就越好，检索效果自然更好。

3.2 切片分块：为什么 chunk 大小影响这么大

清洗完之后就是切片。切片听起来很简单，就是按固定字数把大文档切成小段，但这是最影响检索效果的一步，也是最容易被忽略的一步。

为什么必须切？因为 Embedding（文本转向量）模型对输入长度有限制，而检索时需要对文件片段做“相似度匹配”，太长太短效果都不好。切太碎，语义不完整；切太大，混入了太多无关内容，检索结果的准确率也会下降。

我在实际项目里的经验值是：中文场景下每个切片控制在 300-500 字左右，同时保留 50 字左右的重叠（overlap）。为什么要有重叠这一刀？因为自然语言的语义边界不是恰好落在第 500 个字上的，片段与片段之间经常会出现关键信息跨段的情况，比如一个概念在上一段给出名词、下一段解释含义。重叠能够确保这个被切断的点前后都有衔接，检索时不容易漏掉关键内容。

更高级一点的做法是按语义边界切。比如先按 Markdown 标题分段，再按段落切，如果一个段落还是太长，再按句子边界继续切割。很多知识库平台已经能自动识别标题层级做层次切分，我测试下来这种结构化切分的检索准确率明显优于纯按字数硬切。

3.3 向量化与存储：Embedding 模型、向量库怎么选

切片完成之后，就到了把文本转化成语义向量的环节，也就是俗称的 Embedding。

这里有一个常见的误解：Embedding 不是给每个词编号，而是把一整段文本映射到高维空间里的一个点。语义接近的文本，在空间里距离就接近。搜索引擎搜“报销流程”能找到“费用报销需要注意什么”，靠的就是语义近似，而不是字面相同。

Embedding 模型的选择上，我是这样判断的：

• 中文场景优先用中文语料训练过的模型，比如 text-embedding-v3、bge-large-zh、bge-m3 等，实测对中文长文档、专业术语的语义捕捉度比通用英文模型好不少。
• 需要多语言支持的团队，可以考虑针对多语言优化的模型，整体按需选型。
• 不要迷信模型越大越好。Embedding 模型相当耗时，团队规模小的时候一个百来 M 的中文模型已经够用，跑在 CPU 上都能凑合。

向量数据库的选择，我在团队里用过 Milvus 和开源的 Chroma、Qdrant，当时的判断依据主要是数据规模和并发要求：

如果只是自己搭来玩玩、数据量不大，开源知识库平台自带的向量库完全够用，不用非去单独配一套。

3.4 召回与排序：向量检索、全文检索、重排序的选择

存储完成之后，知识库就具备“查询”能力了。查询过程不是一步到底，而是“粗召回 + 精排序”。

粗召回阶段，通常用向量相似度（语义匹配）和关键词检索（BM25）并行跑。我为什么要同时跑两路？因为向量检索擅长找“意思相近但用词不同”的内容，关键词检索则擅长在专业名词、型号、编号上精确命中。两者互补，混合检索往往能兜住更多情况。

但召回来的结果可能是几十条甚至上百条，你不能全塞给大模型，所以要做精排序。精排序通常用 Rerank（重排序）模型做，它对召回的候选做更细粒度的语义打分，排掉那些表面相关但实际答非所问的结果。这一步能显著提升准确率，代价是多一次模型推理，会有一定延迟和成本。

如果团队预算有限，我建议至少也做一个基于规则的精排——比如把包含精确关键词、来源于更高权重文档的结果排前面，比如给人工标注过的重要文档加一个权重分。这些都能改善检索质量，而且不需要额外加载模型。

4. 实操：用 Dify 建一套可复用的知识库流水线

4.1 为什么我建议先别自己从零搭，而是用平台先把流程跑通

如果你不是专门做 RAG 方向的技术团队，我的建议非常直接：第一版方案别自己从零写代码搭流水线，直接用一个成熟的平台把流程跑通，先把效果调出来。我自己就是先用的 Dify。原因很简单：

• 平台把加载、清洗、切片、向量化、召回、排序全都串好了，你只需要传资料，选参数。
• 它有配套的可视化调试界面，能直接看到检索命中的内容，调试起来非常高效。
• Agent 接口、模型配置、知识库 API 都能一站式管理。

如果是零基础入门，Dify 的社区版部署在一个 8G 内存的云服务器上就能跑得动。我当时的部署流程就是先装 Docker，把 Dify 的 docker-compose 拉起来，界面访问成功后，再进后台配模型供应商的 API Key。

4.2 建库的具体步骤：上传文档、设定分段规则、选 Embedding 模型

在 Dify 后台里创建知识库时，我通常按文档类型分别建库，比如“产品文档库”、“规章制度库”、“项目经验库”。这样后续可以让 Agent 根据用户提问，自动选择应该调用哪个库。

上传资料后，最需要留意的是分段设置。Dify 默认模式可以调分段标识符和最大分段长度。我的建议：

• 用 Markdown 标题作为分段标识符，让系统优先按章节切，切出来的片段天然带结构化语义。
• 分段长度设置到 400-500 token，重叠 50 个 token。这是很多线上业务实测下来比较稳的组合。
• 打开“引用元数据”的选项，能看到每条检索结果的来源，调试的时候非常有帮助。

Embedding 模型方面，Dify 支持多个模型供应商。我当时选的是一个中文效果较好的 Embedding 在线模型，具体选择依据就是前面提到的中文语料适配性。如果部署在内网，就考虑用 Ollama 跑本地的 bge-m3，效果也不会差太多。

4.3 把知识库接入 Agent：让 Agent 学会“先查后答”

建好知识库只是第一步。接下来要让 Agent 知道“自己有知识库可用”，并且在回答前主动去查。

在 Dify 的 Agent 编排里，你可以添加一个“知识检索”工具。关键是给它写清楚调用说明，别写得太抽象，要写明白它的能力边界和使用场景。我的提示词大致是这样：“当用户的问题涉及公司制度、产品使用、历史项目数据时，请先检索知识库；如果知识库没有相关内容，直接说明没有，不要猜测回答。”

这一步极其重要。不写清楚边界，Agent 很容易偷懒：遇到什么问题都不去查，凭自己的“印象”直接开答。或者相反：把用户随口一句话都去触发检索，延迟很大。调用策略的描述就是让 Agent 学会判断“什么时候该查”。

调试到这一步，你已经有了一个能回答内部问题的 Agent 雏形。接下来真正头疼的问题才开始出现——下面这节就是我实际遇到的各种鬼问题和排查思路。

5. 实测阶段最难过的三关：查不到、查不准、查太慢

5.1 查不到：召回错位时的排查链路

第一种最常见的问题是“查不到”。用户明明问的是公司报销流程，知识库里也有报销制度，Agent 却回答“知识库中没有相关资料”。这时候我会按下面的链路排查：

第一步，先去知识库后台搜索验证。用同一个问题测试召回，看系统到底有没有召回相关片段。如果召回为空，说明问题出在“入库”和“召回”环节；如果召回到了，但 Agent 说没有，那问题出在提示词和上下文处理上。

第二步，若是召回为空，再去检查切片的覆盖度。这类问题八成都出在切片太碎：报销流程分散在多个标题下面，关键词没在同一段出现，向量匹配时就很难命中。解决方式是下调分段长度或打开重叠。

第三步，如果召回不为空但命中的不是用户要的那个意思，就要考虑混合检索。词面不匹配是向量模型经常翻车的地方，尤其在专业名词、缩略语上，混合检索能很大程度补上这个短板。

这里特别提醒：这轮排查时最容易走火入魔的地方，是看到一个召回结果不好就立刻换 Embedding 模型。我的经验是，先排除切片和检索模式问题，再考虑换模型。换模型意味着全部数据要重新向量化，成本不小，不排查清楚就换是很浪费的。

5.2 查不准：重排序能救场，但也会帮倒忙

第二种问题是查到了但结果不对。比如问“怎么提交请假申请”，召回的是“请假管理规定”，内容通篇都在讲可休天数，没有提审批流程。这时候光靠向量召回是不行的，因为向量模型打分时很难区分“相关政策”和“具体操作步骤”的差别。

我的优化手段依次是：

• 第一步，在分片的时候就把“制度类”和“流程类”文档分开建库，让路由层决定查哪个库。
• 第二步，引入 Rerank 模型，对召回候选做二次精细排序，实测可以把命中准确率提升 2-3 成。
• 第三步，如果重排序效果还不行，优化召回来源的元数据过滤。比如在文档里人工打标签，把“流程图”和“制度解释”区分开，查询时按标签做过滤，排除干扰项。

顺便提醒一个很容易踩的坑：Rerank 并不总是正向的。当时某个测试场景只有一条正确资料，因为其他资料和问题措辞接近，Rerank 反而把一条看似相关但其实是旧版本的内容顶了上来。所以重排序模型上线前，务必用一批人工标注好的查询做 A/B 验证，别盲目相信它一定能提升效果。

5.3 查太慢：并发上不去、Embedding 超时怎么办

第三种问题是性能相关问题。知识库本身构建的时候，一天的文档量如果几百份，中午触发批量导入，Embedding 接口 429 报错是常事。这时不要并发全开，要把批量提交改成串行或小批量并发，再加个重试机制。我在 Dify 配置里就把 Embedding 并发调到比较保守的水平，宁慢勿崩。

在线问答步的延迟更大。一次问答可能要经过向量检索、Rerank、再加一次大模型生成，总耗时很容易到 6-10 秒。优化路径有几条：

• 缓存：对相同的常见问题直接缓存答案，命中缓存时秒回。
• 限定召回数量：topK 从默认 6 减到 3-4，延迟和 token 消耗都明显下降，多数场景效果并不受损。
• 流式输出：先让检索结果在页面上出来，模型生成时流式逐步返回，用户观感会好很多。

压测时还要记得，不要全链路同时打。我当时压测发现瓶颈首先出现在向量库的 QPS，而不是模型推理层面。做了缓存后发现 QPS 翻了两倍，延迟也从 10 秒降到 1.5 秒，压测效果才真正达标。

6. 进阶：多模态、增量更新、多知识库路由——上线之后才面对的问题

6.1 图片和非结构化资料怎么入库

热搜里有人在问 RAG 知识库能不能存图片，答案是可以，关键看你图里是什么信息。如果是带文字的图片，两条处理路径：

• 轻量方案：OCR 提取文字后，只把文字入到知识库，图片本身在检索展示环节用链接引回原图。
• 完整方案：用多模态模型（例如带视觉能力的模型）直接生成图片描述，把“图片描述文本”入到向量库里，检索命中后把描述的语义返回给大模型。这种方式能让“图的形状、表格结构”也成为可以被语义检索的信息。

团队日常运维类资料里，截图成了很大的信息载体，我的建议就是先 OCR 后入库，图本身不参与语义索引，而是在展示时作为证据链接附上。性价比最高。

6.2 已有资料的更新机制：全量重建与增量同步

知识库最容易被忽视的问题就是更新。很多团队建库后半年不更新，最新的流程文挡没进去，新增的规则也没有入库，结果 Agent 给出的还是半年前的信息。我给团队定的更新机制很简单：

• 修改频率高的文档，每天凌晨自动拉取云端文件，全量重建增量索引。
• 手动更新类资料，每月人工盘点一轮，主要在后台检测“过期”文件并更新。
• 删除旧文件时，记得在向量库里同步清理对应的旧向量，否则旧的过期内容还是会被召回，这个问题特别隐蔽。

更新机制做得好，知识库的长期可用度才会高。建库只花了三天，但如果半年不管它，它会在不知不觉中变成一个“旧资料库”。

6.3 多知识库路由与权限控制的价值

当我们把“产品文档”“规章制度”“项目复盘”分开建库后，Agent 面临的另一个问题就是“该查哪个”。我的做法是给每个知识库定义一个描述标签，比如“报销审批流程，包含费用申请标准与审批节点”，并让路由控制在 Agent 提示词里完成。实测这种“先路由后检索”的方式比把所有库一把梭查一遍效果稳得多，也让日志排查更清晰、权限控制更好做。

权限控制这块，如果知识库涉及不同敏感级别的资料，建议在 Agent 工具层做一次访问控制校验。不是为了防自己人，而是防止某些“不该说”的信息被知识库一起捞走，这在一些对外输出的场景里非常关键。

这一路趟下来我的感受是：知识库与其说是个“技术组件”，不如说是一个需要持续运营的资料管理体系。Doc 文档导进来只是开始，切片参数、Embedding 选型、检索质量评估、定期更新，每一个环节都会直接影响 Agent 到底好不好用。目前我最受用的一条经验是：知识库的质量提升，永远先把“能查到我想要的内容”做好，再谈什么花哨的智能体编排。如果你也在搭 Agent，正好卡在知识库这关，希望这篇能帮你少走点弯路。