選 Guardrails 元件，可以先從「這次需要拿回什麼結果」開始。

假設採購助手正在整理一份供應商比較報告。候選內容夾著不需要交付的姓名與私人電話，也多了一句「這家一定能在三天內交貨」，但提供給助手的資料沒有這項保證。需求是保留比較內容、移除指定個資，並擋下無來源的交期承諾。這是選型情境示意，沒有執行任何偵測器。

這份報告需要幾種不同的判斷。電話符合什麼格式、姓名出現在哪裡、交期保證有沒有依據，所需資料和輸出都不同。把它們包成一題「這份報告安全嗎」，很容易得到一個標籤，後續卻不知道該修改哪裡，也不知道到底檢查了哪一項要求。

Day 25 已說明 Guardian 與分類器可能重疊，Day 26 則處理生成、審查與交付的時間。接著要縮小候選範圍，就需要把要判斷的問題、判斷所需的輸入，以及處置需要的輸出放在一起看。

一張選型矩陣，先看元件回答哪個問題

下面的選型矩陣（Decision Matrix）用來找出值得驗證的候選。各列可能重疊，例如專用 Guardian 也能採用分類方式；表中的成本欄只列出應檢查的負擔，沒有假定哪一類一定比較快或便宜。

正規表示式（Regex）：比對明確的文字形式

Regex 適合處理能夠寫清楚形式的條件，例如電話的數字與分隔符號、公司定義的案件編碼，或明確禁止出現的字串。它把待掃描文字與規則比對，可以回傳命中的字串和位置，讓應用接著阻擋或遮罩。在採購報告的情境裡，如果電話格式已有明確定義，就可以先評估這種做法。規則也能搭配其他條件：Presidio 官方文件中的 PatternRecognizer 就支援 Regex、上下文詞與驗證邏輯。不過，單純的格式命中只找到候選；相似的數字也可能是案件代碼，電話換了分隔符號或寫法則可能漏掉。這類護欄的維護工作，是確認規則涵蓋哪些變體、如何處理例外，以及命中後依哪項政策採取動作。規則可以逐條檢視，但不能因為容易解釋，就把沒有命中當成整份內容已經安全。

命名實體辨識（NER）：找出實體類型與文字範圍

姓名、機構名稱等內容不容易靠一種固定格式列完，NER 的任務就是從文字中找出受支援的實體，替相應片段標上類別。spaCy 的 NER 文件以模型預測實體範圍與類別，也提醒結果依賴訓練資料。對採購報告而言，這讓 NER 成為定位姓名的候選；選用時要確認實體類別、語言與領域是否符合需求，再看台灣姓名、縮寫和中英混合語句的實際辨識情況。取得位置後，應用才有辦法修改指定文字；但一般 NER 找到的機構、地名或姓名，並不全是這次政策要求移除的個資，仍須界定要處理哪些類別與情境。PII 分析器也可能把 NER 與規則放在同一套工具裡：Presidio 官方文件中的 RecognizerResult 就包含實體類型、分數及起訖位置。因此，評估的對象應包括工具實際使用的辨識器，以及結果能否對回待遮罩的那一版原文。

分類器（Classifier）：判斷內容是否落入指定類別

這裡談的是訊息或文件層級的分類器：把該任務所需的文字或對話送進去，取得類別標籤或分數，例如是否含有某類有害內容、是否偏離服務範圍。若需求是命中某類風險後拒絕整份交付，這種結果可能已足以接到處置；若要保留報告、只移除其中幾個字，文件標籤通常還不夠，必須另外取得定位結果。分類器的能力要依任務看，例如 Granite Guardian HAP-38M是針對英文有害內容的二元分類器，不能只因為能回傳風險分數，就拿來判斷採購報告的交期保證有沒有依據。分數也需要配合標註案例設定門檻：把門檻調得更嚴，可能增加誤擋；調得更寬，則可能漏掉目標風險。選型時應確認分類定義與語言，再衡量服務能接受哪種判錯後果，而不是直接沿用另一個場景的門檻。

專用安全語言模型（Guardian LLM）：依支援的安全準則判斷風險

Guardian LLM 通常經過安全或風險判斷的專門訓練，用來評估使用者輸入、模型回覆或指定上下文。它的輸出仍可能是分類結果，例如 Qwen3Guard-Gen透過生成文字回傳安全程度與風險類別；所以 Guardian 與 Classifier 可以重疊，前者描述用途與訓練方向，後者描述判斷任務。選用時，要讀模型的風險分類體系（Taxonomy）、輸入角色與結果定義，確認它在檢查哪一種風險。企業條件若超出既有分類，就要查是否接受自訂準則，例如 Granite Guardian 4.1提供這項能力，但官方仍要求測試自訂條件，並明示只使用英文資料訓練與測試。對正體中文採購報告，專用訓練只能提供候選理由；是否能辨認這次在意的風險、能否交出處置所需的結果，以及讀取上下文和產生判斷的成本，都需要按實際需求確認。

語言模型評審（LLM-as-a-Judge）：把內容與明確準則放在一起評估

LLM-as-a-Judge 是讓語言模型依指定問題與評分準則評估內容的用法，可用於需要理解語意、比對前後文，或判斷內容是否符合某項業務要求的情境。以採購報告為例，要問「三天內交貨是否得到提供的文件支持」，就應一起送入候選主張和相關來源；要問「這段文字是否形成交期承諾」，則應交代承諾的判定準則與允許的說明範圍。兩題需要的依據不同，不能只給一句「請檢查是否安全」。評審可以依設計回傳判斷、理由與對應文字，方便人工複核，但理由本身仍可能出錯，解析成功也沒有證明語意正確。實際使用時，需要用已標註案例校準準則，並區分判斷不確定、資料不足與執行失敗；缺少來源或可信的授權資料，就應先補齊輸入或限制判斷範圍。這種彈性的代價包含上下文讀取、判斷輸出，以及政策、提示與解析規則的維護，不能只計算最後那個通過或失敗標籤。

需求不同，留下來的候選就不同

回到採購報告。如果要求是移除指定姓名和電話、保留其他內容，能交出原文位置的偵測器應先留下。固定形式的電話可以從 Regex 評估起，自由文字中的姓名則可考慮 NER 或支援相應實體的 PII 分析器。只回傳「這份文件有個資」的模型，還需要補上定位與文字處理，才有辦法完成遮罩需求。

如果政策只要整份阻擋，需求又會改變：文件層級的分類結果可能已足以接到拒絕交付的處置。相同風險，因為預期動作不同，適合的輸出介面也不同。不能把「判斷有沒有」和「保留內容但移除哪些字」當成同一項驗收。

交期保證則需要另一種依據。要查「一定能在三天內交貨」是否受供應商資料支持，就必須把相關來源與候選主張一起交給支援這項任務的評審。只看這句話是否有害，或只找「一定」這個詞，都沒有完成來源比對。若需求只是「客服不可形成交期承諾」，則是語意與政策判斷，不必假裝在驗證供應商的真實交貨能力。

這也表示，語意複雜度增加時，先要確認缺的是理解能力，還是判斷資料。沒有把來源送進去、沒有可信的授權狀態，換更大的模型也不能把那些資訊補成事實。選型矩陣有時會讓人得到「先補輸入」的結論，而不是選出另一個模型。

支援來源比對的 Guardian 也可以進入同一輪候選比較。例如 Granite Guardian 4.1提供 RAG 來源支持度的使用方式，並支援自訂準則；官方仍要求自訂條件經過測試，而且明示只使用英文資料訓練與測試。拿來判斷這份正體中文報告，需要確認的就是這些適用條件。

若需求是固定類別的有害內容篩檢，就可從該任務的分類器評估。例如 Granite Guardian HAP-38M的範圍是英文有害內容二元分類；Qwen3Guard-Gen則依其安全政策，生成安全程度與風險類別。把模型卡的任務、語言與結果定義對照需求，才知道這個候選是否該留下。

先對齊要求，才比較代價

候選留下來以後，才有公平的比較起點。若一個元件只掃電話，另一個同時讀文件、判斷交期，兩者的整次耗時不能直接用來決定誰比較適合。

對需要遮罩的報告，比較的終點應是能交付的處理版本。除了偵測，還要把位置轉換、遮罩、失敗重查的成本算進去；對來源比對，則要包含必要文件的讀取與判斷輸出。只看模型回傳標籤的時間，會漏掉完成需求所需的其他工作。

實測時也應保留同一項問題、同一份必要資訊與相同的預期處置。姓名漏掉、電話位置錯誤、正常敘述被當成承諾，會造成不同後果；不宜全部壓成一個總分，再讓低延遲掩蓋其中一項失敗。語言、文字長度與實際流量，也需要符合服務預計面對的條件。

成本同樣不只在推論。Regex 的變體與例外需要維護，分類器需要標註和門檻校準，評審需要維護政策與準則；誤擋之後的重查和人工處理，也會消耗資源。便宜元件若交不出需求所需的結果，補足缺口的代價仍要算回來。

參考資料

• spaCy：Named Entity Recognition
• Presidio：Analyzer、PatternRecognizer 與結果範圍
• Qwen：Qwen3Guard-Gen 模型卡
• IBM：Granite Guardian HAP-38M 模型卡
• IBM：Granite Guardian 4.1 模型卡、自訂準則與適用限制