如何在 Android 專案接入 Gemini Decisions API：六步實作指南

11 月 11 日，Google DeepMind 推出 Gemini Decisions API，背後是一個新模型 gemini-decision-1。它不生成文章，只回答有範圍的選擇題：是或否、多選一、按評分標準打分。一次請求可以帶著同一份文字、圖片、音訊、影片或 PDF，問上一千條問題。

對 Android 開發者來說，這是把「分類」與「路由」從自建模型搬去 API 的一條捷徑。這篇由取得金鑰開始，逐步接到你的應用流程，最後講幾個實際會踩到的坑。

步驟一：在 Google AI Studio 取得 API 金鑰

第一步不是寫程式，是拿鑰匙。用 Google 帳號登入 Google AI Studio，在 API Keys 頁面建立一組金鑰，同時開一個專案。免費層可以用來做原型，正式上線前再視用量決定是否留在免費層。

1. 登入 Google AI Studio，進入 API Keys。
2. 建立新專案，再建立金鑰。
3. 把金鑰寫進伺服器端的環境變數，不要寫進 Android 專案。

第三點要講白：金鑰屬於敏感憑證，一旦打包進 APK，任何人反編譯都拿得到。正確做法是由自家後端保管金鑰，Android 應用呼叫你的端點，再由後端轉發去 Gemini。多一層代理，多一點延遲，但省掉一整類安全事故。

步驟二：安裝 SDK 與設定 Android 的網絡層

官方提供 Python、JavaScript 與 REST 三種接入方式，另有 google-genai 的 SDK。Android 端最簡單的做法，是用 Retrofit 或 OkHttp 呼叫自家後端，後端再用官方 SDK 發請求。這樣做的好處是版本升級只在後端做一次。

1. 在後端安裝 google-genai，設定 API 版本為 v1beta。
2. 在 Android 專案加入 Retrofit 與 OkHttp，建立一個呼叫自家端點的介面。
3. 把請求與回應定義成資料類別，欄位對應 API 的 questions 與 confidence。

如果你堅持由應用直連，至少要把金鑰放在 Firebase 遠端設定之類可控的地方，並設定每日上限。應用的權限清單只需要網絡存取，不需要讀取相機或檔案，除非你確實要上傳圖片。

網絡層還要設定超時與重試。決策請求本身只要幾百毫秒，把客戶端超時設在兩秒，重試最多兩次，再加一個退避間隔，就足以應付大部分不穩。不要無限量重試，一萬個用戶同時重試，你的成本會比延遲更難看。

步驟三：把問題寫成 noul、choice、score 三種格式

Decisions API 的輸入分兩部分：一份共用輸入，加上一組問題。共用輸入可以是文字、圖片、音訊、影片或 PDF，上限 256K 詞元。問題有三種寫法，選對格式，答案才會穩定。

• noul（是／否）：估算某個條件成立的概率，可以附上「算成立」與「不算成立」的描述。
• choice（多選一）：由 2 到 255 個選項中選一個，回傳勝出者與每個選項的正規化概率。
• score（有序評分）：按你給的等級評分，由 0 開始，回傳連續分數與各級概率。

實作上，一條請求可以混合三種格式。例如你上傳一張廚房照片，同時問「檯面有積水嗎」（是／否）、「應該怎樣處理」（三選一）、「嚴重程度」（三段評分）。三個答案一齊回來，你不需要發三次請求。

步驟四：一次送出多條問題，控制成本

這套 API 的收費方式與聊天模型不同。輸入每百萬詞元 0.10 美元，輸出詞元不收費；共用輸入每條請求只計一次，問題本身只加自己的指令與評分標準。官方說，與 Gemini 3.5 Flash-Lite 搭 Interactions API 相比，同一組基準測試便宜接近五倍。

1. 把同一份素材的所有問題合併成一條請求。
2. 每個問題只寫必要的指令與選項，避免重複貼上同一段背景。
3. 在後端記錄每條請求的詞元數，換算成每日成本。

合併請求就是批次決策的核心，好處不只是錢。官方稱請求由一條問題增加到一百條，延遲幾乎不變，維持在 150 到 250 毫秒，模型運算約 50 到 100 毫秒。換句話說，一次問十條比問十次快得多。

記住三個數字：1,000 條問題、256K 詞元、150 至 250 毫秒。低於這個量級，合併的好處有限；接近這個量級，省下的時間與費用才明顯。

步驟五：用信心分數做分流

每個答案都會附一個 0 到 1 的信心分數。這個數字比答案本身更有用，因為它讓你決定幾時交給人。

1. 高於 0.85：直接採用，寫入資料庫或觸發動作。
2. 0.6 到 0.85：交給較大的模型重問一次。
3. 低於 0.6：排入人工審核佇列，附上原圖與問題。

以內容審核為例，相片有沒有違規、屬哪一類、嚴重程度，三個問題可以一次問完。信心不足的個案不會靜靜過關，而是有人再看一眼。這種設計比單純追求準確率實在，因為錯的分類會直接影響用戶。

步驟六：接上現有工具鏈

你不一定要自己寫接入層。官方說生態整合正在鋪開，包括 OpenRouter、LangChain、Vercel、LiteLLM、Pydantic AI、Pipecat、LiveKit 與 OpenCode，Gemini in Google Cloud 則在排隊。

1. 已經用 LangChain 的團隊，可以直接把模型換成 gemini-decision-1。
2. 用 Vercel AI SDK 的前端，可以沿用原有的串流與工具呼叫流程。
3. 語音代理用 Pipecat 或 LiveKit 的，適合把決策層放在語音回合之間。

實作貼士：五個減少誤判的做法

第一，問題要寫得像驗收條件，不要寫成開放式提問。「畫面是否有未清理的液體」比「描述畫面」有用得多。

第二，選項要互斥。choice 最多 255 個，但選項越多，概率越分散，十個以內通常夠用。

第三，善用評分標準的描述。score 的每個等級寫一句具體標準，比只寫「低中高」穩定。

第四，圖片與影片可以調解析度。解析度越高，細節越多，詞元也越貴，先問自己需不需要看清細節。

第五，同一批素材固定用同一組問題，方便比較版本之間的變化。改問題等於改量尺，舊數據就不能直接比。

疑難排解：四個常見問題

回傳 400，多數是問題格式不對。noul 的欄位名容易串錯，choice 的選項要放在 criteria 之內，建議先照官方範例跑一次。

答案來回飄移，通常是共用輸入太長而問題太短。把關鍵條件寫進問題，不要指望模型自己從 200K 詞元的文件裡挑。

延遲比預期高，先檢查是不是每條問題都重新上傳同一張圖。共用輸入只計一次，但重複上傳會令請求變大。

回傳的答案全部落在同一個選項，通常是選項描述太相似。把每個選項的差異寫成一句可觀察的事實，例如「有玻璃碎」與「只有水漬」，比「嚴重」與「非常嚴重」有效。

成本突然上升，看兩個地方：圖片的解析度設定，以及有無把整份 PDF 當成為每條問題的背景。官方亦提到，OpenAI 在 10 月已推出類似的 Decisions API，同樣以每百萬輸入詞元 0.10 美元起計，格價時要連準確度一併比。

結論：Gemini Decisions API 值得接入嗎

如果你的應用有一堆「是或否、哪一類、幾多分」的重複判斷，這套 API 的價值很直接：一次請求、幾百毫秒、按輸入計費，還有信心分數幫你決定幾時交人。它不適合寫文案、聊天或長篇推理，那些仍然要用生成式模型，兩者可以並存在同一個應用裡。

接入的成本主要在後端那一層代理，不在模型本身。先揀一個真實場景，例如審核用戶上傳的相片，用免費層跑一百個樣本，對照人工判斷，再決定要不要全面換上。這一步做過，你對它的信心分數才有感覺。