Guardrail 的治理問題，不只是哪個模型更準
看到一組 guardrail 基準測試時，我第一個想到的不是冠軍是誰，而是我們究竟把什麼叫做「安全」交給了誰定義。
這篇 Red Hat Developer 的比較很有意思：它把 prompt injection 與 content safety 放在一起，測試小型專用 classifier、BART zero shot、LLM judge，以及 Jev 類 decision model。結果沒有一個系統在所有面向都勝出。Prompt injection 任務裡，兩億參數的 DeBERTa 已有 89.01% 準確率，延遲 54.1ms，和 35B 的 Qwen 89.31%、312.5ms 相比，準確率只差一點，反應時間卻是明顯不同的量級。內容安全則由 Jev 以 86.20% 領先，但延遲達 360.4ms。
工程上，這提醒我們不要被模型規模或「通用決策」的光環帶走。當任務有足夠標註資料，專用模型往往更便宜、更快，也較容易重現與除錯。資料不足、政策常變、需要跨情境判斷時，通用模型才可能提供彈性。但治理真正難的地方，正是準確率之外的代價。
第一是可問責。一次誤放攻擊提示，可能造成系統被繞過；一次誤殺正常內容，則可能讓使用者失去發言、求助或工作的機會。兩種錯誤不能只用同一個 accuracy 掩蓋，必須依使用情境分開計算，並記錄誰訂門檻、誰能申訴、誰負責覆核。
第二是在地化。content safety 並非全球一致的分類題。語言、方言、身分認同與社會脈絡都會改變「有害」的判斷。若基準資料主要來自單一語境，模型的高分可能只是對主流規範的高適應，對少數群體卻帶來更高誤殺率。
第三是制度成本。延遲不只影響體驗，也決定哪些組織用得起這套安全機制。資源有限的學校、地方政府或小型平台，若只能在昂貴模型與完全不防護之間選擇，治理就會變成特權。
所以，選 guardrail 不該是找一個永遠最高分的模型，而是先問：這個場景最不能承受哪種錯誤？誰會承擔後果？我們能否提供人工覆核、申訴與持續更新的資料？基準測試是起點，不是治理結論。真正成熟的安全設計，應該把模型表現、延遲、資源門檻與權力責任放在同一張評估表上。
作者：袁怡萱