企业官网建设流程全解析

前前后后做了六七个AI落地项目，有成功的，也有上线没多久就被用户点名的。最近花了两个晚上把其中几个明显失败的项目翻出来复盘，越复盘越发现一个扎心的事实：真正让项目凉掉的，很少是模型不够强，而是喂给模型的知识库太乱。模型本身像个聪明但没见过世面的新人，你给它什么资料，它就只能照着资料发挥；资料里全是坑，它回答出来也全是坑。这篇复盘想把我踩过的几个典型坑、排查思路和最后沉淀下来的改造方案完整记录下来，给正在搭知识库、做RAG、用Dify这类平台跑应用的同学一个参考。内容偏实操，不讲空话，照着做基本能避开我当年犯过的错。

1. 复盘口径：先看看这三个项目是怎么翻车的

1.1 项目A：客服机器人，模型没问题，但回答永远答非所问

第一个失败项目是给一家电商公司做客服机器人。当时信心很足，因为调用的对话模型在公开测试里的表现相当能打，我也没把知识库当回事，想着直接把公司现有的帮助文档丢进去就完事。

上线前测试就出了问题：用户问“发错地址了运费谁承担”，机器人会回一篇完整的产品白皮书；用户问“怎么修改订单收货地址”，机器人有时候答非所问，有时候干脆说“请咨询人工客服”。一开始我以为是模型的意图识别能力不够，换了好几个模型都一样。后来耐着性子去翻知识库，发现问题出在文档处理环节。

当时知识库里塞了一千多份从旧帮助台导出的PDF和Word文件，标题混乱、格式不统一，有的文件甚至把FAQ问题和另一个问题粘在同一个段落里。更致命的是，我用固定500字硬切文本，一个完整的问题经常被从中间腰斩，前半段进了上一个分块，后半段进了下一个分块，检索的时候根本找不回完整表达。一份文档里有20条规定，我只把开头那一条完整切了出来，剩下全是被切碎的“半截话”。这种库，别说GPT级别的模型，你就是给它一个能读完整本书的超级模型，它也只能从残缺的碎片里瞎猜。

1.2 项目B：农业垂直领域问答，术语密集，召回率低到离谱

第二个失败项目是给某农业技术团队做知识问答系统，想回答种植户关于浇水、施肥、病虫害的问题。这个项目我一开始更关注模型选型，专门挑了在当时中文能力比较强的模型，可真正做出来效果依然惨不忍睹。

测试时我拿了100条真实种植户提问去跑，结果只有21条能正确命中知识库里的对应内容。比如用户问“这两天该不该浇水”，知识库里明明有这个技术指导，但那条指导的标题是“土壤墒情监测与灌溉决策”，库里也没有把两者关联起来。因为种植户根本不会用术语提问，他们说的是大白话，而知识库里的内容全是严谨的技术表述。

问题出在向量化环节。我当时用的是通用领域的Embedding模型，它对“浇水”“灌溉”“土壤墒情”这些词的理解明显不够，语义鸿沟直接导致召回率极低。再加上知识库里大部分内容是从网上找的二手技术文章，不是一线规范文档，文章本身就是东拼西凑，检索出来再怎么喂给模型，答案质量也高不到哪去。这个项目让我第一次意识到：垂直行业的知识库构建，根本不是“丢进一个开源知识库工具里”就完事，它需要做术语归一、同义扩展、文档分级，甚至要针对行业习惯专门调Embedding。

1.3 项目C：私有化部署的知识库，扫描件和表格全丢了

第三个项目是企业内部私有化知识库，客户对数据安全要求很高，明确要求所有资料必须在内网部署，不能走公网上的任何大模型接口。项目本身用的是开源模型做私有化部署，我一开始也以为是模型能力不如商用模型，结果测试时发现回答经常是“不知道”或者答非所问。

后来逐条排查知识库里的文档，发现真正的问题更基础：这家企业的大量资料是老式扫描版PDF，根本没有可复制的文字层，我没做OCR就直接入库了，检索时看着像有内容，实际全是乱码和空文本；还有一部分技术参数存在表格里，表格又是用图片形式插入的，图片内容在传统文本切分流程里会被直接丢弃。结果就是，一个听起来很复杂的失败案例，根源只是“图片没处理、表格没转文本”这种最不起眼的问题。

我后来统计了一下，文档里大约有六成有效信息因为格式处理不当而完全无法检索。这个项目让我彻底明白：知识库的底层工程，比模型选型要重要得多，模型再强也补不回来丢失的数据。

2. 问题定位：知识库才是那个看不见的短板

2.1 RAG链路里，模型只是个“临时看书”的考生

复盘完这三个项目，我发现它们都算同一个技术路线：RAG，检索增强生成。RAG的逻辑很朴素：用户提问后，系统先从知识库里检索出相关文档片段，再把片段和问题一起塞给模型，让模型基于检索结果来组织答案。模型不是一台把所有知识都装进脑子里、考试时凭记忆输出的机器，它更像一个进考场前才开始翻教材的考生，翻到哪页就靠哪页答题。

这就好理解了：如果你给考生的是一本缺页的书、一本印刷错误的书，或者目录标题全是乱的，考生再聪明也答不出正确答案。RAG的效果上限，被知识库的检索质量牢牢卡住。很多时候项目跑不动，你换模型、调Prompt，效果提升只有几个百分点，因为你一直在优化“考生的大脑”，却忽略了“教材”本身全是问题。

我在项目B里深有体会：换了个更强的模型，准确率从21%只涨到27%，后来把知识库清洗了一遍、重做了检索方案，准确率直接跳到78%。这个对比已经足以说明问题。所以我现在的习惯是：模型只负责把话说得像人，知识库才负责把话说对。

2.2 失败项目里反复出现的四个共同坏点

把三个项目放在一起对照，我发现所有失败背后都有四个共同坏点，单独看都很基础，但凑在一起足以让项目全线崩溃。

第一，不洗文档就直接入库。页眉页脚、目录、水印、乱码、广告位，通通混在正文里。知识库检索出来一大堆噪声，模型根本分不清哪句是真正的内容，哪句是版权声明。

第二，一刀切式的固定分块。用固定字数硬切，语义被拦腰截断，这在项目A里被体现得淋漓尽致。切分不是一个“随便设个500字”的活，它直接决定后续模型能不能看到完整的上下文。

第三，只依赖单一的向量检索。很多人以为有向量化就够了，但实际业务里，用户表达和文档原文往往是不同语言体系，一个向量召回不到全部相关内容。你要么是混合检索，要么做好同义改写和查询扩展，否则召回率一定上不去。

第四，没有评测机制就上线。项目A和B都没有在真实用户问题集上做过系统验证，几个人手动试几个问题觉得“还行”就交付，结果上线后全网用户一提问，立刻露馅。后来我养成了习惯：每个知识库必须准备一套评测问题集，没跑过评测的项目不许上线。

2.3 “模型繁忙”和知识库队列积压，常常被错误归因

做项目时还遇到过一个特别迷惑的情况：Dify平台里知识库状态一直显示“排队中”，用户那边看到的是“模型繁忙，请稍后再试”。当时第一反应是模型服务并发上限了，赶紧去扩容，结果没有任何改善。

后来查了一圈才发现，问题出在知识库的索引和Embedding任务积压上。当知识库里新增几百份文档或者重新分段之后，系统要对每个分块重新做Embedding和向量入库，任务量一大就会出现排队。与此同时，用户提问时系统要做多次查询召回，如果知识库数据太乱、分段太多，每次查询都要扫描大量无关向量，延迟和资源开销都会成倍增长，最终表现成用户侧的“繁忙”提示。

从那之后我排查类似问题就多了一条思路：先看知识库侧有没有排队任务，再看索引是否过期，最后才怀疑模型服务。上线规划时也切记给批量Embedding任务预留资源窗口，别让入库任务和线上查询撞在同一时间点。

3. 可复用的知识库改造方案

3.1 文档洗白白：入库前必须做的四件事

第一个教训就是要做文档预处理，我建议所有人在解析环节就定好规则。

第一件，格式归一。把PDF、Word、PPT、图片统一转成Markdown或者其他统一的结构化格式。这个步骤不是可选项，是必选项。来源文档格式五花八门，你不归一，后面所有处理都会碰到地雷。推荐用开源的文档解析服务，配合Dify这类知识库平台自带的文件解析能力，把复杂格式在入口处一次性“烫平”。

第二件，扫描件必须做OCR。像项目C那样把扫描PDF直接丢进去，等于建了一座满是乱码的图书馆。OCR之后还要人工抽检，确保关键表格、数字没有被识别错。农业、法律、医疗这类行业对数字准确性极其敏感，识别错一个数字，回答就会错一整条逻辑。

第三件，剔除噪声。页眉、页脚、页码、水印、目录索引、参考文献列表里的内容，在入库前要么删掉，要么单独处理。尤其是页眉中的公司名和版权标识，会污染模型的语言习惯，让它把“技术支持热线”当成回答主体。

第四件，保留标题层级。清洗文档时，我特别强调保留下原有文档的标题结构和层级关系，因为标题是最好的切分线索。你可以把清理后的文档想象成一本带目录的纸质书，标题就是导航。用标题作为分段边界，而不是靠固定字数硬切，后续检索会精准很多。

3.2 切分策略：不要迷信固定Token，要跟着内容结构走

切分是知识库工程里最容易被低估的环节。固定500字切一切确实省事，但效果很随机，尤其当文档里一个问题有20条细则时，固定切分会让20条细则散落在完全不同的分块里，模型每次只能看到其中一两条。

我现在用的是这套切分策略。

首先是尽量按标题和章节结构切分。解析文档时把标题识别出来，以章节为基本分段边界，章下内容过长再继续细分。这个做法从根本上保留了语义完整性。

其次是设置合理的分块长度和重叠。建议是主分块长度为300到500个token，重叠50到100个token。重叠部分是为了避免边界语义被切断。你可以理解为两段之间做个“交接棒”，一小段重复内容能让模型在前一段的结尾处还能承接后一段的开头，信息不断档。

然后是分类型管理。FAQ短文本和长篇幅手册要放进不同的知识库，因为它们的召回需求完全不同。FAQ适合小分块精准命中，长手册适合大分块保留上下文。都混在一个库里，相似度算法会被短小精悍的FAQ带着跑，长文档里的深层内容永远没有出头之日。

如果文档特别长，我还会用父子块方案：先在大段落级别做索引，命中父块后，再把父块内部的子块作为上下文投给模型。简单说就是先找对章节，再在章节里精读细节，兼顾召回率和上下文长度。

表格这类结构化数据，洗成Markdown表格或者行文式描述后再入库。Dify里可以直接把表格转成文本，但要保留关键行和关键列的表述。图片如果要入库，要么用OCR把图里的文字和表格结构提出来，要么用支持视觉输入的多模态Embedding模型。回到很多人问过的问题“RAG知识库能存储图片吗”，答案是能，但前提是你先把图片转换成模型能理解的内容，或者用多模态检索方案，否则图片就是一只好看但扎不着的刺猬。

3.3 向量、检索与重排：把组合拳打满

知识库改造不能只停留在清洗分段，检索链路也必须跟着升级，不然还是会碰到项目B里的术语鸿沟。

第一环是Embedding选型。中文场景我现在首选BGE系列或者M3E这类专门优化过中文语义的模型，实践下来比通用英文模型靠谱得多。如果业务有多语言需求，就用BGE-M3这类支持多语言和长文本的模型。开源模型完全够用，没必要一上来就买商业向量化接口。

第二环是混合检索。单纯向量检索的缺陷是只认语义相近，不认关键词精确匹配，而很多行业场景恰恰要靠专有名词精确命中。我的方案是向量检索和全文检索并行，然后用RRF融合算法把两边结果排序合并，让两种优势互补。这在Dify平台里就是直接用“混合检索”模式，如果没有可视化平台，自己写也行：向量召回TopK和BM25召回TopK取并集，再按RRF分数排序。

第三环是重排。向量和全文检索召回的结果可能还是带噪声，我再加一层重排模型比如BGE-Reranker，对候选片段和用户问题做更细粒度的相关度打分，把最相关的片段排到最前面。重排模型比普通Embedding慢，但它只处理前几十个候选，性价比很高。

第四环是调好两个核心参数。TopK不要迷信越大越好，我一般取3到8，视业务复杂度而定；Score阈值控制在0.3到0.5之间，阈值定太低会把大量不相关内容塞给模型，导致幻觉；阈值定太高又可能什么都召不到。这套组合打满后，我后续几个知识库项目的召回质量都提升明显。

4. 避坑指南与上线前的验证清单

4.1 用100条真实问题验证知识库，而不是对着模型跑分

这是个血泪教训。项目A和B都死在“没有评测”上，所以我后来强制自己和团队遵守一条计划：任何知识库上线前，先做一轮可量化的评测。

具体做法是准备100到200条来自真实业务场景的提问，这些提问要尽量还原用户的真实说法，包括口语化表达、错别字、行业黑话。然后为每个问题标注期望命中的文档出处。接下来跑一遍检索链路，统计两个指标：命中率，也就是正确文档出现在结果列表里的比例，以及MRR，也就是正确结果排名的倒数平均。MRR越高说明排序越靠谱，0.6以上算及格，0.8以上就是优秀。

有了这两个指标，你就可以把“效果好不好”从一个主观判断变成一条客观刻度。改造前命中率只有21%，改造后78%，这个数字会直接倒逼你去把知识库做扎实。行业里现在也流行用LLM-as-Judge，让一个强模型给回答质量打分，但我更建议先用命中率和MRR这类客观指标把好入口关，再用模型打分做参考。尤其做专利辅助、技术咨询这类对准确性要求极高的场景，光靠模型打分是远远不够的。

4.2 排查“答非所问”和“一本正经胡说八道”的固定套路

项目一多，我总结出了一套面对“模型说胡话”时的排查顺序，照着走基本能把问题定位到具体环节。

第一步看引用。机器人回答问题时，它到底参考了哪段知识库内容？如果引用的文档本身就跟问题无关，那问题出在检索阶段，跟模型一点关系没有。这一步能帮你排除掉一半以上的幻觉问题。

第二步看阈值和TopK。如果引用文档相关，但模型还是答偏了，很可能是Score阈值设得太低，把噪声也当成相关资料塞了进去。试着调高阈值、减小TopK，过滤掉边缘结果，回答通常马上变干净。

第三步看分块和上下文。回答引用的内容正确，但模型只拿到其中一个片段，缺少关键细节，那就要去检查分块是否把完整上下文切断了，或者有没有启用父子块机制。

第四步才轮到考虑换模型、调Prompt。我见过太多人一上来就跳到第四步，结果换了一圈模型也没用。记住我这条原则：先用引用定位检索，再用参数过滤噪声，最后才碰模型层。

4.3 一些容易被人忽略、但很致命的小坑

前三条讲完，我再补充几个藏在角落里的实操细节。

首先是知识库更新后一定要重建索引。很多人更新了文档，没触发重新Embedding，用户提问时检索到的还是旧内容。尤其平台里直接改了分段方式，旧索引不会自动清掉，很容易让线上代码跑到一半就冲进废弃的向量里，得到一堆过时信息。我的办法是每次修改分段配置后，都建立一个新版本知识库，发布前做一个新旧版本对比测试，确认无误后再切换。还要留意类似Dify知识库批量处理时出现的排队现象，那是Embedding任务积压的信号，不是拿用户说“模型繁忙”就锁到模型头上的借口。

其次，多版本文档一定要做版本管理。知识库里的文档会随着产品迭代更新，同一份操作手册可能同时存在V2、V3两个版本。如果库里混杂新老版本，模型有时候会回答新版内容，有时候又会引用老版内容，用户根本分不清对错。我现在强制要求每条知识数据都带版本号和生效日期，检索时按版本做过滤。

第三，行业知识库一定要做术语归一和同义扩展。农业场景里“浇水”和“灌溉”是一回事，法律场景里“甲方”和“委托方”可能指同一方，你需要一份行业同义词表，或者用豆包等大模型工具批量抽取关键词和别名，做一个语义映射。这步做完，检索效果会有肉眼可见的提升。

还有一点，图片和表格不是“库里的装饰品”。我看到很多人在“RAG知识库能存储图片吗”这个问题上纠结，却没有意识到问题的本质是结构化信息提取。技术手册里的接线图、参数表、流程示意图，最终都要变成文本或者多模态向量才能参与检索和生成。不要再把图片原封不动丢进去，那只会让知识库变成一个好看的图片文件夹。

整体构建完成后，我有另一个很深的体会：知识库工程质量对项目成败的影响，远远超过模型服务的水平。我把这套改造流程复制到后来的几个项目上，尤其是农业技术问答和类似专利辅助检索的场景，知识库的命中率普遍从两成多涨到七成以上。现在每次再遇到项目回答质量不行，我已经不会再急着换模型了，先把知识库这只“木桶”补好，才是性价比最高、也最扎实的一条路。