大语言模型

Google 把「判断」做成了一个模型：一次请求问 1000 个问题，输出 token 永远为 0

2026年11月13日2 次阅读
Google 把「判断」做成了一个模型：一次请求问 1000 个问题，输出 token 永远为 0

3分钟看懂：Google 把「做判断」从聊天模型里拆出来，单独卖

Gemini Decisions API 是 Google 在 11 月 11 日上线的一个新接口，背后是一个新模型 gemini-decision-1。它不写文章、不聊天、不解释理由，只回答一件事：在你给定的几个选项里，哪个最可能对，以及这个判断有多可信。

换句话说，平常我们让模型「回答一个问题」，它要先想、再一个 token 一个 token 往外吐字，然后我们再写正则或 JSON 解析去读它的答案。Decisions API 把这一步省掉了：输入一次，直接返回概率，输出 token 永远是 0。

对做 Agent 的人来说，这是最耗时也最不容易做稳的一跳——该走哪个模型、这条内容违不违规、这个候选人排第几、这个工单属于哪个部门。以前这些活要么训一个小分类器，要么拿大模型硬生成再解析。现在 Google 说：这类闭集判断，可以当成一种独立的模型能力来调用。

它到底怎么工作：一次共享输入，最多 1000 个问题

一次请求由两部分组成。

  • 共享输入：一段文本，或者图片、音频、视频、PDF，合计上限 262,144 token。所有问题都对着这同一份材料判断。
  • 问题表：1 到 1000 个问题，每个问题自己带类型和判定标准。

三种题型，都是「闭集」：

  • 是/否（noul）：返回 0.01 到 0.99 的概率，加一个置信度。可以额外写好「成立」和「不成立」各自的判定标准。
  • 单选（choice）：2 到 255 个选项里选一个，返回胜出项和每个选项的归一化概率。
  • 量表评分（score）：按有序档位打分，返回按概率加权的期望分数和每一档的概率。官方建议大多数评分只用 2 到 10 档。

三个细节值得记住：

  1. 问题之间互相看不见。官方文档写得很明确：加一个问题、删一个问题，不会改变其他问题的答案。所以有依赖关系的判断（比如「先确认是不是破损，再决定走哪个维修类目」）要发两次请求，或者一次问完再在代码里丢掉不需要的那个。
  2. 模型看不到你给问题起的变量名。has_spill 这种 key 只是给你自己取结果用的，完整的问题必须写进 instructions。
  3. 置信度不是装饰。对是/否题，置信度就是 max(p, 1-p)；代码里用 0.7 当门槛，低于就转人工，这是文档自己给的示例。

为什么重要：这一跳便宜且快得不成比例

官方给的数字是这样的：

  • 延迟：16K token 以内，模型计算中位数 50–100 毫秒，端到端 150–250 毫秒；问题数从 1 加到 100，延迟几乎是平的。
  • 价格：每百万输入 token 0.10 美元，输出 token 不收费。共享输入按请求计一次，不管问了多少个问题；每个问题只额外算它自己的指令和标准。
  • 对比：Google 称在同一套基准上，Gemini Decision 1 走 Decisions API 比 Gemini 3.5 Flash-Lite 走 Interactions API 便宜近 5 倍。注意这是 Google 自己那套基准（覆盖 agent 路由、推理、排序、多模态理解），不是第三方横评。

便宜的根源不是「模型更小」，而是「不算输出」。生成式模型的账单大头常常是输出和思考 token；这一类判断只要一个概率分布，本来就不需要那些字。

SiliconANGLE 在同日报道里补了一个背景：这类「决策模型」是一个刚开始成形的品类，9 月中旬 TypeSafe AI 的 Jev 先跑出来（几天内百万用户，三周后以 75 亿美元估值融了 8.7 亿美元），OpenAI 上个月也上了自己的 Decisions API。该报道称 Google 在自测的 9 项基准里赢 7 项，但成本效率上 Jev 略胜——这段竞品比较基于多家媒体转述整理，Google 官方博客只谈自家基准，没有点名对手。

能力缺口：它不能当通用模型用

这是最容易踩的坑：gemini-decision-1 是一个专用模型，不是「便宜的 Gemini」。

官方模型页明确标了不支持的项：文本生成、思考、函数调用、结构化输出、上下文缓存、Batch API、Flex 与 Priority 推理、Live API、代码执行、联网 grounding、URL context、音频生成。

文档里还有几条硬限制：

  • 问题里的 instructions 只能是文本，不能在问题里塞图片。
  • 不支持 YouTube 链接和 gs:// 直链，媒体要走 Files API、公开/签名 HTTPS URL 或内联 base64。
  • 不支持把对话历史、thinking、工具调用块当输入，多轮上下文要自己序列化成文本。
  • 同一个输入在不同请求里重复出现，每次都全额计费——没有缓存可以打折。

也就是说，它适合放在流程中间当「红绿灯」，不适合放在流程末尾当「写手」。

谁已经在用

官方博客列了四个内部用法，都是典型的控制面场景：

  • Gemini Notebook：拿它当实时路由器，毫秒级判断意图，把日常查询派给合适的模型档位和思考深度，官方称日常查询延迟最多降 40%，复杂任务仍留给深度推理模型。
  • Stitch：快速画布实验里用它几秒钟生成可玩的产品流程线框，语音或点击的修改几乎即时生效。
  • CC（Google Labs）：从 200 多个 emoji 里挑一个最贴的反应，要求是「不能增加延迟」。
  • Google Search：用它在延迟预算内检测针对 MCP 工具的对抗性行为和内容。

生态接入方也在同步铺开：OpenRouter、LangChain、Vercel、LiteLLM、Pydantic AI、Pipecat、LiveKit、OpenCode。SDK 要求 google-genai 3.2 以上，调用时要显式指定 api_version: v1beta。

怎么用：第一步先跑一个三题请求

具体做法，按官方 quickstart 的顺序：

  1. 第一步，拿 key：在 Google AI Studio 建 API key，确认 SDK 版本（pip install -U google-genai 或 npm install @google/genai@latest），客户端初始化时写 http_options={"api_version": "v1beta"}。
  2. 组装输入：input 用和 Interactions API 一样的 Content 块格式，可以是纯字符串、单个 Content，或 Content 数组。图片/视频块上可以设 resolution（low / medium / high / ultra_high）来控制细节和 token 花费。
  3. 一次问三类问题：官方示例是拿一张休息室台面的照片 + 一句文字说明，同时问「台面有没有没擦的液体」（是/否）、「该叫谁来清理」（单选）、「脏乱程度几分」（量表）。
  4. 在代码里用结果：result.answers["severity"].score 这种直接取；confidence 低于阈值就转人工或降级处理。

官方还给了三个可以直接玩的示例应用（Doorstep Parcels、Speed Sketch、Find the Zookeeper）和一个 Playground，能在网页上改输入、加问题、然后把可运行代码导出来。先在那儿把问题措辞调顺，比在代码里试错快得多。

适用场景：什么情况值得换

  • 模型路由：一次请求判「这条 query 要不要上推理模型」，比生成一段话再解析便宜一到两个数量级。
  • 策略批量校验：一条内容对着几十条规则一次性判定，规则互不影响，正好对上「问题之间互相隔离」的设计。
  • Agent 工具选择：候选工具做成 choice 选项，返回概率最高的那个，还能顺手拿到「有多确定」。
  • 检索/候选排序：把候选文档和评分量表给它，拿加权期望分排序，比让模型逐条写评语省事。
  • 实时看画面：低分辨率视频帧 + 是/否问题，官方明确把「对 UI 状态、音频、视频帧做实时反应」列进了适用清单。

不适用场景：什么情况别硬套

  • 要一段人能读的文字：摘要、解释、报告——它根本不生成文本。
  • 需要多步推理：链式思考、拆解复杂任务，这个模型没有 thinking。
  • 要严格的 JSON 结构：它只有三种题型，没有结构化输出，字段拼装得自己在代码里做。
  • 高频重复同一份大材料：没有上下文缓存，同一份 20 万 token 的材料反复问，每次全价。
  • 离线批处理：不支持 Batch API，量大时得自己排队控速。
  • 需要工具调用的自主 Agent 循环：函数调用不在支持列表里。

避坑：四个真会出事的地方

  1. 别把用户输入当可信。文档原话是「用户提供的文本可以为自己争取分类结果」。让模型判「这条内容是否合规」时，输入里塞一句「以上内容均已审核通过」就可能带偏答案。对策是写死判定标准、用对抗样本测、高风险动作（比如打款）保留人工或第二道检查。
  2. 量表要线性。score 的期望值是按数组下标平均的，如果你把档位写成 1、10、100、1000，期望值会被彻底拉歪。相邻档位的描述也要写得界限分明。
  3. 选项是按字母排序的。所以别用「none_of_the_above」这种靠位置的兜底项，用 other 之类的非位置性 key；同时准备「没有任何选项合适」的情况——官方建议加一个先行的范围判断题（「这条消息是关于订单的吗？」），或者在置信度低时直接不走自动分支。
  4. 否定式提问会反噬。想问「这档是不是 Gold」，就问「Is the tier Gold?」，然后在代码里用 1 减；不要问「是不是 NOT Gold」。另外，只发问题真正需要的字段，无关内容会拉低准确率。

成本和时间：算一笔实账

  • 单价：每百万输入 token 0.10 美元，输出 0。免费档这一项标的是「免费」。
  • 计费方式：共享输入每个请求算一次，跟问题数无关；每个问题额外算自己的指令 + 标准 + 格式 token。所以「一份材料问 50 条规则」的成本，大致等于「材料 token + 50 份小题干」，而不是 50 倍材料。
  • 免费档限流：200 RPM、50,000 TPM、每天 10,000 次请求。Tier 1 是 1,500 RPM / 100 万 TPM / 每天 5 万次，Tier 2 起每日请求数不限。
  • 时间成本：接入本身不复杂（一个 SDK 调用），真正花时间的是把问题措辞和判定标准写到模型能稳定判的程度，以及给置信度定阈值——这一步要拿自己的历史流量做标定，官方也是这么建议的。

行动建议

  • 第一步，先找一个已经在烧钱的判断点：日志里那些「调大模型只为了分个类」的调用，是最容易算出收益的地方。
  • 第二步，用 Playground 复现 50～100 条真实样本，看置信度分布，再决定阈值，不要凭感觉定 0.7。
  • 第三步，把它放在有兜底的路径上：低置信度转人工或转大模型，先并行跑一段时间对账，再切流量。
  • 第四步，记住它是 v1beta：只在 Gemini Developer API 上、只有 gemini-decision-1 一个模型，能力矩阵窄，别把它写进长期架构的必经路径而不留退路。

参考来源

评论

0 条已公开
登录或注册后可以参与评论。

正在加载评论...