“效果不好是不是要微调？”这是最常见的问题之一。实际上，提示词工程（Prompting）、检索增强生成（RAG）和微调（Fine-tuning）解决的是不同问题，成本也差别很大。

【1. 提示词工程：永远先从这里开始】
适合：任务描述不清、输出格式不稳定、需要少量示例引导。
做法：明确角色与任务、给出输入输出格式、加入 few-shot 示例、要求在信息不足时说“不知道”。
优点是成本最低、迭代最快；缺点是对知识缺失无能为力，提示词过长也会增加成本与延迟。

【2. RAG：解决“模型不知道”的问题】
适合：需要引用企业内部文档、经常更新的知识、需要给出处的场景。
关键环节：文档清洗与切分、向量检索 + 关键词检索混合、重排序（rerank）、在提示词中要求“仅依据资料回答”。
优点是知识可更新、可溯源；缺点是系统更复杂，检索质量直接决定上限。

【3. 微调：解决“模型不会这样做”的问题】
适合：需要稳定的特定风格或格式、特定领域的表达习惯、把长提示词“内化”以降低成本、让小模型在窄任务上接近大模型。
常见方式：全参数微调成本高；LoRA/QLoRA 等参数高效微调只训练少量参数，显存需求低很多。
注意：微调并不是注入大量新知识的可靠方式，知识类问题通常优先考虑 RAG。微调还需要高质量标注数据、评测集和持续维护。

【简单决策顺序】
先优化提示词 → 若问题是缺知识，加 RAG → 若问题是格式/风格/行为不稳定或成本过高，再考虑微调 → 三者可以组合使用。

【常见误区】
- 没有评测集就开始微调，无法判断是否真的变好。
- 用微调解决本该由检索解决的时效性问题。
- RAG 效果差时只换模型，而没有检查检索召回率。

讨论：
1. 你们项目中哪一种方案带来的提升最明显？
2. LoRA 微调的数据量，你们的经验是多少条起步比较合适？