凌晨的装置区，某化工行业头部集团的值班工程师碰上机泵振动异常。放在过去，他的动作是先在班组群里发一条语音，再翻共享盘里那套不知道现行版在哪的操作规程，实在不行就打电话把已经下班的老师傅叫醒。那天他换了个方式，打开手机上的对话框，敲了一句很口语的话：这台泵振动大，先看什么。屏幕上很快给出几条处置建议，每一条后面都挂着引用来源，操作规程的对应章节、同类异常的检修记录、厂家说明书里的维护条目。他把引用逐个点开核对，确认无误，再联系中控调整负荷。
这个对话框背后，就是该集团和数商云一起做的企业知识库智能体。项目从技术文档检索这件看起来很基础的事切入，做到后来，逐渐长成一套覆盖现场问答、售后支持、新人培训的企业AI知识库。回头看整个过程，值得讲的不只是模型和平台，还有那些在会议室里被反复争执、后来才写进规则里的细节。
一、问题的起点：文档不缺，缺的是能直接用的答案
（一）一份规程要在好几个地方才能凑齐
该集团的装置建得早，工艺路线长，技术文档是长期一层层攒下来的。工艺规程在技术部门的共享盘，操作规程挂在班组的学习平台，设备说明书和设备台账在设备管理系统，检修方案和事故案例留存在安全与生产两边的档案里，厂家发来的技术资料常常还是邮件附件。同一个问题，往往要在几个系统之间来回跳。
值班工程师那次找答案的过程就很典型。他先要知道这台泵的振动报警对应哪一类原因，这属于操作规程；再要确认上一回同样的报警是怎么处理的，这属于检修记录；还得看一眼厂家对轴承间隙的要求，这属于说明书。这些信息分布在不同的地方，每一种都有自己的检索方式，而现场留给他的判断时间很短。
新人遇到这种情况更被动。没人带的时候，他连该去哪个系统找都不知道，只能问人。老师傅的经验确实管用，但经验停留在口头，写不进文档，也传不下去。人员流动一快，那些只在班组里流传的判断方法就跟着流失了。
（二）老检索为什么越用越没人用
集团此前也做过知识库搭建，上一轮的方案是典型的文件管理思路：把文档集中上传，做一个站内搜索框，按标题和正文关键词匹配。刚上线时大家还会点进去看，用久了问题就冒出来。
1. 人说的是口语，文档里写的是术语
现场的人问的是这台泵声音不对、油温上得太快、这个东西能不能停，文档里写的是机组异常振动、润滑油回油温度偏离设计值、非计划停车条件。关键词对不上，检索结果自然就偏。用户搜不到，第一反应不是换个说法再搜，而是判定这套系统没用。往后哪怕内容补得再全，他也不会再打开。
2. 一台设备有好几个名字
同一台设备，设计院图纸上用的是位号，操作工习惯叫俗称，设备台账里是另一套命名，厂家资料里又是英文缩写。搜其中一个叫法，只能捞到一部分文档，剩下的要靠人猜。要让检索认得全，就得有人把这些叫法整理成同义词关系。这件事在旧系统里没人做，靠个人也做不了，因为它需要设备、工艺、现场三方面一起确认。
3. 找到了也不敢直接用
最麻烦的一点是可信度。同一份工艺文件存在多个修改稿，命名规则不统一，有的带日期有的不带，用户搜出来一堆，根本判断不了哪一份是现行的。有人干脆绕过系统，直接找熟悉的人确认。系统越不可信，越没人用；越没人用，里面的内容越没人维护，这个循环在过去几轮知识管理尝试里都出现过。
二、项目起步：先把范围划小，再把口径谈拢
（一）第一次需求会，讨论的焦点不是技术
集团信息中心最初的想法很直接：做一套覆盖全集团的企业知识库智能体，把能接的系统都接进来，一次解决问题。数商云的项目团队提了一个不太一样的建议，先不要铺开。技术文档智能检索这件事，看起来简单，实际上牵扯的部门多、标准杂，一上来就全量覆盖，很容易做成一个没人验收的大工程。
双方最终选定的切口是某个装置区的设备检修问答。范围只覆盖一类设备，参与的业务方有限，需要整理的语料也收得住。信息中心的负责人在复盘会上说过，当时最担心的是业务部门觉得又是IT搞出来的东西，所以试点阶段的目标定得很克制：先让现场的人愿意用第二次。
这个判断后来被证明是对的。范围小的时候，语料里那些互相矛盾的表述、过时的说法、只有某个班组才懂的简称，都能被一条条翻出来谈清楚。等到第二批、第三批场景往里加的时候，团队已经有了一套跑顺的处理方式，不用每次重新摸索。
（二）语料治理花的力气，比模型选型多得多
真正开工之后，团队发现时间主要花在文档上，而不是算法上。
1. 先分类，再谈怎么切片
多年的文档，格式五花八门：扫描件、带批注的图纸、嵌套表格的规程、只有图没有文字的说明书。数商云团队先做的是分类，按用途把文档分成规程类、方案类、记录类、案例类、厂家资料类，不同类别用不同的解析方式。规程类要保住章节结构，案例类更看重事件经过和处置结论，厂家资料则要把表格里的参数对应关系提出来。
切片方式直接影响后面的检索效果。切得太碎，答案缺少上下文，用户看不懂；切得太整，检索命中不了具体那一小段，模型拿到的是一大坨无关内容。团队在试点阶段试了几轮，最后是按章节加问答对的方式混合处理，规程按目录层级切，检修记录按问题、原因、处置三段切。
2. 术语表是人一条条写出来的
同义词和别名的整理没有捷径。设备管理部出了一份常用叫法清单，生产技术部补了工艺侧的习惯说法，现场班组又提了一批只有一线才用的简称。数商云团队把这些整理成术语映射，再用它去校正检索。听上去是笨办法，但这部分做得越扎实，后面智能问答答得越稳。有人问过能不能让模型自己学，答案是可以学一部分，但涉及安全边界的叫法，还是得人来拍板。
3. 表格和图纸单独处理
化工文档里大量信息藏在表格里，参数表、检查项清单、物料对应关系。直接把表格当普通文本切，行列关系就散了，用户拿到的答案会对错行。团队的做法是保留表头与行的对应关系，让参数和它的适用条件绑在一起入库。图纸则只做索引，把图号、名称、适用设备和相关说明文字挂上去，用户问到时给出图纸所在位置，而不是硬把图纸内容转成文字，转出来反而容易出错。
（三）跨部门坐在一起，是为了定义什么算答对了
知识库上线后，最常被问到的一句话是：凭什么说这个答案是对的。
为了回答这句话，集团组了一个跨部门的小组。生产技术部负责工艺与操作口径，设备管理部负责检修与备件，安环部负责安全规程，客服与销售技术支持负责对外说法，法务和合规看外发风险，信息中心负责系统和账号。数商云在这个小组里的角色，是把各家的判断标准收集起来，写成知识库里的规则。
争得最厉害的一次，是关于安全相关的提问要不要给出处置建议。安环部的态度很明确，智能体可以告诉用户这种情况在规程里属于哪一类，可以指到原文，但不能给出替人做决定的结论。这条线后来被写进了回答规则：涉及安全边界的提问，智能体只做定位和引用，不做推断。类似的争论还有几处，比如未公开的工艺参数能不能进检索范围，客户问到的产能问题该由谁来答。这些事没有标准答案，只能一家一家谈。
三、知识库智能体开发中的几个关键设计
（一）检索层：先找得到，再谈答得好
数商云在这套系统里用的是混合检索的思路，关键词检索和语义检索并行，再通过重排序把最相关的内容提到前面。听起来是技术细节，落到现场就是很具体的差别。用户问换热器结垢了怎么处理，关键词检索能命中规程里写着结垢的段落，语义检索则能捞到那些只写了传热效率下降、压差上升的内容，两路结果合起来，答案的覆盖就完整得多。
引用来源的排序也做了调整。同一份文档，现行版本排在历史版本前面；有批准记录的排在草稿前面；一线反馈过用得上的处置记录会得到更高权重。用户看到的不是一个孤零零的答案，而是一份有先后顺序的依据清单，他自己能判断先看哪一条。
（二）回答层：答不出来的时候，比答错更危险的是硬答
大模型应用最容易翻车的地方，是它很会编。在化工场景里，一个编出来的参数含义很严重。团队在设计回答策略时定了明确的规则：答案里的每一句都要能追到具体文档的具体位置，追不到的句子直接删掉；检索不到足够依据时，智能体明确说没有找到相关依据，同时给出最接近的文档位置和可以求助的岗位；涉及外发内容的提问，直接路由到经过审核的对外口径。
这套规则刚上线时，用户会抱怨它怎么老说不知道。业务部门顶住了这个压力，没有为了让回答显得聪明而放松约束。后来的情况反过来了，因为回答总能点到原文，现场的人开始把它当成一个能找到依据的搜索入口，而不是一个信口开河的机器人。有人甚至养成了习惯，看完答案先点引用，点完再动手。
（三）权限层：谁能问什么，跟着组织架构走
知识库里的内容分两类，一类是所有员工都能看的通用规程和培训材料，一类是限定范围的，比如特定装置的操作细则、未公开的工艺参数、客户相关的技术资料。数商云把权限体系和企业现有的账号体系对接，用户登录后能检索到的范围，跟他所在部门、岗位、装置直接对应，不需要另外学一套规则，也不需要管理员手动加人。
对外场景的隔离做得更严格。面向客户的智能客服只接入经过审核的外发知识集，涉及内部工艺、成本、产能的问题一律不进入回答范围。有些问题是客户常问、但内部资料里没有合适说法的，就由技术支持部门补写标准答复，走完审核再入库。这条流程定下来之后，客服人员不用再凭经验拿捏哪些话能说。
（四）交付层：源码交付和国产化适配，是信息中心提的要求
作为集团级项目，信息中心对交付方式有明确要求。数商云采用的是源码交付，集团的开发团队拿到代码之后，可以自己接入内部系统、调整界面、做后续的功能扩展，不必每次都等外部团队排期。运行环境方面，系统适配了国产化的服务器、操作系统和数据库，符合集团对基础设施的合规要求。
这两件事在项目初期看着像额外条件，到后期反而成了推进速度的保障。信息中心能自己处理一部分集成工作，业务部门提的小需求不用全部排在外部团队的队列里，改完就能测，测完就能上。
四、上线之后，变化藏在日常动作里
（一）现场处置：先查依据，再打电话
以前遇到异常，第一个动作是找人或发群消息。现在不少班组的第一动作是打开智能问答，把问题按自己的说法讲出来，拿到几条处置建议和对应的引用文档，核对之后再决定要不要升级。这个顺序的变化看起来不大，实际影响不小。老师傅不用再被反复打扰那些手册里其实写了的问题，可以把精力放在真正罕见的工况上。而每一次提问和引用的记录，也成了后续补文档、补术语的素材。
（二）客服与售后：口径统一，但边界清楚
该集团的客服和技术支持团队原来各自维护一套问答文档，遇到复杂问题就转给工程师，转接过程中信息容易丢。现在智能客服承担了前置的应答工作，标准问题的回答口径统一来自同一个企业AI知识库，回答里带引用，用户可以自己看依据。转人工的时候，对话记录和已经检索到的资料一并带过去，工程师接手不用从头问一遍。
对外回答的边界也明确下来。智能客服只答审核过的内容，遇到超出范围的提问直接说这个问题需要工程师确认，然后走转接流程。客服人员反而觉得轻松，因为不用再自己承担判断口径的责任，系统里写清楚了什么能说、什么不能说。
（三）研发与培训：把翻手册换成提问加核对
技术部门用它的方式不太一样。做工艺变更或者设备改造方案时，工程师会先问一遍历史情况，类似的改造以前做过没有、当时遇到过什么问题、相关的评价报告放在哪。检索出来的引用清单，直接成了方案附件里的参考资料，比凭记忆去翻档案省事得多。
新人培训的变化更明显。过去的带教方式是发一套资料自己看，看完也不知道记没记住。现在的做法是让新人用智能体做练习，自己提问、自己核对原文，带教师傅抽查引用是否正确。判断一个新人有没有上手，看他能不能问出好问题、能不能判断引用是否对得上，比看他背了多少条规程更实在。
五、复盘：企业AI知识库项目里容易被忽略的几件事
（一）这不是一个IT项目
推进过程中最耗时的环节，全部发生在业务侧：定义什么算正确答案、整理术语、确定哪些内容可以对外、谁来审核新入库的材料。数商云在能源和物流行业的头部企业里也遇到过类似的情况，IT部门推动力很强，但如果业务部门只当配合方，知识库搭建起来也很难持续更新。这个项目能往前走，是因为生产技术部和设备管理部各出了固定的对接人，全程参与语料评审和回答抽检，遇到争议当场拍板，不用层层往上递。
（二）评价标准不是像不像人
有一段时间，业务部门会拿几个刁钻问题去考智能体，答不上来就认为效果不行。项目组的看法是，用这种方式评价大模型应用意义不大。真正该看的是：回答的引用能不能点开、点开之后原文是不是支持这个说法、查不到依据的时候系统有没有明确说明。宁可它老实说没找到，也不要它流畅地编一段出来。这个共识花了一些时间才建立起来，但它决定了后面所有优化动作的方向。
（三）上线只是开始
文档在更新，装置在改造，人员在流动，知识库如果没人管，时间一长就会失真。集团把维护职责分到了各业务部门，新发布的规程、修订的操作步骤、典型事故的复盘结论，都有对应的入库动作和审核人。信息中心负责系统运行和权限维护，数商云负责平台的更新和技术支持。这套分工写进了运维手册，不依赖某一个人的记忆，也不依赖外部团队随时在场。
从技术文档智能检索这个切口进去，该集团拿到的其实不只是一套能问话的系统。检索路径从分散走向集中，跨部门的判断标准从口头默契变成了写下来的规则，一线经验有了可以回查的记录。企业知识库智能体开发这类项目，难的地方往往不在模型本身，而在于愿不愿意花时间，把业务里的模糊地带一条条谈清楚。
如果所在企业也在考虑类似的事情，欢迎联系数商云获取详细方案，也可以预约顾问交流或申请演示。聊的时候不妨先从自己最痛的那个场景说起，通常比从平台功能清单说起更有用。
评论