ARTICLE · 1143631
工业软件的企业级 RAG,为什么不能只做一个万能对话框?
从传统知识库到 Agentic RAG，真正需要重构的不是问答界面，而是企业知识的组织方式。
先说一个现象
最近看了不少工业 AI 产品，发现一个挺有意思的事情。
产品功能越来越丰富，界面却越来越相似。
左边是知识库，中间是业务数据，右边放一个 AI 对话框。
你问它“什么是设备预测性维护”，它能回答；问它“帮我总结一份检修规程”，它也能完成；甚至让它生成一份设备运行分析报告，也能写得有模有样。
看起来，AI 已经融入了工业软件。
但真正用到生产管理场景，就会发现问题。
你问它：
“昨天主排水系统用电量为什么增加了？是不是和设备故障有关？”
它可能会告诉你，设备老化、运行时间增加、负荷变化都有可能导致能耗上升。
回答没有明显错误，但也没有真正回答问题。
因为它不知道昨天具体是哪台设备运行异常，不知道对应的测点在哪里，不知道维修管理系统中有没有相关工单，更不知道这些信息之间是否存在业务关联。
它只是根据已有知识，生成了一个看起来合理的解释。
这其实是当前很多工业 RAG 产品的共同问题：什么都能回答一点，但很难真正理解一个具体的业务。
问题不完全在于模型能力。
更重要的是，企业并没有为 AI 建立一套能够理解业务对象、连接业务系统、验证真实数据的知识体系。
一、我们可能把 RAG 想得太简单了
过去建设企业知识库，思路其实很直接。
把设备说明书、管理制度、操作规程、检修报告上传到平台，通过文档解析、文本切片和向量化处理，建立一个可检索的知识库。
用户提问，大模型检索相关内容，再组织成自然语言回答。
这就是典型的 RAG。
对于制度查询、技术文档问答和知识检索，这套方式确实有效。
但工业企业有一个很明显的特点：
真正有价值的业务知识，并不全部存在于文档里。
它还存在于设备管理系统的台账中，存在于生产系统的运行记录中，存在于能源系统的统计数据中，也存在于维修工单、安全隐患和项目执行过程中。
而且，这些信息通常不在同一个系统里。
举个例子。
设备管理系统知道一台水泵的型号、厂家和安装位置。
能源管理系统知道它每天消耗多少电。
运行监控系统知道它什么时候启动、什么时候停止。
维修管理系统知道它出现过哪些故障、进行过哪些检修。
设备说明书则记录着它的运行参数和维护要求。
这些信息单独看都很完整。
但对于 AI 来说，如果没有统一的关联关系，它们就是几份互不相识的数据。
传统 RAG 解决的是“能不能找到知识”，而企业级 RAG 更需要解决“能不能把分散的知识联系起来”。
这是两个不同层次的问题。
二、工业 AI 真正缺的，是一套统一的业务语言
我认为，工业软件建设企业级 RAG，有一个容易被忽视的核心能力：
工业本体（Industrial Ontology）。
这个概念听起来有些抽象，但它要解决的问题很具体。
同一台设备，在不同业务系统里可能有不同的名字。
在设备管理系统中叫“2#主排水泵”。
在能源管理系统中叫“二号排水泵”。
在维修系统中又变成“主排水泵02”。
人能理解它们可能指向同一台设备，但 AI 不一定能够准确识别。
尤其在一个矿井存在几百台甚至上千台设备的情况下，仅靠名称相似度去匹配，很容易出现错误。
本体建设要做的，就是为这些业务对象建立统一的语义定义。
例如，什么是设备，什么是生产系统，什么是测点，什么是运行指标，什么是故障事件。
更重要的是，定义它们之间的关系。
一台设备属于哪个系统。
一个测点监测哪台设备。
一个运行指标由哪些数据构成。
一次故障关联了哪些维修记录。
一条维修记录依据哪份技术规程。
这些关系建立起来之后，AI 才有机会从孤立的信息中理解一条完整的业务链路。
这里还需要区分两个概念。
本体定义业务世界的规则，知识图谱记录真实业务世界中的对象和关系。
本体告诉系统，设备可以关联测点、故障和维修工单。
知识图谱则记录，某台具体的设备关联哪些实际测点，发生过哪些故障，对应哪些真实工单。
本体与图谱结合，才能让不同系统的数据建立关联。
不过，本体也不是万能的。
它不能凭空判断两个名称相似的设备就是同一个对象。
实际建设中，仍然需要设备编码、主数据映射、业务规则以及必要的人工审核。
本体的价值，不是让 AI 记住更多术语，而是让 AI 理解企业业务中“谁是谁、谁和谁有关”。
这才是工业企业建立统一知识体系的基础。
三、企业级 RAG 正在从知识检索走向知识连接
最近，Progress Software 发布的新一代 Agentic RAG 产品能力，给了我一些启发。
它提出了一个很有价值的思路：
Agentic Knowledge Layer，统一智能知识层。
与传统知识库不同，这种架构不要求所有业务数据都提前进入向量数据库。
它将两种知识访问方式结合起来。
一种是 Knowledge Box。
将企业制度、技术规范、设备文档等相对稳定的内容提前解析、索引和治理，需要时直接检索。
另一种是通过 MCP 连接业务系统。
对于实时变化的业务数据，Agent 可以在用户提出问题时调用相应系统，获取当前数据，而不是依赖可能已经过期的知识副本。
与此同时，Smart Agent 可以将复杂问题拆解成多个子问题，分别检索知识库、连接业务系统，再评估是否获取了足够的信息。
Progress 在 2026 年 10 月发布的产品更新中，明确介绍了 Knowledge Box、MCP 实时连接和 Smart Agent 多步检索的协同方式。
这个思路很适合工业互联网平台。
因为工业企业的数据天然具有两种不同的特点。
一类是相对稳定的知识。
设备说明书、操作规程、技术标准、管理制度。
另一类是不断变化的事实。
设备状态、实时负荷、生产任务、故障工单、能源消耗。
如果全部采用文档 RAG，动态数据容易过期。
如果全部依赖实时接口，又缺少业务知识和历史经验。
更合理的方式，是让知识检索和实时数据访问相互配合。
我认为，在 Progress 这类统一知识层架构的基础上，工业互联网平台还应进一步补充本体管理和知识图谱能力。
因为工业场景不仅需要连接系统，还需要理解系统之间的业务语义。
否则，Agent 虽然拥有很多工具，却未必知道应该使用哪一个。
四、真正的 Agentic RAG，不应该只是换一个更聪明的模型
现在很多产品开始使用 Agentic RAG 这个概念。
但有些所谓的 Agentic RAG，只是在原有知识库前面增加一个大模型，让它先判断用户意图，再选择一个检索工具。
这种方式可以提升使用体验，但距离企业级智能知识平台还有一定差距。
真正有价值的 Agentic RAG，应该具备三个能力。
第一，知道用户到底在问什么。
比如用户问：
“分析昨天主排水系统的用电异常。”
系统不仅要识别“用电分析”这个意图，还应识别主排水系统、所属矿井、查询时间、用电指标等业务对象。
第二，知道应该去哪里找答案。
系统通过工业本体识别业务对象，再找到相关设备、测点和数据源。
需要用电量，就调用能源管理系统。
需要运行状态，就调用工业时序数据平台。
需要维修记录，就查询维修管理系统。
需要判断是否符合维护要求，就检索对应的设备规程。
第三，知道现有证据能不能支持结论。
这是最容易被忽略的一点。
假设昨天主排水系统用电量上升，同时某台水泵存在维修记录。
这只能说明两个事件在时间上可能存在关联。
不能直接得出“用电量增加就是设备故障导致的”这一结论。
如果缺少运行时长、负荷变化、设备启停等关键数据，系统应该明确说明证据不足。
必要时继续检索，而不是强行给出原因。
好的 Agentic RAG，不只是能找到更多信息，更应该知道哪些结论有依据，哪些只是推测。
工业 AI 尤其需要这种能力。
五、工业企业需要的，不是更多知识库，而是统一的知识基础设施
回到产品设计。
如果要建设一个真正面向工业软件的企业级 RAG 平台，我认为核心不应该是堆叠更多功能菜单。
而应该建立一条完整的知识处理链路。
业务系统接入 → 知识抽取 → 本体映射 → 知识融合 → 智能检索 → Agent 应用。
这条链路可以进一步拆成五个部分。
1. 数据连接层：解决知识从哪里来
统一连接生产管理、安全管理、设备管理、能源管理、项目管理等业务系统。
支持数据库、API、文件、消息和工业时序接口。
这里需要明确一个原则：
不是所有数据都必须复制到 RAG 平台。
对于设备档案、规程和知识文档，可以同步和建立索引。
对于实时测点、生产状态和敏感业务数据，则可以通过授权接口按需访问。
2. 知识加工层：解决数据如何变成知识
从企业文档、数据库和业务接口中抽取实体、属性、关系和规则。
例如，从设备检修记录中识别设备、故障现象、维修措施及处理结果。
但抽取不等于确认。
大模型生成的知识需要经过规则校验、实体对齐和必要的人工审核，才能进入正式知识体系。
3. 工业本体层：解决知识之间如何关联
建立统一的设备、组织、生产系统、测点、指标、事件和业务规则模型。
通过语义映射，把不同系统中的数据关联到统一业务对象。
这是整个平台最值得投入的部分之一。
因为知识库可以通过现有开源产品快速搭建，真正困难的往往是企业内部的业务语义统一。
4. Agentic RAG 层：解决知识如何被使用
不再只依赖向量相似度检索。
而是将全文检索、向量检索、知识图谱检索、结构化查询和 MCP 工具调用结合起来。
由 Smart Agent 根据业务问题动态选择检索路径。
同时保留执行过程、原始证据、数据来源和检索记录。
5. 知识治理层：解决知识是否可信
这一层不能只做权限管理。
还应该包括知识版本、数据血缘、实体一致性、知识更新、访问审计和 RAG 质量评估。
例如，同一设备在两个系统中出现不同型号时，平台应该能够发现冲突，而不是随意选择一个作为答案。
再比如，用户查询某项安全制度时，系统应该优先使用当前有效版本，而不是检索到一份已经废止的旧文件。
企业级 AI 最终拼的，不只是回答速度，而是回答结果能不能经得起验证。
六、工业本体管理中心，可能是未来企业级 RAG 的关键分水岭
为什么我会特别强调本体管理？
因为随着工业智能体越来越多，企业很容易进入另一个困境。
设备运维智能体建一套设备知识库。
能源管理智能体再建一套设备知识库。
安全监管智能体又重新定义一遍设备、组织和生产系统。
每个智能体都能独立运行。
但它们之间的业务对象无法统一，数据关系也很难复用。
最后，看似建设了很多 AI 应用，实际上又制造了一批新的知识孤岛。
过去是业务系统之间的数据孤岛，未来可能变成智能体之间的知识孤岛。
解决这个问题，需要把本体建设从单个 AI 应用中独立出来。
建立企业级工业本体管理中心。
统一定义业务对象、属性、关系和约束。
统一管理跨系统字段映射、实体编码及数据来源。
再通过知识图谱和语义服务，将这些能力提供给不同的业务智能体。
这样，新增一个智能体，不必重新定义设备是什么，也不必重新梳理所有业务系统之间的对应关系。
它可以直接使用已有的工业本体和知识连接服务。
这才是真正意义上的知识复用。
当然，本体中心本身也不能建设成一个只会画关系图的工具。
真正有价值的本体管理中心，必须同时具备模型设计、语义映射、实体对齐、版本治理和服务开放能力。
少了跨系统语义映射，本体容易停留在概念层面。
少了统一实体识别，知识图谱容易出现大量重复对象。
少了治理和版本管理，本体一旦发生变化，就可能影响多个 Agent 的正常使用。
所以本体管理不是简单增加一个“本体配置”菜单，而是需要从产品架构上进行设计。
七、企业级 RAG 应该怎么落地？
很多企业在建设 AI 平台时，习惯先规划一个覆盖所有业务系统的大架构。
生产、安全、能源、设备、项目、合同、采购全部纳入。
从架构上看，确实很完整。
但如果一开始就试图完成整个企业的知识体系建设，项目很容易变成一项长期的数据治理工程。
我的建议是：
不要先追求全覆盖，先打通一条真正有价值的业务链。
例如，选择煤矿主排水系统作为试点。
连接设备管理、能源管理和维修管理三个系统。
首先建立设备、生产系统、测点、运行指标、故障事件和维修工单的统一语义模型。
再实现跨系统设备识别和数据关联。
最后接入 Agentic RAG，让用户能够直接提出业务问题。
比如：
“昨天主排水系统的用电变化，与相关设备的运行状态和维修记录有什么关系？”
系统需要能够完成真实的数据查询、跨系统关联、知识检索和证据验证。
同时，也要能明确说明哪些数据尚未获取、哪些异常原因无法确认。
这个场景跑通后，再扩展通风机、压风机、供电系统以及其他生产管理业务。
比起一次性建设几十个知识库，先完成一条可验证、可复用的业务链路，更容易体现企业级 RAG 的价值。
而且，验收方式也应该发生变化。
不能只测试“AI 能不能回答这个问题”。
还应该检查：
它有没有识别正确的设备？
有没有调用正确的业务系统？
获取的数据是不是最新的？
检索的规程是不是有效版本？
跨系统关联有没有发生错误？
最终结论是否得到实际数据支持？
回答得像不像专家，不应该成为唯一标准。能不能提供可靠的业务证据，才是工业 AI 更重要的评价维度。
最后，谈谈我对工业 RAG 的一个判断
过去几年，工业软件数字化建设解决了大量业务流程线上化和数据采集的问题。
企业逐渐拥有了越来越多的业务系统，也积累了越来越多的数据。
但系统越多，数据之间的关联就越复杂。
现在大模型出现了，我们希望它能够理解这些数据，帮助企业完成查询、分析和辅助决策。
这件事情真正的难点，可能并不是让模型变得更聪明。
而是如何让它理解一个真实的企业。
理解一台设备属于哪个系统。
理解一个指标来自哪个测点。
理解一条故障记录对应哪台设备。
理解一项管理制度约束什么业务。
理解不同系统中的信息，哪些能够关联，哪些不能混为一谈。
这些问题，靠一个大模型、一套提示词或者一个向量数据库，很难从根本上解决。
它需要统一的数据连接、工业本体、知识图谱、Agentic RAG，以及贯穿整个过程的知识治理体系。
所以，我越来越觉得：
企业级 RAG 的终点，不应该是一个更强大的知识库，而应该是一套能够连接企业知识、业务对象和实时系统的智能基础设施。
未来工业 AI 的竞争，也许不再是谁的对话框功能更多，谁的大模型参数更大。
而是谁能够把企业长期沉淀的业务知识，真正转化为可理解、可关联、可验证、可复用的智能服务。
让 AI 知道答案在哪里，只是第一步。
让 AI 理解答案为什么成立，才是企业级 RAG 真正需要跨过的门槛。
而这，可能才是工业软件从“接入大模型”走向“真正具备 AI 能力”的开始。