这周的数据新闻，看起来有点散。
一边是 Power BI 继续把语义模型接进 AI-first 的数据应用，一边是 Databricks 在 Data + AI Summit 之后继续推 Unity Catalog 的治理能力；MIT CISR 专门讨论企业为什么需要给 GenAI 建语义层，Lyft 又写了一篇很细的指标语义层实践。
Shopify 则讲了一件更有意思的事：怎么训练 AI 在不该回答的时候说“不”。
这些东西放在一起，有一个共同的意思：
AI 进数据工作台以后，聊天框会越来越便宜，可信的业务语义会越来越贵。
以前我们做报表，报表主要是给人看的。页面上有指标、有筛选器、有折线图，业务同学点进去，自己判断。
现在情况开始变了。
报表、指标字典、数据模型、权限、血缘和质量规则，正在变成 AI 可以调用的上下文。它们不再只是“文档补齐”，而是模型能不能答对、能不能拒答、答错后能不能追溯的前提。
这事不热闹。真上线的时候，偏偏最先卡在这里。
Power BI：语义模型开始变成 AI 应用入口
Microsoft 在 6 月 Power BI 更新里提到 Fabric Apps for Semantic Models。简单说，就是围绕 Power BI semantic models 构建更像 AI-first 的数据应用体验。
这条消息如果只当产品功能看，容易觉得只是又多了一个入口。
但站在数据团队角度，它更像一个信号：语义模型不再只是 BI 工程师内部维护的层，而是开始变成 AI 应用理解业务数据的入口。
过去很多公司做语义层，常见目标是让业务少问几个口径问题：销售额怎么算，复购怎么算，活跃用户怎么算。语义层像一本摆在旁边的说明书，写得认真一点，大家偶尔翻一下。
AI 进来以后，这本说明书的位置变了。
模型不会像人一样在会议室里听半天背景，也不会自动知道“收入”在财务、运营和增长团队口中分别是什么意思。它要么从语义模型里拿到定义，要么自己猜。
一旦让它猜，后面的图表再漂亮，也只是把猜测画得更像真的。
所以这条更新给数据分析师和 BI 同学的提醒是：以后你维护的可能不只是报表页面，而是一套给人和 AI 共用的业务接口。
这套接口至少要说明四件事：
- 一个指标到底叫什么；
- 它由哪些表和字段算出来；
- 在什么业务场景下能用；
- 哪些问题不应该直接回答。
最后一点尤其容易被忽略。一个语义模型如果只告诉 AI “能问什么”，不告诉它“不能问什么”，就像只教新同事查库，不告诉他哪些数不能随便往外发。
这不是聪明，是危险。
Databricks：治理台正在从后台走到前台
Databricks 这周继续围绕 Unity Catalog、Governance Hub 和数据治理讲更新。
这些词听起来不如 Agent、BI Copilot、自然语言问数热闹，但它们恰好说明一件事：企业 AI 数据应用越往生产走，治理越不可能只待在后台。
过去很多数据治理项目有一个尴尬处境。
治理团队在后台建标准、补血缘、配权限、写质量规则；业务在前台继续导 Excel、截屏、群里问数。两边都忙，彼此都觉得对方“不懂工作”。
AI 进来以后，这种割裂会更明显。
如果一个 AI Agent 要替业务查数、解释指标、调用数据产品，它不能只接一个数据库账号。它还需要知道：
- 用户有没有权限问这个问题；
- 这个指标有没有被废弃；
- 这张表的新鲜度是否正常；
- 这个结果能不能用于对外披露；
- 回答里该不该展示明细数据。
这些判断不可能都写在 Prompt 里。
Prompt 适合表达意图，不适合承担组织规则。
真正能长期工作的，是权限、目录、血缘、质量、审计这些看起来不性感的东西。它们过去像机房里的管线，平时没人看；现在 AI 要接水龙头，管线在哪里、阀门归谁、哪段水质有问题，就全都得摊开。
对国内数据团队来说，这个信号很实用：不要把 AI 数据应用项目只当成“模型接入项目”。它更像一次把数据治理推到前台的机会。
当然，这也意味着另一个问题。
如果治理本身做得像填表，AI 也救不了它。
MIT：语义层不是给 AI 的词典，而是业务边界
MIT CISR 最近有一篇文章，题目很直接：The Case for a Semantic Layer。
文章讨论的是企业为什么要为 GenAI 构建 semantic layer。这个说法听起来像架构师会议里的词，但它对应的，其实是很多数据团队每天都在补的洞。
一个业务问题进来，系统不能只知道字段名。
它还要知道字段背后的业务含义、计算边界、权限限制、更新频率和适用场景。
比如同样是“客户”，在 CRM 里可能指销售机会，在支付系统里可能指付费账户，在运营分析里又可能指最近 30 天活跃用户。人类开会时可以靠上下文慢慢对齐，模型不行。
模型如果没有语义层，就只能把这些词当作相似的字符串。
这就是 AI 问数最容易出问题的地方：它不是不会查，而是不知道自己查到的是不是你真正要的那个东西。
所以语义层不只是给 AI 的词典。
它更像一组业务边界：哪些概念可以等价，哪些不能；哪些指标适合日报，哪些只能用于实验分析；哪些字段可以给普通用户看，哪些只能在授权场景里出现。
这件事落到普通数据团队，可以先不用想得太大。
先把最常被问的 20 个指标写清楚，已经比空谈“企业级语义层”更有价值：
- 指标定义；
- 数据来源；
- 更新时间；
- 适用场景；
- 不适用场景；
- 负责人和变更记录。
AI 不会嫌这些东西朴素。
它真正怕的是，公司自己都没留下答案。
Lyft：指标语义层不是概念，是团队协作方式
Lyft Engineering 写了一篇关于 Metric Semantic Layer 的文章，讲他们如何治理和扩展关键数据定义。
这类文章不用盯着具体技术栈看。更有用的是它承认了一个现实：指标定义不是“写清楚一次”就结束了。
公司越大，团队越多，同一个指标越容易出现多个版本。
增长团队要一个口径，财务团队要一个口径，运营团队又有一个临时排除规则。每个人都有理由，每个人也都觉得自己那版才是“业务真实情况”。
这时候，语义层如果只是一张漂亮的指标字典，很快就会失效。
真正难的是让指标定义进入协作流程：
- 谁有权新增指标；
- 谁负责审批口径变化；
- 变更后哪些报表和模型会受影响；
- 旧口径保留多久；
- 业务争议发生时，以哪个版本为准。
这些问题听起来很杂，但它们决定了语义层能不能活下来。
很多公司不是没有指标字典，而是指标字典没有参与工作。它躺在文档平台里，像一个很认真但没人邀请的同事。
Lyft 这类实践的启发在于：语义层不是为了让数据团队显得专业，而是为了减少每次跨团队协作时重新解释世界的成本。
这件事一旦和 AI 放在一起，就更明显。
因为 AI 不会知道你们上个月在会议室里吵过什么。它只会读取系统里最后留下来的东西。
如果系统里留下的是多个冲突口径，AI 的回答就会像一个很勤快的新同事：每句话都像对的，但越帮越乱。
Shopify：会拒答的 AI，比每题都答的 AI 更像工具
Shopify Engineering 最近写了 Sidekick 的数据自动整理和拒答能力。
这件事适合放进数据周刊，因为它把很多公司不愿意面对的问题说出来了：AI 数据助手不应该每个问题都硬答。
在数据场景里，拒答不是失败。
拒答可能是系统知道数据不够新，知道口径不匹配，知道用户权限不够，或者知道这个问题本身不能从现有数据推出结论。
这比“给一个看起来合理的答案”更负责任。
做数据工作的朋友应该很熟悉这种场景。
业务问：“这个活动是不是有效？”
如果只看转化率，像是有效；如果补上渠道变化、库存变化、补贴变化，答案又没那么确定。一个负责任的数据分析师不会立刻拍板，而是会先问：你说的有效，是 GMV、利润、复购，还是新客留存？
AI 也应该学会这件事。
问题在于，很多 AI 数据产品的演示恰恰反过来：你问什么，它都答；答得越快，演示越顺。
可是生产环境不是演示厅。
一个总是回答的系统，很容易让人误以为“答案已经存在”。而很多数据问题真正的答案，是“现在还不能这么问”。
Shopify 这类实践有意思，是因为它把 AI 数据产品从“会生成答案”往“会判断问题是否成立”推了一步。
对数据团队来说，这意味着以后设计 AI 问数，不只是准备数据集和示例问题，还要准备拒答规则。
哪些问题要提示换口径，哪些问题要要求补时间范围，哪些问题要提醒样本太少，哪些问题要直接拦下来。
这些规则不花哨，但很接近真实工作。
拾穗解读：这周真正的关键词，是“可托付”
这周几条新闻放在一起，我觉得可以用“可托付”来概括。
一个数据系统能不能托付，不是看它能不能回答更多问题，而是看它在不确定的时候怎么处理。
能不能说清楚指标来自哪里。
能不能知道用户有没有权限。
能不能保留口径变化的痕迹。
能不能在数据不够时拒绝回答。
能不能在异常或拒答发生时给出下一步路径。
这些问题过去也存在，只是过去由人兜底。业务问错了，数据同学听出来；指标口径不对，老员工提醒一句；告警太粗，值班同学凭经验补判断。
AI 进来以后，这些隐性的经验不能再只停在人脑里。
它们要被写进语义层、治理台、质量规则、拒答策略和事件记录里。
这对普通数据从业者不是坏消息。
相反，它给了一个很清楚的机会：以后更值钱的，是能把一个模糊的数据问题整理成可复用、可审计、可交接的系统能力。
这话听着有点硬。
换成日常说法就是：别只把答案给出去，要把答案为什么可信也留下来。
下次你再做一张报表、一张指标表、一个异常告警、一套问数规则时，可以多问一句：
如果明天不是人来看它，而是一个 AI Agent 来调用它，它能看懂吗？
如果看不懂，不一定是 AI 太笨。
也可能是我们以前留给系统的东西太少了。
本周其他值得看
- Salesforce Engineering 讲 Data 360 的分群系统如何支撑大规模客户数据模型，适合关注企业级数据产品的同学补一眼。
- Trivago Engineering 写了 Kafka Consumer 成本优化，虽然不在本期主线里，但对做数据平台成本治理的人有参考价值。
来源：
- Power BI June 2026 Feature Summary
- What’s New in Unity Catalog and Governance at Data + AI Summit 2026
- Metric Semantic Layer: How Lyft Governs and Scales Key Data Definitions
- Building Semantic Layers for GenAI
- Data Engineering Weekly #275
- Shopify: Teaching Sidekick to say no - automated data curation with LLM judge consensus
- How Data 360 Segmentation Processes a Quadrillion Records Across Arbitrary Customer Data Models
- How We Cut Kafka Consumer Deployment Costs by 83%
