LLM Wiki 與卡片盒筆記的差異

前言

過去幾個月，由於開發上有跨服務的需求，開始有了想把公司 RD team 的知識庫建起來的想法。上週開始動工後，同事推薦我紅了一陣子的 Karpathy 的 LLM Wiki 作為知識庫語意分析的架構，我才第一次真的認真看完整頁的內容。

可能我這陣子剛好在上 Sönke Ahrens 的《卡片盒筆記思考術｜知識個體再進化》，閱讀 LLM Wiki 的當下覺得跟卡片盒筆記的概念很相似，但似乎又不太一樣，而一時間又說不出個所以然。

跟 AI 討論並釐清兩者的差異後，當下的違和感就消失了。

首先，LLM Wiki 想要解決的是「知識維護與重新發現的成本問題」。

傳統的 RAG 系統在每次使用者問問題時，都需要從頭開始尋找片段並拼湊答案，知識並沒有「累積」的過程。

LLM Wiki 想讓知識查詢過一次後，就能消化昇華成知識，並保持在最新狀態。它的本質是一個「客觀事實的收納庫」。所以它很適合一般組織層級的知識庫，像是我們團隊想做的 RD team 知識庫、公司的 KMS…等。

同時也因為這種特性，所以某些強調知識點之間關聯性的使用場景，套用這種架構的 Agent 可能就沒辦法產出讓人意料之外的回答。

卡片盒筆記思考術，本身是一種思考方法。

我第一次在網路上看到卡片盒叫做「卡片盒筆記法」，但從課程標題就可以看出些端倪，卡片盒的本質並不是筆記方法，而是一種強調思考脈絡的思考方法，並且想解決「如何把看似無關的知識點產生新的化學反應」的問題。

所以如果真的能夠透過卡片盒的架構（靈感、文獻、永久、專案）去創建知識庫，理想上能夠將各個文件的觀點提煉出洞察（文獻筆記昇華成永久筆記的過程），並且在新的洞察產生時，觀察與既有的洞察之間的關聯性，再延伸出新的洞察。

想像起來覺得畫面很美，但也預期得到實作上會有多困難：

但有沒有一種折衷方案，能夠把卡片盒強調的知識點之間的關聯性，在 LLM Wiki 的 ingest 中實作出來？那或許會是意想不到的效果。