在制造业集团内部，知识很少以整齐的形态存在。产品参数写在技术文件里，故障处理经验留在工单系统中，项目方案沉在销售团队的共享盘里，工艺变更通知流转在审批流程里。每份内容都有自己的产生场景，也困在自己的系统边界之内。业务人员要快速得到一个准确答案，往往需要在多个系统之间反复切换，甚至依靠电话求助才能完成判断。
某制造行业头部集团与数商云合作，围绕大模型深度落地展开系统性实践。项目没有从模型调参开始，而是把重心放在知识治理与连接上：梳理散落在各业务系统中的知识资产，建立统一的知识底座，再通过检索增强的方式让大模型基于企业自有知识作答。最终实现的，不只是对话式查询资料，而是跨系统知识智能互通带来的业务协同变化。下文依次还原项目背景、解决方案与落地成效。
一、项目背景：知识散落在系统里，答案却难以汇聚
1. 集团型企业的知识分布现状
(1) 该集团业务覆盖多个产品线，研发、生产、销售、服务分别运行在各自的信息系统中。产品资料、工艺文件、故障记录、客户问答、项目方案沉淀在不同平台，彼此之间缺少统一的索引与语义关联。同一个概念在不同系统中的命名并不一致，检索结果自然难以合并。
(2) 对业务人员来说，找资料之前先要判断它在哪个系统，再切换入口、适应不同的检索规则。跨部门协作时，同一个技术问题可能在不同部门得到不同版本的答复，谁也无法快速确认哪一版是现行口径。信息并不是没有，而是需要付出额外成本才能获得。
(3) 集团并非没有知识管理意识，过去也建设过文档库和内部百科类平台，但内容主要依靠人工上传与维护，更新滞后、覆盖面有限。随着业务扩张和人员流动，知识资产的完整性越来越依赖个别骨干的记忆和责任心。
2. 跨系统协同中的真实堵点
(1) 售后服务环节的情况比较典型。设备出现异常时，服务工程师需要同时参考产品手册、历史工单、备件信息和工艺变更记录，而这些内容分散在不同系统。现场人员往往通过电话向后方专家求助，响应质量受专家在岗状态和个人经验影响。
(2) 研发与工艺之间的知识传递也不顺畅。设计变更之后，相关工艺文件、检验标准和作业指导书需要同步调整，人工核对难免遗漏，下游部门拿到旧版本文件的情况时有发生，纠正起来代价不小。
(3) 销售与投标场景存在类似问题。方案模板、资质材料、项目案例和应答口径散落在各个团队手中，业务人员重复整理材料，输出质量参差不齐，集团层面的沉淀难以被有效复用。
3. 大模型应用从尝鲜走向务实
(1) 集团管理层对大模型技术保持关注，也做过工具层面的尝试。通用大模型在开放话题上表现流畅，但涉及具体产品参数、内部流程和专有术语时，回答往往似是而非，甚至生成看似合理却无法核实的内容。
(2) 这些体验让团队意识到，制约大模型进入业务场景的关键，不是模型的能力上限，而是企业知识能否以可用、可控、可追溯的方式被模型调用。缺少知识底座，模型输出就无法承担实际业务责任。
(3) 基于这一判断，集团决定启动AI知识库项目，目标不是做一个演示性质的问答工具，而是把分散在各业务系统中的知识统一治理，让大模型在真实业务中稳定输出可信答案。数商云在知识工程与大模型应用方面的方法积累，成为此次合作的基础。
二、解决方案：以知识底座为核心的搭建路径
1. 知识盘点与治理先行
(1) 项目启动后，双方没有急于接入模型，而是先做知识资产盘点。数商云团队与集团各业务条线逐项梳理知识来源，覆盖产品、工艺、质量、服务、销售和职能管理等领域，明确每类知识的产生方、使用方、更新频率与责任归属。这是企业知识管理中最基础、也最容易被跳过的一步。
(2) 盘点过程中暴露出不少问题。同一主题的内容在多处存在，版本不一；部分关键知识只存在于个人电脑和聊天记录中；一些历史文档缺少元数据，无法判断时效性。团队据此建立知识分类体系和治理规则，把维护责任、更新时机和失效处理方式固定下来。
(3) 结构化数据与非结构化文档采取不同的处理方式。结构化数据保留原有系统作为权威来源，通过接口读取；非结构化文档则进行清洗、切片和标注，补齐标题、适用范围、生效状态等字段，为后续检索与引用打好基础。
2. 跨系统知识智能互通的架构设计
(1) 跨系统互通是项目的核心命题。数商云搭建的知识中台通过接口与集团现有业务系统建立连接，把分散的知识以统一方式纳管，同时保留各系统对自身数据的权威地位，避免形成新的数据孤岛。
(2) 检索层面采用语义理解与关键词匹配相结合的方式。用户提出问题后，平台不只匹配字面词汇，还能理解业务语境，把来自不同系统的相关信息聚合起来，按可信度与时效性排序，形成相对完整的答案。
(3) 权限体系与集团原有账号体系打通。不同岗位、不同层级、不同子公司的员工，看到的知识范围与在原系统中的权限保持一致。涉及敏感信息的内容，在检索与生成环节都会被识别并按规则处理，避免越权访问。
3. 大模型与业务场景的贴合方式
(1) 方案采用检索增强的技术路线。大模型不直接依赖自身参数记忆作答，而是先在企业知识库中检索相关内容，再基于检索结果组织语言。答案附带来源指引，使用者可以回到原文核对，输出结果因此具备可追溯性。
(2) 针对集团内部的专有术语、产品代号和业务缩写，项目团队构建了术语库与同义词映射。用户用口语提问，系统也能理解其对应的专业概念，减少因表述差异造成的检索偏差。
(3) 场景选择上，双方优先落地知识密度高、使用频率高、错误代价高的环节，包括售后服务支持、研发文档查询、销售方案辅助和新人培训。每个场景都设定回答边界，超出知识库范围的问题，系统如实说明并引导至人工渠道。
4. 权限、安全与持续运营机制
(1) 安全机制贯穿项目全程。知识入库前进行来源审核，入库后实施访问审计；模型调用过程记录完整日志，便于追溯。对于涉及核心工艺和商业机密的内容，采用更严格的访问控制策略，确保知识使用不突破安全边界。
(2) 运营机制同样被放在重要位置。集团为每类知识设定责任人，建立反馈通道。使用者对答案进行评价，发现错误或过时内容可以随手反馈，系统将问题分派给对应责任人处理，形成知识质量持续改进的闭环。
(3) 数商云还为集团培养了内部运营团队，把知识治理的方法、工具与流程沉淀在集团内部。项目交付的不只是可运行的系统，更是能够长期运转的知识运营能力，这为后续扩展更多场景提供了条件。
三、落地成效：从查得到到用得准
1. 业务前端的变化
(1) 售后服务的变化最为直观。服务工程师在现场遇到问题时，通过统一入口提问，就能获得来自产品手册、历史工单和工艺文件的综合答案，并看到内容来源。过去需要多方电话确认的问题，现在可以在统一界面内完成初步判断。
(2) 研发与工艺协同的效率得到改善。设计变更信息进入知识库后，相关文档的关联关系被自动识别，需要同步更新的内容会提示责任人。下游部门查询资料时，系统优先呈现现行有效版本，减少因版本混乱造成的返工。
(3) 销售与投标团队可以把精力更多放在客户需求分析和方案设计上。过往项目中的方案要点、常见问题和应答口径，可以通过知识库快速调用，输出的材料在专业性和一致性上都有改善。
2. 组织知识循环的形成
(1) 知识贡献不再是少数人的额外负担。员工在日常工作中产生的问答记录、解决方案和复盘总结，经审核后可以沉淀进知识库，成为组织资产的一部分。知识从写给人看，逐渐转向写给人和大模型共同使用。
(2) 专家经验的价值被放大。资深工程师的排查思路、工艺人员的判断依据、销售骨干的客户沟通经验，经过结构化整理后进入知识库，不再局限于师徒传承或小范围分享，服务范围扩展到整个集团。
(3) 新人培养方式随之改变。新员工可以借助知识库了解产品体系、业务流程和常见问题，遇到不确定的内容先查询再确认，上手过程更加平稳，也减轻了带教人员的重复解答压力。
3. 大模型深度落地的关键判断
(1) 项目的实践验证了一个基本判断：大模型在企业内部能否真正发挥作用，取决于知识供给的质量。模型是引擎，知识是燃料。燃料不纯，引擎再强也难以驱动业务。知识治理的投入，最终会体现在答案的可用性上。
(2) 场景切入的节奏同样关键。与其一开始就追求覆盖所有业务，不如选择知识基础较好、用户需求明确的场景先行验证，跑通从知识入库到用户反馈的完整链路，再逐步扩展。这样既能控制风险，也能积累内部信心。
(3) 权限与安全必须前置考虑。企业知识往往涉及核心竞争力和合规要求，如果安全机制在后期才补齐，返工成本高，用户信任也容易受损。把权限设计融入架构初始阶段，是项目顺利推进的重要前提。
4. 后续演进方向
(1) 在现有基础上，集团计划把知识智能互通的范围延伸到更多业务系统，让知识不仅服务于问答，也能嵌入流程。例如在工单流转、变更审批等环节主动推送相关知识，帮助员工在关键节点做出更准确的判断。
(2) 知识质量的评估方式也将继续细化。除了用户反馈，团队希望通过使用情况、引用来源与业务结果之间的关联分析，识别知识短板，指导治理优先级，让知识库随着业务发展持续演进。
(3) 从更长远的角度看，这次合作让集团建立起面向大模型时代的知识基础设施。它既支撑当前的应用场景，也为后续更深入的智能化探索保留了空间。
5. 对同类企业的参考价值
(1) 对于同样拥有多业务系统、多组织层级的集团型企业，这个案例提供了相对稳妥的路径：先解决知识从哪里来、由谁维护、如何授权的问题，再讨论模型如何接入。顺序反过来，项目很容易停留在演示阶段。
(2) 知识库的价值不在建成那一刻，而在投入使用之后的持续运转。责任机制、反馈通道和运营团队，决定了知识库能否跟上业务变化。忽视运营，再完整的内容也会逐渐失效。
(3) 大模型深度落地不是一次技术采购，而是一项需要业务、IT与知识管理部门共同参与的系统工程。数商云在这个项目中承担的角色，也不止于技术实施，更包括方法导入与能力共建。对于希望在内部推进类似工作的企业，这些经验具备现实参考意义。
评论