datainfra前沿动态 · Vol.93

Databricks 给出 Lakebase Search 的容量规划曲线；预测式 AI 函数以五个 SQL 函数进入 Databricks；BigQuery 为生成式 AI 函数加上按 token 计费的日配额；Data Engineering Weekly 提出由编排引擎维护物理模型的自组织数据栈

本期聚焦四条把「靠经验兜住的隐性约束」改写成可测量规则的动作：向量检索的容量用缓存比与候选池两个旋钮定档，预测式分析从建模流程压成 SQL 函数调用，生成式 AI 的花费从账单回溯前移到配额拦截，数据栈的物理图从人画改成引擎维护。

DataInfra Databricks Lakebase 向量检索 BigQuery 生成式AI函数 成本治理 Data Engineering Weekly 数据编排 语义层 容量规划

本期四条动态集中在 10 月 14 日，来自两个厂商与一份行业周刊，做的是同一件事的四个版本：把原本由工程师凭经验判断的东西换成能测量、能声明、能复核的规则。Databricks 用一份公开的容量实测,把「Lakebase Search 该买多大」归结为缓存比与候选池两个旋钮；同一天它又发布五个预测式 AI 函数，把预测、归因、异常检测从建模流程压成一次函数调用；Google Cloud 把 BigQuery 生成式 AI 函数的成本控制从账单回溯前移成四条按 token 计费的日配额；Data Engineering Weekly 的长文则主张物理模型与依赖图不再由人画，改由编排引擎按「期望状态—观测状态」的落差持续重排。四处都不新增不确定性，只是把不确定性搬到能被看见的位置。

Databricks 用一份实测把 Lakebase Search 的容量问题归结为两个旋钮

事件概述

Lakebase Search 在 2026 年 9 月正式可用（本专栏 09-29 期报道过其发布与 IVF 分区、RaBitQ 量化的实现路径）。10 月 14 日，Databricks 补上了一份至今缺失的东西：把这套检索引擎放到一个真实内部应用和一个公开语料上，量化「该配多大的计算」。

真实应用是 Slide Hub，一个约 700 份内部演示文稿、23k 行幻灯片的内部检索应用，它的应用数据、投票、遥测、变更历史、预览图与两个索引都放在同一个 serverless Lakebase Postgres 实例里。公开语料是 MIRACL English，全量 32,893,221 条 passage，团队切出 1M、2M、4M 三个子集，用 Apache-2.0 的 gte-large-en-v1.5 生成 1024 维向量——自托管在单张 A10G 上每秒 379 条，全语料 2.95 GPU 小时，对应走 model serving endpoint 的 $48.87；GPU 产出的向量与 endpoint 向量平均余弦 1.0000、最低 0.9978。

结论里最有迁移价值的一条是：容量不是按行数算的，是按向量索引大小算的。Slide Hub 的 23k 行和 4M passage 的语料遵循同一条曲线，在 2M 上做的测试可以预测 4M 上的行为。

技术解析

  • 计量单位与缓存：Lakebase Postgres 以 Compute Unit（CU）计价，1 CU 约 2 GB 内存及配套的 CPU 与本地 SSD；自动伸缩范围是 0.5–64 CU，且最大值最多只能比最小值高 16 CU；固定规格最高 112 CU；32 CU 以下的计算可以缩容到零。最近读过的页放在 Local File Cache（LFC）里，最多可用掉计算内存的 75%，每 CU 约 1.6 GB。
  • 索引大小与缓存比：lakebase_ann 索引随语料线性增长——1M 是 5.8 GB、2M 是 11.5 GB、4M 是 23.0 GB。官方定义 cache ratio = 缓存大小 ÷ 向量索引大小，比值 1.0 表示索引刚好装下。8 CU 下用二进制 COPY 载入全部 4M 行耗时 19 分钟。
  • 命中率曲线（Zipf 偏斜负载）：ratio 0.07 时命中 45%，0.57 时 86%，1.14（索引刚好装下）时 97%。均匀负载低几个百分点，因为它不复用任何页。官方给的经验值是「缓存做到和索引差不多大，可以省掉 95%–98% 的存储读取」。
  • 延迟随缓存比塌陷：warm 向量 p50 从 ratio 0.07 的 187 ms 降到 ratio 2.3 的 4 ms；混合检索在 ratio 接近 1 之前一直停在约 800 ms，跨过之后掉到 33 ms。代价可以按页算——向量检索每 miss 一页约 252 微秒、混合检索约 316 微秒，官方概括为「一次 miss 约 0.3 ms」，miss 2000 页的查询多付约半秒。索引里一页装一到两条向量。
  • 冷查询才随语料变大：固定 cache ratio 接近 1.0 时，warm 向量延迟在 1M 到 4M 之间稳定在 11–23 ms，warm 混合检索稳定在约 276 ms；变慢的是从存储读的那些——冷向量查询从 1M 的 44 ms 涨到 4M 的 133 ms，冷混合查询在 4M 上到 911 ms。
  • 候选池是第二个旋钮：20 个公开查询下，40 / 100 / 200 / 1000 候选的冷延迟是 127 / 240 / 387 / 740 ms，首次触及 13 / 16 / 24 / 109 ms，重复查询 5.0 / 7.9 / 11.7 / 35.3 ms；触及页数 5655 / 7355 / 10401 / 28972；以 1000 候选为参照的 Top-10 重合度是 74.5% / 89% / 90.5% / 100%。Slide Hub 上线时用的是 1000，现在降到 200——保留 90.5% 的 Top-10、只读三分之一的页、冷延迟减半，官方文档示例则只取 40。
  • 召回与构建模式：4M 语料默认索引（109 probes）的 recall@10 是 0.74，耗时 3 ms；2000 probes 提到 0.95，耗时 49 ms。用 build_mode = 'quality' 重建后，默认 probes 下召回升到 0.80（3 ms），500 probes 就到 0.91（13 ms）——同样的召回在默认构建上需要 1000 probes 和 20 ms。代价是构建时间：4M passage 在 16 CU 上要 52 分钟。lakebase_ann.epsilon 提到测试能接受的最高值 4，只加不到 0.3 个百分点。
  • 瓶颈在数据库和 App 之间换手：500 用户压测下，1 CU 配 MEDIUM App（2 workers）是 196 req/s、p50 1.8 s；8 CU 同样配置升到 336 req/s、p50 1.0 s；16 CU 配 LARGE App（4 workers）至少 662 req/s、p50 343 ms。8 CU 之后 App 成为瓶颈——16 CU 配同样的 MEDIUM App 只多 4%，数据库连接大部分空闲。连接池同样关键：50 用户下无池 45 req/s、p95 2.4 s，加池后 85 req/s、p95 0.7 s。
  • 成本：1 CU-hour 是 0.213 DBU，按 AWS 美东目录价约 $0.085（Premium）/ $0.11（Enterprise）。一次 14 分钟的区域内压测花 $0.13，服务 109,602 次请求无错误。Lakebase 占 Slide Hub 30 天账单约 1%。官方推荐的生产基线是把最小值设为 0.5 CU 常开（约 $31–40 每月），省掉约 1 s 的计算唤醒与空缓存，dev/test 分支仍可缩到零。
  • 检索形态：Slide Hub 走混合检索，向量与 BM25 各取 200 候选，用 k=60 的 Reciprocal Rank Fusion 融合（每张幻灯片在两路的得分各是 1/(60 + rank)，相加）；向量侧加 0.70 的相似度门限，标题命中加权、笔记权重 0.5。官方称单个索引支持 10 亿以上向量。

行业影响

这份材料补上的正是存算分离检索一直缺的一环。存算分离把「节点无状态、可缩容到零」变成了卖点，代价是缓存命中率取代数据量成为性能的第一决定因素，而这个数字在买之前无从得知。Databricks 给出的不是一句「配大一点」，而是一条可迁移的换算：先量索引大小，再按想要的 cache ratio 选 CU，命中率从曲线上读出来。可迁移性来自 ratio 本身与语料规模无关——1M 到 4M 之间 warm 延迟几乎不动，这等于允许在小样本上做容量实验。

第二条影响落在容量规划的责任归属上。缓存比、候选池、probes、构建模式这四个旋钮里，前两个决定延迟，后两个决定召回，而官方明确「只在应用真的需要更高召回时才调 probes」。这把过去属于检索引擎内部实现的取舍摊到了应用侧，让「要多少召回、愿意付多少延迟」变成一个能写进需求的参数，而不必再靠换引擎来解决。文章也把边界写在明处：数字来自 MIRACL 与一个 23k 行的内部应用，10 亿向量的说法是产品上限而非实测。

相关链接

Databricks 把预测、归因与异常检测压成五个 SQL 函数

事件概述

10 月 14 日，Databricks 发布 Predictive AI Functions（Beta），一次给出五个 SQL 原生函数：升级后的 ai_forecast，加上全新的 ai_top_drivers、ai_detect_anomalies、ai_predict_value、ai_predict_class。作者是 Jonathan Brito 与 Gary Shambat。

官方把痛点描述得很直接：业务方反复问的三类问题——下季度销售额是多少、这个指标为什么动了、最近的数据是不是不正常——过去都得交给数据科学团队建模并管理基础设施，排不上队的问题干脆没人问。新函数把这些能力做成内置函数，背后由 Databricks 集中维护的模型支撑，分析师可以在 SQL 编辑器或 notebook 里直接调用，可以在 Genie 里用自然语言触发，也可以嵌进看板。官方称这些函数能在数亿行上运行。

值得注意的是发布时间上的巧合：两天前（10 月 12 日）Google Cloud 刚把 TimesFM 3.0 放进 BigQuery 的 AI.FORECAST（本专栏 10-13 期已报道）。两家在同一周把时间序列基础模型塞进了 SQL 层。

技术解析

  • ai_forecast 换了一代底座：新版由 transformer 架构的时间序列基础模型驱动，官方的类比是「像大语言模型在文本上预训练那样，在海量多样时间序列上预训练」，这让模型对季节性与趋势这类常见模式自带识别能力，官方声明「无需调参」。SQL 形态是表函数： 
    SELECT * FROM ai_forecast(
  TABLE(taxi_history),
  horizon => '2027-11-01',
  time_col => 'ds',
  value_col => 'trip_count',
  prediction_interval_width => 0.95,
  version => '2'
)
    version 参数用来锁定版本，prediction_interval_width 直接指定预测区间宽度。
  • 业务因素有两条入口：内置节假日支持自动处理圣诞下滑、开学季上扬这类本地事件；外部协变量允许把定价调整、市场投放这些驱动因素的序列喂进去。此前时间序列基础模型最常被诟病的一点正是无法接入业务侧已知的因果变量。
  • ai_detect_anomalies 自动拟合：传入观测表、时间列与值列，函数自己拟合模型并标出异常行，返回 is_anomaly 字段供过滤： 
    SELECT * FROM ai_detect_anomalies(
  observed  => TABLE(SELECT DATE(tpep_pickup_datetime) AS dt,
                            SUM(fare_amount) AS revenue
                     FROM samples.nyctaxi.trips GROUP BY dt),
  time_col  => 'dt',
  value_col => 'revenue'
) WHERE is_anomaly = TRUE
  • 另外三个函数的分工：ai_top_drivers 解释指标变化由哪些细分驱动，按绝对与相对影响排序；ai_predict_value 做回归、预测连续值；ai_predict_class 做分类、预测类别值，两者都可用于补缺失值。
  • Genie 侧的接入节奏不同步：ai_top_drivers 在 Genie 中已经可用，ai_forecast、ai_detect_anomalies、ai_predict_value、ai_predict_class 标注为 coming soon。官方给的理由是这些函数用的是定制化的机器学习方法，这让 Genie 能回答通用大模型单独处理不好的问题。
  • 基准口径：官方用 fev-bench 做对比，任务胜率定义为「按 scaled quantile loss 衡量、一方概率误差低于另一方的任务占比」，结论是新版 ai_forecast 优于其他云数据仓库提供的同类函数，也优于自己的上一版。文中只给了柱状图，没有列出逐项数值与参与对比的具体产品名。

行业影响

这条发布值得注意的不是「SQL 里能跑预测」——把 ARIMA、Prophet 包成 SQL 函数已经做过好几轮——而是维护责任的转移。过去一个预测任务一旦上线，模型版本、特征口径、重训节奏都由使用方的数据团队背着；现在这些由平台集中维护，团队拿到的是「跨看板、跨 SQL、跨 Genie 一致的结果」。一致性的代价是可控性：外部协变量与节假日支持只覆盖了业务因素里能被表达成序列的那一类，而模型的调参入口基本被拿走了。

与 BigQuery 的路线对比也能看出两家对同一件事的不同处理方式。BigQuery 把模型名暴露成参数（MODEL => 'TimesFM 3.0'），允许在模型之间切换与升级；Databricks 把模型隐藏在函数后面，只留一个 version 参数。前者给了可替换性，后者给了口径统一。对本专栏一直跟踪的那条主线——能力下沉到查询层之后治理怎么跟着下沉——这次两边给出的答案刚好相反，而 Databricks 同一天在 BigQuery 侧看到的是把配额做成一等公民（见下一条）。

相关链接

BigQuery 给生成式 AI 函数装上按 token 计费的日配额

事件概述

10 月 14 日，Google Cloud 宣布 BigQuery 生成式 AI 函数的 token 配额正式可用（GA），把这类按 token 计费的查询从「事后看账单」改成「事前设上限」。博文作者是 Tushar Jaiswal 与 Alicia Williams。

问题是被规模逼出来的：AI.GENERATE、AI.IF、AI.CLASSIFY、AI.SCORE 这类函数把大模型直接搬进 SQL，一条查询就能给数百万条工单分类或给每条商品评价打情感分。一旦跨上大数据集，账单的事后性就成了主要风险。新能力通过 Google Cloud IAM 的配额系统提供四条日配额，分项目级与项目内按用户级两个维度。

技术解析

  • 四条配额与默认值：输入 token 每日每项目 200 billion、每日每项目每用户 150 billion；输出 token（含 thinking token）每日每项目 20 billion、每日每项目每用户 15 billion。按用户级限额只在该项目内生效，不跨组织累加。
  • 两条容易漏掉的口径：配额是全局的——用量跨所有区域累加，费用不会在某个没盯着的区域悄悄堆高；输出配额包含推理 token，与 Gemini 平台的计费口径一致。
  • 覆盖范围：AI.GENERATE、AI.GENERATE_TABLE、AI.GENERATE_TEXT（含别名 ML.GENERATE_TEXT）、AI.CLASSIFY、AI.IF、AI.SCORE、AI.AGG 受配额约束。embedding 类函数 AI.GENERATE_EMBEDDING 与 AI.EMBED 明确不受约束，理由是它们跑在便宜得多的模型上。
  • 执行语义：查询启动时若所需配额已耗尽，直接以 QuotaExceeded 错误拒绝；若配额在查询运行中耗尽，BigQuery 停止发送新的 LLM 调用。支持 max_error_ratio 的函数（如 AI.IF）在未处理行处于该比例内时返回部分结果，超出则整体失败；通用函数（如 AI.GENERATE）仍然成功，被跳过的行没有生成值，其 status 字段写入 quota-exceeded 错误。
  • 与账单 spend cap 的分工：token 配额是预防性、AI 专用、按项目与按用户两级，BigQuery 在查询执行期间跟踪 token 用量并在接近上限时停手；Cloud Billing spend cap 是美元级、项目与服务级的财务兜底，执行不即时、会有一定的超支。官方建议前者作第一道防线，后者作项目级安全网。
  • 定额度之前先量一遍：AI.COUNT_TOKENS 返回模型 tokenizer 对一段文本产生的 token 数，且不下发任何计费的生成调用。官方明确它只是下界——不含输出与思考 token、不含各 AI 函数在输入外自行添加的指令包装、也不含图片等非文本输入。
  • 一个可复算的例子：以 Gemini 3.1 Flash-Lite 为例，BigQuery 走批处理有五折折扣，输入 $0.125/百万 token、输出（响应加推理）$0.75/百万 token。若一次小样本运行显示输入输出比约 100:1，则 0.125 × I + 0.75 × O = 100（单位百万 token）配上 I = 100 × O，解出每日约 754 million 输入 token 与 7.54 million 输出 token，把两条配额设成这两个值即可把项目日支出压在 $100 附近。
  • 运维路径：管理员在 IAM & Admin → Quotas & System Limits 里按 BigQuery API 过滤即可查看与调整，调低立即生效、无需审批，调高在同一页面申请（多数自动批准）。需要 Owner、Editor、Quota Administrator 或 Service Usage Admin 之一。也可以用 Cloud Quotas API、gcloud 与 Terraform 批量下发。该页面一并展示历史 token 消耗趋势，可选 7/14/30 天或自定义区间。官方建议先设按用户配额，防止单个用户或一次失控实验耗尽项目预算。
  • 相关的同日动作：10 月 14 日的发布说明里，AI.AGG 新增 output_schema 参数（GA，可指定输出 schema 的字段列表）；Dataform 的 preserveGovernanceControls 转 GA，可在多次执行之间保留表上的 BigQuery 数据策略与治理标签；BigQuery Conversational Analytics agent 可发布到 Gemini Enterprise（GA）。

行业影响

这条发布把生成式 AI 的成本控制放到了和计算槽位（slot reservation）相同的治理层级上。此前仓库里的 AI 函数只能靠两种粗糙手段兜底：限制谁能用，或者等账单出来再追责。配额系统给出的是第三种——在不禁止使用的前提下，把消耗量化成与业务单位（行数、工单条数）可换算的 token 数，并在执行路径上拦截。

对数据平台团队来说，真正的变化是「AI 函数的成本可以进容量计划了」。AI.COUNT_TOKENS 加上小样本运行，让一条新管道上线前的 token 预算有了一个可复算的估算方法，而不再依赖「先跑一周看看」。这恰好补上了过去两年 SQL 内 AI 函数推广中最缺的一环：能力先行、治理滞后。同一天 BigQuery 侧还把 AI.AGG 的输出 schema 固定下来、把 Dataform 的治理标签纳入跨执行保留，这三处改动指向同一个方向——让 AI 函数产出的东西在 schema、策略与花费上都可被事先声明。

相关链接

Data Engineering Weekly：把物理模型交给编排引擎维护

事件概述

10 月 14 日，Data Engineering Weekly 主编 Ananth Packkildurai 发表长文《The Self-Organizing Data Stack》，提出一套针对 Agent 时代的编排架构。文章对话的两篇前身是 Ian Macomber 的《The Post-AI Data Stack》与作者自己此前一篇《ETL to ECL (Extract, Contextualize, Link)》。

文章的起点是一个具体困境：今天的数据工程师做两份工作——决定该有哪些表，以及手工把编排引擎的调度、依赖、重试、回填接起来。一个月后来一个新需求，工程师要么花三天逆向别人的脆弱 DAG、承担下游静默损坏的风险，要么复制 SQL 新建一张表。理性的选择永远是后者。把这个生存本能乘上两百名工程师和三年，就得到现代数据仓库的高熵扩张：十几个版本的 customer_spend、没人敢重构的数千个模型、没人敢删的 PB 级僵尸表。编码 agent 的出现让情况更糟——它把生成新管道的成本压到接近零，却没改变底层的编排模型，重构已有管道的风险依旧极高。

提出的方案是：物理模型不再需要为人类的可理解性而塑形，也不由人手维护；依赖图从工程师画出的刚性输入，变成编排引擎持续维护的动态输出，按复用、成本与正确性三项随消费需求变化持续优化。人类保留的是定义、策略与判断。作者把这套设计命名为 self-organizing data stack。

技术解析

  • 资产是契约，不是表：在自组织栈里，asset 是一个有稳定身份的逻辑数据产品，声明自己的语义含义、粒度（grain）以及对每个下游消费者的 commitments。核心的结构性拆分是「资产保持身份不变，而物理实现可以改变」——契约属于资产，引擎拥有物理机制。这让平台可以持续重新接线而不强迫任何下游消费者改代码。
  • 引擎的五个循环：Synthesize（为新的请求建物理表与变换）、Consolidate（发现规格重叠时提议共享、拆分或合并底层工作）、Verify and Repair（在发布前拿下游契约测试每一次图变更或失败修复）、Coordinate（原子地激活带版本的变更，不打断任何在生效的消费者契约）、Escalate（语义歧义挡住进展时，带着证据与权衡向人类负责人提一个具体问题）。
  • 语义层是承重墙：引擎靠语义层解释意图——权威来源、实体键、单位、已批准的计算口径、时间规则。原则是「系统不能把对列名的合理猜测变成业务定义；含义缺失时上报一个开放问题，而不是在 SQL 里猜」。
  • 一个完整例子：销售应用要求 customer_spend_30d（每个客户一行、过去 30 个完整 UTC 自然日、用已批准的购买金额与客户身份定义、包含没有购买的客户、新源数据五分钟内反映）。planner 从语义层编译出正式规范并自动推导测试——「每客户一行」强制唯一性，「包含零消费客户」要求对客户注册表做 outer join，「已批准购买金额」提供对原始 ledger 的对账规则。一个月后支持 agent 要同一指标的 90 天版本。planner 发现两者 DNA 相同（同一 USD 购买定义、同一客户身份规则，且都是完整 UTC 日边界——滚动到当前秒的窗口无法共享聚合），于是提议一个带 90 天历史的共享中间层 customer_spend_daily，确认源历史存在、检查访问策略、回填日汇总，在其上建 90 天资产，并静默把已有的 30 天资产改接到新的日中间层。原文的那句话是：「任何资深工程师都能在十分钟内做完这个重构。重点是没有人必须做。」
  • 复用是带阻尼的：不同币种策略、客户定义、访问范围或财历的差异要求各自独立实现；「相似的列名和匹配的样本行永远不能证明等价，只有正式定义可以」。即便可以共享也有热力学成本——共享依赖会扩大失败爆炸半径，为满足一个实时消费者每五分钟刷新重型中间层会比跑两条独立管道更贵。planner 表现得像一个阻尼控制系统：测量真实计算成本、要求最低预期节省阈值才重组、限制单个资产的重构频率。
  • DAG 里外翻转：runtime 维护两份带版本的视图——Desired State（消费者已签约的结果与 SLA）与 Observed State（实际存在的实现、血缘、watermark 与健康状态）。新请求、失败的检查或过期的契约在两者之间打开落差时，引擎提出一次图变更（graph mutation）。调度从这些决策中涌现：源 watermark 推进时跑日汇总，UTC 午夜推进窗口视图。原文对 LLM 的定位写得很硬：「模型的置信度永远不能授权一次图变更。」
  • 对抗性验证：文中举了历史身份扇出（historical identity fan-out）的例子——客户身份源跟踪历史账户合并，已批准的归因规则要求用「购买时有效」的映射。若候选转换只用 account_id join，任何有两条历史映射的账户都会把每笔购买算两次，而 schema 检查、null 检查、聚合后主键唯一性检查会全部通过。自组织栈转而要求针对语义不变量（semantic invariants）做验证，并坚持「计算和测试出自同一个模型时，这个模型不能认证自己的假设」。
  • 原子切换与可追责的回滚：coordinator 把每次激活绑定到事务性注册表里的严格 revision number——staging 资产、校验测试期间契约没有漂移、原子翻转活跃指针（或跨独立存储后端做蓝绿迁移）。若缺陷仍漏过，恢复记录必须点名暴露窗口内读过坏数据的所有下游消费者，因为「回滚一张表无法撤销一个 agent 已经做出的动作」。
  • 决策即数据：每一次澄清、规范、提案、验证报告与部署都进不可变决策日志，构建在 W3C PROV 与 OpenLineage 这类标准之上。文中给出的示例记录把每个需求追溯到其出处（decision:d17、policy:approved_spending_semantics@4、message:m3），替代了过去由星型模型承担的「认知工作」。
  • 运维与代谢：图不是人画的时候，调试从 broken commitments 而非 failed tasks 开始；运维控制台依次回答四个问题（哪些承诺未满足、影响哪些消费者、哪些近期图变更触及了它们、引擎正在测试什么修复）。刹车有三档：冻结某域的重组、把资产钉在已知良好版本、用历史输入重放一次提案。栈还要有新陈代谢——按显式契约到期、合规保留策略与重建成本来退休资产，而不是只增不减（财务作业可能只在季末运行，清理动作不能只靠查询日志抓取来判断）。清理动作包括把物理表降级成虚拟视图、冻结计算但保留历史、或在最后一个共享依赖消失后彻底溶解中间表。

行业影响

这篇文章的价值不在它提出的系统已经存在——它并不存在——而在于它把「Agent 成为数据消费者之后，编排引擎的接口该是什么」这个问题拆成了可实现的五段。过去两年业界的默认答案是把 agent 接到现有的 DAG 工具上，让 agent 写 DAG；文章主张的是反过来：DAG 降级成一次性执行产物，持久的是资产、承诺与决策。这两条路的分歧点在于谁拥有图的作者权（graph authorship），而这个分歧会决定语义层、血缘标准与验证框架未来几年往哪边投入。

对平台团队来说，可立即执行的部分在文末的四条：把消费者承诺做成一等公民并与实现它的 SQL 分开存储；先投语义层再投 planner，因为引擎只能重组它能从正式定义证明等价的东西；建对抗性验证，绝不让 agent 给自己的工作打分；把决策当成数据来捕获。这四条不需要等到自组织引擎出现才有意义——它们也是让当前这套人工 DAG 能被 agent 安全改动的前置条件。文章也坦白了代价：把物理模型的作者权交出去，换回的是「每个需求都能追溯到谁授权了这个定义」，而决策日志从此成了必须长期维护的一等资产。

相关链接

编者评

把四条放在一起看，10 月 14 日这天发生的事情有一个共同的形状：AI 能力下沉到数据栈之后，那些原本靠工程师经验、部署文档与口头约定兜住的约束，被改写成能测量、能声明、能被机器执行的规则。Databricks 的容量实测把「检索集群该买多大」变成缓存比与候选池两个可计算的旋钮；预测式 AI 函数把「要不要为这个问题建个模型」变成 version => '2' 这样一个参数；BigQuery 的 token 配额把「AI 查询花了多少钱」从月度账单前移到执行路径上的 QuotaExceeded；自组织数据栈的主张则把「这张表为什么存在」从 SQL 文件里的隐含知识变成一条带出处的决策记录。

四处的效果都是把不确定性换个位置，而不是消灭它。缓存比仍然要靠自己量索引大小才知道；预测函数的内部口径被收走之后，业务侧能施加影响的只剩协变量与节假日两个入口；配额拦得住单日超支，拦不住一个低效 prompt 长期消耗预算；引擎接管图之后，人类要读的东西从 schema 换成了决策日志，而那份日志从现在起必须自己负责。前三条是厂商在自家产品里做的取舍，第四条是一位从业者为整个行业提的取舍清单，它们的共同点是都要求使用者先把自己那一侧的约束写清楚——写清楚索引多大、写清楚要什么召回、写清楚每天花多少、写清楚每个口径是谁批准的。

同一天 Databricks 还有一条没有单独立篇但与主线相关的发布：Document Intelligence 的解析、抽取、分类 REST API 转为正式可用（ai_parse_document、ai_extract、ai_classify 正式可用，做路由决策的 ai_decide 为 Beta）。它把非结构化文档进仓的路径从异步批处理改成了同步调用——上传即解析、解析即入库——与上面四条一样，是把一段过去由人排期的工作改成了可即时触发的接口。

本期的来源覆盖需要交代一处缺口：阿里云、火山引擎等中文来源的官方博客与产品更新页仍然无法抓取到可解析的条目列表，这已是连续第十二期。本期没有在国内厂商侧找到可核实的当日更新，改以 GitHub 上开源项目的发布记录作为间接观察——10 月 14 日前后，Apache Paimon、Doris、StarRocks、SeaTunnel、Amoro、Kyuubi、Linkis、InLong 等项目的发布记录均无新版本，ClickHouse 当日四个分支的补丁发布说明为空，LanceDB 仍停留在 v0.41.0-beta.6。这个缺口本身也是一个信号：国内数据基建的公开更新节奏目前仍集中在闭源产品与线下渠道。