"RAG已经过时了。把所有内容都扔进1M token的上下文里就够了。"最近在AI行业中,这样的讨论越来越常见。随着主流生成式AI纷纷支持长文本上下文,我们已经进入了理论上可以把整个企业文档一股脑塞进提示词中进行提问的时代。

那么,RAG(检索增强生成)真的不再需要了吗?本文将正面回应这一讨论,并从技术角度和具体数据出发,给出结论:对于企业知识库用途而言,"按场景搭配使用才是当前的最优解"。

本文要点

长文本上下文革命与"RAG不需要论"出现的背景
"全部投入即可"论在企业知识库面前遇到的5堵墙
长文本上下文真正能发挥威力的领域
混合型作为现实解,以及设计时的判断依据

长文本上下文革命 -- 让AI"读完全部"成为现实

在过去一两年里,大语言模型(LLM)的上下文窗口(即一次交互能处理的信息量)出现了爆发式扩张。

主流生成式AI已支持 100万(1M)~200万(2M)token 级的长文本上下文
换算到中文文本,1M token大约相当于原稿纸3,500张、书籍10~15册的体量
支持多模态读取图片、表格、PDF的模型也越来越多

这是几年前完全无法想象的规模。考虑到GPT-3时代(2020年)的上下文窗口大约只有4,000 token,如今已经发生了接近3个数量级的跃升。

在这种迅猛进化的背景下,AI社区自然而然开始出现这样的声音:"既然能读那么多,直接把企业文档全部塞进提示词不就行了,还特地搞RAG检索干什么?"

关于RAG的基本原理和核心思路,已在什么是RAG一文中详细介绍。本文将在此基础上,探讨"RAG不需要论"究竟能否成立。

"全部投入即可"论的现实 -- 理论与实践的差距

先说结论:对于个人使用或小规模文档集,把所有内容塞进长文本上下文确实是可行的运营方式。但一旦进入企业知识库的使用场景,就会撞到一堵又一堵的墙。下面来看最具代表性的5堵。

壁垒1:成本 -- 每次查询都要发送100MB吗?

长文本上下文最大的难点是成本。因为放入提示词的token原则上每次都要计费。

假设某家企业持有100MB的内部文档(换算成纯文本约50MB = 2,500万字),按token换算大约是1,600万token的规模。目前的1M上下文装不下,但我们假设未来扩展到2M、5M的情形来进行估算。

场景	单次查询的输入token	单次查询的成本感	每月1万次查询的情况
RAG(仅相关分块)	数千~数万	不足1元	几百到几千元
长文本上下文全量投入	100万~1,600万	数十~数百元	数十万~数百万元

如果使用提示词缓存(对相同提示词的重复请求进行折扣的机制),缓存命中时的费用可以压缩到原来的约1/10。但即便如此,每天数百万元规模的成本也难以轻易消除。此外,首次调用生成缓存时、或文档更新后重建缓存时,依然要按全价计费,这一点同样不容忽视。

"只发送相关几页的RAG"和"每次都发送全部的长文本上下文",在成本量级上真的是相差数量级。

壁垒2:容量 -- 1M~2M也装不下中型企业的全部文档

从根本上说,长文本上下文能否装得下全公司的文档,本身就是个问题。

1M token ≒ 书籍10~15册
一家中型企业的内部文档,通常达到 PDF 1,000~~5,000件、数千万~~数亿token 的规模
如果把会议记录、Slack日志、客户邮件也算进来,量级还会再翻一位数

也就是说,目前1M~2M的规模,距离"全部投入"还差得很远。长文本上下文确实是巨大的进步,但作为"能承载整个企业知识的存储",它依然偏小。

壁垒3:权限分离 -- 并不是所有人都能看同样的文档

企业知识库的一个基本前提是,不同用户、不同部门的访问权限是不同的。

只有人事部门才能查看的薪资、绩效资料
特定项目的机密资料
仅限高管的经营资料

在长文本上下文的方案中,理论上需要为每个用户组装不同的文档集合放入提示词。但这就带来了:

缓存按用户分裂,成本效率大幅下降
权限校验逻辑渗透到提示词生成层,设计复杂度上升
"这条信息能不能放进去?"的判断一旦失误,就直接导致信息泄露

等问题。对于以权限和访问控制为前提的企业用途,在检索阶段就能过滤的RAG型方案明显更自然。关于Monoshiri AI采用的文件夹级访问控制机制,安全策略中也有详细说明。

壁垒4:Lost in the Middle -- 越长精度越差的现象

人们往往会想当然地认为"放进长文本上下文,AI就会认真读完",但实际上多项研究已经指出,LLM会重点关注提示词的开头和末尾,而容易漏掉中间部分的信息。这一现象被称为 "Lost in the Middle"。

尤其在 精准抽取单一事实的提问("X的申请截止日期是什么时候?"等)上,劣化最为明显
随着文档数量、文档长度的增加,精度下降会进一步加剧
即便模型宣称支持1M上下文,也有观点认为实际能以高精度处理的大约只有数十万token

RAG 只把关联度较高的几页内容放入提示词,因此在结构上不易受Lost in the Middle的影响。在"从海量文档中抽取某一具体语句"的任务上,RAG反而更胜一筹。

壁垒5:更新 -- 每新增1份文档要做什么?

企业知识几乎每天都在更新。规章修订、新品发布、会议记录追加……我们来对比一下每新增1份文档时,两种方案分别会发生什么。

方案	新增文档时的处理
RAG	仅将新增部分向量化,注册到索引中
长文本上下文全量投入	整体重新生成提示词,缓存也要重建

"是否能只处理差分" 是直接影响运营成本的关键视角。RAG擅长差分更新,而长文本上下文全量投入不擅长差分更新,这是一个明显的本质差异。

长文本上下文真正发挥威力的领域

以上我们讨论了长文本上下文的挑战,但这并不意味着"它没用"。恰恰相反,在RAG不擅长的领域,长文本上下文会展现出压倒性的优势。

1. 小规模、自成闭环的知识

由数件到数十件文档构成的知识库,全部塞进长文本上下文是最快、最强的方案。例如针对 一本产品手册、一份合同、一份会议纪要 的问答,直接贴到提示词里比建立检索索引更快,精度也更稳定。

2. 文档内部的深度推理、横向分析

"对比A章和B章,指出其中的矛盾""对整体进行归纳"这类任务,必须同时看到文档整体,RAG的分块方式反而不利。这是长文本上下文的独家优势。

3. 跨多文档的整合性分析

对10~30份左右的关联文档进行横向对照,"抽取这些文档中共同的模式"等分析类任务,也很适合长文本上下文。

精准检索型任务交给RAG,整体俯瞰型任务交给长文本上下文 -- 这样划分后,两者的分工就清晰起来了。

现实解是混合型 -- 3种方案的搭配使用

基于以上特性,实际业务中主流的做法正在向以下3种方案的组合演进。

1. 经典RAG -- 大规模知识检索问答的基础

传统RAG在 "从海量文档中抽出几页来回答" 这一典型场景中,至今仍是性价比最高的选择。关于语义搜索的机制,已在用AI搜索企业内部文档的方法中进行了讲解。

2. 长文本上下文活用 -- 小规模、深挖型用途

在目标文档已经收敛,且需要文档内部深度推理的场景中,直接使用长文本上下文就是最短路径。

3. 混合型(Agentic RAG / RAG + Long Context / CAG)

近期尤其受到关注的是混合型方案。代表性的发展形态包括:

Agentic RAG:由AI智能体自主判断"先检索 → 不够就继续检索 → 必要时直接去读全文"的模式
RAG + Long Context:先用RAG收敛出相关文档集合,再把这些文档整体用长文本上下文让模型阅读(可缓解分块切片带来的副作用)
Cache-Augmented Generation(CAG):把常用文档预先加载到提示词缓存中,跳过检索步骤同时抑制成本的模式

与其说"选RAG还是长文本上下文",不如把它们理解为 融合两者的统一设计。

设计企业知识库时的5个判断维度

那么,设计自家知识库时到底应该以什么为标准来选型?建议从以下5个维度进行梳理。

1. 文档量

规模	推荐方案
数件~数十件	以长文本上下文为中心
数百件~数千件	以RAG为中心,必要时混合
数万件以上	RAG是必需

2. 是否需要权限分离

如果需要按部门、按职级区分访问权限,在检索阶段就能过滤的RAG型方案几乎是刚需。

3. 更新频率

在文档以日/小时为单位追加、更新的环境中,擅长差分更新的RAG更便于运营。

4. 成本承受度

当查询量很大(例如全公司员工每天都用)时,每次查询都发送大量token的长文本上下文方案 会严重压迫预算,务必慎重估算。

5. 提问类型

以"抽取某一具体事实"的提问为主 → RAG更有利
以"纵览整篇文档"的提问为主 → 长文本上下文更有利
两者并存 → 混合型

Monoshiri AI之所以以RAG为基础,正是因为针对企业知识库这一用途,把上述维度全部考虑进来之后,RAG目前仍是平衡性最好的选择。不过,我们也预计长文本上下文还将继续进化,因此在设计上非常重视"能在合适的场景中把两者灵活结合"的能力。计费方式请参见定价方案,核心功能请参见功能一览。

总结

本文围绕长文本上下文时代的"RAG不需要论"是否成立、以及企业知识库的设计方针,进行了讲解。要点整理如下:

长文本上下文的确具有革命性,但在企业知识库用途上有成本、容量、权限、精度、更新这5堵墙:"全部投入即可"论在个人使用和小规模文档集上成立,但在全企业级别的文档场景中目前尚不成立
RAG与长文本上下文不是对立而是互补:精准检索型场景是RAG的强项,整体俯瞰型场景是长文本上下文的强项
现实解是混合型:Agentic RAG、RAG + Long Context、Cache-Augmented Generation等融合二者的设计正在成为主流
设计时的5个判断维度:文档量、权限分离、更新频率、成本承受度、提问类型。把自身需求按这5个维度梳理一遍,最优解自然会浮出水面

AI技术演进速度极快,几年后当下的常识很可能再次被改写。即便如此,"什么技术最契合自家的使用场景"这一判断视角,无论在哪个时代都同样重要。希望本文能为您的判断提供一份有益的参考。

RAG已经过时了吗?长文本上下文时代的知识库设计