大上下文能替代 RAG 吗？让 Agent 直接搜索文件有什么不同？
大上下文扩大一次可读的内容量；RAG 用索引先筛证据；文件搜索让 Agent 根据线索逐步读取。三者可以组合。即使忽略 Token 费用，仍有更新及时性、搜索覆盖、权限、读取次数和错误定位的差别。
| 方式 | 更适合 | 主要限制 |
|---|---|---|
| 直接放全文 | 少量完整文档，需要综合比较 | 容量上限；信息多时可能忽略关键段落 |
| 预建 RAG | 大语料、重复问答、统一过滤和引用 | 解析、分块及索引更新可能丢失或延迟证据 |
| 文件搜索与按需读 | 代码仓库、持续变化文件、探索调用关系 | 依赖搜索词和探索策略，可能漏文件或反复搜索 |
代码检索为何常需要组合
Section titled “代码检索为何常需要组合”“谁调用了这个函数”适合先查符号和引用；“哪段代码实现重试”可能需要语义检索。读到函数后，还应沿调用者、配置和测试确认行为。仅找到相似片段，不足以证明真实执行路径。
用同一任务比较证据覆盖、答案正确率、完成时间和读取次数。论文曾观察到部分模型更容易使用上下文两端的信息；这不等于所有新模型都必然相同，应测试当前模型和位置变化。
资料
核对于 2026-10-14。Lost in the Middle 原论文、上下文工程中的按需读取。场景取舍为本站工程建议。