一、项目缘起：客服电话背后，是一堆找不到的文档
（一）一个被反复提起的现场
某制造业头部集团的客户服务中心，工位隔板上贴着几张手写便签，上面记着常用资料的存放路径。售后工程师接到现场报修电话，客户在电话里描述一台设备的报警现象。要判断问题出在哪，他得同时看这台设备的出厂配置、最近一次改型说明，还有前不久发过的技术通报。说明书躺在共享盘一个很多人已经记不清的旧目录里，维修手册在另一套系统里按机型编号存放，技术通报有的挂在邮件附件上，有的只存在于工作群的聊天记录中。
资料都在，凑不到一起。真正耗时间的不是判断故障，是找齐判断故障要用的那几页纸。新来的工程师遇到这种情况，第一反应是打电话问人。老师傅在工位就答得快，出差去现场了就只能等。客户在那头听着翻纸的声音，工程师在这头一个个目录点过去，谁都不舒服。这个细节后来在项目复盘会上被反复提到，因为它说明问题不在某一个系统，而在知识被切成了很多块。
（二）试过的几条路子，都没走通
集团信息中心不是没有动作。他们先试的是买一套现成的智能客服产品，演示时效果不错，卡在了数据这一关：资料要传到厂商的云上，而设备参数、工艺改动这类内容属于内部敏感信息，安全部门不同意。后来组织了几个人用开源模型自己搭，模型说话很流畅，但答案经常和自家手册对不上，把不存在的参数说得像真的，工程师试了几次就不敢用了。也试过最朴素的办法，把内部搜索优化一下，问题是关键词对不上就返回空结果，用户连着搜几次没结果，慢慢就不打开了。
（三）选型标准：模型能力之外的三件事
正式立项之前，信息中心和业务部门坐在一起开了几次会，把选型标准理清楚。他们关心的不是模型榜单上的排名，而是几个很具体的问题。
一是历史文档能不能被真正读懂。集团积累的技术资料格式杂，双栏排版的说明、带合并单元格的参数表、扫描的老图纸都有，如果解析这一层做不扎实，后面所有环节都是空中楼阁。二是权限能不能跟着组织走。同一个问题，研发人员能看到的答案和经销商能看到的答案应该不一样，售后和售前看到的范围也不一样。三是这套东西能不能放在自己机房里，出了问题自己的运维团队能不能接手，而不是每次都要等厂商排期。
数商云进入候选名单，是因为前期沟通时对方把重点放在文档解析和知识治理上，没有一上来就讲模型多大。最终确定的方案里，企业知识库智能体部署在客户自有的服务器上，企业AI知识库的数据不出内网，智能体开发平台负责对话编排和工具调用，国产化适配和源码交付也写进了交付范围。
二、文档解析：先把文件读懂，再谈回答问题
（一）盘点家底，是项目里最不起眼也最关键的一步
项目组做的头一件事不是装环境，是清点资料。信息中心拉着各业务口的人，把散落在共享盘、业务系统、个人电脑和邮件里的文档过了一遍。格式比预想的杂：Word、PDF、Excel、PPT、CAD图纸、扫描件，还有一部分是纸质台账拍的照片。同一份文档存在多个版本，文件名里带着“最终”“最终改”“最新版”这样的字眼，打开一看，改动内容还不太一样。有些表格里嵌着公式和批注，能看出是几个人接力改过的痕迹。
这次盘点让项目组认清了一件事：知识库搭建这件事，前半程的功夫其实花在把文件变成可检索、可引用的内容上，模型只是后半程的事。资料本身没理清楚，再好的模型也只能在混乱上叠加混乱。
（二）不同类型的文档，走不同的处理路线
1. 版式文档。说明书、维修手册这类文档有清晰的章节结构，但排版也最麻烦。双栏布局、页眉页脚、跨页续排，直接抽取会把页眉和正文混在一起。处理时要先识别标题层级，保留章节关系，让切出来的每个段落都带着上下文，用户看到答案时能知道它出自哪一章、哪一节。
2. 表格。设备参数表、工艺参数表、物料清单，这些内容价值最高，结构也最难还原。合并单元格、跨页表格、表头不在第一行，抽取之后如果不还原行列关系，检索出来就是一堆意义不明的数字。项目组在这类文档上花了额外的时间做规则校验，宁可慢一点，也不让错误的参数进到库里。工程师照着错误参数去操作设备，后果比查不到资料严重得多。
3. 扫描件与图纸。早年归档的资料有不少是扫描件，字迹深浅不一，还盖过章、打过孔。识别之后要人工抽查，把容易认错的机型代号、专有名词挑出来，补进词典。图纸这类内容则转成图片配文字说明，检索的入口放在图号和名称上，工程师用起来更顺。
4. 长文档切分。切得太碎，答案没有上下文；切得太长，检索命中的精度就下来了。项目组最后采用的是按语义和结构切，标题跟着正文走，表格单独成块并保留表名，像说明书这种层级清晰的文档，切出来的片段自带章节位置。用户看到的不再是孤零零的一句话，而是一段能放回原文语境里的内容。
（三）解析做得好不好，由业务问题来验收
解析质量不看界面好不好看，看业务问题能不能答出来。项目组准备了一份问题清单，都是客服和工程师真实提过的，比如某个型号的设备在什么工况下需要更换某个部件，某个工艺参数调整之后下游工序要怎么配合。用这些问题一轮轮去测，答不上来就回头查是哪一步丢了内容：是解析没抽到，是切分把关键句切断了，还是检索没匹配上。
这份清单后来一直留着，每次调整都要重新跑一遍。它比任何验收文档都管用，因为它检验的不是技术指标，而是系统到底能不能替一线的人解决手头的事。
三、知识库搭建：从能搜到，到敢照着做
（一）知识结构和权限，决定了系统能不能用得久
1. 分类和标签先定规则再动手。按产品线、文档类型、适用机型几个维度划分，标签由业务部门统一提，避免同一种东西在不同部门叫不同名字。分类一旦定下来就尽量稳定，频繁调整会让用户的查找习惯反复被打破，用起来就会觉得别扭。
2. 权限跟着组织走。集团的组织层级、项目划分、外部经销商的边界，都要在知识库里对应上。做法是让权限继承自既有的人员体系，用户在系统里是什么角色，在知识库里就自动拥有对应的可见范围，不需要管理员一个个去配。人员调岗、离职、加入新项目，这些变化在原有系统里完成，知识库这边自动跟着变。
3. 可见范围要分得清。面向经销商的内容、只对内部开放的内容、某个项目组才看得到的内容，在处理阶段就分好，不要等到上线之后再补。后补的权限往往牵一发动全身，容易出纰漏。
（二）检索调优：让答案找得到，也说得清
1. 混合检索解决两类问题。机型编号、图号、物料编码这类内容必须精确匹配，差一个字符都不行；用户口语化提问时又需要语义检索兜住。两种方式配合使用，才能既接得住规范提问，也接得住随口一问。
2. 术语表要有人维护。内部简称、机型代号、外文缩写，这些词通用模型不认识，得靠人工整理进去。项目组请各业务口的老工程师贡献了一份口语叫法的对照表，用户怎么叫，系统都要能对应到标准名称上。这份表刚开始是手工维护的，后来在用户反馈里持续补充，慢慢变成了一份挺有意思的内部语言地图。
3. 每条回答带出处，是建立信任的关键。回答下面附文档名称、章节位置和更新时间，用户点开就能看原文。工程师愿意用这套系统的原因很朴素：它能告诉他这句话是从哪来的。这一点比答案本身更能决定系统能不能活下来。答错了可以改，来源不明的答案没人敢照着做。
（三）智能体开发：从回答问题到走完一段流程
1. 多轮对话和提问改写，是给一线用户准备的。现场人员说话往往不完整，“那个报警怎么处理”这种问法，系统要结合前面的对话补全机型、工况这些缺失信息，再去检索。追问一次比答错一次好得多，用户也不会觉得系统在装傻。
2. 工具调用让智能体往前多走一步。通过数商云的智能体开发平台，团队把工单系统、备件库存和售后服务系统接进来，用户问完问题可以直接查工单状态、看备件在不在库、把处理记录回填到工单里。这时候智能问答就不只是个会聊天的搜索框，它能陪用户走完一段流程，用户少切几次系统，事情就办完了。
3. 智能客服场景里，分寸感很重要。面向经销商的咨询入口，常见问题交给智能体接，遇到涉及合同、价格、责任认定的问题，自动转人工，转接时把对话上下文和用户信息一起带过去，人工坐席不用从“您好请问有什么可以帮您”重新开始。人工没有被替代的感觉，反而觉得接得更顺，因为来的人已经说清楚了问题，前面聊过的内容也都在。
四、上线之后：机制比模型更容易被忽略
（一）知识负责人这件事，必须落在业务侧
系统上线后最现实的问题不是模型准不准，而是文档更新了谁来管。项目组和业务部门商量后，在每条产品线设了知识负责人，负责本领域文档的更新、过期内容的标记和用户反馈的处理。信息中心只提供工具和培训，不代替业务判断内容对错。这个分工一开始有争议，业务侧觉得自己已经够忙，但试运行一段时间后大家承认，只有写文档的人才知道文档什么时候变了。
用户的反馈入口做得比较轻：回答下面设有反馈入口，用户觉得答得不对可以补一句原因。这些反馈定期汇总，由知识负责人看哪些问题集中出现，是文档缺了，还是解析错了，还是切分不合适。问题分到对应的人手上，处理完在系统里留个记录，下一次更新时能查到这段内容是怎么被改过来的。
（二）对接和交付方式，决定了后续几年的主动权
知识库不是孤岛。上线过程中，团队把知识库和企业既有的账号体系做了对接，用户不用记新的账号密码；人员和岗位发生变动，权限自动跟着调整。文档更新的入口也做了约束，业务系统里的资料发布之后，知识库按周期同步，减少两边说法不一致的情况。
交付方式上，这个项目采用的是本地部署加源码交付。集团信息中心的技术人员参与了部署和调试过程，供应商的工程师把解析规则、权限配置、对话流程的设计思路讲清楚，运维团队后续可以自己调整。国产化适配这块，从操作系统到数据库都在客户既有的技术路线之内，没有为了上系统而改造机房。对于一家把设备参数看得比较重的制造企业来说，这套安排让他们心里踏实。
（三）一线反馈里的变化
系统跑起来之后，客服中心的感受最直接。以前新同事遇到不熟悉的问题，第一反应是找老师傅；现在会先去问智能体，把答案和原文出处一起看完，实在拿不准再找人确认。老师傅被问的次数少了一些，被问的问题质量高了——来问的人已经看过了资料，问的是判断上的分歧，不是资料的存放位置。
技术资料的更新也比以前顺手。过去文档改完发在群里，谁看到了算谁的；现在改完发布到知识库，用户查到的就是当前版本，不用再猜哪份是最新的。检索从翻目录变成直接发问，这个过程省下来的时间很难用一句话说清，但一线的人能感觉到差别：同样一个报修电话，处理起来从容了不少。
后来这套做法在集团内部又推广到了另外几个业务口，包括面向经销商的咨询场景。有家能源行业的头部集团来交流时，问得最多的也是权限和文档解析这两块，可见大家遇到的麻烦其实很像，只是各自的文档长得不一样。
五、复盘：这个项目真正难的地方在哪里
项目做完再回头看，模型选型反而不是最难的部分。难的是把多年积累的资料翻出来，一份份看清楚它们长什么样；难的是和业务部门一起把权限边界画清楚，让不同角色看到该看的内容；难的是让业务侧愿意为知识质量负责，而不是把系统当成信息中心一家的事。这三件事没有一件能靠采购解决，都得有人坐下来磨。
如果有人在评估类似的大模型应用项目，有几点体会或许有用。文档解析的效果直接决定后面的天花板，这一层省下来的时间，后面要用更多的检索调优来补。权限设计要在搭建初期就定好，后补的权限通常会出问题。上线只是开始，知识负责人机制和反馈处理流程，比多做几个功能更能决定系统能活多久。
企业AI知识库这件事，说到底是把组织里已经存在的经验，换一种能被机器读懂的方式重新组织一遍。模型在进步，工具在变，这套组织工作不会自己消失，反而会随着可用数据变多而变得更要紧。数商云在这个项目里承担的是知识库智能体开发和交付的角色，从文档解析、知识库搭建，到智能问答调优和智能体编排，全程和客户的业务团队一起推进，遇到分歧就回到具体业务场景里找答案。如果所在企业也在考虑类似的方向，欢迎联系数商云获取详细方案，也可以预约顾问交流或申请演示，先看看自己的文档家底能支撑起什么样的应用，再决定从哪里开始动手。
评论