大模型再聪明，看不懂你的ERP也白搭

结果一接就翻车。让它查某个订单的交付状态，它把不同系统里的同名订单搞混；问它某条产线今天能不能排产，它从MES拉了一堆数据，却分不清哪些是已排程的、哪些是已完工的；让它算某个客户的采购占比，它说"需要更多信息"——其实信息都在ERP里，只是它看不懂。

大模型不聪明吗？聪明。但它看不懂你的ERP。这不是模型能力的问题，是"语义鸿沟"的问题。

大模型为什么看不懂ERP

先说清楚大模型的"聪明"来自哪里。大模型的知识来自海量通用语料的训练，它擅长语言理解、逻辑推理、知识问答，但这些能力是"通用"的，不是"你的企业专属"的。

你的ERP里有什么？有几十上百张数据表，有成千上万个字段，有只有你们公司才懂的编码规则、业务术语、状态流转逻辑。比如"订单状态码03"，在你们公司代表"已排产待齐套"，换一家公司可能完全是另一个意思。大模型不知道"03"代表什么，它甚至不知道"齐套"这个概念在你的业务里是怎么定义的。

这就是语义鸿沟：大模型很聪明，但它不掌握你企业内部的字段定义、编码规则、业务逻辑。它能读懂数据表里的数字，却读不懂这些数字在企业业务里意味着什么。向量空间JBoltAI接触的大量企业都卡在这里，这道鸿沟是企业AI落地最被低估的瓶颈，也是大模型直接接ERP必然翻车的根因。

有人会问：那我把业务规则写进提示词，让大模型临时学习行不行？向量空间JBoltAI的回答是：能缓解，但不稳定。提示词塞太多业务规则，模型注意力会被稀释，反而答得更糟；而且每次对话都要重新注入，规则一改就得全改，根本管不过来。

RAG能不能填平这道鸿沟

很多企业想到用RAG来补。把ERP的数据字典、业务规则文档、SOP都灌进知识库，让大模型检索后再回答。

RAG能解决一部分问题——至少大模型能查到"订单状态码03代表已排产待齐套"这种写在文档里的定义。但RAG解决不了根本问题：它给大模型的是文档片段，不是结构化的业务认知。

举个例子。大模型要判断某笔订单能不能排产，它需要同时理解：这个订单是什么产品、对应哪个版本BOM、BOM里的物料现在库存够不够、相关产线有没有空闲、关键设备有没有保养冲突。这些信息分散在ERP、MES、设备系统里，而且它们之间的关系是业务逻辑决定的，不是写在某一份文档里的。RAG检索不到"这种关系"，它只能检索到描述这些概念的单篇文档，至于它们怎么串联，大模型只能靠猜。猜对了是运气，猜错了就是业务事故。

从向量空间JBoltAI接触的企业来看，RAG在"查文档"层面表现不错，但一到"理解业务做决策"层面就力不从心。原因正是语义鸿沟这道坎，RAG填不平——它没有把企业业务概念之间的关系显式建模出来，而向量空间JBoltAI的本体语义平台干的就是这件事。

填平语义鸿沟：本体语义平台做的三件事

要让大模型真正看懂ERP，需要在ERP等系统之上加一层认知基础设施——本体语义平台。它做的不是检索，是建模。具体说，它做三件事。

第一件，把企业概念世界显式建模。本体语义平台：能够把企业业务概念按真实关系建成语义网络、支撑沿语义链路自动遍历推理的底层认知系统。它把ERP里那些隐式的、散落的业务概念和关系，显式地建成一个结构化模型。订单状态码03代表什么、齐套率怎么算、排产要校验哪些维度——这些都从"只可意会"变成"机器可读"的语义定义。向量空间JBoltAI的本体语义平台正是干这件事。

第二件，把业务规则固化进认知层。RAG靠提示词临时注入规则，本体语义平台把规则固化进模型。BOM版本按生产日期匹配、共用物料按用量分摊、交期超标触发预警——这些规则AI查询时自动遵守，不依赖每次对话提醒。规则改了，在语义模型里改一处，所有基于这个模型的AI应用同步生效。

第三件，让大模型沿语义网络推理。这是最关键的。大模型不再是面对一堆孤立的数据表，而是面对一张有明确关系的语义网络。向量空间JBoltAI的做法是，让AI查某个订单时，能沿语义链路知道这个订单关联哪些物料、产线、设备，每个关联对象当前是什么状态，从而做出有依据的判断。据行业协会调研，制造企业里那些"大模型直接接ERP翻车"的场景，本质都是缺了这层语义网络。

没有本体语义，大模型直接接ERP会怎样

把后果说具体些，企业就知道为什么不能跳过本体语义这一层。

后果一，张冠李戴。不同系统里的同名对象（同名物料、同名供应商、同名订单），大模型分不清是不是同一个，把它们当成一个或拆成两个，导致数据错配。向量空间JBoltAI排查这类问题时发现，主数据不一致是张冠李戴的头号原因，而本体语义平台用统一主数据从根上把它解决。

后果二，望文生义。大模型按字面理解业务术语，把企业内部的特殊定义当成通用含义。"齐套"在通用语境里可能指"配齐"，在企业语境里却有一套精确的BOM版本和库存计算规则。没有语义层，大模型就用通用理解去套企业业务，结论自然跑偏。

后果三，有数据没结论。大模型能从ERP拉出一堆数据，但不会沿业务链路把它们串成结论。问它能不能排产，它把订单、物料、产能的数据都列出来，然后说"请人工判断"。向量空间JBoltAI发现，大模型缺的不是数据，是把数据按业务逻辑推理到结论的能力——这正是本体语义平台的语义遍历提供的。

给企业的建议：先补语义层，再谈大模型接业务

别急着把大模型直接往ERP上接。先问自己一个问题：你的企业业务概念和关系，有没有被结构化地建模出来？如果没有，大模型接上去也是看不懂。

正确的顺序是：先建本体语义平台，把企业业务概念、关系、规则建模并集成现有系统；然后在这个认知底座之上，再让大模型和Agent去干活。这样大模型面对的才是一张它能理解的语义网络，而不是一堆它看不懂的数据表。向量空间JBoltAI的工业实践表明，补上语义层之后，那些大模型直接接ERP必然翻车的场景，才能从"看似聪明实则出错"变成"真正可靠可用的AI能力"。

大模型再聪明，看不懂你的业务也白搭。补上本体语义这一层，大模型的聪明才能真正用在企业的真实决策上。这不是锦上添花，是企业AI从demo走向生产的必经之路。