Schema 能告诉 AI 有哪些表、栏位和型别，却不会告诉它公司如何定义「有效客户」、退款要不要扣除，或转换率该用哪个分母。AI 要可靠地查企业资料，除了看懂资料结构，还需要可追溯、可审阅且有适用范围的业务语意。
Schema 描述资料长相，不描述公司如何做决定
假设资料库里有这些栏位：
accounts(account_id, created_at, status)
subscriptions(account_id, started_at, cancelled_at, plan)
events(account_id, event_name, occurred_at)
invoices(account_id, amount, paid_at, refunded_at)
光看名称，模型可以推测 paid_at 是付款时间、amount 是金额，也能组出语法正确的 SQL。但当使用者问「上个月新客转换率是多少」，schema 没有回答下面任何一题：
- 「新客」以帐号建立、首次启用，还是首次付款认定？
- 同一公司开了三个帐号，分母算一个还是三个？
- 免费方案转付费是否计入转换？
- 转换时间窗是注册后 7 天、30 天，还是同一历月？
- 测试帐号、内部帐号与取消后重订要不要排除？
- 迟到资料与退款应回补到哪一期？
这些不是栏位探索问题，而是业务规则。模型即使完全没有写错 SQL 语法，也可能在多个「都说得通」的定义中选错一个，最后交出精确但不可用的数字。
2026 年提出的企业 Text-to-SQL benchmark EntSQL，正是为了测量这个落差。它包含五个业务领域、1,066 组中英语意对齐案例；论文指出，多数案例除了问题和 schema，还需要内部指标、报表惯例或组织规则。该研究在英文输入、提供长篇企业文件的设定下，最佳受测系统只有 15.9%。这不是所有 AI 分析工具的通用准确率，但它说明了一件事：把 schema 丢进 prompt，并不等于模型已理解企业。EntSQL 论文摘要与版本纪录
AI 分析需要的不是更多栏位，而是六种语意
「语意层（semantic layer）」通常指位于原始资料与使用端之间、集中描述商业概念的模型。不同产品实作并不相同，但常见内容包括 metrics、dimensions、relationships 与计算规则；例如 Salesforce 的 Tableau Semantics 也把维度、量值、关系与指标列为主要定义类型。Tableau Semantics 概念文件
若目标是让 AI 协助分析，可以先不争论工具名称，而是确认六种语意是否齐全：
| 语意 | 必须说清楚的问题 | 缺少时的典型错误 |
|---|---|---|
| Entity | 客户、帐号、订单分别以什么 key 识别？ | 把多帐号公司重复计数 |
| Grain | 每列代表事件、日、订单还是客户？ | JOIN 后金额或人数膨胀 |
| Metric | 公式、分子、分母与聚合方式是什么？ | 同名 KPI 算出不同版本 |
| Time | 使用事件时间、入库时间或财务期间？ | 跨月结果无法对帐 |
| Scope | 哪些状态、方案、地区与测试资料要排除？ | 把不适用样本算进结果 |
| Authority | 谁核准、适用哪个专案、何时更新？ | 过期规则持续被重用 |
完整的 semantic layer 可以让 metrics 与 dimensions 被不同工具重用，甚至把定义转成查询。Cube 的官方文件便示范了如何将 measure、dimension、filter 与 calculated measure 写进可重用资料模型，再由模型生成 SQL。Cube Data Modeling 文件
但「有一份指标字典」与「系统会强制套用同一套计算」仍是两件事。Markdown、Wiki 或 catalog 可以提供上下文；可执行的 semantic layer 则能在查询时套用定义。团队应清楚标示自己目前做到哪一层，不能因为文件存在，就假设所有 AI 查询都会自动遵守。
把一句指标定义，写成 AI 能被审查的契约
「付费转换率＝付费客户／新客户」看似已经很清楚，实际上仍缺少执行条件。较可用的定义至少应长成下面这样：
指标：新客 30 日付费转换率
适用范围：台湾自助注册帐号；排除员工、测试与合作伙伴帐号
Entity：company_id，一家公司只计一次
分母：观察月首次完成 email 验证的公司
分子：分母公司中，验证后 30 日内首次成功付款者
时间栏位：verified_at、paid_at，皆以 Asia/Taipei 计算
重订规则：观察月前曾付费者不算新客
资料来源：accounts、company_members、invoices
验证：分母与 CRM 新客月报对帐；抽查跨月底付款案例
Owner：Growth Ops
版本：2026-07-01 起适用
这个格式的重点不在 Markdown，而在它让人能提出具体异议：为什么用 email 验证而不是建立帐号？企业业务带来的客户为何排除？30 日跨越报表月份时如何呈现？
AI 可以协助把契约转成 SQL，但契约本身不该由模型默默猜完。只要 entity、grain、时间窗或排除条件尚未取得共识，就应先把它标成待确认假设，而不是用最可能的栏位名称代替决策。
不一定要先买一套 semantic layer，先判断缺口在哪
导入方式可以按重用需求逐步增加：
- 一次性探索：在分析 Plan 写清 grain、filter、join 与时间窗，保留 SQL 供审阅。
- 专案内重用：建立指标卡、栏位映射与状态码 Reference，指定 owner 和版本。
- 跨工具共用：将稳定 metrics、dimensions、relationships 放进可执行的 semantic layer 或 metrics layer。
- 组织级治理：加入变更审核、权限、测试、lineage 与淘汰流程。
如果公司只有几张稳定报表，先把最常争议的十个指标写清楚，通常比一次建模所有资料更实际。反过来，若同一指标同时供应 BI、试算表、API 与多个 AI Agent，仅靠每次 prompt 附上一份文件，很容易发生版本漂移；这时可执行且集中治理的语意层会更重要。
Lantide Data 如何把业务语意放进可治理的分析流程
Lantide Data 不把自己定位成企业级 semantic layer 或指标服务。它处理的是另一段风险：当分析师与 AI Agent 真的要查资料时，如何让业务语意被读取、被审阅，并留在可追溯的交付流程里。
- Reference docs 适合保存栏位映射、状态码、join 说明与完整指标定义；Project Knowledge 中只保留用途与读取时机，让 Agent 按任务载入，而不是把大型文件永远塞进 prompt。
- 跨对话可重用的口径可由 Agent 提案进 Queued Knowledge，附上可验证 evidence；只有使用者 Apply 到 User 或指定 Project 后，才会进入后续上下文。
- 正式分析把 entity、grain、filter、时间窗与验证方式写进 Plan。使用者审阅并按下 Execute 后，Agent 才依契约执行，最后以 SQL evidence 与限制形成 Report。
这三层分别处理「大型参照资料」「核准后的长期知识」与「本次分析契约」，彼此不能取代。Reference docs 与 Agent Memory 提供上下文，不会像可执行 semantic layer 一样自动强制所有指标定义；Plan 审阅也不能证明来源资料本身正确。团队仍需维护上游模型、测试口径，并由对结果负责的人作最后判断。产品机制可参考 Agent 分析工作流、可治理的 Agent Memory 与 Reference docs 操作说明。
结语：先找出模型正在猜的那一层
下一次 AI 产出一段能跑的 SQL，先别只检查语法。逐项问 entity、grain、metric、time、scope 与 authority 是否已有明确答案；没有答案的地方，就是模型正在猜的地方。
Schema 是分析入口，不是业务契约。可靠的 AI 分析也不只是把更多文件送进 context，而是让定义有来源、适用范围与核准者，并让每次执行留下可审阅的 SQL 和限制。