Databricks 推出 ai_decide：在治理数据上做快速决策

Databricks 上线 ai_decide 决策函数

Databricks 近期发布了一款全新的 AI Function——ai_decide，主打在受治理（governed）的数据之上进行快速、可扩展的决策。这一函数延续了 Databricks 将大语言模型能力直接嵌入 SQL 与数据管道的思路，让数据团队无需搭建复杂的外部推理服务，就能在数据平台内部完成基于 AI 的判断逻辑。

从命名可以看出，ai_decide 的核心定位是"决策"，而非单纯的文本生成或分类。它试图解决一个常见的业务痛点：面对海量结构化与非结构化数据，如何用一致、可审计的方式做出规则化又带有语义理解的判断。

为什么要把决策放进数据平台

传统做法中，业务决策逻辑往往散落在应用层、脚本或人工审核环节，既难以规模化，也难以保证数据治理的一致性。把决策能力下沉到数据平台层，意味着判断过程能够直接复用平台已有的权限、血缘和审计机制。

对于强调"governed data"（受治理数据）的企业而言，这一点尤为关键。数据的访问控制、合规要求与可追溯性，都可以在同一套框架下延续到 AI 决策环节，避免因为引入外部模型服务而形成治理盲区。

与其他 AI Functions 的关系

ai_decide 并非孤立的功能，而是 Databricks AI Functions 家族的一员。此前 Databricks 已陆续提供文本摘要、分类、情感分析等内置 AI 函数，ai_decide 补上了"决策"这一环，让开发者可以用近乎写 SQL 的方式，把 AI 判断串联进现有的数据工作流。

Databricks AI Functions 是一套直接在 SQL 层调用大语言模型的内置函数体系，允许用户以 SELECT ai_summarize(text) 这样的形式在标准 SQL 查询中调用 AI 能力，底层依托 Databricks 托管的模型服务（Model Serving）运行。这一设计的核心优势在于：数据不必离开 Databricks 的安全边界，所有调用都通过 Unity Catalog 进行权限校验，并自动记录数据血缘。相比之下，传统方案需要将数据导出到外部 API 端点（如 OpenAI 或 Anthropic 的公共接口），在数据合规要求严格的行业（金融、医疗）中往往面临数据出境或隐私审计的障碍。

"数据治理"（Data Governance）在企业语境中通常涵盖三个核心维度：访问控制（谁能读写哪些数据）、数据血缘（数据从何而来、经过哪些加工）以及审计追踪（何时、由谁、因何原因访问或修改了数据）。Databricks 的 Unity Catalog 是其统一的元数据与治理层，负责在集群、工作区乃至云账号之间统一执行这些策略。当 AI 决策函数作为 SQL 算子运行时，每一次模型调用的输入与输出天然地纳入这套机制，监管部门或内部合规团队可以像审查普通数据操作一样审查 AI 决策行为，这在传统外部模型服务方案中几乎无法实现。

适用场景与价值

从产品定位推测，ai_decide 适合需要在数据流转过程中即时做出判断的场景，例如内容审核的通过与否、交易风险的分级、客户请求的自动路由等。这类任务既需要一定的语义理解能力，又要求处理速度和吞吐量。

把这类决策交给平台内置函数的最大好处，是降低了工程复杂度：团队不必单独维护模型服务、管理调用配额或处理数据出域的合规风险。决策结果也能天然地与下游的数据表、报表和管道对接。

结语

ai_decide 反映出数据平台厂商将 AI 能力"原生化"的趋势——不再把大模型当作外挂，而是作为数据处理链条中的标准算子。对于已经在使用 Databricks 治理数据的团队来说，这意味着可以用更低的门槛把 AI 决策纳入日常工作流。

需要提醒的是，本文基于官方发布的有限信息整理，关于 ai_decide 的具体性能指标、定价与支持的模型细节，仍需参考 Databricks 官方文档进一步确认。