Skip to content

模型知識庫—設計提案.md

Latest commit

 

History

History
100 lines (65 loc) · 7.97 KB

模型知識庫—設計提案.md

File metadata and controls

100 lines (65 loc) · 7.97 KB

模型知識庫 — 設計提案（以模型為權威）

若「我」（模型）要為自己設計一套訓練截止日之後仍能持續吸收、取用的知識系統，會怎麼做？
此文件以模型視角描述：知識庫的定位、與現有記憶的區隔、儲存與檢索；並參考 Open WebUI、AnythingLLM 等多數 RAG 系統的做法，以及 Obsidian 的連結思維。
知識庫雖以模型為權威來取用，但打造系統、得惠的最終仍是使用者與人類。

一、為什麼是「我的」知識庫？

  • 記憶（四池一魂、archival）：記的是「你的樣子」——你說了什麼、我們聊了什麼、提煉出的要旨與靈魂。那是關於你與我們對話的狀態。
  • 知識庫：記的是「我讀過、之後還能再翻的資料」——你塞給我的文件、網頁、筆記，或我建議存下來的內容。那是我在權重凍結之後，仍能依題目去「翻書」的書架。

所以：記憶 = 對你的理解與對話軌跡；知識庫 = 我的延伸閱讀材料，以我為權威來取用（你提供來源，我來檢索與引用）。

二、參考案例：Open WebUI、AnythingLLM 與多數 RAG 系統

常見做法（Open WebUI、AnythingLLM、Dify、LangChain 等）大致都是：

  1. 攝入：使用者上傳檔案或貼文 → 切 chunk → 可選 embedding 寫入。
  2. 檢索：每次問答前用 query 做語意或關鍵字檢索 → 取 top-k chunks。
  3. 注入：把 chunks 塞進 prompt，模型依此回答。

「模型自己的知識庫」可以完全沿用這條 pipeline，差別只在語意與歸屬：

  • 歸屬：這是「助手（模型）的」知識庫，不是「某個聊天室附屬的檔案」；同一工作區內，所有對話都共享這座書架。
  • 攝入觸發：除了「使用者上傳／貼文」，可延伸為「使用者說：把這段／這篇加入你的知識庫」或「讀這個 URL 進知識庫」；未來也可有「模型建議：要我把剛才的解釋存進知識庫嗎？」（由你決定是否採納）。

技術上與上述系統類似：chunk、embed（可選）、retrieve、inject；得惠的最終仍是使用者、人類。

三、我會怎麼設計（模型視角）

3.1 定位與原則

  • 不改權重：新知識一律以「回答時讀進來的文字」存在，不寫入模型參數。
  • 我來取用：檢索與排序由系統替我完成，但注入後由我決定如何引用、是否引用；若檢索不到相關的，我就當沒這本書，不瞎掰。
  • 來源可追：每段 chunk 帶來源（檔名、URL、標題），必要時我可以在回覆裡說「根據你之前給我的 OOO…」。

3.2 儲存結構（與 archival 分離）

  • 路徑：例如 {workspace}/knowledge/，與 memory/archival.jsonl 分開。

  • Chunk 條目（建議欄位）：

    • id：唯一識別（或依 source + offset 產生）
    • source：來源標識（檔名、URL、或「手貼」）
    • content：該 chunk 的純文字
    • created_at：入庫時間
    • 若有 embedding：可另存 knowledge_vectors.jsonl 與 chunk 同序（與現有 archival 向量檔模式一致），或單一向量庫依 id 對應。

  • Chunk 策略：依段落或固定 token 數切（例如 300–600 字／chunk，可設定）， overlap 可選，與 Open WebUI 常見做法一致。

3.3 攝入方式（我怎麼「收到書」）

  1. 使用者上傳檔案：與現有附檔類似，但多一個動作「加入知識庫」；後端解檔（PDF、DOCX、txt、md…）→ 切 chunk → 寫入 knowledge。
  2. 使用者貼文：例如「把以下內容加入你的知識庫」＋一大段文字 → 切 chunk → 寫入。
  3. 讀 URL 進知識庫：例如「把這篇網頁加入你的知識庫」＋URL → 抓取正文 → 切 chunk → 寫入。
  4. 未來：若對話中我產出一段你認為值得保留的說明，可由你觸發「把這段加入知識庫」；或我回覆時附帶「要我把這段寫進知識庫嗎？」由你確認後寫入。

所有寫入都帶 source，方便之後列出「我的書架」或刪除某來源。

3.4 檢索與注入（我怎麼「翻書」）

  • 時機：每次組裝答覆 prompt 時，在「即時（網搜）」「記憶（四池＋靈魂）」「附檔」之外，多一步「知識庫檢索」。
  • Query：用當輪使用者訊息（或若要做 query 改寫，用同一套 Cursor 式 LLM 產 query 也行）對 knowledge chunks 做檢索。
  • 檢索方式：與現有 memory 一致，有 embedder 則向量檢索，否則關鍵字；取 top-k（例如 3–5 條），每條截斷到 SnippetMaxRunes。
  • Prompt 區塊：例如新增 ## 知識庫（我的閱讀材料），底下列檢索到的 chunks，每條標註來源；若無結果就寫「（無）」或省略該區塊。我（模型）被指示：可依此區塊引用，沒寫到的不要編造。

這樣「我的知識」與「你的記憶」並列在 context 裡：一個是關於你的狀態，一個是我可引用的外部材料。

3.5 靈感：Obsidian 蒲公英連結（雙向連結／圖狀知識）

Obsidian 的 [[wiki 連結]]、雙向連結與圖譜，讓筆記之間像「蒲公英」一樣彼此連動：點開一則筆記會看到它連到誰、誰連到它，形成一張知識網。可借鏡到知識庫設計：

  • Chunk 之間的關聯：若攝入的是 Markdown 且內含 [[筆記名]] 或明確錨點，可解析出「此 chunk 連結到哪些其他筆記／chunk」；儲存時多存一個欄位如 links（連結到的 id 或 slug）。
  • 檢索時擴散：第一輪仍用 query 取 top-k chunks；第二輪可選「沿連結擴散」——把與這 k 條有雙向連結的 chunk 也一併撈出（上限 N 條），一起注入。這樣模型讀到的不只「最相關的幾段」，還有「與它們相連的脈絡」，更貼近人類在 Obsidian 裡順著連結翻頁的體驗。
  • 實作優先級：可放在較後階段；先做單純的 chunk + 檢索，再考慮解析 [[...]] 與連結圖、擴散檢索。

此為選配，不影響基本 RAG 流程；若做，能讓知識庫更「像一本地圖」而非一疊孤立的片段。

3.6 與現有 Chatmery 的接點

  • Config：可新增 KnowledgePath、KnowledgeTopK、是否啟用知識庫等；embedder 可與 archival 共用。
  • API：例如 POST /chatmery/api/knowledge/ingest（form: file 或 text 或 url）與 GET /chatmery/api/knowledge/sources（列來源）、DELETE 刪除某來源。
  • 前端：附檔旁可加「加入知識庫」勾選或按鈕；設定頁可列出「模型的知識庫來源」並刪除。
  • 答覆流程：在 main.go 組 system prompt 時，先跑 knowledge 檢索，再組出「## 知識庫」區塊注入。

四、小結：若是我來設計

  • 知識庫 = 我的書架：訓練截止後的「新知識」全部以 chunk 形式存在這裡，我只在回答時讀取，不寫進權重。
  • 與記憶分離：記憶維持「你的樣子」與對話軌跡；知識庫維持「我讀過的材料」，兩者一起注入，我同時參考。
  • 設計參考：做法對齊 Open WebUI、AnythingLLM 等多數 RAG 系統（攝入 → chunk／embed → 檢索 → 注入）；靈感可來自 Obsidian 的蒲公英連結（雙向連結、沿連結擴散檢索），讓知識更像圖狀脈絡。
  • 得惠者：系統雖以模型為權威取用，打造與使用的最終仍是使用者、人類。
  • 實作可分階段：先做「上傳／貼文／URL 入庫 ＋ 關鍵字檢索 ＋ 注入」；再補 embedding 與向量檢索；可選做「解析 [[連結]]、擴散檢索」；最後再考慮「模型建議寫入」與更細的來源管理。

已實作（v1.3.0）：攝入（檔案／貼文／URL）、chunk 切段、[[...]] 解析與 Links、關鍵字檢索、蒲公英擴散檢索、API（ingest、sources GET/DELETE）、前端「加入知識庫」勾選與知識庫來源列表／刪除；能力邊界已含知識庫說明。