Databricks ai_decide 将受治理数据从分析推向行动

Databricks 于 9 月 30 日推出 Databricks ai_decide，新增了一项处于测试阶段的 SQL 函数，可将受治理的数据转化为概率、选择和评分。矛盾随即显现：企业希望以数据的速度获得 AI 辅助决策，但运营决策所需的问责性高于普通文本生成。

这项新函数会依据用户提供的评分标准，对结构化记录或文本进行评估。它可以估计某一事件是否需要关注、在指定结果中做出选择，或按有序量表为案例评分。这些输出随后可供另一项 SQL 查询、工作流或应用程序使用。

这让此次发布的重要性超过了又一个模型端点。Databricks 正将基于模型的判断嵌入数据工作流之中，团队已在这里管理表、权限、管道和业务逻辑。Google Cloud 在 BigQuery 中提供了相关的生成式函数，而通用模型 API 则允许开发者手动构建类似系统。如今的竞争在于，谁能在不掩盖不确定性的前提下，让概率性决策真正投入运营。

Databricks ai_decide 通过一次 SQL 调用完成多项决策

关键变化不在于 Databricks 能从 SQL 调用模型，而在于一个受治理的函数能够围绕同一条记录返回多项可直接用于决策的评估结果。

根据该公司的发布文章，Databricks ai_decide 面向基于受治理企业数据的快速决策。该函数属于公司更广泛的、面向特定任务的 AI Functions 系列。

其语法包含三个部分：状态、一组问题，以及可选的版本设置。状态包含正在评估的证据，可以是普通文本、JSON 编码对象、JSON 数组，或由另一项 AI Function 生成的 VARIANT。

问题在一次调用中定义一次，并应用于每一条输入行。每个问题均包含说明和响应类型。某些类型还要求提供描述可选结果的标准。

函数参考文档列出了三种响应类型：

• noul 估计某项陈述为真的概率，返回 0 到 1 之间的数值。

• choice 从最多 255 个具名标准中选择一个标签，并返回每个标签的概率。

• score 根据包含 2 到 10 项标准的有序量表对输入进行评估。

不常见的术语 noul 指的是概率性的“是或否”评估。该函数并不强制给出布尔答案，而是报告估计的可能性。当下游系统需要阈值判断而非绝对断言时，这一区别至关重要。

例如，支持团队可以询问某个工单是否需要立即升级处理，也可以询问应由哪个团队负责该案例，以及情况看起来有多紧急。这三项评估均可将同一份工单作为证据。

结果为一个包含响应、元数据和错误字段的 VARIANT。VARIANT 是一种用于半结构化值的灵活数据类型，例如嵌套 JSON。成功调用会标识函数版本，而失败调用则可能返回错误说明。

对于选择类问题，输出包含选中的标签、每个可能标签的概率以及置信度值。评分问题则包含数值分数、原始量表描述、概率和置信度。

这种设计让分析人员获得的信息多于单一生成标签。工作流可以自动接受高置信度决策，将不确定案例转交人工处理，并记录概率分布以供后续审查。

Databricks 还警告，生成的答案可能会因调用而异。这句话很容易被忽视，却界定了核心运营挑战。SQL 语法让该函数易于使用和组合，但不会让底层判断变得确定无疑。

受治理的 AI 决策让数据团队承压

Databricks ai_decide 迫使数据团队将模型判断视为生产逻辑，而不是从聊天机器人复制出来的实验性输出。

许多企业决策本就始于数据仓库或湖仓。支持工单、产品列表、保险文件、事件报告、申请资料和交易记录，最终都会成为由管道处理的数据行。

当决策可以写成精确规则时，传统 SQL 表现出色。超过固定金额的交易可以进入审核队列；带有已知错误代码的工单可以被分配给特定团队。

更棘手的案例取决于语义。客户可能在未使用公司官方事件术语的情况下描述服务中断；产品列表可能暗示适用性，却不符合受控分类体系；一个案例也可能同时满足多项相互竞争的优先级。

组织通常通过人工队列或外部模型服务来处理这类情况。人工审核可能很慢，外部服务则会引入额外的代码、数据传输、凭据、监控和治理工作。

Databricks ai_decide 压缩了这一路径。团队可以在数据旁表达定性评分标准，并在 SQL 中获得结构化评估。这些评估随后可参与筛选、连接、仪表板、Lakeflow 管道、Workflows 或应用逻辑。

更广泛的AI Functions 概览介绍了用于文档解析、提取、分类、搜索准备及其他转换的内置函数。Databricks ai_decide 则在这些准备步骤之后增加了一层明确的决策能力。

以文档工作流为例，ai_parse_document 可以将上传文档转换为结构化内容，ai_extract 可以识别指定字段，Databricks ai_decide 随后可依据业务评分标准评估产生的 VARIANT。

这一流程改变了谁能够构建工作流。数据工程师不再需要将每项决策都封装为自定义服务。分析人员可以借助熟悉的数据工具检查状态、标准、答案、概率和错误。

它也改变了谁需要承担责任。一旦由 AI 生成的评分控制分流或优先级排序，数据团队负责的就不只是查询性能，还必须帮助定义可接受的错误率、升级阈值、监控规则和回退行为。

治理成为产品设计的一部分。Databricks 表示，文档数据会保留在其安全边界内。该公司称不会存储传入 AI Function 调用的参数，但会保留运行元数据，例如运行时版本。

访问权限并不会自动收窄。Databricks 文档称，启用相关预览功能后，用户默认会获得 system.ai schema 的 EXECUTE 权限。管理员必须先移除该 schema 级权限，才能向选定函数或群组授予访问权。

这些访问控制本身仍处于公开预览阶段，并且需要启用。它们适用于 system.ai 下的面向特定任务的函数，但不管理通用的 ai_query 函数。

这一边界很重要。企业不能假定启用一种治理机制就能覆盖所有通向模型的路径。管理员需要为面向特定任务的 AI Functions 和直接 Model Serving 调用分别制定策略。

因此，此次发布同时给平台负责人、安全团队和运营领导者带来压力。平台负责人必须确保函数可靠，安全团队必须有意识地配置访问权限，业务领导者则必须界定概率性自动化可被接受的场景。

结构化评分标准才是真正的机制

核心机制是从开放式提示转向具备结构化不确定性的明确评分标准。

通用模型提示可以问：“我们该如何处理这个案例？”回答或许表达流畅，但另一个系统仍需对其进行解析。模型也可能虚构类别、改变格式，或在未生成可靠字段的情况下解释其决定。

Databricks ai_decide 收窄了这种交互。开发者定义具名问题、说明和允许的标准，函数则返回具有可预测结构的响应，供下游 SQL 调用。

这种约束减少了集成工作，也让审核人员能够看到决策契约。合规专家可以审查升级处理的定义，运营经理可以检查类别描述，数据工程师可以验证概率如何转化为工作流动作。

选择类型展示了这一方法。假设某支持组织将配送、账单和技术支持定义为仅有的分流标签，函数必须从这些名称中选择，并返回每一个标签的概率。

选中的标签很有用，但概率分布可能提供更多信息。账单与技术支持之间概率接近的结果表明存在歧义。工作流可以将该案例发送至通用队列，而不是假装最高概率标签已经确定无疑。

评分类型使用有序标准，而非自由形式的数值。团队可以定义三个紧急程度级别，从常规请求到关键阻塞问题。返回的分数是标准索引的概率加权平均值。

这种方法保留了相互竞争评估的信息。如果模型将概率分配到多个级别，结果可以是小数。输出还会保留评分图例以及支撑分数的概率。

多个问题可以共享同一个状态。这减少了为类别、紧急程度、升级处理及其他判断分别通过不同提示传递相同证据的需要，也让相关答案保持在一起。

但共享输入并不能保证每个问题都代表独立评估。团队应测试说明是否会以意外方式相互影响，也应验证合并问题是否会改变其工作负载的质量、延迟或成本。

Databricks 表示，如果另一模型在其内部基准测试中表现更佳，底层模型可能会发生变化。当前文档将可能使用的模型与 Apache 2.0 许可证关联，并要求客户参阅适用的模型条款。

托管式模型选择减少了配置工作，但也意味着函数行为可能在稳定的 SQL 接口之下持续演变。版本元数据有助于识别函数契约，但团队仍需基于具有代表性的数据进行回归测试。

这正是该机制在运营层面变得重要的地方。由确定性条件构成的存储过程可以针对精确预期输出进行测试；概率性函数则需要分布检查、阈值检查和重复评估。

团队应为每项重要评分标准维护带标签的评估集。这些评估集应包含常见示例、边界案例、缺失证据、相互冲突的证据，以及始终应交由人工处理的输入。

他们还应将建议与执行分离。决策函数可以以有限的下行风险为支持队列排序优先级；同样的置信度不应自动授权退款、拒绝申请人、暂停账户或启动安全响应。

SQL 接口让组合变得容易。良好的系统设计必须让具有重大后果的行动始终保持审慎而难以自动执行。

Databricks ai_decide 与通用模型调用及数仓 AI 展开竞争

核心竞争在于：任务专用的托管函数，与围绕通用模型端点构建决策逻辑的灵活性之间的取舍。

Databricks 已提供 ai_query，这是一项调用 Model Serving 端点的通用函数。开发者可以选择受支持的模型，编写自己的提示词，并控制参数和返回类型。

ai_query 文档建议，团队在任务目标与某项任务专用 AI Function 相匹配时，应优先从该函数开始。文档将 ai_query 定位为需要更精细控制模型、提示词、参数或输出的场景。

这一区别形成了明确的权衡。

任务专用函数可减少配置工作，并提供结构化契约。Databricks 管理操作背后的系统，并可持续改进其实现。团队则可专注于自身的证据、问题与判断标准。

通用模型调用提供更高灵活性。开发者可以使用自定义模型，调整解码设置，定义不同的 schema，实现备用端点，或固定特定模型版本。但这也意味着需要承担更多工程和评估工作。

当一项决策可归入其提供的三种形式时，Databricks ai_decide 最具优势。概率、命名选项和有序评分覆盖了许多路由与优先级排序任务，但并不能涵盖所有决策结构。

企业可能需要多标签分类、受约束的数值估计、证据引用、基于规则的排除条件，或一连串相互依赖的问题。在这些场景中，开发者仍可能需要 ai_query、自定义函数或外部应用程序。

竞争范围也不限于 Databricks。Google Cloud 为 BigQuery 提供了 AI.GENERATE_BOOL 函数，可返回布尔结果、响应详情和状态信息。它可通过 Gemini 处理文本和被引用的非结构化内容。

Google 的布尔函数支持模型和请求参数。其文档也警告称，提示词设计会影响结果，而查询规划可能使模型推理处理的行数超出预期。

Google 还单独提供 AI.IF，其文档称该功能支持提示词优化及优化模式。该模式可训练蒸馏模型，以在大规模使用时降低成本和延迟。

Databricks 在一次调用中采用了更广泛、以评估标准为导向的方法。Databricks ai_decide 可以回答多个问题，并为命名选项或有序评分返回概率。Google 已文档化的布尔函数则侧重于真或假的生成，尽管 BigQuery 还提供其他标量和生成式函数。

两种方案都无法取代应用设计。数仓原生 AI 缩短了数据与推理之间的距离，但团队仍需选择阈值、物化输入、控制权限并评估输出。

因此，竞争将取决于运营层面的证据，而不仅仅是语法。采购方需要了解这些函数在其自身记录、所在区域、合规要求及生产规模下的实际表现。

一项能够节省集成工作、却带来不可预测成本的函数将难以成功。同样，一个要求专业团队为每项常规分类任务投入精力的灵活端点，也会面临困境。

Databricks 押注于这样一种判断：许多企业决策具有足够相似的结构，值得由托管原语来处理。结果取决于，当组织将这些原语连接到真实行动时，它们是否仍然易于理解。

快速决策仍需要缓慢验证

Beta 标签是最明确的警示：Databricks 简化了实施过程，但并未消除不确定性、区域限制或人工问责。

Databricks ai_decide 目前以 beta 功能形式提供。工作区管理员可通过 Previews 页面控制访问权限，该函数仅在受支持地区可用。

它无法在 Databricks SQL Classic 上运行。文档要求使用 Databricks Runtime 15.4 LTS 或更高版本，并建议使用 Runtime 18.2 或更高版本，以获得当前功能和性能。

这些前提条件限制了即时采用。使用旧版运行时、Classic 数仓、不受支持地区，或严格预览策略的组织，必须升级基础设施或等待后续支持。

模型层还引入了另一项不确定性。Databricks 表示，当内部基准测试发现更优选项时，可能会更换底层模型。这种托管式演进可以改善结果，但从客户视角看，也会带来模型漂移。

决策管道不能仅依赖函数名称保持不变。团队需要建立基准评估、发布控制、受监控的阈值，并能够在平台变化后比较结果。

评估标准本身也可能失效。指令可能遗漏重要例外，类别之间可能重叠，有序量表也可能制造证据并不支持的精确感。

置信度需要谨慎解读。较高的置信度字段表示，在该函数的处理流程下，当前状态对该评估的支持程度。它并不证明答案在事实层面正确或公平。

概率输出也存在类似风险。0.9 的数值看似精确，但如果没有校准证据，用户不应假设 90% 的同类预测都会正确。校准必须在组织自身带标签的案例上进行测试。

数据质量仍然至关重要。如果状态中包含过时、不完整或误导性的记录，即使评估标准结构良好，也可能产生糟糕的决策。治理控制谁可以使用数据，但无法保证每项输入都适用。

偏见也可能通过示例和标准进入系统。类别描述可能编码了团队的历史实践，包括其中的盲点。评分可能复现评估集里不一致的人类判断。

高影响场景需要更强的保障措施。就业、信贷、医疗保健、保险、法律和安全决策所涉及的责任，远不止一项模型输出。组织应在自动化行动前让业务领域、法务、安全和风险团队参与其中。

即使是较低风险的工作流也需要失败处理机制。该函数可能返回空响应和错误信息。管道必须决定是重试、暂停、采用确定性的备用逻辑，还是将案例转交给人工处理。

根据文档，生成的答案可能在不同调用之间有所变化。因此，重复评估可能对边缘记录给出不同标签或评分。当下游行动只能发生一次时，团队需要制定幂等性策略。

成本同样值得仔细审查。每次由模型支持的评估都会消耗推理资源。若对大型表的每一行运行多个问题，一项便捷查询可能迅速变成昂贵操作。

开发者应在调用函数前筛选相关行，物化稳定的输入集合，防止意外重新评估整张表，并在重复推理不增加价值时存储输出。

这些问题并不会否定产品方向。它们说明，受治理的 AI 决策需要比生成式摘要更高的标准。糟糕的摘要只会给读者带来不便；糟糕的路由或优先级决策则会改变接下来发生的事情。

三个信号将揭示这场押注是否奏效

接下来的考验在于，Databricks 能否将一个有前景的 SQL 抽象转化为可衡量、可治理的生产能力。

第一个信号是有文档支持的评估表现。Databricks 尚未提供独立基准测试，以证明其在代表性决策任务中的准确率、校准度、延迟或成本。客户需要与自身工作负载相关的证据，而非笼统的速度承诺。

有价值的验证应将 Databricks ai_decide 与 ai_query、确定性规则和成熟的人工审查进行比较。它应衡量标签准确率、概率校准度、重复调用的一致性、处理时间，以及需要升级处理的案例数量。

如果团队能够以受控错误率发布可重复的收益，任务专用方案就会获得可信度。如果他们必须为每次调用包裹大量修正逻辑，这一抽象节省的工作量就会低于其语法所暗示的程度。

第二个信号是更广泛的生产可用性。该功能目前仍带有 beta 标签，需要启用预览，无法用于 Classic SQL 数仓，并且只支持部分地区。

向更广泛可用性迈进，将表明 Databricks 对服务可靠性、治理覆盖范围和运营支持抱有信心。持续的预览限制则会使该函数局限于实验和低风险工作流。

治理成熟度也属于同一信号。管理员需要对执行权限、模型访问、审计轨迹、区域处理以及底层模型变更拥有清晰控制。这些控制必须能在不同云平台和工作区配置中保持一致。

第三个信号是客户在演示之外的实际使用。产品分类和支持工单路由都是易于理解的示例。更有力的证据将来自设有公开审查阈值、且具备可衡量业务成果的生产工作流。

应关注概率是否改变工作流，而不仅仅是为仪表盘增添装饰。一家公司可能自动处理明确的决策，将模糊记录发送给专家，并利用由此产生的修正来测试其评估标准。

还应关注竞争对手。Google Cloud 已经提供数仓原生生成式函数，其他数据平台也在持续将模型访问能力部署到受治理数据附近。若竞争函数提供更清晰的校准能力、更广泛的输入支持或更低的运营开销，就会削弱 Databricks 的优势。

Databricks ai_decide 抓住了一项重要转变。企业已不再满足于只能描述信息的模型。它们希望系统能够协助选择、排序、路由和升级处理，同时仍处于既有数据控制体系之内。

审慎的下一步不是将该函数直接连接到具有重大后果的行动。应选择一个范围明确的队列，定义清晰的评估标准，并建立带标签的评估集。将函数输出与现有决策进行比较，然后设定自动化和人工审查的阈值。分别跟踪错误、不确定性、延迟和漂移。

在你的组织中，哪项决策既足够重复，值得评估，又足够可逆，能够安全测试？这才是 Databricks ai_decide 的正确起点。该产品的长期价值将来自透明的运营纪律，而不是将概率输出视为确定性。