一、一个反复出现的场景，把问题推到了台前
（一）开会前先找文件，成了这家集团的日常消耗
某能源行业头部集团的业务横跨资源开采、设备运维、工程建设和供应链保障，内部知识散落在各种地方。制度文件躺在行政系统里，设备手册归运维部门管，技术方案留在项目组的共享盘上，还有一批历史故障处理记录，只存在于几位老工程师的笔记和聊天记录里。跨部门协调会开始之前，参会的人往往要先花一段时间找资料，找到了还得互相确认版本对不对。
这算不上谁失职。用集团信息化负责人的话说，集团从来不缺文档，缺的是第一时间拿到正确那一份的办法。问题被反复提起，却一直没被真正解决。
（二）卡住的其实不是搜索技术
最早的想法很朴素：既然找不到，那就上一个搜索。全文检索系统并不是没试过，关键词敲进去，返回的列表长得让人发愁，用户还是得逐条点开看。搜索工具只能按字面匹配，它不知道停机检修流程和设备停运后怎么恢复说的是同一件事，也不清楚一份文件对哪个部门有效、哪个版本已经作废。
换句话说，问题不在检索快不快，而在知识本身没有组织好。文档没有分类口径，没有责任人，没有生效和失效的标记，任何搜索引擎接进来都会是同一个结果。这个判断后来成了整个项目的起点，也影响了企业知识库智能体的选型方向。
（三）通用大模型直接接进来，为什么不好使
集团内部做过一轮尝试。有人把一批制度文件丢给通用大模型，让它做问答。演示环节效果不错，一旦放进真实场景，问题就冒出来了：模型会凭印象编出流程里的节点，会把已经作废的条款当成现行规定，还会在答不上来的时候给出一个听起来很合理的错误答案。对能源行业来说，这样的回答比不回答更麻烦。
再往下追，才明白症结在哪。通用大模型缺的不是语言能力，而是这家集团自己的知识边界，哪些文件算数、谁能看、什么时候更新、答错了由谁负责。所以知识库智能体开发的重点，从第一天起就不是挑一个多大的模型，而是把知识理清楚，再让模型在这套边界里工作。
二、企业知识库智能体到底要解决什么
（一）知识库搭建是第一步，也是最容易被低估的一步
项目组把工作顺序倒了过来。以前做系统，习惯先定界面、先看效果；这次先不动界面，把时间花在知识库搭建上。
1. 先把文档收拢，再谈智能
集团抽调了各条业务线的人，按用途把文档重新归堆：制度类、设备类、工艺类、项目类、安全类。收拢过程中出现了不少意料之外的情况，同一份操作规程在不同部门有各自的版本，同一台设备的说明书有原厂版和内部修订版，还有些关键资料只有纸质扫描件。整理的人没有急着判对错，而是先登记，标明谁在用、用在哪。
2. 权限和版本要立在前头
这一步最琐碎，也最不能省。哪些内容全员可查，哪些只在部门内可见，哪些需要审批后调阅，都要有明确规则。版本问题同样如此，每份文件要有生效时间、修订记录和作废标记。项目组内部有个共识：权限和版本不提前定好，后面换什么模型都救不回来。
3. 更新机制决定这套系统能不能活下去
知识库最容易出问题的时候，是上线之后的日常。制度改了、设备换型了、流程调整了，如果没人负责更新，系统很快就会被当成不准的东西而弃用。为此，集团给每类知识指定了维护责任人，把更新动作接进原有的文件发布流程，文件在系统里发布新版，知识库同步跟着变。
（二）智能问答要答得准，也要说得清
1. 答案必须带出处
这是项目组在评审时定下的硬要求。员工提问之后，智能问答给出的回答后面要附上引用的文件名称和具体条款，点开能直接看到原文。有了出处，用户就能自己判断这条回答适不适用于眼前的场景，而不是把系统当成一台不容置疑的答案机器。
2. 答不上来的时候，要知道该找谁
知识库覆盖不到的边角问题一定存在。与其硬编一个答案，不如老实说明没有找到依据，同时把问题转给对应的责任部门。系统上线后，这些没被回答的问题反而成了最有价值的输入，它们清楚地告诉知识管理者，哪些地方还有空白。
（三）智能客服和内部问询，其实是两条线
对外和对内的需求差别很大。面向客户的智能客服，回答要统一、话术要规范，还要能接住投诉、顺畅转到人工；面向内部员工的智能问答，更看重专业细节和权限边界。集团的做法是把两套场景分开建设，共用同一套企业AI知识库底座，但在问答风格和可见范围上分别配置。同一批资料，对外只开放产品和服务相关的内容，对内才放开技术细节。
三、项目推进中真正的难点，跨部门协同
（一）业务部门要从提需求变成给答案
项目启动会上，一位业务负责人提了个很实在的问题：系统上线以后，谁来保证里面的内容是业务真正认可的？这句话把项目的重心从技术侧拉回了业务侧。后来形成的做法是，每个业务条线都派出熟悉流程的人，参与知识梳理和问题测试。他们不写代码，但要判断系统的回答靠不靠谱，要指出哪里说得不对。
这种参与一开始并不顺利。有人觉得是额外负担，有人担心把自己的经验交出去以后就不值钱了。项目组没有讲大道理，只拿真实的问题去测，让一线员工用平时的说法提问，看系统答成什么样。错误的答案摆在面前，业务部门的注意力自然就转到了怎么改上。
（二）IT部门的关注点：可控、可查、可维护
IT团队在项目里的角色更像守门人。他们关心的不只是问答效果，还有几件事：系统部署在哪里，数据会不会出去，出了问题能不能查到谁在什么时候问了什么、系统引用了哪份文件。这些要求看起来和智能不沾边，实际上决定了系统能不能在集团里长期跑下去。
推进过程中，讨论最多的反而是日志、权限和接口这些基础问题。等这些说清楚了，后面的功能推进速度明显快起来。
（三）国产化适配与源码交付，为什么被反复提起
作为集团级系统，部署环境本身就有限制。项目要求知识库智能体能在国产化软硬件环境中稳定运行，模型接入方式要留有余地，将来换模型或者增加模型时不需要推翻重来。同时，集团希望拿到源码，理由也很直接：知识库要跟着业务变化长期演进，把关键能力握在自己手里，后续调整才不用每次等外部排期。
数商云在这个项目里承担的就是这部分工作，提供智能体开发平台与知识库搭建能力，同时支持国产化适配和源码交付。用项目负责人的话讲，选型时看的不是功能清单有多长，而是以后我们自己能不能改得动。
四、上线之后，工作方式发生的那些变化
（一）新人上手不再靠追着问
能源行业的一线岗位，过去新人熟悉流程主要靠两件事：跟着老师傅跑现场，翻厚厚的手册。现在他们遇到流程类的疑问，会先在企业知识库里问一句，拿到带出处的回答，再对照原文确认。老师傅从重复回答里被解放出来，把精力放到现场指导和异常判断上。
（二）跨部门协作少了一道道转述
过去跨部门办事，信息要经过几轮口头转述，越传越走样。现在涉及制度依据的事情，员工可以直接在系统里查到条款原文，讨论时引用的是同一份文件，争论点从规定到底是什么，转到了这个场景适不适用。这是个不太起眼但影响很深的变化。
（三）知识开始被当成一项日常维护的工作
系统上线之后，集团内部多了一批知识维护的角色。他们定期看没有被回答的问题、看被反复追问的话题、看作废文件的清理情况。知识管理从一次性的整理动作，变成了持续运转的日常。这一点，比问答准确率更能说明项目是不是真的站住了。
五、复盘：这类项目做成与否，取决于几件不太技术的事
（一）先整理知识，再谈智能体
从这家集团的经验看，企业知识库智能体的效果，很大程度上在上线之前就已经定下来了。文档乱、版本乱、权限乱，模型再强也只能把混乱放大。反过来，知识底座扎实，规模普通的模型也能给出可信的回答。这也是为什么项目里花在知识库搭建上的时间，比花在模型调优上的时间多得多。
（二）找到愿意为内容负责的人
技术团队可以把系统做出来，但没法替业务判断哪条规程是对的。项目能往前走，靠的是各条业务线上那些愿意花时间看回答、指出错误、提供正确说法的人。他们的参与程度，往往决定了系统上线后是越用越准，还是慢慢没人用。
（三）把长期演进的可能性留出来
知识库不是建完就定型的项目。行业在变，设备在换，制度在改，系统必须跟着动。所以在选型和架构阶段，能不能自主调整、能不能换模型、能不能把新的知识源接进来，这些问题的答案比当下答对几个问题更重要。大模型应用真正走进企业，靠的往往不是某一次技术突破，而是这些看起来枯燥的基础安排。
（四）多个行业看下来，路径其实很接近
除了这家能源集团，制造业企业在处理设备维修知识时，零售企业在统一门店运营规范时，物流企业在梳理运输异常处置流程时，遇到的困境几乎一样：资料分散、口径不一、老员工的经验带不走。它们选择的路径也相近，先把知识收拢和分层，再让智能问答站到员工面前，把维护责任落回业务线。
如果所在企业也正被文档查找、经验传承、跨部门口径不一这些问题困住，欢迎联系数商云获取详细方案，也可以预约顾问交流或申请演示，先看一轮真实场景下的问答效果，再判断这条路适不适合自己。
评论