Databricks Predictive AI Functions 将预测引入 SQL，但真正的考验在于可信度

Databricks 发布了五项处于 beta 阶段的 Predictive AI Functions，将预测及相关机器学习任务直接带入 SQL、仪表板和 Genie。该公司表示，分析师如今无需构建或维护单独的模型，也能回答预测性问题。这一承诺瞄准了长期存在的瓶颈，但也将责任从数据科学家转移到了平台及其用户身上。

此次发布包括升级后的 ai_forecast 函数和四项新函数，涵盖驱动因素分析、异常检测、数值预测和分类。因此，Databricks Predictive AI Functions 的应用范围不止于销售预测，还覆盖业务团队经常向数据部门提出的多类问题。

关键的冲突并非 Databricks 与某一家竞争性数据仓库之间的较量，而是自助式预测与传统模型开发流程之间的对立。Google BigQuery 和 Snowflake 已经让机器学习更贴近数据仓库用户，因此基于 SQL 的预测并非新鲜事。Databricks 押注于一组规模更小的托管函数，认为它们能够让常规分析工作也足以轻松使用预测能力。

这种便利也带来了更大的责任。预测可以顺利运行，却仍可能导致糟糕的业务决策。即便平台管理底层模型，团队仍必须理解数据质量、评估窗口、不确定性以及不断变化的市场条件。

Databricks Predictive AI Functions 将五项机器学习任务转化为 SQL

此次发布以五项托管函数替代了多种定制建模需求，分析师可以在自己原本就查看数据的地方调用这些函数。

Databricks 于 2026 年 10 月 14 日宣布推出 beta 版本。根据其 Predictive AI Functions 公告，这些函数可在 SQL、AI/BI 仪表板以及平台的对话式分析界面 Genie 中使用。

这五项函数分别解决不同的分析问题。ai_forecast 将时间序列预测至未来。ai_top_drivers 识别与某项指标变化相关的细分群体。ai_detect_anomalies 找出落在预期范围之外的观测值。

另外两项函数处理常见的预测任务。ai_predict_value 估计连续数值，例如需求量或交付时间。ai_predict_class 分配类别，例如可能的结果或客户细分。

Databricks 将每项函数定位为由集中维护的机器学习模型支持的原生 SQL 操作。分析师可以将输出置于查询和数据管道中，而非将数据导出至独立的建模环境。他们也可以通过仪表板展示结果，或让 Genie 通过自然语言问题调用这些函数。

这种部署位置很重要，因为许多预测需求都始于日常报表。一位高管看到收入图表后，会询问其接下来会如何变化；一位运营经理注意到某个峰值，想知道它是否异常；一位产品负责人看到转化率下降，便会询问是哪一细分群体推动了这一变化。

这些问题往往会变成数据科学团队的工单。团队需要定义目标、准备数据、选择方法、验证结果，并建立交付流程。一个只需几秒钟表达的需求，可能需要数天的技术工作。

Databricks 希望将这一路径压缩为一条查询。其示例使用纽约市出租车行程数据集来预测乘车量、识别异常观测值，并在现有分析界面中回答预测性问题。

升级后的 ai_forecast 使用预训练的、基于 Transformer 的时间序列基础模型。时间序列基础模型会先从众多数据集中学习重复出现的时间模式，再接收客户的特定序列。Databricks 表示，这种设计支持在无需针对具体任务调优模型的情况下进行预测。

该函数还接受可能改变预测结果的信息。节假日设置有助于表示反复出现的日历效应。外部协变量，即已知会影响目标的相关变量，可以包括促销、价格或营销支出。

这一组合使得此次发布的意义不止于在仪表板上方添加一个对话助手。这些函数针对受治理的数据执行分析操作，并返回可供其他 SQL 步骤使用的结构化输出。

不过，beta 标签仍然很重要。Databricks 正在引入一层托管预测能力，而不是宣告模型开发的终结。实际问题在于，标准化函数在哪些场景中表现足够好，能够取代定制项目。

直接压力落在分析和数据科学团队身上

Databricks 正在促使企业决定：哪些预测需求值得使用定制模型，哪些应成为分析师的日常工作。

数据科学家并不会从这一工作流中消失。他们的职责会转向评估、治理和复杂案例。如果托管函数能够处理重复性的预测任务，专业人员就可以减少为不同部门反复搭建类似管道所花费的时间。

这种变化也给分析工程师带来压力。他们可能需要负责生产查询，其中预测输出与数据转换和业务逻辑并存。这扩展了可靠数据产品的定义。

传统 SQL 检查会判断记录是否到达、列是否符合预期类型，以及转换是否计算正确。预测函数还需要额外测试。团队必须检查预测误差、预测区间、误报、漂移，以及不同业务细分中的表现。

业务分析师面临的是另一种压力。他们能更快获得预测结果，但也需要更好地判断模型输出意味着什么。结果出现在熟悉的图表旁边，并不代表它就可靠。

以季度销售预测为例。历史模式可能捕捉到季节性，但计划中的市场退出可能使这些模式失去意义。一项促销活动可能增加销量，却降低利润率。预测也可能遗漏输入数据中没有体现的突发供应限制。

外部协变量只有在团队正确选择并维护它们时才有帮助。它们必须同时适用于历史时期和预测期。一个与过去销售额高度相关的变量，未来可能无法获得，或根本无法知晓。

驱动因素分析带来了相关挑战。一项函数可以识别哪些细分群体对指标变化贡献最大，但这并不能自动证明这些群体导致了变化。贡献和因果关系回答的是不同的问题。

分类和数值预测也需要各自的保障措施。训练标签可能编码了旧有业务规则或不平等对待。对缺失值的预测可能看似精确，却掩盖了针对某一特定群体证据不足的问题。

因此，此次发布改变的是任务队列，而不是底层标准。简单直接的需求可以转向自助服务，而模糊或高影响的问题仍需专家审查。

这种划分应取决于后果。用于早期规划的粗略人员配置预测，与会改变信贷、医疗保健或就业决策的预测，风险并不相同。同样易于调用，并不意味着应采用同样的审批流程。

团队还需要明确所有权规则。必须有人决定哪些源表适用、如何监控输出，以及何时需要升级处理。缺少这一结构时，自助式预测可能会制造更多不一致的答案，而非消除瓶颈。

一种有用的运营模式是将探索与运营使用分开。分析师可以快速探索模式，再通过审查和测试将有价值的查询提升至更正式的使用阶段。这样既能保留速度，也不会把每一次临时预测都当作生产级证据。

此次发布也提高了人们对数据平台的期待。如果预测成为常规 SQL 的一部分，管理员就必须与传统查询一道治理访问权限、成本、血缘关系和可复现性。

对于消费这些结果的知识工作者而言，上下文仍然至关重要。缺少假设、源数据时期和评估历史的预测，很难受到质疑。团队可以使用可搜索的 knowledge base，让这些决策与分析保持关联。

托管预测正在挑战定制模型管道

核心竞争在于：即时、标准化的答案，与围绕单个组织具体问题构建但速度较慢的模型之间的较量。

定制预测管道提供控制力。数据科学家可以选择算法、设计特征、定义损失函数，并根据业务目标调优模型。他们还可以为稀疏数据、产品发布、结构性断点或特殊日历构建专门的处理方式。

这种灵活性需要付出代价。每增加一个模型，就会增加开发和维护工作。团队必须管理依赖项、计算环境、定期再训练、监控，以及用于交付结果的接口。

Databricks Predictive AI Functions 颠倒了这种权衡。平台选择并维护建模方法；用户提供数据和参数，然后通过熟悉的分析界面获得结果。

对于常见需求，标准化可能很有价值。多个部门可以使用同一托管实现，而不必分别委托开发不同版本。从仪表板调用的函数与通过 Genie 调用的同一函数，应遵循一致的分析路径。

集中维护也可以带来模型改进，而无需每位客户重建自己的管道。这一优势取决于 Databricks 是否能够保持行为稳定、记录变更，并向团队提供足够的信息以评估新版本。

预测函数说明了其运作机制。预训练模型先从广泛的时间序列集合中学习模式，随后便可以从一个新序列生成预测，而无需进行传统的逐数据集训练。

这种技术通常被称为零样本预测。“零样本”意味着模型将既有学习应用于目标序列，而无需专门针对该预测任务进行训练。

Databricks 表示，升级后的函数可自动识别季节性和趋势。它还支持节假日效应和协变量，用以处理通用历史模式可能遗漏的业务特定因素。

该公司使用 fev-bench 评估 ai_forecast，并报告称其任务胜率高于一家领先的云数据仓库及其先前的函数。fev evaluation library 支持可复现的预测任务、概率预测、协变量和多项误差指标。

Databricks 通过缩放分位数损失定义所报告的胜率。分位数损失会在不同概率水平上评估预测，并根据预测与观察结果之间的距离进行惩罚。缩放有助于比较单位不同的序列。

不过，发布文章没有提供足够的公开细节，无法将这一结果泛化到所有工作负载。读者需要了解确切的任务集、竞争对手配置、输入约束、模型版本以及完整的误差分布。仅有胜率并不能说明每次胜负的幅度。

这一差异至关重要，因为预测质量会因领域而异。一个模型可能在众多基准任务中表现出色，却仍会难以应对零售商生命周期短暂的商品或制造商的间歇性需求。

当业务目标不同于通用统计指标时，定制化流程仍具优势。库存团队可能更关注避免缺货，而非最小化平均预测误差。另一个团队则可能认为高估需求的成本更高。

托管函数仍可作为这些团队的基线。它能立即提供结果，供专业人员与定制方法进行比较。如果定制模型无法显著优于托管基线、以至于不足以证明其维护负担是合理的，那么标准化就会变得更有吸引力。

这是对这次发布最有力的解读。Databricks 并不是要取代所有预测建模，而是在提高数据仓库内部可用的最低能力门槛，并迫使定制项目证明其附加价值。

BigQuery 和 Snowflake 表明这是一场平台竞赛

Databricks 加入了一场更广泛的竞争：让机器学习像原生数据操作一样自然，而不是一个独立的软件项目。

Google 已经通过 SQL 将模型训练和推理引入 BigQuery。其平台涵盖预测、异常检测、回归、分类、贡献分析以及其他机器学习任务。

BigQuery 还提供由 TimesFM 支持的托管预测函数。Google 的内置 TimesFM文档说明，用户无需创建单独的模型即可进行单变量和多变量预测。

BigQuery 函数支持多个时间序列的标识符、预测区间、上下文窗口控制以及未来协变量。Google 也为需要更多控制能力的团队保留了传统的模型构建路径。

Snowflake 在其平台内提供预测和异常检测函数。其文档中的 GBM 异常模型会将观测值与预测进行比较，并使用梯度提升机识别异常值。

这些竞争性方案有着共同的重要方向：云数据平台希望客户能够在不将受治理数据迁移至独立技术栈的情况下完成分析、预测和行动。

差异将体现在模型质量、易用性、工作负载要求、集成能力和透明度上。团队应在不同平台上测试相同的业务时间序列，而不是根据某一家供应商的基准测试推断其优越性。

对于已使用其 SQL 仓库、仪表板和 Genie 的客户，Databricks 具备集成优势。同一个函数可以将对话式提问与可重复执行的 SQL 及可见的仪表板输出连接起来。

Google 可以强调 BigQuery ML 已较为成熟的一系列模型构建工作流。这些工作流让 SQL 从业者能够训练和评估多种模型类型，同时保留比单一托管函数更多的控制权。

Snowflake 也已将机器学习函数集成到其数据环境中。其异常检测工作流展示了仓库平台如何隐藏大部分模型开发过程，同时仍呈现分析输出。

结果并不是一份简单的功能清单。名为“预测”的函数，可能在可接受数据、上下文限制、缺失值处理、不确定性输出和解释变量支持方面存在差异。

治理层面同样重要。企业买家必须询问：管理员能否限制访问、将每项结果追溯到其数据，以及在服务发生变化后复现某项预测。

自然语言访问又增加了一个维度。Genie 可以让不编写 SQL 的人也能使用这些函数。这会扩大采用范围，但也可能向决策者隐藏重要的查询细节。

因此，对话式界面应展示生成的查询、所选列、筛选条件、时间范围和不确定性。否则，用户可能是在评估流畅的解释，而非实际的分析过程。

Databricks 认为，专用预测方法能让 Genie 回答通用语言模型无法可靠处理的问题。这一区分在原则上是成立的。语言模型生成文本，而预测需要与有序观测数据和评估指标绑定的数值方法。

不过，界面在调用正确方法之前仍可能误解请求。用户询问收入为何变化时，可能指的是区域贡献、价格-销量分解，或因果影响。这些分析并不能相互替代。

因此，这场平台竞赛将不止取决于让函数可以被调用。获胜的产品必须帮助用户提出正确的问题、检查计算过程，并识别结果何时不足以支持结论。

Beta 限制使验证成为产品的一部分

最大的未知数在于，自助式用户是否会以专家应用于定制模型的同等严谨程度来验证预测结果。

至少有一个函数已经存在明确的 Beta 限制。Databricks 文档称，ai_detect_anomalies 需要 Pro 或 Serverless SQL 仓库，并且需要加入 Predictive AI Functions 预览计划。

该函数会检查每个值之前的历史记录，估算预期范围，并分配异常分数。用户可以调整阈值，以控制何时为某一行标记异常。

其当前的异常检测限制包括：每个时间序列最多可输入 8,192 行。每个序列还需要唯一的时间戳，且一次调用只能分析一个数值列。

前八行用于提供历史上下文，不会产生常规异常输出。使用短时间序列的团队必须了解这会如何影响覆盖范围。

该函数还提供平滑功能，可将相邻的警报合并为一次异常事件。平滑可能让事件更易阅读，但也可能将短暂间隔内的正常值标记出来。

这些细节表明，“无需管理模型”并不意味着“无需做分析选择”。阈值、分组列、协变量、节假日和评分窗口都会影响结果。

误报会带来运营成本。一个将常规波动标记为异常的告警系统可能耗尽用户的精力。漏报则带来另一种风险，因为具有重要影响的变化可能在未经审查的情况下通过。

预测需要回测，即根据模型未见过的历史时期来评估预测。团队应测试多个预测跨度，因为七天的准确率并不能保证一个季度的准确率。

他们还应将托管模型与简单基线进行比较。上一周期的数值、季节性平均值和成熟的统计方法通常都能提供有用的参考点。复杂模型应通过改善相关结果来赢得信任。

预测区间值得关注。点预测给出一个预期值，而区间则传达一个合理范围。仅基于中点作出的决策可能造成虚假的确定性。

分层级评估同样重要。整体预测可能看似准确，因为高销量产品主导了指标。较小地区或新上市产品的表现仍可能很差。

数据泄漏是另一种危险。泄漏发生在模型接收到预测时本不可能获得的信息时。某个协变量在历史数据中看似有效，却可能让未来评估变得不切实际地容易。

驱动因素分析需要严谨的表述。排名靠前的细分市场可以解释某项变化在算术上的贡献，却不能证明客户行为为何发生变化。团队应将因果主张留给能够识别因果效应的设计。

分类输出也可能放大历史问题。如果标签反映了不一致的人类决策，自动化这些标签可能会以更大规模复制这种不一致。

模型更新会引入可复现性问题。集中维护的模型能够自动改进，但同一查询最终可能产生不同结果。企业需要为重要决策保留版本记录和变更通知。

Beta 阶段将揭示 Databricks 是否在这些函数周围提供了足够的评估工具。有价值的补充包括内置回测、基线比较、性能摘要和准确率恶化告警。

在此之前，团队应为运营用途附上一份简洁的模型卡。它应说明目标、数据窗口、预测范围、输入变量、已知局限性、验证方法和责任人。

这些文档不必拖慢实验进程。当输出进入规划、自动化行动或高管报告时，它们就变得必要。

简洁的 AI 工作流也可以保留假设与后续决策。目标是避免让一次临时预测变成未经记录的组织事实。

三个信号将表明这场押注是否奏效

接下来的考验不在于分析师能否调用这些函数，而在于组织是否会反复信任并将其输出投入运营。

第一个信号来自客户工作负载的证据。Databricks 展示过使用公开出租车数据的示例，并报告了基准比较。买家现在需要看到零售、金融、制造、软件及其他运营环境的公开结果。

最有力的证据将包括预测跨度、基线模型、不确定性校准，以及部署后误差的变化。它还应展示托管函数在哪些场景下失效。

广泛的客户证据将强化这样一种观点：一个统一维护的模型层可以服务多样化的业务问题。狭窄或经过高度筛选的示例则会削弱这一主张。

第二个信号是更深入的评估与治理支持。应关注运营查询周围是否出现原生回测、模型版本可见性、数据血缘、监控和审批控制。

这些能力将表明 Databricks 将预测视为不止是另一种 SQL 表达式。它们也会缩小快速分析与受治理生产流程之间的差距。

缺少评估工具会将更多工作重新转移给客户。即便模型训练本身变得更容易，这种结果仍会保留一部分原有瓶颈。

第三个信号是 BigQuery、Snowflake 及其他分析平台的回应。竞争供应商可以通过新函数、更强的基准测试、更好的对话式集成或更清晰的控制机制作出回应。

快速的竞争反应将证实托管预测 SQL 已成为核心数据平台类别。若各供应商的采用情况普遍疲弱，则意味着定制工具仍服务于大多数严肃的预测需求。

团队无需等待市场尘埃落定。他们可以从一个范围明确的用例开始，其中的决策可逆，且结果能够快速出现。

每周需求预测比多年战略预测更容易评估。由人工审查的异常告警，比自动改变客户访问权限的告警更安全。

先写下输出将支持的决策。然后，在比较结果之前定义基线、评估周期、误差容忍度和升级规则。

让托管函数在历史窗口上运行，并按细分市场记录表现。纳入预测区间，并检查最严重的失败案例，而不仅仅是平均分数。

如果该功能表现良好，就将其纳入现有仪表板，并清晰展示其假设条件。在团队了解结果如何随季节变化和异常事件而变化之前，仍应保留专家审核环节。

Databricks Predictive AI Functions 让高级分析更易于提出需求和部署。其长期价值将取决于团队是否也能让评估同样触手可及。

此次发布让分析师能够以更短的路径从数据得出预测。它也减少了此前迫使组织在将模型投入运营前暂停推进的一些阻力。这让严谨的审核变得更加重要，而非不再重要。

如今，哪个重复出现的问题正消耗你们数据团队的时间？选择一个问题，将托管结果与简单基线进行测试比较，并记录其成功与失败之处。这一对比将揭示 Databricks 是否消除了真正的瓶颈，还是仅仅将其转移到了下游。