智能体需要可解释的含义：语义层、本体论与受控指标
当含义无法明确时，对话式商业智能就会失效。文本转SQL的研究表明，语义层、本体论以及规范标识如何确保答案的准确性。
来源: Make Meaning Machine-Interpretable Before You Trust the Agent
想象一下周一的例会场景。一位同事将代理商的回复粘贴到Slack上：上季度每客户的收入数据，格式整齐，解释简明，且充满自信。财务人员看了一眼，整个会议室顿时陷入沉默。那个数字指的是预订量，而已确认的收入则存储在另一个具有不同粒度及自身排除项列表的数据中。SQL本身没有问题，只是大家尚未明确问题的真正含义。
经历了太多这样的场景后，“模型生成了有效的SQL”已不再被视为成功标准。大型语言模型几乎让所有仓库数据都具备了机器可读性。可读性很容易实现，但可解释性才是稀缺的——对于这家特定公司、在做出这个特定决策时，客户、收入、活跃用户、流失率以及上季度这些概念究竟意味着什么？
在智能体出现之前，人们会在编写任何查询之前先进行解读。在运行时将任务交给智能体，除非提供预设的答案，否则它会即兴编造一个合理的解释。根本的解决方案是将企业语义视为产品来管理：为其赋予标识、进行版本控制、进行测试、将其与实际数据对应起来，让人类和软件能够以相同方式使用它。
对大多数团队而言，可交付的成果是一个受规范约束的语义层或指标层。更长远的目标则是构建以本体论为驱动的模型，该模型能够整合各种下游输出，无论是LookML、SQL视图、API契约还是智能体工具，从而避免每个产品都不得不自行创造一套私有规则。
为何可靠的答案反而会带来风险
基于聊天的商业智能通常被描述为“从自然语言到SQL的转换”，这一说法掩盖了其中的难点。真正的难点在于如何在一个参考框架下理解问题，并将其含义迁移到另一个参考框架中。
试想这样一个问题：“上个季度各客户的收入是多少？”对于仓库而言，执行精确的查询并不困难。真正的挑战在于确定该用哪种查询来对应这个问题。这里的“收入”可能指订单额、账单金额或已确认的收入；客户则可能是销售对象、开票对象，或是季度报表中显示的任何账户层级节点。而“上个季度”的时间范围也可能依据日历月份、财年，或是运营团队所选择的滚动周期来界定。
在仪表板上，分析师早已做出了这些决策。标有“收入”字样的数据块显得十分权威，因为相关语义决策早已内嵌在该数据载体中。而聊天式系统则颠倒了这一顺序——现在，对于任意问题，决策都是在软件运行时动态做出的，这使得语义信息从维基页面变成了运行时基础设施。
令人担忧的是，模型在生成看似合理的SQL语句方面的能力越强，其错误带来的危害就越大。语法正确性并不能说明语义上的有效性。一个表述完美的解释可能会如此巧妙地回答错误的问题，以至于在板报内容与聊天记录出现矛盾之前，没人会察觉到问题。那些只关注查询是否执行过的团队，实际上是在培养自己信任那些看似合理实则错误的答案。
维度模型本身已蕴含一定意义
尽管如此，仓库数据也并非一张白纸。基于Kimball理念的维度建模多年来一直在弥补通用关系型数据库结构表达能力的不足。事实、维度、度量值、粒度、层次结构以及一致性维度，都将业务含义融入到人们可以查询的结构之中。
一个构建良好的星型模式本身就已能充当非正式的语义层。而现代的语义层则在此基础上进一步添加了度量定义、计算规则、术语、允许存在的关联以及列名无法体现的商业规则。正式的本体论则走得更远，它刻意将概念模型与其关系型实现分离，并在两者之间建立映射关系。
最好将其视为一条连续谱，而非一种转换过程：
- 操作型关系型模式
- 维度模型
- 语义层
- 正式本体论
沿着这条序列向下推进，意味着会为模型注入更多含义，从而减少其需要猜测的部分。每一处被隐含的内容，都是一种期望：通过推理能够得到首席财务官所认可的定义。
研究持续揭示的结论
近期的文本转SQL研究都得出了同一个结论：明确业务含义能够提升准确性，这一效果即便在原本为分析而设计的模式中依然成立。
Figueiredo及其同事在测试中让GPT-4 Turbo处理星型模式数据。仅依靠该模式本身，查询的正确率约为58%，而加入上下文语义后这一比例上升到了约89%。Rumiantsau和Fokeev在基于Contoso构建的分析仓库模型中添加了简短的语义文档，准确率从大约48%提升到了52%，甚至进入了60%的高位区间。这些提升意义重大，因为最初的基准并非混乱的事务型模式。
当物理架构对业务信息的描述越少时，其负面影响就会越明显。Painter及其同事针对一个包含500多个表的运营数据库进行了优化，通过提供术语、规则、关联关系及映射信息，将经过验证的SQL生成率从约8%提升到了约78%。Nascimento及其同事则通过引入以业务为导向的概念名称，使一个复杂的工业数据库的执行准确率从41%上升到了65%；而当有用的关联语义也被明确体现后，这一比例更是提升到了74%。
各类正式模型呈现相同的趋势。Sequeda、Allemang和Jacob的一项研究显示，直接对企业关系数据库提问题时的准确率约为17%，而通过由本体论支持的知识图谱进行查询时准确率可达到约54%。Nascimento的后续研究仍选择使用关系型存储来执行SQL语句，但首先通过知识图谱将业务概念与物理架构相连接。以架构关联F1值衡量时，仅使用大型语言模型的准确率约为0.85；采用知识图谱方法的准确率为0.90，结合知识图谱与大型语言模型的准确率为0.93，而具备完美召回率的完整语义关联流程的准确率则达到0.996。
其合理解读应从架构层面而非宣传角度入手：明确概念与关系结构之间的映射关系，减少模型在语义处理上的自主发挥空间，将执行任务交由原本就高效运作的关系型引擎来完成。
关系模型做到了什么与没做到什么
Codd提出的关系模型实现了数据独立性：应用程序不应依赖于数据的物理存储方式。这一成就至今依然重要。
对话式商业智能则需要更具体、更复杂的要求。仅靠关系型分析模式本身并无法涵盖回答问题所需的全部业务含义。名称、键、约束条件以及注释能起到辅助作用，而维度模型则能提供更大帮助。不过，度量标准定义、各术语的角色、时间规范、数据来源以及将概念映射到物理对象的规则，往往仍存在于人们的头脑中或演示文稿里。
正因如此，词汇表、度量存储、语义层以及目录才围绕着数据仓库应运而生。它们逐步明确了分析师或大型语言模型原本可能需要即兴处理的那些内容。现代语义层是在业务智能应用场景中的一种实用解决方案。它的范围仍比企业的整体概念模型要窄，若将两者混为一谈，团队日后就难免会感到意外。
在保留数据仓库的同时添加本体
在信息科学实践中，本体用于描述目标领域中存在的实体、关系及约束，其表述方式便于软件使用。它与谓词逻辑中的关系模型同源，都是用于描述事物及其相互关系的陈述。
数据库领域早已在研究这一问题。W3C的直接映射与R2RML规定了关系型数据如何转化为RDF词汇表。基于本体的数据访问则将这一理念进一步推进：用户查询概念模型，系统便会将其转换为针对现有数据源的SQL语句。成熟的开源虚拟知识图谱Ontop正是通过R2RML映射以及轻量级的OWL 2 QL本体来实现这一功能的。
选择OWL 2 QL虽不那么引人注目，但却有其实用的理由。它属于DL-Lite系列，该系列的局限性是刻意设计的，旨在确保通过本体论进行的查询在面对大型关系数据库时仍能高效处理。为了能够将查询重写为SQL，它牺牲了表达能力。早在那时，针对仓库和多维模型的本体论研究就已经存在，这类本体论能够表示维度、度量值和层次结构，并从概念模型中推导出分析结构。
目前仍很少被采用的，是一种专为现代商业智能设计的本体论语言，它能够在统一的受控模型中整合业务实体、关系、度量值、粒度、聚合、时间、来源信息以及仓库映射等内容。
采用这种方式并不意味着要将仓库数据迁移到图数据库中。含义可以在本体中描述，而事实仍保留在关系表中，计算则通过SQL完成。将图结构具体化是可选的，仅对能从中受益的工作负载有用，并非决定性标准。
存储的事实及其含义
行与RDF三元组之间的关联比工具间的竞争所显示的更为紧密。行用于表明某个元组属于某个命名关系，而三元组则将命题拆分为主语、谓语和宾语。强规范化已经促使关系型设计趋向于更小的事实单元。二者在形式上并不完全等价，但这种相似性颇具参考价值。
对智能体而言，重要的区别并非表格与图的区别，而是外延数据与内涵意义的区别：即存储的事实与关于这些事实含义的规则。本体可以声明一个类包含另一个类、两个谓词互为逆关系、某种关系具有传递性，或者某种特定组合是不可能的。OWL为这类声明提供了形式化语义，SHACL用于验证图的形状，而在需要更复杂逻辑时还有更完善的逻辑框架可供使用。
并非所有的本体都能顺利转换为 SQL，因为某些语言的表达能力超出了高效转换工具的处理范围。OBDA 研究正直面这一问题，提供了限制表达能力、进行近似处理、物化存储或分步推理等解决方案。这种约束很有用，因为它强制明确哪些语义会在预编译的执行路径上生效，哪些则不在所选配置范围内。如今很少有企业会记录这些损失，因此它们便以争论的形式出现在聊天频道中。
供应商的上下文并非你的本体
各供应商已在积极行动。Google Cloud就是一个很好的例子，其2026年的几项新功能都针对机器可使用的企业级场景。Dataplex Universal Catalog已被重新设计为Knowledge Catalog，更像是一个实时的上下文图谱，而非静态的注册表。它提供语义搜索、丰富的描述、关系图谱、经过验证的SQL模板、上下文API以及供智能体使用的访问路径。与此同时，Looker的Open SQL接口允许JDBC客户端将LookML模型视为模式来查询，从而复用其中已定义的维度、聚合值、计算结果及关系。
这些新功能都印证了一个基本观点：智能体需要的不仅仅是数据行级的访问权限，还需要经过整理的上下文、语义模型、各种关系、经过验证的示例以及受管控的接口。
即便如此，它们仍未能形成统一的整体企业本体。LookML语义、目录术语、BigQuery图定义以及由智能体生成的上下文虽相互关联，但属于不同的表达形式。除非组织拥有这些要素的标准标识符及明确的映射关系，否则“只需定义一次”的承诺就会沦为空谈，实际上不得不为每个产品分别定义。
整个季度的时间都浪费在了这种困境中。供应商的上下文图虽然极具价值，却不能作为语义真理的正式来源。可以自由采用它，但需记住，采用并不等同于拥有。
六大设计原则
最重要的原则是：含义必须同时能被人类和机器理解，并且在各种表达形式中保持一致。
为事物赋予意义与身份标识。每一个概念、关系、指标、政策以及质量声明都应拥有一个稳定的标识符。名称仅是标签，而标识符才是构成该对象的实质。术语“客户”会出现在控制面板、API、仓库表格以及客服提示中，所有这些地方都应指向同一个语义对象；如果业务上确实存在不同的概念，也应明确指向不同的对象。销售支持和财务部门可以对“活跃客户”的定义有所不同，前提是他们绝不能在未明确说明的情况下共享同一ID。
让定义具备可执行性。散文是为人和模型服务的，但任何影响计算的内容都需要结构支撑：类型、关系、基数、单位、公式、粒度、有效时间、约束条件、映射规则以及政策。目录中的描述性段落在很大程度上只是人为约定而已。
在基于 Google Cloud 构建的架构中，一种可行的分配方式如下：Knowledge Catalog 负责存储身份信息、定义、单位、所有权、有效时间、策略、关联关系以及映射关系；LookML 负责存储可执行的公式、维度、连接逻辑以及查询生成功能；Conversational Analytics 则在相应上下文中解析自然语言，以经过验证的查询作为回归分析的基准。只有当各组件的 ID 被刻意设置成跨越这些边界时，这种架构才能成立。
需明确将语义映射到物理数据上。假设本体中规定客户拥有一个账户，那么实现方案就必须为使该陈述成立的关系或推导过程命名，且这种映射关系及其两端的对应数据都应进行版本控制。没有一键工具能够将OWL直接应用到所有目录产品中，必须有人来构建并维护这种桥梁，否则“语义”这个词也就只不过是个品牌标签而已。
将关系视为首要要素。一个角色之所以有意义，是因为它与流程、组织、活动、能力及成本之间的关联，而非取决于名为role_type的列。客户、产品、合同、账户和指标也是如此。宽松的命名与表述方式已有助于自然语言向SQL的转换，但正式的关系语义才是区分关系型便利性与本体清晰度的关键。构建这些语义需要付出实际努力，而忽视这一成本的本体在试点阶段就会失败。
将度量标准保留在同一模型中。维度度量已具备标识、公式、粒度及聚合行为，而语义层则进一步提升了其可执行性。更广泛的含义，包括所有权、单位、排除项、来源、策略、生效日期以及与企业概念的关联，往往会被分散到其他系统中。实际上，真正的架构问题通常是碎片化：一个维度度量、一个LookML度量以及一个目录术语，分别以三种不同的身份描述着同一业务概念中相互重叠的部分。
一次编译，多种方式输出。 应有一个标准模型来生成或管理各种输出形式，如 LookML、SQL 视图、API 架构、目录条目、图结构、智能体工具契约、文档以及验证测试。平台可以保留自己的语法，但含义不应由它们自行定义。
LinkML证明了存在一种与技术无关的模型，能够生成SQL DDL、BigQuery DDL、JSON Schema、OpenAPI、OWL、SHACL、文档以及验证工具。但它无法替他人选择事实、维度、度量值、数据粒度或符合标准的维度。虽然已有将本体转换为星型模式的研究，但目前还没有主流技术链能够实现从标准本体，经过受管控的维度仓库和可执行的语义模型，最终生成基于本体的自然语言到SQL的转换。正是这一缺失的流程构成了工程上的挑战，而生成DDL仅仅是较为简单的演示而已。
两条路径与融合的需求
大多数企业无法暂停仓库程序并首先基于本体进行重构。这没有关系。关键是要让智能体能够可靠地处理可发货物品的含义，并设计出合适的策略路径使其逐步成熟。
在方案A中，标准的企业本体拥有语义权威性，具备稳定的标识符和明确的逻辑语义。物理数据不会变动，本体会被映射为关系型及其他表示形式。分析指标则变为编译后的预测结果。智能体会获取形式化的概念、关系、规则及来源信息，各项变更会像代码一样被版本控制并发布。产品内部的表示形式则源自企业所拥有的语义，或与之相对应。
备选方案从已有的基础架构开始构建：一个受管控的指标层，搭配目录与上下文模型，并有意识地为这些模型添加稳定的规范标识符。仓库始终保持权威性，而语义对象到表格、列、连接操作及过滤条件的映射关系也会被记录下来。智能体选择经过认证的字段和指标，而非原始表格，同时从上下文服务、经过验证的查询以及符合权限要求的检索机制中获取上下文信息。指标、映射关系、标准查询语句以及语义回归测试都会被纳入持续集成/持续部署流程中。特定产品内部的标识符永远不会转变为企业级身份标识，而交叉引用机制则确保了数据迁移的可行性。
在 Google Cloud 上，一个完善的备选方案是将用于提供上下文和辅助发现的 Knowledge Catalog 与 Looker 相结合：通过受管控的语义模型限制对话分析的范围，仅允许针对经过验证的语义对象进行分析，将已确认的查询作为回归基准，并将企业标识符独立于任何单一产品之外保存。Knowledge Catalog 仅在狭义上类似本体论，它能为智能体提供带类型的上下文与关系，但并非完整的正式本体论系统，应将其视为可灵活调整的工具而非不可更改的准则。
风险在于会出现这样的战术性语义层：其标识符与逻辑永远无法提升为更正式的模型。无法实现整合的备选方案不过是装饰着控制面板的死路而已。
先解决问题，再处理表格
一个合理的对话式 BI 实现路径不应从选择表格开始，而应从语义解析开始。
以“本季度高价值零售客户的流失率是否上升？”这一问题为例。在开始处理之前，必须先将“流失率”、“高价值零售客户”以及“本季度”这些概念转换为受管控的对象。这些对象包含了指标定义、分类标准、时间规则、允许的维度、数据来源映射以及相关策略。只有完成这些步骤后，执行层才能编写具体的查询语句。
循环处理团队应当能够按八个步骤复述整个处理流程：
- 问题与用户上下文
- 将语义内容转换为受管控的概念和指标
- 根据策略和权限筛选相关上下文
- 将语义对象映射到实际数据
- 生成查询语句或工具执行计划
- 执行查询并进行结果校验
- 提供有依据且来源明确的答案
这种思维方式绝非简单地将分析框架粘贴到提示词中然后寄希望于结果。大语言模型依然可以明确意图并制定计划，但它是通过受控的语义对象和工具契约来实现的，而非通过解码名为 fct_rev_v3 的表格中的CFO词汇表。
经过验证的查询可作为测试和示例，但它们并非语义本身。它们仅能证明某个问题在某一时刻得到了被接受的解决方案。其背后的含义仍需要独立的身份与定义。
何者不属于语义架构
满是文字描述的目录有助于发现，但它并非可执行的语义系统。
默认将分析工具指向原始仓库架构，并称其为自助式商业智能，其实只是将语义风险转嫁给了概率模型。
将每个仓库事实都复制到“用于人工智能”的知识图中，却缺乏明确的实施收益，这会导致出现另一个因同步延迟而落后的企业事实版本。
如果将指标与本体完全分离，以至于同一个业务概念在商业智能系统和知识模型中拥有相互冲突的标识，日后必然会引发矛盾。
将表现形式与语义混为一谈，比如认为图结构本质上比维度模型更具语义性，这种想法其实属于盲目模仿。维度模型、语义层、知识图谱和本体各自以不同的程度编码意义，仅选择图结构本身并不能增添意义。
将人工智能生成的元数据或关联关系视为事实，且不标注其来源或审核状态，正是这种看似合理的虚构内容如何演变为政策的途径。
一句话概括目标
人们希望像询问天气一样轻松地获取上个月的数据。这已不再是幻想。软件正在承担过去分析师和工程师默默完成的语义处理工作，而获得一致的答案则意味着要让这项工作变得明确化。
无论是安装在仓库中的大型语言模型，还是结合向量搜索的目录系统，都并非最终目标。真正的目标是一个受规范管理的语义系统，在该系统中，概念、关联、指标、约束、政策、质量及来源对人类和机器而言都具有统一含义，并通过正式的映射与底层数据相关联。
大部分基础数据仍然最适合在关系型数据库和SQL分析引擎中处理，语义或本体技术尚无法取代它们。语义技术的任务是在关系型架构本身无法承载的层面完善模型，即便在进行了维度建模和精心命名之后仍需如此。
当目前还无法实际构建并维护完整的分析本体时，可以先部署受管控的语义层，但需保持其结构不变。语义层应逐步向上迁移，从仪表板和查询提示中脱离出来，融入企业级核心模型中，同时将每个产品对应的层视为经过编译的视图。
目标并非某个单一的数据库、工具或语法。而是让人类、控制面板、应用程序以及人工智能代理都能以相同的方式理解同一含义。如果这四者之间存在分歧，问题就不出在大型语言模型上，而是被搁置的身份识别问题。
相关阅读
- 用通俗语言解释 LangGraph 概念：状态、内存与协调机制 —— 在编写代码之前：了解在 LangGraph 中协调机制、运行时、有状态代理、短期与长期记忆、多代理系统以及人类干预分别意味着什么。