007｜长上下文与 RAG 结合：什么时候该检索，什么时候该全文
大模型上下文越来越长，但 RAG 不会消失。关键是理解它们各自适合什么场景，以及如何组合。
核心结论：长上下文（朗·康·泰克斯特）让模型能读更多原文，但 RAG 更省成本、更快、更适合大规模知识库。两者不是替代关系，而是互补关系。
一、长上下文能做什么
- 直接把整本书、整个代码库、整份报告塞进 prompt。
- 减少信息丢失，保留完整细节。
- 适合一次性需要全局理解的任务。
二、长上下文的问题
| 问题 | 说明 |
|---|---|
| 成本高 | 长上下文 token 多，费用贵 |
| 速度慢 | 推理延迟随长度增长 |
| 注意力稀释 | 关键信息可能被淹没 |
| 不适合动态知识 | 实时数据需要外部检索 |
三、RAG 仍然有价值的场景
- 知识库很大，无法全部塞进 prompt。
- 知识需要频繁更新。
- 需要精确引用来源。
- 要控制成本。
四、组合策略
| 场景 | 策略 |
|---|---|
| 问题明确，知识库小 | 全文 + 总结 |
| 问题明确，知识库大 | RAG 检索相关片段 |
| 需要全局理解 | 全文 + 分段检索 |
| 实时数据 | RAG 必须接入外部数据库 |
五、面试高频问答
Q：长上下文会不会替代 RAG？
不会完全替代。长上下文适合小范围、全局理解；RAG 适合大规模、动态、低成本场景。未来更多是'全文理解 + 精准检索'的组合，即 Agentic RAG。
六、一句话总结
长上下文让模型读得更多，RAG 让模型读得更准。聪明的系统会按需选择，而不是二选一。
下一步推荐
- 008｜Agent 项目工程化：代码组织、测试、部署
- 009｜Agent 测试、监控与可观测性