RAG — 个人知识库场景下被绕开的方案

5 篇提到,且多数作为「对照组」出现——个人规模的知识库不需要它。

主张

RAG 是为「语料超出上下文窗口」设计的,个人知识库通常不在此列。

对个人 vault(几百到几千篇):

• 语料能塞进上下文,或者用 grep + 排序就能精准定位
• RAG 引入的成本(向量库、embedding 更新、chunk 调优)大于收益
• 而且 chunk 是给机器看的,wiki 是给人看的 —— 后者随时能读、能改、能分享

karpathy-llm-wiki 的替代方案:摄入时编译成结构化 wiki,查询时 lookup。selfwiki 的全局搜索 skill 用的就是 rg + 加权排序,零基础设施。

什么时候真需要 RAG:企业级、跨百万文档、需要语义模糊匹配。

为什么重要

• 对判断:别被「必须上 RAG」绑架 —— 先问语料规模,再选方案

Evidence(5 篇来源)

• rednote_20260507_终于整理好了这本书的中文版_智能体设计模式中文版拿走不谢_真的很清晰了
• douyin_20260419_出手就爆火_Karpathy的个人第二大脑方案_karpathy_obsidian_第二大脑
• douyin_20260531_AI产品经理实战之AI客服2026选RAG还是Agent_我做过3个AI客服项目_1个月烧2_8万_1
• douyin_20260531_AI_产品经理实战之AI客服的Eval体系怎么搭_我接触过_10_个_AI_客服团队_7_个连测试集都
• douyin_20260530_LLM_Wiki_和_GBrain_真正的差别_不是谁检索更强_n而是它们在回答两个完全不同的问题_n

---

基于 312 篇干净转写的 compile 结果重建(2026-08-12)。status: budding —— 人工校准后升 evergreen。