假設主管丟來三個需求：
- 幫客服把回覆草稿寫快一點。
- 讓員工能查公司內部文件，而且答案要附來源。
- 做一個能查庫存、建立工單，必要時再請人核准的助理。
三個需求都可能用到 Gemini，但入口不一樣。第一個重點是模型生成，第二個重點是搜尋與引用，第三個還多了工具權限和流程控制。
所以選 Google Cloud AI 產品時，先問「系統要完成什麼工作」，不要先問「哪個產品最強」。
先看四層產品地圖
可以把常見產品分成四層：
| 需求層次 | 常見入口 | 主要工作 |
|---|---|---|
| 呼叫生成模型 | Gemini 模型、Vertex AI API | 摘要、分類、擷取、生成與多模態理解 |
| 探索與建置模型 | Vertex AI Studio、Model Garden、Vertex AI 平台工具 | 試 Prompt、比較模型、評估、微調與部署 |
| 搜尋企業資料 | Agent Search | 語意搜尋、關鍵字搜尋、RAG 與引用 |
| 建立可執行任務的 Agent | Vertex AI Agent Builder、ADK、Agent Engine | 規劃步驟、呼叫工具、維護狀態與部署 |
這是一張判斷方向的地圖，不是嚴格的產品邊界。同一個正式系統，往往會同時使用其中兩到三層。
Gemini：先選能力，再選版本
Gemini 是 Google 的多模態模型家族。不同版本會在品質、速度、價格與生命週期之間取捨。
截至這篇更新時，常見起點是：
| 模型 | 適合情境 | 目前狀態 |
|---|---|---|
gemini-3.5-flash | 一般生成、多模態理解、工具呼叫與結構化輸出 | GA |
gemini-3.1-flash-lite | 高流量、延遲與成本較敏感的簡單任務 | GA |
gemini-3.1-pro-preview | 需要先驗證高階能力的實驗 | Preview |
這裡刻意把 Preview 標出來。預覽模型很適合做概念驗證，但版本、配額或支援條件可能改變；正式環境若使用它，必須先設計升級與回退方案。
模型名稱也會更新。實作前應查看官方的模型版本與生命週期，不要直接從舊文章複製 Model ID。
不要只憑名稱選模型
比較模型時，至少要看五件事：
- 品質：用自己的真實案例測試，不只看公開榜單。
- 延遲：互動式客服和離線報表能接受的等待時間不同。
- 成本：輸入、輸出、快取與思考 Token 都可能影響費用。
- 能力：是否支援需要的模態、結構化輸出、函式呼叫或 Grounding。
- 生命週期：是 GA、Preview，還是已公告淘汰日期。
最實用的做法通常是：先用一般型 GA 模型建立品質基準，再拿較輕量的模型跑同一組測試。若較便宜的模型已達標，就沒有必要為每個請求支付更高成本。
Vertex AI Studio：先把需求試清楚
Vertex AI Studio 適合快速試做：
- 比較不同提示詞
- 測試文字、圖片或 PDF 輸入
- 調整輸出設定
- 取得可放進應用程式的範例程式碼
但 Studio 裡「看起來可以」只是起點。正式開發還要補上版本固定、測試資料、錯誤處理、權限、監控與成本控制。
下一課會直接用 Google Gen AI SDK 呼叫 Vertex AI 上的 Gemini。先在 Studio 找方向，再把相同任務放進可重複執行的程式，通常很順。
Model Garden：模型不只 Gemini
Model Garden 是瀏覽與使用模型的入口，內容包含 Google 模型、合作夥伴模型與開放模型。
你可以用它回答幾個問題：
- 這個模型是否支援目前區域？
- 可以用代管 API 呼叫，還是需要自行部署？
- 授權與商業使用條件是什麼？
- 模型大小、硬體需求與費用是否符合預算？
不同模型的使用方式並不相同，不能看到 Model Garden 裡有一張模型卡，就假設它一定能用相同 API 或相同權限部署。
如果 Gemini 已經符合需求，通常先用代管模型會比較簡單。只有在模型能力、授權、資料控制或特定成本條件真的需要時，再評估其他模型。
Agent Search：答案要根據企業資料時
如果需求是「讓員工問公司文件，回答要能指出來源」，核心問題不是寫出漂亮句子，而是先找到正確資料。
Agent Search 提供企業搜尋與 RAG 所需的代管能力，包括語意搜尋、關鍵字搜尋與 Grounding。常見流程是：
使用者問題
↓
搜尋有權限查看的相關文件
↓
把片段與來源交給 Gemini
↓
產生答案並顯示引用它適合想快速建立企業知識搜尋、又不打算一開始就自己管理每個向量索引細節的團隊。
Google Cloud 的產品名稱近年有調整：原本名為 Vertex AI Agent Builder 的搜尋產品後來改稱 AI Applications；現在「Vertex AI Agent Builder」指的是更完整的 Agent 建置套件。看舊教學時，若發現畫面或名稱對不上，先確認文件日期與目前產品名稱。
Vertex AI Agent Builder：不只回答，還要做事
當系統需要查庫存、建立工單或呼叫內部 API，就進入 Agent 的範圍。
Agent 通常包含：
- 模型：理解需求與決定下一步
- 工具：搜尋、資料庫或 API
- 狀態：保存工作流程需要的資訊
- 控制：權限、核准、逾時與重試
- 評估與觀測：確認每一步是否安全、正確
重要的是，模型可以「提出」要呼叫哪個工具，真正執行與授權仍應由應用程式控制。不能因為模型產生了一段函式參數，就直接讓它繞過身分驗證或業務規則。
用需求選入口
回到開頭三個需求：
客服回覆草稿
先用 Gemini 搭配 Vertex AI API。把公司語氣、輸出格式和不確定時的處理方式寫清楚，再用歷史案例建立測試集。
內部文件問答
先評估 Agent Search。重點是資料來源、存取權限、文件更新、引用與答案是否有根據，不只是 Prompt。
能查庫存與建立工單的助理
用 Agent Builder 相關工具設計流程，但把查詢與寫入分開處理。建立工單這類會改變外部狀態的操作，最好加上明確確認或人工核准。
成本不要靠猜
生成式 AI 的成本通常受這些因素影響：
- 輸入與輸出 Token 數量
- 模型版本
- 是否使用 Grounding、搜尋或其他工具
- 線上即時或批次處理
- 快取、思考與多模態資料量
- 自行部署模型時使用的運算資源
價格會調整，所以課程不寫死每百萬 Token 的金額。估算時請看Vertex AI 定價，再用真實輸入長度和預期流量試算。
上線前至少要有：
- 專案預算與告警
- 每個功能的使用量記錄
- 輸入與輸出 Token 監控
- 模型版本變更與回退計畫
- 一組可以重跑的品質測試
小練習：你會怎麼選？
請替下面三個情境各選一個起點，並寫下理由：
- 每晚把五千筆商品評論分成固定的六個類別。
- 讓法務搜尋內部合約，答案必須附上段落來源。
- 從現場設備照片判斷故障現象，再草擬檢查步驟。
沒有唯一答案。你要說清楚的是品質、延遲、成本、資料來源與風險之間怎麼取捨。
下一課會從第一條路徑開始：用目前的 Google Gen AI SDK，實際呼叫 Vertex AI 上的 Gemini。
