一个下午搭好你笔记的个人 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 升级
如果开始用这个问重要问题,看一下评估