RAG 胜过微调的场景，以及它失效的场景

RAG 在早期部署战中胜出是有道理的：比微调便宜，知识库不用重新训练就能更新，而且你能审计模型看到了什么。对大多数问答和文档对齐任务，它仍然是正确架构。但失效模式是真实的，“加 RAG 就好”已经成了那种没什么帮助的建议——就像十年前”用数据库就好”那样。

RAG 悄悄表现不佳的地方

需要跨多文档综合的任务——任何单个被检索 chunk 都不包含答案——是 RAG 最受伤的地方。检索器返回单独最相关的 chunk，常常错过那个把它们桥接起来的 chunk。需要领域特定风格或术语的任务很少受益于 RAG，因为被检索的文本是内容，不是声音。语料很小——几千篇以下——有时直接塞进上下文反而更好，没有检索的复杂度。

微调赢的场景

如果任务要求模型学会一种新格式、一种新的领域词汇、或一种 prompt 无法建立的行为模式，微调是杠杆。RAG 教不了行为，它只能检索内容。混用——用微调教行为，用检索拿内容——比单用任何一个更常是正确答案。

RAG 不是解决方案。它是适用于一类特定问题的部署模式，把它当作所有 LLM 问题的答案，就是团队最后在调试向量搜索而不是解决实际任务的原因。