Google DeepMind 推出 Gemini Decision 1 用於基於代理的決策

Google DeepMind 推出 Gemini Decision 1 及專用 Decisions API，試圖將 Agent 系統中大量「該調用哪個工具」「是否符合政策」「應分給哪類模型」「風險有多高」等封閉式判斷，從通用生成模型中拆分出來。開發者可一次提交最多 25.6 萬 Token 的文字、圖片、音訊、影片或 PDF，並圍繞同一份材料提出最多 1000 個相互獨立的問題；模型不逐字生成解釋，而是在一次前向計算中直接為候選項提供機率與可信度。Google 公布的典型端到端延遲為 150 至 250 毫秒，價格為每百萬輸入 Token 0.10 美元，輸出免費。不過，這些延遲數據主要來自不超過 1.6 萬 Token、最多 100 個問題的測試，並未證明在滿上下文、1000 問時仍能保持相同速度；獨立評測也將其排在 18 款決策模型中的第 9 名，說明其校準與多模態能力突出，但並非所有決策任務的綜合冠軍。

文章作者、來源：Google DeepMind

目前許多 Agent 即使只需回答「是或否」，也會調用完整的生成模型。模型需要讀取上下文、推理並逐 Token 輸出文字，應用隨後再從答案中解析一個布林值或類別。

這種方式靈活，但在高頻工作流中很浪費。一個客服 Agent 可能需要依次判斷用戶意圖、帳戶風險、適用政策、工具權限、升級隊列和回覆模型；每一步都調用生成模型，會累積延遲、費用及格式解析錯誤。

Gemini Decision 1 採用不同思路：開發者先定義有限的候選答案，模型只負責給這些選項評分。它不是聊天模型，也不會起草解釋，更接近一個能夠理解長上下文和多模態資訊的通用分類、排序與策略判斷層。

Google 提供三種問題形式：

• “是／否”判斷，返回條件成立的概率；
• 從 2 至 255 個選項中選擇，並返回每個選項的歸一化機率；
• 根據預先定義的有序量表評分，同時返回各等級概率和加權分數。

每個結果還附有 0 至 1 之間的置信度。應用程式可設定閾值：當置信度高時自動執行，置信度不足時轉交給更強的模型或人工審核。blog.google

一次請求最多可包含 25.6 萬 Token，並針對同一份輸入提出 1000 個獨立問題。

例如，保險公司可以同時提交一份掃描的索賠表、現場損壞照片、客戶通話錄音和帳戶資料，然後要求模型判斷材料是否齊全、屬於哪類事故、是否存在欺詐信號、應該分配給哪個隊列，以及需要多緊急地處理。

共享材料僅計費一次，各問題僅額外增加其自身的指令和候選項 Token。因此，當數十項檢查都需要讀取同一份長文件時，這比將文件重複發送數十次更經濟。官方定價為每百萬輸入 Token 0.10 美元，不收取輸出 Token 費用，也無單獨的 OCR 或語音轉文字費用。

但這1000個問題必須彼此獨立。模型不會讓第二個判斷讀取第一個判斷的結果。如果工作流程是「先判斷文件類型，再根據類型採用不同審核規則」，開發者仍需在代碼中連接兩步，或再次調用 API。需要生成說明文字、提取任意欄位或撰寫回覆時，也仍然需要生成或資訊抽取模型。

Gemini Decision 1 跳過逐 Token 解碼，直接在一次前向計算中為全部候選項評分。Google 說，模型計算的中位耗時為 50 至 100 毫秒，包含服務和網絡環節後的端到端延遲約為 150 至 250 毫秒。

官方測試顯示，在不超過 1.6 萬 Token 的多模態輸入上，將單次請求從 1 個問題增加到 100 個，延遲基本保持平坦。相同基準中，其成本據稱比透過 Interactions API 調用 Gemini 3.5 Flash-Lite 低近五倍。

這些數字不能直接外推到所有情況。模型雖然允許 25.6 萬 Token 和 1000 個問題，但 Google 沒有證明同時用滿兩項上限仍能在 250 毫秒內完成；大型視頻、音頻和 PDF 的上傳時間也不包含在模型計算時間裡。實際部署必須使用自己的文件長度、問題數量和網絡位置重新測量。

傳統分類器通常面向一種預先固定的数据格式，而 Gemini Decision 1 能夠在同一請求中共同讀取文字、圖片、音頻、視頻和 PDF。

官方示例向模型提交了一張茶水間台面的照片和一句文字說明，同時詢問三件事：是否存在未清理的液體、應當擦拭還是叫清潔、現場嚴重程度如何。模型判斷存在少量潑灑，建議用布擦拭，並給出各選項機率。

開發者還可以降低圖片或影片的解析度，以犧牲部分細節來減少 Token 和費用。對於理賠、內容審核、商品檢查或影片事件識別，這比分別運行 OCR、語音識別、視覺模型和規則引擎更容易搭建；但統一模型也意味著，一旦其對視覺或語音內容理解錯誤，多個後續判斷可能同時受到影響。

Google 称 Gemini Decision 1 在路由、推理、排序和多模態理解基準中表現領先，並取得最低的校準誤差。其官方比較中，模型在 JevBench 達到 92.2%，高於 GPT‑6 Luna 的 90.9% 和 Jev 1.14 的 90.0%；校準誤差為 0.0250，約為 Jev 的 0.0494 的一半。

但它並未包攬所有任務。Jev 在瀏覽器任務決策 Mind2Web Multimodal 上以 86.8% 略高於 Gemini 的 86.2%，在判斷何時調用工具的 When2Call 上也以 82.0% 領先 Gemini 的 79.9%。

獨立的 Artificial Analysis Decision Index v2.1 給 Gemini Decision 1 約 66 分，在 18 款決策模型中排第 9 名。它在知識與推理類項目中排名第一，卻在需要同時正確理解整份簡歷、發票、收據或論文的 AA‑Paperclip 測試中，只有 33% 的文檔能夠做到全部問題均答對；Drex Max v1.1 為 63%。在獨立 When2Call 測試中，它也落後於 Drex Max 和 Jev。

這說明「置信度校準好」和「每項判斷都最準確」不是同一件事。校準良好的模型更清楚自己何時可能出錯，有利於設置人工複核閾值；但如果應用錯誤地把高置信度當成事實保證，仍然可能自動執行錯誤決定。

Google 已在多個產品中使用這套 API。Gemini Notebook 用它判斷查詢應當交給哪個模型及何種思考強度，官方稱普通查詢延遲最多降低 40%；Stitch 用它快速響應語音或點擊產生的設計修改；Google Labs 的 CC 從 200 多個表情中選擇反應；Google Search 則將它放在 MCP 工具調用之前，檢測對抗行為和危險內容。

這些案例揭示了其真正定位：它不是用戶最終看到的智能，而是位於 Agent 背後的控制平面。生成模型負責寫代碼、組織語言和解決開放問題；決策模型負責決定下一步調用什麼、是否允許調用、需要多強的模型，以及何時應當停止自動化並交給人。

這種分工可能比單純擴大通用模型更適合大規模 Agent 系統，因為大量日常步驟並不需「更會寫」，只需要足夠快、便宜且概率可信地選對分支。

Gemini Decision 1 目前透過 Gemini Developer API 的 `v1beta` 端點提供，Google Cloud 支援仍標示為「即將推出」。Google 尚未公開參數量、訓練資料、訓練算力、具體架構或完整系統卡，因此無法判斷它是否由現有 Gemini 模型蒸餾而來，亦無法獨立驗證訓練層面的安全與資料聲明。