# LLM 知識庫的複利效應，前提是有人查得出寫錯的那一頁。

> AI 應用 · 2026-07-13 · HTML 版（正本）：https://voidvector.tech/zh/insights/llm-wiki-compounding-audit-gap/
> 語言：zh-Hant · 來源：voidvector（虛空向量有限公司）

「知識複利」是最近很紅的說法：AI 每次被問問題，都該讓知識庫變得更好，而不是查完就忘。但幾乎沒有人問一個更基本的問題——如果那次查到的答案是錯的，複利複的到底是什麼？

一個客服 AI 被問「這台機器保固幾年」。它三秒內給出答案，語氣篤定，還附上出處頁面。答案是錯的——它引的那一頁寫的是上一代機型的條件。麻煩的地方在於：那一頁不是任何人寫的。是這套系統自己，在上個月某一次問答之後，把當時的答案整理歸檔進去的。錯誤現在長得跟正確答案一模一樣——有標題、有結構、有交叉連結，被引用的時候，看起來跟真的合約條款沒兩樣。

## 先講清楚：這套「會自己寫筆記的知識庫」在做什麼

這個設計最近在工程圈很紅。源頭是 Andrej Karpathy 今年四月貼出的一份技術筆記，之後陸續有廠商把它包裝成企業產品在賣。它的想法用一句話講完：與其讓 AI 每次被問問題都回頭去翻一次原始文件，不如請它像一個永不下班的維基編輯，把讀過的東西整理成一份會越長越厚的內部百科，之後直接讀那份百科來回答。

*(圖：圖一：三層架構（原始文件／Wiki／Schema）與三個循環（Ingest／Query／Lint）。虛線的 file-back 是整套設計的關鍵——也是後面所有問題的來源。)*

拆開來看是三層加三個循環。三層是：不會被改動的原始文件（合約、年報、會議紀錄）；LLM 整理出來的 Wiki（結構化頁面，彼此交叉連結）；還有一份 Schema，規定這個 Wiki 該怎麼組織、每種頁面該怎麼寫。三個循環是：Ingest 把新資料讀進來、整理成頁；Query 讀 Wiki 回答問題；Lint 定期回頭掃描整份 Wiki，抓出矛盾和過時的內容。

真正的巧思藏在 Query 裡面一個叫 file-back 的動作：AI 答完一個問題之後，如果答得不錯，這個答案會被寫回 Wiki，變成一頁新內容，成為下次有人問類似問題時最先讀到的東西。用得越多，Wiki 越厚，下次答得越快。開頭那個客服 AI 的錯誤，就是從這裡長出來的。

## 它為什麼讓人興奮：知識會沉澱，不會用完就丟

要理解這套東西為什麼讓人眼睛一亮，得先看它在對比什麼。一般的 RAG 檢索是這樣運作的：使用者問問題，系統臨時去文件堆裡撈幾段最相關的內容，餵給模型，模型組出答案，然後——就沒有然後了。那個答案的組織過程、那次「從十份文件裡拼出一個結論」的功夫，答完就蒸發。下次有人問同一個問題，整套從零再做一遍。查一百次，就從零開始一百次。

Wiki 式的做法把這個功夫留了下來。答案不只給使用者，也沉澱回知識庫，變成資產。廠商把這件事講成「知識複利」——每一次使用都讓知識庫變得更值錢，而不是原地踏步。這個說法很有吸引力，也是我們自己在追這條線的原因。誠實的但書要講在前面：目前公開的討論裡，「複利」還是一個類比，我還沒看到夠長的實測數據去支撐那條漂亮的上升曲線。方向合理，但它現在是一個有前景的假設，不是一個被驗證過的結論——這兩件事在做預算決策時，差別很大。

## 同一個 file-back，不會分辨它寫回去的是對是錯

假設複利成立，接下來才是真正該問的問題：如果那次被寫回去的答案是錯的，複利複的是什麼？

*(圖：圖二：左邊是說帖裡的那條線，右邊是同一套機制的另一面。兩條線走的是同一個 file-back——它只會忠實地把答案存下來，不會判斷那是對是錯。)*

把這套架構產品化的說帖，多半會誠實地承認這個風險，說法通常是「錯誤會被百科全書化」——看起來權威，但其實是錯的。承認完，話題就轉去講產品的其他好處了。沒有人交代下一步：這一頁被寫回去之後，誰、在什麼時候、用什麼方法，會發現它是錯的？

標準答案是 Lint 循環——讓 LLM 定期回頭掃描整份 Wiki，抓矛盾、抓過時。聽起來很合理，直到你發現一件事：跑 Lint 的，通常就是當初寫下那一頁的同一個模型。

## 派模型去抓自己的錯，等於請它檢查自己的盲點

一個模型如果在某個領域會出錯——比如把兩份格式相近的合約條款張冠李戴，或是把「保固」寫成「保修」卻漏掉兩者範圍上的差異——它在 Ingest 階段寫錯所依據的判斷，跟它在 Lint 階段檢查時所依據的判斷，來自同一套訓練分佈。它抓得到的錯，剛好是它本來就不容易犯的那一類；它抓不到的，剛好是它自己的系統性盲點。

「讓 LLM 當自己作業的裁判」這件事，在研究圈已經被討論得夠多了，結論相當一致：自我一致（self-consistent）不等於正確，只代表這個模型在不同時間點對同一件事會給出同樣的答案。所以一份用同一個模型編、同一個模型審的 Wiki，最危險的內容，往往不是那些一眼看得出來的荒謬錯誤——那種通常會撞上別的線索，反而容易被抓到。最危險的是模型自己覺得「這樣寫很合理」，因此連標記為可疑都懶得標記的那些頁面。它們會安安靜靜地待在知識庫裡，等著被引用。

## 複利的另一半帳：Wiki 長得比人審得快

所以人要進來看。這也正是所有企業版本的標準答案：加一道人工審核，AI 起草、人類簽核。問題是這道防線的數學不太成立。

*(圖：圖三：兩條線的成長速度不一樣（示意，非實測數據）。用量越大，Wiki 長得越快；人能審的量卻幾乎是一條平線。中間張開的那塊，就是沒人看過就生效的內容。)*

在複利的敘事裡，用量是好事：問得越多、file-back 越多、Wiki 長得越快。但同一條曲線翻過來看就是審核負荷——Ingest 每批可能更新十幾頁，Query 每個好答案都可能生出一頁新內容，Lint 定期再吐出一份矛盾清單。這些全部堆到同一批人面前，而那批人的人數，通常從導入第一天到第一百天都沒有變過。

接下來的劇本我們看過太多次：第一週認真審，每一頁都讀；第二週開始選擇性審，挑看起來重要的；一個月後，看到綠燈就過。這不是紀律問題，是介面問題。一頁一頁看 diff、判斷「這次修改可不可信」，本身就是一件認知負荷極高的工作，而多數系統丟給審核者的就是一個原始的差異畫面，沒有任何東西幫他排序哪幾頁值得停下來、哪幾頁可以放過。把「人工審核」四個字寫進流程圖，不等於這件事在真實世界裡會被做完。

所以我們看任何一套「AI 起草、人簽核」的工作流時，第一個問的都是同一件事：AI 產出的曲線，跟人審核的曲線，是不是同步在長？如果不是——那複利故事會在第幾個月撞牆，其實是可以先算出來的。

## 換一代模型，舊頁面留下的是誰的判斷

還有一層更少人談。Wiki 是被模型「編輯」出來的，而編輯這件事有立場：什麼重要到值得獨立成頁、什麼次要到可以併進別頁的附註、兩個說法衝突時該信哪一邊。這些都是判斷，不是客觀轉錄。

*(圖：圖四：一份跨越多個模型世代累積出來的 Wiki，像地層一樣疊著好幾套互不相容的編輯立場——而通常沒有任何一頁標註自己是哪一層。)*

換一代模型，這些判斷會整批跟著換。新模型對「重要」的標準、對「衝突」的敏感度、甚至對「簡潔」的定義，都不會是舊模型的複製品。於是一份累積了兩三個模型世代的 Wiki，疊起來的不只是知識，還有好幾套互相打架的編輯品味——而且通常，沒有任何一頁標註「我是哪個模型、依照哪一版 schema 寫的」。

等到有一天你發現某個舊頁面的判斷邏輯跟現在的寫法對不起來，你會沒有辦法追查，只能猜。一份真的想要複利的知識資產，需要記錄的不只是「這頁改了什麼」，還有「這個判斷是誰做的」——哪個模型、哪一版 schema、經過誰簽核。這一點，無論是原始的技術筆記，還是包裝在它之上的商業版本，目前都沒有處理。

## 評估這類系統前，先問三個問題

採用任何一套「AI 起草、人類簽核」的知識系統之前，不管是自建還是跟供應商買，這三個問題都值得當面問清楚。第一，寫錯的那一頁，事後怎麼撤銷或改正——有沒有留下記錄，還是只能悄悄覆蓋掉？第二，審核的人力，有沒有跟著用量一起編列預算，還是假設「人工審核」這四個字本身就是解法？第三，每一頁知識，有沒有留下是哪一版模型、哪一版 schema 寫出來的，讓你在換模型時分辨得出哪些判斷需要重新檢查？

回到開頭那個保固答錯的客服 AI。如果它引用的每一頁都留著審核紀錄、每一次修改都對得上是誰簽核、每一頁都標著是哪個模型世代寫的，那麼答錯的那一刻，就只是一次可以被追蹤、被修正、甚至可以變成下一輪 Lint 規則的正常事件。少了這三樣，它就只是一台包裝得像百科全書的猜測機器。

知識要複利，複利的必須是驗證過的判斷，不是格式化過的自信。少了查核機制，長得最快的不會是你的資產，是那些還沒被拆穿的錯誤。