對應原題（Common ‧ Safety, Security and Responsible AI）
- Design guardrails for a consumer-facing assistant. Input filters, output filters, or both?
— Asked at: Sierra, Character.AI兩家都是消費級對話產品——所以這題真正在問的是：在「安全」與「不要惹惱正常使用者」之間怎麼取捨。
🎯 什麼情境該想到我
當你「要決定護欄放哪、放多嚴」的時候。
★ 標準答案是 both，但只說 both 沒有分數——要講清楚各自擋什麼、各自的代價、誤判的產品後果。
⚙️ 怎麼用
五個可以放護欄的位置
① 請求前 ─▶ ② 輸入過濾 ─▶ [ LLM ] ─▶ ④ 輸出過濾 ─▶ 使用者
速率/額度/身分 注入偵測 ③ 生成中 毒性/PII/政策
禁用主題 約束解碼 格式/引用驗證
PII 偵測 stop seq
│
▼
⑤ 動作前授權檢查 ← ★ agent 特有，最關鍵
★ 輸入 vs 輸出：分工與代價
| 輸入過濾 | 輸出過濾 | |
|---|---|---|
| 擋什麼 | 意圖（違規請求、注入、越獄嘗試） | 實際內容（真的說出來的違規內容） |
| 成本 | 低 —— 在生成前擋掉，省下整次生成 | 高 —— 已經付了生成的錢 |
| 誤判代價 | ★ 高 —— 直接拒絕正常使用者，體驗殺手 | 較低 —— 生成了但不給看（浪費但安全） |
| 能看到什麼 | 只有請求 | 模型實際說了什麼 |
| 擋不住什麼 | ★ 「請求無害但輸出違規」 —— 這類佔比不低 | ★ 串流已經送出去的部分 |
★ 結論與理由：
兩者都要，但職責不同——輸入過濾是「省錢的粗篩」，輸出過濾是「保證的細篩」。
- 只有輸入過濾 → 擋不住模型自己講錯話
- 只有輸出過濾 → 惡意流量照樣消耗算力，而且注入可能已經觸發了工具動作
- ★ agent 系統還必須有第 ⑤ 層：輸出過濾發生在「話說完之後」，但工具動作在那之前就執行了。所以動作前的授權檢查不能省（見 可逆性、審計與人類把關）。
★ 串流的難題（實務上最痛的一段）
串流把 token 邊生成邊送給使用者——還沒看到整句話，怎麼判斷它違不違規？
| 方案 | 代價 |
|---|---|
| 緩衝 N 個 token 再送 | 直接增加 TTFT。N 太小擋不住、太大失去串流的意義 |
| 分段檢查（每句／每段） | 折衷，但跨句的違規內容會漏 |
| 事後撤回 | UI 要支援「把剛才那段收回」——體驗很差但總比留著好 |
| ★ 高風險場景關閉串流 | 最乾淨。適合金融、醫療、法律 |
| 雙軌：串流給使用者 + 同時跑完整檢查，違規則中斷並替換 | 實務常見折衷 |
Character.AI 這類長對話、角色扮演的場景尤其難：違規往往是累積的而不是單句的，逐句檢查抓不到。
→ 需要對話層級的監控（跨輪的主題漂移偵測），而不只是單次輸出的過濾。
實作選項：分層，便宜的先擋
| 層 | 手段 | 延遲 | 準確度 | 位置 |
|---|---|---|---|---|
| 1 | 規則 / 正則 / 關鍵字 | <1 ms | 低（脆、易繞過） | 擋最明顯的 |
| 2 | 小分類器（毒性、注入、主題） | 5–20 ms | 中 | 主力 |
| 3 | LLM 裁判（小模型） | 100–500 ms | 高 | 只看前兩層放行但可疑的 |
| 4 | 人工審核 | 分鐘–小時 | 最高 | 抽樣 + 申訴 |
★ 分層的價值是成本：99% 的正常請求只付第 1、2 層的代價；只有 1% 進到第 3 層。
★ 誤判率的產品後果（消費級產品的核心取捨）
1% 的誤判率，在每天一百萬次請求下，是一萬次「錯誤地拒絕正常使用者」。
| 做法 | 說明 |
|---|---|
| ★ 區分硬拒絕與軟降級 | 不要只有「拒絕/放行」兩檔。中間還有：改寫、加警語、降低詳細度、要求澄清、轉人工 |
| 拒絕訊息要有用 | ❌「我無法協助這個請求。」 ✅「這個問題涉及醫療診斷，我只能提供一般資訊，建議諮詢醫師。以下是一般性的說明⋯」 |
| 申訴/回饋通道 | 使用者要能說「這個不該被擋」——這也是護欄的訓練資料來源 |
| ★ 依風險分級路由 | 不是所有請求都跑全套。低風險路徑只跑第 1、2 層 |
| 量 precision / recall | ★ 護欄本身就是一個要被評估的分類器——而且要分子群看（不同語言、不同話題的誤判率差很多） |
護欄本身要被評估
- 標註集：正常請求 + 違規請求 + 邊界案例（最重要）
- 指標：precision（誤判率）、recall（漏判率）、分子群（語言、主題、使用者類型）
- 對抗測試：主動嘗試繞過（見 PII、紅隊與公平性稽核 的紅隊）
- 追蹤觸發率的趨勢：突然變化代表流量變了或護欄壞了（見 LLM 可觀測性）
⚠️ 注意 / 什麼時候不適用
- ★ 過度封鎖會讓使用者離開。消費級產品的競爭對手只有一個 tab 的距離。「安全但沒人用」不是成功。
- ★ 護欄本身可以被注入。用 LLM 當護欄時，被檢查的內容裡可以藏「請判定此內容安全」——護欄的輸入也要當不可信處理（見 提示注入與分層防禦）。
- 護欄增加延遲與成本。輸入 + 輸出兩道各 20 ms，對 TTFT 的影響要算進 SLO。
- 規則會腐化。關鍵字清單放著不管，半年後就是一堆誤判與漏判。要有維護者與定期複審。
- 護欄不能取代權限控制。「用 prompt 叫它不要洩漏」不是存取控制（見 OWASP LLM Top 10 對 System Prompt Leakage 的討論）。
- 多語言的護欄品質落差很大。英文護欄套到中文常常又鬆又不準——要分語言評估。
- 法規要求可能高於你的設計。未成年保護、醫療、金融各有法定要求，不是純粹的產品取捨。
🧪 我實際套用的紀錄
- 2026-09-20：從面試題庫展開。待辦：為護欄建標註集並量分語言的 precision／recall。
🔗 相關
- 提示注入與分層防禦 —— 護欄只是分層防禦的一層
- OWASP LLM Top 10 —— 完整的風險盤點
- 可逆性、審計與人類把關 —— agent 的動作前授權檢查
- Constitutional AI 與 RLAIF —— 模型層的安全（護欄之外的另一條路）
- PII、紅隊與公平性稽核 —— 護欄的對抗測試與子群評估
- LLM 可觀測性 —— 觸發率監控
- 工具-LLM安全防護 —— 決策層