大模型能写出语法正确的 SQL，却常算错同一个「良率」：口径散落在代码与人脑里，两个 Agent 得出不同数字且都自洽。语义层把业务概念、字段映射与计算口径编译成受认证、可追溯的资产，让 Agent 先确认能否回答、按什么口径回答。本文以 NVIDIA 开源的 Auto Ontology 为样本，讲清 certified 定义、provenance 与只读 MCP，以及制造业为何尤其需要这一层。
一句话概述
大模型分析工业数据最常见的失败，不是 SQL 写错，而是口径没人对齐：同一个「良率」，两条 SQL 都成立，数字却差十几个百分点。语义层（semantic layer）就是把「这个指标在业务上是什么意思、映射到哪些列、按哪个公式算、谁批准的」变成可认证、可追溯的资产，让 Agent 先确认能不能答、按什么口径答，再动手查询。这不是给工厂多加一个 AI 功能，而是给 AI 补一层它一直缺失的业务地基。
一、SQL 对了，数字却错了
设想一个再普通不过的提问：「上个月 3 号线的良率是多少？」
- Agent A 按一次合格率算：分母含全部过站记录，得到 82.4%；
- Agent B 按终检合格率算：分母只含终检记录，得到 91.7%；
- 两条 SQL 语法正确、连接正确、都能跑出结果，谁都没「幻觉」。
问题出在业务含义没有被存在系统里。「良率」是中文词，数据库里只有 judge、station_no、lot_id 这样的列名；哪个列算合格、分母要不要排除调试件、跨产线是否合并，全靠工程师口口相传。模型只能从列名和采样值里猜，猜错也无从自知。
这类错误比生成一段错误的 SQL 更危险：它输出干净、图表漂亮、结论言之凿凿，却把两个部门的决策引向不同方向。
二、数据库里没有「业务含义」
数据库的强项是存值与保证事务，不是存语义。它知道一列是整数，不知道这列代表「一次合格率」还是「终检合格率」；知道两表有外键，不知道这条 join 在业务上是否被允许。
于是把 schema 直接塞进大模型上下文，会撞上三堵墙：
- 隐性知识：列名到业务概念的映射写在人的脑子里；
- 上下文预算：表越多，schema 越吃 token，关键定义反而被稀释；
- 即兴 join：模型每次现推连接路径，无法判断业务逻辑是否成立。
更隐蔽的是「无法回答」与「结果为零」分不清：当数据里根本没有广告支出这类字段，模型仍可能编出一条 SQL 返回空集，让人误以为答案是 0。
三、语义层到底存了什么
语义层不是又一个报表工具，也不是 OWL 推理器，而是关系数据之上的一层业务语义模型。以 NVIDIA 在 2026 年 11 月开源的 Auto Ontology 为例，它的核心对象大致三类：
| 对象 | 存的是什么 | 工业场景例子 |
|---|---|---|
| Term | 业务概念、描述、同义词 | 良率、工单、LOT、工程、一次合格率 |
| ColumnAttribute | 业务属性到物理列的映射 | 良率 → 生产明细表的判定列 |
| SqlAttribute | 可复用的派生表达式（受治理口径） | OEE = A×P×Q、Cpk、一次合格率 |
三者叠起来才是「口径」：术语把问法收敛到唯一概念，列映射告诉模型数据在哪，SqlAttribute 直接给出经过认证的算法。检索可以是概率性的，但定义必须是确定性的——把确定性的部分从模型手里拿走，幻觉空间才被压缩到意图理解这一小段。
物理表只存列与值；语义层补上业务概念、字段映射与受认证的计算口径。
四、为什么「自动生成」不等于「业务批准」
语义层最容易被误解的一点，是以为「自动生成本体」就等于「口径已经可信」。恰恰相反。
Auto Ontology 的官方流程是五步：Discover（从元数据生成起始本体，也可导入既有语义模型）→ Ground（调和跨系统的不一致定义）→ Validate（用认证定义与血缘校验查询，答案带 provenance）→ Expose（经 MCP / CLI / API 暴露）→ Learn（把认证修正与使用回灌本体）。
其中语义编译由 LLM 提案术语、列归属与候选 SQL 表达式，但产出只是草稿，必须由业务专家在界面或用真实问题测试、修正后打上认证标记；未认证的内容不应作为对外答案的依据。这一步没有捷径：把「哪个分母算良率」这种问题交给模型自动拍板，等于把治理责任交给概率。
自动编译只是草稿，人工认证才让口径生效；每次修正回灌本体。
配套的两个设计也很关键：
- provenance：答案连同 SQL、命中的术语、认证状态一起返回，数字可回溯到口径；
- 只读 MCP：官方
docs/mcp.md列出 9 个只读工具（ask_question、check_answerable、check_readiness、search_terms、get_term、get_term_columns、get_term_sql_attributes、get_sql_attribute、describe_table），并明确刻意不提供浏览原始库表的工具——Agent 必须经语义层触达数据。check_answerable先判断这问题能不能答，check_readiness先判断语义层是否已编译且库连接是否存活，避免「看着健康但每问必败」。
五、一个可对照的开源样本
把 Auto Ontology 当样本，是因为它的边界写得比较诚实：Apache-2.0 许可、Next.js 前端 + FastAPI 后端 + 摄取服务 + Postgres/pgvector 的组合，默认模型走 NVIDIA NIM 的 Nemotron 系列，但按角色用环境变量三元组配置，可换成任意 OpenAI 兼容端点；连接器里包含 SQLite，对开发态数据库友好。
同时也要看清它现在不适合什么：官方 CONTRIBUTING.md 明确当前不接受外部 PR，仓库尚无正式 Release；官方把 Vault 列为可选组件，生产部署的连接凭据存储需自行加固；README 自报「本体创建时间缩短 90%」但并未公布基线与测试方法，评测交给独立仓库在 BIRD 等基准上做。换句话说，它现在更适合当设计蓝本与试点工具，而不是直接当生产基础设施依赖。
六、制造业为什么尤其需要这一层
制造业的口径混乱有结构性原因：同一个指标在设备、产线、工厂三层各算一次，MES、质量系统、集团报表各有实现；「一次合格率 / 终检合格率 / 直通率」在口语里常混用；OEE 的 A、P、Q 三个分量在不同代码里可能各有一套公式。
再加上工业数据自带的关联要求：同一个数字必须说清是哪个工厂、什么时间、哪条产线、哪台设备、哪个工序、哪一批次，沿什么控制逻辑汇聚上来。缺了这层关联，口径认证就无从谈起。
同一个「良率」两条 SQL 都成立，差别只在分母口径是否被认证。
青璃在这方面的做法可作为一个普通案例：在 ONLINE 数据管理分析系统里把 OEE、CPK 等计算口径统一固化，并用三环联动控制模型描述设备、产线、工单之间的数据关联，让「损失落在哪道工序」能沿关系链回溯。这里重点不是某个产品，而是同样的问题——口径能不能被认证、结论能不能回到源头。
七、落地时建议的顺序
- 先盘口径，再谈模型：把最常问的 10 个指标列出来，逐个写清分母、过滤条件、时间口径与归属层级；
- 认证优先于覆盖：宁可只让 5 个 certified 指标可答，也不要让 50 个草稿口径被 Agent 引用；
- Agent 只走语义层：不提供裸库浏览，权限继承登录人角色，每个答案保留 SQL 与认证状态；
- 先试点再依赖：用演示库跑通 ingest → compile → ask_question，实测能不能正确回答自己业务的几个问题，再决定是否纳入生产栈；
- 语义资产留在自己库里：本体是治理资产，不应锁死在某个年轻框架的数据模型上。
八、结语：从「答得快」到「答得对」
过去几年，工业软件的读者默认是人：看板、报表、筛选器，人来点、人来读。当模型成为数据的第一消费者，软件的核心资产就从「有多少功能」变成「有没有一套机器可推理、且被人批准过的业务定义」。
语义层不会让模型更聪明，但能让模型少猜一点：口径是确定的，来源是可查的，不能回答的问题会被提前拦下。对制造业而言，这比多一个会聊天的界面重要得多——因为工厂里的每一个数字，最终都要落回到某条产线、某道工序、某批物料上。
参考来源
本文关于 Auto Ontology 的事实以官方仓库一手文件为准；项目处于早期，接口与部署方式可能变化，建议以仓库当前版本复核。
[1] NVIDIA/auto-ontology README（定位、五能力、Apache-2.0、模型三元组） — https://github.com/NVIDIA/auto-ontology
[4] 官方 LICENSE（Apache License 2.0） — https://github.com/NVIDIA/auto-ontology/blob/main/LICENSE
[6] 官方评测仓库 ontology-sql-eval（BIRD 等基准） — https://github.com/NVIDIA/ontology-sql-eval
[7] 青璃官网博客《从 GPT Astra 看未来工厂》 — https://www.tsingley.com/blog/gpt-astra-future-factory-online
