RAG 真的已死?为什么大上下文窗口还不够(至少目前如此)

大模型向量数据库云通信

picture.image

OpenAI 最近发布的 GPT-4.1 震动了 AI 社区:惊人的 100 万 token 上下文窗口、精准度大幅提升,而 Gemini 2.5 在研究模式下甚至宣称支持高达 1000 万 token。作为一家 RAG 即服务创业公司的创始人,我的收件箱立刻被各种宣称 RAG 已死的消息塞满,建议我们在为时已晚之前赶紧转型。

picture.image

但 RAG 真的已经死亡了吗?以下是为什么我们仍然坚定看好 RAG,尽管新型大上下文模型令人印象深刻。

无限上下文的幻觉

GPT-4.1、GPT-4.1 mini 和 GPT-4.1 nano 最多可处理 100 万个上下文 token,而之前的 GPT-4o 模型最多可处理 12.8 万个。100 万个 token 相当于 8 个完整的 React 代码库,因此长上下文非常适合处理大型代码库或大量长文档。

GPT-4.1 能够可靠地处理 100 万 token 上下文长度的信息,并在注意相关文本和忽略长短上下文干扰项方面比 GPT-4o 更加可靠。长上下文理解是法律、编程、客户支持以及许多其他领域应用的关键能力。

picture.image

大上下文模型看起来像是灵丹妙药。它们的宣传效果很诱人:

  • 毫不费力地处理海量数据
  • 简化的 API —— 不再需要复杂的索引和分块
  • 零遗漏结果(所有内容都在上下文中!)

但任何在实际场景中使用过超大上下文的人都知道,现实并非如此美好。

成本和速度:现实检验

考虑这个情况:一个典型的 RAG 查询大约是 1000 个 token,成本约 0.002 美元。将此扩展到完整的 100 万 token 上下文会使成本增加 1000 倍,达到每次查询约 2 美元。不仅仅是成本,速度也会受到严重影响。OpenAI 自己的演示显示,一个 45.6 万 token 的请求需要痛苦的 76 秒 —— 想象一下用户每次互动都要等待那么长时间。在规模化应用中,这些延迟是不可接受的。

代理工作流程会成倍增加痛苦

现代 AI 工作流程越来越多地利用代理方法 —— 多个链式 LLM 调用以达到最终结果。每一步都会增加成本和延迟。突然间,那个每次查询 2 美元的场景膨胀成了在财务和运营上对严肃应用来说不可行的方案。

引用:信任很重要

目前的大上下文模型无法有效处理引用。与 RAG 能够轻松引用源文本块不同,大上下文方法失去了关键的透明度。对于任何需要可验证性的应用 —— 法律、医疗、技术领域 —— RAG 仍然是不可替代的。

picture.image

上下文仍有限制

当然,100 万 token 相当于约 20 本书,看起来很惊人。然而,这对于许多现实世界的企业来说还远远不够。我们与管理着数十亿 —— 是的,数十亿 —— token 的公司合作。即使是 1000 万 token 的上下文也远远不够。对于如此海量的数据,实用且可扩展的 token 经济学仍未解决。

结论

虽然未来可能会带来支持仅使用上下文窗口模型的突破,但现在需要实用的解决方案。目前,RAG 仍然是有意义、可扩展的 AI 应用的唯一可行选择。RAG 不仅没有消亡 —— 它正在茁壮成长。

所以,RAG 还没有死,它才刚刚开始。

后续有很多值得我们探究的技术方向,比如Deep Search,Deep Research以及Agentic RAG等

picture.image

添加微信,备注” LLM “进入大模型技术交流群

picture.image

picture.image

如果你觉得这篇文章对你有帮助,别忘了点个赞、送个喜欢

/ 作者:致Great

/ 作者:欢迎转载,标注来源即可

0
0
0
0
关于作者
关于作者

文章

0

获赞

0

收藏

0

相关资源
字节跳动 XR 技术的探索与实践
火山引擎开发者社区技术大讲堂第二期邀请到了火山引擎 XR 技术负责人和火山引擎创作 CV 技术负责人,为大家分享字节跳动积累的前沿视觉技术及内外部的应用实践,揭秘现代炫酷的视觉效果背后的技术实现。
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论