一、能聊天的 AI一问公司数据就翻车很多人体验过大模型聊天、写文档、查资料都很顺。但把它接进公司让业务人员直接问上个月华东区哪个产品的复购率最高“客户 A 这个季度下了多少单、还有多少没回款”回答就开始飘了。要么数字算错要么口径对不上要么干脆编一个看起来合理的结果。业务人员试了几次不信了又退回到找 IT 拉数的老路。问题不在大模型笨。它能把一句话拆成查询意图、能生成 SQL、能组织语言把结果说清楚。真正卡住它的是它不知道你公司里的复购率到底怎么算、华东区包含哪些省份、客户 A在三个系统里到底是不是同一个人。这些是企业内部才知道的业务约定。大模型在公网上学不到接上数据库也猜不出来。它需要一个懂你公司业务的中间层来告诉它。二、智能问数到底难在哪一层智能问数听起来简单——自然语言进去数据答案出来。但中间这条链路有几道坎每一道都可能让结果出错。第一道是意图理解。业务人员说的话往往不精确。最近销量怎么样是想看趋势、看排名还是看同比客户是指成交客户还是包括试用客户大模型要先把模糊的话拆成明确的查询意图。第二道是口径对齐。同一个指标在不同部门定义不同。财务算的收入是开票口径销售算的是签单口径这两个数字能差出好几个百分点。大模型不知道用哪个就得有人提前告诉它标准口径是什么。第三道是跨系统关联。一个问题经常要查多个系统——客户信息在 CRM订单在 ERP回款在财务售后在工单系统。要拼出一个完整答案得先知道这几个系统里说的是不是同一个客户、同一笔单。这三道坎传统做法是靠数据中台把数据先搬齐、做一张大宽表。但表是固定的问题却是千变万化的建好的宽表永远跟不上业务人员临时冒出来的新问题。三、本体语义怎么让问答不再翻车本体语义平台处理这几道坎的思路是把业务约定提前建模成一层语义而不是等问的时候再临时拼。意图理解这一层语义网把业务对象的边界定义清楚——“客户这个对象包含哪些属性、和订单”产品是什么关系。大模型顺着这层语义走能判断复购率涉及的是订单对象里的某个状态过滤而不是漫无目的地猜。口径对齐这一层每个指标的计算规则、统计范围、过滤条件都作为对象属性或关系定义在语义网里。大模型查复购率时拿到的是公司既定的算法不是它自己理解的版本。跨系统关联这一层本体语义把不同系统里的同名对象、异名同义对象做映射明确CRM 里的 account_id 和 ERP 里的 customer_code 指向同一个客户实体。大模型要跨系统查时走的是这条事先打通的关系路径而不是自己尝试 join。结果就是业务人员问什么大模型都能在一套统一的语义口径下作答不会再因为口径漂移而算错。这层语义越完整问答的准确率越高而且是持续积累的——不是一次性建好就完了。四、不止问答跨系统分析、辅助决策、实时查询把语义这层搭起来能做的远不止一问一答。跨系统数据分析是第一个延伸场景。以前要做一份客户全貌报表得从四个系统导数据、人工对账、再拼到 Excel 里一周出一份。有了统一的语义层大模型可以在一次提问里把客户的基本信息、历史订单、回款进度、售后工单全拉出来按任意维度切片。不是固定报表而是问到哪儿分析到哪儿。实时问答查询是第二个。传统的宽表是 T1 甚至 T7 的问的是昨天甚至上周的数据。本体语义平台走的是逻辑查询数据还在各系统的原位问到的时候现取。对于库存、在途、当天订单这种时效性强的数据这一点差别决定了它能不能用在实际业务里。辅助决策是更进一步的应用。当语义层不只定义了对象和关系还定义了业务规则——比如库存低于安全线就该建议补货“某客户回款逾期超过 30 天就该预警”——大模型就不只是回答问题而是能基于对象状态主动给出建议。它从一个问答工具变成一个决策助手。在 JBoltAI 这套企业 AI 体系里本体语义平台扮演的就是这个角色把企业分散在各系统、各口径的数据统一成一层大模型能读懂、能推理的业务语义支撑从智能问数到跨系统分析再到辅助决策的整条应用链路。山东向量空间人工智能科技在做的也正是把这层语义做扎实让大模型在企业里能真正落地到这些场景而不是停在 demo 阶段。五、一个常被忽略的前提问得准才能答得对智能问数能不能用起来还有一半责任在提问的人。大模型再聪明也只能回答被问到的问题。而很多业务人员其实不太会问——要么问得太笼统“帮我看看数据”要么问的方式让模型无法定位用了一堆公司内部黑话却没给上下文。所以智能问数落地往往要配套做一件事沉淀一批高质量的问法范例。把业务部门常问的问题、对应的正确口径、期望的答案形式整理出来既作为语义层建设的输入这些高频问题定义了哪些对象关系必须先建好也作为引导业务人员提问的参考。这件事做扎实了问答准确率会有一个明显的台阶式提升。它不是技术问题是怎么让业务和大模型对齐的问题。六、问数落地拼的是语义这层底子大模型让用自然语言查数据这件事从不可能变成了可能这是实打实的进步。但能不能在企业里真正用起来、用得准、用得让人信取决于它背后那层语义做得多扎实。智能问数、跨系统分析、辅助决策这些场景听起来都很吸引人但它们共享同一个前提企业得先把自己散落的业务对象、关系、规则用一种大模型能理解的方式表达出来。这件事不做再强的大模型也只能在企业门口打转。这大概也是为什么那些真正把智能问数用起来的企业花的力气最多的不是接大模型而是搭语义。模型是别人的语义是自己的——这才是企业 AI 能不能落地的分水岭。 大模型能聊天能写代码，为什么在企业里问个数据还是答不准
一、能聊天的 AI一问公司数据就翻车很多人体验过大模型聊天、写文档、查资料都很顺。但把它接进公司让业务人员直接问上个月华东区哪个产品的复购率最高“客户 A 这个季度下了多少单、还有多少没回款”回答就开始飘了。要么数字算错要么口径对不上要么干脆编一个看起来合理的结果。业务人员试了几次不信了又退回到找 IT 拉数的老路。问题不在大模型笨。它能把一句话拆成查询意图、能生成 SQL、能组织语言把结果说清楚。真正卡住它的是它不知道你公司里的复购率到底怎么算、华东区包含哪些省份、客户 A在三个系统里到底是不是同一个人。这些是企业内部才知道的业务约定。大模型在公网上学不到接上数据库也猜不出来。它需要一个懂你公司业务的中间层来告诉它。二、智能问数到底难在哪一层智能问数听起来简单——自然语言进去数据答案出来。但中间这条链路有几道坎每一道都可能让结果出错。第一道是意图理解。业务人员说的话往往不精确。最近销量怎么样是想看趋势、看排名还是看同比客户是指成交客户还是包括试用客户大模型要先把模糊的话拆成明确的查询意图。第二道是口径对齐。同一个指标在不同部门定义不同。财务算的收入是开票口径销售算的是签单口径这两个数字能差出好几个百分点。大模型不知道用哪个就得有人提前告诉它标准口径是什么。第三道是跨系统关联。一个问题经常要查多个系统——客户信息在 CRM订单在 ERP回款在财务售后在工单系统。要拼出一个完整答案得先知道这几个系统里说的是不是同一个客户、同一笔单。这三道坎传统做法是靠数据中台把数据先搬齐、做一张大宽表。但表是固定的问题却是千变万化的建好的宽表永远跟不上业务人员临时冒出来的新问题。三、本体语义怎么让问答不再翻车本体语义平台处理这几道坎的思路是把业务约定提前建模成一层语义而不是等问的时候再临时拼。意图理解这一层语义网把业务对象的边界定义清楚——“客户这个对象包含哪些属性、和订单”产品是什么关系。大模型顺着这层语义走能判断复购率涉及的是订单对象里的某个状态过滤而不是漫无目的地猜。口径对齐这一层每个指标的计算规则、统计范围、过滤条件都作为对象属性或关系定义在语义网里。大模型查复购率时拿到的是公司既定的算法不是它自己理解的版本。跨系统关联这一层本体语义把不同系统里的同名对象、异名同义对象做映射明确CRM 里的 account_id 和 ERP 里的 customer_code 指向同一个客户实体。大模型要跨系统查时走的是这条事先打通的关系路径而不是自己尝试 join。结果就是业务人员问什么大模型都能在一套统一的语义口径下作答不会再因为口径漂移而算错。这层语义越完整问答的准确率越高而且是持续积累的——不是一次性建好就完了。四、不止问答跨系统分析、辅助决策、实时查询把语义这层搭起来能做的远不止一问一答。跨系统数据分析是第一个延伸场景。以前要做一份客户全貌报表得从四个系统导数据、人工对账、再拼到 Excel 里一周出一份。有了统一的语义层大模型可以在一次提问里把客户的基本信息、历史订单、回款进度、售后工单全拉出来按任意维度切片。不是固定报表而是问到哪儿分析到哪儿。实时问答查询是第二个。传统的宽表是 T1 甚至 T7 的问的是昨天甚至上周的数据。本体语义平台走的是逻辑查询数据还在各系统的原位问到的时候现取。对于库存、在途、当天订单这种时效性强的数据这一点差别决定了它能不能用在实际业务里。辅助决策是更进一步的应用。当语义层不只定义了对象和关系还定义了业务规则——比如库存低于安全线就该建议补货“某客户回款逾期超过 30 天就该预警”——大模型就不只是回答问题而是能基于对象状态主动给出建议。它从一个问答工具变成一个决策助手。在 JBoltAI 这套企业 AI 体系里本体语义平台扮演的就是这个角色把企业分散在各系统、各口径的数据统一成一层大模型能读懂、能推理的业务语义支撑从智能问数到跨系统分析再到辅助决策的整条应用链路。山东向量空间人工智能科技在做的也正是把这层语义做扎实让大模型在企业里能真正落地到这些场景而不是停在 demo 阶段。五、一个常被忽略的前提问得准才能答得对智能问数能不能用起来还有一半责任在提问的人。大模型再聪明也只能回答被问到的问题。而很多业务人员其实不太会问——要么问得太笼统“帮我看看数据”要么问的方式让模型无法定位用了一堆公司内部黑话却没给上下文。所以智能问数落地往往要配套做一件事沉淀一批高质量的问法范例。把业务部门常问的问题、对应的正确口径、期望的答案形式整理出来既作为语义层建设的输入这些高频问题定义了哪些对象关系必须先建好也作为引导业务人员提问的参考。这件事做扎实了问答准确率会有一个明显的台阶式提升。它不是技术问题是怎么让业务和大模型对齐的问题。六、问数落地拼的是语义这层底子大模型让用自然语言查数据这件事从不可能变成了可能这是实打实的进步。但能不能在企业里真正用起来、用得准、用得让人信取决于它背后那层语义做得多扎实。智能问数、跨系统分析、辅助决策这些场景听起来都很吸引人但它们共享同一个前提企业得先把自己散落的业务对象、关系、规则用一种大模型能理解的方式表达出来。这件事不做再强的大模型也只能在企业门口打转。这大概也是为什么那些真正把智能问数用起来的企业花的力气最多的不是接大模型而是搭语义。模型是别人的语义是自己的——这才是企业 AI 能不能落地的分水岭。