第十篇，我們準備好要把東西放到知識庫裡了，今天要講的是 Ingest 採集、攝取

在第二篇我們有講過這個概念：「把原本不在系統內的資訊帶入系統內的過程」，如今回頭看，我覺得寫得不夠簡單。所以在這篇我這樣說：

「把資料丟到知識庫」 = Ingest。夠簡單吧

為什麼要特地弄一個名詞出來耍帥？

不是耍帥，主要是因為知識庫有 AI 進駐，要跟 AI 分工的話就要定義清楚，而且這是資料入庫的第一個動作，我們需要確保資料的正確性與在需要的時候，被搜到的能力。

補充，Ingest 這個名詞是來自 Karpathy 的 LLM Wiki 文件定義，剛好是這次知識庫系列文章所用的教材。

如果你有不同的定義、名詞來表達「把資料丟到知識庫」，例如傳送、閃現還是轉移，隨便你好嗎，只要我們有共識我們正在「入庫」就好，然後因為用英文表達不太親民，我這邊把 Ingest 翻譯成中文：

採集

好，怎麼定義給 AI 看？

秉著「不控制讀者想怎麼做」的出發點，我這邊先給原則、再給 Prompt、最後給成品

讀者可以根據自己的需要決定要「只看原則，其他我自己決定」、「再多看看怎麼向 AI 發起討論好了」、或者「我直接拿寫好的定義來改就好」。

三個都可以，啊如果你說「哼，三個我都不看」那麼

小小注意

三條：

1. Ingest 不是「一件事做完」，是有順序的多種動作與事件組合成「一個動作」。
2. Ingest 的觸發時機要講清楚。
3. Ingest 的定義要服務於「無痛檢索」——意即：入庫後要找的到，而且盡量降低資訊錯誤的可能性。

怎樣算「資訊錯誤」？我這邊只能舉幾個例子像是：跟既有資料衝突、單純跟事實不符等等。實際上導致資訊錯誤的原因有很多，無法完整地定義出來，所以我說「盡量」。

那麼其他條就 BJ4 不解釋直接進入下一part。

Prompt

我想幫我的知識庫定義一套資料入庫規則，我把它叫做 Ingest，想跟你討論：

• 具體的 Ingest 觸發機制
• 如何判定一則內容要收錄到知識庫的哪裡？
• 原始來源要怎麼保存下來——我自己貼的文字、外部檔案、連結，各自要怎麼處理？
• 資料進來前，我需要親自判斷這筆資料在講什麼、值不值得入庫

特別說明一下這行：資料進來前，我需要親自判斷這筆資料在講什麼、值不值得入庫

因為通常有些人會直接全部丟給 AI，直接「一條龍」紀錄到知識庫裡面，這是做法/風格的不同。

我是自己認為，既然知識庫的負責人是使用者，那麼「判斷資料內容」這件事就不該隨便外包，要是後續你搜到該筆資料，發現根本與事實不符呢？

AI 只會給你「不會錯」的整理，不會錯有時並不等於正確。

我的版本

### Ingest（收錄新來源）

1. 觸發：你明確要求收錄，並提供文字、檔案或連結；或 AI 主動發現值得收錄的內容、經你同意後才收錄。一旦觸發就直接執行，不用再次確認「要不要收錄」。
2. 決定歸屬，兩層判準：
   a. 範圍判準優先——先判斷這則內容本質上是什麼，對照 `wiki/index.md` 各主題的範圍宣告，列出合格候選。
   b. 沒有任何候選合格 → 開新主題；有候選合格 → 才輪到經濟判準：沿用現有頁面、加個段落夠不夠，還是划得來開新頁面。
   c. 內容同時沾到多個合格候選時，選一個主要歸屬寫實際內容，其他候選只用交叉引用連過去，不要重複寫兩份。
3. 保存來源：確保原始來源真的落地在 `raw/` 對應路徑——對話文字另存、外部檔案複製進去，已經在 `raw/` 的就不用動。
4. 寫入 wiki：在決定好的位置補充既有頁面或建一頁來源摘要，更新受影響頁面與交叉引用；跟舊內容矛盾時明確標註差異。
5. 維護索引與紀錄：需要時更新 `wiki/index.md`，並在 log 裡追加一筆收錄紀錄。
6. 圖片：來源含圖片時，先讀完文字內容，再視需要查看相關圖片。

不複雜，所以大部分人都不會定義清楚，但給 AI 做的規範最好還是定義清楚，否則公親變事主（押韻）。

閒聊

我看了一下時程，再這樣下去有機率我的鐵人賽會失敗，前面的文章動輒三四千字，如果每篇都「照著計畫走」，我要不是過勞要不就烙跑（押韻），得調整一下。

所以這一篇本來有實作、示範單元的，我挪到下一篇寫，這個減少字數的模式預計跑個三四篇，再看看效果吧。

話說寫草稿的當下（8/23） 高雄停班停課，我不知道這件事還約了健身的教練課，我想說乾每次都雷聲大雨點小，雨下午就停了吧，結果沒有耶，下午雨更大了。

但我也不好意思跟教練說「欸乾雨好大哦，不去了」，要是被當作俗仔怎麼辦？

所以我就去了，回家才發現今天高雄停班停課，雖然很白癡，但我真是個猛男。