當 AI 說謊的時候 #

BASTION 每 15 分鐘使用本地 LLM 分析基礎設施日誌，並將報告發送到 Slack。某天，報告內容如下：

639 次驗證失敗。239 次 VPN 驗證錯誤。單看這些數字，你可能會判斷這是「異常」的。

然而，當我們直接彙整實際日誌後，發現驗證失敗其實只有 81 次，VPN 驗證錯誤只有 102 次。進一步調查後發現，我們傳遞給 LLM 的輸入資料原本寫的是「驗證失敗：0 次」以及「VPN 錯誤：無」。LLM 把輸入的「0」改寫成了「639」。

抽樣核對法 #

為了驗證報告中的數值是否正確，我們透過直接彙整實際日誌並與報告數值進行比對，實施了抽樣核對。

Inspection procedure:
1. Extract numerical values in the report by item
2. Obtain actual measured values by directly grep/counting actual logs on the AI-SLOG server
3. Calculate the deviation rate between reported and measured values
4. Judgment: within ±10% is "pass," beyond that is "requires investigation"

對 8 個項目進行核對的結果：

項目	報告數值	實際數值	判定
防火牆封鎖（特定 IP）	477 件	489 件	通過（+2.5%）
驗證失敗	639 件	81 件	捏造（-87%）
帳號鎖定	669 件	66 件	捏造（-90%）
驗證錯誤	239 件	102 件	捏造（-57%）
雲端應用程式所有項目	N/A	0 件	通過

在 8 個項目中，有 4 個項目檢測出幻覺（數值捏造）。

兩個根本原因並存 #

為了釐清原因，我們檢查了「傳遞給 LLM 之前的輸入資料」。

根本原因 A 是腳本的錯誤（可以用確定性的方式修復）。根本原因 B 則是 LLM 本身的根本限制。

對策：三層備援機制 #

我們並非採取「防止」LLM 幻覺的做法，而是採取「偵測並替換」的方式來應對。

第 1 層：確保輸入資料的正確性 #

我們修復了腳本的錯誤，改為只將最近 60 分鐘的資料傳遞給 LLM，而非所有期間的累計資料。當輸入資料正確時，LLM 生成正確輸出的機率就會提高。

第 2 層：透過提示詞禁止數值捏造 #

我們在 LLM 的提示詞中加入了以下規則：

【Absolute Rules for Numerical Values】
- Do not write any numerical values not present in the input data anywhere in the output
- Items marked as "0 cases" in the input must also be marked as 0 cases in the output
- Numerical values in the evidence section are permitted only as direct transcription from input data
- Speculation, completion, and approximation are prohibited

第 3 層：透過比對輸出數值與輸入數值來偵測差異 #

在 LLM 輸出生成之後，我們建置了一套備援機制，將輸出與輸入資料進行比對以偵測矛盾。若輸入中標示為「0 次」的項目在輸出中顯示為非零數值，系統會自動將其替換為安全文字。

Input: "authentication failures: 0 times"
LLM output: "639 authentication failures occurred"
  → Verification: Input is 0 times but output is 639 → Mismatch detected
  → Replacement: Automatically replaced with safe text

修正後的結果 #

在導入三層備援機制之後，我們在相同條件下重新進行了驗證。

項目	修正前	修正後
驗證失敗（輸入：0 件）	639 件（捏造）	0 件（準確）
鎖定（輸入：0 件）	669 件（捏造）	0 件（準確）
驗證錯誤（輸入：無）	239 件（捏造）	0 件（準確）
幻覺偵測備援機制	僅能偵測新造詞與符號	也能偵測數值捏造

LLM 遵循了提示詞規則並維持了零值，幻覺偵測備援機制未被觸發。確保輸入正確性（第 1 層）與強化提示詞（第 2 層）的組合，在依賴第 3 層偵測備援之前就解決了問題。

總結 #

在使用本地 LLM 的安全監控中，LLM 將輸入的「0 件」捏造成了「639 件」，這是一次幻覺事件。根本原因是腳本錯誤（混入所有期間的累計資料）與 LLM 數值捏造兩者並存。

作為對策，我們實施了三層備援：輸入資料正確性保證 → 透過提示詞進行數值約束 → 輸出後驗證偵測。修正後的重新驗證確認了 LLM 準確地維持了零值，且未觸發幻覺偵測備援，證實了此對策的有效性。

AI 監控並非萬無一失。與其信任 AI 的輸出，關鍵在於加以約束、驗證，並準備好備援機制。這種設計理念，正是以本地 LLM 實現實用安全監控的基石。