46 lines
1.6 KiB
Markdown
46 lines
1.6 KiB
Markdown
---
|
||
title: "提示词工程 vs 微调"
|
||
created: 2026-06-19
|
||
updated: 2026-06-19
|
||
type: concept
|
||
tags: [prompt-engineering, fine-tuning, llm, cost-optimization, dspy]
|
||
sources:
|
||
- https://towardsdatascience.com/six-choices-every-ai-engineer-has-to-make-and-nobody-teaches/
|
||
---
|
||
|
||
# 提示词工程 vs 微调
|
||
|
||
## 两种投资曲线
|
||
|
||
提示词工程和微调遵循**截然不同的投资曲线**——不是"哪个更好"的问题，而是"哪个在什么条件下更合适"。
|
||
|
||
| | 提示词工程 | 微调 |
|
||
|---|---|---|
|
||
| **速度** | 快（小时到天） | 慢（数周） |
|
||
| **成本** | 低 | 高（GPT-4o 客户支持 ~$1 万 + 6 周） |
|
||
| **灵活性** | 高，易迭代 | 低，需重新训练 |
|
||
| **可靠性** | 脆弱（小输入变化 → 不一致输出） | 规模化可靠一致 |
|
||
| **缩放** | 好（< 10 万查询） | 更好（大批量，任务稳定时） |
|
||
|
||
## 关键发现
|
||
|
||
- DSPy 等提示优化工具在部分基准上**超过微调 6-19 个百分点**，需要的样本数少 35 倍（LLM Stats, 2026）
|
||
- 微调在任务**稳定且定义明确**时，高容量下回报最大
|
||
- 差距在逐年缩小——微调已演变为"提示已达上限后的最后一步"
|
||
|
||
## 实践框架
|
||
|
||
1. **从提示词开始**
|
||
2. **遇到提示无法修复的故障时才升级到微调**
|
||
3. **低于 10 万查询，提示几乎总是正确的选择**
|
||
|
||
## 混合模式
|
||
|
||
生产中越来越普遍：**微调解决领域风格和基调 + RAG 作事实基础**。两种技术解决不同的问题，互补而非互斥。
|
||
|
||
## 参考
|
||
|
||
- [[ai-production-tradeoffs|AI 生产权衡]]
|
||
- [[rag|RAG (检索增强生成)]]
|
||
- [[nobrega-ai-production-tradeoffs-2026|原文文章]]
|