笔记软件里躺着几百篇笔记，想找点什么全靠缘分——这是我搭个人知识库前的状态。把笔记接上大模型之后，"我去年是不是研究过这个话题"变成了可以直接问的问题。这篇手记记录整个搭建思路和踩过的坑。
RAG 是什么，又不是什么
RAG（检索增强生成）的流程一句话能说完：提问时先从你的资料里搜出相关片段，连同问题一起交给模型回答。
用户提问 → 检索相关片段 → 片段 + 问题拼成提示词 → 模型生成回答
它不训练模型，不微调权重，只是"开卷考试"。这意味着资料更新即知识更新，没有重训成本——这是它适合个人知识库的根本原因。
四个环节的关键决策
1. 切分（Chunking）。把文档切成小块存入向量库。这里是我踩坑最多的地方：
- 按固定字数切，会把一个完整论点拦腰斩断
- 按 Markdown 标题层级切，保留语义完整性，效果好得多
- 每块保留来源信息（文件名、标题路径），回答时才能给出处
2. 向量化（Embedding）。中文资料建议选对中文优化过的 embedding 模型，通用英文模型处理中文语义时打折明显。
3. 检索。纯向量检索对"这个词明明在文档里却搜不到"的情况无能为力，因为向量理解语义但不认字面。务实做法是向量 + 关键词混合检索，两路结果合并后再交给模型。
4. 生成。提示词里明确写："只根据提供的资料回答，资料里没有就说没有。"否则模型会用它的通用知识"脑补"，你的知识库就失去了可信度。
三套方案对比
| 方案 | 上手难度 | 灵活度 | 适合谁 |
|---|---|---|---|
| 现成工具（各类笔记软件的 AI 功能） | 低 | 低 | 不想折腾，资料都在一个 App 里 |
| 开源框架自建（LangChain/LlamaIndex + 向量库） | 中 | 高 | 想要控制权，能接受写代码 |
| 完全手写（embedding API + sqlite-vec） | 高 | 最高 | 想搞懂每个环节的人 |
我的建议路径：先用现成工具验证"对话式知识库"对你有没有用，真的高频使用后再自建。很多人搭完复杂系统才发现自己一周只问两次，那就没必要。
最大的坑：垃圾进，垃圾出
RAG 系统的上限不在技术，在你的笔记质量。如果笔记本身是大段未消化的收藏剪贴，检索出来的就是噪音。搭知识库的过程会逼你整理笔记——这其实是它最大的隐性收益。
写在最后
个人知识库的价值随时间复利：资料越积越多，检索越来越准，而你需要维护的只是"持续写笔记"这一个习惯。工具会过时，习惯不会。