拿一般的大型語言模型（LLM），加上一段「請判斷這段文字是否安全，只回答 Safe 或 Unsafe」的提示，就能開始做安全判斷。既然如此，為什麼還要另外找一個 Guardian LLM？
一般 LLM 可以承擔這項工作。但兩個模型都回傳 Unsafe，只說明輸出看起來相同，還不知道它們依據哪些風險定義、接受了哪些訓練，以及判斷是否適用於眼前的服務。
前面幾篇已經把企業會遇到的問題拆開：內容是否有來源支持、文件是否試圖改寫指令、Agent 是否越過授權。接著要選擇元件時，先確認模型能判斷哪一項風險，再看這次判斷要付出多少成本與等待時間。
專用安全模型（Dedicated Guardian）通常經過針對安全或風險判斷的訓練，用來檢查使用者輸入、模型回覆，或其他指定內容。通用 LLM 則可以透過提示與評分準則，扮演評審（LLM-as-a-Judge）。兩者的差別，包含訓練目標與既有判斷能力，不是單純比較參數大小。
Qwen3Guard-Gen 就是一個例子：它以安全標註的提問與回答訓練，透過生成文字完成安全分類，輸出安全程度與風險類別。這是一個專用 Guardian，同時也在執行分類任務。
再看 IBM Granite Guardian HAP-38M，它是針對英文仇恨、辱罵、髒話與其他有害內容訓練的二元分類器，使用精簡的 RoBERTa 架構。它屬於 Guardian 家族，卻不需要像聊天模型一樣生成一段回答。
因此，把 Guardian LLM、一般 LLM、分類器（Classifier）排成三種互斥的選項，容易混淆。專用或通用，談的是模型為哪些任務準備；生成標籤或直接分類，談的是它如何產生判斷。專用 Guardian 可以採用不同做法，通用 LLM 也可以被要求輸出分類標籤。
這個區分會影響需求怎麼寫。只需要辨認某種固定風險時，應先確認分類器能否完成任務；需要讀懂對話、比對政策或來源時，則要確認模型實際支援哪些輸入與判斷。會聊天、會推理，不能直接推成每一項防護能力都已具備。
Guardian 的風險分類體系（Taxonomy），會決定它把哪些內容視為風險、類別之間怎麼分，以及最後的標籤代表什麼。
Qwen3Guard 將安全程度分成 Safe、Controversial 與 Unsafe。Controversial 指有害與否可能依情境而異，或不同應用會有不同判斷的內容。它不是一次逾時，也不是模型沒有成功執行。應用要依自己的政策決定如何處理這個類別。官方安全政策也列出各類風險的定義。
個資尤其適合用來看這個差別。這份政策中的個人可識別資訊（PII）類別，關注未經授權的敏感個資分享或揭露。如果企業真正想問的是「文字裡是否包含姓名、電話與地址」，這與「是否發生未經授權揭露」就不是同一個問題。
假設文字來自核准的地址修改表單，裡面有電話和地址。偵測個資存在，應該找得到這些內容；至於能否交給指定服務處理，還要看目的端與授權。換成同一份內容準備公開貼出，政策判斷又會不同。這是情境示意，沒有假定某個模型會輸出哪一種結果。
因此，一個 Guardian 回傳 Safe，不能直接解讀成「沒有個資」。同樣地，標出 PII 類別，也未必會提供姓名、電話的精確位置，更不代表已經產生可交付的遮罩版本。這些需求要從模型的輸入、輸出與支援任務逐一確認。
比較模型時，這個問題會比榜單名次更早出現。若通用 LLM 被要求判斷「是否含個資」，另一個 Guardian 依自己的政策判斷「是否未經授權揭露」，把兩者的安全標籤直接算成答對或答錯，可能是在比較兩個不同的任務。先讓測試標準與判斷問題對齊，才有辦法討論誤擋與漏擋。
其他風險也需要各自的依據。判斷來源支持度，要有當次檢索文件；涉及 Agent 授權，則要接到可信的業務狀態與權限控制。把內容分類的安全標籤一路延伸成整個任務都能放行，會超出模型實際回答的範圍。
一般 LLM 適合拿來探索需要理解文字的政策條件。例如企業規定客服「可以說明退款程序，但不可承諾退款結果」，可以把規定與候選回覆交給模型，請它判斷文字是否已形成承諾。這與偵測髒話不同，需要讀懂業務限制和句子的意思。
在政策仍會調整、案例不多，或檢查結果先交由人審閱的階段，透過提示修改問題，可以先釐清判斷需求。代價是企業需要自己維護評分準則、輸入條件與結果解析，並確認它在實際語句上判得如何。模型寫出一段流暢理由，不能替代這些確認。
專用 Guardian 也未必只能使用固定分類。Granite Guardian 4.1 的官方模型卡支援自訂判斷準則（Bring Your Own Criteria，BYOC），讓使用者提供自然語言條件，再依指定格式輸出判斷。這表示「通用模型可以改政策、專用模型只能判固定類別」也不是可靠的分法。
真正要問的是：這個模型如何接受自訂條件，條件變動後需要驗證哪些案例，以及它是否能保留企業在意的例外。官方文件仍要求自訂準則經過測試，並明示這個版本只使用英文資料訓練與測試。拿來處理台灣客服的正體中文、引文或混合語句，需要另外確認適用性。
若現有通用 LLM 已在明確的任務與案例下，達到服務所需的判斷品質與等待時間，就有繼續使用的理由。改用專用 Guardian 時，則要說清楚這次替換改善的是哪一項需求。
TypeSafe AI 的 Jev提供另一種做法：把待檢查的文字、相關情境與自然語言準則交給模型，直接取得指定型別的結果與機率。它不生成一段評審回覆、而是按類別和針對使用者定義內容輸出機率/選項/評分；Noul 回傳條件成立的機率，Choice 在指定選項間做判斷，Score 則依設定的等級評分。TypeSafe 把這種定位稱為 System One，重點是讓軟體可以直接使用一項範圍明確的判斷。
相較於透過生成文字回傳標籤的 Qwen3Guard-Gen 或一般 LLM，Jev 省去判斷文字的生成與解析；相較於前述固定任務的 HAP 分類器，它可以用自然語言指定這次要檢查的條件。不過，Granite Guardian 也能接受自訂準則，直接輸出機率的分類器也早已存在。Jev 值得比較的是這些能力如何組合，以及在指定任務上的表現，不能只因為產品定位新，就推定比既有 Guardian 更準、更快。
放進護欄時，可以沿用前面的退款例子，把「回覆是否承諾退款結果」寫成一項明確條件；另外檢查輸入是否試圖繞過指令。多項獨立問題可以放在同一個請求中評估，再由應用依各項結果決定放行、阻擋或轉人工。原廠護欄範例採用的也是模型提供評估、應用設定門檻與處理方式的分工。退款案例在這裡是候選用法，尚未實測；實際退款權限、金額與核准狀態，仍應由可信的業務資料和程式檢查。
型別符合預期，只能讓結果容易接進程式，沒有保證語意判斷正確。官方也明示，機率校準（Calibration）是在一群預測上評估，無法保證單筆答案。文件中的 confidence是 Choice 與 Score 的機率分布統計，不是額外驗證過的正確率；Noul 則沒有獨立的 confidence 欄位。
而串流 Guardian 則多了一個時間上的要求。Qwen3Guard-Stream使用詞元（Token）層級的分類器，在文字逐步生成時持續判斷，並保留串流狀態。Jev 對一次送入內容的快速判斷，不能直接等同於這種增量偵測能力；若反覆送出尚未完成的回覆，檢查頻率、上下文與何時把文字交給使用者，仍得另外設計。兩者可以成為不同位置的候選元件，例如串流 Guardian 檢查生成中的內容，Jev 評估傳送前的業務準則；這是組合方式的設計推論，是否值得採用，還要一起計算判斷品質、等待時間與呼叫成本。
分類器可以直接產生類別分數；生成式 Guardian 或通用 LLM，則可能需要先讀取政策、對話與文件，再生成判斷，有些還包含推理過程。最後只顯示一個 Safe，不代表前面的運算也只有一個詞。
所以，Guardian 不必然比較小，也不能預先認定專用模型一定比較快。對生成式模型而言，減少不必要的輸出，可以縮短部分生成工作；輸入很長時，讀取上下文、記憶體使用與服務排隊仍可能占重要部分。不同硬體、推論方式與同時進來的請求，也會影響結果。
窄範圍分類器可以作為降低運算負擔的候選，但省下來的能力範圍不能藏起來。英文 HAP 分類器的低延遲用途，無法直接回答繁中退款承諾是否越權。若為了補足缺口，後面每筆都得再叫另一個模型，整體成本就要把後續檢查與等待一起計入。
自架模型要承擔硬體、容量與維運成本；使用託管服務則要看計費方式、資料能否送出，以及實際服務限制。選型時應比較同一項任務、相近輸入長度與預期流量下的代價，並把判錯後的重查、人工處理和服務中斷納入。單看參數量或每次呼叫單價，很難決定哪個方案適合。
回到開頭，一般 LLM 判 Safe／Unsafe 可以是起點。專用 Guardian 則把某些風險判斷放進訓練目標，提供另一種選擇；是否適合，仍要看它判的問題是否與企業需求一致。
iThome鐵人賽
看影片追技術