知識庫最危險的錯誤不會報錯：一個靜默 33 天的事故

我自己有一套個人知識庫，從 LINE、RSS、GitHub 收進來的文章，經過抓全文、摘要、九個維度評分、向量化，再依分數決定要進知識庫、發到部落格，還是歸檔。

今年 8 月 31 日才發現，站上全是 4 到 7 月的舊內容，看不到當週新文章。往下查，新進的文章大量停在同一個分數：33 分，全部被送去歸檔。

這個狀態已經持續 33 天。排程每天照跑，exit code 是 0，log 裡沒有一行錯誤。

每一環都「正常」的失效鏈

根因很小：評分用的模型 qwen3.5:35b-a3b 已經從 GPU 主機上移除，設定檔還指著它。

但從「模型不存在」到「1,060 筆文章被寫進假分數」，中間經過了七個環節，每一個單獨看都沒有錯：

1. Ollama 回 HTTP 404，body 是 {"error":"model 'qwen3.5:35b-a3b' not found"}
2. HTTP 工具對它做 json.loads，成功，因為那是合法的 JSON
3. 錯誤 payload 被當成正常回應往下傳
4. 取 message.content 找不到，回 None
5. 評分函式收到 None，不拋例外、不寫 log，重試三次後回 None
6. 上層落到預設分數 DEFAULT_SCORES
7. 批次把預設值當真分數寫進資料庫，程式正常結束

為什麼撐了 33 天沒人發現？因為摘要用的是另一個模型，那個模型還在。每一筆文章都有一段漂亮的中文摘要，系統看起來完全健康。

單一環節壞掉、相鄰環節正常，會製造出系統健康的假象。 這是我從這次事故學到最貴的一句話。

第二次了

更難看的是，這是同一個症狀的第二次。今年 3 月就發生過一次 33 分事故，那次我修的是「模型回應格式不相容」。

那次修的是觸發條件，不是失效模式。「拿不到有效回應就靜默套用預設值、而且 exit 0」這個機制原封不動。五個月後換了一個觸發條件（模型被移除），同樣的失敗再來一次。

不是修好 bug 就結束，而是要問：這類錯誤下次換個入口進來，系統會不會再把它吞掉。

真正的修法：可以夾限，不可以捏造

這次改的是機制：

• HTTP 層：payload 帶 error 鍵就直接判定失敗並記 log，不讓「合法 JSON」混過去
• 解析層：九個維度缺任何一個就算失敗，不補預設值
• 批次層：連續 5 筆失敗就熔斷，失敗的資料不寫進資料庫，保持「尚未評分」讓之後重試
• 程式出口：拿不到評分就印 [ABORT] 並 exit 1，讓排程與告警看得到

修復過程中的 code review，連同原事故，在同一條路徑上一共整理出八個缺口：分數是布林值、Infinity、不是物件的回應、第九個維度根本沒驗……每一次都只修了被指出的那個實例。到後來把原則濃縮成一句話，拿它去掃整條路徑：

可以把一個真實訊號夾到合理範圍（7 變 5），但不可以無中生有一個值。

測試也會說謊

最讓我警覺的，是八輪裡有三輪，問題出在修復和測試本身。

其中一組 fuzz 測試，27 個全綠。後來故意把防護程式碼拿掉再跑一次，還是 27 個全綠。因為那組測試的隨機輸入幾乎永遠走不到成功路徑，等於沒測。

另一支名為「驗證防護有效」的測試，掛了一個豁免標記，而那個標記的作用正是關掉防護。

之後定下一條規則：測試寫完，要反過來破壞被測的目標，確認該紅的會紅。 這次每一項防護都用這個方法驗過。

換到企業知識庫，會在哪裡出事

個人知識庫錯了，損失是一個月的文章路由。企業知識庫錯了，可能是客服機器人對著顧客講錯退貨規則，或是人資機器人引用一條已經作廢的規章。

所以幫企業建知識庫時，我會先確認三件事：

• 上游（模型、檢索、資料庫）拿不到結果時，系統是明確失敗，還是安靜地給一個看起來合理的答案
• 每個回答能不能指回來源文件，讓人點進去核對
• 有沒有一組固定的真實問題，每次換模型、改 prompt 之後重跑比對

這三件事都不性感，也不會出現在 demo 裡。但知識庫上線之後，決定它能不能被信任的，是出錯時的行為，不是答對時的樣子。

我這套系統目前還沒有對問答品質建立正式的評估基準（例如 faithfulness 這類指標），這是下一步。先量出現況分布，再決定門檻，而不是直接抄一個數字當標準。

千葉熊工作室提供企業知識庫（RAG）建置：回答附來源、依部門隔離、身分驗證與稽核：www.chiba.tw/products/knowledge-base/　企業 AI 導入：www.chiba.tw/ai/

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。