百万token上下文窗口也杀不死向量数据库？CPU笑了

金磊 梦晨 发自 凹非寺
量子位 | 公众号 QbitAI

“Claude 3、Gemini 1.5，是要把RAG（检索增强生成）给搞死了吗？”

随着新晋大语言模型们的上下文窗口（Context Window）变得越发得长，业界人士针对“RAG终将消亡”观点的讨论也是愈演愈烈。

之所以如此，是因为它们二者都是为了解决大模型的幻觉问题（即那种一本正经地胡说八道），可以说是属于两种不同顶尖技术流派之间的对峙。

一方面，以Claude 3、Gemini 1.5为代表的流派，陆续支持200K和100万token的上下文窗口，用大力出奇迹的方式让大模型能够精准检索到关键信息来提供准确答案。

另一方面，RAG则是一种外挂知识库，无缝集成外部资源，为大语言模型提供了准确和最新的知识，以此来提高生成内容的质量。

诚然有很多人在体验过超长上下文窗口大模型后，觉得这种方式已经让AI在回答的准确性上做到了突破，无需再用RAG：

而且从Claude、Gemini等玩家在测评榜单的数据来看，在回答准确性上的成绩也是屡创新高。

但事实真是如此吗？不见得。

因为在此期间，与“RAG要消亡了”背道而驰的声音也是越发坚定：

从各种评价和讨论来看，这派的观点可以概括为——你（长上下文窗口）强任你强，但缺点也是蛮明显的。

有网友便列举了长上下文窗口的四大通病（四个V）：

• Velocity（速度）：基于Transformer的大型模型，在检索长上下文时要想达到亚秒级的速度响应仍然具有挑战性。

• Value（价值）：长上下文窗口毕竟属于大力出奇迹，但它高支出的特点对于日常应用来说，在成本上是不切实际的。

• Volume（体量）：即使上下文窗口越发得长，但和全网庞大的非结构化数据相比就是小巫见大巫；尤其是企业级动辄GB、TB这种体量，还涉及众多私有数据的情形。