即使2025年了，RAG也不会被淘汰

RAG（检索增强生成）自从第一个大上下文窗口的LLM（大语言模型）发布以来，就逐渐式微。

一些值得注意的“RAG死亡”时刻包括：

• 2023年5月：Anthropic 的 Claude，具有 100k token 的上下文窗口
• 2024年2月：Google 的 Gemini 1.5，具有 1M token 的上下文窗口
• 2025年3月：Model Context Protocol 让你可以直接与数据进行对话

现实是这样的：

即使拥有令人印象深刻的 2M token 上下文窗口，目前的长上下文 LLM 仍然只能处理简单数据集。

例如，一个 1M token的上下文窗口大致相当于 1500 页文档。

对于演示来说很不错，但对于生产级应用来说仍然不足。

但假设我们拥有一个上下文窗口，支持无限的tokens：

• 可扩展性和成本：处理数百万 token 的速度很慢，并且在计算和财务上都非常昂贵。即使计算成本有所下降，延迟仍然是应用中的大问题。

• 性能退化：LLM 仍然面临“丢失在中间”的问题。这是指它们无法有效利用长文本中间部分的信息。通过消除无关文档，避免“找针”情景，你能获得更好的结果。

• 数据隐私：为基础模型提供所有数据可能会引发严重的数据隐私问题。特别是在高度监管的行业，如医疗保健或金融服务，你需要实施基于角色的数据访问控制。

结论：你需要长上下文 LLM 和 RAG。

但由于“RAG”这个术语似乎如此具有争议，我们可以这样说： 我们不必称之为 RAG。 我们可以称其为简单的检索，或者是上下文策划。

无论你决定称之为何，能够控制输入上下文窗口的数据质量，将决定生成输出的质量。

毕竟，garbage in, garbage out（垃圾进，垃圾出）。