Fine-tuning（微调）

更新时间：2026-08-12

导读

Fine-tuning（微调） 在你提供的高质量示范上继续训练基础模型，使输出在固定格式、语气、分类边界或领域术语上更稳定。OpenAI 托管流程：上传 JSONL → 创建 fine-tuning job → 获得 ft:... 模型 ID。可微调基础模型列表、数据格式、训练与推理单价以 Fine-tuning 文档 与 定价页 为准——产品线持续调整，示例 model 名需对照文档替换。

先问：你真的需要微调吗？

需要最新外部知识？ ──是──→ 优先 RAG（Embeddings + Responses）
       │
       否
       ↓
Prompt + JSON Schema 已稳定？ ──是──→ 不必微调
       │
       否
       ↓
有大量标注、分布稳定、prompt 已榨干？ ──是──→ 考虑 Fine-tuning

路径	更适合
Prompt + 结构化输出	格式可控、样例可放进 context
RAG	知识频繁更新、需引用来源
工具 / Responses API	查 DB、调 HTTP、执行代码
Fine-tuning	海量稳定样本、风格 / 分类 / JSON 合规率不达标
Agents SDK	多步编排、handoff，非权重训练

微调不会让模型自动掌握新事实；事实错误仍靠 RAG 或工具。

训练数据：JSONL 规范

监督微调通常用 JSONL，每行一条。Chat 类模型多为 messages 数组：

{"messages": [
  {"role": "system", "content": "你是工单分类器，只输出一行 JSON，无 markdown。"},
  {"role": "user", "content": "快递三天没到，要投诉"},
  {"role": "assistant", "content": "{\"intent\":\"logistics\",\"priority\":\"high\"}"}
]}

数据质量清单

• 复杂任务常需 500+ 高质量样本；先用 50 条 smoke train 验证格式
• assistant 即标准答案，格式一致、无多余寒暄
• 覆盖拒答、歧义、边界 case
• 90/10 训练 / 验证拆分，避免同一用户句式泄漏
• 去除 PII，遵守版权与 API 数据政策
• 不含未文档化字段或错误 role 顺序（常见失败原因）

训练 Job 工作流

步骤	操作	注意
1. 上传	POST /v1/files（purpose: fine-tune）	大小与行数限制见文档
2. 创建	POST /v1/fine_tuning/jobs	base_model 必须在可微调列表
3. 监控	轮询 status	failed 时下载 error file
4. 调用	model="ft:..."	与基础模型调用方式相同

from openai import OpenAI

client = OpenAI()
job = client.fine_tuning.jobs.create(
    training_file="file-abc123",
    model="gpt-4o-mini-2024-07-18",  # 以文档可微调列表为准
    validation_file="file-def456",
)
print(job.id, job.status)

超参（epochs、learning_rate_multiplier 等）以文档推荐为起点，在小验证集上网格搜索。

评估：超越 training loss

维度	做法
对照基线	held-out 集对比「最佳 prompt + 基础模型」
格式合法率	JSON parse、schema 校验通过率
业务指标	F1、准确率、人工满意度
安全回归	harmful 请求拒答能力不能变差
线上 A/B	5% canary，对比延迟、成本、错误率

loss 下降 ≠ 业务变好；以 held-out 业务指标 为准。

上线、版本与成本

• 版本快照：保留 ft:... ID、训练集 hash、超参与评估报告
• 并存策略：新 ft canary 放量，指标下滑即切回基础模型
• 成本：训练费（token × epochs）+ 推理费（通常高于同档基础模型）；用 定价页 估算 ROI
• 重训触发：业务规则变更、新意图占比超阈值、评估连续下滑
• 安全：微调不能替代 moderation；敏感输出仍要审核

与其他能力组合

用户输入 → RAG 检索 context → ft 模型输出 JSON → 服务端 schema 校验 → 落库
多步流程 → Agents SDK 编排 → 仅在「分类 / 格式化」节点调用 ft 模型

常见问题

只有 100 条数据够吗？

简单二分类可能够，但易过拟合。必须留验证集；若不如 prompt 基线，应停止扩大训练。

微调模型怎么调用？

Chat / Responses 的 model 填 ft:... 完整 ID；SDK 用法与基础模型一致。

能否微调 embedding 模型？

以官方当前产品为准；多数 RAG 场景优先调 chunking、混合检索与 rerank。

Job 失败如何排查？

下载 error file；常见为 JSONL 格式错误、单条超长、非法 role、空 assistant。

训练数据会被 OpenAI 用于训练吗？

查阅最新 API data usage 与企业协议；Enterprise 政策可能不同。

官方资源

• Fine-tuning 指南
• Fine-tuning API Reference
• OpenAI Platform
• API 定价

下一步阅读

• Embeddings（嵌入）
• Prompt Engineering 指南
• Responses API 中文指南
• 文本生成（Text Generation）

行动路径

今天：收集 5 条「prompt 优化仍失败」的样例，区分知识缺口 vs 格式 / 风格问题。明天：若属后者，手写 20 行 JSONL 提交 smoke job。本周：在 held-out 50 条上对比基础模型 vs ft 的格式合法率，再决定是否扩大数据与上线。