首页 › trending › RAG死没死?海外吵出第三条路

百万token的窗口都开出来了,RAG是不是该进坟墓了? 这个问题过去一段时间在 Hacker News 和 r/LocalLLaMA 上被反复翻出来吵,而且每次都能吵出几百层楼。奇怪的是,这么热闹的一场论战,中文圈几乎只引进了结论——「长上下文是未来」,然后就没有了。真正的信息差在于:海外吵到最后,两派谁都没赢,反而吵出了一条国内教程很少系统讲的「第三条路」。今天这篇,把这场论战的三个阵营、核心证据、和你能直接抄的架构方案一次讲透,顺带说说同期另一场关联热吵——「是不是所有任务都该上最大模型」。


第一场:百万上下文 vs RAG,「RAG已死」论战

争论是怎么烧起来的

导火索是长上下文模型的突飞猛进。据谷歌官方发布资料,Gemini 1.5 Pro 在2024年就把上下文窗口做到了100万token,后来一度开放到200万,官方演示里「大海捞针」(Needle in a Haystack)测试几乎满分。于是海外社区很快出现一种声音:既然能把整本书、整个代码库塞进窗口,还建什么向量库、切什么chunk、维护什么Embedding?RAG那套流水线,是不是典型的「为锤子找钉子」?

HN上这类帖子标题往往很简单粗暴,类似「RAG is dead」,评论区立刻分成三派。这个模式跟当年「微调已死」「提示词已死」一模一样——海外社区的规律是:每当一个新能力上线,就有人宣告整条技术路线死亡,然后被现实拉回来。

三方阵营与各自软肋

阵营 核心主张 常见论据 软肋
直塞派(长上下文) 全文塞进窗口,砍掉RAG整条流水线 捞针测试近满分;架构简单,无向量库运维;信息无损不切块 贵、慢、对「中间段」不敏感;文档常更新就得重塞
RAG派 检索才是企业级正解 成本只有直塞的零头;可挂权限、可增量更新;多租户隔离必须靠检索 管线长、chunk切错全盘皆输;检索质量是玄学
合流派(第三条路) 长上下文当「内存」,RAG当「硬盘」 两边证据都支持混合架构;头部团队实践都往这走 架构复杂度上升,需要评测体系兜底

直塞派有一个常被忽略的硬伤:捞针测试满分≠模型真的读完了全文。斯坦福团队2023年的论文《Lost in the Middle》早就发现,关键信息放在上下文中间位置时,模型召回率明显下降——两头好、中间差。2025年更狠:一个叫 NoLiMa 的基准专门把「关键词重叠」这根拐杖抽掉(针和问题之间不允许字面重复),结果据该基准报告,大多数名义上支持百万token的模型,有效可用长度骤降到32K上下——窗口是窗口,脑子是脑子。同年 Chroma 团队发布的《Context Rot》报告也指向同一件事:输入变长后,哪怕塞进去的是无关填充内容,模型在简单任务上的表现都会滑落。这两份材料是RAG派反击的弹药库,建议自己去搜原文读一遍,比看任何二手总结都有用。

直塞派的钱包论 vs RAG派的账本论

直塞派的反杀主要靠「省事」:不用搭管线,不用调chunk大小,产品经理都能上手。对个人开发者的一次性任务,这确实是实话——300页PDF就问一个问题,谁给你搭RAG谁有病。

但RAG派的账本是这么算的:以主流API定价计,一次塞满几十万token的问答,成本是「只带几KB检索片段问答」的成百上千倍(具体倍数以各家定价页为准,量级不会错)。更别提延迟——直塞百万token的首token延迟,跟检索后只喂2KB压根不是一个量级。企业场景还有第三座大山:权限。财务文档你敢整库塞给每个员工的每次提问吗?检索层做权限过滤是成熟方案,直塞方案里这个问题至今没有好答案。

第三条路:海外头部团队的实际做法

合流派最有代表性的一步棋是 Anthropic 2024年9月发布的 Contextual Retrieval 方案:给每个chunk在入库前生成一段「上下文说明书」,据其官方博客口径,检索失败率直降49%,再加Rerank重排后下降67%。这个数字组合成了后来无数企业RAG改造的基准线。思路说穿了很朴素——chunk不是孤立的碎片,是带着上下文的碎片;而Rerank则是「召回从宽、精排从严」。

把合流派的共识画成一张决策图,大概是这样:

flowchart TD
    A["用户提问"] --> B{"资料能塞进上下文吗"}
    B -->|小且一次性| C["全文直塞长上下文"]
    B -->|大或常更新| D["走RAG检索"]
    C --> E["重点核对中间段细节"]
    D --> F["词法加向量混合召回"]
    F --> G["Rerank重排"]
    G --> H["只喂相关段落"]
    E --> I["生成答案"]
    H --> I
    I --> J{"引用能对上原文吗"}
    J -->|对不上| K["换更大模型重试一次"]
    J -->|对得上| L["返回答案并附引用"]
    K --> L

注意左下那条分支:「换更大模型重试」正是通往第二场论战的桥。


第二场:人人都在劝你用小模型,翻车了算谁的

r/LocalLLaMA 的日常是「8B小模型吊打一切」,企业博客的日常是「我们又省了60%推理成本」——第二场论战就烧在这里:是不是每个任务都该用旗舰模型?

三方阵营

阵营 主张 典型场景 软肋
小模型党 80%任务小模型绰绰有余 分类、抽取、格式转换、简单改写 复杂推理悄悄崩,崩了还不报错
旗舰党 分层路由是伪优化,调试两套模型的行为差异比省的钱贵 高错误代价任务:付钱、发邮件、改生产代码 成本失控,且旗舰也会翻车
分层派 按错误代价分档,用评测数据定档 所有认真落地的团队 前期要建评测,偷懒直接退化成拍脑袋

这场争论里最值钱的视角差来自分层派的一个换算:该用哪个模型,不取决于任务看起来难不难,取决于错一次的代价有多大。 总结邮件错一句,重发就是;给客户发的报价单错一个小数点,那就是事故。前者锁死小模型,后者永远旗舰+人工复核。海外团队的实际操作通常是:低代价任务先试小模型,评测不过关再升档——顺便说一句,头部编程工具也是这么干的,据其官方文档口径,后台辅助任务默认跑Haiku档小模型,主力任务才用大模型。

反对者的炮火也集中在这里:小模型的失败是静默的。大模型写砸了往往看得出来,小模型写砸了经常「看起来像那么回事」。一套prompt在旗舰上跑得好好的,挪到小模型上行为完全不同,等于要维护两套心智模型——这笔隐性成本,省token的钱未必填得回来。中立者的结论通常是:路由本身没问题,问题是用「感觉」路由。没有评测集就谈分层,等于闭眼开枪。

这两场论战其实是同一场的两个切面:长上下文 vs RAG 决定了「喂什么」,大小模型之争决定了「谁来算」。 海外社区真正沉淀下来的,不是谁消灭谁的宣言,而是一套「先评测、再分层、混合架构」的工程纪律。


对中国用户的启示

视角差:中文圈的传播链通常是「海外有人发帖→搬运结论→」,而论战过程里最有价值的证据链(NoLiMa、Context Rot、Lost in the Middle)几乎没人系统翻译过。把这三份原文读完,你对RAG的理解就能超过大多数只看过教程的人。

价格差:这条混合路线在国内落地几乎是免费的——长上下文侧,DeepSeek、Qwen、Kimi 等国产模型的窗口规格以各自官方文档为准,普遍够用;RAG侧,RAGFlow、Dify、LangChain/LlamaIndex 全是开源可自部署;Rerank 有智源开源的 bge-reranker;本地小模型配 Ollama 或 LM Studio,零API费。微软开源的 GraphRAG 则适合「文档之间有关系网」的场景,是合流派的进阶积木。

方法差:别急着选边。海外吵了一个来回的结论是——先建评测,再谈架构。


信息差总结

你可能知道的 别人已经知道的
长上下文窗口越大越好 NoLiMa证明多数模型有效长度远小于名义窗口,32K可能是真实甜点区
RAG要向量检索 词法检索BM25混合召回,在精确匹配场景常强于纯向量
RAG就是把文档切块入库 Anthropic口径:chunk加上下文说明失败率-49%,加Rerank到-67%
用模型选最大的准没错 分层路由按「错误代价」分档,低代价任务小模型锁死
论战要看谁赢了 海外论战的价值在边界条件:吵的不是赢家,是适用范围

行动指南:本周就能做的五步

  1. 建考卷(30分钟):从你自己的文档里出20道题,标注每题答案在原文的位置。这是你的私有评测集,比任何公开榜单都管用。
  2. 测直塞基线:把全文塞给旗舰模型跑一遍考卷,记下分数、token消耗和延迟。这是你的对照组。
  3. 搭最简RAG:从BM25起步(不需要向量库),跑同一份考卷对比。很多团队惊讶地发现词法检索并不输。
  4. 加Rerank:召回50条、重排取前5,再看失败率变化。用你自己的数据验证那49%→67%的口径适不适用于你。
  5. 给任务贴「错误代价」标签:把手头AI任务分成「错了无所谓」和「错一次要命」两档,前者全换小模型跑一周,统计翻车率——这是你自己的路由策略,不用听任何人的宣言。

延伸思考

海外社区这两场论战最值得学的,其实不是任何技术结论,而是讨论的方式:每一方都在拿基准数据和成本账本说话,而不是拿信仰说话。国内AI内容的常见姿势是「XX吊打XX」「XX已死」,而海外的原生讨论是「在我的数据集上,方案A比方案B失败率高37%,代价是……」。前者是站队,后者是工程。下次再看到「XX已死」的爆款帖,别急着转发结论,先去评论区找反对者贴的数据——信息差往往不在帖子正文里,在吵的那几百层楼里。


参考来源

说明:本轮抓取通道受限,未附具体帖子链接。以下均为官方/社区稳定入口,用文中关键词(RAG is dead、NoLiMa、Context Rot、Contextual Retrieval)在站内搜索即可定位原帖与原文。

  1. Anthropic 官方博客 Contextual Retrieval(49%/67%数据出处):https://www.anthropic.com/news/contextual-retrieval
  2. Chroma 研究报告《Context Rot》:https://research.trychroma.com/context-rot
  3. Google Gemini 官方博客(长上下文发布公告入口):https://blog.google/products/gemini/
  4. Hacker News 站内检索(搜「RAG is dead」「long context」):https://hn.algolia.com/
  5. r/LocalLLaMA 社区(小模型路线日常讨论):https://www.reddit.com/r/LocalLLaMA/

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入