RAG 值不值得学习？它有什么局限性？

RAG 被归到“要学的技术”那个货架上：有仓库、有文档、有版本号，会与不会判断起来干脆，还能写进简历。但立正指出，很多人学 RAG 是从 pipeline 开始的——切文档、做 embedding、存向量库、检索——这套流程学完会给人一种“前后差距特别明显”的进步感，甚至可以直接写进简历，然后 checklist 打上勾就不用再学了⁠1。问题在于，这种学法是把它当 Science 学：读文档、跑 demo、记概念，学之前不会、学之后会了，checkpoint 很清晰；可日常工作中用到的技术大多是 Craft，不是靠读懂显性知识就能掌握的⁠2。真正该学的是第二个货架上的东西：上下文管理、任务拆解、人机协同、结果确定性——它们看起来很软，但决定 RAG 在你的任务里到底 work 不 work⁠1。

围绕 RAG 的讨论反复出现过同一个问题：读懂它在做什么，离判断它值不值得用，还差几层工作⁠3。你得先看懂技术，知道它在哪些任务里好用、哪些不行；然后拿回评价标准——对你的任务来说，质量、延迟、一致性、概率校准，究竟什么重要；再往下是找到真正合理的比较对象，如果不用它，完成同一个任务最好的选择是什么；最后才有条件判断这个问题是否值得现在投入⁠4。跳过这几步，就容易陷入叙事陷阱：你以为自己在判断它有多厉害，其实先接受了别人对“厉害”的定义⁠3。所以“RAG 有没有局限”这个问题，答案取决于你的任务和替代方案，不是技术本身能给出的。

如果还在犹豫要不要投入，可以先做一件小事：针对你手上一个真实问题，写下你打算怎么用 RAG 解决、你觉得哪里会出错，然后再去看教程或让 AI 给方案。立正提到，先自己猜再让 AI 动手，错了才有得学；配环境、调端口这类“假困难”可以交给工具，难要留给真正的问题——这件事值不值得做、该怎么拆、做出来的东西好不好⁠5。做完之后撤掉帮助再做一遍，卡住的地方就是还没学会的地方⁠5。这样一轮下来，你判断的就不再是“RAG 这个名词值不值得学”，而是它在你的任务里到底解决了什么、没解决什么。