让 AI 大模型基于自己的资料回答问题，有两条路：把资料挂在外部按需检索（RAG），或者把资料整个塞进长上下文，两条路的适用边界常被混淆。
可以把它想成开卷考试：RAG 是允许带一柜子书、随翻随用；长上下文是考前把整本书背进脑子。这个类比的失效之处在于，背下来的内容考试期间不会更新，而长上下文里的资料每次请求都可以换一份，刷新成本低得多。带走一个判断：RAG 管找得准，长上下文管看得全。
结论前置：查资料用 RAG，通读用长上下文
资料量大、问题只涉及其中几处，用 RAG：检索出相关段落作答，省而准；资料不长、问题需要通盘理解，用长上下文：整篇铺开，模型看全貌。一个是精查，一个是通读，先定用途再定路线。资料增长快、问题每天在变的业务，几乎注定要走 RAG；资料一套用半年的业务，长上下文够用。
差异一：资料放的位置不同
RAG 把资料放在模型外部，请求时先检索再拼接，模型只看到被选中的片段；长上下文把资料直接放进输入窗口，模型从头读到尾。前者考检索器的眼光，找漏了就答不全；后者考窗口容量和注意力，太长可能顾此失彼。判断走哪条线，可以先量两件事：资料总量与窗口容量的比值，单个问题涉及的资料跨度。片段怎么选、怎么切，见截断和压缩差在哪？丢信息和浓缩信息。
差异二：更新和成本不同
RAG 的资料更新快：换掉库里的文件，下一次检索就生效；长上下文的资料随请求走，每次都要重新计一遍输入量，量大时消耗可观。资料频繁更新的场景 RAG 占优，一次通读的场景长上下文省事。文心一言、秘塔AI搜索在资料问答上的实现都属于检索增强一类，思路相通。
两条路线对提问方式的要求也不同。RAG 场景下，问题越具体、关键词越准，检索命中越好，含糊的提问容易检回一堆不相关片段；长上下文场景下，模型看得到全文，提问可以更口语化，甚至可以问「这份资料里最反直觉的三点是什么」这类需要通读才能答的问题。记住这一条，很多「同样的资料换个问法答案变差」的现象就能解释：问题多半出在检索没接住你的问法，换种问法常常立竿见影。
两条路线的差别，按四个维度对一遍：
| 对比项 | RAG | 长上下文 |
|---|---|---|
| 资料位置 | 模型外部，检索后拼接，只看选中片段 | 直接放进输入窗口，从头读到尾 |
| 把关的地方 | 检索器的眼光，找漏了就答不全 | 窗口容量与注意力，太长容易顾此失彼 |
| 更新与成本 | 换掉库里的文件，下次检索即生效 | 随请求走，每次重算输入量，量大消耗可观 |
| 对提问的要求 | 问题越具体、关键词越准越好 | 可更口语化，能问需要通读才答得出的问题 |
| 顺手场景 | 资料量大、问题只涉及其中几处 | 资料不长、需要通盘理解 |
混合用法为什么常见
工程上常两条并用：RAG 先筛出候选段落，再用长上下文一次性喂给模型，兼顾省量与全面。筛选和生成是否分开跑，还牵涉调用方式的选择，见异步和同步调用有什么区别？适用场景分开讲；分步调用的额度安排见限流和排队有什么区别？一张表分清；混合方案的调试顺序也有讲究：先验证检索质量——单独看检索回来的段落对不对，再验证生成质量——固定资料只看回答稳不稳，两步分开定位问题快得多，混在一起查只会互相干扰；回答时是否先推理再落笔，见思考模型和直接回答有什么区别？。
路线选择速查：
- 资料多、问题散：RAG 精查
- 资料短、要通读：长上下文
- 两样都占：先检索后通读，混合着来
路线对准资料形态，省力又省量。
聊聊 RAG 和长上下文的常见疑问
- RAG 检索不到就一定答不出吗？：取决于产品设计，有的会如实说明缺资料，有的退回模型自身知识。
- 长上下文越长越好吗？：不是，超过需要只会多花量，还可能稀释模型对关键段的注意力。
- 两者的答案能标注来源吗？：RAG 天然带出处，长上下文的来源靠资料本身的定位信息支撑。
一句话收束：RAG 管找得准，长上下文管看得全，你的资料形态说了算。
