AI Context 管理实战：RAG 不是万能的
目录
先说结论
RAG 和 long context 不是替代关系，是互补关系。
RAG 适合：
- 大规模知识库检索（>1M tokens）
- 需要精确检索的场景
- 成本敏感
Long Context 适合：
- 需要跨文档推理
- 复杂多跳查询
- 中等规模（<200k tokens）RAG 的真实能力
什么是 RAG
# RAG = Retrieval Augmented Generation
# 1. 检索相关文档
# 2. 把文档放进 prompt
# 3. LLM 生成答案
retrieved = vectorstore.similarity_search(query, k=5)
prompt = f"Context: {retrieved}\n\nQuestion: {query}"
response = llm.generate(prompt)RAG 的适用场景
# 适合 RAG：
# - 文档库 > 1M tokens
# - 需要精确检索（比如"查找 XX 政策"）
# - 实时更新的知识库
# - 成本敏感（token 按量计费）RAG 的局限
# RAG 的问题：
# 1. 检索质量依赖 embedding 模型
# 2. 多跳查询效果差（需要跨文档推理）
# 3. 检索结果可能不相关
# 例子：
query = "这个函数的作者是谁？它最后一次修改是什么时候？"
# RAG 可能检索不到这种跨维度的查询Long Context 的真实能力
Long Context 适合的场景
# 适合 Long Context：
# - 代码库分析（跨文件理解依赖关系）
# - 合同审查（需要理解多个章节的关联）
# - 复杂文档问答
# 例子：
context = load_entire_codebase() # 50k tokens
query = "这个模块的数据流是怎样的？哪些地方可能有问题？"
# Long Context 能理解跨文件的依赖关系Long Context 的局限
# Long Context 的问题：
# 1. 成本高（所有 token 都进 LLM）
# 2. 中间信息容易被忽略（lost in the middle）
# 3. 超过 200k 后质量下降
# 研究发现：
# LLM 对 context 中间部分的信息注意力最低
# 重要信息放在开头或结尾效果更好什么时候用哪个
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 10万文档检索 | RAG | 太大了，RAG 更高效 |
| 单个复杂代码库分析 | Long Context | 需要跨文件理解 |
| 合同多章节关联分析 | Long Context | 章节之间有依赖 |
| 实时更新的知识库 | RAG | 数据源在变化 |
| 简单 Q&A | RAG | 精确检索更有效 |
实战：RAG + Long Context 结合
# 方案：先用 RAG 检索，再用 Long Context 分析
# Step 1: RAG 粗筛
relevant_docs = vectorstore.similarity_search(query, k=10)
# Step 2: Long Context 精读
context = "\n\n".join(relevant_docs) # 把检索结果拼在一起
prompt = f"Context: {context}\n\nQuestion: {query}"
# 如果 context 超过 200k：
if len(context) > 200_000:
# 分批处理，每批 200k
results = []
for chunk in split(context, 200_000):
results.append(llm.generate(f"Context: {chunk}\n\nQuestion: {query}"))
final_result = merge_results(results)结论
RAG 和 Long Context 各有适用场景：
- RAG：大规模检索、成本敏感、精确匹配
- Long Context：复杂推理、跨文档理解、中等规模
实际系统往往是两者结合：
- RAG 做粗筛
- Long Context 做精读
搞清楚你的场景是"检索"还是"推理"，选对方案。