移动应用的微调 vs 提示词工程

提示词工程是每个开发者首先使用的工具。编写一个系统提示词,告诉模型如何行为、输出什么、避免什么。它在原型阶段效果出奇地好。

微调是第二个工具,在提示词达到极限时使用。在你想要的确切行为的样本上训练模型。它需要更多前期工作,但以更低的成本提供更好的结果。

对于移动应用,这个选择的影响超出了准确性。提示词工程需要在每次API调用中发送长系统提示词(成本)。微调将指令嵌入模型权重中(推理时免费)。

提示词工程: 快速路径

工作原理

你编写一个指导模型的系统提示词:

You are a cooking assistant for the RecipeApp. When users ask about
recipes, provide step-by-step instructions. Always include prep time
and cooking time. Format ingredients as a bulleted list. Keep
responses under 200 words. Never suggest recipes that include
allergens without a warning. If the user asks about non-cooking
topics, politely redirect to cooking.

这个提示词随每次API调用一起发送。模型在大多数时候遵循(大部分)这些指令。

优势

• 速度: 几分钟即可编写和测试
• 灵活性: 通过编辑文本改变行为
• 无需训练数据: 零样本即可工作
• 无需基础设施: 只需API调用
• 迭代速度: 几秒钟内尝试新提示词

劣势

• Token成本: 你的800-1,500 token系统提示词在每次请求中都会计费。在10K MAU、每天9万次请求的情况下,每月多出7,200万到1.35亿个额外tokens。
• 不一致性: 模型以概率方式遵循指令。典型遵循率为70-85%。边缘情况会出问题。
• 有限的领域知识: 模型只知道提示词中的内容。你无法将整个产品目录放入系统提示词中。
• 提示词注入漏洞: 用户有时可以覆盖系统提示词的指令。
• 准确率上限: 再多的提示词工程也无法教会通用模型你的特定领域术语、风格或边缘情况。

微调: 精准路径

工作原理

你创建你想要的确切输入-输出行为的样本:

{"messages": [
  {"role": "user", "content": "Quick pasta recipe for one person"},
  {"role": "assistant", "content": "**One-Pot Garlic Pasta**\n\nPrep: 5 min | Cook: 12 min\n\n- 100g spaghetti\n- 2 cloves garlic, minced\n- 2 tbsp olive oil\n- Red pepper flakes\n- Parmesan\n\n1. Boil pasta in salted water\n2. Saute garlic in olive oil (2 min)\n3. Toss drained pasta with garlic oil\n4. Top with pepper flakes and parmesan"}
]}

在500-5,000个这样的样本上训练模型。模型学会你的格式、风格、领域知识和边缘情况处理。

优势

• 准确率: 领域任务上90-96% vs 提示词的70-85%
• 无需系统提示词: 指令在权重中。每次请求零额外token。
• 领域知识: 模型了解你的产品、术语和风格
• 一致性: 回复可靠地遵循训练时的格式
• 端侧部署: 微调模型在本地运行。无API成本、无延迟、无网络依赖。
• 提示词注入抵抗力: 行为在权重中,而非可覆盖的文本指令

劣势

• 前期时间: 训练数据准备需要数小时到数天
• 训练成本: 每次微调运行$5-50(一次性)
• 灵活性较低: 改变行为需要重新训练
• 数据需求: 最少200-500个高质量样本

正面对比

领域任务准确率

微调在领域特定指标上始终优于提示词。差距在格式遵循和领域术语上最大,微调可以锁定你需要的确切模式。

月度成本 (10K MAU, 每日9万次请求)

微调有一次性成本(每次训练运行$5-50)。部署后,每次推理成本为零。月度成本仅为新用户模型下载的CDN带宽。

延迟

各自获胜的场景

提示词工程获胜当:

• 你在原型阶段,还不知道用户是否需要该功能
• 任务是通用的(非领域特定)
• 你没有训练数据
• 行为需要每周变化
• 用户数很少(500 MAU以下)

微调获胜当:

• 你已验证功能并在扩展
• 任务是领域特定的(你的产品、你的术语、你的格式)
• 准确率很重要(分类、提取、合规敏感内容)
• 你有500+个期望行为的样本(或可以创建)
• 成本、延迟、离线支持或隐私很重要

迁移路径

两种方案不是互斥的。它们是顺序的:

1. 从提示词工程开始。 快速构建功能。验证用户兴趣。用云API上线。

2. 收集训练数据。 使用你的提示词的每次API调用都会生成一个输入-输出对。你的提示词工程API日志成为你的微调数据集。

3. 信号明确时微调。 当你知道用户需要该功能、当你的提示词稳定、当成本或延迟重要时,在收集的数据上微调一个小模型。

4. 端侧部署。 导出GGUF,发送给用户。系统提示词消失。准确率提升。成本降为零。

Ertas等平台使微调步骤变得简单: 上传你的训练数据(可以直接来自你的API日志),选择基础模型,使用LoRA训练,导出GGUF。微调基础设施为你处理。

从提示词到微调的流程

你的API日志是宝贵的资源。每条日志包含:

• 用户输入(训练输入)
• 系统提示词(隐式编码在预期输出中)
• 模型输出(训练输出,经过质量筛选)

筛选高质量输出(模型正确遵循指令的情况),格式化为训练样本,你就有了微调数据集。你的提示词工程越好,你的微调数据就越好。

这就是为什么两种方案互补。好的提示词创造好的训练数据。好的训练数据创造不再需要提示词的模型。

Ship AI that runs on your users' devices.

Free plan with 30 credits/mo, no card required. Paid plans from $25/mo USD.

Start freeor view pricing →