Safety on Tarragon

Guardrail

Thu, 14 May 2026 00:00:00 +0000

Guardrail 的核心概念是「在 LLM 的 fuzzy 行為外層加上可驗證的控制邊界」。LLM 本身會生成機率性輸出，guardrail 用 deterministic 檢查、policy、structured output、權限與人工審查，把錯誤後果限制在可承擔範圍內。

概念位置

Guardrail 是一組控制層。常見形式包含 structured output、validator、allowlist、rate limit、sandbox、human approval、eval、monitoring 與 rollback。它通常包在模型輸出與下游副作用之間。

可觀察訊號與例子

客服分類可以用 enum schema 限制類別；tool use 可以用 allowlist 限制可呼叫工具；production 操作可以要求 human-in-the-loop approval；外部內容進 context 前可以標記為 untrusted，降低 prompt injection 後果。

設計責任

設計 guardrail 時先判斷失敗代價，再選控制強度。低風險任務用 schema 與 retry 即可；高副作用任務要加 permission boundary、sandbox、審查與 audit log。相關基礎見 Deterministic vs Fuzzy engineering。

Human-in-the-loop（HITL）

Thu, 14 May 2026 00:00:00 +0000

Human-in-the-loop（HITL）的核心概念是「人類在 LLM 工作流中介入的設計」、用來在 fuzzy AI 行為的關鍵節點插入 deterministic 人類判斷。HITL 不是「有 vs 沒有」的二元、是 spectrum：位置由 risk（副作用範圍 + 失敗代價）跟自動 validator 能力決定。

概念位置

HITL 三種觸發時機：

時機	介入點	適合任務
Pre-act	Action 執行前確認	不可逆 / 高代價（DB write、deploy）
Mid-stream	Agent 過程中遇不確定主動問	路徑分歧、需要 domain judgment
Post-hoc	結果交付後 user 申訴 / 校正	評分類、低代價、user 數量大

跟其他相關概念對照：

概念	跟 HITL 的關係
Agent 自主度分層	Full auto / checkpoint / step-by-step / plan-first → 對應 HITL 時機
Tool 副作用範圍	等級 1-2 不需 HITL、等級 4-5 強制 HITL
Guardrail	Schema / validator / monitoring 是自動 guardrail、HITL 是人類 guardrail

設計責任

讀 AI 應用設計或 agent paper 看到「HITL」「human-in-the-loop」「approval flow」「appeal」就是這個機制。實作判讀：

位置由 risk 跟 validator 能力決定：risk 高 + validator 弱、HITL 頻率高；risk 低 + validator 強、HITL 頻率低。
三時機可組合：pre-act 擋高代價、mid-stream 處理 agent 不確定性、post-hoc 收回饋。三者各擋不同 risk class、不互斥。
避免橡皮圖章化的四條件：分級不同 risk 走不同 gate、approval UI 強制 show diff、reject 有明確 fallback、approval 訊號回饋進系統。任一不滿足、HITL 退化成形式。
跟 jagged frontier 的關係：frontier 外的任務該強制 HITL、不交給 user 自由心證。
跟 fuzzy engineering 典範的關係：HITL 是 fuzzy 行為的 deterministic guardrail 一種、不是預設要有、看 risk 跟自動 validator 能力決定。

完整 HITL 拓樸設計見 4.5 人機協作拓樸。

Hallucination

Tue, 12 May 2026 00:00:00 +0000

Hallucination 的核心概念是「LLM 生成的內容語法、語氣、結構看起來合理、但內容上是事實錯誤、引用不存在的來源、虛構不存在的 entity」。這是 LLM 基於統計分布生成的固有特性；以目前的研究跟工程實踐、靠「更大模型」或「更好對齊」很難徹底消除、可控的做法是用工程手段降低觸發率跟下游偵測。

概念位置

Hallucination 的常見形態：

形態	例子	風險
虛構引用	引用不存在的論文 / API / 函式名稱	使用者照抄、出錯
虛構 entity	虛構不存在的公司 / 人名 / 地址	寫入文件、產生誤導
數值幻覺	給看似精確但實際錯誤的數字	商業 / 工程決策被誤導
因果幻覺	編造看似合理但不存在的因果關係	推理鏈不可信
法律 / 醫療幻覺	虛構不存在的法條 / 治療方案	高風險領域、可能造成實際傷害

降低 / 偵測 hallucination 的常見手段（依場景變化）：

RAG：把真實內容檢索後注入 prompt、模型基於真實內容生成。
temperature 降低：採樣較保守、減少創造性但也減少幻覺。
citation 要求：prompt 要求列出引用、後續可驗證。
下游驗證：對輸出做事實檢查（如 code 跑 compiler、引用查實際資料庫）。
明確的「不知道就說不知道」instruction：降低過度自信、但不能消除。

事實查核註：Hallucination 的研究跟降低技術仍在快速演進、不同模型、不同任務類型的 hallucination rate 變化大、引用前以最新研究跟具體 model card 為準。Stanford TruthfulQA 等 benchmark 是常見參考。

設計責任

理解 hallucination 後可以解釋兩個現象：為什麼 LLM 給的「具體事實」（人名 / 數字 / 引用）特別要驗證（生成機制本身就會虛構）、為什麼 LLM 寫的 code 看似合理但 import 不存在的 package（hallucinate 出 library API）。

production 場景下、hallucination 影響合規（生成包含真人 PII 的虛構內容仍是 PII 處理）、UX（使用者照抄誤導內容）、安全（生成假 URL 引發釣魚）；應對策略不是「擋住 hallucination」、是「降低觸發率 + 下游驗證 + 適當的 disclaimer」。詳見 LLM Log 與 PII 治理。

Refusal Rate

Tue, 12 May 2026 00:00:00 +0000

Refusal rate 的核心概念是「LLM 拒絕回答 prompt 的比例」。LLM 在訓練階段（特別是 RLHF）會學到「對特定類型的請求說『我不能幫忙這個』」、production 服務通常會監控這個比例作為對齊強度跟異常行為偵測的訊號之一。

概念位置

Refusal 行為的典型形態：

形態	例子
安全相關拒絕	“Sorry, I can’t help with that request.”
政策相關拒絕	“I’m not able to discuss specific medical advice.”
能力相關拒絕	“I don’t have real-time data access.”
模糊拒絕（soft refusal）	“That’s an interesting question, but…”

Refusal rate 作為偵測訊號的兩個方向：

率突然下降：可能是對齊被繞過、prompt injection 攻擊在進行、或新版本模型對齊變弱。
率突然上升：可能是訓練資料或對齊政策變嚴、影響使用者體驗、或 vendor 端政策調整。

實作上、偵測 refusal 通常用簡單 pattern matching（看是否含 “I can’t” / “I’m not able” / “Sorry” 等）或更精確的 classifier；具體實作依偵測平台設計。

事實查核註：refusal rate 的標準化測量方式、跟「對齊強度」的對應關係仍在研究演進、不同 vendor 跟 model 的 baseline 差異大、引用前以對應模型的 model card 跟最新研究為準。

設計責任

理解 refusal rate 後可以解釋兩個現象：為什麼 production LLM 服務監控 refusal rate（變化是異常訊號）、為什麼開源模型的 refusal rate 通常低於商業旗艦（前者 safety RLHF 投入較少）。

production 設計時、refusal rate 是 content 層偵測訊號之一、需配合 tool call 序列、token usage、prompt pattern 等其他訊號才能形成完整偵測覆蓋。詳見 LLM Service 偵測訊號覆蓋。