1. 觸發事件——AI 寫下「639」，實際數字卻是 0 #

不久前，我們的本地 LLM 在自動產生的監控報告中寫下「639 次身分驗證失敗」。實際查核日誌後，該時段內的身分驗證失敗次數是 0。LLM 只是憑空生成了一個看似合理的數字（我們曾在〈本地 LLM 在監控報告中捏造數值的事件及其對策〉一文中記錄過這段插曲）。

這並非 LLM 的缺陷，而是它的本質。LLM 擅長產生「在脈絡上看似合理的文字」，但它本身並沒有能保證「數字符合事實」的內建機制。它經常寫出正確的數字，但那並非因為正確性受到保證——只是恰巧對了而已。

在 AI Ops 的場景中，這一點絕不能被忽視。一份無法信任的監控報告，與根本不存在沒有兩樣，甚至更危險。如果有人相信「639 次身分驗證失敗」並據此採取行動，就會把時間花在一個並不存在的問題上。反之，真正的異常也可能因此被掩蓋。

因此，我們建立了一套機制，不會盲目相信 LLM 所寫下的數字——那就是幻覺稽核。本文將說明其實作背後的思路。

2. 原則——事實不是由 LLM 產生的，而是由日誌產生的 #

稽核的出發點在於角色的分離。

出現在監控報告中的「事實」——數字、計數、IP 位址、時間戳記——並非來自 LLM 的文字生成，而是來自對真實設備日誌的確定性查詢所得。LLM 的角色，僅限於將已確認的事實，轉化為人類容易閱讀的文字。

• 事實（數字、對象、時間戳記）→ 由對日誌的查詢產生（即事實依據 ground truth）
• 敘述（摘要、說明、行文）→ 由 LLM 產生

光是這樣的角色分離，就能大幅降低捏造的空間。若要求 LLM「讀取日誌並計數」，就很容易誤計（＝捏造）；但若先彙整好計數結果，將已確認的數值交給它，再要求它「用這些數字說明狀況」，數字本身就不會再變動。

3. 透過「稽核」抓出仍可能殘留的捏造 #

即使角色已經分離，LLM 在撰寫過程中仍可能夾帶未曾提供給它的數字，或誤判對象。因此我們設置了一道稽核步驟：在輸出產生之後，再次將 LLM 產生的報告與原始日誌交叉核對。

大致流程如下。

1. Aggregate logs to build the "confirmed facts"       <- ground truth
2. Hand the confirmed values to the LLM to generate the report text
3. Extract the quantitative claims from the generated report
   (e.g., "N authentication failures on host A")
4. Cross-check each claim against the source logs (the confirmed facts in step 1)
5. If an unsupported or contradictory claim is found,
   replace it with the confirmed value, or regenerate the report
6. Record every detected mismatch (when, where, what was fabricated)

這裡有兩個關鍵點。

交叉核對是確定性的。我們不會讓另一個 LLM 來做比對。用一個本身也可能產生幻覺的東西，去稽核幻覺，毫無意義。交叉核對是針對一項不可動搖的事實——原始日誌——所做的機械式檢查。

以「主張（claim）」作為驗證單位。與其事後再從自由格式的文字中撈取數字，不如從一開始就以容易驗證的結構（「對象／指標／數值」的三元組）接收 LLM 的輸出，這樣比對就會穩健得多。我們關注的不是行文的形式，而是每一項個別主張是否有事實依據作為支撐。

比對示意（數值僅為說明用）：

[AUDIT] report_id=████
  claim: host=A  metric=auth_fail  value=639
  truth: host=A  metric=auth_fail  value=0
  => MISMATCH  (replace with confirmed value / regenerate)

  claim: host=B  metric=port_scan  value=47
  truth: host=B  metric=port_scan  value=47
  => OK

4. 這並不是要「讓 LLM 變得更聰明」 #

這是作為設計理念的關鍵所在。幻覺稽核並不是試圖讓 LLM 變得更聰明或更準確的做法。在「LLM 會犯錯」這個前提不變的情況下，透過結構設計讓輸出結果變得可信。

即使 LLM 寫錯了數字，也會在稽核階段與事實依據交叉核對，因此最終報告中的數字是有保證的。我們並非把信任託付給 LLM 的聰明程度，而是託付給驗證機制本身。

5. 設計上的取捨（誠實地說） #

它並非萬靈丹。

1. 成本會增加。彙整、生成、稽核各自增加了一道流程。儘管如此，我們判斷在正式環境的監控報告中，「可被信任」這件事的價值，足以彌補這項成本。
2. 它所能抓出的，是「事實與數量」上的捏造。像「身分驗證失敗次數」這類可驗證的主張，可以進行交叉核對，但諸如「這個趨勢看起來很危險」之類主觀敘述的妥當性，很難以機械方式驗證。正因如此，我們把 LLM 的角色限定在摘要與排版，並在設計上不讓它做出判斷。
3. 它的前提是事實依據本身正確。稽核建立在「原始日誌即為事實」這個前提之上。日誌蒐集本身的準確度，以及設備層級判定的準確度，正是整套機制的基礎（蒐集與自動判定的機制，我們在其他文章中另行說明）。

6. 與 BASTION 根本理念相同的原則 #

這種「不信任 LLM 所寫數字」的立場，與 BASTION 整體的設計一脈相承。

真正會驅動系統的決策——最終判定攻擊來源 IP、執行防火牆封鎖——並非由 LLM 做出，而是根據真實設備日誌所做的確定性判定（多層關聯活動偵測機制的運作方式）。LLM 擅長的是自然語言的摘要與排版，而非正式的決策判斷——這條界線，正是我們在〈設計越漂亮，越要用真實數據質疑〉一文中所描述的驗證準則。

幻覺稽核，正是把同一套原則套用到報告這一層。無論是 LLM，還是（可能已被入侵的）Agent，對我們而言都是「不輕信、要驗證」的對象。

7. 總結 #

我們委託給 AI 的範圍越廣，「如何驗證 AI 的輸出」就越能決定產品的可信度。

• 事實（數字）並非由 LLM 產生，而是取自日誌
• LLM 所寫下的主張，會在輸出後與事實依據進行交叉核對
• 交叉核對是確定性的。不要用幻覺去稽核幻覺
• LLM 的角色僅限於摘要與排版，不做判斷

不要囫圇吞棗地全盤接受 LLM 所寫的數字。這雖然不起眼，卻是能讓 AI Ops 在正式環境中放心運行的基礎。