一家做建材批发的商贸公司，三十家门店，去年上了AI问数，头一个月就出了个不大不小的洋相。月度经营分析会上，老板让AI现场拉一个毛利率前十的单品清单，屏幕上秒出结果。财务经理扫了一眼就皱眉：第三名那个瓷砖品类的毛利率不对，比财务报表里的数高了四个点。会议室安静了几秒，BI工程师小周把清单导出来对了一晚上，查明白的原因让人哭笑不得------AI认识"成本"这个词，也找到了成本字段，但它取的是入库成本，财务口径用的是移动加权成本。库存明细表里这两个字段挨着，名字就差两个字。
词全认识，数取错了。问题不出在词上，出在词和库之间那段没接上的路。
概念对得上嘴，对不上库，演示好看一问就穿帮
做数据平台的人管这一层叫语义层------把业务术语映射成数据库里的表和字段，让不懂SQL的人也能拿到数。这不算新东西，BI行业做了二十多年，报表工具里的语义模型、指标平台里的口径定义，干的都是这件事。新变化在于用的人：以前踩在语义层上的是写好固定逻辑的报表，映射错了顶多一张图错；现在踩在上面的是大模型，它要拿着这层映射去现场理解任意一句人话、自己拼取数路径------映射的每一处含糊，都会被放大成自由发挥的空间。语义层这个老概念，因为AI问数成了新的瓶颈。
行业里讲语义层，讲的就是这层映射：业务这边说"毛利率"，系统那头知道去哪张表、取哪个字段、按什么口径算。映射建好了，取数是毫秒级的事；映射没建，AI就只能自己猜。
猜，恰恰是大模型最危险的地方。库里的字段名是给人看的，不是给它看的------"入库成本""出库成本""移动加权成本""标准成本"，字面上个个都像成本，含义个个不同。大模型靠字面相似度挑一个，挑对了没人夸，挑错了它也不报错，照常吐出一个格式规整的数。这种错误的隐蔽性比报错可怕得多：问数界面上看不出任何异常，数错了就是错了，直到哪次对账才冒头，冒头的时候往往已经错了一阵子。
演示环境里问数又快又准，是因为厂商把词库和挂载都提前配好了。换到自己企业的环境，这道工序一寸都没干，效果自然两回事。不少团队在这里产生过误判------以为问数不准是模型不行，换模型、调提示词，折腾一圈，病根其实是词还没连到库上。
挂载这道工序，干的是最笨也最要紧的活
JBoltAI本体语义平台的数智化建设中心里，这道工序由本体数据源挂载智能体专职负责。它干的活说来不玄：把本体连接到具体的表，把本体属性连接到具体的字段。前面梳理导入的工序把词送进了网，这一步给每个词接上取数的管道------词有来处，数有去处，语义层到这里才算落地。
活虽然说不玄，工程上的讲究不少。一个本体未必只挂一张表------ERP的订单表和MES的工单表都挂给"订单"这个本体，问数时按来源前缀区分；反过来，一张宽表里的字段也可能分属不同本体，库存明细表的批次号挂给"批次"本体、库位编码挂给"库位"本体，各走各的逻辑。属性挂字段要带口径说明，同样是成本属性，挂到移动加权成本字段上就要注明口径。注明了有两个用处，下次有人问"这个数怎么算的"，答案有处可查；AI取数取到这个属性时，口径说明跟着进上下文，它就知道这个"成本"是移动加权口径，不会拿字面相似的另一个字段来凑。挂载关系本身也是记录在案的：哪天数取错了，回溯的时候能分清是挂载断了、口径标错了还是源头数据有问题，不用全盘推翻重来。
这些映射的确定，同样不是大模型自己拍板。哪个字段才是财务认的那个成本，智能体把候选字段和样例值摆出来，财务的人指定，指定的结果生效。跟梳理那道工序一个道理------机器起草，人确认，确定性的活交给智能体，口径的裁判权留给业务。
表在变，挂载就得跟着养
有一个容易被低估的事实：挂载不是配一次管永久。企业的表结构是活的------上年加了批次字段，今年门店系统升级换了库存表，字段改名的、含义变了的，每个变更都可能让原来的挂载悄悄失效。失效的挂载比没挂载更坑：没挂载问不出数，至少知道缺什么；挂载失效取回一个旧字段的数，错得悄无声息。
那家建材商贸公司后来真碰上了一回。门店系统升级，库存明细表从老库迁新库，表名没变，字段顺序全变了，还有三个字段改了名。迁移完的头一个星期没人觉得异常，问数照常出结果------直到有人发现"可用库存"答出来的数普遍偏大。排查发现老表里有个"可售数量"字段，新表里改名叫"在库数量"，含义从可卖口径变成了实物口径，原来的挂载跟着老字段名指到了新字段上。三个字段的改名，核对修正花了两天；要是当初挂载记录里没留口径说明，连排查的抓手都没有。
所以挂载清单和词库一样，是活的资产。系统升级、表结构变更，回来把挂载关系核一遍，变更的改挂载，下线的摘干净。这个维护量不大，但得有人管、有机制管------把挂载当成上线时的一次性配置，半年后问数开始出一些说不清的错数，再回头排查，花的功夫比每次变更时顺手核一遍多得多。
从工程体系上看，这一层映射也不是孤立的技能。JBoltAI本体语义平台把语义建模做成了基础工程件------问数、追溯、执行类的应用都踩在这层映射上取数，映射的质量直接决定上面所有应用的数的质量。地基打几分，楼就稳几分，这个关系在AI应用里一样成立。
两道工序合起来，才算答完"数从哪来"
把前两道工序连起来看，其实是一根链的两环。梳理导入解决"词从哪来"------每个词有出处、有前缀、有户口；数据源挂载解决"数到哪取"------每个词连着表、连着字段、带着口径。两环都通了，AI问数才谈得上可信：答出来的每个数，词有来处可查，数有去处可核。
那家建材商贸公司后来补了这门课。小周和财务把成本类属性的挂载逐个过了一遍，入库成本、移动加权成本各归各位，口径说明写进挂载记录。第二个月经营会上，AI拉的毛利率清单和财务报表对上了。老板问怎么做到的，小周的回答很实在：AI把词都认识了，我们把每个词该连哪个字段，一个一个给它连对了。
给正在上AI问数的团队一个便宜的检验动作：挑十个业务最常用的指标，让AI答一遍，再让人工按财务口径核一遍，十个里错两三个以上的，别急着调模型，先查挂载------多数时候，模型是替映射背了锅。
词都认识，数取不出来或者取不对，先别怀疑模型，低头看看词和库之间那段路通没通。