RAG 与长上下文怎么选

RAG 和长上下文不是同一层面的选择。长上下文解决“模型一次能读多少”，RAG 解决“从哪里拿到正确材料、怎样控制材料、怎样追溯来源”。

如果你正在做知识库、客服、内部助手或文档问答，可以用下面这套决策方法。

1. 一句话选择

  • 资料少、一次性分析、权限简单：选长上下文。
  • 资料多、经常更新、需要引用、多人权限：选 RAG。
  • 问题复杂且资料多：RAG 先召回，再用长上下文综合。

2. 决策矩阵

维度长上下文RAG
上手速度快，工程少需要切分、索引、检索
更新频率更新后要重新组织上下文文档更新后可重建索引
来源引用可做但不稳定更自然
权限控制难度高可检索前过滤
成本大文档反复发送会贵可控制召回数量
调试难知道模型关注了什么可查看召回片段
适合任务单次阅读、总结、审阅长期知识库、客服、FAQ

3. 什么时候选长上下文

长上下文适合“材料边界明确”的任务。

例子：

  • 分析一份年度报告。
  • 审阅一组产品需求文档。
  • 总结一场会议的转录文本。
  • 对一个小型代码仓库做整体理解。

判断标准：

  1. 文档数量不大。
  2. 不需要频繁更新。
  3. 不涉及复杂权限。
  4. 回答不要求严格来源定位。
  5. 请求量不高，token 成本可接受。

4. 什么时候选 RAG

RAG 适合“长期可维护知识系统”。

例子：

  • 客服 FAQ。
  • 产品帮助中心。
  • 内部制度问答。
  • 销售资料库。
  • 技术文档助手。

RAG 的关键价值：

  • 检索最新文档片段。
  • 给回答附来源。
  • 根据用户权限过滤知识。
  • 记录召回结果，方便排查。
  • 降低每次请求的上下文长度。

5. 成本比较

不要只看模型是否支持长上下文。真正要看每次请求发送多少 token。

成本项长上下文RAG
初始开发低中到高
每次调用可能很高通常可控
维护成本文档少时低需要维护索引
错误排查高中
权限治理高中

如果每天只有几十次内部使用，长上下文可能够用。如果是公开产品，每天上千次问答，RAG 或混合方案更稳。

6. 混合方案

很多项目最后不会二选一，而是这样做：

用户问题
→ 权限过滤
→ RAG 检索 10–30 个候选片段
→ 重排和去重
→ 把关键片段放入较长上下文
→ 模型生成答案和引用
→ 记录召回与用户反馈

这个方案的好处是：RAG 保证材料来源，长上下文负责综合推理。

7. 评估方法

上线前准备 30–50 个真实问题，分成三类：

类型示例看什么
精确事实某功能限制是什么是否找到正确来源
综合判断A 方案和 B 方案怎么选是否引用足够材料
边界问题问无关或无权限内容是否拒绝或说明缺口

记录指标：

  • 召回是否命中正确文档。
  • 回答是否引用来源。
  • 是否编造文档里没有的信息。
  • 是否泄露无权限内容。
  • 平均成本和延迟。

8. 失败案例

长上下文失败：

  • 把整个知识库塞进去，成本高、慢、还难调试。
  • 文档更新后忘记替换上下文。
  • 不同用户看到不该看的资料。

RAG 失败：

  • 文档切分太碎，召回片段没有上下文。
  • 只用向量相似度，关键词命中差。
  • 没有评估集，回答错了也不知道原因。
  • 检索到旧文档，没有版本控制。

9. 最小推荐

如果你是第一次做：

  1. 先用长上下文做原型，验证用户问题。
  2. 收集真实问题和失败案例。
  3. 当文档增长、权限复杂、成本升高时再上 RAG。
  4. 上 RAG 后保留长上下文综合能力。
  5. 每月维护评估集和高频问题。

不适合场景

  • 只为了赶热点写 Demo，不需要复杂 RAG。
  • 高风险合规问答，不应只依赖长上下文。
  • 没有文档治理的人，不要急着做大型知识库。

选型的核心不是技术名词，而是：材料会不会变、谁能看、能不能引用、错了能不能查、成本是否可控。

顶部