4.6 微调流程详解：数据准备、训练监控与模型评估
一、微调流程概览（与书 4.2.2 对应）
《大模型应用开发极简入门》第4章 4.2.2 微调流程 明确为：数据准备（格式/质量）、API 调用、训练监控、模型评估。本节按该流程展开，便于在「对格式与领域有极致要求」时落地微调。
微调（Fine-tuning）用业务数据更新模型参数，适配特定领域或格式。流程：数据准备 → 格式转换 → API 提交 → 训练监控 → 模型评估。
二、数据准备（书 4.2.2 数据准备）
2.1 格式要求
OpenAI 微调需 JSONL 格式，每行一个 JSON 对象，且为 Chat 风格的多轮消息：
{"messages": [{"role": "system", "content": "..."}, {"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}
可无 system，但至少包含 user 与 assistant。多轮对话可在一行内包含多组 user/assistant。
2.2 数据质量（书 4.2.2 质量）
- 数量：至少数十条，通常数百至数千条；越多且越多样，效果越稳，但成本上升。
- 一致性：格式统一、无缺段、无乱码；assistant 内容需与任务一致（如都输出 JSON、都遵循同一风格）。
- 多样性：覆盖目标场景的各种表述与边界情况，避免过拟合到少数句式。
2.3 数据清洗建议
- 去除重复或高度相似的样本。
- 检查长度：单条不宜过长，避免超出模型上下文。
- 敏感信息脱敏后再用于微调。
三、格式转换与文件上传
3.1 从 CSV/Excel 到 JSONL
若原始数据为表格（如「输入」「输出」两列），可写脚本转为 JSONL：
import json
rows = [{"input": "用户问题1", "output": "期望回复1"}, ...]
with open("train.jsonl", "w", encoding="utf-8") as f:
for r in rows:
obj = {
"messages": [
{"role": "user", "content": r["input"]},
{"role": "assistant", "content": r["output"]}
]
}
f.write(json.dumps(obj, ensure_ascii=False) + "\n")
3.2 上传与校验
通过 OpenAI API 上传文件（File API），得到 file_id。使用「校验」接口可检查格式是否符合微调要求，再提交训练任务。
四、训练与监控（书 4.2.2 API 调用、训练监控）
4.1 提交训练任务
调用 Fine-tuning API，传入 training_file（file_id）、model（如 gpt-3.5-turbo）、可选 validation_file、超参数（如 epochs、batch_size）。任务提交后返回 job_id。
4.2 监控训练进度
通过 Jobs API 查询状态：pending → running → succeeded / failed。running 时可查看训练 loss、验证 loss（若提供验证集），便于判断是否过拟合或需早停。
4.3 训练完成后
成功后获得专属模型 ID（如 ft:gpt-3.5-turbo:xxx），在 ChatCompletion 等 API 中将该 ID 作为 model 传入即可使用。
五、评估（书 4.2.2 模型评估）
5.1 评估维度
- 格式符合率：输出是否满足预定格式（如 JSON、字段完整）。
- 任务准确率：在测试集上对比微调前后，按业务指标（如分类准确率、抽取 F1）评估。
- 幻觉率：是否出现明显编造或与输入矛盾，可抽样人工标注或用规则/模型辅助判断。
5.2 测试集设计
预留与训练集同分布但未参与训练的测试集；可再加一批「边界样本」检验鲁棒性。
5.3 与提示工程对比
若微调后效果仍不如预期，可对比「同任务下仅用提示工程」的效果。有时高质量提示 + 少样本即可达到可用水平，无需微调；微调适合提示已优化到瓶颈、且对格式/领域有极致要求的场景（与书 4.2.1 适用场景一致）。
六、成本与权衡（书 4.2.4）
- 训练成本：按训练 Token 计费，数据量越大成本越高。
- 推理成本：微调后模型调用单价可能与基础模型不同，需以官网为准。
- 数据要求：高质量标注数据是效果关键，数据不足或噪声大时，微调收益有限。
- 迭代周期：数据准备 → 训练 → 评估通常需数天，迭代慢于提示工程，适合相对稳定的任务。
七、数据量不足时的替代方案
若当前仅有少量标注数据（如几十条），直接微调可能过拟合或效果不稳定。可考虑：（1）先用提示工程 + 少样本将现有样本作为 in-context 示例，验证任务可行性与格式；（2）再通过主动学习或业务积累逐步扩充数据，达到数百条后再启动微调；（3）或采用领域预训练/继续预训练（若平台支持）再微调，但成本与复杂度更高。书中 4.2.4 的「数据要求」与 4.3 的「组合策略」均支持「先提示、后微调」的路径，本节与之一致。
八、小结
微调适合对格式与领域有极致要求的场景；数据质量与数量是效果的关键。本节与书中 4.2.2「微调流程」完全对应，按数据准备、API 调用、训练监控、模型评估执行即可。下一节将给出法律文本分析与代码审查的微调实战案例。建议在立项微调前，先用 4.1～4.5 的提示技巧做到当前数据下的效果上限，再根据格式符合率与业务指标决定是否投入微调，避免过早投入而收益有限。
九、OpenAI 微调 API 的简要说明
微调通过 OpenAI 的 Fine-tuning API 提交：需先上传 JSONL 格式的训练文件（及可选的验证文件），获得 file_id 后调用创建 job 的接口，传入 model（如 gpt-3.5-turbo）、training_file、可选超参数（如 n_epochs）。任务创建后可通过 Retrieve job 接口轮询状态，成功后会返回 fine_tuned_model 的 ID，在 ChatCompletion 等接口中将该 ID 作为 model 参数即可使用。具体参数名与可选值以 OpenAI 官方文档为准，本书与本节侧重流程与数据准备，实现时以文档为准。书中 4.2.2「微调流程」中的「API 调用、训练监控」即对应上述步骤。
十、与 4.1 提示工程、4.7 实战案例的衔接
4.1～4.5 提示工程：微调前建议先用提示工程（角色、少样本、格式约束、防御性提示）做到当前数据下的效果上限；若格式符合率或领域术语仍不达标，再投入数据做微调。微调后的模型在推理时仍可使用 system/少样本等提示，与提示工程互补。4.7 节实战：法律文本分析与代码审查的数据格式、质量要求与本节 2.1～2.3 一致；按本节流程准备 JSONL、上传、监控、评估后，即可在 4.7 的两个场景中复现。书中 4.2.1 微调概述、4.2.2 流程、4.2.4 成本与权衡在本节已全部覆盖，4.2.3 实战在 4.7 节展开。与 1.6 节选型的关系：1.6 指出微调适合「格式与领域要求极高、有足够标注数据」的场景；本节的数据准备与质量要求即该判断的落地标准。立项微调前建议先用 4.1～4.5 的提示技巧做到当前数据下的效果上限，再根据格式符合率与业务指标决定是否投入微调，避免过早投入而收益有限。
下一节预告：4.7 微调实战案例：法律文本分析与代码审查应用
