文獻知識庫的兩條路：Wiki 化與 RAG

1　先看規模，再選方法

選工具之前，先估算你的文獻有多少字。下表的門檻來自 Anthropic 與 Karpathy 公開的經驗值，是起點，不是定律。

KMDB 目前有 226 本書、約 8,100 萬字元的清理稿，遠超過一次對話能讀的量。所以我們兩條路都要：用 Wiki 整理概念與書與書之間的關係，用 RAG 回到全文找原句。本講義的示範只取其中 7 本研究方法書：

語料刻意混合三種情況：簡體中文譯本、英文原文、掃描 OCR 本。DBA 學生手上的文獻多半也是這樣混雜，而問題往往就出在這裡。

2　Wiki 化：讓 AI 先讀索引

這一節說明概念與做出來的樣子。想直接動手，請到第 8 節，從步驟 0 開始做。

2.1　2026 年的做法：LLM Wiki

Andrej Karpathy 在 2026 年 4 月公開了一種做法：不要每次提問都從原文重新撈片段，而是讓 LLM 把讀過的東西編譯成一個持續累積的 Markdown Wiki。他的原話是「the wiki is a persistent, compounding artifact」。他說自己的研究 Wiki 約 100 篇文章、40 萬字，原以為需要複雜的 RAG，結果 LLM 自己維護索引檔就夠用。

這個想法並不新。Zettelkasten 要求一則筆記只放一個概念、每則有固定 ID、連線時寫明為什麼連；Nick Milo 的 Maps of Content 用一頁地圖串起相關筆記；Andy Matuschak 的 evergreen notes 主張筆記要原子化、以概念為單位、密集連結。LLM Wiki 的新意在於，維護工作交給 AI，而這些筆記方法的原則，正好讓 AI 檢索更有效率。

2.2　讓 Wiki 檢索保持高效率的六條原則

2.3　用 KMDB 做出來的樣子

wiki/
├── AGENTS.md          給 AI 的維護規則（先讀這份）
├── index.md           索引：21 頁，每頁一行
├── log.md             維護紀錄，只往下追加
├── sources/           書目頁 7 頁：書目、摘要、可回查頁碼、清理品質備註
├── concepts/          概念頁 12 頁：跨書整合，每句附頁碼
├── maps/              主題地圖 1 頁：依論文流程排列
├── queries/           問答歸檔 1 頁：查詢後存回的答案
├── catalog/           KMDB 全部 226 本書，一行一本（程式自動產生）
└── tools/             build_catalog_index.py、wiki_lint.py

示範 Wiki 的原文留在 KMDB 裡，所以沒有 raw/ 資料夾；你自己做的 Wiki 會把書稿放進 raw/（第 8 節步驟 1）。catalog/ 是選配的全庫總目錄。

下面是一張概念頁的開頭。注意 relations 裡有一條連線標為「研究者推論」：把溯因分析的「意外發現」和孔恩的「反常」連在一起，是我們的判讀，不是任何一本書的主張。建立文獻樹時，最需要分辨的正是這件事。

---
id: CON-005
type: concept
title: 溯因分析
summary: 從理論預期之外的意外發現出發，提出暫時性解釋，再用資料反覆修正以建構新理論
aliases: [溯因推理, 溯因, abductive analysis, abduction, 意外發現, surprise]
sources: [SRC-TT-ABD]
relations:
  - {type: 方法延伸, target: qualitative-coding, basis: 引用}
  - {type: 概念相近, target: anomaly-crisis-incommensurability, basis: 研究者推論}
  - {type: 立場衝突, target: case-study-research, basis: 研究者推論}
status: draft
---
## 原書怎麼說
- `原文依據` 做菜比喻：想照食譜做菜卻發現沒有大蒜，只有一筐一時衝動買的
  金橘，於是運用已知的烹飪知識做出新菜（SRC-TT-ABD p.4）。
- `原文依據` 皮爾士把溯因描述為從意外事實跳到暫時性假設的推論；歸納與
  演繹負責後續的檢驗（SRC-TT-ABD p.14–16）。

2.4　健康檢查：KMDB 現有的真實問題

Wiki 會隨時間變亂。Karpathy 指出，人們放棄維護 Wiki，是因為維護負擔增加得比價值快；所以健康檢查要交給程式定期做。我們把檢查程式對 KMDB 的書目與知識萃取檔跑了一次，找到這些問題：

2.5　AI 起草會出錯：一個實例

這次的概念頁由 AI 起草，再回原書逐頁核對。核對時發現一處錯誤：AI 起草時把 Gillham 寫成「如果所有證據都一致，反而要懷疑」。回到原文第 19 頁，作者的意思其實是：

If every kind of evidence agrees then you have simple, confirmatory triangulation. … Often you don't get that.（Gillham, PDF p.19）

原文說的是「全部一致是單純的確認性三角驗證，但實際上常常不一致」，和 AI 寫的意思差很多。這就是為什麼概念頁預設是 status: draft，人工回原書核對後才改成 reviewed；也是為什麼每句主張都要附頁碼。沒有頁碼，這個錯就查不出來。

3　RAG：一次做起來

RAG（Retrieval-Augmented Generation，檢索增強生成）的骨架只有六步。課程筆記本把每一步都攤開，中間結果都印出來（下載筆記本，再到 Colab 上傳開啟｜檢視程式碼 kmdb_rag.py）：

3.1　前處理：三個看不見的問題

PDF 斷行。轉出的文字每行都硬換行，一句話被攔腰截斷。不處理的話，切分程式找不到句子的邊界。

簡體原文、繁體提問。示範語料中 6 本是簡體譯本，抽樣約有三成的漢字繁簡寫法不同。用繁體問「為什麼」，簡體原文寫的是「为什么」，關鍵字檢索就對不上。我們用 OpenCC 的 s2tw 統一轉成臺灣用字；不要用 s2t，它會把「吃」轉成「喫」、「為」轉成「爲」。

譯名與 OCR 雜訊。簡中譯本寫「庫恩」「常規科學」「不可公度」，臺灣慣用「孔恩」「常態科學」「不共量性」，這是字形轉換解決不了的。Yin 一書是掃描本，頁首常出現「2 RAFRARHRIt 59」這類亂碼，也有「圳括」這樣的錯字。

繁簡未統一的對照，是把語料維持簡體、問題維持繁體，其餘條件相同。

3.2　切分：同一段文字，兩種切法

下面是孔恩一書導讀的同一段文字，標記 ｜ 的地方是切點。固定長度切分每 500 字切一刀，切在「工｜作」中間；遞迴切分先找段落，再找句號，切在句子結束處。

固定長度 500 字

遞迴切分 500 字

4　實作單元：在 Colab 跑出你的第一個 RAG

這個單元帶你用 Google Colab 從頭到尾跑一次 RAG_一次做起來.ipynb。Colab 是 Google 提供的線上 Python 筆記本，用瀏覽器就能執行，不必在自己的電腦安裝 Python。全程約 30–40 分鐘，其中一半以上的時間是在等模型下載與向量化。

做完之後，你會得到三樣東西：

• 三本書、四種切法的索引；
• 一張比較各種切法命中率的表；
• 一段附來源編號、可以直接貼給 Claude 的提示詞。

各步驟附上的輸出，是用預設的 3 本書實際執行的結果。你的畫面應該大致相同，但時間會依機器而異。

4.1　開始之前

• 一個 Google 帳號。
• KMDB 練習資料：Google Drive 資料夾，可以直接檢視與下載。書稿放在其中的 books/。
• 筆記本：在 Colab 開啟（打開 Drive 上 00_課程示範/rag/ 的課程版），或下載 .ipynb 檔，再到 Colab 上傳開啟。
• 預設的 3 本書：溯因分析、論文寫作與時間管理，以及 Gillham 的英文版個案研究。熟悉流程後，再換成你自己的書。

4.2　打開筆記本與連接資料

4.3　讓 Colab 找到書稿（最容易出錯的一步）

Colab 在 Google 的雲端主機上執行，讀不到你電腦裡的檔案。書稿要放在 Colab 看得到的地方，筆記本才讀得到。

以下兩種方式擇一。建議用方式 A：做一次，之後每次打開筆記本都讀得到。

方式 A：新增捷徑，再掛載雲端硬碟

1. 用和 Colab 相同的 Google 帳號打開 KMDB 練習資料夾。先看右上角的頭像：同時登入學校與個人帳號時，最容易在這裡用錯帳號。
2. 在頁面上方資料夾名稱旁的 ▾ 選單，選「整理 → 新增捷徑」，位置選「我的雲端硬碟」，按「新增」。
3. 到 我的雲端硬碟 確認：出現 KMDB_CM979_唯讀複本_20261003，圖示左下角有一個小箭頭，就是捷徑。捷徑不佔你的空間，內容是唯讀的。不要用「建立副本」，也不要整個資料夾下載再上傳：一千多個檔案，很慢，也沒有必要。
4. 回到 Colab，執行步驟 1a。跳出授權視窗時選同一個帳號，畫面上的權限全部勾選，再按「繼續」。
5. 看輸出的最後一行：出現「✔ 找到書稿：KMDB_CM979_唯讀複本_20261003/books（226 本書）」就完成了。

方式 B：下載幾本書，上傳 zip 到 Colab

不想讓 Colab 存取你的雲端硬碟時用這個方式。缺點是每次重新連線都要再上傳一次。

1. 打開 books 資料夾，按住 Ctrl（Mac 按 ⌘）點選 2–3 本書的資料夾，按右鍵「下載」。Drive 會先顯示「正在準備下載」，完成後下載一個 zip。
2. 在 Colab 左側點資料夾圖示，再點上方的上傳圖示，選這個 zip。等檔名旁的進度圈跑完，才算上傳完成。
3. 在左側的 zip 檔上按右鍵「複製路徑」，貼到步驟 1a 的 ZIP_NAME 兩個單引號中間，並把 USE_DRIVE = True 改成 USE_DRIVE = False。
4. 執行步驟 1a。最後一行出現「✔ 找到書稿：KMDB_CM979_唯讀複本_20261003/books（2 本書）」之類的訊息，就完成了；括號裡是你上傳的本數。

步驟 1 的 DATA_DIR 怎麼寫

最簡單的做法：照抄步驟 1a「✔ 找到書稿」那一行印出的路徑；和預設值相同時，就不必改。要自己寫時，對照表 9。在 Colab 裡，「我的雲端硬碟」叫做 MyDrive，步驟 1a 已經切換到那裡，所以從「我的雲端硬碟」底下的資料夾開始寫即可。

寫法規則只有三條：前後各一個英文單引號；資料夾之間用 /，不要用 Windows 的 \；不要寫成「我的雲端硬碟/…」。

不想手打時：點 Colab 左側的資料夾圖示 → 依序展開 drive → MyDrive → 找到 books → 按右鍵「複製路徑」→ 貼到 DATA_DIR 的兩個單引號中間。

筆記本另外有幾道防呆：DATA_DIR 指到上一層（例如 KMDB 資料夾本身）時，會自動往下找到 books；課程資料夾的路徑寫錯時，會改用步驟 1a 找到的位置，或到雲端硬碟裡往下找三層；寫成「我的雲端硬碟/…」也會自動換成 MyDrive。自己的資料夾找不到時會直接報錯，不會自動猜，以免讀錯書。

出錯時怎麼處理

4.4　依序執行步驟 1–6

步驟 1：設定與讀檔。先不必改設定，直接執行。BOOKS 列出要用的書，QUESTIONS 是 3 道已確認答案頁的示範題。執行後會印出每本書的頁數與字數：

case-study-research-methods-bill-gillham     57 頁／區塊   166,451 字元  《Case Study Research Methods》
data-analysis-to-theory-breakthrough        161 頁／區塊   180,810 字元  《從資料分析到理論突破……》
graduate-thesis-writing-time-management     133 頁／區塊   127,030 字元  《研究生論文寫作與時間管理》
合計 3 份文件

頁數比原書少一兩頁是正常的：空白頁和純圖頁沒有文字，讀檔時會被略過。

步驟 2：前處理。這一格印出同一段文字處理前後的樣子。請找兩件事：「⏎」代表的硬換行是否被接回去，簡體字是否轉成了臺灣繁體。例如「意外发现」會變成「意外發現」。

步驟 3：切分。第一次執行會下載約 470 MB 的向量模型，請耐心等候。接著印出四種切法的統計：

策略               片段數      平均字元    平均 token      超過 512 被截斷
S1 固定 500        938       499         245           0.0%
S3 遞迴 500       1162       402         198           0.0%
S4 一頁一塊          351      1331         645          80.9%
S6 小塊找整頁答       2932       159          81           0.0%

注意最後一欄：「一頁一塊」有八成的片段超過模型一次能讀的 512 tokens，超出的部分模型根本沒讀到。下一格會用「｜」標出 S1 與 S3 在同一段文字上的切點，比較看看哪一種會把句子切斷。

步驟 4：建索引。每種切法建一次 BM25 與向量索引，這是最花時間的一步。在 CPU 上，每種切法約需 1–2.5 分鐘；GPU 快很多。

S1 固定 500：938 個片段，建索引 149 秒
S3 遞迴 500：1162 個片段，建索引 104 秒
S4 一頁一塊：351 個片段，建索引 59 秒
S6 小塊找整頁答：2932 個片段，建索引 95 秒

步驟 5：檢索與評估。第一格用 Q1 比較 4 種切法 × 3 種檢索法的前三名，✔ 表示命中答案頁：

S3 遞迴 500   BM25 ·graduate-thesi:PDF 第 29 頁 ✔data-analysis-:PDF 第 4 頁 ·data-analysis-:PDF 第 137 頁
S3 遞迴 500   向量   ✔data-analysis-:PDF 第 14 頁 ·data-analysis-:PDF 第 133 頁 ✔data-analysis-:PDF 第 3 頁

BM25 的第一名來自論文寫作那本書：它只比對字面，問題裡的「歸納」「演繹」在那本書也出現過。向量檢索的第一名就是答案頁。第二格計算 3 題的 Hit@5：

策略              BM25      向量      混合      前5名總字數
S1 固定 500        67%     67%     67%       2,500
S3 遞迴 500        67%     67%     67%       2,046
S4 一頁一塊          67%     67%     67%       5,313
S6 小塊找整頁答        67%     67%     67%       5,507

每種做法都只找到 2 題。沒找到的是 Q3：用中文問 Gillham 的英文書。

步驟 5b：加上譯文。TRANSLATIONS 已經放了 Q3 的英文譯文。執行後，Q3 從找不到變成找得到：

S3 遞迴 500    只用原問題    0%　加上譯文  100%

這和第 5 節的完整實驗一致：跨語言時，先翻譯問題，比調整切分有效。

步驟 6：生成。這一格印出一段提示詞：開頭是作答規則，接著是 [1]–[5] 的原文摘錄，每段標明書名與 PDF 頁碼，最後是你的問題。整段複製，貼到 Claude 的對話框。檢查回答中的每個論點是否都附了 [編號]，再挑一個編號，回到原書那一頁核對。

有 Anthropic API 金鑰的話，在 Colab 左側的鑰匙圖示（密鑰）新增 ANTHROPIC_API_KEY，並開啟這份筆記本的存取權，這一格就會直接印出 Claude 的回答。金鑰不要直接寫在程式碼裡，分享筆記本時才不會外流。

4.5　換成你自己的書與問題

1. 挑書：打開 00_課程示範/wiki/catalog/books-catalog.md，每行最後的 books/…/ 就是書名代號。把 2–4 個代號填進 BOOKS。
2. 找答案頁：打開那本書的 cleaned_*.md，用搜尋找出答案所在的段落，往上找最近的「### PDF 第 N 頁」，那就是頁碼。再對照 PDF 確認一次。
3. 寫問題：在 QUESTIONS 寫 3–5 題，gold 填書名代號與頁碼。至少放一題跨語言的題目，並在 TRANSLATIONS 補上譯文。
4. 從步驟 1 重新執行：選單「執行階段 → 執行之後的所有儲存格」。

4.6　常見問題

4.7　完成之後，想一想

1. 在你自己的題目中，哪一題 BM25 找到了、向量沒找到，或反過來？從問題的用字和原文的用字，你怎麼解釋？
2. 「一頁一塊」與「小塊找整頁答」送給 Claude 的字數，都是遞迴切分的兩倍以上。對你的研究問題來說，多給的脈絡值不值得？
3. Claude 根據摘錄寫出的回答，你回原書核對後，有沒有哪一句的意思被改變了？

5　切分策略的實驗結果

同一組 7 本書，用 7 種切法各建一次索引，再用 3 種檢索法回答同樣 20 題。評估指標是 Hit@5：答案所在的 PDF 頁是否出現在前 5 名片段中。20 題的答案頁都已回原文逐題確認。

向量化時間在 2 核心 CPU 上測得，且同時有其他工作在跑，只供相對比較。語意切分的時間包含逐句計算向量。

5.1　從結果讀出什麼

1. 差距最大的不是切分，而是語言。用中文問簡中譯本的 14 題，各策略在混合檢索下的 Hit@5 介於 93% 到 100%。用中文問英文書、用英文問簡中書的 5 題（Q05；Q06；Q16；Q17；Q19），所有策略在混合檢索下最多只找到 1 題。把這 5 題翻成文獻的語言，原問題與譯文兩組結果再以 RRF 合併後，命中率大幅回升：

   表 14　跨語言 5 題：原問題 vs. 雙語查詢（混合檢索 Hit@5）。最右欄是換成雙語查詢後，20 題整體命中率的變化

   策略	只用原問題	原問題＋譯文	20 題整體
   S1 固定長度 500 字	20%	80%	75% → 90%
   S2 固定長度 500 字＋重疊 100	20%	80%	70% → 85%
   S3 遞迴切分 500 字	0%	60%	75% → 90%
   S4 依結構（一頁一塊）	0%	80%	65% → 85%
   S5 語意切分	—	—	—
   S6 小塊檢索、整頁作答	20%	100%	80% → 100%
   S7 遞迴＋書名頁碼標頭	0%	40%	75% → 85%

   語意切分（S5）未重跑這項對照。對手上有中英文獻的 DBA 學生來說，先做雙語查詢，比調整切分參數有效得多。multilingual-e5-small 是小型多語模型，換用 bge-m3 等較大的模型，跨語言表現可能改善，但仍值得先用自己的題目測過。

2. 前處理比切分更重要。簡體原文沒有先轉成繁體時，BM25 的 Hit@5 從 75% 掉到 45%，是所有比較中最大的落差。接回 PDF 斷行的影響較小（75% 對 70%），可能是因為斷行只拆散了跨行的那一組字元二元組。

3. 一頁一塊最差。KMDB 的一頁平均 562 tokens，有 61% 的頁面超過向量模型的 512 tokens 上限，後半頁根本沒被讀到。Hit@5 只有 60%–65%，送給 LLM 的字數卻是遞迴切分的 2.6 倍。NVIDIA 發現依頁切分最好，和我們的結果相反；差別在於他們用的模型能讀完整頁。結論是：片段長度要配合向量模型的上限。

4. 重疊沒有幫助。S2 比 S1 多了 25% 的片段，向量與混合檢索的 Hit@5 都下降一題；以向量檢索為例，從 75% 降到 70%。這與 Chroma 及 2026 年系統性分析的結論一致。

5. 語意切分的效益不足以支付成本。S5 在混合檢索下比遞迴切分多命中一題（80% 對 75%），MRR 相同（0.64），卻多花了約 6 分鐘逐句計算向量；BM25 的 MRR 則明顯較低。一題的差距在 20 題中不足以下結論，這與 NAACL 2025「成本換不到穩定提升」的結論並不矛盾。

6. 遞迴切分是穩定的基準。S3 向量檢索的 Hit@5 達 80%，是單一檢索法中最高；中文問簡中書的 14 題，三種檢索法全部命中。加上書名頁碼標頭（S7）讓 BM25 的 MRR 從 0.60 升到 0.62，差距在一題以內；但在跨語言的題目上，S7 反而比 S3 差（表 14），可能是中文標頭讓英文片段的向量偏向中文。

7. 小塊找、整頁答的召回率最高，代價是字數。S6 混合檢索的 Hit@5 為 80%，加上雙語查詢後跨語言 5 題全部命中；但前 5 名送給 LLM 的字數約 7,012 字，是遞迴切分的 3 倍多。要求完整脈絡時選它，在意成本與精準時選 S3。

限制：只有 20 題，一題就是 5 個百分點；評估題是為本講義撰寫並逐題回原文確認答案頁，可能偏向撰寫者熟悉的用詞。向量模型只測了一種。這些結果說明的是「這批資料、這個模型」的情況，用意是示範評估方法，不是給出通用排名。

5.2　逐題看：哪一題、哪一種切法找得到

下表是混合檢索下，答案頁在第幾名出現。綠色表示前 5 名，黃色表示第 6–10 名，紅色的「—」表示前 10 名都沒有。

5.3　研究文獻怎麼說

2026 年可以採用的起手式：先依 Markdown 結構切（章、節、頁），過長的再用遞迴切到 256–512 tokens，中文要把「。！？」加進分隔符號；重疊從 0 開始試；語意切分不必當預設；檢索用 BM25＋向量混合；回傳給 LLM 時用小塊找、大塊答。最重要的一條：用你自己的問題評估。所有研究都指出，最佳設定會隨資料集改變；我們這次的結果也與部分文獻不同。

另外常被引用的「FloTorch 2026 基準：遞迴 69%、語意 54%」，原始出處目前無法讀取，二手文章的歸屬也互相矛盾，課堂上可當成「二手引用要溯源」的例子，不宜當作定論。

6　RAG 資料庫、開源方案與前端

6.1　這份講義的 RAG 是怎麼做的

第 3–5 節的 RAG 是「實驗室版本」：一支 Python 程式（kmdb_rag.py）每次執行時，把書讀進來、切分，再在記憶體裡建兩套索引。BM25 關鍵字索引由 rank_bm25 套件建立；語意向量由 multilingual-e5-small 模型產生，存成一個數字矩陣。查詢時兩套索引各排一次，再以 RRF 合併成前 5 名。最後把這 5 段原文組成附來源編號的提示詞，貼給 Claude 作答。

它沒有資料庫伺服器，也沒有網頁介面，結果直接印在筆記本裡。這樣做是為了讓每一步都看得到，也方便同一批書換七種切法反覆比較。代價是索引每次都要重建：這次 7 本書在一般筆電等級的 CPU 上，光是向量化一種切法就要 4–8 分鐘。若要涵蓋 KMDB 全部 226 本、約 8,100 萬字元，就不能每次重算，這時才需要真正的 RAG 資料庫。

6.2　和 RAG 資料庫、套裝方案的差別

表中的 LlamaIndex、LangChain、Haystack 這類名稱沒有列成一列，因為它們是框架：寫 Python 版 RAG 時用來少寫程式的工具組，本身沒有給使用者的介面。這份講義刻意不用框架，是為了讓切分、索引、合併每一步都看得見；正式建庫時用框架，可以省下大量程式碼。

「RAG 資料庫」比本講義的筆記本多了四件事：

1. 持久保存：索引存在磁碟上，關掉電腦再開，不必重算。
2. 增量更新：新增、修改、刪除一本書時，只處理那本書的片段。
3. 中繼資料篩選：例如只查 2020 年以後的文獻，或只查某幾本書。
4. 多人同時使用：伺服器型資料庫可以讓研究團隊共用同一個索引。

6.3　一定要有前端介面嗎？

看是誰要用。給自己做研究時，Claude Code 或 Codex 的對話視窗本身就是介面，不必另做網頁。依需要，有三種接法：

要給別人用時才需要前端，例如給研究團隊、給不寫程式的同事。Streamlit 或 Gradio 用幾十行 Python 就能做出「輸入問題、顯示原文段落、產生回答」的網頁；不想寫程式，就直接用表 17 的套裝應用。對多數 DBA 學生的個人論文研究來說，Wiki 加上一支可以由 AI 執行的檢索程式就夠了。

6.4　One-shot 提示詞怎麼寫

One-shot 的意思是：一次把需求講完整，讓 AI 能從頭做到驗證，而不是一來一往地補需求。一份好的 one-shot 提示詞包含七個部分：

1. 目標
2. 資料的位置與格式，最好附一個實際的檔案片段
3. 要做的步驟
4. 技術選擇
5. 驗證標準，例如黃金問題、要通過的測試
6. 不可以做的事
7. 完成後要回報什麼

下面三份提示詞由淺到深，可以直接複製到 Claude Code 或 Codex。

提示詞 A：寫出檢索程式（等同本講義的做法，附驗證）

請在這個資料夾建立一個最小的文獻 RAG 檢索程式，供我做研究使用。

【資料】
- books/ 底下每個子資料夾是一本書，全文在 cleaned_*.md。
- 每頁以「### PDF 第 N 頁」開頭；檔案開頭到「## 全書正文」之前是中繼資料，不要索引。
- 多數中文書是簡體字，我會用臺灣繁體中文提問；也有英文書。

【要做的事】
1. 讀檔時保留每個片段的書名與 PDF 頁碼。
2. 前處理：接回 PDF 的硬換行；用 OpenCC 的 s2tw 把簡體轉成臺灣繁體。
3. 切分：遞迴切分，目標 500 字元，分隔符號依序為段落、換行、。！？、英文句點、逗號；不加重疊。
4. 索引：BM25（中文用字元二元組，英文用單字）加上 intfloat/multilingual-e5-small 向量
   （查詢加 "query: "、片段加 "passage: " 前綴），兩者以 RRF 合併。
5. 向量存成檔案，第二次執行不必重算。
6. 指令列用法：python search.py "問題"，印出前 5 名，每筆附書名、PDF 頁碼與前 200 字。
7. 另寫 build_prompt()：把前 5 名組成附 [編號] 來源的提示詞，要求模型只能依摘錄回答，
   摘錄不足時說明缺什麼。

【驗證】
- 先只用 2 本書跑通，再跑全部。
- 寫 tests/test_search.py，至少包含：
  (1) 隨機抽 3 個片段，確認原檔中標示的那一頁確實含有這段文字；
  (2) 以下黃金問題的答案頁出現在前 5 名：
      「溯因分析和歸納法、演繹法有什麼不同？」
        → data-analysis-to-theory-breakthrough，PDF 第 3、4、14–16 頁
      「寫論文時應該怎麼分配時間？」
        → graduate-thesis-writing-time-management，PDF 第 44–45 頁
- 用一題書中沒有的問題（例如「2026 年台積電營收是多少？」）產生提示詞，
  確認提示詞會要求模型說找不到依據。

【限制】
- 不要修改 books/ 裡的任何檔案。
- 先提出計畫讓我確認，再開始寫程式；需要安裝套件或下載模型時先告訴我。
- 完成後回報：建立了哪些檔案、完整的測試輸出、跑全部書花了多久、已知限制。

下載這份提示詞（A-search-program.md）

提示詞 B：升級成 RAG 資料庫＋網頁前端

請把現有的 search.py 升級成可以長期使用的文獻 RAG。

【資料庫】使用 Chroma 的 PersistentClient，資料存在 ./db。
每個片段的 metadata 包含 book、title、page、source_path，以及來源檔的 sha256。

【增量更新】python ingest.py 只處理新增或內容雜湊改變的書；
已刪除的書要從資料庫移除；每次執行把新增／更新／刪除寫入 ingest_log.jsonl。

【前端】用 Streamlit 做一個頁面：
- 輸入問題，可以勾選只查哪幾本書；
- 顯示前 5 段原文，每段附書名與 PDF 頁碼；
- 按「產生回答」才呼叫 Claude API。API 金鑰從環境變數 ANTHROPIC_API_KEY 讀取，
  不要寫進程式碼或任何檔案。

【回答規則】每個論點後面附 [編號]；摘錄不足時明說找不到依據，不要自行補充。

【驗證】
- 沿用 tests/ 裡的黃金問題，全部要通過。
- 新增一本書後，確認只有那本被處理；刪除一本書後，確認查不到它的片段。
- 用 streamlit run app.py 在本機開啟，並截圖給我看。

【限制】先給計畫；不要改 books/；完成後列出啟動指令與完整測試輸出。

下載這份提示詞（B-database-frontend.md）

提示詞 C：包成 MCP 工具，讓 Claude Code 與 Codex 直接查

請把 search.py 包成本機 MCP server，用官方 Python MCP SDK 撰寫，以 stdio 執行。
提供一個工具 search_literature(query, top_k=5, books=None)，回傳片段文字、書名與 PDF 頁碼。

完成後：
1. 告訴我在 Claude Code（claude mcp add）與 Codex（codex mcp add）註冊這個 server 的指令；
2. 自己用一個黃金問題呼叫一次，貼出回傳結果；
3. 在 README 寫明這個工具只讀取 books/ 與 db/，不會寫入任何檔案。

下載這份提示詞（C-mcp-tool.md）

7　在 Claude Code 或 Codex 裡一次寫出程式並驗證

以下以提示詞 A 為例，走一次完整流程。兩個工具的操作大同小異，差別列在表中。

7.1　五項驗證：不要只相信 AI 說「完成了」

1. 親手跑一次：在終端機執行 python search.py "溯因分析和歸納法有什麼不同？"，看前 5 名是不是你預期的書和頁。
2. 抽查頁碼：從結果中挑一段，打開原檔搜尋開頭幾個字，確認它真的在標示的那一頁；再翻原始 PDF 對一次。
3. 黃金問題：自己再加 2–3 題你知道答案在哪一頁的問題，請 AI 加進測試。
4. 問一題書裡沒有的：把提示詞貼給 Claude，確認它說「找不到依據」，而不是編一個答案。
5. 看改了什麼：執行 git status 與 git diff，確認 books/ 沒有被改動；也檢查 AI 有沒有為了讓測試通過而修改測試本身。

8　用 Obsidian 一步一步建 Wiki

Obsidian 是一套讀寫本機 Markdown 檔案的筆記軟體。它不會把你的檔案鎖在自家格式裡，所以 Obsidian 編輯的資料夾，Claude Code 或 Codex 也能同時讀寫。下面的流程從課程提供的骨架 wiki-starter/ 開始，分成兩個階段：

• 階段一：親手做出最小的 Wiki（步驟 0–9，約 40 分鐘）。只用 Obsidian，不需要 AI 工具，也不需要 Python。
• 階段二：讓 AI 接手維護（步驟 10–14）。用 Claude Code 或 Codex 匯入第二本書、執行健康檢查、用 Wiki 回答問題。

第一次只要做到這條鏈：概念頁 →（引用＋頁碼）→ 書目頁 → raw/ 裡的清理稿 → 找到「### PDF 第 N 頁」那一段原文。這條鏈成立，Wiki 的核心就學會了；關係圖、Bases 與 AI 匯入，都是在這條鏈上增加的功能。

8.1　開始之前

講義使用 Obsidian 的英文介面名稱。第一次操作建議維持英文介面，選單名稱才對得上。動手前，先弄清楚四個觀念：

1. vault 就是一個資料夾：Obsidian 把你選定的資料夾叫做 vault，裡面的 .md 檔就是筆記，不會被轉成別的格式。
2. Properties 就是 frontmatter：Obsidian 畫面上的 Properties 面板，是檔案最上方兩條 --- 之間那段文字（YAML frontmatter）的表單介面，兩者是同一批資料。要看原文，就切到原始碼模式：按 Ctrl／Cmd＋P 開啟命令面板，輸入 source，選 Toggle Live Preview/Source mode；再做一次就切回來。
3. 一個頁面有四個名字，見表 22。
4. 連結有兩種，見表 23。

[[abductive-analysis|溯因分析]] 的前半段是要連到的檔名，後半段是畫面上顯示的文字。檔名用英文，是為了讓不同譯名都指到同一個檔案，AI 引用時也不會因為中文標點或空格出錯。寫在 Markdown 表格裡時，中間的 | 要寫成 \|，否則表格會被切斷。

規則：每寫一條 relations，內文也要有一個對應的 [[連結]]。relations 這種多層欄位在 Properties 面板裡無法正常編輯，一律在原始碼模式修改。一行的 {type: 引用, target: …} 和逐行條列兩種寫法都可以；示範 Wiki 用前者，下面的範例用後者，比較不容易打錯。

8.2　階段一：親手做出最小的 Wiki

書目頁範例（步驟 5）

---
id: SRC-TT-ABD
type: source
title: 從資料分析到理論突破：如何用溯因分析做出創新性的質性研究
summary: 以溯因分析從質性資料做出理論突破：意外發現、開放編碼與聚焦編碼
aliases: [從資料分析到理論突破, 蒂默曼斯與塔沃里]
author: 史蒂芬．蒂默曼斯（Stefan Timmermans）、伊多．塔沃里（Iddo Tavory）
raw: raw/data-analysis-to-theory-breakthrough/cleaned_data-analysis-to-theory-breakthrough.md
raw_language: 簡體中文譯本
status: draft
updated: 2026-10-03
---

# 從資料分析到理論突破

- 作者：史蒂芬．蒂默曼斯（Stefan Timmermans）、伊多．塔沃里（Iddo Tavory）
- 原始層：`raw/data-analysis-to-theory-breakthrough/cleaned_data-analysis-to-theory-breakthrough.md`（簡體中文譯本）

## 定位摘要

本書主張質性研究的理論突破來自「意外發現」：研究者熟悉既有理論，才看得出資料中不符合預期的地方，再提出暫時性的解釋，並用資料反覆修正。

## 可回查頁碼

- 意外發現與金橘的做菜比喻：PDF 頁 2–4
- 溯因與歸納、演繹的差別：PDF 頁 14–16

概念頁範例（步驟 6）

---
id: CON-001
type: concept
title: 溯因分析
summary: 從理論預期之外的意外發現出發，提出暫時性解釋，再用資料反覆修正以建構新理論
aliases: [溯因推理, 溯因, abductive analysis, abduction]
sources: [SRC-TT-ABD]
relations:
  - type: 引用
    target: timmermans-tavory-abductive-analysis
    basis: 引用
status: draft
updated: 2026-10-03
---

# 溯因分析

## 一句話

從理論預期之外的「意外發現」出發，提出最有希望的暫時性解釋，再反覆用資料檢驗與修正。

## 原書怎麼說

- `原文依據` 做菜比喻：想照食譜做菜卻發現沒有大蒜，只有一筐一時衝動買的金橘，於是運用已知的烹飪知識做出新菜（SRC-TT-ABD p.4）。
- `原文依據` 皮爾士把溯因描述為從意外事實跳到暫時性假設的推論；歸納與演繹負責後續的檢驗（SRC-TT-ABD p.14–16）。

## 來源

- [[timmermans-tavory-abductive-analysis|蒂默曼斯與塔沃里《從資料分析到理論突破》]]

補上的連結（步驟 7，換掉書目頁「可回查頁碼」的第一行）

- 意外發現與金橘的做菜比喻：PDF 頁 2–4 → [[abductive-analysis|溯因分析]]

完整的範例頁（欄位與內容較多，可對照）：書目頁、概念頁。

階段一完成的標準：一個 vault、raw/ 裡有一本書、一張書目頁、一張概念頁、兩頁互相連結，而且能從頁碼回到清理稿裡的原句。做到這裡就可以停；階段二是進階。

8.3　階段二：讓 AI 接手維護

Claude Code 與 Codex 是能直接讀寫你電腦資料夾的 AI 工具。網頁版的 Claude 或 ChatGPT 看不到你電腦裡的 index.md，所以這個階段一定要在 Claude Code 或 Codex 裡、開啟 my-literature-wiki 這個資料夾操作。兩套工具擇一即可，操作原理相同。

匯入提示詞（步驟 11；換成別本書時，只改書名代號那一處）

請先讀 AGENTS.md，再依下列順序工作，每做完一步就告訴我結果：

0. 先確認這台電腦能執行 Python（執行 python --version；Windows 上若失敗，再試 py --version）。
   兩者都不能執行時，停下來告訴我錯誤訊息，不要修改任何檔案。
1. 依 AGENTS.md「匯入」的步驟，把 raw/case-study-research-methods-bill-gillham/ 這本書匯入 Wiki：
   - 建立 1 張書目頁；概念頁最多新建 5 張。新建之前先查 index.md 與各頁的 aliases，
     已有的概念就補一節「這本書怎麼說」，不要重複建頁。
   - 檔名只用英文小寫、數字與連字號；所有新頁面的 status 一律填 draft。
   - 每句「原文依據」都附（SRC-ID p.頁碼），頁碼必須回 raw/ 的清理稿找到「### PDF 第 N 頁」確認；
     查不到就標「待回查」。
   - 連線只能用五種類型：引用、概念相近、方法延伸、立場衝突、研究者推論；
     原書沒有直接說的關聯，一律標「研究者推論」。每條 relations 在內文也要有對應的 [[連結]]。
2. 執行 python tools/build_index.py 與 python tools/wiki_lint.py，貼出健康檢查報告的完整內容。
   「需要處理」的項目請修正後再執行一次；標題含「提醒」的項目不用修。
3. 在 log.md 尾端追加一筆 ingest 紀錄。
不要修改 raw/ 與 AGENTS.md 裡的任何內容。

下載這份提示詞（D-wiki-ingest.md）

查詢提示詞（步驟 13；換成自己的問題時，只改「問題：」那一行）

請先讀 AGENTS.md 與 index.md，再依 AGENTS.md「查詢」的步驟回答下面的問題：

問題：溯因分析和 Gillham 的個案研究，對「理論要不要先行」的看法有什麼不同？

- 只讀 index.md 加 3–5 個相關頁面；每個論點附（SRC-ID p.頁碼），需要時回 raw/ 的清理稿核對。
- Wiki 裡找不到依據的部分，直接寫「Wiki 中沒有依據」，不要自己補充。
- 回答後，把問題與回答存成 queries/ 裡的新頁：type 填 query，ID 用 QA- 開頭，
  檔名只用英文小寫、數字與連字號，status 填 draft；內文用 [[連結]] 連到引用的頁面。
- 存檔後執行 python tools/build_index.py 與 python tools/wiki_lint.py，貼出健康檢查報告，
  並在 log.md 尾端追加一筆 query 紀錄。
不要修改 raw/ 與 AGENTS.md 裡的任何內容。

下載這份提示詞（E-wiki-query.md）

8.4　備份與進階外掛

Obsidian 的核心外掛 File recovery 會定期保留筆記的快照，可以救回誤刪的內容；要完整追蹤每次變更，就用 Git。進階外掛都屬於社群外掛，要在設定中開啟社群外掛後才能安裝：

• Dataview：用查詢語法列出符合條件的筆記。
• Smart Connections：用本機向量模型找出語意相近的筆記，等於在 Obsidian 裡內建一個小型 RAG。
• Copilot for Obsidian：在 vault 裡和 AI 對話。

安裝前先看清楚授權，以及資料會不會送到雲端。

9　兩者怎麼搭配

實務上的分工：RAG 負責找，Wiki 負責記。用 RAG 找到原文段落、核對頁碼後，把整理好的結論寫進 Wiki，並在 log.md 留下一筆紀錄。下次再問相關問題，AI 先讀 Wiki，不必從頭撈。Karpathy 所說「好的答案應該存回 Wiki」，指的就是這個循環。

10　課堂流程與討論

10.1　取得 KMDB 練習資料

課程提供一份 KMDB 的唯讀複本，內含 226 本書的清理稿、知識萃取、書目檔，以及 00_課程示範/，也就是本講義的 Wiki 示範與筆記本。資料夾在 Google Drive，可以直接檢視與下載；各子資料夾的連結見表 30。

講義用到的程式、提示詞與 Wiki 骨架另外收在本頁的實作包，不含書稿，可以直接下載。

KMDB 練習資料只限本課程練習使用，請勿轉傳。共用資料夾是唯讀的：要練習時，先把需要的幾本書下載到自己的電腦，再在自己的資料夾中操作。在 Drive 對資料夾按右鍵選「下載」，Drive 會打包成 zip；整個資料夾約 150 MB，建議只下載需要的幾本書。

10.2　今天的流程

請在課前完成第 8 節步驟 0–3：下載並解壓縮實作包、把第一本書放進 raw/、安裝 Obsidian、開成 vault。課堂時間才夠做核心的步驟 4–8。

基礎路徑：完成 Wiki 起始版，包括 AGENTS.md、index.md、3 張書目頁、5 張以上的概念頁，且至少一條連線標為「研究者推論」。

進階路徑：再用第 7 節的流程與提示詞 A，以自己選的書寫出檢索程式並完成五項驗證。

10.3　討論題

1. 本次實驗中，片段最長的「一頁一塊」並沒有比較好找。從表 13 的「超過 512 被截斷」一欄，你怎麼解釋？如果換成一次能讀 8,000 tokens 的向量模型，你預期結果會怎麼變？
2. 文獻研究多半建議遞迴切分不加重疊，而 Anthropic 建議為每個片段補上脈絡說明。在你的論文文獻中，哪一種資訊最容易在切分後遺失：書名、章節、作者立場，還是前後文的論證？
3. 你的 Wiki 裡，哪一條連線最可能是研究者推論，卻被誤標成引用？這種誤標會怎麼影響你在文獻探討中的論證？
4. 2.5 節的例子中，AI 起草的概念頁把原意寫反了。如果你的 Wiki 有 200 頁，你會用什麼流程與抽查比例，確保錯誤不會累積？
5. 你的論文研究需要表 17 中的哪一種做法？什麼樣的條件出現時，你才需要從「AI 直接讀 Wiki」升級到「RAG 資料庫加前端」？
6. Karpathy 的做法受到一種批評：摘要與整理本身就是產生洞見的過程，全部交給 AI，等於把思考外包。你同意嗎？在你的研究中，哪些頁面你會堅持自己寫？

附錄　下載檔案一覽

所有檔案都收在整包 zip 裡，也可以個別開啟。文字檔（.md、.py、.json）點開會直接顯示在瀏覽器中，可以全選複製；.ipynb 與 .zip 會直接下載。本包不含任何書籍全文，書稿請到 KMDB 練習資料（Google Drive）下載，各項連結見表 30。

參考來源

1. Karpathy, A. (2026, April 2). LLM Knowledge Bases [Post]. X. https://x.com/karpathy/status/2039805659525644595
2. Karpathy, A. (2026, April 4). llm-wiki [GitHub Gist]. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
3. Hacker News discussion of LLM Wiki. https://news.ycombinator.com/item?id=47640875
4. Lütke, T. qmd: local markdown search. https://github.com/tobi/qmd
5. Anthropic. (2024, September 19). Introducing Contextual Retrieval. https://www.anthropic.com/news/contextual-retrieval
6. Anthropic. (2025, September 29). Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
7. Chroma Research. (2025, July 14). Context Rot. https://www.trychroma.com/research/context-rot
8. Smith, B., & Troynikov, A. (2024, July 3). Evaluating Chunking Strategies for Retrieval. Chroma Research. https://www.trychroma.com/research/evaluating-chunking
9. Han, S. (2025, June 18). Finding the Best Chunking Strategy for Accurate AI Responses. NVIDIA Technical Blog. https://developer.nvidia.com/blog/finding-the-best-chunking-strategy-for-accurate-ai-responses/
10. Qu, R., Tu, R., & Bao, F. (2025). Is Semantic Chunking Worth the Computational Cost? Findings of NAACL 2025, 2155–2177. https://aclanthology.org/2025.findings-naacl.114/
11. Bennani, & Moslonka. (2026). A Systematic Analysis of Chunking Strategies. arXiv:2601.14123. https://arxiv.org/abs/2601.14123
12. ihower.（2024，2025 年更新）. 以繁體中文資料重做 Chroma 切分評估的部落格文章. https://ihower.tw/blog/12373-rag-chunking
13. LangChain. Recursive text splitter. https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter
14. Edge, D., et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130. https://arxiv.org/abs/2404.16130
15. Sarthi, P., et al. (2024). RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval. arXiv:2401.18059. https://arxiv.org/abs/2401.18059
16. Zettelkasten.de. Introduction to the Zettelkasten Method. https://zettelkasten.de/introduction/
17. Milo, N. Maps of Content. Linking Your Thinking. https://www.linkingyourthinking.com/ideaverse/youre-already-doing-it-sort-of
18. Matuschak, A. Evergreen notes. https://notes.andymatuschak.org/Evergreen_notes
19. Wang, L., et al. (2024). Multilingual E5 Text Embeddings. 模型：intfloat/multilingual-e5-small
20. Mintplex Labs. AnythingLLM. https://github.com/Mintplex-Labs/anything-llm
21. Open WebUI. Knowledge. https://docs.openwebui.com/features/workspace/knowledge/
22. InfiniFlow. RAGFlow. https://github.com/infiniflow/ragflow
23. LangGenius. Dify. https://github.com/langgenius/dify
24. Cinnamon. Kotaemon. https://github.com/Cinnamon/kotaemon
25. Google. (2026, July 16). NotebookLM is now Gemini Notebook. https://blog.google/innovation-and-ai/products/gemini-notebook/notebooklm-gemini-notebook/
26. Chroma. Clients. https://docs.trychroma.com/docs/run-chroma/clients；Chroma MCP：https://github.com/chroma-core/chroma-mcp
27. LanceDB. https://docs.lancedb.com/；Qdrant client（本機模式）：https://github.com/qdrant/qdrant-client；pgvector：https://github.com/pgvector/pgvector
28. Streamlit. https://docs.streamlit.io/；Gradio：https://www.gradio.app/
29. Model Context Protocol. What is MCP? https://modelcontextprotocol.io/docs/getting-started/intro
30. Anthropic. Claude Code: Memory（CLAUDE.md 與 AGENTS.md）. https://code.claude.com/docs/en/memory；Permission modes：https://code.claude.com/docs/en/permission-modes；MCP：https://code.claude.com/docs/en/mcp
31. OpenAI. Codex: AGENTS.md. https://learn.chatgpt.com/docs/agent-configuration/agents-md；Approvals and security：https://learn.chatgpt.com/docs/agent-approvals-security；MCP：https://learn.chatgpt.com/docs/extend/mcp
32. Obsidian Help. Vaults, Properties, Aliases, Bases, Graph view, Settings. https://obsidian.md/help/vault；/properties；/aliases；/bases；/plugins/graph；/settings
33. Dataview：https://github.com/blacksmithgu/obsidian-dataview；Smart Connections：https://github.com/brianpetro/obsidian-smart-connections；Copilot for Obsidian：https://github.com/logancyang/obsidian-copilot

示範語料引用之原書：Yin, R. K.《案例研究：設計與方法》第 5 版（簡中譯本）；Gillham, B. (2000). Case Study Research Methods；Timmermans, S., & Tavory, I.《從資料分析到理論突破》（簡中譯本）；Kuhn, T. S.《科學革命的結構》（簡中譯本）；Mahoney, J.《社會科學的邏輯》（簡中譯本）；Woolf, N. H., & Silver, C. Qualitative Analysis Using NVivo: The Five-Level QDA Method；謝立斌《研究生論文寫作與時間管理》。頁碼皆指 PDF 頁碼，正式引用請回原書。