RAG、微调与长上下文：知识接入方案选型
让大模型掌握新知识，常见有四种手段。它们解决的问题不同，经常被混为一谈：
| 方案 | 注入的是 | 改变的是 | 时效性 |
|---|---|---|---|
| 提示工程 | 上下文信息 | 不改模型 | 每次请求 |
| 长上下文 | 上下文信息 | 不改模型 | 每次请求 |
| RAG | 上下文信息（可检索） | 不改模型 | 知识库随改随生效 |
| 微调 | 参数化的知识/风格 | 模型权重 | 需重新训练 |
一个关键的认知：RAG 和微调不在同一个竞争维度上。RAG 解决"模型知道去哪里找"，微调解决"模型如何表现"。
逐项对比
RAG 的边界
适合：事实频繁更新、需要溯源、知识量大到无法放进上下文、需要权限隔离的场景。
局限：引入检索链路（延迟、成本、出错面）；模型对上下文的忠实性仍受提示词和模型能力影响；注入"技能"而非"知识"的效果差。
微调的边界
适合：固定的输出风格/格式、领域术语理解、压缩常见模式以降低推理成本、小样本行为矫正。
局限：不适合注入事实性知识——参数化知识难以更新、无法溯源、训练成本高，且容易过拟合或引入幻觉。期望"微调让模型背下知识库"通常是错误方向。
长上下文的边界
长上下文模型让"把全部文档塞进去"变得可行，但要警惕：
- 成本线性增长：每次请求都为全量 token 付费，RAG 只为命中的片段付费。
- 注意力稀释：上下文越长，中间内容的利用率越低，长上下文不等于长记忆。
- 权限与更新：无法按用户隔离知识，也无法只更新增量。
经验：文档规模小（几十页内）且变化少的长上下文直接塞是合理方案；规模大、更新频繁、多用户多权限的系统，RAG 在成本与工程可控性上仍占优。两者也可组合：RAG 先召回，长上下文负责吸收召回结果。
决策路径
知识是否有频繁更新或需要溯源？
├── 否 → 是否只是风格/格式/领域语感问题？
│ ├── 是 → 微调
│ └── 否 → 提示工程
└── 是 → 知识总量能否放进上下文窗口（且成本可接受）？
├── 是 → 长上下文直接注入
└── 否 → RAG
└── 同时存在行为/风格问题 → RAG + 微调组合
组合使用
典型的高配方案是分层叠加：
微调（底层） ：领域语言风格、输出格式、工具调用习惯
+
RAG（中层） ：事实知识、实时数据、私有文档
+
提示工程（上层）：单次任务的临时指令与示例
组合的次序也有讲究：先建设 RAG 通路并在其上收集真实问答数据，这些数据（含召回上下文）再成为微调的训练素材，比先微调后补检索的路径更稳。