# 长上下文与 RAG：放得下资料，不等于用得对资料

比较长上下文与检索增强在资料规模、更新、来源和任务完整性上的适用条件。

要点：长上下文适合需要同时理解一组资料关系的任务，检索增强适合从较大且持续变化的资料中选择相关依据。两者可以组合。选择时应验证信息是否被正确使用，而不只确认输入没有超过长度限制。

![展开的长幅技术图纸与单独选出的页面（AI概念配图）](/images/guides/covers/long-context-vs-rag-v2.png)

## 容量是条件，理解效果仍需验证

模型能够接收一份长文档，不意味着它会同样准确地处理每个位置、每个限制和每组关系。资料中的冲突、重复与不相关内容，都可能影响回答。

测试时可以把关键条件放在不同位置，检查是否遗漏；也可以加入相似但不适用的资料，观察模型能否保持对象与版本的区分。输入成功只是开始。

## 检索减少输入，也可能遗漏必要信息

RAG 通过选择相关片段减少每次处理范围，但检索阶段可能漏掉分散在多份资料中的条件。需要整体比较的任务，不能只依赖少量相似片段。

可以根据问题先确定资料范围，再选择完整文档、片段或二者组合。对于跨资料推理，保留目录、对象关系与引用线索，有助于后续判断是否还缺少依据。

| 任务条件 | 优先关注 |

| --- | --- |

| 固定资料整体分析 | 完整结构与跨段关系 |

| 大量资料按需查询 | 检索覆盖与过滤条件 |

| 资料频繁变化 | 来源更新与有效版本 |

| 需要精确引用 | 结论与原文位置对应 |

## 从每次任务的完整成本比较

长上下文可能增加输入费用与等待，RAG 则需要解析、索引和检索维护。应把质量、时延、调用与维护一起比较，避免只计算其中一项。

真正的问题不是哪种技术会取代另一种，而是哪种资料组织方式能让当前任务取得足够依据。把容量、选择与验证分别考虑，企业才更容易做出稳定的工程判断。

## 让同一问题接受两种资料组织方式

选一个需要跨段条件的询盘问题，分别提供整份资料与检索片段，核对遗漏、干扰、来源与总成本。既看能否放入，也看能否正确使用；结论只适用于这组样例与当前配置。

## 参考来源

- [Anthropic｜Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)：组织指令、资料和工作状态；文章发表于 2025-09-29

- [Anthropic｜Contextual Retrieval](https://www.anthropic.com/engineering/contextual-retrieval)：检索上下文与重排序方法；不引用实验数字作为企业效果承诺

## 资料进入模型之前的选择

- 整体关系：是否需要完整资料

- 相关依据：检索是否覆盖必要条件

- 实际使用：验证遗漏、引用与成本

![资料进入模型之前的选择](/images/guides/diagrams/long-context-vs-rag.svg)

## 继续阅读

- [上下文工程是什么？让 AI 拿到当前任务真正需要的信息](/guides/context-engineering)

- [知识库搜不准：关键词、向量检索和重排怎么配合？](/guides/rag-retrieval)

- [AI 应用成本怎么算？从单次调用看到每项合格任务](/guides/ai-cost-budget)

围绕当前问题查看任务、资料与人工确认示例，再用企业样例验证。

下一步：[按业务环节查看沙盘](/library)

原文：/guides/long-context-vs-rag

内容版本：guide:long-context-vs-rag:v1

<!-- version:guide:long-context-vs-rag:v1 -->

[结合企业情况咨询](/intake?source=%2Fguides%2Flong-context-vs-rag&articleId=guide%3Along-context-vs-rag&versionId=guide%3Along-context-vs-rag%3Av1)