護欄Guardrails

護欄在擋什麼

「護欄」不是單一功能，而是一整套限制機制的統稱，通常分佈在系統的不同環節：

1. 1

   輸入端檢查

   使用者送出的內容先經過檢查，過濾明顯的惡意指令、敏感資料、或不符合使用範圍的請求。

2. 2

   系統提示詞約束

   在模型看到使用者輸入之前，先用系統層級的指令設定行為邊界，例如「只回答與產品相關的問題」。

3. 3

   模型生成過程

   部分平台在生成階段就加入內容政策限制，直接影響模型會不會生成某類內容。

4. 4

   輸出端檢查

   模型生成的內容送到使用者之前，再經過一層檢查，攔截不該出現的內容、格式錯誤，或明顯偏離任務範圍的回答。

為什麼需要它

AI 應用直接面對使用者輸入，攻擊面很大。 只要是開放輸入的系統，就有人會嘗試 prompt injection 或 jailbreak 讓 AI 做超出設計範圍的事，護欄是第一道防線。

AI 的輸出本身不可完全預測。 即使沒有惡意攻擊，模型也可能因為 幻覺 或誤解而生成不該出現的內容，輸出端的檢查能在問題送到使用者面前先攔下來。

部署到真實場景，責任在你身上。 一旦 AI 應用對外提供服務，生成的內容、做出的行為，責任通常落在建置系統的一方，護欄是把風險控制在可接受範圍內的必要成本。

常見的護欄類型

類型	做的事	常見弱點
關鍵字／規則過濾	偵測特定字詞或模式並攔截	容易被換句話說繞過，也容易誤傷正常內容
系統提示詞約束	用指令限定角色、範圍、語氣	面對刻意設計的提示詞攻擊時可能被覆蓋
另一個模型審查	用獨立的模型檢查輸入或輸出是否合規	增加延遲與成本，審查模型本身也可能誤判
結構化輸出驗證	要求輸出符合特定格式，格式不對就拒絕	無法處理格式正確但內容有問題的情況

單一類型都有各自的弱點，這也是為什麼實務上通常組合多種機制一起用。

對開發者的實際建議

先想清楚系統的攻擊面。 使用者能輸入什麼、AI 能做什麼動作（尤其是有沒有連到 Function Calling），範圍越大，需要的護欄越完整。

輸出端的檢查不能省略。 很多團隊只在輸入端花心思，卻忽略輸出內容同樣可能出問題，尤其是模型被誘導後生成的內容。

護欄要能持續調整，不是設完就結束。 攻擊手法會演進，使用情境也會擴展，護欄規則需要隨著實際使用中蒐集到的案例定期檢視與更新。

延伸閱讀：Prompt Injection 是什麼、Jailbreak 是什麼、對齊是什麼。