--- title: AI 判斷不可信怎麼辦 — 生產環境的對抗驗證與誤判稽核 description: 讓 AI 的判斷可信到敢寫進正式資料庫、甚至影響績效，靠的不是更好的 prompt。這篇拆解一套 production 級的四層信任機制：信任分級、多視角對抗驗證、誤判系統性稽核、破壞性寫入保護，附一次修 66 張誤判、兩層裁決擋掉 4/6 過度開火的真實數字。 category: ai-qa tags: [llm-as-judge, adversarial-verification, ai-qa, production-ai, trust-boundary] date: 2026-07-27 faq: - q: 怎麼確保 AI 的判斷可信到敢寫進正式資料庫？ a: 把 AI 當成「會出錯的下游」來設計，不是當真理。四層：一、信任分級——高信心自動寫、borderline 保留原判並通知人。二、對抗驗證——同一個判定用多個獨立視角平行去「反駁」它，多數通過才算，不是同一個 prompt 問三次。三、誤判稽核——用 SQL 指紋找出 AI 的「罐頭答案」模式，重讀原文按 rubric 修正。四、寫入保護——鎖定規則加欄位白名單加 force 模式，防重跑覆蓋。 - q: 「對抗驗證」跟「同一個 prompt 問三次」差在哪？ a: 差很多。問三次同一個 prompt 只是拿到三份帶同樣偏見的答案，錯的會一起錯。對抗驗證是給每個驗證者「不同的立場」：L1 叫它盡力攻擊原判定、找過度開火，L2 叫它捍衛原判定，只有兩層都同意才改、都反對才駁回、分歧升人工。真實一批 16 票裡，L2 擋掉了 L1 想改的 6 個裡的 4 個——那 4 個是 L1 的誤殺。 - q: AI 批次分析的效能瓶頸在哪、怎麼省 token？ a: 瓶頸幾乎都是 output-bound 不是 input-bound——生成的 token 才是天花板（例如一批 22 張票約 80K 輸出就到頂），所以要砍的是「一次處理幾張票」不是「塞多少 context」。省 token 的招：主票給完整 diff、聚合子票只給檔名（省約 95%）；讓模型輸出結構化資料不要寫 boilerplate；解析結果讓下一步不用重讀 raw log。 - q: AI 回傳「success」就代表寫入成功、可以驗收了嗎？ a: 不行。這是最容易踩的破壞性寫入陷阱。曾有一個寫入 API 無條件覆蓋十幾個欄位，就算把資料清成 null 也照樣回 success——結果洗掉了 36 張票的分數。「API 說成功」不是驗收，「DB 裡的值等於我送進去的值」才是。驗收要回讀資料庫比對，不能信回應碼。 --- # AI 判斷不可信怎麼辦 站上另一篇談的是「[AI 寫的 test 怎麼信任](/ai-qa/trusting-ai-generated-tests.html)」——那是信任 AI 產出的**程式碼**。這篇更進一步：**怎麼讓 AI 的「判斷」可信到敢寫進正式資料庫、甚至拿去影響績效評分**。 難點從來不是「接上 AI」。接個 API 誰都會。真正的難題是：AI 的判定是**主觀、會出錯、且無法逐張人工複核**的，你憑什麼敢把它的估點、風險評估、OKR 歸類、績效評分**直接寫進生產資料庫**？ 答案不是「更好的 prompt」。是把 AI 當成一個**會出錯的下游系統**來做工程防護。 ## 核心心智模型：AI 是會出錯的下游，不是真理 ```mermaid flowchart TB AI[AI 判定
估點/風險/OKR/評分] --> L1{信任分級} L1 -->|高信心| W[自動寫入] L1 -->|borderline| H[保留原判
通知人複核] W --> V[對抗驗證
多視角反駁] V -->|多數通過| DB[(正式 DB)] V -->|被駁回| H DB --> A[誤判稽核
SQL 指紋抓罐頭答案] A -->|發現系統性誤判| R[重讀原文
按 rubric 修正] R --> DB P[寫入保護
鎖定+白名單+force] -.守著.-> DB style AI fill:#f59e0b,color:#fff style DB fill:#7c3aed,color:#fff style P fill:#ef4444,color:#fff ``` 四層——信任分級、對抗驗證、誤判稽核、寫入保護——缺一層都會在某個時刻讓錯的判定溜進生產。下面逐層拆。 --- ## 第一層：信任分級（不是所有判定都該自動寫） 不要「AI 說什麼就寫什麼」，也不要「全部都要人審」（那 AI 就沒意義了）。分級： - **高信心** → 自動寫入。 - **borderline（模稜兩可）** → **保留原本的判定不動**，另外產一筆「待人工核准」的指令，通知人來看。 關鍵字是**非破壞性**：borderline 的情況下，系統只**產出建議**、不自動改動既有值。AI 不確定的時候，預設是「什麼都不動」，而不是「賭一把寫下去」。 --- ## 第二層：多視角對抗驗證（重點：立場要相反） 這是最容易做錯的一層。很多人以為「驗證」就是**同一個 prompt 問三次取多數**——錯。問三次只會拿到三份**帶同樣偏見**的答案，錯的會一起錯。 真正有用的是給每個驗證者**不同的立場**，讓它們互相對抗： ```mermaid flowchart LR J[AI 原判定] --> L1[L1 攻擊層
refuter / critic
盡力反駁原判] L1 -->|想改| L2[L2 捍衛層
skeptic
盡力維護原判] L2 --> D{兩層都同意?} D -->|都同意改| Y[改] D -->|都反對| N[駁回, 維持原判] D -->|分歧| E[升人工] style L1 fill:#ef4444,color:#fff style L2 fill:#06b6d4,color:#fff style E fill:#f59e0b,color:#fff ``` L1 的任務是「攻擊」——找原判定哪裡過度開火、哪裡誤掛。但只有 L1 會**矯枉過正**（為了找碴而亂改），所以加一個**立場相反的 L2**：它的任務是「捍衛原判定」。**只有兩層都同意才改、都反對才駁回、分歧才升人工。** > **真實數字**：一批 16 票，L1 想改其中 6 個。L2 擋掉了 4 個——那 4 個是 L1 的誤殺。如果只有 L1，這 4 張正確的判定就會被 AI 自己改壞。 還有一個維度的對抗：對「OKR 歸類」這種判定，用**多個獨立視角**平行 challenge——業務場景 refuter、季度時間 refuter、漏掛 critic——再綜合裁決，攔截單一視角放過的誤掛與漏掛。同一關鍵字（例如「入金」「清算」）在不同產品線語意不同，要先鎖定業務場景，再對規則的**範圍描述**（不是標題）做比對。 --- ## 第三層：誤判系統性稽核（AI 會有「口頭禪」） AI 犯的錯往往**不是隨機的**，是**成模式的**——同一種情境它會反覆給同一句「罐頭判語」。這反而好抓： > **真實案例**：早期批次分析用一句罐頭判語，把一批**其實有實質驗收條件**的票壓成了低分。做法：用 SQL 去**指紋比對**（找出重複出現的罐頭措辭）→ 撈出所有中招的票 → **重讀原文、按 rubric 重新評分**（多個 agent 平行跑）→ 用最小破壞面寫回。**一次修正了 66 張歷史誤判。** 這層的價值是：AI 的錯是系統性的，你的修正也可以是系統性的。與其祈禱它不犯錯，不如假設它一定犯錯，然後建一套「定期用 SQL 抓自己的口頭禪、批量校正」的機制。 **還要防漂移**：AI 重跑同一張票時，估點值容易在幾分之間來回跳（噪音）。把新判定**錨定到上一版快照分數**，非顯著差異就不動——因為「噪音比漂移更傷」，數字每次重跑都變，人就不信它了。 --- ## 第四層：破壞性寫入保護（「success」不是驗收） 最後一道，也是最血的一課：**不要相信寫入 API 回的 `success`。** > **真實案例**：一個寫入 API 無條件覆蓋十幾個欄位，而且**就算你把資料清成 null 也照樣回 `success`**。結果一次重跑洗掉了 **36 張票的分數**——API 全程回成功。 「API 說成功」不是驗收，「**DB 裡的值等於我送進去的值**」才是驗收。驗收要**回讀資料庫比對**。 配套的寫入保護： - **鎖定規則**：已完成/已終局的票不給覆蓋（判定已定案）。 - **欄位白名單**：只允許改指定欄位，其他一律不碰。 - **force 模式**：要繞過鎖定必須人工顯式指定，不能是預設。 - **分層寫入**：接前面的信任分級——高信心自動改、borderline 只留建議。 還有一類靜默 bug 要特別點名：**read-local-write-cloud**。本地跑 AI 分析、卻讀本地資料寫雲端 DB，當本地落後雲端時就會**默默產出錯數字**。**讀寫必須同源**——這是一整類難抓的 bug，不會報錯，只會讓數字悄悄錯掉。 --- ## 附帶心法：批次分析是 output-bound 做 AI 批次分析時，很多人本能去壓縮 input（塞更少 context）。方向錯了——**瓶頸幾乎都是 output-bound**：生成的 token 才是天花板（例如一批 22 張票約 80K 輸出就到頂）。所以要砍的是**「一次處理幾張票」**，不是「塞多少 context」。 省 token 的實用招： | 招式 | 做法 | 效果 | |---|---|---| | 差異化 context | 主票給完整 diff、聚合子票只給檔名 | 省約 95% token | | 結構化輸出 | 讓模型輸出結構化資料，不要寫 boilerplate | 省每次數千 token | | 解析代替重讀 | 讓下一步讀「解析後結果」不重讀 raw log | 下游不再燒 token | 還有一個校準紀律：用**真實結果數據回頭校 AI 的量尺**。曾發現「估點 1 分」和「估點 2 分」的實際工時**無差別的佔了 81%**，於是修正評分映射，把兩級合併——不是拍腦袋調，是拿實測分布當證據。 --- ## 一張圖收尾：把 AI 當下游來設計 ```mermaid mindmap root((敢寫進生產 DB
的 AI 判斷)) 信任分級 高信心自動寫 borderline 保留原判通知人 非破壞性預設 對抗驗證 立場相反不是問三次 L1 攻擊 L2 捍衛 多視角 refuter/critic 誤判稽核 SQL 指紋抓罐頭答案 按 rubric 批量重判 錨定快照防漂移 寫入保護 success 不是驗收 回讀 DB 比對值 鎖定+白名單+force 讀寫同源 ``` > AI-as-judge、adversarial verification 大家都在講，但真正拿去**寫進會影響人事的生產資料庫**、還有 production 數字撐著的案例極少。重點一句話：**把 AI 當「會出錯的下游」設計，不是當真理**——它一定會錯，你的系統要在它錯的時候還守得住。