谷歌推出低成本多模态决策接口
谷歌发布由 Gemini Decision 1 驱动的决策 API，可针对多模态输入回答最多 1000 个封闭式问题，并返回校准后的概率。支持判断、选择及量表评分，输入价格为每百万 Token 0.10 美元。
AI 深度解读
Agent 里不少模型调用，只是为了回答「该走哪条分支」：选工具、分流请求、检查策略、给结果打分。Google 推出的 Gemini Decisions API，把这类任务单独做成了接口：不生成文本，直接返回候选项的概率，再由代码决定下一步。
它的吸引力是共享输入、批量判断和可用于设置阈值的概率。但原文的性能数据均由 Google 自报，低延迟也有输入长度前提。对开发者来说，值得研究的是这种调用方式能省掉哪些环节，以及它什么时候比普通模型更合适。
不让模型写答案，程序怎么接着跑？
Gemini Decision 1（gemini-decision-1）面向封闭集合决策（closed-set decisions），也就是先给定可选答案，让模型判断各项有多大可能成立。它支持文本、图片、音频、视频和 PDF，在一次预填充处理中读取输入，输出 token 用量始终为 0。
每个请求包含模型 ID、一份共享输入，以及一组问题。原文列出三类问题：
noul：判断是或否，返回「是」的概率，范围为 0.01 到 0.99。原文使用这个类型名，但未提供请求示例。choice：从 2 到 255 个选项中选一个，并返回所有选项归一化后的概率。score：按 2 到 255 个有序评分等级评估，返回概率加权分数。
每个答案还携带 0 到 1 的 confidence。Google 建议把低置信度结果交给备用流程或人工审核。原文没有说明 confidence 与选项概率之间的具体计算关系，不能直接把两者当成同一个数。
它省掉的是生成答案再解析的步骤，业务分支仍要由代码定义。
一次最多提交 1,000 个问题，但各问题并行计算，互相看不到答案。因此，它适合对同一份材料做多项独立检查；如果后一道题依赖前一道题的结果，仍需拆成不同调用。
150–250 ms 和低价格分别有什么前提？
普通生成模型逐 token 解码，Gemini Decision 1 则在一次前向计算中给候选项打分。Google 报告的模型计算时间中位数为 50–100 ms，端到端延迟为 150–250 ms。
这个数字对应输入不超过 16K tokens 的情况；问题数从 1 增至 100 时，延迟近乎不变。完整上下文容量虽然达到 262,144 tokens（256K），覆盖共享输入与全部问题，但原文没有提供满上下文或 1,000 个问题时的延迟。
计费按每 100 万输入 tokens $0.10 收取，输出费用为 $0，没有额外的 thinking-token、转录或 OCR 费用。共享输入在单次请求中只计费一次，每道题增加自己的指令和判断标准 tokens。
这里的节省发生在同一次请求内。目前没有 prompt caching，也没有 Batch API，跨请求重复提交上下文仍需完整计费。
价格也并非最低：TypeSafe Jev 1.14 为 $0.042/M；GPT-6 Luna 在 OpenAI Decisions 上的未缓存输入同为 $0.10/M，支持缓存，但按 Luna 费率收费。三者输出费用均为 $0。Google 的 7 项共同评测总费用分别为 $0.88、$0.68、$0.93，Gemini 3.5 Flash-Lite 为 $4.14。
因此，Google 所说接近便宜 5 倍，是相对 Flash-Lite 的共同评测费用，不能理解成比所有竞品都便宜。
分数领先，能直接放心自动化吗？
下面是原文转述的 Google 自报结果，拒答与安全拦截均计为错误。表中 Jev 指 TypeSafe Jev 1.14，Luna 指 OpenAI Decisions 上的 GPT-6 Luna。
| 评测 | Gemini Decision 1 | Jev | Luna | Gemini 3.5 Flash-Lite |
|---|---|---|---|---|
| JevBench，公开集 | 92.2% | 90.0% | 90.9% | 86.6% |
| Amazon ESCI，Macro-F1 | 58.7% | 56.7% | 54.7% | 47.2% |
| New Yorker Caption，仅文本 | 79.7% | 72.0% | 68.4% | 73.7% |
| Mind2Web Multimodal | 86.2% | 86.8% | 81.8% | 78.0% |
| PubMedQA | 79.8% | 78.2% | 74.4% | 77.6% |
| Global-MMLU-Lite，非英语 | 86.0% | 85.0% | 79.6% | 78.8% |
| When2Call | 79.9% | 82.0% | 70.4% | 60.9% |
| MMAU，音频 | 71.8% | 未报告 | 未报告 | 67.7% |
| Video-MME，无字幕 | 69.1% | 未报告 | 未报告 | 63.3% |
| Top-1 ECE，越低越好 | 0.0250 | 0.0494 | 0.0721 | 0.2104 |
Gemini Decision 1 在 9 项准确性评测中领先 7 项，但 Amazon ESCI 的 58.7% Macro-F1 仍是它的最低分；When2Call 和 Mind2Web Multimodal 则落后于 Jev。
更有价值的指标可能是校准误差 ECE。校准衡量的是：模型报出的概率，与实际答对的频率是否接近。它的 0.0250 约为 Jev 0.0494 的一半，对设置自动处理阈值有帮助，但不能保证每类业务、每个概率区间都同样可靠。
接入方面，目前仅支持 Google 托管的 Gemini Developer API v1beta，需要 google-genai SDK 3.2 或以上版本，没有开放权重或自托管。Google AI Studio 提供免费原型额度，文档提供 Python、JavaScript 和 REST 指南。
生态支持正在向 OpenRouter、LangChain、Vercel AI SDK、LiteLLM、Pydantic AI、Pipecat、LiveKit 和 OpenCode 推进，不能据此认定每个集成都已可用；Google Cloud 上的支持仍标为即将推出。
我的判断
这个方向适合答案集合明确、判断需要语义理解的任务。相比让通用模型返回 JSON，它把概率输出、批量提问和计费方式统一起来；相比固定规则，它能处理更模糊的输入。但确定性条件依然适合直接用代码判断，没有必要全部交给模型。
概率是否可靠，要用自己的业务样本验证。
Google 内部案例包括：Gemini Notebook 用它选择模型档位，日常查询延迟最多降低 40%；Google Labs 的 CC 从超过 200 个选项中挑选 emoji；Stitch 的 rapid canvas 用它在数秒内构建可交互线框。这些是厂商提供的案例，原文没有给出足够的对照条件，无法据此估算普通团队收益，也不是作者独立实测。
此外，OpenAI Decisions 的问题上限为 400，上下文标为 1,050,000 tokens；Jev 每请求默认 64K，通过 opt-in header 可达 262K，没有固定问题数上限，但受上下文限制。选型要看实际输入和任务，不能只比较单项跑分。
能拿来做什么
- 给 Node Agent 增加工具路由时，先固定候选工具，收集真实请求，对比现有路由的准确率、延迟和费用，再决定是否替换。
- 对同一份文本或多模态材料做多项独立检查时，可以合并为一次请求，减少共享输入的重复计费；存在依赖的问题仍应分步执行。
- 给自动处理设置置信度阈值前，先统计业务样本的误判，并把低置信度结果接到备用流程或人工审核。
- 接入 JavaScript 项目前，确认
google-genaiSDK 至少为 3.2，并检查所用框架集成的实际状态；重复上下文较多时，把缺少缓存的成本计入比较。