提示工程 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关于发票、订阅、支付方式的问题 - TECHNICALBug、错误、集成问题、性能问题 - 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( modelclaude-opus-4-5, max_tokens512, messages[ { role: user, content: EXTRACTION_PROMPT.format(intake_formform_text) } ] ) try: raw message.content[0].text.strip() return json.loads(raw) except json.JSONDecodeError as e: print(fParse error: {e}\nRaw output: {raw}) return {} # 测试 result extract_intake_data( Maria Gonzalez34岁女性。报告昨天开始出现剧烈胸痛 评为6/10。还出现呼吸急促和轻微头晕。 无既往心脏病史。 ) print(json.dumps(result, indent2)) # 输出 # { # 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/101周。}, {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(fLine {i1}: Invalid JSON - {e}) continue # 检查结构 if messages not in example: issues.append(fLine {i1}: Missing messages key) continue messages example[messages] roles [m.get(role) for m in messages] if assistant not in roles: issues.append(fLine {i1}: No assistant message found) # 检查空内容 for j, msg in enumerate(messages): if not msg.get(content, ).strip(): issues.append(fLine {i1}, message {j1}: 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, indent2))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产品——他们会通过抵制在穷尽简单性之前就追求复杂性的冲动来做到这一点。原文链接提示工程 vs 微调 vs RAG - 汇智网