When might prompt engineering be preferred over task-specific fine-tuning
1️⃣ 考察意图
面试官想看的不是“prompt engineering 省钱，fine-tuning 效果好”这种教科书式二分法。真正考察的是：你能否在真实工程约束下，量化地权衡数据量、任务复杂度、迭代速度和资源成本。刁钻点在于：很多候选人只会背定义，但说不出具体场景下“多少数据算少”“多快迭代算快”“什么任务必须 fine-tune”。答好了能展示你对 LLM 应用落地的深度理解，包括 prompt 的脆弱性、fine-tuning 的过拟合风险，以及如何用实验数据做决策。
2️⃣ 标准答
核心原则：当任务可以通过自然语言指令清晰描述，且数据量 < 1000 条、迭代周期 < 1 周时，prompt engineering 是首选。 下面从三个维度展开：
1. 数据量与标注成本
- prompt engineering 胜出场景：任务只有几十到几百条样本，比如客服意图分类（50 个类别，每类 5 条示例）。用 few-shot prompt（如 5-shot）配合 chain-of-thought，准确率可达 85-90%。如果 fine-tune，需要至少 500-1000 条/类才能避免过拟合，且标注成本高。
- 实际坑：prompt 对示例顺序敏感。我踩过：同一组 few-shot 示例，换顺序后准确率从 88% 掉到 72%。解法：固定随机种子，或做多次采样取平均。
- trade-off：prompt 的“零成本”是假象——调试 prompt 的时间成本可能超过 fine-tune 的训练时间。对于 100 条数据，写 prompt + 调优可能花 2 天，而 LoRA fine-tune 训练只需 30 分钟，但数据准备要 1 天。所以“数据量少”不等于“prompt 总成本低”。
2. 任务复杂度与推理能力
- prompt 适合：任务可分解为简单规则，如“提取邮件中的日期和金额”。用 structured output（如 JSON mode）配合 system prompt 即可，准确率 95%+。
- fine-tune 必须：任务需要领域特定知识或复杂推理，比如医疗诊断（从病历中判断疾病类型）。prompt 会因上下文窗口限制（如 8K tokens）而漏掉关键信息，且模型缺乏领域术语理解。用 LoRA fine-tune 在 1000 条专业病历上，F1 可从 0.6 提升到 0.85。
- trade-off：prompt 的灵活性是双刃剑——切换任务只需改 prompt，但 prompt 本身脆弱。例如，从“情感分类”切到“主题分类”，prompt 重写后可能引入偏见。fine-tune 固化权重，但切换任务要重新训练。
3. 迭代速度与部署约束
- prompt 胜出：快速原型验证阶段。比如产品经理要求 3 天内上线一个“FAQ 问答”功能，用 prompt + retrieval（BM25 检索 top-5 文档）即可，无需训练。迭代时改 prompt 即可，部署只需更新 API 调用。
- fine-tune 必要：生产环境对延迟和成本敏感。prompt 调用大模型（如 GPT-4）每次 0.1 元，而 fine-tune 后的小模型（如 Llama-3-8B）每次 0.001 元。如果日请求 100 万次，prompt 成本是 fine-tune 的 100 倍。
- 实际坑：prompt 的推理延迟不稳定。我遇到过：一个复杂 prompt（含 10 条示例 + 指令）导致首 token 延迟从 200ms 飙升到 2s。解法：用 prompt caching（如 Anthropic 的 prompt caching）或压缩 prompt（移除冗余示例）。
总结决策树
- 数据量 < 500 条 → prompt engineering
- 数据量 500-5000 条 → 先 prompt，若准确率 < 80% 则尝试 LoRA fine-tune
- 数据量 > 5000 条 → fine-tune 优先，prompt 仅用于快速原型
- 任务需要领域知识 → fine-tune
- 迭代周期 < 1 周 → prompt
- 生产环境高并发 → fine-tune 后用小模型
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从数据量、任务复杂度、迭代速度三个层面回答。数据量层面：少于 500 条样本时 prompt 更高效，因为 fine-tune 需要大量标注数据避免过拟合。任务复杂度层面：简单规则任务用 prompt 即可，但领域特定或复杂推理任务必须 fine-tune。迭代速度层面：快速原型用 prompt，生产环境高并发用 fine-tune 后的小模型。总结一句：选择取决于数据量、任务复杂度和资源约束，没有绝对优劣。”
4️⃣ 高频追问 & 应对
追问 1：你说数据量少于 500 条用 prompt，那如果我有 500 条但 prompt 准确率只有 70%，怎么办？
先分析失败原因。如果是 prompt 设计问题（如指令模糊、示例不典型），尝试优化 prompt（加 chain-of-thought、换示例顺序、用角色扮演）。如果仍不行，用 LoRA fine-tune 在 500 条上，通常 1-2 个 epoch 即可，准确率可提升到 85%+。注意：500 条 fine-tune 容易过拟合，要用 dropout（0.1）和 early stopping。如果还不行，考虑数据增强（用 GPT-4 生成 200 条合成数据）或改用更大的模型。
追问 2：生产环境高并发时，为什么不用 prompt 而用 fine-tune？prompt 也可以用小模型啊。
关键在成本。小模型（如 Llama-3-8B）的 prompt 推理成本是 fine-tune 的 3-5 倍，因为 prompt 长度通常比 fine-tune 的输入长（fine-tune 后模型不需要 few-shot 示例）。例如，prompt 平均 500 tokens，fine-tune 后输入平均 100 tokens，成本差 5 倍。而且 fine-tune 后模型可以量化到 INT4，推理速度提升 2-3 倍。所以对于日请求百万级的场景，fine-tune 的 ROI 远高于 prompt。
追问 3：如果任务需要频繁切换（比如每天换一个分类体系），prompt 和 fine-tune 怎么选？
这种情况 prompt 是唯一选择，因为 fine-tune 无法每天重新训练。但要注意 prompt 的稳定性：用 system prompt 定义分类体系，user prompt 只传输入。如果分类体系变化大，考虑用 dynamic few-shot（从向量数据库中检索最相似的示例）。另一个方案：用 adapter 架构（如 LoRA），训练多个 adapter 对应不同任务，推理时动态加载。但 adapter 切换有延迟（约 50ms），需要权衡。
5️⃣ 避坑 · 常见错误答法
- ❌ “prompt engineering 永远比 fine-tuning 便宜，所以优先用 prompt。” → ✅ “prompt 的调试时间成本可能超过 fine-tune 的训练成本，尤其对于复杂任务。实际决策要算总账：数据准备 + 调试时间 + 推理成本。”
- ❌ “fine-tuning 一定比 prompt 效果好。” → ✅ “对于简单任务（如情感分类），精心设计的 few-shot prompt 准确率可达 95%，而 fine-tune 可能因数据偏差反而更差。效果取决于任务和数据质量。”
- ❌ “prompt 不需要数据，所以适合冷启动。” → ✅ “prompt 需要高质量的示例和指令设计，本质上也是一种‘数据工程’。没有领域知识时，prompt 可能产生幻觉，而 fine-tune 至少能学到数据分布。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“检索增强 vs 模型内化知识”角度切入。举例：在客服问答中，用 prompt + BM25 检索比 fine-tune 更灵活，因为知识库更新快。但若问题涉及复杂推理（如多跳问答），fine-tune 后的模型能更好利用内化知识。
- 如果你只做过传统 NLP：用“规则系统 vs 机器学习”类比。prompt 像规则系统（灵活但脆弱），fine-tune 像训练分类器（稳定但成本高）。强调你理解 trade-off 的量化方法，比如用交叉验证评估 prompt 的稳定性。
- 如果你是校招无项目：聚焦论文复现。提到《Prompting vs Fine-tuning: A Comparative Study》中的结论：对于 100 条样本，prompt 准确率 82%，fine-tune 86%，但 fine-tune 需要 2 小时训练。展示你做过类似实验，并理解统计显著性。
- 《Prompting vs Fine-tuning: A Comparative Study on Few-shot Text Classification》
- 《LoRA: Low-Rank Adaptation of Large Language Models》
- 《The Power of Scale for Parameter-Efficient Prompt Tuning》
- 《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》
- 《Anthropic Prompt Caching: Reducing Latency and Cost for Long Prompts》