← 返回文章列表

上下文窗口 vs RAG vs 微调：如何选择

让 LLM 处理你的数据和任务有三种方式 - 把一切放进上下文窗口、接入 RAG（检索增强生成），或对模型进行微调。每种方式成本、知识更新速度和精度上限都不同。下文说明它们如何工作、有何区别，以及如何为聊天机器人、客服助手或内部 copilot 选择策略，避免不必要支出。

同一问题的三种路径

目标相同：模型需要回答关于你的产品、文档、政策或领域的问题 - 而不仅是预训练知识。选项如下：

方式 核心思路 知识存放位置
上下文窗口 所需文本全部写入 prompt 每次请求
RAG 检索相关片段 + 生成 索引 / 知识库
微调 重训模型权重 模型权重中

实践中往往不是「非此即彼」，而是组合：RAG 负责事实，微调负责风格与格式，长上下文用于单次请求中的少量完整文档。

上下文窗口：全部写在 prompt 里

上下文窗口是模型在一次请求中「看到」的文本量（以 token 计）：system prompt、对话历史、附件与指令。

工作原理

在 prompt 中放入：

  • 系统指令（「以 X 公司法务身份回答」）；
  • 相关文档全文或大段内容；
  • few-shot 示例（「这是优质回答样例」）。

现代模型（GPT-5.6、Claude Fable 5、Gemini 3.5 Flash）支持 100-200 万 token 上下文 - 相当于数百页。许多场景无需额外基础设施即可满足。

优点

  • 基础设施最少 - 无需向量索引与 embedding 更新流水线。
  • 即时更新 - 修改 prompt 文本，知识立即生效。
  • 透明 - 你确切知道本次请求模型「看到了什么」。
  • 无需训练的 few-shot - prompt 中的示例定义回答格式。

缺点

  • 成本随长度增长 - 厂商 long-context 定价常为基价的 1.5-2 倍。
  • 容量上限 - 即使 200 万 token 也装不下整个企业知识库。
  • 「大海捞针」问题 - 极长上下文中间部分的信息模型利用较差（lost-in-the-middle）。
  • 延迟 - input token 越多，首 token 越慢。

何时选上下文

  • 体量小且稳定：5-50 份文档、单一产品、单一 FAQ。
  • 原型或 MVP - 一天内验证假设，无需 RAG 栈。
  • 需要单次请求全文的任务：对比两份合同、整 PR 的 code review。
  • 需要对 prompt 内容完全可控（审计、合规）。

RAG：检索 + 生成

RAG（Retrieval-Augmented Generation）- 回答前系统在你的库中检索相关片段（向量检索、BM25、混合），插入 prompt，模型基于检索结果生成回答。

工作原理

典型流水线：

  1. 入库 - 文档切分为 chunk（300-1000 token），生成 embedding。
  2. 索引 - 向量库（Pinecone、Qdrant、pgvector、Chroma）+ 可选关键词索引。
  3. 查询 - 用户问题 -> embedding -> top-k chunks。
  4. 生成 - chunks + 问题 -> LLM -> 回答（最好带来源引用）。

知识更新：对变更文档重新索引 - 无需重训模型。

优点

  • 可扩展 - 索引与分块得当可覆盖数百万页。
  • 时效性 - 新文档分钟级入索引，而非数周。
  • 减少幻觉 - 模型基于给定片段；引用提升可信度。
  • 节省 input - prompt 只放相关片段，而非整库。

缺点

  • 复杂 - 分块、embedding、rerank、评估、漂移监控。
  • 检索质量 = 回答质量 - 检索差则模型再好也答不好。
  • 延迟 - 检索 + 生成两步，外加 rerank。
  • 重复与矛盾 - 索引中多版本文档会干扰系统。

何时选 RAG

  • 体量大或频繁变更：文档、wiki、工单、Confluence、PDF 归档。
  • 回答需要来源链接（客服、法务、医疗等需免责）。
  • 用户与请求量大 - 拉 5 个 chunk 比塞 500 页进上下文更省。
  • 数据不能写入模型权重（保密、租户隔离）。

微调：知识在权重里

微调 - 在你的数据上继续训练基座模型：instruction/response 对、对话、领域文本。权重调整使模型更熟悉风格、术语与典型任务，无需长 prompt。

形式：

  • 全量微调 - 所有参数（贵，很少需要）。
  • LoRA / QLoRA - 冻结基座上的适配器（定制模型主流）。
  • DPO / RLHF - 对齐偏好（语气、安全、格式）。

工作原理

  1. 构建数据集：问答、客服对话、代码示例、JSON 回答。
  2. 在 GPU 上训练适配器或完整模型（数小时到数天）。
  3. 部署微调 endpoint 或 merged 权重。
  4. 推理时 - 短 system prompt，模型已「掌握」模式。

微调不能替代最新事实：价格、API 版本、产品动态若无 RAG 或新鲜上下文，无法可靠「记住」。

优点

  • 风格与格式 - 统一语气、JSON schema、回答模板。
  • 更少 prompt token - 无需长指令与大量 few-shot。
  • 单次请求延迟与成本 - 同任务 prompt 更短。
  • 专业术语 - 医疗、法律、内部行话。

缺点

  • 贵且慢 - 数据、GPU、迭代、评估；需 ML 能力。
  • 易过时 - 新产品 = 新训练周期或与 RAG 混合。
  • 过拟合风险 - 模型「背」训练集，泛化差。
  • 罕见事实较弱 - 找「policy v3 第 4.2 段」不如 RAG。

何时选微调

  • 任务稳定、格式高度重复：分类、抽取、模板化摘要。
  • 需要短 prompt、百万级请求低延迟。
  • 大量高质量标注对话（数千+ 样本）。
  • 本地 / air-gapped - 单模型推理，无需每 chunk 调外部 API。

关键维度对比

维度 上下文 RAG 微调
知识体量 受窗口限制 几乎无上限 受训练集限制
时效性 即时（新 prompt） 快（reindex） 慢（retrain）
启动成本 低 中 高
单次请求成本 随上下文长度增 检索 + 短上下文 prompt 低
幻觉 中等风险 检索好则较低 中等，「自信」错误
来源引用 手动写入 prompt 自然 难
基础设施 模型 API 向量库、流水线 GPU、MLOps
合规 / 审计 完全控制 prompt 检索日志 权重黑盒

实用决策矩阵

先用上下文，若：

  • 少量文档能放进 10-20 万 token；
  • 一个 sprint 内要 POC；
  • 每次请求独特且需「整文件」（diff、合同）。

再加 RAG，若：

  • 库体变大或每周更新；
  • 用户问数千页中的具体事实；
  • 需要引用与更低幻觉率。

再加微调，若：

  • 95% 请求回答格式严格一致；
  • RAG 可用但 prompt 被指令与示例撑爆；
  • 有数据集与 eval 迭代预算。

2026 典型生产栈：

微调模型（风格 + 路由）
    + RAG（知识库事实）
    + 适度上下文（system prompt、最近 N 轮、必要时 1-2 份完整文档）

常见错误

  • 「全塞进 100 万上下文」 - 贵、慢；同等预算下检索质量往往更好。
  • FAQ 用微调代替 RAG - 模型「记住」过时价格；RAG 或上下文更简单。
  • RAG 不做 eval - 无 recall@k、faithfulness、人工评审等指标会静默退化。
  • chunk 过小 - 段落语义丢失；过大 - prompt 噪声多。
  • 忽略 rerank - 纯向量 top-5 常不如 BM25 + rerank 混合。

总结

上下文窗口 - 小体量快速启动、完全可控。RAG - 可扩展知识库、新鲜事实与引用的标准方案。微调 - 投资稳定行为与格式，而非事实百科。

多数企业助手以 RAG + 短 system prompt 为优；当质量或单次成本的可量化收益足以覆盖训练投入时再上微调。长上下文用于「单次读完整文档」等定点场景，而非替代全组织检索。

常见问题

能否用超长上下文替代 RAG？

理论上 - 小库可以。实践中 - 很少划算：成本与延迟随 prompt 长度线性增，模型对长上下文中间信息利用更差。RAG 只拉相关内容，可扩展到大归档。例外 - 「读整文件」：code review、对比两版合同、分析 200 页 PDF。

企业聊天机器人必须微调吗？

启动阶段不一定。多数内部 copilot 与客服 bot 用 RAG + 好 system prompt 即可。微调适合：已有数千条参考对话、统一格式（JSON、工单、CRM 字段）、或单次 token 成本极敏感。先用 RAG 测 baseline - 无指标的微调常不划算。

RAG 与微调哪个更便宜？

RAG 前期更便宜：向量库、embedding API、无需 GPU 集群。微调启动更贵（数据、训练、部署），但在高流量下若去掉每次 prompt 中的长指令与 few-shot，可能降低单次成本。比较 6-12 个月 TCO：RAG infra + embedding 刷新 vs 重训与微调推理成本。

各方式知识更新频率？

上下文 - 每次请求（当前 prompt）或部署新模板版本时。RAG - 文档变更时：增量 reindex 数分钟到数小时；全量 rebuild 按 schedule 或换 embedding 模型时。微调 - 行为或领域变化时：发布间隔数周到数月；事实（价格、版本）仍靠 RAG 或 tool calls。

三种方式能组合吗？

可以，且优质生产系统常如此。 微调模型定风格与路由（「是否需要查库」）。RAG 提供最新片段。上下文放系统规则、对话历史，有时一份完整文档用于「通读」任务。关键是角色清晰 - 事实来自 RAG、行为来自微调、约束与 few-shot 来自 prompt - 避免各层重复同一文本。

联系方式