semantic-layer ontology knowledge-graph data-analytics ai-agents

本体还是语义层？人工智能代理需要两者中的什么。

本体与语义层有何不同，仅存在其一时会遇到什么问题，知识图谱的适用场景，以及构建上下文层的实际步骤。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 9 分钟1984 词

来源: **Ontology vs. Semantic Layer: Why Your AI Agent Needs Both**

向三个数据来源询问同一问题——即收入额是多少——得到的答案往往不尽相同：财务部门称其为1020万，市场部门称其为1040万，而Slack内置的AI助手则称其为980万美元。各方都无法达成一致。过去人们会通过简短的会议来解决这类问题。如今智能代理不会去询问同事某个指标的含义，因此当遇到名为rev_ttm_adj_v2的列时，它要么随意编造一个数字，要么直接采用最先出现的定义。

据称，将建模后的领域知识引入检索系统可使幻觉发生率降低约40%。但这仅限于知识以建模形式存在的情况，而非仅存在于少数构建表格的人的记忆中。如果中间只有原始表格和SQL代码，存储容量和智能代理的技能就几乎不起作用，因为企业不会依赖这些输出结果。

上下文层

上下文层负责定义函数而非产品。它汇集语义定义、领域知识、溯源信息、治理策略、质量指标以及认证状态，并通过统一接口为人类用户和智能体提供这些信息。

本体与语义层承担了此处的大部分工作。供应商的营销材料常常将二者混为一谈，但实际上它们解决的是不同的问题；如果构建顺序错误，会导致人工智能项目在演示时表现良好，但在实际应用中却无法正常运行。

一言以蔽之的职责划分

简而言之：语义层负责处理诸如收入多少之类的问题，而本体则负责处理诸如客户究竟是什么之类的问题。

语义层负责处理各项指标。它规定了收入、月活跃用户数及生命周期价值的计算方式，包括应使用哪些公式以及应用哪些筛选条件，从而确保所有团队和工具都能得到一致的结果。

本体层则负责定义含义。它明确了何为客户、客户与订单之间的关联、什么条件能让用户获得白金等级，以及软件是否能够从已存储的事实中推导出新的结论。

本体层：概念、关系与推理

按照教科书上的定义，即对共享概念模型的明确形式化规范，其内容可归纳为三部分：

类：领域中实体的类型，例如客户、产品、订单、地区。
属性与关系：这些实体之间的关联方式。例如客户会下订单，产品则属于某个类别。

公理与规则：逻辑约束。每个订单至少包含一种产品，且客户在任何时刻仅属于一个区域。

本体是以RDF和OWL等W3C标准编写的，这样机器不仅能够读取它们，还能对其进行分析推理。假设本体规定白金级客户的年收入需超过100万，而事实数据表明Acme公司的年收入为200万，那么系统会自动推断Acme属于白金级客户，而无需人工编写任何if-else条件语句。语义层和商业智能工具则无法做到这一点，它们只能执行预先定义好的计算，无法推导出未被定义的新事实。

本体论还能在系统间的词汇表之间建立关联。CRM系统中用“Customer”表示客户，ERP系统中用“Client”表示客户，财务系统中用“Account”表示客户，而本体论会将它们全部映射为同一个业务对象。以这种方式构建的智能体会遵循连通图来工作，而非在相互独立的表之间进行猜测。在医疗领域，SNOMED CT是标准本体；在金融服务领域，FIBO是标准本体；而在受监管的行业里，正式的本体论几乎是强制要求的。

其成本同样显而易见。Palantir已将企业本体论发展为一个市场类别，但实现起来十分困难：需要派驻嵌入式工程师、进行手动建模，完整的构建过程需要6到18个月的时间，而且具备形式逻辑能力的人才十分稀缺。

语义层：一致的标准与数据

这种工作方式更为实用。20世纪90年代，Business Objects推出了Universe，这是一种将业务术语应用于复杂数据结构的方法。根本问题依然存在：收入计算方式各异，数据相互矛盾，导致信任度下降。如今，其影响更为严重，因为过去的数据不一致只会让演示文稿显得尴尬，而现在则可能让报告中出现虚假数据，进而影响决策。

现代语义层由四个部分组成：

元数据存储库，将mrr_calc_v3之类的标识映射到月度经常性收入。
业务逻辑引擎，将指标公式集中存储，以便一次性定义后重复使用。
查询转换功能，用于生成连接和过滤条件。
访问控制机制，统一实施行级和列级的权限管理。

相关工具发展极为迅速。dbt加入了由MetricFlow驱动的语义层，该层将指标定义以YAML格式纳入版本控制，并将其编译为多种SQL格式。2025年9月，Snowflake、Salesforce、dbt Labs和BlackRock共同启动了开放语义交换（OSI）项目，2026年1月发布的1.0版本提供了一种用于交换语义元数据的中立格式。Cube、AtScale、LookML、DAX、Databricks Metric Views以及Snowflake Semantic Views等产品都在朝着同一个方向发展，即语义层正逐渐成为构建适合人工智能的数据架构的常规组件。

不过这也存在局限。该层级能够准确说明收入是如何计算的，但却无法说明客户如何与市场及其规则相连接，也无法判断某个账户是否符合域名规则中设置的高风险标记标准。《Metadata Weekly》的杰西卡·塔利森对此做了精辟的总结：语义层级负责数据查询，而本体论则负责处理上下文与推理逻辑。

仅使用一种层级会带来什么问题

仅依靠语义层级只能得到准确但内容单一的答案。上个月哪个渠道创造了最高的商品交易总额？可以给出精确答复。但为何该数值会下降，或者支出为何应该上升？则无法回答，因为没有模型能够描述渠道、支出与客户画像之间的相互关系。

本体论仅能很好地描述概念，但在处理具体数据时却力不从心。Acme Platinum算吗？逻辑上似乎成立。那Acme上个月带来了什么？又是三种相互矛盾的答案，因为该系统缺乏指向事实表或聚合规则的任何指引。

行业数据也印证了这一点。Gartner预测，由于成本过高、价值不明确以及管控不足，到2027年底将有超过40%的代理型AI项目被废弃。在248位受访的数据管理负责人中，63%承认自己缺乏支持AI发展的相关实践。问题往往不在于模型本身，而在于底层数据缺乏语义基础。

趋势也并非只朝一个方向发展。Gartner在2026年的峰会上预测，到2030年，通用语义层将成为数据平台与网络安全领域的重要基础设施；Futurum则认为其采用率将从今年的16%上升至2031年的30%。微软正在Fabric IQ中预览内置的本体支持功能，而Timbr.ai则销售带有推理功能的语义层。这两种方法正在逐步走向融合。

知识图谱与分类法

知识图谱用于存储各种实例，因此真实的客户和订单会以节点的形式呈现。可以把本体视为架构，而知识图谱则视为数据本身。在运行时根据关系进行操作的智能体，就是在该图谱中移动的。

分类法是一种简化版的本体：由父节点和子节点构成的层级结构，不包含推理功能，也没有横向链接。产品目录、数据领域分类以及个人身份信息标记通常都是从这里开始的，这确实是一个不错的起点。只有当系统需要跨类别进行推理时，比如判断A类别的降级是否会影响B类别的库存，才需要完整的本体。

各组成部分的关联

上下文层分为两大部分：

数据上下文：本体、语义层、知识图谱、数据来源追溯、质量评分以及访问策略。它告诉人工智能该系统所处行业的特点。
应用上下文：用户偏好、对话历史、领域文档以及检索到的事实（记忆机制与RAG技术）。它告诉人工智能正在与谁交流。

一个问题需要经过四个阶段才能得到处理：

本体定义了诸如收入确认之类的概念及其相关规则。
语义层将其转化为可执行的计算逻辑：需要连接哪些表以及如何进行聚合。
知识图谱将概念与其度量指标、来源脉络及下游使用方联系起来。
MCP在推理时为智能体提供所需上下文。

两年来的上下文工程讨论都指向这一点：可靠的输出需要结构化的上下文，而本体与语义层正是其中最难实现的两个部分。MCP解决的是上下文的传递问题，而非内容本身。如果给智能体提供无约束的表结构和SQL语句，该协议就会如实地传递出错误信息。

某供应商的解决方案

某数据库供应商将其解决方案描述为开放式语义堆栈，也称为OSI，它整合了度量标准、定义、原始数据、上下文图以及本体，而非依赖另一层BI语义层。该架构包含三层：

最底层为语义层：包含度量标准定义、计算规则以及维度与数据之间的映射关系。它基于Ant-OSI标准构建，可与行业通用的OSI标准协同工作，目前已应用于蚂蚁集团的实际业务中。
中间层为上下文图：将度量标准、对象、事件、数据关联关系及使用者以网络形式连接起来，大型语言模型基于此结构的推理能力明显优于基于原始架构或YAML格式的推理。
最顶层为本体层：包含与数据库语义相对应的业务语义，同时整合了工作区内的专用术语与企业级通用概念，并能按照各自的规划持续演化。

其背后的原则是代码化的语义定义。只需定义一次语义，BI工具便可据此绘制仪表板，智能体能够编写SQL语句，治理工具也能追踪数据来源，所有操作都基于同一定义，无需为BI、AI和治理分别设定不同的语义标准。在该供应商的客户测试中，自然语言转数据的准确率远超其他方案。他们的观点是，模型本身并不能区分产品，因为大家都将同样的技术称为大语言模型；真正起决定作用的是语义上下文的质量。使用正确的业务定义替代原始数据表，提升自然语言转SQL的准确率的效果，比仅通过提示词调整更为显著。

从何处开始

在以下情况下，应从语义层入手：

团队对“收入”或“活跃用户”的含义存在分歧。
项目属于对话分析或数据聊天类应用。

数据栈已经实现集中化管理，期望在两到六个月内获得反馈结果。

以下情况建议优先构建本体：

企业处于金融、医疗或政府领域，且对合规性有严格要求。
人工智能需要跨不同领域进行推理，例如按客户、产品或法规维度分析。
同一个概念在六种不同的系统中有着不同的名称。
需要实现自动化分类或基于规则的异常检测功能。

对于大多数企业而言，合理的实施顺序为：

首先构建语义层，集中管理核心指标，确保商业智能系统和人工智能使用相同的定义。
初期本体设计应保持简洁，仅作为业务术语表，无需采用完整的OWL标准。
随后添加治理相关要素：数据来源追溯、质量评分、责任归属及认证信息。

通过MCP将所有内容暴露给代理，从而使上下文层从图表转变为基础设施。

dbt不会提供本体，而且类似Palantir的本体并不适合所有团队。从词汇表逐步发展成正式本体比试图一次性实现所有目标更为现实。

该供应商自身的路线图也体现了这种渐进性。短期内，语义层将覆盖所有工作空间，具备集中管理的指标和可搜索的术语。中期，词汇表、类别层次结构以及实体关系会首先以分类法的形式出现，随后实现跨系统对齐与基本推理能力，并逐个领域扩展。长期来看的问题是，那些分别建模语义的领域如何合并，以及如何保持本地和全局定义的不断发展。