某制造业头部集团的售后服务中心里，有一面墙专门用来贴便签。不是装饰性的留言板，是实打实的疑难杂症墙：哪个型号的设备在什么工况下容易报警，哪位老师傅处理过什么怪毛病，客户提过什么手册上没写的要求。坐席遇到答不上来的问题，就去墙上找线索。这面墙存在了很多年，直到集团决定做企业知识库智能体，它才第一次被完整地读了一遍。
事情的起点并不复杂。集团下面有多条产品线，售后、客服、研发、工艺各有各的资料柜。手册是PDF，图纸是扫描件，工艺变更通知躺在邮件里，维修记录堆在工单系统里。客户打电话进来，坐席要在几个系统之间来回切，搜索靠关键词，搜不到就靠记忆和打电话问人。新人培训周期长，老员工一调岗，经验就跟着走。管理层慢慢意识到，问题不是没有知识，而是知识找不到、对不上、不敢用。
于是有了这个项目：搭一套企业AI知识库，用大模型做智能问答，先服务售后和客服，再往研发、销售延伸。选型阶段，集团信息中心牵头，把业务部门也拉进来一起看方案。最后选择与数商云合作，原因说起来很朴素——支持私有化部署，能做知识库智能体开发而不只是套一个问答界面，支持国产化环境，源码交付给集团自己的IT团队。这套要求当时看起来有点苛刻，后来证明每一条都省了麻烦。
一、先弄清楚知道和查到是两回事
项目刚启动的时候，有人提过一个想法：买个通用大模型，把文档丢进去，不就能问了？这个想法很快被现实按住。集团内部开了一次碰头会，信息中心、售后、客服、工艺几个部门坐在一起，把各自的困惑摊在桌面上，才发现知识这件事比想象中麻烦得多。
（一）知识散落的方式，比预想更复杂
售后部门拿出一份维护手册，同一型号的设备，手上有不同时期发的版本，内容对不上，谁也说不清哪份是现行的。工艺那边更头疼，工艺文件改过之后，通知发了邮件，但售后现场用的还是旧口径，因为没人负责把邮件里的变更同步到手册里。研发有一批测试报告和故障分析记录，格式自由，放在个人电脑或者共享盘的角落里，别人根本不知道有这份东西。
更麻烦的是表达方式。有位老师傅在访谈里说，手册上写的是检查过载保护装置，可客户嘴里说的是机器一开就跳。这两个说法在系统里搜不到一起，坐席知道大概是一回事，新来的坐席就只能干着急。还有一份关键资料，存在一个返聘老工程师的电脑里，他带过很多徒弟，但从来没系统写过。项目组的人说，那段时间最大的感受是，集团其实很有家底，只是家底没摆在明面上。
（二）通用大模型直接用，答得越流畅越让人担心
项目组做过一个简单的试验，拿公开的大模型问备件型号和安全规程。模型的回答通顺、礼貌、结构完整，但里面的型号是编的，看起来还挺合理。负责售后的副总当场就说，这种东西如果直接给客户看，出了事谁负责。设备维修涉及人身安全和停机损失，答案错了不是体验问题，是责任问题。
这次试验定下了项目的基调：大模型应用可以上，但不能裸奔。答案要能溯源，要能说清楚是从哪份文件的哪一段来的；权限要能控制，不同角色看到的内容不一样；答不上来的时候要承认答不上来，而不是硬编一个。这些要求后来都写进了需求文档，也成了选择数商云的直接原因——他们做的是企业知识库智能体开发，不是把模型包装成一个聊天框。
（三）选型清单上的硬条件
集团看方案的时候列了一串条件，都是被现实逼出来的。第一是私有化部署，设备资料和客户信息不出内网；第二是权限体系，研发、售后、销售、外部服务商各看各的；第三是引用溯源，每条回答能点回原文；第四是能接现有的工单系统和客服系统，不能另起一个孤岛；第五是国产化适配，集团的IT环境有自己的要求；第六是源码交付，后续调整不用事事找厂商。
这些条件摆出来，能完整接住的厂商并不多。数商云的方案里，智能体开发平台、知识库搭建工具、国产化适配和源码交付都是标准能力，不需要单独定制，这让选型的过程少了很多拉扯。
二、知识库搭建：先让人把话说完
知识库搭建这件事，外行听起来像搬箱子，把文档从A处挪到B处。真正做过的人都知道，难点从来不在搬，在整理。
（一）知识盘点那段时间，最费劲的是让人开口
项目组做的第一件事不是打开工具，而是跑现场。他们跟着坐席上了一个完整班次，记录客户问什么、坐席怎么答、卡在哪里。又组织了几轮老师傅访谈，不填问卷，就聊天，聊到具体故障的时候让他们讲当时怎么判断的。便签墙上的内容被一条条拍下来，转录成文字。有些老师傅不愿意写文档，但特别愿意讲，前提是有人认真听。
这个过程花的时间比计划的久，但后来被证明是最值钱的一段。因为很多知识是以口头经验的形式存在的，不把这些话掏出来，后面的系统再先进也没有原料。
（二）切片和标签，决定了智能问答的上限
原始的文档进到知识库里，不能整篇存进去。数商云的团队和集团业务部门一起，把资料按用途分了几类，处理方式各不相同。
1. 事实型知识，重点是准确和版本
备件型号、技术参数、安全阈值这类内容，切分的时候要跟着机型和部件走，还要标明适用版本和生效状态。同一参数有多个版本的时候，系统只认现行版本，历史版本留档但不参与回答，避免坐席拿到过期信息。
2. 流程型知识，重点是步骤和条件
维修步骤、审批流程这类内容，按动作顺序切，每一步带上前置条件。比如某个操作要求设备处于停机状态，这个条件必须和步骤绑在一起，否则检索出来的答案会缺一半意思。
3. 经验型知识，重点是场景和判断依据
工单里的排查记录、老师傅的判断口述，长度不整齐、表达不规范，项目组没有强行改写成标准文档，而是保留原话，在旁边补上标签：机型、故障现象、环境条件、处置动作、结果。这样既保住了现场感，也让它能被检索到。
标签体系是这一段的核心工作。除了机型、部件、工序这些硬标签，还专门建了一份同义词表，把客户的口语说法和手册术语对应起来。跳闸、过载保护动作、开关断开，在系统里指向同一个意思。这份表不是一次写完的，而是在上线之后持续补充，坐席遇到搜不到的说法就反馈进来。
（三）权限不是附加题，是设计题
知识库里的内容，不同的人能看的范围差别很大。研发能看到完整的技术资料，销售只能看对外口径的部分，外部服务商只能看被授权的那部分设备资料。工艺参数涉及集团的看家本事，权限卡得很细。
这件事在知识库搭建阶段就要设计好，不能等上线再补。数商云的做法是把权限和知识条目的标签打通，谁在什么角色、能看哪些标签下的内容，规则配一次，后续新增资料自动按规则生效。集团IT的人说，如果权限靠手工维护，资料一多就管不住，早晚出事。
三、知识库智能体开发：从检索到回答的几道关
知识进了库，只是第一步。坐席要的不是一个能搜出资料的框，而是一个能听懂问题、给出答案、还能说明依据的助手。这是知识库智能体开发和普通搜索最本质的区别。
（一）先让检索听懂行话
对话式检索和关键词搜索不一样，用户说的是完整的一句话，里面混着设备俗称、工况描述和客户的情绪。项目组和数商云一起调了几轮检索策略，把同义词表接进去，把机型和故障现象作为强约束条件。搜跳闸的时候，系统会先判断是哪类设备、什么工况，再去匹配对应的处置建议，而不是把相关文档一股脑倒出来。
（二）答案必须带着出处来
这是集团最坚持的一条。智能问答给出的每条回答，下面都列出引用的原文段落，点开能看到完整上下文、所属文件、版本和生效状态。坐席把答案转给客户之前，自己会扫一眼出处，确认没问题再发。这个习惯看着多了一步，实际上让坐席敢用系统了。
反过来，系统对没把握的问题也有明确态度。资料里找不到依据的时候，它不会拼凑一个像模像样的答案，而是直接说明暂无对应资料，并给出转人工的入口。项目组说，宁可让系统显得笨一点，也不能让它显得不可靠。
（三）智能客服接了工单，才算进入流程
客服场景的接入方式比较克制。外部渠道来的咨询，只有高频、标准、风险低的问题交给智能客服自动应答，比如查询服务网点、了解保养周期这类。涉及故障判断和安全操作的问题，智能客服的角色是给坐席准备建议话术和引用材料，由坐席确认后发送。
工单系统对接之后，坐席输入客户的描述，系统会把可能相关的历史工单、处置记录、手册段落一起列出来，按可能性排序。坐席不需要在几个系统之间来回切，答案和依据在同一个界面里完成。这个改动看起来不大，但坐席的日常操作路径短了不少，忙的时候差别很明显。
四、跨部门协同：谁说了算，谁负责改
这类项目最容易出问题的地方，不是技术，是职责。知识错了谁改，新资料谁上传，答案有争议听谁的，这些事不提前定好，系统上线之后就会慢慢荒掉。
（一）业务部门当评委，不当旁观者
集团定了一个规矩：每个业务部门派一位知识责任人，定期抽查智能问答的回答质量。抽查发现错误，处理方式不是让技术团队去调模型，而是回到知识条目本身，看是资料过期、切分不当，还是同义词没覆盖。改的是知识，不是参数。这个规矩让业务部门从一开始就参与进来，而不是等着验收。
（二）IT 和数商云的分工很清楚
数商云负责智能体开发平台、知识库搭建、模型适配和检索策略调优，集团IT负责数据源对接、权限体系、日常运维和后续的知识更新。源码交付之后，IT团队自己能调整召回参数、增加数据源、修改对话流程，不用每次改动都走厂商排期。集团信息中心的负责人说，他们要的是一个自己能接得住的系统，而不是一个离了厂商就转不动的黑盒。
（三）国产化适配不是一句话的事
集团的IT环境有明确的国产化要求，芯片、操作系统、数据库、中间件都在名单里。数商云的团队在部署阶段做了大量适配工作，模型推理也在本地环境跑通。跑通是一回事，跑稳是另一回事。上线前做了一轮长稳测试，模拟并发访问和连续运行，把资源占用和响应情况摸清楚，才敢正式切流量。
五、上线之后，变化发生在细节里
项目验收会上没有人念成绩单，大家都是讲事。事讲出来，效果就在里面了。
（一）新人上岗那段时间，不再靠硬背
以前新人培训是把手册翻一遍，记住多少算多少，上岗之后遇到不会的就问旁边的人。现在新人先学的是怎么问问题：把客户的描述拆成机型、现象、工况几个要素，输进去看系统给出的建议和依据。系统告诉他的不只是答案，还有答案在哪份文件的哪一段。上手速度明显快了，带教的人也轻松了不少。
（二）坐席的日常操作路径短了
客服主管提到一个变化：以前疑难问题集中在少数几个资深坐席身上，客户等待时间会被拉长。现在系统能先把相关资料和话术准备好，普通坐席也能处理过去不敢接的问题，疑难问题的分流顺畅了很多。客户侧的感知是等待时间短了，答复的口径也统一了，不会再出现不同坐席说法不一样的情况。
（三）研发和销售也开始用这个库
研发那边把历史工单和故障记录当作输入，查同类问题的发生规律，用来反推设计上可以改进的地方。销售准备技术交流材料的时候，会先在库里核对对外口径，避免拿错版本。一个本来为售后和客服搭建的系统，慢慢变成了集团层面的知识入口。
（四）同行交流时的共鸣
项目过程中，集团和一家能源行业头部企业有过一次交流。对方也在做类似的事，同样卡在资料散、口径乱、权限不好管这几关上，同样担心大模型编造内容。两边聊得最多的话题不是模型选哪个，而是知识治理怎么落地、业务部门怎么参与进来。这说明企业AI知识库这件事，不同行业遇到的坎是相似的，差别只在于谁的决心下得更早。
六、复盘：企业AI知识库落地绕不开的几件事
项目做下来，参与的人各有各的体会，但有几点是共识。
（一）知识治理是长期活，得有人负责到底
系统上线不是终点。资料会过期，工艺会变更，新的故障会冒出来，知识库如果没人持续维护，答案很快就会失真。集团的做法是把知识责任人落到具体岗位，谁的业务谁负责更新，定期检查。这件事没有技巧，就是要有制度、有人管。
（二）评估方式决定系统往哪走
如果考核的是系统答了多少条，团队就会想办法让它多答；如果考核的是坐席采纳情况和工单处理是否顺畅，团队就会盯着答案准不准、引用全不全。集团选择了后者。指标怎么定，系统的行为就往哪个方向偏，这一点在项目中期看得特别清楚。
（三）别把智能体当成一个搜索框
搜索框是独立于流程的，用户想起来才去用。智能体要嵌进流程里，坐在坐席的工作界面上，连着工单系统，跟着业务动作走。集团这个项目能被用起来，很大程度上是因为它出现在坐席本来就要待的地方，而不是又多了一个要打开的网页。
回头看，这个项目的价值不在于用了多大的模型，而在于把散落多年的知识整理了一遍，把该说清楚的口径说清楚了，把权限和责任落到了人头上。模型和平台是工具，真正难的是这些看不见的活。数商云在过程中承担了平台的搭建和智能体的开发，也把这套方法带进了集团的日常运转里。
如果正在评估类似的项目，从知识盘点和权限设计入手，比从选模型入手更稳妥。欢迎联系数商云获取详细方案，也可以预约顾问交流或申请演示，先看看知识库搭建和知识库智能体开发的实际效果，再判断适不适合自己的业务节奏。
评论