Gemini Decisions API 怎麼用?confidence 門檻與 Agent 路由驗收
本文目錄
想讓 agent 先判斷問題該走文件查詢還是測試工作流,可以使用 Gemini Decisions API。但收到高 confidence 的答案後,程式仍要先查適用範圍與動作權限,才決定是否採用路由。
Google 於 2026-11-11 推出 Gemini Decision 1。它對固定候選做評分,回傳機率與 confidence,沒有生成文字答案;官方提供 Gemini API/AI Studio 存取,Google Cloud 支援仍列 coming soon。
一次請求要問哪些問題?
Decisions API 文件提供三種題型:
| 題型 | 用在什麼判斷 | 讀取的主要結果 |
|---|---|---|
noul | 輸入是否符合一個條件 | yes 的機率與 confidence |
choice | 從固定候選中選一項 | choice、各選項 probabilities 與 confidence |
score | 依有順序的 rubric 評分 | 加權 score、各級機率與 confidence |
針對 coding 工作流,可以拆成「是否屬於這個 repository 的開發問題」與「應查文件或交給測試流程」兩題。所有問題都讀取共用 input,彼此看不到對方的答案;先後條件要在你的程式裡組合。
以下為請求內容示意,尚未呼叫 API。SDK 文件要求 3.2 以上,Python、JavaScript 與 REST 的完整呼叫形式請依官方 quickstart:
{ "model": "gemini-decision-1", "input": "The project tests fail after changing a date formatter.", "questions": { "in_scope": { "type": "noul", "instructions": "Is this a software development question about the current repository?" }, "route": { "type": "choice", "instructions": "Choose the next workflow for this repository question.", "criteria": { "read_docs": "Explain documented behavior without running commands.", "test_workflow": "A code behavior needs reproduction in an approved test environment.", "other": "The question requires another workflow." } } }}題目 key 是你用來對應答案的識別字,模型不會看到它;要把真正問題寫進 instructions。test_workflow 只代表送到後續流程,實際可跑的指令仍由該流程的權限與規則決定。
confidence 很高,也可能是在肯定「不符合」
yes/no 題的 noul 是 yes 機率,confidence 則是 max(noul, 1 - noul)。例如 noul: 0.03、confidence: 0.97,表示模型很確定答案為 no。只判斷 confidence >= 0.9 就放行,會把確定不適用的輸入一起送進工作流。
另外,choice 一定要在候選裡選。若沒有合適選項,高分也無法替你補出正確的新工作流。因此先做 scope check,再檢查候選白名單及門檻。下面是可獨立執行的政策測試,只使用人工 fixture,沒有呼叫模型:
import assert from 'node:assert/strict';
const allowed = new Set(['read_docs', 'test_workflow']);const unit = (x) => Number.isFinite(x) && x >= 0 && x <= 1;
function chooseWorkflow(answers) { const scope = answers?.in_scope; const route = answers?.route; if (scope?.type !== 'noul' || route?.type !== 'choice') return 'human'; if (!unit(scope.noul) || !unit(scope.confidence) || !unit(route.confidence)) { return 'human'; } if (scope.noul < 0.9 || scope.confidence < 0.9) return 'human'; if (route.confidence < 0.85 || !allowed.has(route.choice)) return 'human'; return route.choice;}
const fixture = (noul, confidence, choice = 'read_docs') => ({ in_scope: { type: 'noul', noul, confidence: Math.max(noul, 1 - noul) }, route: { type: 'choice', choice, confidence },});assert.equal(chooseWorkflow(fixture(0.97, 0.94)), 'read_docs');assert.equal(chooseWorkflow(fixture(0.97, 0.94, 'test_workflow')), 'test_workflow');assert.equal(chooseWorkflow(fixture(0.03, 0.97)), 'human');assert.equal(chooseWorkflow(fixture(0.97, 0.5)), 'human');assert.equal(chooseWorkflow(fixture(0.97, 0.99, 'delete_repo')), 'human');assert.equal(chooseWorkflow(fixture(0.97, NaN)), 'human');assert.equal(chooseWorkflow({}), 'human');console.log('路由政策 fixture 通過');存成 routing.mjs 後執行 node routing.mjs。這些斷言可驗證程式有遵守自己的政策;模型是否能正確分類,要用真實 API 結果另測。0.9 與 0.85 都是本文示意門檻。
用自己的案例選門檻,先影子執行
先收集一組人工標註案例,包含明確文件問題、確實需要重現的 bug、與專案無關的要求,以及內容互相矛盾的輸入。每次測試固定 model、題目、候選描述與資料版本,保留預期路由、實際路由和 confidence。
比較門檻時,同時看「自動採用多少比例」與「自動採用之中錯了多少」。把所有案例都送人工能得到很低的自動誤判量,卻沒有完成分流;只追高自動採用率,也可能把錯誤送進後續流程。先以影子模式只記錄建議,確認錯誤類型後再開放低影響動作。
官方公告的 150–250 ms 是其量測結果,文中細節以最多 16K context 等條件描述延遲;最大 256K 輸入、最多 1,000 題的規格不能直接視為同延遲保證。本文沒有執行延遲、校正或正確率 benchmark。
若你已使用 Jev 的 Choice、Score 與 Noul,可以沿用固定案例與 fallback 政策的思路;SDK、回應欄位、門檻及效果仍須按 Gemini 重新驗收。分類結果也無法取代工具權限或對不可信輸入的防護。
2026-11-12 查核官方公告與文件。本文的本機 fixture 只驗證政策程式,不包含帳號資格、API 回應或實際 agent 執行。
參考資料: