企业官网建设流程全解析

1. RAG 为什么在企业知识库里频频翻车

先说个扎心的现状：我接触过的几十个企业知识库项目里，真正把 RAG（Retrieval-Augmented Generation，检索增强生成）用明白的，十个里面不到三个。剩下的要么是“看起来能回答”，要么是“回答得一本正经但完全不着调”，要么干脆直接跟你说“我不知道”。

其实绝大多数人没搞清楚一件事——RAG 本身并不是一个“开箱即用”的答案系统，它是一个由多个环节组成的链路。任何一个环节出问题，最后呈现出来的都是“答非所问”。

企业知识库上 RAG 这件事，跟你想象的不太一样。它不是装一套开源框架、把 PDF 扔进去、然后就能像 ChatGPT 一样对答如流。它更像你在公司里带一个新员工——你把资料全部丢给他，他不一定能办好事情，你得告诉他哪些资料是权威的、哪些信息要优先参考、什么样的提问应该走什么样的流程。

答案离谱，根因几乎都出在同一个地方：你跳过了“知识工程”，直接做了“模型接入”。

我见过太多团队把 RAG 当成一个“Embedding 加向量库”的组合，觉得只要把文档切片、向量化、存进 Milvus 或者 Qdrant，然后接上大模型 API，就万事大吉。但现实是，这样的系统跑在真实业务场景里，召回率低得惊人，甚至有时候召回的片段跟问题是两码事。

先别急着甩锅给大模型。我们一步步把这个链路拆开看，你大概率能发现自己项目里到底哪个环节出了问题。

2. 找准病灶：六个环节逐一排查

一条典型的 RAG 链路是：文档解析 → 文本切片 → Embedding 向量化 → 向量检索 → 重排（Rerank）→ 大模型生成回答。很多团队只关注了“向量检索”和“大模型生成”，前面三个环节基本是拿默认配置应付过去的。

可偏偏问题就藏在那些“觉得没什么好调的”地方。

2.1 文档解析：垃圾进，垃圾出

企业知识库里的文档格式千奇百怪。PDF 算是最客气的，还有 Word 里的文本框、PPT 里的图形备注、扫描件里的图片、Excel 里的合并单元格。很多切片工具拿到 PDF 就直接按文本流提取，表格被拆得七零八落，页眉页脚混在正文里，图表里的关键结论一个都没抽出来。

这不是工具的问题，而是预处理策略的问题。我给你一个参考标准：一份 100 页的产品手册，解析出来的有效文本如果低于 60%，那这个 RAG 项目从源头就注定是答非所问的。

处理思路是这样的：先建档级梳理，把知识库里的文档按结构类型分成“强结构文档”（如操作手册、技术规范）和“弱结构文档”（如会议纪要、邮件往来）。强结构文档优先用版面解析工具（比如 PaddleOCR 的版面分析模块，或者市面上商用的文档智能解析服务），保留标题层级、表格结构和阅读顺序；弱结构文档用常规解析就行，重点是去噪——去掉回复链路的“转发”“回复”标记，去掉签名档，去掉无关的页眉页脚。

顺带提一句扫描件。如果企业知识库里存在大量扫描版合同、扫描版技术图纸，OCR 这步省不了。我建议先用图像方向矫正和质量过滤，把模糊页面筛掉再去识别，识别效果会提升不少。别指望 OCR 一次到位，这类文档得有个“预处理 + 人工抽检”的流程。

2.2 文本切片：不是切得越短越好

切片策略是 RAG 里最容易被低估的环节。很多人直接按固定长度切——256 个 token 一段，或者 512 个字符一段，不管句子是否完整，不管段落是否结束，硬切。

这么干的后果就是：你的检索召回了一大堆“语义不完整的碎片”，大模型拿到的上下文是断裂的，它只能靠猜去补全，回答跑偏是必然的。

固定长度切片的问题在于，语言的语义完整性跟字符长度没有必然关系。一个完整的业务流程描述可能横跨 800 个字符，而一个条款说明可能只有 60 个字。把这两者按同样窗口切，前者被拦腰截断，后者被混入不相关内容。

更合理的做法是结构感知切片。也就是先识别文档的标题层级，以标题为单位保留内容完整性，再对长章节做二次切分。具体可以这样：解析出来的 Markdown 结构里，二级标题和三级标题是最天然的切片边界；对于没有标题结构的段落文本，再用固定窗口切，但要让窗口边界尽量落在句号、分号、段落结束符上。

关于切片大小，我做过一批对比实验，结论供你参考：

尾部加 overlap（重叠）也是必要的。overlap 的意义是防止边界语义被截断，一般取上一段结尾 1-2 句话，或者 10%-20% 的长度。别贪多，overlap 太大会混入大量重复内容，导致检索结果冗余，对大模型反而有害。

2.3 Embedding 选择：模型的差距比你想的大

Embedding 模型负责把文本转换成向量，这直接决定了“相似语义”能不能被正确匹配。国内团队常用的方案里，有 OpenAI 的 text-embedding-3-large，有智源的 BGE 系列，有阿里的 text-embedding-v3，还有 M3E 系列。说实话，每个模型都有自己的脾性，没有绝对好坏，只有合不合适。

一个特别容易踩的坑是：直接用通用领域的 Embedding 模型处理专业领域内容。比如做电力行业知识库，文档里全是“母线保护”“差动继电器”“励磁涌流”，通用模型对这些术语的语义建模非常弱，检索召回的片段经常跟问题差了十万八千里。

更稳妥的做法是领域微调。拿企业里一批真实的问题-文档对，做正负样本构造，用对比学习的方式对 Embedding 模型做二次训练。这块很多人嫌麻烦没做，但我可以说，做了微调的检索效果提升是肉眼可见的。哪怕是拿 500 组标注数据跑几个 epoch，效果都比通用模型直接上要稳得多。

实在没有微调条件的话，也至少做一次离线评测再决定用哪个基础模型，而不是打开 Hugging Face 看下载量选。评测方法后面第 4 章会展开说。

2.4 检索链路：单一向量检索的玻璃天花板

这一节是“答非所问”的高发区。

纯向量检索的问题在哪？它适合“语义相似”，但不擅长“精确匹配”。比如员工问“报销标准是多少”，如果知识库里有一句“单次出差报销上限为 1500 元”，向量检索大概率能找到；但如果问的是“报销标准是多少号文件”，需要精确匹配“XX 字〔2024〕12 号”这种字符串，向量检索的表现就非常不稳定，甚至会给你召回一个完全不相关的制度文件。

混合检索在这里是必须的。我的做法是：关键词检索（BM25 或者 Elasticsearch 的 term query）和向量检索并行，各自返回候选集，再用 RRF（Reciprocal Rank Fusion，倒数排名融合）合并排序。这么做的好处是对“精确 ID、编号、条款"的场景非常友好，同时对"语义相近但字面不同”的提问也能覆盖。

实际参数给一组参考：向量检索召回 top-50，关键词检索召回 top-50，融合后取 top-20 进入下一环节。注意融合不是简单取并集，RRF 的公式是给每个文档在两组结果里的排名取倒数然后叠加，排名越靠前的文档综合分越高，这是个很成熟的策略，实现起来也就二十几行代码。

再补充一个细节：企业知识库往往有硬性权限边界。不同角色的员工，应该只能检索到有权限的文档。但这跟 RAG 链路天然有冲突——RAG 为了召回率，会把范围扩大到整个知识库。所以权限过滤要放在检索前（元数据预过滤），不能放在检索后（召回内容再过滤），不然会有越权内容被送进大模型上下文。

2.5 重排 Rerank：从优秀到及格的关键一跳

先做一个对比：不加重排的 RAG，正确答案已经混在 top-50 候选里，但它排在第十位，大模型上下文窗口有限，只取了前五，结果答案没被送进去；加了重排之后，正确的片段被拉到第一位，大模型生成的答案自然就对了。

Rerank 模型的作用就是对候选片段做一次精排，它跟 Embedding 模型是两个维度的建模。Embedding 是把文本映射到向量空间算相似度，Rerank 是直接判断“这段文本和这个问题有多相关”，精度更高，但计算成本也更高，所以只能用于对少量候选做排序。

我在项目中用 BGE-reranker-v2-m3 这类开源模型比较多，效果不错，而且能在本地部署。流程是：混合检索召回 top-50，Rerank 精排取 top-5 到 top-10，拼入大模型上下文。就多这一个环节，回答准确率能提升至少 20 个百分点。

2.6 上下文组装：不要让模型去猜

最后一道工序是给大模型组装参考上下文。这个环节有两个高频问题。

第一，上下文里装了太多不相干的片段。很多人把 top-10 的片段全塞进提示词，里面有五段是讲别的业务的，大模型分不清哪些才是真正回答问题的依据，于是把不相关内容也揉进了回答。解决方案是给每个片段设置相关性阈值，低于阈值的宁可不放。在回答不安全的时候，应该让大模型直接说“知识库中没有找到相关内容”，而不是硬编。

第二，没有给出推理指引。直接扔几个片段给模型，让它“根据以上内容回答”，模型并不知道这些片段的优先级和引用关系。我在提示词里通常这样写：“以下内容来自企业内部知识库，按相关性降序排列。回答时优先依据排序靠前的内容；若内容之间存在冲突，请在回答中明确指出，并标注信息来源名称。”稍微加几句这样的结构指引，回答的稳定性和规范性都会好很多。

3. 数据层面没做好，再好的模型也白搭

以上六个环节排查完了，还有一个维度很容易被忽略——知识库内容的组织方式。

3.1 检索不到 vs 知识库里压根没有权威答案

这是两种完全不同的情况。我屡次遇见运营团队提需求：“系统回答不了员工的问题，是不是模型不够好？”结果排查下来，答案确实存在知识库里，但藏在某份 PPT 的备注栏里或者某条聊天记录中，这种内容根本不该被纳入知识库。翻遍全部文档后确认：知识库里确实没有针对这个问题的直接答案。

检索不到，是工程问题，可以优化；知识库里没有权威答案，是内容治理问题，必须补内容或者明确告知用户无答案。一个合格的知识库系统应该是“可检索”和“可交付”两条腿走路，但前提是要先保证内容源本身是干净、完整、有效的。建议上线早期就要建立内容淘汰机制——过期的政策制度、已经被替代的操作流程，应当及时标记为失效或者移出检索范围，否则大模型会在新旧两版规则之间犹豫，给出的回答自然错。

3.2 标准文档入库前必须做“结构化清洗”

企业知识库跟互联网海量网页不一样，它有明确的结构和频密的术语。我建议在入库前做一遍降噪和增强：

• 去掉水印、页眉页脚、批注痕迹
• 把表格转成 Markdown 表格，保留表头结构
• 把操作步骤按编号还原成有序列表
• 对关键术语、产品名、内部编号做实体标注

这一套做完，知识库的查询命中率会显著提升。很多团队跳过这一步，直接把 PDF 文本切一切就入库，后面所有环节都在“垃圾数据”上做优化，纯属给自己挖坑。

3.3 知识图谱（KG）跟 RAG 的关系：要不要上，怎么上

我在热词里注意到最近“KG”和“ontology RAG”讨论很多。我的看法很明确：知识图谱不是 RAG 的必选项，它是 RAG 在某些场景下的增强组件。

先说什么时候该上知识图谱。如果你面对的是强关联、多跳查询密集的场景——比如“查询所有供应商中，与 A 项目签订合同金额超过 100 万且近一年有违约记录的供应商”——这类问题靠向量检索几乎无解。因为答案分散在多份合同、多个实体关系的交叉里，向量模型没有这种多跳推理能力。

这时候知识图谱就有用了。你把企业里的供应商、合同、项目、人员建模成实体和关系，存入图数据库（比如 Neo4j），查询时先用 NL2Cypher 把自然语言转成图查询，把实体关系子图作为上下文喂给大模型。这种方法查询精度高，但对知识建模的要求也极高。

我可以给你一个判断标准：如果知识库里的内容主要是流程制度、操作手册、FAQ，逻辑关系不深，那就别上知识图谱，把混合检索和重排做好就够了。如果知识库涉及强关联分析（供应链关系、资产归属、合规交叉检查），那知识图谱值得引入。

再补充一点：RAG 和知识图谱完全可以协同。你可以把知识库的文档按实体关系建索引，用图谱做实体链接和关系扩展，用向量检索做语义召回，两者结果融合后再让大模型生成回答。这种方式在金融和制造行业的复杂咨询场景里效果非常好。

3.4 结构化知识库 vs 非结构化知识库：两者应用场景大不同

这组概念最近在圈子里讨论热度很高，很多人把它们对立起来，其实没必要。

结构化知识库，本质上是把内容整理成标准字段和互相关联的记录，适合存储“员工信息、产品参数、订单状态、库存数量”这类强数据约束的信息。它的特点是查询精确，回答可控，但构建成本高，不适合承载发散性内容。

非结构化知识库，就是传统意义上那些 PDF、Word、网页内容，适合存储“经验总结、操作指导、方案文档、培训材料”。它覆盖面广，构建成本低，但查询是模糊匹配，答案容易出现偏差。

实际项目里，这两类应该共存。比如做售后知识库，产品参数和故障代码放在结构化库里，维修操作说明放在非结构化库里。用户问“某设备的额定功率”，走结构化查询通道，直接给精确数字；用户问“设备过热怎么办”，走非结构化检索通道，给出维修手册里的处理步骤。把两类内容混在一个通道里用向量检索去找，是典型的“通道错配”，效果自然差。

我建议架构上分通道处理：精确查询走规则或 SQL/图查询，语义查询走 RAG 链路，最后在提示词层融合。这也是为什么现在业内更愿意把这类系统叫“Agent + 多源检索”，而不是单纯叫 RAG。

4. 落地实操：评估先行，优化在后

4.1 先做检索质量评估，再谈模型调优

我发现一个普遍现象：很多人优化 RAG 一上来就想着换个大模型，或者调 temperature，这属于本末倒置。大模型只是链条的最后一环，它本身不是答非所问的主要根源。

正确的顺序是：先评估检索环节，再评估生成环节。这一步需要构建一个评测集，我一般建议至少准备 100 条真实问答对。这些问答对要从真实业务场景里抽取，覆盖高频问题、冷门但重要的问题、以及刁钻的跨文档问题。

评测指标可以参考 RAGAS（RAG Assessment）框架里的四个维度：

如果召回率低，问题出在解析、切片、Embedding、检索链路这四块；如果召回率还行但精确度低，问题出在重排和上下文组装；如果召回和精确都及格但忠实度低，再去考虑大模型提示词和上下文窗口。

4.2 一个可以照抄的 RAG 实施配置方案

给一套我在实际项目中验证过多次的配置，供你参考：

• 文档解析：PaddleOCR 版面分析 + 自研结构还原脚本
• 切片：结构感知切片，标题边界优先，最大长度 800 token，overlap 10%
• Embedding：BGE-large-zh-v1.5（如领域特殊，做对比学习微调）
• 向量库：Milvus 或 Qdrant，索引类型 IVFFlat 或 HNSW
• 混合检索：BM25 + 向量检索，RRF 融合，取 top-50
• 重排：BGE-reranker-v2-m3，精排取 top-5
• 大模型：通义千问 / DeepSeek / 智谱 GLM，均可作为底座
• 提示词：结构指引 + 优先级说明 + 拒绝机制

这套方案在普通规模的内部知识库上，检索精度达到 85% 以上是很现实的。

4.3 Mac 上也能低成本搭建/RAG 验证

评论区有人问 Mac 上能不能搭 RAG。能，而且现在比想象中容易。M 系列芯片的 Mac 跑本地模型很顺手，如果你只是验证效果，不需要上生产级系统，用 Ollama 拉起一个本地大模型，比如 qwen2.5 7b，再配一个 Docker 里跑的 Qdrant 或 Chroma，方案用 LangChain 或 Dify 做编排，几百行代码就能跑通一个最小可用的 RAG。前期拿这个环境去测试切片逻辑、提示词模板、检索效果，比直接在服务器上反复调效率高得多。

再说个细节：开发归开发，评估一定要在贴近生产环境的数据上进行，不然 Mac 上的“感觉不错”一到真实企业知识库就会翻车。

5. 一个完整排障案例实录

分享一个我印象特别深的项目。一家中型制造企业，把一整套设备运维手册做成了 RAG 知识库，功能上线之后总部来了投诉电话，说“回答完全不对”。

我接手排查，按照 RAG 链路一步步过：

第一刀切在解析。我没急着看模型，先把源文档抓出来检查，发现运维手册的 PDF 里大量页面是三栏排版，解析出来的文本把三个栏目的内容穿插在一起，读起来完全不是正常人说话的语序。这是典型的版面解析失效。

第二刀切在切片。手册里有大量带编号的维修步骤，按固定长度切片之后，步骤 3 的开头在一段，步骤 3 的结尾和后缀事项在另一段，语义被截断，大模型根本拼不出来龙去脉。

第三刀切在检索。因为前面两层的偏差，向量检索召回的大部分是设备基础参数介绍，看不到真正描述“故障判断流程”的内容。重排模型虽然把正确的片段往前拉了，但正确片段本身是残缺的，拉前也没用。

这个案例的根因并不是“模型不行”，而是最前端的文档解析和切片就把数据搞坏了。后来换了版面感知的解析方案，把重排版按阅读顺序还原；切片改成按步骤编号作为边界，步骤再长也不轻易断开；检索阶段加了关键词兜底，把手册里的“故障代码表”纳入精确匹配。整改之后，同一套大模型，回答准确率从 40% 不到直接拉到 85% 以上。

这给我一个特别深的体会：RAG 跑不好，八成不是模型的问题，是数据工程的问题。你前面的管线脏了，后面一切优化都是负功。

6. 常见问题速查与避坑清单

避坑清单再补充几条经验：

• 生产环境务必保留原始文档的元数据（部门、创建时间、版本号），检索结果按权限过滤才会灵活。
• 大模型生成的所有回答，最好附上引用来源（文档名+原文片段）。企业知识库的可信度全靠引用支撑。
• 日志系统要记录每次问答的检索候选和最终参考片段，不然出问题你连回溯都做不到。

关于权重设计的细节，我用过一段时间的融合参数：向量检索得分和 BM25 得分的权重按 0.5:0.5 起步，如果你发现精确匹配需求高，可以逐渐调成 0.4:0.6。没有绝对标准，但一定要在评测集上验证调整，別凭感觉随手改。

我个人在实际操作中的体会是：每次排查“答非所问”类问题，我都会提醒自己先问一句“数据管线是否是干净的”，再谈模型怎么调。RAG 工程的本质是数据工程，这句话值得每个准备做企业知识库的团队写在墙上。先把数据治理、切片策略、检索质量这三块地基夯实，再讨论模型选型和推理技巧，顺序别反了。