决策模型进了数仓，最该借鉴的是它的问法

Snowflake 10 月 19 日发布了低延迟决策模型 Decision Fast，目前是私有预览。¹决策模型不写文章：你给它一段内容和几道选项事先定好的题，它直接返回答案和每个选项的概率。两周前，同系列、偏批量的 Snowflake Decision 已经进入 Cortex AI Functions。²Snowflake 称演示中一次调用往返在 300 毫秒以内，但没给测试条件，也没公布价格和模型规模。¹

我认为最值得借鉴的是它的问法，速度倒在其次：把判断写成有固定选项的题，答案带着概率直接落进表里。调用就是一句 SQL：在 AI_COMPLETE 里填上模型名，整张表逐行判断，答案是结果里的一列。¹Databricks 走的是同一条路：SQL 里有 ai_decide，网关上开放了 TypeSafe 的 System One 接口，请求格式和 Snowflake 几乎一样。⁵（Snowflake 的 Python 示例也用 TypeSafe 的 SDK，但没说模型由谁训练。¹）

先把问题写成类型，答案就能直接落进一列

题型把答案限死在合法选项里，所以结果可以直接当一列用。一次请求有两部分：state 是要判断的内容，比如工单正文；questions 是几道带类型的题。¹题有三种：²⁵

是非题（接口里叫 noul）：返回“是”的概率，落表就是一个 0 到 1 的数值列。
单选题：选出一个选项，并附上每个选项的概率，落表就是一个枚举列。
打分题：按有序等级打分，返回加权分数和每一级的概率。

演示里，一张工单只调用一次，就同时得到交给谁、有多急、客户情绪三个判断。¹

对比通用大模型：它返回一段文字，要先解析成 JSON，失败了还得重试；表一大，失败的行就是一批要补跑的数据。决策模型的答案本身带类型，Snowflake 说应用不再需要解析器和重试循环。¹

概率是这套设计的出口：有把握的直接用，没把握的交出去

概率决定答案能不能直接用：设一个阈值，高于阈值的直接执行，低于的交给大模型或人工。Snowflake 的例子里，路由到 Billing 的概率是 0.99，可以直接拿来和阈值比。¹Decision 的发布文章还建议先让决策模型判断一个请求难不难，难的交给大模型，其余走便宜的路径。²不过这只是设计建议，没有数据支撑，阈值和转交流程要自己搭。

FIG.1Decision Fast 的核心设计：问题写成类型，答案带着概率回来，按概率分流。分流和回流是使用方要自己搭的部分。

我在 d1 那篇里主张按置信度分流，在 OpenJev 那篇里批评过网关把概率压成“拦”或“放”两档。Snowflake 把概率原样放进 SQL 结果，²分流就是一个 WHERE 条件；概率和结论一起落表，事后还能查到每个判断当时有多大把握。

快慢两档，按等不等得起来选

选哪一档，只看结果要不要马上用。整张表跑、可以等的，用 snowflake-decision，比如评论分类、工单归队、AI 回答质检。²用户在等结果的，用 snowflake-decision-fast，比如用户还在填工单时就判断去向和紧急程度、实时风控初筛、agent 的第一步分流。¹Snowflake 文档也这样划分：大表走批量，对延迟敏感的交互走 REST API。³两档的准确率和速度差多少，官方没给数字。¹

FIG.2按两件事选位置：答案是不是有限的几个选项，结果要不要马上用。

摘要、开放推理、自由抽取这类开放任务，Snowflake 自己说不适合决策模型，²仍交给通用大模型。金额、指标口径这类必须算准的数，我主张留给固定的 SQL 和代码。

省钱最多的位置在大模型前面

按回报从高到低，有三个位置。

**第一，挡在大模型前面分流，省的是最贵的调用。**假设一条管道每天 100 万条请求原本全交给大模型，如果决策模型能高置信度地处理其中 80%，大模型调用就降到每天 20 万次。这个 80% 是假设，要在自己的数据上量。

**第二，批量打标签，省的是输出 token 和重试。**AI_COMPLETE 的输入和输出 token 都计费，仓库费用另算。⁴决策模型只答题不写字：Databricks 的示例一次问三道题，输入 238 个 token，输出 0 个。⁵大模型要写 JSON、常附理由，这些输出都要付钱，解析失败还要重跑。Decision 还没定价，具体省多少暂时算不出。

**第三，在线判断，换来的是不用让用户等。**300 毫秒以内，判断就能放进用户正在等的流程里，比如工单一提交就分到对的队列。但这是演示数字，没有负载条件，也没有 p95（95% 的请求在多长时间内返回），上线前要自己压测。

照搬之前先做三件事

列出数仓里现有的判断：CASE WHEN、关键词规则、人工打标。答案是有限选项的，都是候选。
在自己的数据上量错误率，乘以每天的调用量，看业务能不能接受。
把概率、模型名和题目版本跟结论一起落表。Snowflake 说接下来几个月模型会快速更新；¹模型一换，同一行可能得到不同答案，没有版本记录就说不清当时为什么这样判。

把判断写成有类型的题，让答案带着概率回来，这就是决策模型带进数仓的问法。用得好不好，看三件事：阈值设在哪、没把握的交给谁、落表的判断能不能追溯。