先说结论
当且仅当：知识量超过上下文窗口 + 知识更新频繁 + 检索准确度可以容忍 ~80% 时，RAG 才值得做。
否则有更简单的选择。
三种被误用的场景
1. 文档总量 < 200KB
直接把全部文档塞进上下文。Claude 4.6 支持 1M context，几百 KB 的文档读完毫无压力。RAG 引入的检索召回噪声反而拖累效果。
2. 问题模式高度集中
如果用户 80% 的问题集中在 20% 的内容上，做一个 FAQ 缓存表，命中就直接返回，没命中再走模型。比 RAG 简单 10 倍。
3. 知识需要"组合理解"
RAG 是片段化检索——它能告诉你"X 在 P 页"，但不擅长回答"X、Y、Z 三者综合起来意味着什么"。这种问题应该上全文 + 长上下文。
RAG 的真实成本
不是向量数据库的钱，是：
- chunk 切分策略：切大了召回噪声多，切小了缺失上下文
- embedding 更新：文档一改，嵌入要重算
- 检索质量评测：你怎么知道召回是好的？需要测试集和持续监测
RAG 不是把 PDF 丢进 Pinecone 就完事，它是一个信息检索系统的子集。