从知识库到工业上下文：让AI懂业务，还需要补上什么？

把企业内部的Word、PDF、制度和产品资料上传进去，让员工通过自然语言提问，是不少企业尝试大模型的起点。

但当问题进入研发、工艺、生产、设备和质量，企业很快会发现：资料已经放进去了，AI给出的回答却未必适用于眼前这项任务。

在9月5日烟台“2026山东工业AI应用落地论坛”的分享中，豪迈专门提醒：不要做通用知识库，效果不好，这是他们此前踩过的坑。

这是一条来自企业自身实践的反馈，值得认真对待。

它也让我们进一步追问：企业已经积累了这么多资料，为什么AI仍然不容易把业务问题回答好？

一、找到一段内容，还要判断它是否适用

假设一名维修工程师问：“设备出现这个报警，应该怎么办？”

知识库可以检索手册、维修记录和历史文档，再由大模型整理回答。但要把答案用到现场，还需要弄清楚：

• 这是哪一台设备，采用什么配置？
• 这份手册适用于哪个版本，设备后来有没有改造？
• 当前参数与历史故障发生时是否相似？
• 推荐的处理办法，有没有前置条件？

文字相似，并不意味着业务条件相同。

豪迈的经验提醒我们，要认真检验通用知识库能否满足具体业务需要。至于其效果不佳的具体原因，还需要结合原有方案和使用场景进一步拆解，不能仅凭这条反馈替企业下结论。

从方法上看，如果知识库建设停留在资料集中上传、切片和相似度检索，型号、版本、适用范围等信息就容易被忽略。

改进也未必需要另起炉灶。补充文档标签、版本管理、结构化查询和来源追溯，都可能改善效果。是否引入知识图谱，要看实际问题需要。

关键是先明确：谁在什么场景下，需要得到什么样的答案？

二、一个工程知识案例：让信息沿着业务关系被找到

在服务商分享的一个船舶与海工知识应用案例中，工程对象分散在不同章节、技术规范、项目和船型资料里，同一个对象还可能有不同叫法。

这类问题不仅需要检索文字，还需要识别：谈的是哪个对象，属于哪个项目，适用什么条件，以及证据来自哪里。

据分享介绍，项目尝试通过本体和知识图谱，连接工程对象、章节、文档、项目、船型及来源，使业务问题能够沿着这些关系找到相关资料与原始出处。

本体模型在这一过程中经历多轮调整。随着资料范围扩大，原先的建模方式也需要重新审视。

这一案例提供的启发是：知识组织既有技术难度，也需要企业讲清业务概念、关系和适用规则。模型建得细，不一定就更适合检索和维护。

本文两处匿名案例均依据服务商分享整理，用于讨论实施思路；不据此推定其上线范围或实际收益。

三、本体到底是什么？

用企业管理语言理解，本体首先是在约定三件事：

有哪些重要对象，对象之间有什么关系，用什么属性和规则描述它们。

例如，零部件由某个物料编码标识，图纸有版本，工艺适用于特定产品，质量问题关联某个批次或工序，工程变更影响特定范围。

这些关系原本就存在，只是分散在ERP、MES、PLM、Excel、文档和员工经验中。

本体帮助统一描述这些概念与关系；知识图谱则可以把具体对象和关系组织起来。两者相互配合，但不必把所有知识工程都理解成“建设一张大图谱”。

对企业而言，实际价值在于：当大家和AI谈论一个物料、一台设备或一份图纸时，能够知道说的是哪一个对象，以及哪些规则适用。

如果现有系统和数据表已经能清晰表达这些信息，就应当优先复用。

四、另一个维修案例：历史知识还要连接当前状态

在服务商分享的另一个设备故障诊断案例中，历史维修记录是重要基础，但实施思路还涉及维修文档、报警与处理日志、工艺参数、机床参数、IO点位及设备状态。

原因很直观：知道过去怎样修过，还不足以判断现在这台设备出了什么问题。

分享介绍了结合本体、知识图谱、设备数据、规则和Agent的方案思路。它带来的启发是，维修助手需要同时面对两类信息：相对稳定的专业知识，以及随现场变化的业务状态。

例如，某种处理方法可能适用于一个型号，却不适用于改造后的设备；某个参数如果采集时间过早，也不能直接代表当前状态。

知识必须带着适用条件，状态必须带着时间。

这也是AIHUB关注“工业上下文”的原因：一个业务任务需要的信息，往往跨越文档、系统和现场。

五、工业上下文：围绕任务，组织有效信息

在AIHUB的研究中，我们把“工业上下文”理解为：

围绕一个具体工业任务，按需提供准确、相关、有效且经过授权的信息，并明确可调用的工具及其边界。

这里最重要的是“围绕任务”和“按需”。

对于维修助手，上下文可能包括设备身份与配置、有效手册、近期报警、参数时间、相关维修记录，以及允许执行的操作。

对于研发技术标准问答，则可能包括工程对象、项目要求、标准版本、适用条款及原始出处。它未必需要连接实时设备数据。

企业已有系统仍然承担重要职责：记录交易与状态，管理版本，执行业务规则和权限控制。Agent可以帮助理解问题、组织查询和调用工具，但库存、BOM版本、审批状态等事实仍然需要可靠来源。

这些职责今后可能重新组合，具体软件形态也可能变化。无论入口怎样变化，事实记录、专业计算和业务控制都需要有人、有系统负责。

六、建起来以后，谁维护？AI又能做什么？

工业上下文要在业务里持续使用，就必须能够更新。

图纸换版了，旧答案如何失效？设备改造了，谁确认原来的维修方法还能使用？不同系统对同一个物料的记录不一致，谁来处理？

这些都需要明确的数据和业务责任人。AI可以辅助提取、关联和发现冲突，关键业务事实与规则仍需由企业确认。

同时，查询、建议、发起流程和执行操作，需要分别授权。

维修助手查阅记录、提出检查建议、生成待审核工单、修改设备参数，影响范围明显不同。企业应当根据任务设置最小权限，并明确审核、日志、异常处理和人工接管方式。

权限也必须由系统和工具执行，不能只在提示词里写一句“请谨慎操作”。

这意味着，让AI进入业务，还需要把信息维护、工具调用和责任边界一起设计好。

七、企业怎么起步？先做一个有负责人、有验收标准的场景

AIHUB当前更倾向的路径是：从一个具体场景出发，先建设它需要的局部上下文，再依据实际效果逐步扩展。

例如，先限定一类设备的维修辅助，或者一个产品系列的技术标准查询。起步时问清四个问题：

第一，谁真正需要解决？ 明确实际使用者、业务负责人，以及谁来判断结果是否有价值。

第二，当前问题有多大？ 记录查找耗时、错误类型、返工等基线，选择与业务目标相关的指标。

第三，最少需要哪些信息？ 列出必要的文档、对象、关系、版本、状态和权限，优先利用已有系统。

第四，怎样判断值得继续？ 用真实问题测试，检查答案是否正确、证据是否可追溯、条件是否适用，并记录数据整理、开发、人工审核和持续维护的成本。

节省工时可以体现效率改善，但是否转化为实际成本下降，还需要单独核算。

如果局部场景有效，再把可以复用的对象、术语和规则沉淀下来；如果效果不理想，就据测试结果调整范围或技术路径。

场景先行，上下文逐步完善，本体按需生长。

写在最后

豪迈关于通用知识库的踩坑提醒，以及服务商介绍的工程知识与维修案例，共同促使我们关注一个更具体的问题：企业积累下来的信息，怎样才能在需要的时候，以正确的版本、适用条件和权限被使用？

这需要知识整理，也需要系统连接、业务判断和持续维护。

AIHUB希望围绕这些真实问题继续积累：把案例讲清，把适用条件问透，再通过小范围验证判断价值。

对制造企业来说，值得长期建设的能力，是持续把可信的工业知识用到具体任务中，形成可验证的业务改善。

围绕这些问题，山东CIO联盟·AIHUB计划于今年10月在济南组织专题交流，主题为“企业知识工程：如何让AI真正懂业务”。

我们希望从企业的真实经验出发，深入讨论：知识库建设踩过哪些坑？如何围绕具体场景组织文档、数据和业务规则？知识怎样持续更新，AI的操作权限如何设置，又怎样判断投入是否值得？

欢迎正在探索这些问题的企业CIO、数字化与AI负责人，以及拥有实际项目经验的技术伙伴，带着案例、困惑和待解决的问题参与交流。具体安排将通过山东CIO联盟公众号后续发布。

连接工业知识，让AI真正进入业务。

山东CIO联盟 · AIHUB