企业智能问数落地：从一句话到跨系统完整答案

销售总监电话响起经销商在催一单设备的交货进度。他需要在 ERP 里查订单状态、在 MES 里查产线进度、在 WMS 里查配件库存——三个系统、三套账号、三套逻辑。在传统流程里这个过程可能要 2-3 小时有了企业智能问数能力他说一句话系统就能把所有相关数据汇齐反馈。这个场景每天在制造企业发生 N 次但真正能做到分钟内拿到完整决策依据的企业不到 5%。一、企业问数难在哪里企业里的数据查询场景表面看是技术问题实际是语义问题。当业务人员说帮我查一下某客户上半年的订单情况时这个订单情况在不同系统里对应不同的数据实体在 ERP 里是销售订单在 CRM 里是商机记录在 MES 里可能是工单。一个完整的答案需要综合这三个来源的数据而且要做口径对齐——哪个系统的时间字段是创建时间哪个是确认时间哪个是交付时间——大模型不知道这些业务人员也未必说得清楚。多系统数据无法互通表面上是接口问题实际是语义不一致问题每个系统的字段命名、数据口径、业务含义都有差异大模型要真正理解业务人员在问什么需要先理解不同系统里同一个业务概念的不同表达方式。这正是本体语义平台的价值所在它不是再造一套数据而是在不同系统的语义层之间建立对齐关系让大模型能准确地把业务问题翻译成跨系统的数据查询指令。二、从问数到答案的三个阶段阶段一自然语言理解与本体映射业务人员输入某客户二季度的在制品交付情况大模型首先要做语义理解——这句话涉及哪些业务概念。本体语义平台在内部维护了一个业务本体库里面包含了企业中所有核心业务概念的语义定义。客户对应 ERP 和 CRM 的相关字段在制品对应 MES 的工单实体交付则需要关联 ERP 的交货单和 WMS 的出库记录。这个映射过程是动态的大模型根据问题提取出涉及的本体再根据本体的关系图谱确定需要查询哪些数据源最终生成一条完整的语义链路。阶段二跨系统数据查询执行本体映射完成后大模型沿着语义链路逐个系统查询。每个数据源有一个对应的查询接口描述——说明这个系统支持哪些字段查询、支持什么样的过滤条件、返回数据的口径是什么。本体语义平台不直接写 SQL而是通过语义描述生成符合各系统口径的查询指令屏蔽了底层数据源的差异。这个阶段的关键挑战是数据口径对齐。同一个时间概念在 ERP 里可能是创建时间在 MES 里可能是开工时间在 WMS 里可能是出库时间。本体语义平台在本体层定义了统一的时间口径规则查询结果返回后自动做时间轴对齐而不是让业务人员自己判断哪个时间才是正确的。阶段三答案生成与追问支持查完数据后大模型把结果拼装成自然语言答案。这个答案不只是原始数据的罗列而是包含了上下文解读大模型会说明数据来源、标注异常值、给出趋势判断。如果业务人员不满意继续追问为什么这个月在制品积压增加了大模型会基于已有的查询结果做进一步推理而不需要重新跑一遍全流程。多轮追问能力是企业智能问数区别于普通 BI 报表的关键。传统报表是静态的问完一个指标才能想到下一个智能问数是动态的业务人员可以从一个数字追到另一个数字像和专家对话一样逐层展开分析。向量空间JBoltAI 在多个制造业项目里验证过上线初期业务人员平均每个问题会追问 1.5-2 次追问的问题往往比第一句更具体、更有业务价值。三、三个常见落地误区误区一先接数据再建本体很多团队的做法是先把系统接进来能查到什么算什么。但不建本体就接数据数据口径不一致的问题会在应用层持续爆发——每次发现数据对不上就要改查询逻辑改到最后整个系统变成一坨补丁。本体应该在数据接入之前就建好。先把业务概念定义清楚再根据本体定义确定需要接入哪些数据源、按什么口径接入。向量空间JBoltAI 在项目实践中发现这样做的团队后期维护成本比前者低 40% 左右。误区二问数准确率达标就算成功问数准确率达到 90% 后很多团队认为项目成功了。但问一个数得到正确答案不等于业务人员真的愿意用这个系统。实际落地中阻碍业务人员持续使用的主要是两个问题回答速度太慢超过 30 秒的业务人员会转回打电话和多轮追问时上下文丢失第二句问同比呢系统需要记得第一句问的是哪个客户。向量空间JBoltAI 在多个项目里验证过准确率到 85% 以上时业务采纳率的瓶颈就从准不准转移到了快不快和能不能连续问。误区三数据源接得越多越好接入 10 个系统不等于能回答 10 个系统的问题。本体语义平台的能力上限受两个因素约束本体规模和管理成本。当企业接入 20 个系统、100 个业务本体时本体的迭代维护本身就成了瓶颈——本体更新滞后于业务变化问数准确率反而会下降。建议的做法是按业务域分批接入先接高频业务域的核心系统ERP CRM MES跑通 2-3 个月后验证准确率再逐步扩展到低频系统。盲目追求系统数量会把项目拖入本体债务。四、落地路径建议企业如果想真正把智能问数用起来有几个可操作的建议先从高频问题入手。选 5-10 个业务人员每天至少问一次的问题先把这些问题跑通。这些问题的语义定义清晰、数据来源固定上线后能快速积累用户信任给团队争取后续迭代的时间。把问数准确率按业务场景分级定义。库存查询和跨系统毛利分析对准确率的要求完全不同前者差 1% 就能被业务发现后者差 10% 可能还在容忍范围内。按业务场景设定不同的准确率目标避免用统一标准消耗不必要的工程资源。建立问数反馈机制。业务人员认为答案不对时是否有便捷的反馈入口反馈数据有没有被用于优化本体定义和查询链路很多项目上线后缺了这一环问数准确率永远停在初始水平无法持续提升。五、边界与开放问题本文没有解决的一个问题是当多个数据源的数据相互矛盾时系统如何判断哪个数据是正确的。这个问题在实践中出现频率不低ERP 显示订单已完成MES 显示工单还在生产WMS 显示物料还没出库。三个系统的数据都对从各自系统的角度但拼在一起就产生了矛盾。当前本体语义平台的处理方式是把这类矛盾标记为数据一致性异常推送给业务人员人工判断而不是替业务人员做仲裁。这个边界需要明确——智能问数能发现数据问题但不替代人做业务决策。