企业官网建设流程全解析

一个央企知识库项目，让我看到了AI落地的复杂

先交代背景：我去年底参与了一个央企集团级知识库项目，目标是把它沉淀多年的制度文件、技术标准、项目文档、历史档案做成一个能“问一句就给答案”的AI知识库。项目不算大，预算不算少，周期将近十个月。做下来最深的感受是：AI落地这件事，真正的复杂度从来不在模型本身，而在模型前面那些看起来不AI的环节——数据、组织、权限、链路、评测、运维。这篇文章就是我个人在项目里的完整复盘，包括踩坑、选型思路和一些可以直接复用的操作经验。如果你接下来要做企业级知识库，尤其是面向央国企这类对安全、权限、可靠性要求极高的场景，这篇内容应该能帮你省不少时间。

1. 这个项目到底在解决什么问题

1.1 需求方眼里的“简单”和交付方眼里的“复杂”

项目立项时候，业务方的预期很直观：把集团内部的制度文件、技术规范、历史项目报告整理到一起，员工通过一个对话入口就能查到“出差报销标准是多少”“某型号设备的维护周期是什么”这类问题。在他们看来，这就像把文件放进一个网盘，再加一个机器人聊天框，没理由做不出。

但实际上，这背后的链路长到超出大多数人想象。我先列一下项目真正要处理的几层内容：

• 数据层：文档格式五花八门，PDF、Word、Excel、扫描件、老旧的图片型档案，甚至有一部分是带有密级标识的制度文件。
• 组织层：集团总部、二级单位、三级单位，不同组织对同一份文件的访问权限不同；同样是制度文件，有些面向全员，有些只允许特定岗位查看。
• 语义层：不少问题是跨文档的，比如“某个项目的结算流程合规吗”，需要把合同模板、审批制度、历史案例、财务规定串起来才能回答。
• 交付层：必须私有化部署，不能走公有云API；模型能力受限；国产化环境要求；还需要有完整的审计记录。

从这时开始，我就意识到这不是一个“RAG框架套上去就行”的项目，而是一个涉及知识治理、权限模型、检索优化、生成控制、部署运维的系统工程。知识库只是外壳，内核其实是组织知识资产的数字化治理。

1.2 为什么传统搜索没有解决，偏偏要上AI

央企内部其实早就有了OA系统、文档管理系统、甚至专业的档案系统，搜索功能也都存在，但使用率一直不高。原因很现实：传统搜索是“关键词匹配”，员工得知道文件里大概有什么词才能搜到；而员工实际提问是“我要报销，流程是什么”，这两者之间的语义鸿沟非常大。

AI知识库的核心价值就是把“关键词匹配”升级为“语义匹配”，让用户用自然语言提问，系统去理解意图并召回相关文档片段。听起来不难，但当你面对的不是几百篇文档，而是十几万份文件、几十个业务系统导出数据的时候，语义匹配的稳定性就会成为最大的问题。后面我会详细讲我们是怎么通过混合检索和重排模型去解决这个问题的，这些都是方案设计阶段就要想清楚的事。

2. 数据治理：知识库落地的第一道坎

2.1 文档“丢进去就行”是一句非常危险的话

很多项目组在启动时会忽略一个事实：知识库的效果上限取决于喂给它的文档质量。集团给我们的初始数据里，PDF占了大约六成，但其中超过三分之一是扫描件，没有文本层；还有一部分是从老系统导出的Excel表，一张表里塞了两三种结构，表头还不在第一行。

如果直接把这些数据切块后灌入向量库，结果会很酸爽——检索时召回的片段全是乱码、残缺表格和OCR错字。我们第一批内测语料就是这么做的，测试集命中率不到四成，相当惨。

所以开工之后，我们花了将近一个半月专门做数据清洗和结构标准化，工作内容包括：

• 扫描件OCR识别：用PaddleOCR做文字识别，针对部分清晰度低的档案做了图像增强处理提高识别率。
• 格式统一：把所有文档转成统一的文本格式，并保留结构标签（如标题、段落、表格、页眉页脚）。
• 表格重结构化：将Excel和Word中的表格解析为Markdown表格文本，方便后续Embedding模型理解结构语义。
• 密级和权限字段抽取：从文档目录和文件属性中提取密级、适用范围、所属部门等元数据。

这一套做下来，数据质量才勉强够用。一个很深的体会是：知识库项目的前半段通常不是AI项目，而是数据治理项目。不要觉得这部分工作没技术含量——恰恰相反，它直接决定了后面算法环节的天花板。

2.2 Chunking（切片）的尺寸，决定了检索的天花板

数据清洗完之后，下一步是决定怎么把文档切成知识片段。这个环节看着简单，藏着的坑却不少。

切片策略主要考虑三个因素：模型支持的输入长度、检索召回粒度、语义完整性。我们当时用的Embedding模型支持最长512个token，所以最开始设的是每段256个token、重叠32个token。结果内测发现：像“报销标准”这种带有明确数值和条件的段落，被切碎后经常把数额和适用条件拆到两个片段里，导致回答缺失关键约束。

后来我们把策略改成“结构感知切片”：优先按文档的标题层级切分，每个二级标题下的内容作为一片；若内容过长再按段落拆分，尽量保证一段完整的语义单元落在一个chunk里。用这种方式，检索命中率明显提升，尤其是制度类文档，效果比固定长度切片好很多。

补充一个实操建议：切片时一定要保留文档的元数据标签，比如“来源部门”“文档编号”“密级”“发布时间”。这不仅是权限过滤的需要，也是回答里做引用溯源的基础。我们一开始没把“发布时间”纳入检索过滤条件，后来问“现在出差住宿标准是多少”，系统经常把五年前已经废止的标准召回出来，教训很大。

2.3 表格数据，单独走一条处理通道

央企知识库里表格类内容非常多：设备参数表、费用标准表、审批权限表、项目进度表。表格这种结构化数据，直接转成文本丢进向量库，效果非常差——因为文本化之后的表格，行与列的对应关系很容易丢失。

我举个例子：一张“差旅费报销标准表”，包含“职级、城市类别、住宿标准、交通标准、伙食补助”五列。转成纯文本后，Embedding模型很难学到“副总经理在北京市的住宿标准是500元”这种多列组合关系。用户问“处长在北京出差能住多少钱一晚的酒店”，系统可能召回整张表，但答案片段里没有准确的对应关系，大模型就容易胡编。

我们的处理方案是：把表格转成Markdown格式后单独建立一套结构化知识索引，同时在检索链路中增加一个“表格识别”分支——当判定用户问题涉及数值、条件、规则类信息时，优先走结构化检索通道，返回精确行数据，而不是通篇向量检索。这个改动上线后，标准类问题的准确率提升了将近20个百分点。

3. RAG链路与Agent化改造

3.1 关键词混淆与混合检索的必要性

知识库的问答不是简单的“向量检索+大模型生成”两步走。向量检索擅长语义相近，但对精确关键词不敏感；而央企文档里大量信息是靠“编号”“标准号”“部门名称”来区分的。比如“根据Q/SY 0381-2020标准执行”和“根据Q/SY 0381-2017标准执行”，语义几乎一样，但完全是两个版本，用纯向量检索很容易把旧版本也召回。

我们最终采用的是混合检索方案：向量检索和BM25关键词检索并行，各自取回TopN结果，然后进行结果融合。融合算法用的是RRF（Reciprocal Rank Fusion），对两条召回结果做加权排序。BM25保证精确编号和术语的匹配，向量检索兜底语义泛化，两者互补之后，召回质量才明显稳定下来。

这里有个细节值得说：混合检索不是简单地把两路结果拼在一起，而是要调整权重。我们的配置是：向量检索Top50、BM25检索Top30，RRF后取Top10送入重排模型。为什么取这么多？因为后面还有一次精排，前面的召回要“宁滥勿缺”，防止漏掉正确答案。

3.2 重排模型：被很多人低估的一环

项目中期我们做过一次对比测试：不加重排链路，直接取混合检索Top5送入大模型，准确率大约在62%；加上重排模型，对混合检索Top10进行精排后取Top5，同一测试集准确率提升到79%。

这个提升幅度接近17个百分点，远超我们预期，也让我彻底意识到重排不是“可选优化”，而是RAG链路里极其关键的一环。重排模型做的事情很简单：对召回的候选片段，逐一计算与用户问题的语义相关度，重新排序，让最相关的片段排到最前面。它能有效纠正向量检索带来的“表面相关、实际不相关”问题。

选择重排模型时我们比较过几款，最终选了BGE-Reranker系列，主要是考虑到私有化部署环境对模型体积有限制，这个模型在效果和资源占用之间比较均衡。推理服务用FastAPI封装成一个独立的rerank服务，和主服务通过HTTP调用。

提示：如果你计划在项目里加重排，一定要在方案阶段就预留GPU资源，而不是等项目上线前才补。重排模型虽然不大，但推理频率高，吃GPU显存不是小数目。

3.3 多跳问答：如何让Agent拆解复杂问题

知识库上线第一周，就暴露了一个之前没测透的问题：用户问的很多问题不是单片段能回答的。比如“我们签订的某项目合同结算，需要经过哪些流程？涉及哪些部门？”这个问题至少涉及合同审批制度、结算流程规范、部门职责分工三份文档。用传统的“召回一个片段、生成一个答案”模式，只能回答其中一部分，回答得又碎又浅。

我们后来引入了一个轻量级Agent方案，思路是三步：

1. 意图识别：先用大模型判断问题是一个单跳问题还是多跳问题。
2. 子问题拆分：如果是多跳问题，把原问题拆解成若干独立子问题，比如上面的例子就拆成“合同结算流程是什么”“审批过程中涉及哪些部门”“流程中的关键节点有哪些”。
3. 分步检索与汇总：每个子问题走一遍检索+重排，拿回答案片段，最后统一汇总生成最终答案。

这个Agent不能复杂，越复杂越容易失控。我们用的是一个很简单的状态机逻辑：最多拆分三个子问题，每个子问题检索Top5，汇总时只基于检索片段二次生成，不允许模型无中生有。这样既解决了复杂问题，又保证了可控性。

3.4 幻觉控制：宁可说“不知道”，也不要编

央企场景对AI知识库的要求，和面向C端聊天机器人完全不同。制度问答里如果模型给出一个错误的标准数值，轻则报销被打回，重则可能引发合规问题。所以我们在“幻觉控制”上花了很大的精力，核心策略是：限制生成来源，强制引用。

具体做法有三条：

• 所有回答必须基于检索到的片段生成，Prompt里有硬性约束：“如果给定材料中找不到答案，必须回答‘未在现有知识库中找到相关信息’”。
• 大模型输出答案时，必须标注来源文档编号和原文片段引用，方便用户回溯验证。
• 对制度标准类问题，采用“抽取式+摘要式”混合策略：涉及具体数值、编号、条款的内容，直接从原文片段抽取，不经过大模型二次转述。

这套规则下来，测试集的“无中生有”类错误从7.2%降到了1.1%左右，基本实现了“可控”。虽然牺牲了一定程度的流畅性，但在企业场景里，准确性远比文采重要。

4. 权限、私有化和上线后运维的复杂

4.1 央企的权限矩阵，比技术方案复杂得多

如果说数据和链路层面的复杂度是技术性的，那权限体系就是组织性的。知识库里既有面向全员公开的制度文件，也有只允许二级单位分管领导查看的内部材料，甚至还有部分标注“内部资料，不得外传”的历史档案。如果权限在检索阶段没有生效，任何一个不该看到内容的员工问到敏感信息，都是重大事故。

我们在实施中把权限体系拆成两层：

• 文档级权限：每一份文档入库时打上权限标签，包括可见范围（全员/某部门/某职级以上）和密级标识。
• 检索级过滤：用户发起检索请求时，系统根据用户身份（部门和职级）实时计算可见文档集合，检索时只对这个子集进行向量匹配和关键词匹配，而不是全量库。

这个设计听起来简单，实际落地时遇到了不少麻烦。最典型的问题是：一份文档被引用到另一份文档中，可见范围到底以哪份为准？比如一份公开制度里引用了某份内部标准文件，用户问起这个引用条款时，系统会不会把内部标准也输出出去？

我们的方案是“引用隔离”：检索片段中如果包含对其他文档的引用信息，且用户对该文档无权限，则回答中自动隐藏引用细节，只保留当前可见内容。牺牲了一点完整性，换来了安全合规的底线。

4.2 模型私有化部署，不是“装个模型”那么简单

由于数据不能出域，整个AI链路必须在央企的内网环境私有化部署。这涉及Embedding模型、重排模型、大语言模型三个推理服务的搭建，每一步都有坑。

先说大模型选型。我们评估过几款开源模型在央企知识问答场景下的表现，最终选了Qwen系列中尺寸适中的版本，原因是它在中文理解、指令跟随、抽取能力上比较均衡，而且中文社区资料丰富，遇到问题好排查。模型量化使用的是INT8，把显存占用压下来一半多点，速度提升了接近30%，效果损失在可接受范围内。

这里给一个显存计算的参考公式：

• 模型推理显存 ≈ 参数(GB) + 激活显存(约参数量的20%左右) + 推理缓存
• 一个7B模型FP16权重约14GB，INT8量化后约7GB，再加上KV Cache和激活值，单卡16GB勉强够单实例跑。

我们当时为了并发稳定，用了一张24GB的卡跑大模型，重排用一张消费级卡就够，Embedding模型对资源要求最低，CPU推理也能跑。整个部署采用Docker Compose编排，各服务独立容器，统一走内网API网关。

注意：不要在一开始就追求最大模型。知识库问答中绝大部分问题都是抽取和改写，不需要特别强的复杂推理能力。一个大而全的模型不仅部署成本高，推理速度慢，还容易在细节上过度发挥，反而不利于精确控制。

4.3 评估、回灌与效果迭代：上线才是开始

项目上线后我们持续做了三个月的运营监控，发现线上用户问的问题和测试集差距非常大。测试集里我们问的是“《采购管理办法》中超过多少金额需要招标”，而用户实际问的是“我们部门买个服务器，是不是一定要走招标流程，自己招标行不行”。前一个是单点查询，后一个是实际业务推理问题，难度高了一个量级。

为此我们建立了一套评估回灌机制：

• 每周从线上对话日志中抽取出回答质量差的问题，人工标注正确答案。
• 将标注数据加入测试集，重新跑检索和生成评估，看效果变化。
• 每周更新一次Embedding模型的重训练数据（可选）或调整切片和检索策略。
• 对反复出错的问题，人工补充知识文档，把隐含的“多文档推理”变成更细粒度的知识片段。

这套闭环跑起来之后，线上问答好评率明显上升。一个直接感触是：知识库不是建完就能完事的，它更像一个有生命的系统，需要持续喂数据和反馈才能维持效果。

5. 常见问题速查与经验总结

最后整理几个我们项目里最具代表性的问题和处理办法，供参考：

经验层面上，我真心建议后面做类似项目的团队，在立项时就把下面三件事谈清楚：

• 数据质量是最大的交付物。不要急着上模型，先花时间把文档清洗、切片、元数据标注做扎实，否则后面每一步都是返工。
• 明确权限和合规边界的责任人。技术方案能做的事只是“按权限标签过滤”，标签和权限规则需要业务方明确拍板，项目经理和法务或保密办共同确认。
• 评测集建设是保命手段。不要凭感觉说效果变好了，建立一份覆盖常见场景的测试集，每次改动都跑一遍，所有优化过程全部数据化。

我在实际操作中还有一个体会：央企知识库这类项目，和互联网产品的AI落地是两个物种。互联网产品追求“惊喜感”，回答越聪明越好；央企知识库追求“确定感”，回答越稳越好、越能追根溯源越好。项目后期我们把Prompt和链路反复“做笨”，效果反而越来越好。做AI落地方案，最大的本事是在花哨和稳重之间找到那条适合业务场景的线，而不是一味堆新技术。希望这次的复盘，能帮你在踩坑之前就绕过这些泥潭。