一、RAG 被唱衰了很多次
每隔一段时间就有人说：上下文窗口都上百万了，RAG 没必要了。
这个说法对一半。上下文变长，确实解决了一部分问题，但它解决不了三件事：成本、时效、权限。
二、三件事 RAG 仍然占优
成本。 把十万字塞进上下文，每次对话都付一次钱。检索只把相关片段送进去，便宜一个量级。
时效。 模型不认识今天的数据。检索可以从数据库、文件库里实时取。
权限。 上下文里能放什么，取决于检索层的权限控制。这份能力是硬需求，不能靠模型自律。
三、真正决定效果的不是模型，是检索质量
实际项目里，回答不准的原因九成在检索：
切分太粗，关键信息被切碎；
切分太细，上下文不够推理；
只做向量检索，精确术语匹配不到；
没有重排序，召回一堆相关但不关键的内容。
我的经验是：先把切分和召回做好，再谈模型选型。
四、混合检索是常规做法
向量负责语义，关键词负责精确。两者合并后重排序，效果普遍比单一路线稳。
工程上还得处理缓存、限流、超时。向量库检索看着简单，并发一上来全是细节问题。
这类工程细节，我在 BackendWiki 上看过几篇讲得比较透的：Redis 的五种数据结构与持久化、缓存三大问题（穿透、击穿、雪崩）、MySQL 索引与事务、Nginx 反向代理，还有 RPC 与 gRPC 的内部机制。做检索服务时这些是底盘，不补会反复踩坑。
五、三条实用判断
判断一：你的知识库更新频率多高？
一周一变，RAG 必选；基本不变，微调或者直接塞进提示词都行。
判断二：回答错了代价多大？
只是参考意见，可以宽松；涉及价格、法规、医疗，必须带引用来源，且要能溯源到原文。
判断三：能不能接受延迟？
检索加一次重排序，通常多几百毫秒。对实时对话有影响，对后台任务无感。
六、一个常见误区
很多人把 RAG 当成"把文档全丢进去"。
实际上 RAG 的核心是"只给需要的那一段"。做得好的系统，送进模型的上下文不多，但准。
反过来，为了省事把整本手册塞进去，效果不一定好，成本一定高。
七、结论
RAG 不会消失，它的形态会变：从"检索一段文本"变成"按需组装上下文"。
模型越强，对检索质量的要求反而越高，因为它会把错误的上下文用得很自信。