Local AI · DGX Spark
讀書複習知識庫
問一本書，答案附上出處。
173 本書的書摘＋全文語意搜尋，本地 embedding × 本地 LLM。
實際介面・Playwright 實機截圖
為什麼要自己蓋一個
書讀完就忘是常態，重讀又太花時間。市面上的筆記軟體能存書摘，但沒辦法「問」，想確認某個概念是哪本書提到的，還是得靠記憶或手動翻找。
Obsidian 裡已經累積了上百本書的書摘，加上買下的電子書全文，兩邊同步到 DGX Spark 切塊、向量化，就成了一個可以直接問答的個人知識庫。
最難的是誠實：書庫沒收錄的書，LLM 不准憑印象瞎編答案。
原理：一個問題的旅程
從書摘同步到一次有出處的回答，中間發生六件事。
書摘與全文同步
Obsidian 裡的書摘筆記，加上買下的電子書全文，同步到 DGX Spark 本地。
chunk 切塊
Markdown 依標題結構切開，過長的段落再進一步細切，維持每個 chunk 的語意完整。
本地 embedding 向量化
qwen3-embedding:0.6b 把每個 chunk 轉成 1024 維向量，並用內容雜湊做增量快取，只重算真的有變動的檔案。
全文一次性建置
173 本書的全文切成 30,224 個 chunk，第一次全量向量化跑完約 39 分鐘，之後靠增量快取只補差異。
提問時語意檢索
問題向量化後，檢索結果從書摘與全文各半混組。純混排的話全文會淹沒書摘，各半才兼顧結構與例證。
本地 LLM 作答
依檢索到的段落生成繁中回答，強制引用《書名》；出題、洞察、翻譯等純 LLM 功能改走 LiteLLM gateway，所有呼叫共用同一佇列，避免互搶資源逾時。
原理深掘：檢索與知識圖譜
分兩階段：離線把書庫建成向量索引；查詢時即時檢索、混組，交給本地 LLM 生成有出處的回答。
建立索引（離線・一次性）
書庫來源
Obsidian 書摘 ＋ Readmoo 解密全文
切塊 Chunk
書摘按標題、全文按章節切成段落
向量嵌入
qwen3-embedding・Ollama 地端
1024 維向量
存 sqlite + npy
查詢（即時）
問題向量化
用同一嵌入模型轉成向量
語意檢索
書摘＋全文各半混排
取最相關 top-k 段落
LLM 作答
qwythos:9b・Spark Gateway
帶檢索段落生成
強制引用《書名》
附出處回答
繁體中文＋標明來源段落
自動複習
隨機抽書庫段落 → 9B 出 3 題 → 自動作答，像 podcast 一樣帶你複習。
知識圖譜
每本書的向量＝其所有段落嵌入的均值；兩書相似度高就連一條邊，呈現書與書的語意關聯。
為何全地端
讀書筆記是私人資料，嵌入／檢索／生成全在自有 GB10 上完成，不經任何雲端 API。
171
本書摘收錄
30,224
全文 chunks（173 本書）
~39min
全文向量化建置一次
1024
維 embedding 向量
關鍵設計決策
書摘＋全文各半混組檢索
書摘給結構、全文給原文例證。純混排會被份量大得多的全文淹沒書摘，所以固定各半，兩邊都要有。
檢索誠實度優先
書庫沒收錄的書，就明說「未收錄」，不讓 LLM 憑印象瞎編答案——寧可答不出來，也不能編。
所有 LLM 呼叫排同一佇列
問答、出題、洞察、翻譯共用一條佇列，不讓多個請求同時搶本地資源導致逾時。
英文對照背景預翻
常用內容先在背景翻好，使用者點下按鈕的當下不用等，體驗上感覺是「秒開」。
技術架構
Frontend
書名 combobox 即時篩選
自動複習出題
知識圖譜（vanilla canvas 力導向）
Embedding
qwen3-embedding:0.6b
1024 維向量
內容雜湊增量快取
Retrieval
書摘＋全文各半混組
語意檢索
強制引用《書名》
LLM
本地 LLM 負責問答
LiteLLM gateway 出題/洞察/翻譯
單一佇列不並發
線上工具已上鎖（Basic Auth）・本頁分享架構與設計