这周的数据工程新闻，很适合和上一周连起来看。
上周我们聊的是生产摩擦：Flink 账单、ClickHouse 瓶颈、Agent 成本。到了这一周，主题往前走了一步：
AI 开始接近数据工作台，但它真正需要的不是更会聊天，而是更清楚的数据基础。
Data Engineering Weekly #274 里几条文章放在一起，几乎像一张路线图。Anthropic 讲 Claude 如何做自助数据分析，Airbnb 讲多产品世界里的数据架构，Uber 讲数据抽象层，LinkedIn 讲 Agent 语义检索，Capital One 讲 DataAgents 如何把 9 个月分析压到 10 天。
听起来都很新。
但往下看，里面反复出现的是一些老词：模型、表、指标、命名、抽象层、检索、验证、责任。
新东西没有绕开旧问题。
它只是把旧问题推到了台前。
Claude 问数：自助分析不是“把 SQL 交给模型”
Anthropic 写了一篇关于 Claude 自助数据分析的文章。最值得注意的，不是“Claude 能不能回答数据问题”，而是他们把准确性的前提讲得很直白：数据模型、转换、测试、仓库表，以及描述这些东西的元数据，仍然是基础。
换句话说，AI 分析 Agent 并不会神奇地越过数仓基本功。
它只是站在基本功上面。
这对很多公司很重要。因为一提到 AI 问数，大家容易先想聊天框：业务用自然语言问，模型自动写 SQL，最后出一个图表。
可是如果底下没有稳定的指标定义，没有经过测试的数据模型，没有 freshness 和 completeness 这类质量检查，模型回答得越流畅，反而越危险。
过去我们做自助 BI，常见的问题是“业务不会拖字段”。到了 AI 问数，问题变成了“业务看不见模型怎么理解这个问题”。
这不是小变化。
前者是操作门槛，后者是信任门槛。
对国内数据团队来说，Claude 这条最值得带走的判断是：如果你们现在要做 AI 问数，不要先问“接哪个大模型”。先问下面这几个问题：
- 核心指标有没有统一定义；
- 关键表有没有质量测试；
- 数据更新时间有没有写进回答；
- 模型用了哪些表，用户能不能看见；
- 结果错了以后，能不能回到当时的问题、SQL 和数据版本。
如果这些问题还没答案，AI 问数越早开放，越容易变成一台很会说话的取数事故制造机。
Airbnb 多产品数据架构：去中心化不是各干各的
Airbnb 的文章讲的是多产品世界里的数据架构演进。
这个话题很像很多公司会遇到的阶段：公司不再只有一个核心业务，而是有多个产品、多个团队、多个域。每个团队都希望按照自己的业务逻辑建表、建指标、建数据产品。
去中心化听起来很合理。
可是问题也很快出现：不同团队开始使用不同的标识符、命名空间和模型约定。上游觉得自己很自治，下游开始到处对表。最后数据仓库里不是没有数据，而是同一个实体在不同地方长得不一样。
Airbnb 的思路不是简单回到“大一统”。他们强调几个原则：不要混用模型，标识符命名要和建模选择绑定，命名空间要区分产品域、全局域和团队自有域。
这件事对国内公司也很有参考价值。
很多数据治理项目失败，并不是因为大家不懂治理，而是因为治理只剩下“填表”和“补文档”。真正难的是在产品团队自治和公司级一致之间，找到可执行的边界。
比如：
- 哪些实体必须全公司统一；
- 哪些指标可以由产品域自己定义；
- 哪些表是团队内部用，哪些表能进入公共消费层；
- 一个用户、订单、商家、门店，在不同产品里到底该怎么命名。
这些问题如果早期不讲清楚，后面就会变成大量“口径对齐会”。
而口径对齐会，是数据人的体力消耗器。
Uber 数据抽象层：别让产品直接绑死物理表
Uber 这篇写的是 Data Abstraction Layer，数据抽象层。
文章里有一个很典型的问题：面向用户的数据产品，如果直接绑定到底层物理表，一旦表被重命名、拆分、迁移，前面的产品就会跟着受伤。原本只是数据平台内部的一次调整，最后变成产品迁移、接口改造和用户体验问题。
Uber 的做法，是在 OLAP、Docstore、Hive 等后端之上加一层抽象。查询请求不直接拍到某张物理表上，而是先经过 schema eligibility、availability window、column continuity 等规则，选择合适的物理候选。
这听起来像大厂架构。
但小团队同样会遇到低配版问题。
比如看板直接查 ODS 表，后面源系统字段一改，所有报表跟着挂；比如一个 AI 问数工具直接把表结构喂给模型，过两个月表拆了，模型还在引用旧字段；比如业务接口直接依赖某个中间表，数仓重构时没人敢动。
数据抽象层的核心不是“多加一层显得高级”。
它是在承认一件事：数据底座会变，但面向业务的语义不能跟着随便变。
这和 AI 问数也有关。
如果 Agent 直接面对物理表，它学到的是一堆当前时刻的字段名。如果中间有抽象层，它面对的才可能是稳定的数据产品、指标语义和可解释的访问边界。
以后很多公司做 AI 数据产品，可能都会补这一层。
只是名字不一定叫 Data Abstraction Layer。
LinkedIn Agent 检索：语义搜索不是“向量库一接就完”
LinkedIn 这篇讲的是 Hiring Assistant 里的 Agent 语义检索和排序。
Data Engineering Weekly 的摘要里提到，他们使用 MUSE，一个双塔 Matryoshka embedding 模型，用 LLM-Teacher 相关性标签训练；检索阶段用 2048 维截断向量做 ANN 召回，排序阶段用 4096 维向量做二级排序。结果是相关性提升 2.7%，InMail 发送量提升 4.1%，同时候选人 sourcing 数量更少。
这些数字当然好看。
但我更关心的是另一个点：Agent 场景里的搜索，不是把文本丢进向量库就结束。
招聘助手要理解的不是“关键词相似”，而是一个多步骤资格判断：候选人的经历、技能、职位要求、招聘方意图之间到底怎么匹配。LinkedIn 的做法，是把这种复杂判断蒸馏进可检索、可排序的 embedding 体系里。
这对企业内部知识库、指标检索、数据目录也有启发。
很多公司做 RAG 或 AI 问数，第一反应是“把文档切块，塞进向量库”。这一步只是开始。真正困难的是：
- 什么叫相关；
- 谁来标注相关；
- 搜索结果进 Agent 之前要不要重排；
- 模型回答错了，是召回错、排序错，还是知识本身错；
- 一条知识过期以后，旧向量怎么处理。
向量库不是保险柜。
它更像一个很大的抽屉。你不设计标签、顺序、清理规则，东西越多，越难找。
Capital One DataAgents：9 个月到 10 天，压缩的是分析链路
Capital One 这篇讲 DataAgents，把原本 9 个月的云资产分析压缩到 10 天。
这类标题容易让人误会成“AI 替人干活，所以效率暴涨”。但看 DEW 的摘要，关键不只是 Agent 本身，而是它们把一个问题拆成了三段：先做可行性评估，再为每类实体生成 Spark SQL 检测逻辑，最后逐个验证中等置信度输出。
换句话说，Agent 不是自由发挥。
它在一个有权威数据产品、有阶段拆分、有置信度标记、有逐项验证的流程里工作。
这点很关键。
很多数据团队现在也想让 AI 做“分析”。可分析不是一团雾。它通常可以拆成几种动作：
- 明确对象范围；
- 判断哪些数据可用；
- 生成检测规则；
- 批量执行；
- 标记置信度；
- 对不确定结果做人审；
- 把结果回写成可复用资产。
如果你把这些步骤都交给一个聊天框，它会显得很聪明，也会显得很不可控。
如果你把这些步骤拆开，Agent 才有机会成为工作流的一部分，而不是一个会输出漂亮解释的黑箱。
拾穗解读：这周真正的关键词，是“可托付”
这周几条信息放在一起，我觉得关键词不是 AI，也不是 Agent。
是“可托付”。
业务敢不敢把一个分析结果拿去开会？数据同学敢不敢让 Agent 直接查表？平台团队敢不敢改底层物理表？招聘团队敢不敢把语义搜索结果交给下一步动作？云资产团队敢不敢把 Agent 的判断写进治理流程？
这些问题看似分散，其实都在问同一件事：
这个数据系统，能不能被人托付一小段责任？
要做到这一点，靠一个更强模型不够。
Anthropic 讲的是数据基础。Airbnb 讲的是多产品架构里的统一边界。Uber 讲的是抽象层。LinkedIn 讲的是语义检索和排序。Capital One 讲的是 Agent 工作流里的验证。
它们都不是“把 AI 接上数据库”这么简单。
这对普通数据从业者有两个提醒。
第一，不要轻视那些旧活。
指标定义、命名规范、表分层、数据质量、权限边界、血缘记录，这些东西以前看起来像文档活、治理活、平台活。到了 AI 时代，它们会变成模型能不能可靠工作的前提。
第二，要开始训练自己从“写查询”切到“设计判断链路”。
AI 能帮你更快写 SQL，更快找文档，更快生成初稿。但你仍然要回答：它为什么这么查、查的是不是对的、结果能不能用、错了以后怎么回退。
这不是反对 AI。
这是把 AI 放回真实工作里。
真实工作从来不是“问一句，答一句”。
真实工作是有人要拿这个答案去开会、投钱、排班、发券、调整策略、写汇报。一个数据系统能不能进入这些场景，最后看的不是它演示时有多顺，而是它出事后能不能解释。
这就是“可托付”的含义。
本周其他值得看
John Kutay 写了 AI Database for Agentic GTM Operations，讨论 Agentic GTM 里的实体解析、预计算和成本问题。这个话题适合做增长、销售自动化和客户数据平台的朋友继续看。
Naidu Rongali 写了从 Hive-style Data Lakes 迁移到 Apache Iceberg，里面提到 Iceberg 的 snapshots、manifest lists 和 column ID 跟踪。这个话题不新，但仍然是很多团队补开放表格式基本功时绕不开的一课。
Kiran Pothina 写 dbt CI/CD、监控和模型健康，重点在 slim CI、manifest、state:modified+ 和 defer。对有多个 dbt 项目、CI 越跑越慢的团队来说，值得单独拿出来看。
Andreas Andreakis 写 DBLog 的 snapshot-equivalence，用形式化方式证明 backfill 和 CDC replay 的一致性。这个题材偏硬，但对做 CDC、流批一体和增量同步的人很有价值。
如果你最近也在公司里推进 AI 问数、数据目录、语义层或数据质量，可以加我微信聊聊：shisuidata。备注「数据周刊」就行。
来源：
- Data Engineering Weekly #274：https://www.dataengineeringweekly.com/p/data-engineering-weekly-274
- Anthropic：How Anthropic enables self-service data analytics with Claude：https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude
- Airbnb Engineering：Scaling beyond one: How Airbnb evolved its data architecture for a multi-product world：https://medium.com/airbnb-engineering/scaling-beyond-one-how-airbnb-evolved-its-data-architecture-for-a-multi-product-world-6125645d470c
- Uber Engineering：Simplifying Data and Product Integrations with a Data Abstraction Layer：https://www.uber.com/us/en/blog/data-abstraction-layer/
- LinkedIn Engineering：Semantic Search for AI Agents at Scale：https://www.linkedin.com/blog/engineering/ai/semantic-search-for-ai-agents-at-scale-retrieval-and-ranking-for-linkedins-hiring-assistant
- Capital One Tech：DataAgents: How we turned 9 months of analysis into 10 days：https://medium.com/capital-one-tech/dataagents-how-we-turned-9-months-of-analysis-into-10-days-8d6ed482f5d7
- John Kutay：Building an AI Database for Agentic GTM Operations：https://medium.com/@john.kutay/building-an-ai-database-for-agentic-gtm-operations-6a0c86fb8cdc
- Naidu Rongali：Why We Moved from Hive-Style Data Lakes to Apache Iceberg?：https://medium.com/@rongalinaidu/why-we-moved-from-hive-style-data-lakes-to-apache-iceberg-f9f23e7a64d3
- Kiran Pothina：Ship Fast, Break Nothing: dbt CI/CD, Monitoring, and Model Health：https://kiran-pothina.medium.com/ship-fast-break-nothing-dbt-ci-cd-monitoring-and-model-health-029d261a7a31
- Andreas Andreakis：Why DBLog Is Snapshot-Equivalent：https://aandreakis.com/posts/why-dblog-is-snapshot-equivalent
