语义层方案可以分为哪五个层级？各层级的核心特征是什么？

语义层分为L0到L4五个层级：L0提示词语义——无语义，靠模型推理，同一问题连续问三遍会得到不同SQL；L1描述语义——可参考，加入表和字段备注、指标字典作为模型参考，准确率约68%；L2契约语义——可执行，指标被定义为系统一等对象，查询经语义编译生成确定性SQL；L3组装语义——可组装，原子级语义对象基于明细数据动态组装，覆盖未知问题；L4过程语义——可验证，改动可追溯影响范围，多步分析全程可查证。

L1到L2的分界线是什么？为什么说L1的天花板在68%附近？

L1到L2的分界线是从“辅助模型猜测”到“系统无需猜测”。L1通过提供语义文档将模型准确率从45-50%提升至68%左右，但仍然是概率生成。L2则将语义从参考变为约束，模型不直接接触物理schema，而是向语义层发送中间表示（如MQL），再由确定性引擎编译为SQL。在一项企业级基准测试中，L2方案的执行准确率达到94.15%，而直接面向物理schema的方案最高仅31.3%。

L2到L3的分界线为何最关键？如何判断一个方案是L2还是L3？

L2覆盖已知问题，L3覆盖未知问题。报表时代问题集是有限的，但Agent时代业务方会随口问出从未被预设过的指标×维度×筛选组合。L3基于明细数据将原子级语义对象动态组装，能以最大语义覆盖度应对开放式问题。判别要点：如果语义对象均为预定义成品，查询只能落在预建宽表与聚合结果上，则仍停留在L2。判断依据要看最小粒度是什么、查询最终落在哪里。

企业如何在PoC现场验证一个语义层方案的真实层级？

建议用企业自己的数据验证：验证L2——挑一个核心指标当场改口径，看变更发生在哪里（改提示词是L0、改文档是L1、改带版本的定义对象才是L2），改完后问同一问题看是否同步；验证L3——让业务人员提三个“报表里没有”的临时口径问题，若对方说需要建模型加表则是L2，同时记录耗时，明细级动态组装需有物化加速保障性能；验证L4——多步分析结论要能点开看到引用的指标定义、查询和中间计算，且能一直点到底。

Aloudata 在语义层技术路线上做了哪些选择？

Aloudata 选择了三条技术路径：1) NL2MQL2SQL——大模型不直接写SQL，而是生成MQL（标明指标、维度、筛选的中间表示），由语义层确定性编译为SQL，模型职责从“完成整段编码”收缩为“从治理好的指标库中选对项”；2) 原子级语义对象+NoETL智能物化——基于明细数据进行原子级封装，支持动态组装，性能由物化策略保障；3) 歧义强制澄清，回答附带证据引用——口径不明时强制反问，数值附加可回溯的引用角标。

L3到L4的分界线是什么？为什么L3需要L4作为补充？

L3到L4的分界线是从“答案正确”到“过程可验证”。L3能动态组装、答得又快又准，但只吐数字不给引用，改了口径也不提示影响范围。L3回答的是没有人预设过的问题，也就没有人能预先核验。当分析结论要进入经营会议和决策流程时，过程可查证不是锦上添花，而是答案唯一可能被信任的方式。L4要求改动一个基础指标定义时，系统能列出所有下游影响并跑回归，多步分析全程可追溯。

不同层级的语义层分别适合什么样的业务场景？

L0适用于个人临时性探索；L1适用于小范围、单场景的问数需求，用户规模和数据量有限，错误代价可承受；L2足以支撑稳定的报表体系与已治理好的指标看板；如果企业采购的是企业级分析Agent，期望它能回答业务方随口问出的开放式问题，那么L3才是真正的入场线；L4则是在L3基础上对过程可验证的更高要求，适用于经营会议和决策场景。

产品解决方案客户案例资源中心合作伙伴关于我们立即咨询

首页>NoETL 博客>当所有人都在谈论语义层，如何判断一个方案的上限？

当所有人都在谈论语义层，如何判断一个方案的上限？

作者：刘靓2026-08-05|NoETL 博客

Aloudata CAN 指标平台发布于 2023 年 12 月。此后两年多，我们投入最多的工作，是向客户解释什么是指标语义层，以及它为什么必要。

最初是在 BI 场景中解释指标口径治理、管理和指标开发一体化的必要性。后来市场对智能问数的热情迅速升温，我们反复强调在 AI 场景下语义层的建设更加必要和紧迫：没有语义层，AI 便无法稳定、准确地响应数据查询。围绕这一主题，我们写过文章，画过漫画，做过视频，几乎试遍了所有能想到的传播方式。这个过程并不轻松——语义层在当时远非厂商共识，一家创业公司要去定义和布道一个新品类，意味着需要反复从零开始构建认知。

熟悉我们的朋友会发现，我们上半年发表了一系列文章，介绍海外数据厂商和研究机构在语义层的一系列动作：OSI 推动了语义的共识，各大厂商相继将“语义/上下文”纳入平台内置能力，Gartner 一再发声将语义与上下文视为关键基础设施，Forrester 亦已启动语义层平台的专项覆盖。至此，语义层在海外不再仅被视为“有价值”，而是被确认为一个可独立评估的品类。

而近期，我们发现国内厂商也终于集体跟进：云厂商将语义层植入数据开发治理平台；运营商发布了通过信通院双认证的本体建模平台；BI 厂商将 ChatBI 升级为搭载指标语义的 Agent 架构；就连一直坚持 NL2SQL 路线的 AI Native 厂商，也开始在方案中写入“语义层”字样。

我们的心情有些复杂。

一方面是“终于”。终于不再是孤独的布道者。

另一方面则是担忧。当一个词汇被所有人同时使用，它便不再传递有效信息。客户翻开五份方案，五份都写着“基于语义层”，这句话便等同于没有说。接下来的剧情会迅速滑向选型只对着功能打钩和报价。

因此，我们想对语义层做一次认真的拆解，为市场提供一把选型的衡量标尺。这把尺子，同样也度量我们自己。

语义层，不是有或无的问题

我们将 AI 分析方案的语义能力划分为五个层级。

L0 提示词语义——无语义。 把表结构、字段名塞进大模型的提示词，模型直接生成 SQL。没有独立的语义资产，一切靠模型推理。这一级严格来说不存在语义层——语义活在每一次对话里，对话结束，它就消失了。判断成本最低的方法是：同一个问题连续问三遍，拿回三份不一样的 SQL，这就是 L0。

L1 描述语义——可参考。 在 L0 基础上加入表和字段的备注、指标字典、业务文档知识库，作为模型的参考材料。模型的推理准确率会显著提升，但本质仍然是概率生成，没有确定性保障。口径散落在各处文档里，一处要改就得处处翻修，一致性很难维持——这个成本往往在上线数月后才真正显现。

L2 契约语义——可执行。 到这一级才发生质变：指标、维度、关系被定义为系统里独立的一等对象，查询经过语义编译生成确定性的 SQL，不再依赖模型猜测。同一个指标，无论谁来问、以什么方式问，引用的都是同一个可版本化的定义。它能稳定覆盖所有“已知问题”。但常见的失效方式是：每个新场景 fork 一个指标变体，场景一多，指标数量快速膨胀，治理成本反噬，没人说得清哪个是哪个。

L3 组装语义——可组装。 语义对象拆解到原子级——原子指标、原子维度、关联关系——基于明细数据动态组装执行，而非做成一个个预定义的成品。关键区别在于：没有预设过的指标×维度×筛选组合，系统也能正确组装和快速查询出来，口径一致。简言之，L2 覆盖已知问题，L3 覆盖未知问题。

L4 过程语义——可验证。 这一级有两层含义。一层在语义层内部：改动一个基础指标的定义，哪些指标、哪些报表、哪些历史分析会跟着变，系统要列得出来，也要跑得了回归。另一层在分析过程中：多步分析的每一步引用了哪个指标定义、生成了什么查询、经过哪些中间计算，全程可追溯。答案不只是对，而且能证明自己是对的。

换成用户视角来总结下，L1 到 L4 对应的是四种体验：答不稳，答已知，答未知，答得可查证。

三条分界线

从 L1 向上，存在三条质的分界线。

L1→L2：从“辅助模型猜测”到“系统无需猜测”。

L1 的性价比其实很高。Cube 团队在一份配对对照实验中（arXiv:2604.25149）测得：仅提供数仓 schema 时，三个前沿模型的准确率在 45.5% 至 50.5% 之间；补上一份 4KB 的手写语义说明文档——描述数据集的度量、口径约定与消歧规则——之后，升至 67.7% 至 68.7%。该实验同时发现，是否提供这份文档解释了几乎全部的显著差异，而在同一档内更换模型差异并不显著。也就是说，L1 便宜、有效，但它的天花板，就停在 68% 附近。

而 L2 则是将语义从参考变为了约束。学界的一项研究可以验证 L2 的价值。Kim、Khoeurn 与 Yoon 于今年 6 月发表了一套语义层中介式 NL2SQL 智能体（arXiv:2606.31041）：模型不直接接触物理 schema，而是向语义层发出一段称为 SMQ 的紧凑中间表示——一个仅含 metrics、filters、group_by 三个字段的 JSON——再由确定性引擎将其编译为方言正确的 SQL。系统强制规定，模型最终查询中出现的每一个表名与列表达式，都必须取自编译器的输出，禁止模型自行生成，也禁止直接查询 INFORMATION_SCHEMA。

结果是：在 547 个任务的企业级基准 Spider2-snow 上，该系统执行准确率为 94.15%。而同一榜单上直接面向物理 schema 的方案，DAIL-SQL 为 2.2%，Spider-Agent 为 23.6% 至 25.8%，ReFoRCE 为 31.3%。

作者还有一个结论值得留意：系统准确率的上限，取决于每个库的语义模型描述得多准、关联关系声明得多全，语义层本身成为主要的维护面。

因此，L1 与 L2 的区别在于：语义究竟是供模型参考的辅助材料，还是系统必须严格遵守的契约。

L2→L3：从“覆盖已知问题”到“覆盖未知问题”。

这是我们认为最关键的一道分界，其根本原因在于数据消费方式的根本性变革。

报表时代，问题集合是有限的、可枚举的。业务方提出需求，数据团队建模、建宽表、出报表，预定义口径足以应对。Agent 时代则完全不同：问题空间无法穷举。业务方会随口问出一个从未被预设过的指标×维度×筛选组合，并且他会视之为理所当然——他所面对的，是一个自称能够回答问题的系统，而非一张固定不变的报表。

为报表时代构建的语义层，不足以支撑 Agent 的开放式问题空间。只有基于明细数据，将原子级的语义对象进行动态组装和查询执行，才能以最大的语义覆盖度应对 AI 时代的开放性问题。

此处有一个实用的判别要点：如果语义层产品拥有实体界面，但其语义对象均为预定义的成品，查询只能落在预建宽表与聚合结果之上，那么它仍停留在 L2——即便方案上写着“语义层”三个字，即便它确实提供了一个语义建模的产品界面。判断依据要看最小粒度是什么，查询最终落在哪里。

L3→L4：从“答案正确”到“过程可验证”。

这一条与前两条不完全同类。前四级回答的是“能不能算对”，L4 回答的是“能不能证明算对了”。而且 L3 并不自动带来 L4——一套能动态组装、答得又快又准，却只吐一个数字、不给引用、改了口径也不提示影响范围的系统，完全建得出来，而且往往就是这类产品的第一版形态。

但 L3 会让 L4 从加分项变成必需品。L2 时代问题集可枚举，答案可以人工事后抽查；到了 L3，系统回答的是没有人预设过的问题，也就没有人能够预先核验它。当分析结论要进入经营会议、进入汇报材料、进入决策流程，“你是怎么算出来的”会被反复追问——此时过程可查证不是锦上添花，而是这个答案唯一可能被信任的方式。

每一层级都有其成立的场景

有必要说一句公道话：分级的目的，并非贬低低层级方案。

L0 适用于个人临时性探索——快速、灵活，出错了自己承担。L1 适用于小范围、单场景的问数需求，用户规模和数据量有限，问题相对集中，错误的代价尚可承受。L2 则足以支撑稳定的报表体系与已治理好的指标看板。

如果场景只需要 L1，就不必为 L3 付费，这是合理的成本控制。

但如果企业采购的是一个企业级分析 Agent，期望它能回答业务方随口问出来的问题，那么 L3 才是真正的入场线。

把问题带到自己的数据上去问

分级体系讲完，还必须给出验收方法，否则便只是一套自洽的说法。

下面这些问题建议在 PoC 现场用企业自己的数据来验证，而不是只看厂商准备的 demo，demo 里的问题天然经过筛选，而经过筛选的问题验证不了上限。

L0 和 L1 不需要单独设验证，问一句就知道。需要动手的是后面的三条分界线：

验证 L2：定义在哪里，改一次动几处

L2 的承诺是查询由语义编译生成、同一指标全局同一定义。顺利的时候看不出差别，所以要通过口径变更过程验证这个定义是不是一个真实存在的对象。

挑一个核心指标，请对方当场改掉它的口径。先看这次变更发生在哪里：改提示词是 L0，改文档或知识库是 L1，而改在一个带版本、有变更记录的定义对象上，才是 L2。

改完之后，问同一个问题，看拿到的是新口径还是旧口径。不同步，说明定义并没有真正收敛到一处。

验证 L3：用厂商没见过的问题

L3 与 L2 的分界，是能不能回答没有被预设过的问题。所以这一层唯一有效的验法，是提问临时口径。

让业务人员现场提三个“我平时会问、但报表里没有”的问题。典型形态是一个已有指标 × 一个从没和它一起看过的维度 × 一个临时筛选。如果对方说“这个我们回去建个模型、加张表”，那就是 L2。

记录耗时。明细级动态组装如果没有物化加速兜底会很慢，慢到业务不愿意再问，这个能力就等于没有。同一个问题第二次问是否明显变快，也值得一并观察。

验证 L4：你凭什么知道它是对的

到了 L3，系统开始回答没有人预设过的问题，也就没有人能够预先核验它。所以 L4 层要验证的是：面对一个你从没见过的答案，你凭什么相信它。

一个多步分析的结论，要能点开看到它引用了哪个指标定义、生成了什么查询、经过哪些中间计算。顺便看一下，是不是能一直点到底。

直接问：如果修改了某个指标的口径，哪些下游资产会受影响？系统列得出来，才是真正的 L4。

我们选择的技术路径

最后，简述 Aloudata 的技术选择，供读者对照参考。

NL2MQL2SQL。大模型不直接编写 SQL，而是生成 MQL（Metric Query Language）——一段标明所需指标、维度与筛选条件的中间表示。模型首先引用受治理的语义，再由语义层将 MQL 编译为确定性的 SQL。模型的职责从“完成整段编码的开放性问题”，收缩为“从治理好的指标库中选出正确项的选择题”。

原子级语义对象 + NoETL 智能物化。基于明细级数据进行原子级语义封装，指标、维度、关联关系被拆解至最小粒度，支持动态组装与查询服务，而非将语义对象固化为预定义的成品。性能由物化策略保障，不必为每个场景人工预建宽表和 Cube。

歧义强制澄清，回答附带证据引用。口径不明时强制反问，而非代用户选择；数值附加引用角标，可回溯其来源——包括使用的指标查询、生成的 SQL 和 Python 计算逻辑。

这些选择都有代价。MQL 的优势限于已治理的语义空间之内。如果一个全新的探索性问题匹配不上任何已定义的语义对象，选择题就做不成。

所以关键在于把“能用选择题回答的空间”做得足够宽。这也是我们坚持把语义层建在明细层，而不是报表层或宽表层的原因。

而这个空间并非一日建成。务实的做法仍是从一组高频核心指标起步，在持续使用中逐步完善治理。

这就是今天我们想探讨的话题，欢迎以上述问题检验我们。

Data Agent，也要像 BI 一样推广吗？