10 月 14 日，我在 Hello World Dev Conference 2026 分享 LLM Wiki 的架構演進。回頭整理這次演講，我最想留下的不是「Agent 可以自動寫 Wiki」，而是更實際的工程問題：來源文件變了，哪些知識要更新、哪些必須保留，而新的答案如何證明沒有漏掉重要條件？
我用一個合成的企業客服案例，將知識更新拆成來源與範圍整理、變更影響分析、答案回歸，以及人工審查。這場演練沒有連接正式企業資料，也沒有發布 Wiki；它展示的是一套可帶回 Agent 或 RAG 專案的變更驗證方法。
演講投影片 PDF
新規生效，不表示舊規則全部作廢
演講用的情境是員工帳號復原：舊規範要求先找 ExampleDesk 服務台，新規則則允許符合條件的人先嘗試自助復原。新規只在生效日期之後，且員工身分、公司管理筆電、帳戶鎖定狀態與自助復原註冊等條件符合時，才改變第一步。
把規則拆成可測的條件，大致會得到下面幾條路徑：
| 情境 | 預期處理 | 要確認的知識 |
|---|---|---|
| 2030 年 3 月 1 日後，正式員工用公司管理筆電、帳戶已鎖定且完成自助復原註冊 | 先嘗試自助復原 | 新規生效日與全部資格條件都出現在回答中 |
| 事件發生在生效日前，或使用者不符合新規資格 | 沿用原 ExampleDesk 流程 | 新規沒有把舊流程全面刪除 |
| 員工身分、裝置管理或註冊狀態未知 | 先追問缺少的資訊 | 不用猜測把使用者歸入符合資格的一側 |
| 自助復原失敗或結果不明 | 轉交 ExampleDesk | 新流程保留可執行的失敗退路 |
這張表是把演講中的合成規則轉成回歸案例的示意，不代表原始演練已逐一測過所有條件組合。實際部署時，內容負責人還需確認哪些條件必須明寫在每次回答、哪些可由經核准的身分或裝置資料補足。
這是條件式局部取代，而不是「最新文件全面取代舊文件」：新資格者可能改變第一步，但歷史事件與不符合條件者依然必須保留既有指引，並納入回歸。
這也是我在 Enterprise RAG 完整指南 所談的版本與適用範圍問題：檢索到相關證據，只完成回答的一部分，系統還要判定證據對眼前情境是否有效。
為什麼從 RAG 走向 Knowledge Compilation
企業原本就用 Wiki 整理流程、常見問答和技術文件；問題是文件更新後，要有人整理新內容、追蹤舊頁面的過期資訊，並處理互相矛盾的規則。LLM 與 Agent 讓部分整理工作可以自動化，但「能寫出頁面」只解決產出速度，沒有解決內容是否完整、適用範圍是否正確，以及新舊版本怎麼共存。
典型 RAG 在查詢階段把文件切成區塊、建立索引，問題進來後檢索相關內容、必要時重新排序，再由模型組成回答。這條路徑可以直接依來源回答；但遇到新舊規則並存時，系統仍要判斷版本、條件與例外。如果每一題都在查詢時重新整合，規則解讀也會變成每次回答都要即席完成的工作。
Knowledge Compilation 把一部分可重複使用的整理工作移到來源更新階段：先釐清生效日、適用資格、例外和保留的舊路徑，再把經整理的規則存成可追溯、可審查的知識。它可以和 RAG 一起使用；這個案例沒有比較兩種做法的準確率、成本或延遲，也沒有證明編譯式知識一定較好。差別在責任放置的位置：哪些判斷在更新時完成，哪些留到查詢時處理。
把知識更新拆成 Compile、Validate、Review
我把知識生命週期分成三個階段，方便團隊檢查責任邊界。
Compile 先整理來源、適用範圍與知識產物。演練把來源證據留在 Raw，將可重用的規則與問答整理到 Wiki，再用 Ops 記錄知識範圍和待審事項。來源、摘要、Concept 與 Query 彼此連結，之後才能追查某項答案依據哪份文件。
三層的重點是來源與依賴關係，不是資料夾名稱：Raw 更新可推動 Wiki 的 Concept 與 Query 變更，也可能讓 Ops 的範圍說明與審查責任過期。
Validate 評估變更影響，再測量回答行為。更新提案不能只列出「要改哪些頁面」，也要指定哪些檔案、問答與來源摘要應保持不變。更重要的是，必須測試最後呈現給使用者的回答正文，而非只檢查檢索結果或引用摘錄。
Review 決定是否核可與發布。Agent 可以提出修改、檢查結構、執行回歸，但一次測試通過不會自動替代內容負責人的審查。這套分工與 AI Agent 完整指南 中的控制、評測與人工治理相同：讓 Agent 做可驗證的工作，再把核准權留給明確的責任人。
影響分析要找出應改與應留
在演練中，Agent 對新增規範提出修改四個既有頁面、增加一份來源摘要的提案，涉及索引、Concept、ExampleDesk 角色和帳號鎖定 Query。指定的五份無關問答與六份既有來源摘要保持不變，這讓「不該改的內容」也能成為明確檢查項目。
但直接相關的頁面找齊了，仍不代表影響分析完整。Agent 最初把 ops/purpose.md 判為保留；它保住了舊範圍說明，卻漏掉新版知識範圍已從六份來源擴為七份。維護 Agent 後來發現並修正了這個差異。這說明檔案層級的變更清單需要覆核，因為治理設定也可能落在主要內容頁面的依賴之外。
另一個教訓是：檔案沒變，不代表模型答案一定不變。因此回歸測試必須同時驗證預期變更和保留路徑，而不能只看 Git diff。
這就是知識變更的 blast radius：一份新來源可能影響多個直接頁面，也可能影響 Ops 中的範圍、來源數量與審查責任。實務上可以要求 Agent 同時提交兩份清單：預期變更清單說明每個頁面為何受影響、依據哪段來源；預期保留清單列出不應改動的頁面和對應回歸問題。兩份清單都要由維護者確認，再進入答案測試。這是從演練推導的工作方式，不是本次測試已證明能完整找出所有依賴。
第一個測試失敗，答案方向卻已經答對
對照四次測量，別把不同考卷當同一把尺
| 階段 | 同一題組下的結果 | 能支持的結論 | 不能直接推論 |
|---|---|---|---|
| v1 Baseline | v1 十題，8/10 | 初始知識快照與該題組的表現 | 不能與 v2 直接比較 |
| v2 Baseline | v2 十一題，10/11 | 新題組下的基準快照 | 不是對 Updated 的單變因比較 |
| v2 Updated | v2 十一題，9/11 | 更新後有兩題未滿足必要回答條件 | 不能據此宣稱模型退步 |
| v2 Revised | 原 v2 十一題，11/11 | 修訂規則後的同題重測 | 不是未見題、正式部署或人工核可 |
v1 和 v2 評測契約不同；即使在 v2 內，Baseline 與 Updated 的知識快照及情境日期也同時改變。因此修稿不把 8/10、9/11、11/11 串成直接的準確率成長曲線。
演練先用六份來源產生十八頁 Wiki 草稿與十七項有來源依據的主張，再凍結 v1 十題評測問題。v1 Baseline 通過 8/10。這個分數描述的是當時那個知識快照在那十題上的表現，不是「LLM Wiki 的準確率」；它也不能和後來的 v2 十一題分數直接對照，因為 v2 使用不同評測問題。
更新後，模型在帳號鎖定問題上選對「先嘗試自助復原」，但答案正文沒有交代完整的適用資格與生效日期。另一題的主要密碼重設路徑也符合預期，卻漏了無法連上公司網路時轉交服務台的退路。影響分析、結構檢查與 Agent 覆核都通過，答案回歸仍然失敗；草稿因此停在人工審查前，沒有發布。
這不是只要多加一條 prompt 就能宣告解決。評測本身也需要治理：v1 有題目要求比使用者問題更多的內容，Model Judge 也曾把來源摘錄當成回答正文。團隊另開 v2 題組並保留 v1 結果，沒有回頭改舊成績。凍結題目讓測量可追溯；發現題目或判分方式有問題，就建立新版本並說清楚差異。
更具體地說，v1 有一題只問分公司透過 VPN 存取資源，評測規格卻額外要求回答總公司的流程；另一個判分問題則是 Judge 把檢索到的來源摘錄，當成使用者實際看到的回答正文。前者會讓「答對使用者問題」仍被判不完整，後者則會把系統沒有說出的內容算成已說。兩者都會污染分數，但修法不同：題目要調整評估範圍，Judge 要明確只評分最終答案正文，並能指出每個必要條件在答案中的證據位置。
因此評測套件也應有自己的版本紀錄：保存題目、預期答案要點、Judge 指令與版本、知識快照和情境日期。更動其中任何一項，都應說明新舊版差異，避免把修訂後的規則套回舊結果。自動 Judge 可協助篩查，但當它的證據來源或判分邏輯受到質疑時，仍需人工抽查和可追溯的判分理由。
在 v2 的同一題組中，Baseline 為 10/11，首次 Updated 為 9/11。兩者的知識快照與情境日期同時改變，因此這不是單變因比較，也不能推論架構讓答案變好或變差。團隊修訂通用回答規則後，用原本的 v2 題目重測，結果為 11/11。這是同題修復重測，不是獨立未見題驗收；資格文字是否每次都必須重述，仍待內容負責人判定。
失敗分析要回到回答本身。SYN-01 選對第一步，卻沒把生效日和資格完整寫出來；SYN-06 走對主要密碼重設流程，卻漏掉公司網路不可用時轉服務台的退路。這和「模型完全答錯」是不同失敗型態：主要動作正確，但條件和例外不足，仍可能讓使用者無法安全完成任務。回歸規格因此要定義每題的必要條件、禁止推論和失敗退路，而不只核對某個關鍵字或第一步。
把 Knowledge Change PR 帶回現有系統
一筆 Knowledge Change PR 的實際欄位示例
這張表是依本文既有合成演練整理的編輯範本，並非新實驗或正式發布紀錄。
| 審核欄位 | 本案例應留下的資訊 |
|---|---|
| Source | SRC-07；生效日 2030-03-01；來源段落與舊版連結 |
| Proposed change | 符合資格的帳戶鎖定案例，第一步改為自助復原 |
| Applicable when | 全職員工、公司管理筆電、已確認帳戶鎖定、已註冊自助復原、日期適用 |
| Must retain | 生效日前或不符合資格者仍走 ExampleDesk；資訊不足先追問；失敗需有退路 |
| Impact | 修改 4 個既有頁面、增加 1 個來源摘要，額外覆核 ops/purpose.md |
| Regression | SYN-01 驗證新資格及生效日；SYN-04 驗證歷史路徑；SYN-06 驗證網路失敗退路 |
| Release gate | 保存答案正文、評分依據及版本；內容負責人核可前不得發布 |
這裡的 SYN-04 僅用來說明既有歷史保留測試的角色，不為它新增分數，也不宣稱原演練已完成正式上線。
我把這套做法稱為 Knowledge Change PR：
- Compile：列出來源、版本、適用條件與受影響知識。
- Validate：檢查預期修改、必須保留的內容，以及使用者實際看到的回答；同時審視題目和 Judge。
- Review：由內容負責人核可，並定義未通過時禁止發布的條件。
不一定要先導入新的 Wiki 平台。可以先用一份 Knowledge Change PR 範本，要求每次更新附上：
- 來源與版本：來源識別、版本或 commit、生效日期、引用段落與可信責任人。
- 適用規則：資格條件、例外、資訊不足時要問什麼，以及失敗時如何回復舊流程。
- 影響清單：要新增或修改的節點、來源依據，以及必須保留的頁面和理由。
- 回歸證據：題組版本、知識快照、情境日期、使用者可見答案、必要條件檢查與失敗原因。
- 發布核可：內容負責人、未通過時的阻擋條件、發布版本與回復方式。
把這些記錄和草稿、測試輸出一起放在可審查的變更中，審查者就能檢查「來源到答案」的鏈條，也能在必要時回復，而不只是看 Agent 最後產生了幾個檔案。若你正在整理 Agent 架構，也可以接著閱讀 WeKnora 架構解析，看看知識、檢索與 Agent 執行如何在平台中銜接。
延伸實作 Repo
poirotw66/llm-wiki-example：可 fork 後建立部門專用 Wiki 的範本，重點放在來源歸檔、知識結構與治理流程；預設 Wiki 內容留白，資料需依自身政策整理後再納入。Tencent/WeKnora：開源知識平台，將文件理解、RAG、Agent 與 Wiki 放在共用知識庫上，適合對照平台化實作與自架部署選項。
前者從一個可自行治理的知識庫範本出發，後者提供較完整的平台能力。選型前仍要確認資料權限、來源更新、答案評測、人工核可與運維責任是否符合自己的環境。
來源
延伸閱讀
- AI Engineering TREC RAG 2026：RAG 評測為何開始加入 Agent 用 TREC RAG 2026 說明 RAG 評測從文件問答走到 Agent-in-the-loop，這篇講方向與題目設計，不講企業 harness 怎麼實作。
- AI Engineering 企業 RAG 評測 Harness 怎麼做（TREC RAG 2026） 以 TREC RAG 2026 與 RAGDoll 為參考，設計可重播的企業 RAG 評測 harness：資料模型、citation、Agent trace、judge 校準與上線門檻。
- Enterprise AI Enterprise RAG 完整指南：檢索架構、評估與企業落地 系統整理企業 RAG 的資料管線、Hybrid Search、重排、GraphRAG、Agentic RAG、評估、權限治理與失敗診斷，建立從知識來源到正式營運的決策框架。
