Gemini Decision 1 与 Jev：封闭式决策 API 和通用 LLM 的区别、成本与场景
2026年11月12日 · 2715 字 · 6 分钟 · Gemini Jev AI决策 智能体
Gemini Decisions API 是 Google 于 2026 年 11 月 11 日发布的封闭式决策接口，使用 Gemini Decision 1 模型，从文本、图片、音频、视频和 PDF 中返回预设问题的类型化判断。 它适合分类、分流和评分；需要解释或写作时，仍要使用通用 LLM。能力说明见 Google 官方公告。
9 月聊 Jev 时，提过一个有点反直觉的变化：有些 AI 模型开始不写答案了。
给它一份材料，再给几个明确的问题，它返回选择、分数或概率，交给程序往下处理。放进智能体里看，像是给负责思考和表达的“大脑”，配一个负责快速判断的“小脑”。
Google 这次沿着类似方向，提供多模态输入与封闭式判断，不生成回答用的文本 token。
这对日常聊天意味着什么？可能没什么。但如果你的系统每天要判断几千次“这条消息交给谁”“这张照片需不需要人看”，就值得往下了解。
Gemini Decision 1 与通用 LLM 结构化输出有什么区别？
假设客服收到一句话：“东西昨天到了，外壳裂了，怎么处理？”
通用 LLM 可以解释售后政策、追问订单号，甚至写好回复。此时，语言表达就是工作的一部分。
但工单系统眼下可能只想知道：该转售后，还是物流？
让模型写一段分析，再从里面找部门名称，多绕了一步。现在的通用 LLM 已经能按 JSON Schema 输出分类字段，因此比较时要把结构化输出方案也放进来。官方结构化输出文档介绍了这类 JSON Schema 约束。
专用决策接口把任务收窄了：先规定允许返回什么，再让模型在这个范围里判断。 它不负责续写一段解释。这给减少生成开销、直接对接程序提供了条件，具体收益仍要和你的现有方案比较。
比如同一份售后材料，可以分别问：是否涉及商品损坏？应分给哪个部门？按事先定义的标准，紧急程度属于哪一档？
来源：Google 官方发布页。架构示意：共享材料与预设问题进入模型，返回类型化结果。图中数值是官方示例。
接口里的三种问题分别叫 noul、choice 和 score，对应是非判断、固定选项、按标准评分。返回的概率和置信度，可以成为程序分流的依据。问题类型与返回字段见 Decisions API 文档。
要留意，“格式合规”和“事情判断对了”是两回事。选项只有物流、售后、财务时，一条招聘咨询也可能被硬分进去。最好留一个“其他”，再处理证据不足的情况。
与 Jev 相比，Google 的决策 API 提供了什么？
两者都在回答同一个需求：让代码拿到可以直接使用的判断。
Jev 已经把状态、类型化问题和结构化结果做成了接口。Gemini Decision 1 则把这类能力放进 Google 的开发者体系，明确支持多种媒体输入。
这里也补一个容易误会的地方：Jev 目前的官方文档已有实验性图片能力，不能简单概括为“Jev 只懂文字，Google 才开始看图”。两者具体怎么选，得看输入形式、接入条件和业务样本。Jev 的设计和输入支持可对照 TypeSafe 官方介绍与 System One API 文档。
Google 用了一个很直观的例子：台面上洒了液体。模型根据画面判断有没有洒漏、下一步做什么，以及严重程度。
来源：Google 官方发布页。官方演示示意，浮层展示判断结果；不是本文实测，也不是已部署的监控系统截图。
这类任务过去也能交给多模态 LLM。变化在于，业务可以直接取走“是否洒漏”“建议动作”等结果，而不必要求模型先描述整张图。
至于谁更准，不能只看发布会。Google 自己公布的表里，Gemini Decision 1 和 Jev 也各有胜出的项目。
来源：Google 官方发布页。Google 自报基准，非独立评测。表中 Jev 版本为 1.14，部分项目和总成本占优；小字可点开放大，不宜据此推断自家业务表现。
150—250 毫秒延迟与每百万输入 0.10 美元有哪些条件？
Google 给出的端到端延迟是 150—250 毫秒，但要把条件一起读完：这是其多模态测试中、上下文不超过 16K tokens 时的中位数口径。
它另有 256K 上下文、单次最多 1000 个问题的容量上限。这不等于把容量拉满，也能保证上面的响应速度。你的网络、材料长度和实际流量，都要另外测。
价格倒比较好理解。当前付费档每百万输入 tokens 为 0.10 美元，没有输出 token 费用。同一请求里，多道题共用的材料只计一次，问题本身仍计入输入。这里采用发布时的 Gemini Decision 官方价格，接入前应再次核对。
举个纯算术例子：若一次请求的材料加问题总共一万输入 tokens，模型费用约为 0.001 美元。这不是实测账单，也不含你系统的其他开销。
如果你原来反复发送同一份材料，每次问一个分类问题，合成一次独立多问的请求，可能更划算。不过目前没有上下文缓存，下一次请求重复发送，仍会重新计费。
三种使用场景：售后分流、模型路由和知识库筛选
售后分流比较适合起步。用户提交破损照片和一句描述，模型判断问题类型，代码负责建单；需要安抚用户、解释赔付政策时，再让通用 LLM 写回复。
下面是我按这个场景设计的提问草案，尚未做 API 实测；接入时需转换成接口要求的字段：
材料：用户原话、商品照片、订单备注。
是非题：材料中是否有商品损坏的明确证据？不要把“担心会坏”当作已经损坏。
选择题：最相关的处理队列是售后、物流、财务还是其他？只按材料判断。
评分题：紧急程度分为普通咨询、影响正常使用、涉及人身安全三档，按这些描述评分。
先把“损坏”和“紧急”的边界写清楚，往往比多加一句“你是专业客服”更有帮助。
还有两种地方我会留意。
一种是模型路由。收到用户请求，先判断是否需要看图、是否涉及复杂推理、是否必须查最新资料，再由代码选择后续能力。简单请求有机会少走一次昂贵调用，但判断错了也会损伤回答质量，节省多少得连同误分成本算。
另一种是知识库筛选。搜索出来十几段资料，先按“能否直接回答这个问题”打分，留下更相关的内容，再交给通用 LLM 组织答案。它只做相关性筛选，引用核对和最终回答仍有各自的工作。
这些都是可尝试的流程设计，不代表 Google 已经替你验证了业务效果。
如何接入与评估：独立问题、置信度和人工复核
同一请求里的问题是独立评估的，第二问看不到第一问的答案。所以“先判断是否损坏，如果是，再根据上一题选部门”这种依赖关系，应由代码衔接，或拆成两次调用。
置信度也不能直接当成准确率保证。先拿一批有人工结论的旧工单跑一遍，看看哪些容易分错，再决定什么分数可以自动流转、什么情况必须转人工。漏掉安全问题与多转一张普通工单，代价显然不同。
接入方面，这是开发者 API，需要 API Key 和程序调用。官方快速开始要求 SDK 3.2 或更新版本，使用 gemini-decision-1；不是在聊天框里选个新模式就能完成。
需要解释原因、提取任意字段、生成工具参数，仍应使用合适的通用模型接口。金额计算、日期比较这类确定规则，代码能做就交给代码。
接入入口：Gemini Decisions API 官方快速开始与接口文档。本文依据官方材料梳理，没有进行账号内 API 实测。
回头看 Jev，我仍觉得这条路线值得关注。但真正让我感兴趣的，是它能否在一个明确的小环节里，稳定地少花一点时间、少花一点钱。
你手上的流程里，有没有哪一步，等了 AI 半天，最后其实只取了它回答里的一个词？那一步，适合拿出来比较一下。