一、项目起点：知识都在，可问一句要绕好几圈
（一）某制造业头部集团的日常
这家集团的业务跨度不小，从零部件加工到整机装配，再到售后维保，各地工厂和服务中心各自积累了一批文档。工艺文件在设计部门的系统里，质检标准挂在质量团队的共享盘上，售后手册和常见故障处理，又躺在客服自己整理的表格里。老员工心里有数，遇到问题知道该找谁；新员工就麻烦了，一个简单的问题往往要问好几个人，才能拼出个大概。
版本问题更让人头疼。同一道工序，现场老师傅手里拿的还是上一版作业指导书，质量部门存档的却是修订后的版本。谁对谁错，得开会吵一轮，吵完还要追溯到底哪一版才算数。这种事不常发生，但每次发生，消耗的都是几个部门的时间。
售后那条线的问题更直接。客户打电话来问设备报警怎么处理，客服要在几个系统之间来回切换，翻到手册再照着念。手册没写清楚的地方，只能转给技术支持，客户在电话那头等，工程师在这头查。客户的耐心有限，转上几次，语气就变了。
（二）为什么没有直接接一个通用大模型
集团的信息化团队一开始也想过省事的办法：接一个通用大模型，把文档丢进去就完事。真试下来，问题不少。文档格式太杂，扫描件、图纸说明、跨页表格、带修订痕迹的规范，直接喂进去，模型要么读不懂，要么把几份文档的内容串在一起。权限也是绕不过去的坎，工艺参数、成本相关内容，不能让所有人都问得出来，而通用模型的问答是敞开式的，谁来问都答。再加上数据不出内网这条底线，这条路基本就堵死了。
项目组把需求重新捋了一遍，结论是要的不是一个会聊天的模型，而是一个基于企业自有文档、按权限回答、能落到具体业务动作上的企业知识库智能体。这个判断定下来之后，才开始找合适的平台，数商云也是在这一轮进入视野的。
二、选型：业务提需求，IT划边界，谁也别替谁做主
（一）业务部门关心的是能不能少问几个人
业务侧的诉求很朴素。售后希望客服接电话的时候，屏幕上能直接跳出答案，并且说清楚依据在哪，方便复述给客户；生产希望一线员工在工位上就能查作业指导书，不用跑回办公室开电脑；培训部门盯着另一件事，新人上手太慢，如果有个随身的问答入口先把常见问题过滤掉，师傅带徒弟的压力能小不少。
这些诉求汇总起来指向同一件事：智能问答必须嵌进原来的工作流，而不是再开一个系统让人登录。多一个入口，就多一次被放弃的可能。
（二）IT部门划出的几条线
IT这边的顾虑完全是另一套逻辑。数据不出内网是底线；文档的权限体系要跟着走，不能因为多了个问答入口就绕过去；系统要能自己维护，改一条答案不必找原厂；还得考虑后面的扩展，今天做售后，明天可能做采购、做研发，平台撑不撑得住。
几条线一划，选型范围就清楚了。支持多种文档格式接入、能私有化部署、能对接既有账号与权限、并且愿意交付源码的方案，才有往下谈的基础。数商云被列进来，主要是因为它同时具备智能体开发平台和知识库搭建能力，国产化适配也有现成路径，项目组不用自己从头啃。
（三）演示环节的一个小插曲
有个细节后来被反复提起。现场演示时，多数方案给的是整理得很干净的样例文档，问答效果自然漂亮。项目组临时从共享盘里挑了几份最难处理的：带批注的扫描件、跨页断行的清单、内容重复但版本不同的手册。数商云的表现在其中不算惊艳，但它能指出哪几段是有效内容、哪里有冲突需要人工确认。这种知道自己不知道的表现，反而让评审组踏实了一些。
三、开发实战：从多文档接入到智能体上线
（一）知识库搭建：最费时间的不是技术，是梳理
1. 先把家底盘清楚
项目组没有一上来就导文档，而是先做盘点。哪些系统里有资料、谁在维护、更新频率如何、有没有权限分级，这些列出来之后才发现，同一个主题的内容散在好几个地方。有的文档已经废弃但没人敢删，有的天天在用却从来没进过系统。这一步做完，导入范围才算定了下来。
2. 清洗比想象中琐碎
扫描件要做文字识别，表格要保住行列关系，带修订痕迹的文件得确认以哪一版为准。数商云这边的做法是按格式分流，结构清晰的直接解析，图片类的先识别再人工抽查。有批老规范版式特殊，识别出来错行严重，业务专家逐页核对了一遍。这部分工作没有捷径，但它直接决定了后面问答的上限。
3. 切片和标注
长文档切成多大的块，直接影响检索准不准。切得太碎，答案断章取义；切得太大，检索出来的内容又杂。项目组和数商云的实施团队一起，按文档类型定了几套切法：规程类按条款切，手册类按问题场景切，清单类尽量保住整表。每块内容再打上来源、适用场景、生效状态这类标记，方便后面做过滤。
（二）智能体开发：把问答接到业务动作上
1. 内部服务台的问答入口
最先上线的是内部服务台。员工用原有账号登录，在对话框里直接提问，答案下面附引用出处，点开能跳到原文档。如果检索到的内容把握不大，智能体会直接说没有找到明确依据，同时给出几条可能相关的内容，而不是硬编一个答案。这条规则是业务部门坚持加的，宁可让人多问一句，也不能让错的答案流出去。
2. 智能客服与售后场景
对外这一侧，数商云把智能体和客服系统做了对接。客户描述故障现象，智能体先给出一轮初步判断和处理建议，把可能的原因也列出来。客服看到的不只是一段话，还有依据和相关处理记录，心里更有底。超出范围的，一键转人工，前面的对话内容一起带过去，客户不用从头再讲一遍。
3. 大模型应用的边界怎么写
开发中争论最多的，是这个智能体到底该管多宽。有人希望它什么都能答，有人担心它乱答。后来定下来的做法是把能力分成几档：有明确文档依据的直接回答；需要跨文档综合的，给出结论并说明这是综合判断；找不到依据的，如实说不知道。这套边界写进了系统提示，也写进了给业务部门的说明材料。
（三）跨部门协同：谁出题、谁验收、谁维护
项目推进到中途，出过一次明显的返工。技术团队按文档做出来的问答，业务专家一看就摇头，说现场不会这么问。问题出在测试集上。最初的测试问题是照着文档倒推出来的，看着规范，跟真实场景对不上。后来改成从客服工单、车间实际问题、培训记录里捞真实提问，效果立刻不一样了。
返工之后，分工也做了调整。业务专家负责出题和把关答案，他们最清楚一线会怎么问、什么样的答案算对；IT负责账号权限、系统接入和日常运行；数商云的实施团队负责平台侧的能力实现和调优，同时在交付过程中把配置方法教给客户团队。知识库不是做完就放着的东西，谁维护哪一块、多久看一遍，都在上线前写清楚了。
四、换个行业，做法并不一样
同样一套企业AI知识库的思路，落到不同行业，侧重点差得挺远。后来和数商云一起复盘时，几个同期推进的场景被放在一起看，反而更容易看清哪些是可以复用的经验，哪些必须因地制宜。
（一）某能源行业头部集团：规程问答容不得含糊
这家集团的知识库核心是安全规程和操作规程。文档相对稳定、条款清晰，但对准确性的要求极高。智能体在这里的定位不是尽量回答，而是严格照条款回答。检索时只认现行有效版本，答案必须带条款出处，超出规程范围的提问一律转人工。为了让这套规则跑得住，数商云在知识库搭建阶段就把文档的生效状态做成了硬条件，过期版本根本进不了检索范围。
（二）某零售行业头部企业：口径统一比答案本身更难
零售这边的难点不在文档多少，而是变化快。促销规则、退换政策、门店运营标准，隔一阵就调整。过去的办法是靠邮件和群通知，一线记不住，也容易记混。这里的企业知识库智能体承担的是口径统一的角色：政策更新后知识库同步更新，门店和客服问出来的答案就是同一个。智能客服在一线用得最多，顾客的问题先由智能体给出一版标准答复，店员按自己的话术讲出去。
（三）某物流行业头部企业：网点多，问答要经得起重复
物流企业的特点是网点分散，同一个问题在不同网点会被反复问到。这种场景下，知识库智能体的价值在于省掉重复解释。时效查询、异常件处理、理赔流程这些高频问题，先由智能体兜住，网点人员不必每次都打电话回总部。做得比较细的一点是，数商云把答案里涉及操作步骤的部分单独拎出来，做成能照着做的清单，而不是一段需要自己理解的说明。
五、上线之后：变化是慢慢显出来的
（一）找知识的路径短了
最直观的变化，是问问题的地方变少了。以前员工要先判断这个问题该问谁、该翻哪个系统，现在大多数情况下在一个入口提问就行。答案带着出处，看到出处就能判断可不可信。老员工被问的次数明显下降，不是问题变少了，而是很多问题在到达他们之前就被解决了。
（二）口径统一之后，扯皮少了
版本冲突这类事情，在上线之后基本没再出现。检索只认有效版本，谁查都是同一个结果。售后和客服的答复也统一了，客户听到的说法一致，对服务的信任感自然不一样。技术之外的好处，往往就藏在这些地方。
（三）知识维护从项目变成日常
项目初期，团队最担心的是上线之后没人管。后来发现，只要把责任落到具体岗位，这件事能转起来。文档更新和知识库同步被写进了原有流程，谁改文档谁顺手更新知识库，不再是额外负担。数商云在平台侧留了相应工具，非技术人员经过培训就能完成大部分维护动作，不必每次都找开发。
（四）复盘：如果重来一次
项目组总结的经验都挺实在。先定场景再谈模型，别指望一招通吃；文档治理要提前做，它可以和开发并行，但不能跳过；测试问题一定从真实业务里来，自己编的测试集只会让人自我感觉良好；人机分工要事先讲清楚，智能体负责找和答，判断和责任还在人这边。
还有一点被反复提到：知识库智能体开发不是一个交付完就结束的项目。业务在变，文档在变，模型和平台也在变。选一个有持续服务能力、能交付源码、愿意陪着走一段的伙伴，比选一份最长的功能清单更重要。如果贵司也在评估类似的方向，欢迎联系数商云获取详细方案，也可以预约顾问交流或申请演示，先把自己的业务场景和文档底子摆出来看一看，再决定从哪里起步。
评论