ReguCheck-RF 法規警語比對

問題現場

產品手冊裡有些安全警語是法規規定要寫的（例如 RF / SAR 相關）。我的任務聽起來很單純：確認每份手冊都有寫、而且寫對。

真正動手才發現有兩層坑：

純人工太慢：警語多、手冊多，逐字比對是重複又耗時的工作。
純比字面會判錯：同一條規定常被「換句話說」。只比字面相似度，會把合規的同義改寫誤判成不合規（false fail），或反過來放過真正缺漏的。

最小技術背景

法規警語 / 合規（compliance）：手冊上依法規必須出現的安全或使用警告。
SAR：衡量人體吸收無線電波能量的指標，相關警語常受規範。
lexical vs semantic：lexical 是「字面像不像」；semantic 是「意思一不一樣」。本案的本質是後者。
LLM 當裁判（guarded judge）：讓大型語言模型判斷語意，但加上護欄——輸出格式固定、結果存檔、可回頭稽核、衝突退回人工。

系統架構與資料流

字面完全相同的先快速放行；只有需要判斷語意的才動用 LLM，且 LLM 與規則衝突時不自動過、退回人工：

flowchart TD
  PDF["手冊 PDF"] --> CL["抽取法規警語 clause"]
  CL --> EX{"與基準字面完全相同?"}
  EX -->|是| PASS["fast-pass 直接通過"]
  EX -->|否| LLM["LLM 語意判讀｜structured JSON + cached + 可稽核"]
  LLM --> CMP{"與規則 / lexical 一致?"}
  CMP -->|一致| OK["判定一致"]
  CMP -->|衝突| NR["NEEDS_REVIEW｜交人工確認"]

關鍵設計決策（含取捨）

決策	選了什麼	否決的替代	為什麼
問題本質	認定是語意判讀	當成字串相似度問題	否決：換句話說一下，字面相似度就失準了
AI 角色	LLM 當裁判，但綁護欄	讓 LLM 全權判定、直接放行	否決：查不到來龍去脈的判斷，不能拿來做合規
輸出形式	固定 structured JSON + 依內容快取	自由文字回覆	否決：格式一漂移，判斷就忽前忽後、難驗證
衝突處理	與規則衝突 → NEEDS_REVIEW 人工	以 LLM 為準自動放行	否決：合規這種事，不容許「AI 說了算」

代表性技術證據

快速放行 + 受控裁判（pseudo-code，示意）

def adjudicate(clause, baseline):
    if clause.text == baseline.text:          # 1. 一字不差 → 直接放行，別浪費 LLM
        return "PASS"
    verdict = llm_judge(                       # 2. 不然才交給 LLM 判語意
        clause, baseline,
        response_format="json",                #    回傳鎖死成 structured JSON
        cache_key=content_hash(clause, baseline),  # 照內容快取，同一題重跑結果一樣
    )
    audit.log(prompt_version, model_id, verdict.raw)  # 3. 整段過程都留得下來、查得到
    if verdict.semantic != lexical_score(clause, baseline).agree:
        return "NEEDS_REVIEW"                  # 4. 跟規則打架 → 不自己決定，退回人工
    return verdict.semantic

固定回傳欄位（示意）：{ "equivalent": true, "reason": "...", "confidence": 0.93 }，缺欄即視為失敗，不放行。

踩過的坑

欄位	內容
症狀	同一條 clause、不同次執行，判斷結果不一致
初判（猜錯）	第一個念頭是來源 clause 的內容變了
驗證	比對稽核裡的 raw JSON，發現是 LLM 回覆的措辭 / 格式在漂移
根因	prompt 沒有結構約束、沒有快取，每次自由發揮
修法	鎖 structured JSON、依內容 hash 快取、記錄 prompt 版本與 model id
預防	加「同輸入重跑結果一致」的測試，漂移即失敗

驗證方式

一致性：同一輸入重跑，判斷與快取一致（不漂移）。
可追溯：每筆判斷都能從稽核還原 prompt 版本、model、原始回覆。
護欄：LLM 與規則衝突時一定進 NEEDS_REVIEW，不自動放行。
驗收標準：字面相同必 fast-pass；同義改寫不被誤判為不合規；衝突一律人工。

可複製 SOP：讓 AI 做可信的判斷

適用情境：要 AI 判斷「兩段內容意思是否一致」這類語意問題，且結果需可信、可追溯。

不適用情境：純機械比對（字面、數值）就足夠時，不需要 LLM。

前置條件

一個權威基準（這裡是法規警語基準）。
稽核儲存：能保存每次判斷的 prompt 版本、model、原始回覆。

步驟

先機械、後語意：能用字面 / 規則快速判掉的先判掉，省成本，也少讓 AI 插手。
鎖輸出格式：LLM 只准回固定欄位的 structured JSON，少一欄就算失敗。
依內容快取：拿內容 hash 當 key，同一題進來，結果每次都一樣、重現得出來。
全程稽核：記 prompt 版本、model id、raw 回覆。
衝突退人工：LLM 跟規則不一致 → 丟 NEEDS_REVIEW 給人，而且留一個能切回舊做法的開關。

停損點

同輸入重跑結果不一致 → 停，先補快取 / 結構約束。
無法稽核某筆判斷 → 停，不可用於合規。

驗收標準

fast-pass、語意判讀、衝突退人工三條路徑都可驗證；判斷可重現、可追溯。

回滾：以 feature flag 切回純規則 / 人工流程，不影響既有合規檢查。

可複製到：任何「需要 AI 判斷語意、但結果要能被審計」的場景。

決策回放（三個月後回讀用）

背景：手冊法規警語人工逐字比對成本高，純字面比對又因同義改寫失準。
限制：合規判斷必須可追溯、可退回人工；不可外流真實手冊內容與產品名。
考慮過但放棄：讓 LLM 直接取代規則引擎、自動放行——被「查不到來龍去脈」否決。
證據：structured JSON 約束、內容 hash 快取、prompt/model 稽核、NEEDS_REVIEW 路徑。
未解：人工覆核的人力到哪、分流門檻怎麼抓；還有不同法規版本的基準要怎麼維護。

作者備註： 合規這種事，「AI 判得準」其實只是最低標；真正能讓你晚上睡得著的，是「萬一判錯，你查得到、也攔得住」。所以我盯的從來不是模型多強，是護欄夠不夠牢。