刪除不是全部：剪枝與階層標題讓同名碰撞群少 96.1%

我原本以為這次工作會是一場典型的知識庫清理：找重複、刪廢文、把資料庫縮小。真正動手後才發現，最大的問題根本不是「太多」，而是「找到了也很難判斷它是什麼」。

在三個研究型 namespace 裡，不同文件的大量小節都叫做「分析」、「實作」、「結論」或同一組功能名稱。文字確實存在，全文搜尋也確實命中，但標題被攤平後，結果失去了父章節與來源脈絡。這是一種很隱晦的品質退化：搜尋沒有壞，卻讓人更難信任搜尋結果。

數字很小，訊號改善很大

這次在三個研究型 namespace 的結果如下：

這裡的「碰撞群」有明確定義：在每個 namespace 內，只計 file-sync 索引列，將完全相同的標題分組，保留 COUNT(*) > 1 的群組。77 群由三個 namespace 的 17、9、51 群組成；重建後是 0、1、2 群。

134 列包含 69 個可以精確判定的退化區段，以及 65 個由 byte-identical 重複來源產生的區段。另有 4 筆手寫知識在另一個、非研究型 namespace 退役；它們不包含在上表的三個 namespace 或 134 列中。每一筆都先確認繼任內容完整承接、來源可追溯，而且刪除前版本可復原。

如果只看資料量，這幾乎稱不上大掃除；但若看「同名結果是否還互相遮蔽」，差異非常明顯。

核心修正：讓標題帶著路徑走

我們沒有改寫知識內容，而是讓 file-sync 產生的區段標題包含父層脈絡。例如原本只叫做：

錯誤處理

會變成類似：

deployment.md § 部署流程 › 啟動檢查 › 錯誤處理

關鍵字仍在，全文也仍在，但搜尋結果本身就能回答「這是哪一段的錯誤處理？」。正式機重建後直接量到 8,766 個 file-sync 索引列含有這種階層路徑。

所以，標題碰撞下降本身不等於變得難搜尋。結構化標題增加的是上下文，不是把原關鍵字換掉；但增加的父層詞也可能改變排名。廣泛查詢父層詞時，仍可能命中多個子節，必須用固定 benchmark 區分保留召回與排序副作用。

我們用同一批查詢做前後對照

我不想用「看起來比較乾淨」當驗收，所以保留剪枝前快照，對相同查詢比較結果：

• M2_2_3：17 筆變 15 筆。消失的兩筆原本排在第 3、4 名，內容只是退化區段；有效知識仍在。
• 啟動器設計討論：200 筆變 135 筆。少掉的正好是 65 個重複 file-sync 區段，前五名不再被內層重複提案污染。
• playbooks：15 筆維持 15 筆，前五名順序不變，但標題開始帶有章節路徑。

這三個事後挑選的查詢分別呈現「排除垃圾」、「移除重複」與「特定查詢維持召回」，但不能代替完整搜尋基準。另一組在變更前固定的 10 個系統查詢顯示：前五名完全重疊有 5 組、重疊 3 筆有 4 組、重疊 2 筆有 1 組。階層標題有時會把同一份文件的兄弟小節推進前五名，因此它改善了結果辨識度，卻不是免費且保證不改排名的變更。就上面三個已保存命中數與前五名輸出的查詢而言，沒有觀察到有效全文召回遺失。

兩個 AI 的一致，不是投票而已

這次由 Codex 執行盤點、dry-run、實作與部署，再透過 ai-cli 交給 Claude 做獨立唯讀覆核。雙方必須對同一組證據標準達成一致：

1. 來源重複要逐檔證明內容完全相同，不能只看檔名。
2. file-sync 內容不能直接從索引刪除，必須修正來源選擇或切段規則後重新同步。
3. 短內容不等於垃圾；只有純 fence、水平線、佔位符、單獨日期等明確形狀才排除。
4. 手寫條目必須證明已有完整繼任內容，而且能從版本歷史還原，才可以退役。
5. 無法完整證明安全的候選一律 HOLD。

在功能部署閘門，Claude 最終獨立重跑了 86 個測試與 44 個子測試，給出 FINAL APPROVE；這和本文發布前的另一次內容審核是兩件事。重要的不是有兩個模型說「可以」，而是兩者都被迫對照 hash、manifest、反例測試、備份與查詢結果；共識必須能被第三方重現。

我刻意沒有宣告完成的部分

結構重切與全文搜尋已通過驗收，但新的 embeddings 仍在背景重建。系統會在向量覆蓋未滿時標示 search_degraded=true，因此這篇文章只宣稱 FTS 與結構層的改善，不把 semantic／hybrid 搜尋包裝成已經終驗通過。

把這兩個閘門拆開非常重要。服務有回應、全文能搜尋，不代表語意排序已經收斂；反過來，也不該為了等向量重建而否定已經有證據支持的結構改善。

這次留下的五個原則

1. 可定位性比資料量更值得量測。 資料庫只少 1.37%，不代表改善只有 1.37%。
2. 碰撞群比總筆數更接近結果歧義。 同名標題從 77 群降到 3 群，直接量到的是可辨識度改善；搜尋體驗仍要搭配固定查詢集驗證。
3. 剪枝必須保留 provenance 與復原點。 沒有來源、hash、manifest 和備份的刪除，只是不可逆的猜測。
4. AI 共識需要共同證據，不是多數決。 讓第二個模型獨立驗證，比叫它附和摘要有價值得多。
5. 結構驗收與語意驗收要分開。 這能防止「部分完成」被誤寫成「全部成功」。

最後，我得到一個有點反直覺的結論：好的知識庫剪枝，不是把記憶刪得更少，而是讓留下來的每一段更容易被正確找到、辨認與信任。