檢索典範與問題分類

← 總索引

2026-08-31～09-04 為了重新設計 DragonsHoard 的 hoard-query 機制，做的兩輪資訊檢索（IR）／個人知識管理（PKM）文獻整理與比對。這頁記的是整理出來的通用理論——問題該怎麼分類、檢索技術本身有哪些典範、PKM 社群的實務做法、怎麼判斷一套篩選設計好不好——適用於任何 AI 維護的個人 wiki，不限 DragonsHoard 這個實例。DragonsHoard 實際套用這套理論、推導出最終機制設計的完整過程，記在 觸發機制演變「三十三」「四十三」，不重複記在這裡。

大原則：問題分類與檢索典範是兩個獨立維度

不同的「資訊需求類型」該對應不同的「檢索機制」，這是兩個獨立維度、可以交叉分類：一邊是使用者到底想要什麼（問題分類），一邊是用什麼技術去找（檢索典範）。一套只有單一 pipeline、對所有問題一視同仁的查詢機制，天花板就卡在這裡。

問題怎麼分類

兩套經典分類法，但實際套用會發現各有站不住的地方（見下方「三」）：

• Broder（2002，Web 搜尋，IBM）三分類：Navigational（已知目標，只是找路徑過去）／Informational（想了解主題，答案可能散落多頁）／Transactional（想執行動作，wiki 場景用不到）。
• Marchionini（1995/2006，資訊科學經典）三分類：Lookup（已知項目搜尋，答案是離散事實）／Learn（瀏覽式學習，需多次疊代評估多個結果）／Investigate（開放式研究、綜合，常跨 session）。Lookup 類問題找到一個答案就停是合理的；Learn／Investigate 類問題定義上就需要看過多篇候選、互相比較才能收斂，「找到一個答案就停」在這類問題上根本不成立。

親自分類測試後的結論：這兩套分類都站不住——Lookup 分得出來，Learn／Investigate 分不出來（Marchionini 原始論文自己畫的也是 Lookup 跟 Exploratory 兩片重疊的雲，從未替 Learn/Investigate 畫過操作型界線）。更站得住的判準，是下面「三」整理出的 Precision/Recall 取捨維度，以及「這條線能不能被 frontmatter facet 表達」這個可操作測試。

檢索技術本身的三種典範

• 全文檢索（Full-text search）：索引＋字串／詞頻比對，不理解語意。規模小的知識庫（數十到百餘頁）用 grep 保底已經夠用，成本排序上還沒到要換掉的量級；規模變大時的技術選項（inverted index、BM25、tolerant retrieval、CJK tokenization 等）是可以之後再展開的方向。
• 分面檢索（Faceted search）：用多個正交的結構化屬性（facets）逐步縮小範圍。個人 wiki 的 frontmatter 天生就是現成的 facet 集合（例如 type／status／tags），問題常常是設計出來的欄位沒有真的被用在檢索上，等於這個典範只用了一部分。
• 超文本連結導覽（Hypertext link navigation）：文獻明講字面搜尋跟連結導覽是互補關係——字面搜尋找到「不知道存在」的未知主題文件，連結導覽補完已知主題的覆蓋範圍。wikilink 是這個典範在 Obsidian 類系統裡的具體實作。
• 擴散活化模型（Spreading Activation，源自認知心理學 Collins & Loftus 1975，後借用做關聯式資訊檢索）：從起點節點沿連結（帶權重）向外擴散、逐步衰減，模擬「聯想」，避免無限制跟連結展開到整個圖。是「怎麼更好利用連結」的具體算法方向——不是漫無目的跟連結走，是有限步數、有權重衰減的可控擴散。

篩選 vs 擴張：不是所有檢索手段都在做同一件事

檢索手段依「候選集合怎麼變化」可以再切一刀，跟上面「三種典範」是不同的軸：

• 篩選（收斂：大範圍→小範圍）：全文檢索、分面檢索都屬於這類——從一個大範圍裡，依某種訊號挑出一個小候選集合。
• 擴張（已篩過的小候選集往外長）：連結導覽方向剛好相反，不是從大範圍篩小，是從已經篩出來的候選出發，沿連結往外多長出候選。

方向不同，代表拿篩選的判準（成本、判別力）去衡量連結導覽會範疇錯誤——連結導覽的角色從來不是「濾掉不相關的」，是「補上篩選階段系統性漏掉的」。

三種手段（分面/摘要式索引搜尋、連結導覽、全文檢索）逐一比較底層資源、成本特性、precision-recall 傾向、對策展的依賴：

	底層資源	成本隨知識庫成長	Precision	Recall 天花板	對策展依賴
索引/摘要搜尋	索引頁文字	不會（自身規模有上限）	中（語意判斷會誤判）	低（摘要必然漏資訊）	高，且是硬性依賴
連結導覽	連結圖	局部會（樞紐頁連結密度）	低（連到一篇相關頁≠內容真的相關，是三者裡證據最弱的一環，只是間接證據）	中（僅一跳，依賴連結完整度）	極高，且是硬性依賴
全文檢索	原始全文	會，線性、無上限	低（字串比對無語意）	高（理論上限，前提用詞對得上）	幾乎不依賴

證據強度排序：索引/摘要搜尋（語意直接判斷）> 全文檢索（候選頁自身文字直接含關鍵字，是直接證據）> 連結導覽（只是連到一篇相關頁，關聯可能跟查詢完全無關，是三者裡最弱的一環）。這條排序容易被誤判反過來——連結存在本身很確定（要嘛連了要嘛沒連，沒有模糊地帶），但這跟「連結來源內容是否真的跟查詢相關」是兩件不同的事，前者的確定性不能代換後者。

好篩選設計的五條判準

不掛任何特定系統的規則，從第一原理推，適用於任何要在「篩選」跟「精讀」之間插一道關卡的檢索設計：

1. 篩選成本要遠低於精讀成本，否則兩階段設計沒有存在理由。
2. 篩選訊號要能在不開全文的情況下取得，這是篩選能先於精讀存在的結構性必要條件。
3. 篩選訊號要有真實的判別力——跟目標相關性沒關係的代理指標，篩了等於沒篩。
4. 篩選一定會犯錯，好設計要清楚知道該往哪邊犯錯：漏放（false negative）跟誤留（false positive）代價不對稱，取決於「錯了之後救不救得回來」——救得回來的錯可以容忍、判準可以鬆，救不回來的錯要嚴防、判準要收緊。
5. 篩選判準要可陳述、可追溯——事後才分得清楚是判準本身有問題，還是候選資料（摘要／索引／連結）本身沒寫好。

判準四延伸出一條操作結論：多數「AI 幫忙找」的場景裡，漏放是沉默、事後幾乎無法挽回的錯（沒有機制會告訴你漏了什麼），誤留是看得見、可控的錯（有後續機制接得住）——這種不對稱下，篩選該偏向「模糊地帶傾向放行」，真正的把關留給後面的機制去做。

篩選在 AI 執行時的實際失敗模式：不是設計風險，是可觀察到的執行特徵

上面「好篩選設計的五條判準」討論的是規則該怎麼寫；這節記的是規則寫對之後，AI 實際執行時仍會出現的落差——2026-09-04 一次真實的 hoard-query 執行裡，AI 完成語意候選（A）後直接收斂進答案，沒有走完規則明訂為「聯集、不取交集」的 grep 候選（B）與反向連結候選（C），儘管三類候選在 CLAUDE.md 裡寫得清楚、沒有任何「A 夠好就可以跳過」的但書。事後被要求補做時，反向連結（C）真的補到一則語意路徑找不到的相關內容（evergreen/topics/LLM Wiki/LLM Wiki 與 RAG 的差異 裡對「篩選」的定義）——證實這不是理論上的風險，是真實發生的漏檢。

診斷：這是生成式 LLM 的通用特性，不限 DragonsHoard、不限單次對話——一旦手上已經有一個讀起來完整、能自洽回答問題的答案，後續步驟只要不強制產出可觀察的中途產物，就容易被悄悄跳過，這件事跟規則寫得多詳細、多明確無關。本質上跟本頁前面討論的「命中就停」（找到就停的靜默 satisficing）是同一種機制，差別只在於：問題分類理論講的是「設計上該不該允許提早停」，這裡觀察到的是「就算設計上明講不能提早停，執行本身仍會自發傾向提早停」——後者更難防，因為它不是規則漏洞，是生成過程本身的傾向。

操作結論：對抗這個特性，解法不是把規則寫得更複雜、更詳細——這次的規則（三類聯集）已經足夠明確，加字沒有用。真正有效的做法是在容易被悄悄跳過的步驟上，要求產出一個哪怕是空的、但可被檢查的中途產物（例如明講「B 候選：無命中」而不是什麼都不寫），把「漏做」變成看得見的東西，而不是無痕跡地消失。這個原則本頁前面在別處已經先實踐過（觸發機制演變「四十三」用實際量測位元組數取代「AI 自覺得夠不夠」），只是這次是反過來從一次真實的執行失誤裡，重新印證同一個原則也適用在「AI 有沒有老實走完自己講好的步驟」這件事上。

PKM 社群實務：Map of Content（MOC）

MOC 不是演算法檢索，是刻意維護的人工導航頁，把同主題筆記手動串起來；Zettelkasten／Obsidian 社群共識是「不要一開始就建，筆記多到自己找不到時才建」。一份全域索引頁（例如 index.md）本質上就是全域 MOC；子專案自己的路由頁是子 MOC。這條實務支持「先讀索引頁再深入」的方向是對的，但單層 MOC 只能撐到主題數量有限的規模——大主題長大到需要自己的路由頁時，等於自然長出第二層 MOC，查詢機制要能遞迴套用同一套邏輯，不是另開一套。

新增的細部概念（比對兩份獨立整理後留下的）

• Precision/Recall 是獨立可命名的取捨維度：「找到就停」本質是 precision 優先的設計，這解釋了「命中就停會系統性漏掉東西」的機制原因，比籠統說「satisficing（找到堪用答案就停，不是找最優答案）」更精確。可以拆成兩條互相獨立的軸：

  問題要怎麼回答？
  Lookup ───────────── Synthesis / Exploration
  單一明確答案             需要整合、探索
  
  需要找多完整？
  Sufficient ───────── Exhaustive
  夠回答即可               儘可能找齊
  

• Information Foraging（Pirolli & Card, 1995）：什麼條件值得付出下一層搜尋成本，不是「有沒有命中」這種二元判斷，而是 information scent／cost-benefit——下一步預期能拿到多少資訊，值不值得多付的成本。

• Aliases/Redirects 是最低成本的第一級 lexical index：同義詞／舊稱／縮寫問題，直接靠 frontmatter 的別名欄位解，不用動全文檢索邏輯。

• Field/Zone weighting（title/tags/body 不同權重）：不同 zone 命中，該給不同的信心權重——例如標題／索引摘要命中，比正文全文命中更值得信任。

• Search Evaluation 要按資訊需求類型分開測，不能只看總準確率：驗證一套查詢機制有沒有變好，要按 Lookup／Exhaustive／Negative 等類型分別建測試集，不是隨便問幾題算通過率。

• Negative Query 是獨立一類，「查無結果」不等於「不存在」：查詢範圍內沒找到，只代表這次搜尋沒命中，不能宣稱內容不存在——這條也呼應了「查無結果不能說沒有記錄，只能說搜尋範圍內未命中」的實務規則。

參考來源：Gary Marchionini（exploratory search taxonomy）；Bates berrypicking model（1989/2002/2005）；Andrei Broder, “A Taxonomy of Web Search”（2002, SIGIR Forum）；Pirolli & Card, Information Foraging Theory（1995）；Obsidian/Zettelkasten 社群 Map of Content 實務；Full-text search／Faceted search（經典 IR 概念）；Spreading activation（Collins & Loftus, 1975，借用至資訊檢索）。

相關頁面

• 觸發機制演變「三十三」「四十三」— DragonsHoard 實際套用這套理論、推導出 hoard-query 最終機制設計的完整過程，含哪些方向被否決及原因
• LLM Wiki 與 RAG 的差異 — LLM Wiki 模式查詢方式（檔案系統操作）跟 RAG（向量相似度）的根本差異，這頁的檢索典範討論是在 LLM Wiki 這一側展開的細節
• Ingest — 同資料夾另一半：這頁討論「怎麼找回來」，Ingest 討論「怎麼放進去」