昨天重新了解了 RAG，也回頭看了 NotebookLM 補錯資料的經驗。今天想接著聊：資料放進知識庫之後，我怎麼知道它處理到哪裡，以及裡面的內容能不能相信？

我一開始想用資料庫，是因為之前做過一個好市多優惠的專案。當時會透過爬蟲以及上網搜尋，把網路賣場的價格、現場價格和優惠時段存起來，再呈現在網站上。

所以開始做知識庫時，我也想沿用類似的方式。只是這次保存的內容，從價格變成了文章、工具介紹和各種知識。

先想以後要怎麼用，再決定存什麼

好市多優惠資料要回答的問題比較明確：網路和現場差多少？優惠到什麼時候？

知識庫的需求就不太一樣。我希望之後看到一筆資料，可以先知道它是什麼、能做什麼，最好還有使用場景，讓我想到可以怎麼利用。想進一步了解時，下面也有詳細說明和原始連結可以看。

這次重新看程式，才把這些需求和資料庫裡的欄位對起來。

「欄位」可以理解成每筆資料固定保存的項目。目前知識庫裡有這幾個：

知識庫使用 SQLite 管理資料，再透過 SQL 讀取或修改。這兩個名稱我也重新分清楚：SQLite 是資料庫引擎，SQL 是操作資料的語言。

對我來說，這裡比較有感的是：欄位怎麼設計，跟我以後想怎麼使用資料有關。

例如只有網址，雖然可以回去看，但還是要一個個點開。只有摘要，閱讀比較快，卻可能少掉細節。所以我希望把來源、詳細內容和摘要分開保存，讓它們各自有用途。

我還需要知道，哪些資料處理過了

除了知識內容，我還有一個需求，就是知道 NotebookLM 有沒有處理過這筆資料。

我當時是手動執行處理，所以需要一個標記，方便確認哪些已經補強、哪些還沒處理。我平常會把它叫作「已處理的標籤」，但重新看程式後，才知道這跟文章的分類標籤用途不同。

像「Python」「PDF」這類標籤，是在說資料跟什麼有關；處理狀態則是在說，這筆資料走到哪個步驟。

目前程式用 notebooklm_enriched_at 記錄補強完成時間。有時間，代表程式已經留下補強完成的紀錄；沒有時間，代表還沒有這個完成標記。不過也可能是補強被否決，不能全部當成還沒開始。

這讓我把兩件事分開看：資料可以已經存進資料庫，但還沒有完成後面的補充整理。

有完成標記，我還是會打開來看

即使 NotebookLM 已經處理過，我還是會打開內容。

一方面，我想確認它有沒有補錯方向；另一方面，我也想順便學習。畢竟我存下來的資料，有些就是因為自己還不熟悉，想之後慢慢了解。

昨天提到的例子就是這樣：原本是 RAG 文章裡的「主要好處」，卻補進了養生資訊。這筆資料即使有完成處理，也不代表內容適合放在那裡。

所以「已處理」對我來說，主要是追蹤進度。內容是否正確，還需要另外確認。

而且目前看到的補強完成時間，也沒有記錄我是不是已經讀過。系統完成工作，和我完成閱讀、核對，是不同的紀錄。

我怎麼確認補充的內容？

我會先回去看原本的連結，再上網找其他資料，比對補充的內容是否符合。

這次整理文章時，也把「符合」拆成了兩個問題：

第一個是，它有沒有在講同一件事？

原本是 RAG 的介紹，補充內容就不能跑去講養生。這種偏題比較容易看出來。

第二個是，它寫的具體說法，有沒有依據？

例如某個工具被介紹成可以辨識掃描版 PDF 裡的文字，就要回到文件確認，它是否真的具備這項能力。即使整篇都在講 PDF，也不代表每個功能描述都正確。

另外，上網看到好幾篇相同說法時，也要留意它們是不是都轉述同一個來源。文章數量多，可以提供查找線索，但還是需要回頭確認依據。

這些檢查不能保證我一定找出所有問題，不過至少讓我比較清楚，自己正在確認什麼。

我現在會分成三件事看

整理到這裡，我發現自己需要區分三個階段：

• 已存入：資料已經被保存。
• AI 已處理：系統完成了一段整理或補強流程。
• 我已核對：我看過內容，也回到來源做過比對。

這三件事不能只靠一個「成功」全部帶過。

我原本想做的，是讓未來的自己更容易找到有用的知識。現在也慢慢發現，除了把資料收進來，還需要知道它從哪裡來、經過什麼處理，以及哪些內容是自己真正看過、理解過的。

對我來說，打開內容確認的那一步，也正是把收藏慢慢變成學習的過程。