Gemini Decision 和普通大模型做分类有什么区别？什么时候该用哪个

先说结论

谷歌 2026 年 11 月 11 日发布了 Gemini Decision（模型 ID gemini-decision-1）和配套的 Decisions API。它不是又一个更大的语言模型，而是一个只做判定、不写回答的模型：你把一段输入和最多 1000 个问题一起发过去，它一次就返回每个问题的概率和置信度，不产生任何输出 token。

代价是它只能判定，不能推理。要它解释「为什么判定为退款类」，它做不到；要它分三步先提取再归类再核对，也做不到。所以它不是一个「更便宜的替代品」，而是把一类特定工作从普通模型那里接管过来。

官方价每 100 万输入 token $0.10，输出不计费。

TeamoRouter 上还没有 gemini-decision-1。 它走的是独立接口 /v1beta/decisions，不是把 model 换成新名字就能用我们现有的接口调用，所以这里只讲怎么判断该不该用它、以及两者的差别。

Gemini Decision 到底做什么

官方文档（2026-11-11）里的规格：

三种题型：

• 是/否：返回 0.01 ~ 0.99 的校准概率，另附 confidence。
• 单选：给 2 ~ 255 个选项，返回最高项、每个选项的概率、confidence。
• 评分档：给 2 ~ 255 个有序档位，返回概率加权的期望分、每档概率、confidence。

「校准概率」是它和普通模型最大的区别之一。普通模型输出的「90% 确信」通常只是措辞，并不对应真实的命中率；校准过的概率才有意义，可以拿来直接设阈值，比如「概率低于 0.7 的自动转人工」。

用普通大模型做分类是什么样

现在的主流做法是：把提示词写好，要求模型按 JSON schema 输出一个结构化的判定结果。

from openai import OpenAI
import json

client = OpenAI(base_url="https://api.teamorouter.com/v1", api_key="你的 TeamoRouter API Key")

schema = {
    "type": "object",
    "properties": {
        "is_damaged": {"type": "boolean"},
        "category": {"type": "string", "enum": ["物流", "退款", "商品", "其他"]},
        "reason": {"type": "string"},
    },
    "required": ["is_damaged", "category", "reason"],
}

resp = client.chat.completions.create(
    model="gemini-4-argon",
    messages=[{
        "role": "user",
        "content": "判断这条客服消息：周一下单的蓝色马克杯周三到货时是碎的。",
    }],
    response_format={"type": "json_schema", "json_schema": {"name": "ticket", "schema": schema}},
)
print(json.loads(resp.choices[0].message.content))

这个路子能work，而且灵活：能输出 reason，能一次做多步判断，能自己决定先提取实体再分类。但它有三个结构性的成本：

1. 每题都要生成输出 token。10 个问题就是 10 份输出，1000 个问题就是 1000 份，按输出价格计费，题越多越贵。
2. 概率不是校准的。模型说「我有 90% 把握」往往不能直接当阈值用，得自己跑一遍标注集校准，或者干脆放弃概率、只看分类结果。
3. 延迟随问题数增长。每多一个问题就多一段生成时间，一批几千条的时候就明显了。

直接对比

那到底什么时候用哪个

按工作性质分，不按「新不新」分。

用普通大模型的场景

• 需要解释理由的审核。风控、内容审核、客服工单，人工复核的人要看模型为什么这么判。Decision 只给概率，给不出理由。
• 需要多步判断的任务。先读 PDF 提取金额，再判断是否超限，最后决定走哪条审批线。这种链式判断是 Decision 明确不做的。
• 需要多轮澄清。用户说得含糊，要追问一轮才能定性。
• 对话型分类。分类结果要接着触发一段回答，比如「判定为退款 → 生成退款指引」。

用 Gemini Decision 的场景

• 批量规则审核。一份合同、一张发票或一段对话，要同时过 30 条合规规则，每条都是一个是/否问题。用普通模型要发 30 次请求、付 30 份输出；用 Decision 是 1 次请求、1 份输入钱。
• 按评分标准给候选打分。比如给 200 份简历按 5 个维度打分，或者对一批回复按 4 档质量评分。评分档题型直接返回概率加权的期望分，不用自己换算。
• 实时媒体的低延迟分类。直播流、语音通话、视频帧，要求几十毫秒出结果且不能有生成延迟。零输出 token 在这类场景里是决定性的。
• 需要可直接设阈值的高流量分类。每天几十万条请求，靠校准概率设「低于 0.8 转人工」，而不是每条都人工看。

官方的用例清单也印证这个分界：请求路由、一次过很多条规则做策略检查、按评分标准给候选打分、工具选择、对实时媒体做低延迟分类。这五件事的共同点是判定本身就有价值，不需要再写一段话。

反过来说，官方也写得很清楚它不适合什么：多步推理。这是设计取舍，不是还没做好。

一个实际的判断方法

拿你现有的分类任务，先回答三个问题：

1. 每个问题需不需要输出一段文字？ 需要 → 普通模型。不需要 → 继续问。
2. 一批输入要问几个问题？ 只有一两个 → 普通模型够用，没必要换接口。几十上百 → Decision 的成本优势开始明显。
3. 概率要不要直接当阈值用？ 要 → Decision 的校准概率是现成可用的；不要 → 概率优势用不上。

三个答案都指向 Decision，才值得为它接一个新接口。

常见问题

Gemini Decision 是 Gemini 4 的某个版本吗？ 不是。gemini-decision-1 是独立的模型 ID，专门配合 Decisions API 使用，不能通过 :generateContent 调用。

它能替代 Gemini 4 Carbon 吗？ 不能。Carbon 是做推理和生成的，Decision 只做判定。两者解决的完全不是同一件事。

为什么它输出 token 是 0 还能返回结果？ 它的输出来自一次 prefill 里算出的概率分布，而不是逐 token 生成文本。所以有概率，没有文字。

在 TeamoRouter 上什么时候能用？ 现在还没有上架。它需要接新的 /v1beta/decisions 接口，不是改个模型名就行。上架后会在价格页出现对应条目。

输入重复发会不会重复计费？ 会。它不支持上下文缓存，跨请求的重复输入每次都按全量算。所以要么一次请求里把所有问题问完，要么自己去重。

相关阅读

• Gemini 4 Carbon API：同为谷歌新模型，但做的是推理和生成
• Gemini 4 Argon API：Gemini 4 系列第一个模型，结构化输出示例见这里
• Qwen 3.8 Flash 和 Max 怎么选：同样按成本和准确率选分类模型的一个实操例子