提示工程 vs 微调 vs RAG

项目进行了三周，我有了一个微调过的模型。数千个训练样本。一张让我皱眉的GPU账单。响应质量是……完全可以通过一个精心设计的系统提示达到的水平。

我花了三周时间微调，而我其实只需要三小时的提示工程。

这是应用AI中最昂贵的错误之一——不是因为微调不好，而是因为它被团队过早、过频繁地采用，而这些团队还没有一个框架来判断每种方法何时适用。从那以后，我咨询过六七个犯了同样错误的团队。

这篇文章是我希望我当初就有的指南。

1、我们实际上在谈论什么

在我们进入决策框架之前，让我们确保我们精确地使用这些术语，因为它们经常被混淆，造成困惑。

提示工程是制作输入的实践——系统提示、指令、示例、上下文——以引导预训练模型朝向你想要的输出。模型的权重不会改变。你调整的是输入什么，而不是模型是什么。

微调是使用你自己的数据集在预训练模型上继续训练的过程，更新模型的权重以更好地适应你的特定任务、领域或风格。你在改变模型是什么。

还有第三种技术经常与两者混淆：检索增强生成（RAG），你在推理时将相关上下文（通常来自向量数据库）动态注入到你的提示中。这值得了解，因为它解决了许多人错误地选择微调来解决的问题——下面会有更多内容。

2、决策框架：从这里开始

在构建任何东西之前，按顺序问这五个问题：

1. 一个精心制作的带示例的提示能解决这个问题吗？
→ 是：始终首先使用提示工程。

2. 问题是模型缺乏它不可能拥有的*知识*吗？
→ 是：使用RAG（动态上下文注入），而不是微调。

3. 问题是规模化下的*风格*、*格式*或*行为*一致性吗？
→ 是：微调是一个强有力的候选方案。

4. 你有50-1000+个高质量的标记示例吗？
→ 否：你还没有准备好微调。先构建数据集。

5. 性能提升是否证明成本合理？
→ 计算一下。微调不是免费的。

大多数跳到微调的团队在没有真正尝试之前就回答了问题1的"否"。他们测试了一两个提示，看到了不完美的结果，就得出结论说模型需要训练。几乎总是，提示需要迭代，而不是模型。

3、何时使用提示工程

提示工程应该是你的默认选择——你的第一个也是通常唯一的工具。它是：

快速 —— 以分钟为单位迭代，而不是小时
便宜 —— 没有训练成本，没有基础设施
可逆 —— 更改你的提示，立即看到新结果
可移植 —— 在模型提供商之间切换而无需返工

它最适合的情况是：

任务在预训练模型的能力范围内（摘要、分类、代码生成、提取）
你需要快速适应变化的需求
你希望模型拥有最新的世界知识（微调模型不会获得知识更新）
你的生产量适中（在中等规模下，API调用具有成本效益）

4、强提示的解剖

弱提示产生不一致的结果。强提示有结构：

# 弱：模糊，没有示例，没有约束
prompt = "分类这条客户消息。"

# 强：明确的角色、任务、格式、约束和示例
system_prompt = """
你是B2B SaaS公司的客户支持路由助手。
你的任务是将收到的支持消息准确地分类到以下之一：
- BILLING：关于发票、订阅、支付方式的问题
- TECHNICAL：Bug、错误、集成问题、性能问题
- FEATURE_REQUEST：新功能请求
- GENERAL：其他一切

规则：
- 只回复类别标签，其他什么都不说
- 如果你不确定在两个类别之间，选择需要更快行动的那个
- 如果两者都适用，"TECHNICAL"优先于"BILLING"（技术问题会阻塞用户）

示例：
消息："我的发票显示上个月重复计费"
类别：BILLING

消息："自从昨天的更新后，API在/users端点返回500错误"
类别：TECHNICAL

消息："如果能导出PDF报告就好了"
类别：FEATURE_REQUEST
"""

user_message = "我们尝试连接Salesforce集成时遇到OAuth错误"
# 预期输出：TECHNICAL

注意这个提示做了什么：

定义了明确的角色
给出了详尽、互斥的类别
明确说明了平局决胜规则
提供了具体示例（few-shot）

仅此一项就能处理绝大多数分类任务，而无需接触模型权重。

5、值得了解的高级提示技术

思维链（CoT）： 对于复杂的推理任务，要求模型在给出答案之前逐步思考。在多步问题上可测量地提高准确性。

prompt = """
分析以下季度收入数据，识别最重要的趋势。
逐步思考：
1. 原始数据显示了什么？
2. 有季节性模式吗？
3. 同比比较如何？
4. 哪个单一趋势最需要领导层关注？
数据：{data}
"""

自一致性： 多次运行相同的提示并聚合结果。对于偶尔出现错误成本高昂的高风险分类很有用。

输出脚手架： 提供模型响应的开头以强制特定格式：

messages = [
    {"role": "user", "content": "总结这次会议记录：{transcript}"},
    {"role": "assistant", "content": "## 会议摘要\n\n**关键决策：**\n"}  # 脚手架输出格式
]

6、何时使用微调

当你真正达到提示工程的天花板时——而不是你想象的——微调才值得它的复杂性。

它最适合的情况是：

规模化下的风格和语气一致性。 如果你的品牌需要非常特定的声音——随意但专业、技术精确但无行话——而且你需要在数百万输出中保持这种风格，微调将这种风格嵌入到模型中，而不是每次都需要提示。

具有自定义逻辑的复杂多步任务。 如果你的任务需要模型遵循一个有20多个分支的决策树，或处理难以在提示中详尽指定的边缘情况，微调模型可以内化这种逻辑。

具有自己词汇表的专业领域。 医学、法律和技术领域经常使用基础模型处理不佳的术语和推理模式。在领域特定示例上进行微调可显著提高质量。

高容量、延迟敏感的生产。 微调后的小模型可以在特定任务上匹配大模型的质量——但推理成本和延迟只有一小部分。如果你每天运行数百万次推理调用，这一点非常重要。

何时不微调：

你的基础模型缺乏回答所需的知识（改用RAG——你无法微调进原始训练数据中没有的知识）
你的高质量示例少于50个（你会过拟合）
你的需求经常变化（微调模型不容易更新）
你还没有用尽提示工程（说真的，先更努力试试）

8、真实世界对比

让我们用一个具体任务来具体说明：从医疗入院表格中提取结构化数据。

表格以不一致的格式输入。你需要提取：患者姓名、主诉、症状、持续时间，以及严重程度（1-10）。

8.1 提示工程方法

import anthropic
import json

client = anthropic.Anthropic()

EXTRACTION_PROMPT = """
你是医疗数据提取助手。从以下患者入院表格中提取结构化信息。
只返回有效的JSON，使用以下确切结构：
{
    "patient_name": "string or null",
    "chief_complaint": "string - one sentence",
    "symptoms": ["list", "of", "symptoms"],
    "duration": "string - e.g., '3 days', '2 weeks', 'unknown'",
    "severity": integer from 1-10 or null
}
如果字段缺失或不清楚，使用null。

示例：
输入："John Smith今天来看病，说他过去一周一直头痛得厉害。他把疼痛评为8/10，还提到有些恶心。"
输出：{"patient_name": "John Smith", "chief_complaint": "Severe headaches for one week", "symptoms": ["headaches", "nausea"], "duration": "1 week", "severity": 8}

输入：{intake_form}
输出："""

def extract_intake_data(form_text: str) -> dict:
    message = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=512,
        messages=[
            {
                "role": "user",
                "content": EXTRACTION_PROMPT.format(intake_form=form_text)
            }
        ]
    )
    
    try:
        raw = message.content[0].text.strip()
        return json.loads(raw)
    except json.JSONDecodeError as e:
        print(f"Parse error: {e}\nRaw output: {raw}")
        return {}

# 测试
result = extract_intake_data(
    "Maria Gonzalez，34岁女性。报告昨天开始出现剧烈胸痛，"
    "评为6/10。还出现呼吸急促和轻微头晕。"
    "无既往心脏病史。"
)
print(json.dumps(result, indent=2))
# 输出：
# {
#     "patient_name": "Maria Gonzalez",
#     "chief_complaint": "Sharp chest pain since yesterday",
#     "symptoms": ["sharp chest pain", "shortness of breath", "mild dizziness"],
#     "duration": "1 day",
#     "severity": 6
# }

这效果很好。对于大多数用例，就在这里停止。

8.2 微调对这个任务有意义的情况

如果你每月处理500,000份入院表格，使用前沿模型的提示成本约为每月3,000-5,000美元。微调后的小模型可能以每月300-500美元的成本处理相同的任务。在这种规模下，微调的投资回报是显而易见的。

或者，如果你的诊所使用高度专业化的术语（复杂的肿瘤治疗记录、罕见疾病分类），在你特定文档上微调的模型将优于即使仔细提示的效果。

8.3 微调：数据现实检查

微调只有你的训练数据好，它才好。这是大多数微调项目失败的地方——不是在训练过程本身，而是在数据质量上。

8.4 最小可行数据集

# 微调数据格式（OpenAI/大多数提供商）
training_examples = [
    {
        "messages": [
            {"role": "system", "content": "你从医疗入院表格中提取结构化数据。"},
            {"role": "user", "content": "患者入院：John Smith，严重头痛8/10，1周。"},
            {"role": "assistant", "content": '{"patient_name": "John Smith", "chief_complaint": "Severe headache", "symptoms": ["headache"], "duration": "1 week", "severity": 8}'}
        ]
    },
    # ... 至少还需要49个示例
]

# 高质量训练数据的规则：
# 1. 明确覆盖你的边缘情况
# 2. 包含优雅处理null的示例
# 3. 确保格式一致性 - 一个坏示例会降低质量
# 4. 大多数任务目标200-500个示例；复杂任务1000+
# 5. 训练前手动验证每个示例

数据质量的80/20法则： 20%的训练示例将代表80%的质量提升。那20%是你最难、最细致入微的边缘情况。把大部分数据整理时间花在那里。

8.5 数据集验证脚本

import json
from pathlib import Path

def validate_fine_tuning_dataset(filepath: str) -> dict:
    """验证JSONL微调数据集的常见问题。"""
    issues = []
    examples = []
    
    with open(filepath) as f:
        for i, line in enumerate(f):
            try:
                example = json.loads(line)
                examples.append(example)
            except json.JSONDecodeError as e:
                issues.append(f"Line {i+1}: Invalid JSON - {e}")
                continue
            
            # 检查结构
            if "messages" not in example:
                issues.append(f"Line {i+1}: Missing 'messages' key")
                continue
            
            messages = example["messages"]
            roles = [m.get("role") for m in messages]
            
            if "assistant" not in roles:
                issues.append(f"Line {i+1}: No assistant message found")
            
            # 检查空内容
            for j, msg in enumerate(messages):
                if not msg.get("content", "").strip():
                    issues.append(f"Line {i+1}, message {j+1}: Empty content")
    
    return {
        "total_examples": len(examples),
        "issues_found": len(issues),
        "issues": issues[:10],  # 显示前10个
        "ready_to_train": len(issues) == 0 and len(examples) >= 50
    }

report = validate_fine_tuning_dataset("training_data.jsonl")
print(json.dumps(report, indent=2))

9、RAG中间地带

许多团队在提示工程和微调之间选择，而正确的答案是RAG。以下是什么时候使用它：

问题	解决方案
模型不知道你的产品文档	RAG —— 在查询时注入相关文档
模型需要访问最近的事件	RAG —— 检索新鲜数据
模型需要引用特定来源	RAG —— 在上下文中包含检索到的来源
模型给出不一致的格式	提示工程
模型对你的体量来说太贵	微调一个更小的模型

10、成本和性能对比

这是真实世界的数学，不是营销：

方法	设置时间	前期成本	推理成本	灵活性	最适合
提示工程	几小时	~$0	$$$（大模型）	非常高	大多数用例
RAG	几天	$（基础设施）	$$	高	知识密集型任务
微调	几周	$$$	$（小模型）	低	高容量、关键风格

突破性洞察：微调通常不是关于质量，而是关于经济性。在特定任务上微调后的GPT-3.5或Claude Haiku模型可以以GPT-4质量的10%推理成本匹配——前提是你有足够的训练数据和范围明确的任务。

11、实用建议

始终从提示工程开始。 构建一个可靠的提示。在50-100个真实示例上测试它。测量质量。只有当你真正遇到天花板时才继续微调。

评估提示质量时，使用评分标准。 不要凭感觉。定义"正确"意味着什么，在保留集上评估，计算准确率或F1分数，并跟踪变化。

如果你决定微调，首先大力投资数据质量。 你的模型只会和你的训练集一样好。为数据整理预算60-70%的项目时间。

模型更新后重新评估提示工程。 GPT-4.5、Claude 4和其他前沿模型比去年好得多。2023年需要微调的任务在2025年可能用提示就能解决。

对于企业用例，考虑两者都用。 对于高容量核心任务使用微调模型，对于边缘情况和新任务使用提示工程的前沿模型。这种混合方法让你在保持灵活性的同时获得成本效益。

12、底线

提示工程和微调不是竞争对手——它们是具有不同工作的工具。错误不是使用其中一个而不是另一个；而是在没有首先理解你实际上试图解决什么问题的情况下就使用任何一个。

如果你还没有投入生产，使用提示工程。如果你每月处理数百万次调用，并且有一个稳定、定义明确的任务，微调的经济性开始变得有吸引力。如果你的问题是模型不知道某些东西，在两者之前先选择RAG。

做对的工程师将更快交付更好的AI产品——他们会通过抵制在穷尽简单性之前就追求复杂性的冲动来做到这一点。

原文链接: Prompt Engineering vs Fine-Tuning: I Wasted 3 Weeks Learning This the Hard Way

汇智网翻译整理，转载请标明出处