我最近有两个特别反感的地方。第一，人们把语义学中一些众所周知的技术，改名为“语境”，然后宣称整个话题是全新的，好像人工智能刚刚创造出来似的。第二，专家们讲解元数据、语义学、分类学、本体论、知识图谱和语境时，一个例子都不举，结果反而让听众更加困惑。

　　在我的职业生涯中，我目睹了所谓的“护城河”在整个技术栈中不断摇摆。早期，存储数据的供应商（关系型数据库供应商）掌握着主导权。后来，护城河转移到了应用层（ERP系统），再到API网关，最终到达了BI工具。最近，基础架构模型公司也开始声称拥有同样的地位。

　　现在，整个技术栈的供应商都围绕着“上下文层”重新定位，声称上下文是重心，将解决概率模型和代理对企业数据缺乏真正了解的缺陷。

　　在这篇文章中，我将用具体的例子来阐释上下文概念背后的原理，这也是我希望更多人能做到的。最后，我会分享自己关于如何构建上下文层的看法。

　　为什么是现在？

　　过去两年发生的四件事使得一个由来已久的争论突然变得迫在眉睫。

　　首先，自主代理出现了。它们代表我们读取文档、编写代码、提交工单和调用API，取代了以往软件仅提供信息的功能。

　　其次，出错的代价也随之增加。如果仪表盘上“收入”的定义模糊不清，首席财务官就会感到恼火。同样定义模糊的代理人可能会基于错误的数字发放退款、发送电子邮件或提交合规报告。

　　第三，技术终于成熟了。LLM（大型语言模型）能够从非结构化文本中提取实体和关系，图数据库已经成熟，OSI、MCP、Delta Share和Iceberg REST 目录等标准正在快速融合。非结构化数据现在可以像结构化数据一样发挥作用了。

　　第四，数据消费者发生了变化。过去，人类每天只进行少量查询，可以通过判断和对话来接受缓慢或不一致的答案。而智能代理发出的查询数量级要多得多，它们既不具备判断力，也不具备沟通能力。

　　当人们从三份不同的报告中得到三个不同的收入数据时，我们会通过对话来调和这些不一致之处，从而容忍这种混乱。但一旦消费者成为代理人，同样的混乱就会演变成运营风险。如果我们现在不解决语义问题，人工智能不仅无法解决我们的一致性问题，反而会加剧这个问题。

　　常见问题解答

　　供应商经常把元数据、语义、分类、本体、知识图谱和上下文等术语混用。买家不知道该问什么，而中间的架构师则不得不负责翻译。但这六个术语并非相互竞争的概念，它们构成了一个技术栈。每一层都负责特定的任务，缺一不可。正是这个技术栈区分了会产生幻觉的人工智能代理和不会产生幻觉的人工智能代理。

　　这篇文章是我在任何关于架构的讨论深入之前都需要向别人提供的常见问题解答。为了使内容更具体，我举了两个例子：我最近购买的MacBook Air，以及一位客服人员正在处理的一个零件缺陷投诉。这两个例子几乎出现在每个答案中。

　　1.元数据、语义、分类、本体、知识图谱和上下文的定义是什么？

　　2. 它们之间有什么关系？

　　3. 语义层物理上位于哪里？

　　4. OSI（开放语义交换）等标准的作用是什么？

　　5. 上下文层是如何构建和持久化的？

　　1. 这些定义是什么？

　　随着这些话题从学术会议上的趣味话题转变为首席数据官（CDO）的优先事项，定义是第一步。抽象的定义容易被遗忘，但举例子能让它们变得具体。

　　(1)元数据

　　元数据是关于数据的数据。例如，MacBook Air 出厂时带有序列号、型号标识符、生产日期、原产国、保修起始日期、订单号和发货时间戳。这些信息都不是笔记本电脑本身，而是对笔记本电脑的描述。

　　在笔记本电脑内部，每个文件都会被赋予元数据：创建日期、修改日期、所有者、权限和 MIME 类型。元数据使资产可查找、可管理且值得信赖。它是其他所有层级赖以生存的基础。

　　元数据进一步分为技术元数据、操作元数据、社交元数据和业务元数据：

• 　　技术元数据就是我们过去所说的数据字典：表格的结构，包括列名、数据类型和长度等。

• 　　操作元数据描述动态数据：新鲜度、上次刷新时间、管道运行持续时间、错误计数、查询延迟。

• 　　社交元数据是用户贡献的隐性知识：管理者的认可、评分、评论以及诸如有多少仪表板使用该表格之类的信号。

• 　　业务元数据描述了资产对组织的意义。名为 cust_addr_st 的列本身没有任何意义，直到它被定义为“这是客户所在的州，美国两位字母邮政编码，取自 ISO 3166-2:US 列表”。

　　这就是我们从元数据过渡到语义的地方。

　　(2)语义

　　语义是指赋予数据的意义。例如，列中的字符串“M5 MacBook Air”只有在经过编码后才能被理解为一台笔记本电脑，它指的是苹果公司的某个特定产品线。语义的作用在于将符号转化为事物：它告诉我们一行代表一个客户，一列代表一个价格，一个值代表一种货币，一个代码代表一个国家。

　　语义涵盖了围绕资产建立意义的一切要素，包括：

• 　　定义：商业术语的精确且共同的含义。“活跃客户”是指在过去 90 天内至少进行过一次交易的客户。“流失客户”不包括已暂停的账户，但包括降级到免费套餐的客户。

• 　　指标和关键绩效指标：数字的计算方式。“月度经常性收入”是指月末有效订阅价值的总和，不包括一次性费用和按比例计算的金额。每个指标要么只有一个标准定义，要么没有标准定义。

• 　　业务规则：政策和计算方法的适用范围。佣金仅适用于超过 10,000 美元的交易。30 天内的退款不计入销售配额。新客户价格仅适用于前 90 天。

• 　　层级结构和分类：概念如何层层递进。产品归类，客户细分，交易分阶段。这就是分类体系的运作方式。

　　语义是商业智能工具、分析师以及日益普及的人工智能代理在利用数据之前必须掌握的关键信息。没有语义，所有用户都只能靠猜测，从而导致结果不一致。

　　(3)分类

　　分类法是一种层级式分类，它将概念组织成父子关系。我的 MacBook Air 就位于任何电商网站都会使用的分类体系中：电子产品 → 电脑 → 笔记本电脑 → 苹果 → MacBook → MacBook Air → 13 英寸 → M5。每一层级都缩小了范围。正是有了分类法，你才能在不列举所有型号的情况下，简单地查询“显示所有笔记本电脑”。

　　企业在各个方面都依赖分类体系。产品归类，客户细分，交易流程分阶段，员工组织架构，行业分类（例如北美行业分类系统 (NAICS) 或全球行业分类系统 (GICS)）等标准，采购支出分类（例如联合国系统分类标准 (UNSPSC)），医疗诊断分类（例如国际疾病分类第十版 (ICD-10)）。每一种分类体系都构成一个父子树，并且都能帮助我们解答汇总问题。

　　同一资产通常同时属于多个分类体系。例如，我的 MacBook Air 就同时属于产品目录分类体系（笔记本电脑类）、支持分类体系（苹果硬件类）、监管分类体系（锂离子电池设备类）和会计分类体系（资本设备类）。大多数企业都有多个分类体系，每个体系都由不同的团队负责管理。

　　分类法无法描述 MacBook Air 运行 macOS 系统、与 iPhone 共享 iCloud 账户，或者与 AirPods 是同一订单购买的。这些都是关联关系，而非分类。一旦你需要描述关联关系，你就已经从分类法跨入了本体论的范畴。

　　(4)本体论

　　本体论是对实体、实体属性以及实体间关系的正式模型。分类法告诉你 MacBook Air是一种笔记本电脑，而本体论则告诉你 MacBook Air配备M5 芯片、预装macOS 系统、由客户拥有、通过订单销售，并且享有保修服务。名词是实体；连接实体的动词是关系。该模型同时编码了实体和关系。

　　本体由三个部分构成：

• 　　实体（正式名称为类）。领域中存在的事物。例如：客户、产品、订单、地址、保修、账户。

• 　　属性。每个实体所具有的特性。客户有姓名和电子邮件地址。产品有 SKU、价格和芯片代数。订单有日期和总金额。

• 　　关系。实体之间的法律联系。客户下订单。订单包含一件或多件产品。产品享有特定期限的保修服务。

　　分类法只提供层级结构。本体论则添加了属性和关系，并使这三者都可被机器读取。

　　本体是用RDFS和OWL等形式化语言编写的，这样软件不仅可以显示本体，还能对其进行推理。大多数领域已经存在行业标准本体：Schema.org为开放网络提供共享词汇表；FIBO为金融领域提供共享词汇表；SNOMED CT为临床医学领域提供共享词汇表；GS1则为全球供应链中的产品标识符提供标准化。

　　本体让机器能够推理意义，但它本身仍然只是一个模型。它定义了可能存在的事物、事物之间的关联以及可以推断出的信息。要回答一个实际的问题，你需要用真实的客户、真实的订单和真实的MacBook Air数据来填充它。填充后的版本就是知识图谱。

　　(5)知识图谱

　　知识图谱是本体与真实数据结合的产物。本体描述“每个客户都有订单，并且居住在某个地址”。知识图谱则描述“Sanjeev Mohan，账号 12345，于 2026 年 5 月 17 日下了订单号为 99887 的订单，购买了一台 MacBook Air（序列号 C02XYZ123），发货地址为 Main Street 123 号，并搭配了一部 iPhone（序列号 F2L456789），符合 AppleCare 服务计划 AP-2026-0517 的资格”。本体是模式，知识图谱则是填充了数据且可查询的该模式实例。

　　关于术语的说明：这种基于本体的视图描述的是一个RDF知识图谱。另一种常见的风格是带标签的属性图，它存储相同的节点、边和属性，但不需要正式的本体。我描述的是基于本体的这种类型，其中图是模型的填充实例。

　　知识图谱由三个结构要素构成：

• 　　节点。实际的实体。我的MacBook Air。我的Apple ID。我下的订单。

• 　　边。它们之间的实际关系。这台 MacBook Air 由这位顾客购买。此订单已发货至此地址。此 AppleCare 服务计划涵盖此序列号。

• 　　属性。节点和边所附加的属性。MacBook Air 节点包含序列号和芯片代数。“购买者”边包含购买日期和购买渠道。

　　其杀手锏功能在于多跳推理。SQL 几乎无法表达“查找所有与 30 天内退回同一型号商品的客户地址相同的客户”这样的需求，而知识图谱则能轻松实现。

　　具体到人工智能领域，GraphRAG 通过知识图谱构建检索流程，使智能体不仅能看到相关文档，还能看到围绕该文档的关联实体网络。这正是背诵型智能体和推理型智能体之间的区别。

　　在上面的例子中，知识图谱捕捉到了交易的所有信息：谁、什么、何时、何地以及如何进行。但它没有捕捉到我为什么选择这台 MacBook Air。这些决定存在于完全不同的信息库中。例如我的网络搜索记录、我之前提交的关于旧笔记本电脑的支持工单，以及我和家人的对话。将所有这些信息整合起来，针对特定时刻和特定用户，这就是我们所说的“上下文”。

　　(6)语境

　　上下文是凌驾于一切之上的情境感知。它连接各种记录系统，使客服人员不仅能够推断发生了什么，还能推断为什么会发生。关于客户交易的上下文可能存在于 Confluence 页面、查询日志、Slack 消息、电子邮件、Web 日志和产品文档中。

　　请注意，其中一些信号是实时信号，而非历史信号。上下文信息并非仅仅由存储的数据构成，它需要实时数据流。IBM于 2026 年斥资110 亿美元收购Confluent，其明确目标是“将实时数据打造为企业人工智能和智能体的引擎”，这正体现了这一点。如果没有上下文层下方的流式基础设施，你始终只能使用昨天的数据。

　　以客户支持为例。一位客户来电咨询MacBook Air键盘故障。客服人员掌握着结构化的记录：购买历史、保修状态、之前的工单。这部分比较容易处理，占比仅为10%。真正决定结果的上下文信息存在于数据库之外：

• 　　零件文档PDF文件，描述了特定生产批次中已知的缺陷模式。

• 　　网络服务器日志显示，该客户本周访问故障排除页面七次。

• 　　顾客在推特上公开批评了该品牌。

• 　　支持搜索栏的查询日志显示，他们在两天内输入了三次“退货政策”。

• 　　上周，一位现场工程师诊断出另一位客户的机器存在同样的缺陷，以下是与该工程师的电子邮件往来记录。

　　这些信息并非集中存在于某个地方，而且只有经过整合才能发挥作用。上下文正是将这些信号整合在一起的运行时行为。如果没有上下文层，智能体拥有数据，却无法做出判断。有了上下文层，智能体每次都能将意义、历史、意图和策略整合在一起进行推理。如果语义层提供词汇，知识图谱提供事实，那么上下文层则提供当下情境。

　　如果你听信硅谷风投的说法，上下文或许会成为下一个万亿美元的商机。但批评者认为，它不过是一个由来已久的知识工程难题，本体论专家们一直在努力解决。就目前而言，它看起来像是一个理论概念，之前的尝试屡屡失败。不过是旧瓶装新酒罢了。

　　2. 它们之间有什么关系？

　　它们是堆叠结构中的层级，而非竞争关系。定义部分按照含义递增的顺序逐一讲解；而堆叠结构则按照相互依赖关系排列。

图 1：人工智能与自信满满的错误答案之间的屏障。

　　从下往上：

• 　　底层是物理数据：数据仓库、湖屋、操作数据库、文档库、消息队列、日志文件。元数据位于这一层之上，用于描述每一项资产。

• 　　上一层是本体，即意义的形式化模型。它定义了什么是顾客，产品有哪些属性，以及它们之间有哪些合法关系。分类体系存在于本体内部，是分类方案的层级骨架。

• 　　知识图谱使用真实的实体和关系来实例化本体。它是模型的填充版本，可以进行查询：是企业的持久上下文。

• 　　语义层位于所有这些之上，作为受监管的业务契约。它是语义的部署：指标、KPI、业务规则和计算逻辑。它提供的API会显示“本季度活跃客户数 = 12,847，以下是具体的统计方法”。它基于相同的定义为BI工具、分析师和AI代理提供服务。

• 　　最上面一层是上下文层：运行时程序集从下面的每一层提取正确的切片，加上用户身份、会话状态、最近的操作和适用的策略，并在做出决定时将其交给人类用户或自主代理。

　　将我的 MacBook Air 逐层分析，就能明白每一层的重要性。元数据层提供序列号和保修到期日。本体层定义了什么是笔记本电脑，以及它包含电池、芯片和保修。知识图谱层记录了我的笔记本电脑序列号为 C02XYZ123 并已关联到我的 Apple ID 等信息。语义层解释了“符合免费更换电池条件”的计算方式：保修有效且电池循环次数超过 1000 次且之前未更换过电池。上下文层在我发起支持聊天时，会将所有这些信息，包括我最近的搜索记录和技术人员的角色信息整合起来，并打包发送给回复我的客服人员。

　　跳过任何一层，系统都会不出所料地崩溃。没有元数据，就找不到任何信息。没有本体，每个人对“客户”的定义都不一样。没有知识图谱，你可以回答“卖了什么”，但回答不了“哪些东西和哪些东西关联”。没有语义层，每个仪表盘都会互相干扰。没有上下文层，代理拥有数据，却没有判断力。

　　下图显示了嵌入了我的 MacBook 示例的堆栈。

图 2：一台笔记本电脑从序列号到实际提供帮助的代理的整个流程。

　　3. 语义层物理上位于哪里？

　　理论就到此为止。实践者面临的最大问题是如何以经济高效的方式实现这些概念。这些层应该具有持久性，以便人类和智能体可以互换使用。元数据已经持久化到数据目录中，通常被称为业务术语表。然而，随着我们向上层架构的构建，持久化问题变得更加复杂，这主要受可用性、可移植性和一致治理的需求驱动。例如，无论数据以何种方式和原因被使用，随着使用规模的扩大，性能损失都应该降到最低。

　　这要求很高。我们既想鱼与熊掌兼得。其中一些要求需要权衡取舍。错误的决策会导致这些理念与数据脱节，最终导致投资失败。

　　本节我们将探讨语义层持久化。我们看到每个供应商都声称自己是最 佳存储位置。然而，实际上，存储这些概念的位置各有利弊。答案不出所料，取决于具体情况。这取决于最终用户群的规模、数据变化的频率和数量，以及谁最了解数据，从而最有能力保持这些概念的更新。

　　在我们探讨上下文层将位于何处之前，首先需要承认我们尚未解决一个更简单的问题：语义层目前位于何处？答案是，无处不在，又无处可寻：

• 　　商业智能 (BI) 工具：语义的概念最早由Business Objects公司在 20 世纪 90 年代初提出。自那时起，几乎所有 BI 工具都声称自己是存储语义的最 佳平台。Looker在这方面做出了巨大努力，但微软的Power BI才是真正的标杆，它声称拥有超过 2000 万个语义模型。BI 工具市场依然活跃：一款相对较新的 BI 工具Omni最近以 15 亿美元的估值融资 1.2 亿美元。优点：对于真正了解数据及其使用模式的用户来说，操作最为直观。缺点：BI 工具可能存在用户锁定问题，并且可能与不支持 BI 的 AI 代理不兼容。

• 　　独立层：无论语义层存在于何处，它始终会造成某种程度的锁定。因此，像AtScale和Cube.dev这样的独立语义层供应商提供了一种独立的服务，供所有用户调用。优点：提供了一个独立的语义层，确保所有 BI 和 AI 用户的数据一致性。缺点：增加了数据工具的数量，并带来了一些运维开销。

• 　　数据治理工具： Collibra、Informatica、Atlan、Alation以及ServiceNow（收购data.world后）等数据目录一直是存储元数据、展示数据沿袭和应用访问策略的核心。它们声称能够存储语义，如今又能够存储上下文，这是一种自然而然的发展，正如Databricks的 Unity Catalog Metrics 等新产品所展现的那样。数据治理工具还包括Profisee和Reltio（已被SAP收购）等主数据管理 (MDM) 供应商，因为 MDM 的设计初衷就是通过黄金记录的概念来提供语义一致性。优点：语义与数据沿袭、策略和黄金记录并列，而数据管理员已经在这些方面开展工作。缺点：目录通常侧重于描述而非执行，因此定义可能与查询的实际运行方式存在偏差。

• 　　数据集成供应商：组织内部的大部分业务逻辑都位于数据集成层，因此像dbt （已被Fivetran收购）这样的供应商 声称自己是存储语义数据的理想场所。事实上，dbt 已根据 Apache 2.0 开源了 MetricFlow，并使用 Git 来存储指标。优点：非常适合数据沿袭分析。缺点：对业务用户来说不够直观。

• 　　数据存储供应商：Snowflake和BigQuery都引入了语义层，该语义层最接近数据表，并且无论使用者类型如何，都会强制执行。例如，AI 代理可以使用 MCP 等协议来访问语义层。优点：强大的集中式治理。缺点：本质上是特定于某个供应商的。

• 　　人工智能代理：代理通过提示上下文和工具描述来学习语义理解。这是目前人工智能厂商竞相研发的领域。优点：持续学习。缺点：应用范围有限，且该领域尚不成熟。

• 　　企业平台供应商： Palantir 的 Foundry 方案提供了最全面的集成，其本体嵌入平台内部，并由其前线部署工程师维护。优点：AI 代理可以原生运行在受管控的、可操作的本体之上。缺点：本体实际上是租用的，而非拥有的。治理工作由供应商负责，而非您。

　　这些层级分别由不同的角色使用，例如数据工程师、数据分析师、数据管理员和业务用户。仅由一个角色创建语义是有限的，因为他们的优先级和业务知识各不相同，这可能导致语义过时。语义需要经过测试和版本控制，以避免与底层数据发生偏差。幸运的是，由于开放标准的出现，语义层与底层数据的这种泾渭分明的界限正逐渐模糊。

　　4. OSI 等标准的作用是什么？

　　企业数据领域一个不为人知的秘密是：每种工具都对“真相”有着各自不同的解读。商业智能工具有自己的指标库，数据目录有自己的术语表。转换工具中的语义层对“月度经常性收入”的定义可能与人工智能代理提示模板中的语义层定义不同。六种工具，六种MRR定义，一致性荡然无存。

　　标准打破了这种恶性循环。

　　开放语义交换 (OSI) 是此技术栈最相关的标准。OSI 的目标是以标准且可移植的格式定义指标一次，使其在任何地方都能被识别，无需手动重新映射。如果您的“活跃客户”定义符合 OSI 标准，那么您的Tableau仪表板、Snowflake语义视图、LangChain代理和 GraphRAG 查询都将读取相同的定义。该定义具有可移植性。截至 2026 年 5 月，已有超过 30 家公司注册支持 OSI，其中包括Salesforce和Databricks。

　　OSI 引入了更高层次的可移植性。例如，Snowflake 语义视图中定义的语义与Hex、ThoughtSpot和Omni等 BI 工具具有双向读写功能。这使得不同的用户可以选择由谁来创建和维护语义，并确保语义在技术栈的不同层级之间保持同步。

　　OSI 是更广泛模式的一部分。增量共享 (Delta Sharing) 正在成为跨组织数据共享的开放标准。Iceberg REST 目录正在逐渐成为表元数据的标准。模型上下文协议 (MCP) 最初由 Anthropic 公司提出，并于 2025 年底捐赠给 Linux 基金会旗下的 Agentic AI 基金会，如今已成为将 AI 代理连接到工具、数据和应用程序的事实标准。

　　本体论由一系列 W3C 标准构建而成。RDFS 提供基本的类和属性模型。OWL 提供推理结构，使软件能够推断新的事实。SKOS 负责分类法和术语表的词汇控制。PROV-O 对事实的来源（即其沿袭）进行建模。在此基础上，构建了之前介绍的领域本体论，例如 Schema.org、FIBO、SNOMED CT 和 GS1，它们都是符合 W3C 标准的词汇表，可供整个行业共享。

　　正是因为有了标准，美国邮政编码中的“加利福尼亚州”才用“CA”表示，而不是“加拿大”。令人遗憾的是，ISO 3166 标准中“CA”指的却是加拿大，而这正是标准存在的意义所在——为了规范这种歧义。

　　对于智能体人工智能而言，标准至关重要，不容商榷。一个需要调用五种工具并遍历三个数据源的智能体，不可能学习五种专有语义方案。OSI、MCP 和开放表格格式是智能体的通用语言。

　　5. 上下文层是如何构建和持久化的？

　　我们已经花了相当多的时间来解释语义的各个方面。现在，是时候了解当今的上下文层是如何构建和存储的了。语义和上下文术语这两个术语经常被混用。希望这篇文章已经阐明，上下文层比语义层要大得多。也许这正是问题所在。当范围过于庞大时，实现起来就变得困难了。

　　前沿模型将上下文视为短暂的，仅在运行时为单个代理回合构建并丢弃。然而，跨会话持久化上下文可以让系统直接回答常见查询，从而减少昂贵的 LLM 往返次数和令牌成本。

　　在《设计人工智能驱动的数据基础》一书中，引入了“提取、上下文、链接”（ECL）模式来构建上下文层：

• 　　提取：上下文信息分散在各个地方，存在于结构化数据库、PDF、电子邮件、聊天记录、支持工单、产品评论和网页日志中。因此，首要需求是能够访问所有这些数据源。现有的集成模式（ETL、ELT、联合）是为人工通过 SQL 查询结构化表格数据而设计的，并非为这种混乱的多格式环境而设计。ECL 可以连接到所有数据源，无需您先将数据复制到一个数据仓库，即可从每个数据源中提取实体及其元数据。

• 　　上下文：找到数据源并不等同于理解它。一旦识别出实体，大型语言模型（LLM）就会推断它们的语义：每个实体是什么，它在您的业务中意味着什么，以及它与其他实体之间的关系。正是在这里，90% 的企业非结构化数据最终变得可用。零件文档 PDF 不再是一堆文本，而是变成了“产品 Z 上的缺陷模式 X，影响批次 Y”。这些上下文理解以本体的形式存储在目录中。

• 　　链接：最后一步通过知识图谱将提取出的上下文信息整合到企业内存中。它在遵守安全策略和业务流程的前提下，将数据库、文档和通信系统中的实体和上下文信息连接起来。其优势在于，代理可以通过 API 或 MCP 查询单一端点，而无需手动集成十几个系统。

　　这就是向上下文架构转变背后的微妙变化。传统的 RAG 架构在模型运行前将数据推送给代理，预先猜测其所需内容。上下文层则完全颠覆了这一模式：代理在运行时通过一个受控的端点获取其所需的确切数据。数据检索过程并未消失，而是得到了有效管理。

　　让我们回到之前提到的MacBook Air故障电话。提取功能会访问订单数据库、零件PDF、网络日志、客户的推文以及支持搜索日志。上下文功能会从每条信息中提取出具体含义：客户、序列号、故障模式、情绪和意图。链接功能会将这些信息整合到一个图中，这样客服人员看到的就是一个完整的故事，而不是几个互不关联的片段。这个可查询的链接视图就是上下文层。

　　一个值得注意的细微差别。当数据集在组织内部生成时，您可以通过数据契约预先定义其上下文，该契约声明了模式、字段语义和质量阈值。但当数据来自组织外部时，例如第三方数据源、合作伙伴数据或缺乏所有者的、管理不善的内部数据源，则无法预先定义上下文，而必须进行推断。ECL 正是自动化这一推断过程。

　　结束

　　在缺乏治理的元数据和不一致的语义之上构建上下文层，只会加速出错。在本文中，我们探讨了元数据、语义、分类法、本体、知识图谱和上下文的概念，但尚未涉及企业最关心的议题，例如安全性、治理、规模和成本。正如语义层几乎可以存在于技术栈的任何位置一样，上下文层最终也可能分布在多个层级，而不是集中在一个地方。