一個下午搭好你筆記的個人 RAG

大部分筆記系統越大越難用。你在 Notion 或 Obsidian 或 Apple Notes 寫了 2000 條筆記,然後找東西變成考古。個人 RAG 解決這個 — 用自然語言問,從你的筆記裡撈答案,附上原文引用。

這是小專案,不是企業系統。目標是明天早上能用,不是 production 等級工具。跳過大 RAG tutorial 教的一半東西。

你會做出什麼

一個 script 吃你的筆記(markdown 檔、Notion / Obsidian / Apple Notes 匯出)
embedding 階段把每個 chunk 向量化
vector store(SQLite + sqlite-vec,最簡單能 work 的選項)
query CLI:ask "我什麼時候寫過跟那個包商的會議?" → 回答帶來源
選配:上層加個小 web UI

完整 stack:Python 或 TypeScript、約 150 行程式碼、本地跑免費,只有 embedding API 成本(2000 條筆記大概 $0.10)。

第一步:把筆記弄到同一個資料夾

最簡單格式是 markdown。主要 app 的匯出工作流:

Notion — 匯出 Markdown & CSV,解壓
Obsidian — 本來就是 markdown
Apple Notes — 用 Bear 或 Apple 自己匯出(有限;Bear 的匯出比較好)
Google Docs — 檔案 → 下載 → Markdown
純文字日記 — 已經完成

全部丟到 ~/notes/(或哪都行)。一個檔案一條筆記。用檔案路徑當之後的 unique ID。

不要預處理。不要去重。不要試著「只抽出有用的筆記」。讓檢索在 query 時過濾。

第二步:切塊跟 embed

用 recursive chunker,每 chunk 約 500 token、重疊 50 token。較小 chunk(200-300 token)對個人筆記實際上比 tutorial 建議的大 chunk 更好用,因為筆記常常包含自包含的想法。

embedding 模型:OpenAI text-embedding-3-small 是最快路徑。2000 條平均長度筆記成本約 $0.05-0.20。或者本地跑 BGE M3 用 sentence-transformers 零 API 花費。

每個 embedding 用 sqlite-vec 存進 SQLite。schema 大概:

CREATE TABLE chunks (
  id INTEGER PRIMARY KEY,
  file_path TEXT,
  chunk_text TEXT,
  chunk_index INTEGER
);
CREATE VIRTUAL TABLE chunk_vectors USING vec0(
  embedding FLOAT[1536]
);

跑一次 ingest。新加實質數量筆記時再跑(或設 cron / git hook)。

第三步:query

query 流程:

用戶用自然語言問
用同一個模型 embed 問題
用 cosine similarity 找最近 top-10 chunk
選配用小 cross-encoder rerank(Cohere Rerank 或 BGE reranker)
把 top-5 chunk 加問題給 LLM
回答案加引用(檔案路徑)

LLM 用 Claude 4.5 Haiku 或 GPT-5 mini 都好;每 query 成本是分錢的零頭。

系統 prompt:「你是助手,只根據 context 裡用戶提供的筆記回答問題。一定引用每個來源的檔案路徑。如果筆記不含答案,清楚說出來。不要編造資訊。」

第四步:小 CLI

# 偽碼
def ask(question):
    q_vec = embed(question)
    chunks = sqlite_vec_query(q_vec, top_k=10)
    reranked = rerank(question, chunks)[:5]
    answer = claude.complete(
        system=SYSTEM_PROMPT,
        user=f"問題:{question}\n\n筆記:\n{format_chunks(reranked)}"
    )
    print(answer)

整個產品就這樣。當 CLI 用一週。如果你發現自己每天都伸手用,再煩 UI 的事。

不要做什麼

個人 scale 不要超出 SQLite 用其他 vector DB。SQLite + sqlite-vec 處理 10 萬 chunk、query 時間 < 100ms。你不需要 Qdrant 或 Pinecone。
不要 fine-tune 任何東西。預設 embedding 對個人筆記夠好。
不要做複雜評估框架。用了就知道好不好。
不要部署到 server。本地跑。你的筆記是私的。
V1 不要加聊天歷史。one-shot Q&A 比你想像有用。
不要靠 agent。直接 retrieve → generate 流程比 agentic loop 適合搜筆記。

之後真的用的話再加

Hybrid search — 透過 SQLite FTS5 加全文搜尋跟向量搜尋並列。Hybrid 檢索實質改善 recall,特別是具體名稱跟日期。
日期 / metadata 過濾 — 「2025 年 11 月我寫過什麼關於 X 的?」需要從檔名或筆記標頭抽日期。
跨 app 來源 — 餵進 Slack 訊息、email、行事曆事件。報酬遞減;筆記通常是 80% 價值。
Web UI — 你真的每天用,小 web app 比 CLI 舒服。但 CLI 起步夠了。

什麼時候不適合做個人 RAG

總共 200 條筆記以下,直接用檔名搜跟 grep。RAG 加複雜度只在實質規模才划算。

筆記是短片段(每條 < 50 字),embedding 檢索沒比關鍵字搜尋多多少。直接用 ripgrep。

筆記是高度結構化的(書摘資料庫,全部同格式),用正規 SQL 過濾。自然語言層沒加任何東西。

你不信任 LLM 看你的私筆記,不要建這個。筆記會送到你用的模型 API,即使有隱私保證,還是資料離開你的機器。在意的話本地跑 BGE M3 + Llama;否則重新考慮。

這改變什麼

我開始用個人 RAG 時讓我意外的是會問的問題類型。不是「幫我找那條筆記」 — 那是搜尋。真實問題:「過去的我對要不要創業是怎麼想的?」「我分手期間日記裡反覆出現的 pattern 是什麼?」「過去三年我對 X 的看法怎麼演變?」

這些問題以前你問不了,因為答案分散在 50 條你絕不會按順序重讀的筆記裡。個人 RAG 讓它們變可解。

下一步

看一下檢索的 chunk size — 500 token 是預設,你的筆記可能要不同
特別看 sqlite-vec — 最簡單 production-ready 的內嵌 vector store
基本版能 work 後試 hybrid search 升級
如果開始用這個問重要問題,看一下評估