🗺️ GCP 服務地圖
AI 與機器學習・AI 基礎與治理・GAIL/PMLE/PAA

Gemini Enterprise Agent Platform:Agent Search 與 RAG

讓 Gemini 依公司文件回答並附上出處,再在提示與回應兩端各加一道 Model Armor 檢查。這一頁把檢索、生成與防護各自負責什麼,以及改名後該找哪個服務,一次講清楚。

RAG 流程模擬(字詞重疊示意) Model Armor 過濾器模擬 主控台 × gcloud/REST × Terraform

💡 先搞懂問題

虛構的「晴空食品」有一百多家門市,總部把冷凍商品退換貨、冷鏈出貨、盤點、排班等規定寫成一份內部作業手冊,放在共用雲端硬碟裡。門市新人遇到顧客問題時,常常找不到該看哪一頁,只好打電話問店長。資訊部試著讓大家直接問 AI 助理,結果助理回答得很流暢,內容卻常常和手冊不一樣:手冊寫冷凍商品不適用七天鑑賞期,助理卻說「網購都有七天鑑賞期」。原因很單純:大型語言模型只知道訓練時看過的公開資料,沒讀過晴空食品的手冊;不知道的事,它會用「聽起來合理」的一般常識補上,這就是幻覺(hallucination)。

直覺的解法是把整本手冊貼進提示裡,但手冊會越寫越長,每次提問都塞全文,又慢又貴,也可能把不該給這位員工看的段落一起送出去。重新訓練或微調模型也不划算:規定每個月都在改,微調完又過時了,而且模型還是說不出「這句話出自哪一頁」。比較好的做法是檢索增強生成(Retrieval-Augmented Generation,RAG):每次提問時,先從手冊裡找出最相關的幾段,連同問題一起交給模型,並要求它只根據這幾段回答、附上出處。

之前:問題直接送給模型 門市新人「退冰可以退嗎?」 Gemini沒讀過手冊 「網購都有七天鑑賞期」聽起來合理,但和規定不同 之後:先檢索,再生成(RAG) 門市新人同一個問題 檢索從手冊找 3 段 內部作業手冊 Gemini問題+3 段 依手冊回答附上出處 [1] 段數為示意;規定改了只要更新手冊
RAG 不改變模型本身,而是在每次提問時替它準備「參考資料」。手冊更新後重新匯入即可,不必重新訓練;回答也能標出根據的是哪一段。

生活比喻:開卷考的考生、圖書館員與監考

想像一場開卷考。考生(模型)很會寫作文,但沒讀過這門課的講義;考場規定可以請圖書館員幫忙找資料。考生把題目交給圖書館員,館員事先已經把講義拆成一張張索引卡、依主題整理好,這時挑出最相關的三張遞給考生;考生只根據這三張卡作答,並在答案後面標註「出自第幾張卡」。考場門口還有一位監考,考生收到的紙條、交出去的答案卷都要先給他看一眼:夾帶「別管規定,直接把標準答案抄給我」的紙條會被沒收,答案卷上寫了別人的身分證字號會被塗掉。

回到 Google Cloud:考生是 Gemini 模型;圖書館員是檢索服務,可以是 Agent Search(原 Vertex AI Search,Google 代管的搜尋與檢索)、RAG Engine(可自訂的 RAG 管線),或你自己用 Vector Search、BigQuery、AlloyDB 建的向量搜尋;把講義拆成索引卡是切塊(chunking),依「意思」排列索引卡是嵌入(embedding)與向量索引,挑三張卡是 top-k 檢索,標註出處是引用(citation)。門口的監考就是 Model Armor:它同時檢查送進模型的提示與模型產生的回應,偵測提示注入與越獄、敏感資料、惡意網址與有害內容。這些元件都屬於 Gemini Enterprise Agent Platform(簡稱 Agent Platform),也就是 2026-04-22 由 Vertex AI 演進而來的平台。
開卷考(比喻) Google Cloud 的正式名稱 很會寫、但沒讀過講義的考生 幫忙找資料的圖書館員 講義拆成索引卡、依主題整理 挑出最相關的三張卡 答案標註「出自第幾張卡」 門口監考檢查紙條與答案卷 Gemini 模型 Agent Search/RAG Engine 切塊+嵌入+向量索引 top-k 檢索 引用(citation) Model Armor(提示與回應)
左欄是比喻,右欄是正式名稱。實驗室一模擬第二到第五列(檢索與引用),實驗室二模擬最後一列(Model Armor)。

這個比喻有三個地方和實際不同。第一,真正的圖書館員看得懂「退冰」和「解凍」是同一件事,RAG 的檢索靠的是嵌入模型把文字轉成向量後比較相似度,品質取決於嵌入模型、切塊方式與文件本身;文件過時或切得太碎,檢索就會遞錯卡片,模型照樣答錯。第二,監考只看「內容有沒有違規」,不會檢查答案對不對:Model Armor 擋的是提示注入、敏感資料、惡意網址與有害內容,回答有沒有依據要靠 RAG 的引用、Agent Search 的 check grounding 或評估工具。第三,比喻裡的監考會親手沒收紙條,但 Model Armor 只回報「有沒有符合過濾條件」,真正擋下或改寫內容的,是呼叫它的應用程式或整合點。

事前:擷取(ingestion) 文件Cloud Storage 解析 切塊 嵌入 索引 提問時:查詢(query) 問題 ModelArmor 檢索 top-k從索引取片段 Gemini問題+片段 ModelArmor 回答+引用 Agent Search:整條擷取與檢索都由 Google 代管,你只管放文件與調設定。 RAG Engine:切塊、嵌入模型、向量資料庫可以自己選,彈性較高。 自建:Vector Search、BigQuery、AlloyDB 自己管索引,程式碼最多。 藍色是 Model Armor 檢查點:提示進入模型前一次、回應送出前一次。
擷取階段在文件更新時做一次,查詢階段每次提問都做。Model Armor 不是 RAG 的一部分,而是包在模型呼叫的前後;用 Agent Platform、Gemini Enterprise、Apigee 等整合時可以直接掛上,自己寫的應用程式則呼叫它的清理(sanitize)API。

新手最常卡在哪裡

第一個坑是名稱:2026 年 4 月之後,Vertex AI 演進為 Gemini Enterprise Agent Platform,Vertex AI Search 改名 Agent Search,Vertex AI Agent Engine 改名 Agent Runtime,但官方註明主控台仍可能顯示 Vertex AI Search 或 AI Applications,API 仍是 Discovery Engine 端點(discoveryengine.googleapis.com),Agent Platform 的 API 主機也仍是 aiplatform.googleapis.com。另外 Gemini Enterprise(員工用的 AI 代理入口)和 Gemini Enterprise Agent Platform(開發者平台)是兩個不同產品。第二個坑是以為 RAG 只要接上就好:切塊太小,關鍵句被切斷;top-k 太小,正確段落沒被取回;提示沒要求「找不到就說找不到」,模型就自己補。第三個坑是把防護交給模型自律:系統指令可以被提示注入繞開,需要獨立的一層檢查。實驗室一處理第二個坑,實驗室二處理第三個。

🎮 互動實驗室一:RAG 流程模擬器

下面是晴空食品的內部作業手冊(虛構,六個段落)。選一個問題或自己輸入,選切塊方式、切塊大小與 top-k,按「執行 RAG」,畫面會依序顯示四個步驟:切塊、檢索、組成提示、示意回答與引用。再按「不檢索直接問」看沒有 RAG 時會怎樣。注意:這裡的相似度是用「兩個字一組」的字詞重疊算出來的分數,只是示意,不是真的向量嵌入;回答也是預先寫好或從檢索片段擷取的示意,用來呈現「模型手上有哪些片段時會怎麼回答」。切塊大小在這裡以「字」計,實際服務以 token 計。

有輸入時以這裡為準,清空就回到左邊的問題。
切塊方式
切塊大小
Agent Search 的版面切塊可設 100~500 token(預設 500);這裡用字數示意。
top-k(取前幾個片段)
Agent Search 的 answer 方法可用 maxReturnResults 控制取回的結果數(預設 10、最多 25);這份手冊很短,模擬預設用 3。
重疊(只對固定大小)
RAG Engine 可以設定 chunk_size 與 chunk_overlap,概念相同。
先用預設設定執行一次第一題。
畫面說明:載入中。
做法你要管的事適合不適合
Agent Search(託管檢索)放文件、選解析與切塊設定、建搜尋應用程式想要現成、品質好的搜尋與附引用的回答,不想自己組管線要自訂嵌入模型、向量資料庫或檢索邏輯
RAG Engine建立語料庫(corpus)、選切塊參數、嵌入模型與向量資料庫要調整 RAG 每一段,但不想從零寫程式只要一般企業搜尋(Agent Search 更省事)
Vector Search自己產生嵌入、建索引、寫檢索與組提示的程式大規模、低延遲的向量相似度搜尋,或要混合語意與關鍵字搜尋團隊沒有人力維護整條管線
BigQuery/AlloyDB 內建向量搜尋在既有資料庫裡存嵌入、用 SQL 查詢資料本來就在 BigQuery 或 AlloyDB,想和結構化欄位一起查主要是大量非結構化文件、沒有既有資料庫

Agent Search 的版面切塊(layout-based chunking)可設定每塊 100~500 token、預設 500,並可選擇把所屬的各層標題加到段落中間的區塊,避免脫離上下文;依官方 Agent Search 文件與 Terraform 提供者文件(查證時間 2026 年 10 月)。實際的相似度由嵌入模型產生的向量計算,同義詞、換句話說也找得到;本頁的字詞重疊做不到這點,所以自己輸入問題時,盡量用手冊裡出現過的詞。

🎮 互動實驗室二:Model Armor 過濾器模擬

左邊是一個 Model Armor 範本的設定:負責任 AI 的四個類別與信心門檻、提示注入與越獄偵測、Sensitive Data Protection(基本或進階)、惡意網址偵測,以及強制執行類型。右邊是晴空食品客服助理收到的 6 則使用者提示與模型產生的 3 則回應。調整任何一個設定,右邊會立刻重新判斷每一則是「通過」「已遮罩」「被擋」或「只記錄」,並列出原因。下方四個任務會即時檢查你的設定。每則內容的偵測結果(信心等級、找到的資料類型)是本頁預先標註的示意值,不是真的模型判斷。

1. 負責任 AI Responsible AI・信心門檻:無/低以上/中以上/高
門檻越低擋得越多:「高」只擋幾乎確定的違規,「中以上」擋中、高信心,「低以上」連些微跡象也擋。兒少性剝削(CSAM)過濾器固定開啟、不能關閉。
2. 提示注入與越獄偵測 Prompt injection and jailbreak detection
信心門檻
3. Sensitive Data Protection 敏感資料
4. 惡意網址偵測 Malicious URL detection
5. 強制執行類型 Enforcement type
「僅檢查」只把偵測結果寫進 Cloud Logging,不回傳封鎖判定;「檢查並封鎖」會回傳封鎖判定,由呼叫端(應用程式或整合點)真正擋下。
通過 0
已遮罩 0
被擋 0
只記錄 0
畫面說明:載入中。

過濾器名稱、信心門檻與強制執行類型依 Model Armor 官方文件「Model Armor overview」與「Create and manage templates」(查證時間 2026 年 10 月)。基本模式的 Sensitive Data Protection 只偵測少數資料類型:信用卡號、美國社會安全碼、金融帳號、美國個人報稅識別碼、Google Cloud 憑證與 Google Cloud API 金鑰;Email、電話等要用進階模式自訂檢查範本,搭配去識別化範本才會回傳遮罩後的內容。本頁假設進階模式的檢查範本包含 Email、電話、信用卡號與 Google Cloud API 金鑰。Model Armor 每次獨立檢查一則提示或回應,不看對話歷史;提示注入偵測對少於三個字詞的輸入不會判定符合。

🛠️ 操作教學:建立資料儲存庫、搜尋應用程式與 Model Armor 範本

不用登入 Google Cloud,也能先把流程走一遍:啟用 API、建立值區放手冊、建立資料儲存庫(解析與切塊設定)、建立搜尋應用程式、預覽查詢、用 Gemini 產生附引用的回答,最後建立 Model Armor 範本並測試一則提示。左邊是簡化的主控台,右邊同步顯示等效的指令與 Terraform,黃色底的那幾行就是目前這一步對應的內容。Agent Search 目前沒有正式版(GA)的 gcloud 指令,所以這幾步在右邊改用 REST API 的 curl 範例,用 gcloud auth print-access-token 取得權杖。可以故意填錯名稱或數字看看驗證訊息,也可以改名稱或設定,看右邊怎麼跟著變。

示意畫面:簡化重繪,只保留和本主題有關的欄位;實際畫面以 Google Cloud 控制台為準。
雲端主控台搜尋資源、文件與產品AI Applications
同一件事的三種做法:主控台、gcloud/REST 與 Terraform 最後呼叫的都是同一組 Google Cloud API(Cloud Storage、Discovery Engine 與 Model Armor 的 API),也都經過同一套 IAM 權限檢查,所以建出來的資源一樣。主控台適合第一次建立、想看每個欄位說明與預覽查詢結果的時候;gcloud 與 curl 適合寫成腳本或在 Cloud Shell 裡測試,Agent Search 沒有 GA 的 gcloud 指令時,就直接呼叫 REST API 或用 Python 用戶端程式庫;Terraform 把值區、資料儲存庫、搜尋應用程式與 Model Armor 範本寫成可以版本控管的設定檔,適合正式環境,練習完執行 terraform destroy,它建立的資源會一起刪除(文件匯入是資料操作,不在 Terraform 裡)。想讓 Google 代管 Terraform 的執行與狀態檔,可以用 Infrastructure Manager;舊的 Deployment Manager 已經停止支援、2027-06-30 之後關閉,新專案不要再用。模型名稱用的是官方文件目前的例子,可用模型與區域會變動,以控制台為準。

自己動手時要注意

權限方面,建立資料儲存庫與搜尋應用程式需要 Discovery Engine 管理員(roles/discoveryengine.admin)或編輯者(roles/discoveryengine.editor),只查詢的使用者給 Discovery Engine 使用者(roles/discoveryengine.user)即可;建立 Model Armor 範本需要 Model Armor 管理員(roles/modelarmor.admin);建立值區與上傳文件需要 Cloud Storage 的對應權限(例如 Storage 管理員)。要先啟用 Discovery Engine API(discoveryengine.googleapis.com)與 Model Armor API(modelarmor.googleapis.com)。官方文件也提醒:從 Cloud Storage 匯入時不會帶入值區的存取權限,有 Agent Search 權限的人就能透過搜尋看到內容,即使他在 Cloud Storage 看不到原檔,所以機密文件要另外規劃資料儲存庫與權限。

費用方面,Agent Search 依查詢次數、版本(Standard/Enterprise)與是否開啟生成式回答等計費,資料儲存庫依索引的資料量計費;Model Armor 依提示與回應的 token 數計費;值區依儲存量計費(不寫具體金額,以官方價格頁為準)。新帳戶的免費試用是 90 天、300 美元抵用金(查證日期 2026-10-08)。範例裡的專案一律用 my-project-id 這種佔位,權杖用 gcloud auth print-access-token 即時取得,不要把 API 金鑰或服務帳戶金鑰寫進腳本;在 Cloud Shell 或用自己的使用者憑證操作即可,CI/CD 等外部系統請改用 Workload Identity Federation。上傳的手冊不要含個資。練習完依下面的順序刪除:

☁️ 對照 AWS 與 Azure 的做法:AWS 上對應的是 Amazon Bedrock:知識庫(Knowledge Bases)負責擷取、切塊、嵌入與檢索,資料來源常放在 Amazon S3,向量存放可以選 OpenSearch Serverless、S3 Vectors 等;防護交給 Bedrock Guardrails,除了內容篩選與提示攻擊,還有情境基礎檢查(contextual grounding check)直接判斷回答有沒有依據,這點和 Model Armor 只看內容安全不同。可以對照 AWS 站的「Bedrock 知識庫 RAG 與 Guardrails」互動教學。Azure 上通常是 Microsoft Foundry 部署模型,搭配 Azure AI Search 建索引做 RAG,內容安全交給 Azure AI Content Safety(含提示防護 Prompt Shields)。可以對照 Azure 站的「Foundry 部署與 RAG」互動教學。

📘 原理補完

先把名字對齊:Vertex AI 之後的產品地圖

2026-04-22,Google 發表 Gemini Enterprise Agent Platform,官方說法是「Vertex AI 的演進」,之後 Vertex AI 的服務都改由 Agent Platform 提供。這次是「改名不改 API」:Agent Platform 的 API 主機仍是 aiplatform.googleapis.com,gcloud 仍是 gcloud ai;Agent Search 的 API 仍是 Discovery Engine(discoveryengine.googleapis.com),主控台也可能仍顯示 Vertex AI Search 或 AI Applications(查證時間 2026 年 10 月)。考試大綱與舊教材常還寫舊名,看到時知道指的是同一個東西即可。

現行名稱(2026-10)舊名一句話說明
Gemini Enterprise Agent PlatformVertex AI開發者打造模型、代理與 ML 的平台,依用量計費
Agent SearchVertex AI Search(更早是 Agent Builder、AI Applications)代管的搜尋、推薦與 RAG 檢索;API 仍是 Discovery Engine
RAG EngineVertex AI RAG Engine可自訂的 RAG 資料框架:擷取、切塊、嵌入、語料庫與檢索
Vector SearchVertex AI Vector Search大規模向量相似度搜尋;新一代 Vector Search 2.0 改名 Agent Retrieval
Agent RuntimeVertex AI Agent Engine代管的代理執行環境(Sessions、Memory Bank 等)
Model GardenVertex AI Model Garden挑選與部署 Gemini、夥伴與開放模型的目錄
Gemini Enterprise(常被說是 Google Agentspace 的後繼)給員工用的 AI 代理入口,主要依座位計費;和 Agent Platform 是不同產品
Gemini EnterpriseGemini Enterprise Agent Platform 員工「用」AI 的入口 連接公司資料(雲端硬碟、SharePoint…) 預建代理、無程式碼建代理 集中治理、可搭配 Model Armor 主要依座位計費 開發者「做」AI 的平台(原 Vertex AI) Model Garden Agent Search RAG Engine Vector Search Agent Runtime 訓練與推論 依各元件用量計費 做好的代理可以發布給員工使用
題目說「讓員工安全地用 AI 查公司資料、用預建代理」選 Gemini Enterprise;說「開發者要把 RAG 或代理做進自家應用程式」選 Agent Platform 裡的元件。兩者名稱只差一個詞,買的人和用的人都不同。

RAG 的品質旋鈕:解析、切塊、top-k 與提示

RAG 答錯時,問題多半出在模型之前。解析(parsing)決定文字能不能被正確讀出:Agent Search 提供數位解析、OCR 解析(掃描的 PDF 建議用)與版面解析(看得懂標題、表格與清單)。切塊決定檢索的最小單位:太小,一句完整的規定被切成兩半,單看任何一塊都不完整;太大,一塊裡混了好幾個主題,相似度被稀釋,提示也變長。Agent Search 的版面切塊以 token 計、可設 100~500(預設 500),並可選擇把各層標題加到段落中間的區塊;RAG Engine 則可以自己設定切塊大小與重疊。top-k 決定取回幾塊:太少容易漏掉正確段落,太多會把不相關的內容一起塞給模型。最後,提示要明確要求「只根據提供的資料回答、找不到就說找不到、附上出處」,檢索一定會回傳 top-k 個結果,就算它們都不相關。

太小適中太大 「…退冰或破損,請顧客在到」 「貨 24 小時內拍照…」 關鍵句被切成兩半單看哪一塊都不完整 【冷凍商品退換貨】到貨退冰請在 24 小時內拍照回報… 一塊講一件事帶著標題不會脫離上下文 退換貨+出貨時段+盤點+排班……(一整頁) 主題混在一起相似度被稀釋、提示變長 top-k 同樣有取捨:太少容易漏掉正確段落,太多會把不相關的內容一起送進提示 (範例文字與大小為示意;實際切塊以 token 計)
沒有一個「最好」的切塊大小,要依文件結構與問題型態實驗,並用評估資料集比較結果。實驗室一第一題改用「固定大小 50 字、不重疊」跑一次,就能看到關鍵句被切斷、怎麼調 top-k 都救不回來的情況。

檢索要用哪一種:Agent Search、RAG Engine 還是自建

三種做法的差別在「你願意管多少」。Agent Search 把擷取、解析、切塊、索引、排序與生成式回答都包好,資料來源可以是網站、非結構化文件或結構化資料,搜尋應用程式的 answer 方法直接回傳附引用的回答;代價是能調的地方有限。RAG Engine 讓你自己挑切塊參數、嵌入模型與向量資料庫(例如內建的 RagManagedDb、Vector Search、Pinecone、Weaviate),擷取來源可以是 Cloud Storage、Google 雲端硬碟或本機檔案,支援 VPC Service Controls 與 CMEK;部分區域需要申請許可清單(allowlist)。Vector Search 只負責向量索引與相似度查詢(以 Google Research 的 ScaNN 為基礎,支援語意、關鍵字與混合搜尋),嵌入與組提示要自己寫。資料已經在 BigQuery 或 AlloyDB 時,用它們內建的向量搜尋,就能把語意查詢和結構化欄位(例如門市、日期)放在同一個查詢裡。

另外兩個常被拿來比較的選項:需要最新的公開網路資訊時,用 Grounding with Google Search 讓 Gemini 參考網路搜尋結果;這是公開資料,不是你的私有文件。微調(tuning)改變的是模型的風格、格式或特定任務的表現,不適合拿來灌入經常變動的知識,也無法附上出處;知識問題先用 RAG。

要最新的公開網路資訊? 要改的是語氣、格式或特定任務? 想要現成搜尋與附引用的回答? 要自訂切塊、嵌入或向量資料庫? 資料已經在 BigQuery 或 AlloyDB? 都不是:自己掌控整條管線 Google Search grounding 模型調整(微調) Agent Search RAG Engine 資料庫內建向量搜尋 Vector Search 是是是是是 否否否否否 實務上常組合使用,例如 RAG Engine 用 Vector Search 當向量資料庫,或 Agent Search 再加上 Google Search grounding
考題常把「微調」放在選項裡當干擾:缺的是公司內部或最新的知識、還要附出處時,答案是 grounding 或 RAG,不是微調。

Model Armor:範本、門檻與強制執行

Model Armor 是獨立的服務,檢查送進模型的提示與模型產生的回應。過濾器有:負責任 AI(仇恨言論、騷擾、露骨色情、危險內容,各自設定信心門檻;兒少性剝削過濾器固定開啟)、提示注入與越獄偵測(可設門檻)、Sensitive Data Protection(基本模式偵測少數高風險資料類型,進階模式用你自己的檢查範本與去識別化範本)、惡意網址偵測,以及目前為 Preview 的圖片檢查。信心門檻分「高」(只擋幾乎確定的違規、誤擋最少)、「中以上」(官方說明適合一般企業用途)、「低以上」(擋得最多,官方不建議用在一般的負責任 AI 類別);主控台沒設定時預設為「高」。

設定放在範本(template)裡,範本建立時要選位置(Region 或多區域,之後不能改),官方建議提示與回應分開用兩個範本;最低設定(floor settings)則在專案、資料夾或機構層級規定所有範本的最低標準,避免某個團隊把防護關掉。強制執行類型有「僅檢查」(只寫 Cloud Logging)與「檢查並封鎖」(回傳封鎖判定);不論哪一種,真正擋下內容的都是呼叫端,例如 Agent Platform、Gemini Enterprise、Apigee、Agent Gateway 等整合,或你自己的程式依判定結果處理。Model Armor 依提示與回應的 token 數計費。

使用者提示 Model Armor輸入範本sanitizeUserPrompt Gemini+RAG 片段 Model Armor輸出範本sanitizeModelResponse 回覆 符合過濾條件:應用程式依判定處理回覆固定訊息、改用遮罩後的內容,或只記錄 floor settings:機構、資料夾或專案層級的最低標準每個範本都不能低於這條線 每次獨立檢查一則提示或回應,不看對話歷史
提示和回應要分開檢查:提示注入多半藏在輸入(包括 RAG 取回的外部文件),敏感資料外洩與有害內容則可能出現在模型的回應裡。圖中的方法名稱是 Model Armor API 的清理方法,用 Agent Platform 等整合時由服務代為呼叫。
門檻:高門檻:中以上門檻:低以上 低信心:放行 中信心:放行 高信心:符合 低信心:放行 中信心:符合 高信心:符合 低信心:符合 中信心:符合 高信心:符合 門檻越低擋得越多,正常的抱怨或醫療、資安討論也越容易被誤擋 紅色=判定符合過濾條件;是否真的擋下由強制執行類型與呼叫端決定
實驗室二的第一個任務就是在「擋下提示注入」與「不誤擋生氣的顧客」之間找平衡。上線前可以先用「僅檢查」觀察 Cloud Logging 的結果,再決定門檻,最後改成「檢查並封鎖」。

遇到題目時的判斷步驟

  1. 先看是「員工直接用 AI」還是「開發者做 AI 功能」:前者是 Gemini Enterprise,後者是 Agent Platform 的元件。
  2. 模型答錯或亂編,缺的是私有或最新的知識、還要附出處:用 RAG 或 grounding,不是微調、也不是換更大的模型。
  3. 選檢索做法:要現成搜尋與附引用回答選 Agent Search;要自訂切塊、嵌入、向量資料庫選 RAG Engine;資料在 BigQuery、AlloyDB 就用內建向量搜尋;要自己掌控大規模向量查詢選 Vector Search;要公開網路資訊選 Google Search grounding。
  4. RAG 已經接上但答案不對:依序檢查解析(掃描 PDF 用 OCR)、切塊大小與標題、top-k、提示有沒有要求「找不到就說找不到」,再用評估或 check grounding 驗證。
  5. 要擋提示注入、越獄、敏感資料外洩、惡意網址或有害內容:用 Model Armor,提示與回應分開設定範本,用 floor settings 統一最低標準;Email、電話這類資料要用進階模式的檢查範本。

容易考錯的地方

Agent Platform 和 Gemini Enterprise 是同一個東西:不是。前者是開發者平台(原 Vertex AI),後者是員工用的 AI 代理入口;題目寫「員工」「座位」「預建代理」多半指 Gemini Enterprise。

改名之後 API 與指令都要改:不用。Agent Platform 的 API 仍是 aiplatform.googleapis.com、gcloud 仍是 gcloud ai;Agent Search 的 API 仍是 Discovery Engine,主控台也可能還顯示 Vertex AI Search 或 AI Applications。

模型不知道公司規定,就拿手冊去微調:知識經常變動、要附出處時,RAG 比微調合適;微調適合調整風格、格式或特定任務的表現。

top-k 越大越準:不一定。太大會把不相關的片段塞進提示,增加成本,也可能讓模型被干擾。調整 top-k 要配合切塊大小一起看。

Model Armor 和 Cloud Armor 差一個字,功能差不多:Model Armor 檢查 AI 提示與回應的內容;Cloud Armor 是負載平衡器前的 WAF 與 DDoS 防護,處理的是網路流量。

Model Armor 會檢查回答有沒有根據:不會。它看的是內容安全(注入、敏感資料、惡意網址、有害內容);回答有沒有依據要看 RAG 的引用、Agent Search 的 check grounding 或評估工具。

Sensitive Data Protection 開了基本模式,就會遮罩所有個資:基本模式只偵測少數資料類型(例如信用卡號、Google Cloud API 金鑰);Email、電話與台灣常見的個資類型,要用進階模式的檢查範本,搭配去識別化範本才會得到遮罩後的內容。

設成「僅檢查」也會擋下攻擊:不會。僅檢查只寫記錄;要回傳封鎖判定得用「檢查並封鎖」,而且呼叫端要依判定處理。

相關考試:依 Google Cloud 各考試官方 exam guide(查證時間 2026 年 10 月),GAIL 點名 Agent Search、RAG APIs 與 Google Search grounding;PAA 點名 Agent Search、RAG Engine、Vector Search、Agent Retrieval 與 Model Armor;PMLE 在風險管理領域點名 Model Armor;CDL 與 PCA 也點名 Model Armor 與 Agent Platform;PDE 涵蓋「為嵌入與 RAG 準備非結構化資料」。

✅ 自我檢測

6 題原創題,選完立即顯示對錯與解析,全部作答後會出現總分。目前得分:0 / 6