Why AI Needs Enterprise Context More Than a Full Ontology为什么 AI 更需要企业上下文，而非完整的本体论
That accumulated knowledge built through training, mistakes, and tribal knowledge passed down in Slack threads is Enterprise Context.通过培训、错误总结以及在 Slack 讨论串中传承的部落知识所积累的认知，就是“企业上下文”。
Without it, AI agents are just new hires: technically capable, but unable to give answers the business can actually trust.没有它，AI 智能体就如同新入职的员工：虽然具备技术能力，却无法给出企业真正信任的答案。
Enterprise Context has five components:企业上下文由五个部分组成：
Business Semantics: the governed definitions behind every metric, entity, and term. What is “Revenue”? What counts as an “Active Customer”? What’s the difference between “Bookings” and “Billings”?业务语义：每个指标、实体和术语背后的治理定义。什么是“收入”？什么算作“活跃客户”？“预订额”与“开票额”之间有什么区别？
This layer is rarely written down in one place. It’s buried inside reporting tool semantic layers, hardcoded into pipeline business logic, or living exclusively in the heads of domain experts.这一层信息很少被统一记录。它们往往隐藏在报表工具的语义层中、硬编码在流水线的业务逻辑里，或者仅存在于领域专家的脑海中。
Three things matter before you try to formalize it: it is not static, definitions evolve as the business changes; it has an owner, someone needs to be accountable for keeping it current; and it needs a home, a governed layer that agents can query reliably, not a spreadsheet that goes stale.在试图将其形式化之前，有三点至关重要：它不是静态的，定义会随业务变化而演进；它必须有所有者，需要有人负责保持其更新；它需要一个归宿，即一个供智能体可靠查询的治理层，而不是一份容易过时的电子表格。
Operational & Structural Context: How your data is actually used in practice. Which tables are reliable? What query patterns have been validated by real analysts? Which column names are misleading or ambiguous? What do your last 10,000 successful queries have in common?运营与结构上下文：数据在实践中是如何被实际使用的。哪些表是可靠的？哪些查询模式经过了资深分析师的验证？哪些列名具有误导性或歧义？过去 1 万次成功的查询有哪些共同点？
This is the institutional knowledge that lives in senior analysts’ heads and nowhere else. The same questions apply: it changes over time, it needs an owner, and it needs to be captured somewhere accessible, not rediscovered every time a new team member joins or a new agent is deployed.这是仅存在于资深分析师头脑中的机构知识。同样的问题也适用：它会随时间变化，需要所有者，并且需要被记录在可访问的地方，而不是每次有新成员加入或部署新智能体时都要重新发现。
Relationships & Hierarchies: How things connect across your business. Supplier → Component → Product → Order → Customer. Not just the schema of individual tables, but the understanding of how your business actually works — which entities are the same thing under different names in different domains, and how deeply things nest.关系与层级：业务各要素之间的连接方式。供应商 → 组件 → 产品 → 订单 → 客户。这不仅是单个表的模式，更是对业务实际运作方式的理解——哪些实体在不同领域中名称不同但指代同一事物，以及事物之间的嵌套深度。
Governance & Trust: What the AI is allowed to access and what it should be confident in. Which data is certified? Which columns contain PII? What are the access policies?治理与信任：AI 被允许访问哪些数据，以及它应该信任哪些数据。哪些数据是经过认证的？哪些列包含个人隐私信息 (PII)？访问策略是什么？
An agent that can query everything but has no sense of data quality or access boundaries is a liability, not an asset.一个可以查询所有内容但对数据质量或访问边界毫无概念的智能体是企业负担，而非资产。
Unstructured Context: The knowledge that doesn’t live in tables at all. Business rules in policy documents. Domain knowledge in wikis. Historical reasoning captured in analyst notes and examples. This is often the hardest to formalize, but it’s frequently the difference between an agent that sounds right and one that actually is.非结构化上下文：那些根本不存在于表格中的知识。例如政策文档中的业务规则、维基中的领域知识、分析师笔记和案例中捕捉的历史推理。这部分通常最难形式化，但它往往是决定智能体表现是“看起来正确”还是“真正正确”的关键。
Here’s a simple map of how these components fit together:以下是这些组件如何组合的简单示意图：
Enterprise Context
├── Business Semantics (metrics, vocabulary, business rules)
├── Operational Context (trusted tables, query patterns, metadata)
├── Relationships & Hierarchies (entity graph, joins, hierarchies)
├── Governance & Trust (policies, data quality, access controls)
└── Unstructured Context (documentation, examples, domain knowledge)Understanding the relationship between Enterprise Context and Ontology matters before you start building.在开始构建之前，理解企业上下文与本体论之间的关系非常重要。
Ontology, a governed vocabulary of terms, metrics, and definitions, plus the typed relationships and asset mappings that connect them is one mechanism for delivering Enterprise Context. Specifically, it covers Business Semantics and Relationships & Hierarchies. A well-built Ontology grounded in Semantic Views handles the majority of what AI agents actually need.本体论（一种包含术语、指标和定义的治理词汇表，以及连接它们的类型化关系和资产映射）是交付企业上下文的一种机制。具体来说，它涵盖了业务语义以及关系与层级。一个基于语义视图构建的扎实本体论，能够处理 AI 智能体实际所需的大部分内容。
A Knowledge Graph is the deepest layer of an Ontology: the populated traversal network for multi-hop chains and recursive hierarchies. It is not synonymous with “Ontology.” Most teams never need it.知识图谱是本体论的最深层：用于多跳链和递归层级的填充式遍历网络。它并不等同于“本体论”。大多数团队根本不需要它。
Most AI failures trace back to missing Business Semantics; the agent doesn’t know what the metric means or how to filter it correctly. Most hallucinations on cross-domain questions trace back to missing relationships; the agent can’t navigate the connections between things.大多数 AI 故障都可以追溯到业务语义缺失；智能体不知道指标的含义或如何正确过滤它。大多数跨领域问题的幻觉都可以追溯到关系缺失；智能体无法导航事物之间的连接。
Here’s what typically happens: a team hits a few wrong answers, someone says “we need a full ontology,” and suddenly there’s a six-month Knowledge Graph project on the roadmap before anyone has defined what “Revenue” means.通常发生的情况是：团队遇到几次错误答案，有人说“我们需要一个完整的本体论”，于是路线图上突然出现了一个为期六个月的知识图谱项目，而此时甚至没人定义过“收入”是什么。
That’s the wrong order, and usually the wrong destination entirely.这种顺序是错误的，而且通常目标本身也是错的。
The goal is Enterprise Context. An Ontology backed by Semantic Views and a governed Business Glossary delivers that for the vast majority of use cases. A Knowledge Graph is needed only when the specific traversal scenarios in the next section apply and they’re less common than the knowledge graph industry would have you believe.目标是企业上下文。由语义视图和治理业务术语表支持的本体论可以满足绝大多数用例。只有在下一节提到的特定遍历场景适用时才需要知识图谱，而这种情况远没有知识图谱行业所宣称的那样普遍。
The rest of this post walks through how to build that context incrementally starting with the layer that solves the most problems, and only going deeper when the use case actually demands it.本文余下部分将介绍如何逐步构建这种上下文，从解决最多问题的层级开始，仅在用例确实需要时才深入挖掘。
Start Here: The Most Common Issues and Their Simple Fixes从这里开始：最常见的问题及其简单修复方案
Before you consider building a full ontology solution with Knowledge graph, check whether one of these simpler patterns solves your problem. Most do.在考虑使用知识图谱构建完整的本体论解决方案之前，请检查这些更简单的模式是否能解决你的问题。大多数情况下是可以的。
Issue 1: The AI gives different answers to the same question问题 1：AI 对同一个问题给出不同的答案
Root cause: No single authoritative definition. Different tables, different filters, different fiscal calendars the agent picks one and gets it wrong.根本原因：缺乏单一权威定义。不同的表、不同的过滤器、不同的财年日历，智能体随机选择一个导致出错。
Simple fix: Semantic View + Verified Queries简单修复：语义视图 + 验证过的查询
Snowflake’s Semantic Views let you define metrics, dimensions, entities, and relationships in a governed layer that agents query through, not around. When an agent asks for ACV, it uses the governed definition. Not the raw table. Not a guessed join.Snowflake 的语义视图允许你在治理层中定义指标、维度、实体和关系，智能体只能通过该层进行查询，而不能绕过它。当智能体询问 ACV（年度合同价值）时，它会使用治理后的定义，而不是原始表或猜测的连接。
Add Verified Query Repository (VQRs) for your most critical questions; these are pre-validated queries the agent can use to answer similar questions, improving accuracy for high-stakes queries为最关键的问题添加验证过的查询库 (VQR)；这些是预先验证过的查询，智能体可以用它们来回答类似问题，从而提高高风险查询的准确性。
When this is enough: Single domain, clear metric ownership, one team maintaining definitions. Integrate Semantic Views into your CI/CD pipeline and treat them as code versioned, tested, and owned by the domain team, not maintained manually.适用场景：单一领域、清晰的指标所有权、由一个团队维护定义。将语义视图集成到 CI/CD 流水线中，并将它们视为代码进行版本控制、测试，由领域团队负责，而非手动维护。
Issue 2: Finance and Sales argue about what Revenue means — the AI picks a side and both teams are unhappy问题 2：财务部和销售部对“收入”的定义争执不下 —— AI 站队导致双方都不满意
Root cause: Cross-domain vocabulary conflict. Different teams have legitimately different definitions that are each correct in their own context.根本原因：跨领域词汇冲突。不同团队在各自的上下文中都有合理的定义。
Simple fix: Multiple domain-scoped Semantic Views + Agent orchestration instructions简单修复：多领域范围的语义视图 + 智能体编排指令
Don’t fight the vocabulary. Own it. Create a Semantic View per domain where each team’s definition is authoritative within their view. Then give your agent routing instructions when the question comes from a Finance context, route to the Finance view; Sales context routes to the Sales view.不要试图统一词汇，而是接受差异。为每个领域创建一个语义视图，每个团队的定义在其视图内均为权威。然后为智能体提供路由指令：当问题来自财务上下文时，路由到财务视图；来自销售上下文时，路由到销售视图。
When this is enough: When vocabulary conflicts are domain-scoped and both definitions are valid. You don’t need a single unified enterprise definition, you need clearly owned definitions with smart routing. This is a governance problem, not a graph problem.适用场景：当词汇冲突仅限于领域内部，且两种定义都有效时。你不需要一个单一的统一企业定义，你需要的是定义清晰且所有权明确，并配合智能路由。这是一个治理问题，而非图谱问题。
Issue 3: The agent answers simple questions well but fails when questions span multiple domains问题 3：智能体能很好地回答简单问题，但在跨领域问题上表现不佳
Root cause: Semantic Views are scoped to one domain by design. An agent reasoning across Sales, Finance, and Supply Chain has no reliable way to know how entities connect across those boundaries so it guesses the join, and gets it wrong.根本原因：语义视图设计上仅限于单个领域。智能体在跨销售、财务和供应链进行推理时，无法可靠地知道实体如何跨边界连接，因此它会猜测连接方式，从而出错。
Simple fix: Glossary + Cross-domain join skill + orchestration instructions + multiple Semantic Views简单修复：术语表 + 跨领域连接技能 + 编排指令 + 多个语义视图
Define a deterministic cross-domain join skill, a tool the agent can call that returns the correct join keys between domains. This removes the join decision from the agent’s reasoning entirely. Pair it with orchestration instructions that specify which Semantic View owns which entities, and add verified query examples that demonstrate correct cross-domain patterns.定义一种确定性的跨领域连接技能，即智能体可以调用的工具，该工具返回领域间正确的连接键。这完全消除了智能体推理中的连接决策。将其与指定哪些语义视图拥有哪些实体的编排指令配合使用，并添加演示正确跨领域模式的验证查询示例。
When this is enough: Most of the time, joins between domains already exist from your data modeling work. The agent doesn’t need to reason about them, it just needs to be told what they are. This pattern handles the majority of cross-domain failures without any graph infrastructure.适用场景：大多数情况下，领域间的连接在数据建模工作中已经存在。智能体不需要推理它们，只需要被告知它们是什么。这种模式可以在没有任何图谱基础设施的情况下处理大多数跨领域故障。
The pattern across all three fixes: The problem is almost never the agent. It’s the absence of a layer that tells the agent what things mean, which definitions to trust, and how entities connect. Semantic Views, verified queries, and explicit routing instructions provide that layer incrementally, without a multi-month ontology project.这三种修复方案的共同点是：问题几乎从来不在智能体本身。问题在于缺乏一个告诉智能体事物含义、信任哪些定义以及实体如何连接的层级。语义视图、验证过的查询和明确的路由指令可以逐步提供这一层级，而无需耗时数月的本体论项目。
If these three patterns don’t solve your problem, the next section explains when a deeper solution is actually warranted.如果这三种模式无法解决你的问题，下一节将解释何时才真正需要更深层的解决方案。
So When Do You Actually Need a Full Ontology Solution with Knowledge Graph?那么，你究竟何时需要带有知识图谱的完整本体论解决方案？
After applying the simple fixes above, you’re left with few scenarios that require a deeper layer.在应用了上述简单修复方案后，仍有少数场景需要更深层的解决方案。
Scenario 1: Multi-hop Chain Reasoning场景 1：多跳链式推理
Your users need to follow chains of relationships of unknown depth to answer a question.你的用户需要跟踪未知深度的关系链来回答问题。
Which Tier-2 supplier delay caused which sub-assembly shortage caused which production line stoppage caused which customer delivery failure?哪个二级供应商的延迟导致了哪个子组件短缺，进而导致了哪个生产线停工，最终导致了哪个客户交付失败？
Which correspondent bank transfer passed through a sanctioned intermediary two hops removed from our direct transaction?哪笔代理行转账经过了与我们直接交易相隔两跳的受制裁中介机构？
Semantic Views model known, fixed joins. They cannot traverse a chain where the depth varies at runtime — where the answer requires following a path and neither the agent nor the analyst knows in advance how many steps that path will take.语义视图建模的是已知、固定的连接。它们无法遍历深度在运行时变化的链条——即当答案需要遵循一条路径，且智能体和分析师都无法预先知道该路径需要多少步时。
This requires a graph representation: nodes, edges, and traversal logic that can follow relationships dynamically regardless of depth.这需要图谱表示：节点、边以及能够动态跟踪关系（无论深度如何）的遍历逻辑。
The signal: If someone has to say “…and then trace that through to whatever it connects to” that’s a Knowledge Graph use case.信号：如果有人必须说“……然后追踪它到它连接的任何地方”，这就是知识图谱的用例。
Scenario 2: Deep Recursive Hierarchies场景 2：深度递归层级
Your data has parent-child structures where the depth is variable, unknown, or business-critical.你的数据具有父子结构，且深度是可变的、未知的或对业务至关重要的。
If this component is unavailable, which of our 400 finished products are affected across all levels of our Bill of Materials?如果该组件不可用，在物料清单的所有层级中，我们 400 种成品中有哪些会受到影响？
What is the ultimate beneficial owner of this corporate entity, accounting for all intermediate holding companies?考虑到所有中间控股公司，该企业实体的最终受益所有人是谁？
Semantic Views support dimension hierarchies. They do not support recursive traversal to N levels where N is determined at query time. This requires either a recursive SQL pattern or a graph layer and typically an ontology layer to govern the inference rules that apply at each level of the hierarchy.语义视图支持维度层级。它们不支持到 N 层的递归遍历（N 在查询时确定）。这需要递归 SQL 模式或图谱层，通常还需要本体论层来治理适用于层级每一级的推理规则。
The signal: If the number of levels in your hierarchy is unknown, variable, or something your users need to reason about — that’s a KG/ontology use case.信号：如果层级中的层数未知、可变，或者用户需要对其进行推理，这就是知识图谱/本体论的用例。
Everything else is not a Knowledge Graph problem.其他所有情况都不是知识图谱问题。
Get Vikas Malik’s stories in your inbox在收件箱中获取 Vikas Malik 的文章
Join Medium for free to get updates from this writer.免费加入 Medium 以获取该作者的更新。
Vocabulary conflicts are a Business Glossary problem. Wrong metric definitions are a Semantic View problem. Poor cross-domain joins are an orchestration problem. Applying a Knowledge词汇冲突是业务术语表问题。错误的指标定义是语义视图问题。糟糕的跨领域连接是编排问题。将知识图谱应用于这些问题中的任何一个，都是用错误的工具做正确的事，不仅构建昂贵、维护困难，而且在解决实际问题上并不比一个编写良好的语义视图更好。
Graph to any of these is the right tool for the wrong job, expensive to build, expensive to maintain, and no better at solving the actual problem than a well-authored Semantic View.（接上文）
If your use case doesn’t clearly match one of the two scenarios above, go back to the simple fixes. You’ll ship faster, maintain it more easily, and get to the same answer.如果你的用例与上述两个场景不明显匹配，请回到简单的修复方案。你会交付得更快、维护得更轻松，并得到同样的答案。
The Right Foundation: How to Build Incrementally正确的基石：如何渐进式构建
Here’s the architectural progression. Build only to the level your use case requires. Stop when you’ve solved the problem.以下是架构演进路径。仅构建到你的用例所需的层级。一旦解决了问题就停止。
Level 0: Clean Data Model0 级：干净的数据模型
No AI is reliable on undefined data. Before any semantic layer, ensure:没有 AI 能在未定义的数据上保持可靠。在任何语义层之前，请确保：
- Core entities are in clearly named tables with a defined domain boundary核心实体位于命名清晰且具有明确领域边界的表中
- Primary and foreign keys are reliable主键和外键是可靠的
- Null rates on key columns are understood关键列的空值率是已知的
- A clear medallion or domain boundary exists存在清晰的奖章架构（Medallion Architecture）或领域边界
If this doesn’t exist yet, start here. An ontology built on undefined data is technical debt, not value.如果这些尚不存在，请从这里开始。建立在未定义数据上的本体论是技术债，而非价值。
Level 1: Metadata1 级：元数据
Add table and column descriptions. Define owners. Apply tags to tables and columns that carry sensitivity, domain, or quality signals.添加表和列描述。定义所有者。为带有敏感性、领域或质量信号的表和列应用标签。
This is unglamorous work, but it is the foundation every higher layer depends on. An agent that can read column descriptions makes far fewer wrong assumptions than one reading raw schema names.这是枯燥的工作，但它是每一层更高层级赖以生存的基础。一个能读取列描述的智能体，比阅读原始模式名称的智能体所做的错误假设要少得多。
AI-assisted classification tools make it significantly faster to apply descriptions and tags at creation time rather than backfilling later.AI 辅助分类工具使在创建时应用描述和标签比事后补全要快得多。
Level 2: Semantic Views — The Foundation2 级：语义视图 —— 基石
Start by formalizing what already exists into Semantic Views. Define your most-queried metrics with clear filter logic, make joins explicit, and add Verified Query Repository for your highest-stakes questions.首先将现有内容形式化为语义视图。用清晰的过滤逻辑定义最常查询的指标，明确连接方式，并为最关键的问题添加验证过的查询库。
- Define your most-queried metrics formally with clear filter logic用清晰的过滤逻辑正式定义最常查询的指标
- Define entity relationships explicitly don’t leave joins to inference明确定义实体关系，不要将连接留给推理
- Add Verified Query Repository (VQRs) for your highest-stakes questions为最关键的问题添加验证过的查询库 (VQR)
- As a general guidance, aim to keep each Semantic View to 50–100 columns to reduce noise for the LLM一般建议：将每个语义视图保持在 50–100 列，以减少对大语言模型 (LLM) 的干扰
Target 2–4 Semantic Views covering your top domains. Integrate them into your CI/CD pipeline. Domain owners should own these as code versioned, tested, and updated as definitions evolve. Scalability through discipline matters more than adding complexity.目标是覆盖核心领域的 2–4 个语义视图。将它们集成到 CI/CD 流水线中。领域所有者应将其视为代码进行管理，随着定义的演进进行版本控制、测试和更新。通过纪律实现的可扩展性比增加复杂性更重要。
Best when: you already have a semantic or BI layer (dbt metrics, Looker LookML, an existing data model) and want to govern what you have.适用场景：你已经拥有语义层或 BI 层（如 dbt metrics、Looker LookML、现有数据模型），并希望治理现有内容。
This path solves 60–80% of Enterprise Context problems without needing a Business Glossary first. The Glossary becomes the natural next step when vocabulary conflicts surface across domains.这条路径可以在无需先建立业务术语表的情况下解决 60–80% 的企业上下文问题。当跨领域出现词汇冲突时，术语表便成为自然的下一步。
Level 3: Business Glossary — Governed Entity Relationships3 级：业务术语表 —— 治理后的实体关系
For cross-domain vocabulary governance and formal entity modeling.用于跨领域词汇治理和形式化实体建模。
Start by defining what things mean in governed, human-verified terms: what counts as Revenue, what Active Customer means, how your fiscal calendar works. Capture terms, metrics, formulas, synonyms, and exclusions. Link concepts to data assets.首先用治理过的、经人工验证的术语定义事物的含义：什么是收入，活跃客户的定义，财年如何运作。捕获术语、指标、公式、同义词和排除项。将概念链接到数据资产。
Start with the 5–10 terms that cause the most disagreement. A narrow, well-maintained Glossary is more valuable than a comprehensive one no one keeps current. Define the governance owner before you define the schema从最易产生分歧的 5–10 个术语开始。一个狭窄但维护良好的术语表，比一个无人更新的全面术语表更有价值。在定义模式之前，先定义治理所有者。
The critical question before building this layer is not what to define, it’s how it will be maintained.在构建此层级之前，关键问题不是定义什么，而是如何维护它。
A Business Glossary that isn’t part of an active governance process becomes stale within months and actively misleads the agents that depend on it.一个不属于主动治理流程的业务术语表会在几个月内过时，并主动误导依赖它的智能体。
Best when: you’re starting greenfield with no existing semantic layer, or when business definitions are the primary source of confusion before any implementation exists.适用场景：在没有现有语义层的情况下从零开始，或者在任何实施方案存在之前，业务定义就是困惑的主要来源。
Level 4: Custom Knowledge Graph — For Genuine Graph Use Cases4 级：自定义知识图谱 —— 针对真正的图谱用例
Only when Levels 1–3 don’t solve the problem.仅在 1–3 级无法解决问题时使用。
If your use case requires multi-hop traversal or recursive hierarchy navigation, this is where you build a Knowledge Graph layer:如果你的用例需要多跳遍历或递归层级导航，这就是构建知识图谱层的地方：
- KG_NODE table: one row per entity instanceKG_NODE 表：每个实体实例一行
- KG_EDGE table: one row per relationship between instancesKG_EDGE 表：实例间每种关系一行
- Traversal UDFs for common graph operations用于常见图谱操作的遍历 UDF（用户定义函数）
- Inference engine stored procedures for rule application用于规则应用的推理引擎存储过程
- An Ontology Semantic View that exposes the graph to agents as a queryable interface一个将图谱作为可查询接口暴露给智能体的本体论语义视图
This is the most powerful and most expensive path. Scope it to the specific traversal use case that requires it.这是最强大但也最昂贵的路径。将其范围限制在需要它的特定遍历用例中。
Build it with a clear transition plan toward native platform capabilities as they mature custom graph infrastructure you build today should be designed to be replaced, not extended indefinitely.构建它时要有一个向原生平台功能过渡的清晰计划——你今天构建的自定义图谱基础设施应该设计为可被替换，而不是无限期扩展。
Common Mistakes to Avoid需要避免的常见错误
Mistake 1: Building an ontology before building Semantic Views错误 1：在构建语义视图之前构建本体论
An ontology is a layer on top of a semantic foundation. Without governed metric definitions and entity relationships at the Semantic View level, your ontology has nothing trustworthy to reference. Teams that skip to Level 4 before establishing Level 2 end up with a sophisticated graph that returns the wrong numbers just more elegantly.本体论是语义基础之上的层级。如果没有语义视图层面的治理指标定义和实体关系，你的本体论将没有可信的参考依据。在建立 2 级之前就跳到 4 级的团队，最终会得到一个复杂的图谱，只是它返回错误数字的方式更优雅而已。
Foundation first.基础先行。
Mistake 2: Modeling every entity and relationship upfront错误 2：预先建模所有实体和关系
Start with the 3–5 entities your AI actually queries most. Add relationships as questions fail, not preemptively. Over-engineered ontologies never get maintained.从你的 AI 最常查询的 3–5 个实体开始。当问题失败时再添加关系，而不是预先添加。过度设计的本体论永远无法得到维护。
Mistake 3: No governance owner错误 3：没有治理所有者
Business definitions drift. “Active Customer” means something different after a product pivot. Fiscal calendars change. Metrics get redefined after a reorg.业务定义会漂移。“活跃客户”在产品转型后意义不同。财年日历会改变。指标会在重组后被重新定义。
If no one owns the Semantic View after you deliver it, it will be stale within six months. Define the owner as a specific person or team, not “the data team” before you define the schema. If you can’t identify an owner, that’s a signal the organization isn’t ready to maintain what you’re about to build.如果你交付后没人负责语义视图，它会在六个月内过时。在定义模式之前，将所有者定义为特定个人或团队，而不是“数据团队”。如果你无法确定所有者，这说明组织尚未准备好维护你即将构建的内容。
Mistake 4: Using a Knowledge Graph to solve a vocabulary problem错误 4：使用知识图谱解决词汇问题
Knowledge Graphs are for traversal and inference following chains of relationships at runtime. If the problem is “Finance and Sales disagree on what Revenue means,” that is a Business Glossary problem, not a graph problem.知识图谱用于在运行时进行关系链的遍历和推理。如果问题是“财务部和销售部对收入的定义有分歧”，这是一个业务术语表问题，而非图谱问题。
Using a Knowledge Graph to solve a vocabulary conflict is like using a chainsaw to slice bread. It will technically work. It is the wrong tool, it will cost ten times as much, and someone will get hurt.使用知识图谱解决词汇冲突就像用电锯切面包。它在技术上可行，但工具用错了，成本高出十倍，而且还会造成伤害。
Conclusion: The One Thing to Remember结论：要记住的一件事
The goal is not to build an ontology. The goal is to give your AI the Enterprise Context it needs to return answers your business can trust.目标不是构建本体论。目标是为你的 AI 提供它所需的企业上下文，以返回企业可以信任的答案。
Start with a clean data model. Add metadata. Build a Semantic View for your most critical domain and make it part of your analytics pipeline. Use a Business Glossary for cross-domain vocabulary governance. Build a Knowledge Graph only when multi-hop traversal or recursive hierarchy navigation is genuinely required not before.从干净的数据模型开始。添加元数据。为最关键的领域构建语义视图，并使其成为分析流水线的一部分。使用业务术语表进行跨领域词汇治理。仅在确实需要多跳遍历或递归层级导航时才构建知识图谱，不要提前构建。
The most expensive mistake in this space is not building too little. It is building the wrong thing at the wrong layer because the problem was misdiagnosed.在这个领域，最昂贵的错误不是构建得太少，而是因为问题诊断错误，而在错误的层级构建了错误的东西。
Diagnose first. Build the minimum layer that solves the problem. Stop there.先诊断。构建能解决问题的最小层级。到此为止。
Disclaimer: The opinions expressed in this post are my own and not necessarily those of my employer (Snowflake).免责声明：本文表达的观点仅代表我个人，不一定代表我的雇主 (Snowflake)。
