在大模型应用开发中，微调、RAG（检索增强生成）与提示工程是三种主流技术路径。面对具体任务，如何选择？本文从数据量、更新频率和成本三个维度提供决策框架。
一、理解三种技术
- 提示工程：通过设计输入指令（如 few-shot 示例、思维链）引导模型输出，无需修改模型参数。
- RAG：将外部知识库检索与生成结合，模型基于检索到的相关文档作答，知识可动态更新。
- 微调：在预训练模型上使用领域数据继续训练，调整模型参数，使其适应特定任务或风格。
二、三个决策维度
1. 数据量
- 提示工程：几乎不需要标注数据，仅需少量示例（通常几个到几十个）。
- RAG：需要构建知识库文档，但无需标注问答对。文档数量可多可少，从几十篇到百万级均可。
- 微调：通常需要数千到数万条高质量标注样本。数据太少容易过拟合，效果不稳定。
决策建议：若标注数据少于 1000 条，优先考虑提示工程或 RAG；若拥有大量领域标注数据且任务固定，可考虑微调。
2. 更新频率
- 提示工程：更新只需修改提示词，实时生效。
- RAG：更新知识库文档即可，检索端实时反映最新信息。
- 微调：每次更新都需要重新训练和部署，周期长、成本高。
决策建议：若知识频繁变化（如新闻、政策、产品信息），RAG 是更优选择；若知识稳定（如领域术语、固定风格），微调更合适。
3. 成本
- 提示工程：成本最低，主要是推理时的 token 消耗。
- RAG：需要向量数据库、检索服务等基础设施，增加工程复杂度和检索延迟，但训练成本为零。
- 微调：需要 GPU 训练资源、数据标注成本及持续维护，初期投入高。
决策建议：预算有限时，从提示工程开始，逐步引入 RAG；微调适合有充足资源且长期收益明确的场景。
三、组合使用与常见误区
三种技术并非互斥。实际应用中常组合使用：例如用 RAG 提供实时知识，用提示工程控制输出格式，用微调调整模型风格。
常见误区：
- 认为微调能“教会”模型新知识——实际上微调更擅长调整行为模式，而非注入事实性知识。
- 忽视 RAG 的检索质量——检索不准，生成再强也无用。
- 过度依赖提示工程解决复杂推理——对于需要多步推理的任务，可能需要微调或结合工具调用。
四、决策流程图（简化）
- 任务是否需要外部知识？是 → 考虑 RAG；否 → 进入下一步。
- 是否有大量标注数据（>1000 条）且任务固定？是 → 考虑微调；否 → 进入下一步。
- 使用提示工程，并持续优化。
五、总结
选择微调、RAG 还是提示工程，核心是平衡数据、更新与成本。多数场景下，提示工程 + RAG 已能解决大部分问题；微调则适用于对风格、格式或特定行为有严格要求的任务。建议从简单方案起步，根据实际效果和需求迭代升级。