Semantic views are structured definitions that describe a database's tables, columns, relationships and business logic so that AI systems can answer natural language questions accurately. They're the layer between raw data and useful answers.语义视图（Semantic views）是结构化的定义，用于描述数据库的表、列、关系和业务逻辑，从而使人工智能系统能够准确回答自然语言问题。它们是原始数据与有效答案之间的中间层。
Building one is straightforward in theory. In practice, most semantic views fail for the same few reasons: definitions that don't match how the business actually operates, incomplete coverage of the concepts people ask about and silent drift as the underlying data evolves. These aren't model problems. They're input problems.理论上，构建语义视图非常简单。但在实践中，大多数语义视图的失败原因大同小异：定义与实际业务运作方式不符、对人们询问的概念覆盖不全，以及随着底层数据的演变而产生的隐性偏差。这些并非模型问题，而是输入问题。
Over the course of building Semantic View Autopilot (SVA), we arrived at a set of principles for what makes a semantic view good — and designed the product around them.在构建“语义视图自动驾驶”（Semantic View Autopilot，简称 SVA）的过程中，我们总结了一套关于如何构建优秀语义视图的原则，并围绕这些原则设计了该产品。
Definitions should come from organizational behavior, not individual knowledge定义应源于组织行为，而非个人知识
The most common way to build a semantic view is to assign someone — usually a data engineer or analytics lead — to define every metric, filter and relationship by hand. The problem is that this person is making hundreds of judgment calls based on their own understanding, and the result reflects a single perspective.构建语义视图最常见的方法是指定某个人（通常是数据工程师或分析主管）手动定义每一个指标、筛选器和关系。问题在于，此人是基于自己的理解做出数百项判断，最终结果反映的只是单一视角。
Business definitions are inherently collective. "Revenue" means what the organization has agreed it means through years of dashboarding, reporting and ad hoc analysis. That agreement is already encoded — in Tableau calculated fields, in recurring query patterns, in dbt model logic. It just isn't written down in one place.业务定义本质上是集体性的。“收入”的含义是组织通过多年的仪表板制作、报告和临时分析所达成共识的内容。这种共识已经编码在 Tableau 计算字段、循环查询模式和 dbt 模型逻辑中，只是没有统一记录在一个地方而已。
How we approach this in SVA: The system ingests from existing data artifacts rather than starting from a blank file. Tableau workbooks, dbt projects, Power BI models, manual SQL and sources from Open Semantic Interchange partners all serve as input. Each is treated as evidence of how the business defines its concepts. The semantic view is assembled from this evidence rather than authored from scratch.我们如何在 SVA 中实现这一点：系统从现有的数据资产中获取信息，而不是从空白文件开始。Tableau 工作簿、dbt 项目、Power BI 模型、手动 SQL 以及来自 Open Semantic Interchange 合作伙伴的源数据，都可作为输入。每一个输入都被视为业务如何定义其概念的证据。语义视图是根据这些证据汇编而成，而非从零开始撰写。
Coverage should reflect real usage, not assumed importance覆盖范围应反映实际使用情况，而非预设的重要性
A hand-authored semantic view tends to cover what the author thinks is important. But the questions people actually ask don't always align with what someone anticipated. Gaps show up in production — a user asks about "net new customers" and the semantic view has no definition for it, even though analysts have been calculating it in SQL for months.手动编写的语义视图往往倾向于涵盖作者认为重要的内容。但人们实际提出的问题并不总是与预期的相符。生产环境中会出现缺口——用户询问“净新增客户”，而语义视图中却没有定义，尽管分析师几个月来一直都在用 SQL 计算这个指标。
Good coverage means the semantic view includes the concepts that people actually use, weighted by how broadly and consistently those concepts appear across the organization.良好的覆盖范围意味着语义视图应包含人们实际使用的概念，并根据这些概念在整个组织中出现的广泛程度和一致性进行加权。
How we approach this in SVA: Query history is one of the primary inputs. SVA clusters queries by the tables, columns, filters and aggregations they use, and looks for convergence. When multiple analysts across different teams independently calculate something the same way, that concept is a candidate for inclusion. This catches definitions that matter in practice but wouldn't have occurred to any single author.我们如何在 SVA 中实现这一点：查询历史是主要的输入之一。SVA 会根据查询所使用的表、列、筛选器和聚合方式对查询进行聚类，并寻找收敛点。当不同团队的多位分析师独立地以相同方式计算某个指标时，该概念就成为纳入语义视图的候选对象。这能够捕捉到在实践中很重要，但单凭某个作者个人可能无法想到的定义。
Noisy signals require consensus, not just frequency嘈杂的信号需要共识，而不仅仅是频率
Query history is rich but messy. Any individual query might be exploratory, wrong or testing something. The most frequently run query on a table might be a health check, not a business question. Frequency alone is a poor proxy for correctness.查询历史虽然丰富，但也十分混乱。任何单个查询都可能是探索性的、错误的或仅用于测试。在某个表上运行频率最高的查询可能只是健康检查，而非业务问题。仅凭频率来衡量正确性是非常不可靠的。
What matters is agreement across independent sources. When the same join pattern, filter condition or aggregation appears across different analysts, different time periods and different tools, that convergence is a meaningful signal. It represents how the organization has collectively settled on a definition, even if nobody formalized it.重要的是跨独立来源的一致性。当相同的连接模式、筛选条件或聚合方式出现在不同的分析师、不同的时间段和不同的工具中时，这种收敛就是一个有意义的信号。它代表了组织集体达成的定义共识，即使没有人将其正式化。
How we approach this in SVA: The system uses clustering to identify convergent patterns rather than simply counting occurrences. It also weights signals by source reliability — a curated Tableau workbook ranks higher than a one-off ad hoc query. When multiple source types agree (for example, query history confirms the join pattern that a Tableau workbook uses), confidence increases. When they disagree, the conflict is flagged.我们如何在 SVA 中实现这一点：系统使用聚类分析来识别收敛模式，而不是简单地计算出现次数。它还会根据来源的可靠性对信号进行加权——一个经过整理的 Tableau 工作簿的权重高于一次性的临时查询。当多种来源类型达成一致时（例如，查询历史证实了 Tableau 工作簿所使用的连接模式），置信度就会提高。当它们产生冲突时，系统会标记出这些冲突。
Confidence should be explicit, not hidden置信度应明确显示，而非隐藏
Not every definition in a semantic view is equally well-supported. Some relationships are obvious — a primary key join confirmed by thousands of queries. Others are ambiguous — two columns that might be related but only appear together in a handful of exploratory queries.语义视图中的每个定义并非都拥有同等程度的支持。有些关系是显而易见的——例如由数千次查询证实的表主键连接。另一些则具有歧义——例如两个可能相关的列，但它们仅在少数几个探索性查询中同时出现。
A good semantic view makes this distinction visible. Treating high-confidence and low-confidence elements identically means either the low-confidence items are silently wrong, or the high-confidence items are unnecessarily held up for review.一个好的语义视图应使这种差异清晰可见。如果对高置信度和低置信度的元素一视同仁，意味着要么低置信度的项目存在隐性错误，要么高置信度的项目被不必要地搁置以待审查。
How we approach this in SVA: The system splits its output by confidence level. High-confidence elements — where the evidence is unambiguous across multiple signals — go directly into the semantic view. Ambiguous elements go into a suggestions panel, each accompanied by the evidence that produced them: which queries support the suggestion, what the cardinality analysis showed, where sources disagreed. Reviewers evaluate proposals with data attached, not bare yes/no prompts.我们如何在 SVA 中实现这一点：系统根据置信度级别对输出进行拆分。高置信度元素（即在多个信号中证据明确的元素）直接进入语义视图。有歧义的元素进入建议面板，并附带产生该建议的证据：哪些查询支持该建议、基数分析的结果、来源在何处存在分歧等。审查人员可以在有数据支持的情况下评估提案，而不是面对简单的“是/否”提示。
This means the human work is reviewing and curating rather than authoring. A subject matter expert who recognizes correct definitions when they see them — but wouldn't write the YAML themselves — can still produce a high-quality semantic view.这意味着人类的工作是审查和整理，而不是编写。一位能识别正确定义但不会自己编写 YAML 的主题专家，依然可以产出高质量的语义视图。
A semantic view should encode understanding, not just examples语义视图应编码理解，而不仅仅是示例
Verified queries — trusted SQL paired with natural language questions — are the highest-value component of a semantic view. They teach the system exactly how to answer specific questions. But if the system only learns to match those exact questions, the value plateaus quickly. Every new question type requires a new verified query.经过验证的查询（即与自然语言问题配对的可信 SQL）是语义视图中价值最高的部分。它们能准确教导系统如何回答特定问题。但如果系统只学会匹配这些精确的问题，其价值很快就会停滞。每一种新类型的问题都需要一个新的验证查询。
The better outcome is for the knowledge contained in verified queries to transfer into the semantic view's structure — as metric definitions, filters and instructions — so the system can handle variations it hasn't seen before.更好的结果是将验证查询中包含的知识转化为语义视图的结构（如指标定义、筛选器和指令），这样系统就能处理它之前未曾见过的变体。
How we approach this in SVA: The system runs an optimization step that takes each verified query, temporarily removes it, and tests whether the model can still answer correctly. Where it can't, the system identifies what concept is missing and adds it to the semantic view as a reusable definition. A verified query about "active customers last month" produces a general definition of "active customer" that works for any time range, region or segment — not just the original question.我们如何在 SVA 中实现这一点：系统运行一个优化步骤，提取每个验证查询，暂时将其移除，并测试模型是否仍能正确回答。如果不能，系统会识别缺失的概念，并将其作为可重用定义添加到语义视图中。关于“上个月活跃客户”的验证查询，会产生一个通用的“活跃客户”定义，该定义适用于任何时间范围、地区或细分市场，而不仅仅限于原始问题。
Semantic views should stay current without manual maintenance语义视图应保持最新，无需手动维护
Business logic changes. New product tiers launch, team structures shift, reporting definitions get updated. A semantic view that was accurate six months ago can quietly drift out of alignment if nobody is maintaining it.业务逻辑会发生变化。新的产品层级推出、团队结构调整、报告定义更新。如果无人维护，六个月前准确的语义视图可能会悄然偏离轨道。
Good semantic views evolve with the organization. Changes in query patterns, new BI artifacts and shifts in usage should surface as proposed updates rather than accumulating as silent gaps.良好的语义视图应随组织一起演进。查询模式的变化、新的 BI 资产和使用习惯的转变，都应以建议更新的形式呈现，而不是积累成隐性的缺口。
How we approach this in SVA: The system monitors usage patterns and query history on an ongoing basis. When new patterns emerge — a new filter value appearing consistently across queries, a join path that's become more common — SVA proposes updates to the semantic view through the same suggestions mechanism used during creation. The same confidence split applies: Clear changes get proposed for direct application; ambiguous ones get surfaced for review.我们如何在 SVA 中实现这一点：系统持续监控使用模式和查询历史。当出现新的模式（例如一个筛选值在查询中持续出现，或者某种连接路径变得更加常见）时，SVA 会通过创建时所用的同一建议机制，提出对语义视图的更新建议。同样的置信度拆分机制也适用：明确的变更会被提议直接应用；有歧义的变更则会被提出来供审查。
These principles aren't specific to Snowflake or to SVA. Any approach to building a semantic view benefits from grounding definitions in real usage, being explicit about confidence and designing for generalization over memorization. SVA is our implementation of these ideas — a system that treats semantic view creation as evidence synthesis rather than manual authoring.这些原则并非 Snowflake 或 SVA 所特有。任何构建语义视图的方法，如果能将定义建立在实际使用情况之上、明确置信度并设计为通用化而非死记硬背，都能从中获益。SVA 是我们对这些理念的实现——一个将语义视图的创建视为证据合成而非手动编写的系统。
