长上下文模型 vs RAG
如今模型上下文窗口已达百万 token（能塞进一整本书）。一个自然的问题：既然能全文喂给模型，还要 RAG 干嘛？ 答案是——仍要看场景。
1. 长上下文能做什么
直接把全部文档放进上下文，让模型「一口气读完全文」再答：
context = "\n".join(all_docs) # 整库塞进 prompt
answer = llm.chat(f"基于以下资料回答问题：\n{context}\n\n问题：{question}")优点：实现极简，无需切分、建索引、调检索。
2. 但长上下文有三道坎
| 问题 | 说明 |
|---|---|
| 成本 | token 按量计费，每次问答都重发全库，贵且随库增长线性膨胀 |
| 延迟 | 输入越长，首字延迟越高，交互体验差 |
| 注意力稀释 | 研究（如「Lost in the Middle」）表明：关键信息若在长文本中部，模型易忽略，准确率反而下降 |
ℹ️「能装下」不等于「读得准」
窗口再大，模型对超长输入中部内容的利用率会下降。RAG 通过检索把「最相关的小段」前置，反而提升命中率。
3. 二者并非对立
更优解是长上下文 + RAG 协同：
top_k = retrieve(question, k=20) # RAG 先精确定位
context = "\n".join(top_k) # 只把相关片段喂给长上下文模型
answer = llm_long.chat(build_prompt(question, context))RAG 负责「缩小范围、降成本」，长上下文负责「在相关片段内做深层推理」。
4. 决策速查
| 场景 | 建议 |
|---|---|
| 库小（小于几万 token）、偶尔问 | 直接长上下文，免建索引 |
| 库大、高频问答、要溯源 | RAG 为主 |
| 需跨多段深度推理 | RAG 召回 + 长上下文生成 |
⚠️别迷信窗口长度
窗口标称 100 万 token，不等于模型真用好了 100 万。上线前用第 13 章指标实测：长上下文直喂 vs RAG 召回，对比忠实度与相关性。
💡组合性价比最高
对大多数生产系统，RAG 召回 Top-K + 长上下文模型生成，比「全库直喂」更准、更省、更可追溯。
🎯练习
取一份 5 万字文档，分别用「全文直喂」和「RAG 召回前 10 段」两种方式回答同一个细节问题，对比两者答案准确率与耗时。
小结
- 长上下文简化实现，但受成本、延迟、注意力稀释三道坎限制
- 「能装下」不等于「读得准」，长文本中部信息易被忽略
- 协同最优：RAG 精确定位 + 长上下文深度推理
- 先测指标再选型，多数场景 RAG 为主、长上下文为辅
- 下一章进入隐私与合规，让 RAG 过得了企业红线 →