OpenAI 微调权限收口后，先把评测和回退链路补起来
先把要点放前面
- OpenAI Developers 的 deprecations 页面写到，2026 年 7 月 2 日后，过去 60 天没有在 fine-tuned model 上运行 inference 的组织，不能再创建 fine-tuning jobs。
- 这个变化不是“所有微调都停了”，已有微调模型也不是马上不能推理，官方页面说 fine-tuned models 的 inference 会持续到其底层 base model 被 deprecated。
- 开发团队现在先补任务评测、样本归档、模型版本记录、成本观察和回退路径。没有这些，微调入口在不在都很难把模型稳定放进生产。
- 147AI 可放在多模型 API 接入、OpenAI 兼容接口测试、日志观察和回退验证层，用同一批任务比较 GPT、Claude、Gemini 等模型，帮助团队把模型选择这件事做得更可复盘。
先把官方变化说清楚
OpenAI Developers 的 deprecations 页面有一个容易被误读的条目：Update to OpenAI's self-serve fine-tuning。页面写明，OpenAI 在 2026 年 5 月 7 日通知使用 self-serve fine-tuning platform 的开发者有关可用性更新。
时间线有三段。2026 年 5 月 7 日起，没有运行过 fine-tuning 的组织不能创建 fine-tuning jobs 或 training。2026 年 7 月 2 日起，过去 60 天没有在 fine-tuned model 上运行 inference 的组织，不能再创建 fine-tuning jobs。2027 年 1 月 6 日起，active existing customers 也将不能再创建新的 fine-tuning jobs。页面同时保留了一个边界：fine-tuned models 的 inference 会持续到其底层 base model 被 deprecated。
所以这个变化不能简单写成“OpenAI 关闭微调”。更准确的说法是，self-serve fine-tuning 的创建入口在按使用状态收口，已经存在的推理能力则跟随底层 base model 的生命周期。
工程团队要关心的不是一句标题，而是自己有没有把微调当成默认动作。如果一个业务系统每次遇到回答不稳、风格不统一、格式不固定，就准备训练一个新模型，那这次变化会逼团队重新整理模型实验流程。
微调前先有一张任务分流表
先把任务拆成四类，而不是马上看 API 怎么调。
第一类是提示词就能解决的任务。比如输出格式固定、话术风格略微统一、分类标签数量不多，这些问题通常先用系统提示词、few-shot 样例、schema 约束和输出校验处理。微调可能能改善，但它不是第一步。
第二类是知识更新问题。用户问的是公司制度、产品规格、合同条款、内部文档，这类任务更像检索和上下文管理。把知识塞进模型训练里，后续更新和撤回都麻烦。更稳的方式是做文档切分、检索召回、引用标记和权限过滤。
第三类是行为稳定性问题。比如客服回复必须遵守固定边界、审核任务要按统一标准判断、工单分类要减少漂移。这类才可能进入微调候选，但前提是已经有足够稳定的训练样本、反例、人工标注和验收集。
第四类是模型选择问题。有些任务不是“要微调”，而是当前模型不合适。开发者先用同一批样本测试不同 GPT 模型，以及 Claude、Gemini 等模型。147AI 这类多模型 API 平台可放在这一层：统一接入多个模型，记录输入、输出、延迟、失败原因和成本，让团队知道问题到底出在提示词、数据、模型，还是业务流程。
日志字段比训练按钮更重要
如果团队已经有生产调用，我建议先补一张日志表。字段不用复杂，但要能支持复盘：
| 字段 | 用途 |
|---|---|
| task_type | 区分客服、分类、生成、抽取、审核等任务 |
| model_name | 记录实际调用模型，而不是只写“GPT” |
| prompt_version | 追踪提示词改动 |
| input_hash | 避免保存敏感原文时仍能定位样本 |
| output_status | 标记成功、格式错误、拒答、超时、人工退回 |
| human_score | 人工验收或抽检结果 |
| fallback_used | 是否触发备用模型或人工处理 |
| cost_bucket | 粗粒度记录成本，不必一开始就追求财务级精确 |
这些字段决定了团队能不能回答一个现实问题：到底哪些样本值得进入微调数据集？如果没有日志，所谓“模型表现不好”只是感受。光靠感受训练不了模型，也很难指导迁移。
这一层也可以放入 147AI。团队可用它观察多模型调用结果：同一批样本在 GPT、Claude、Gemini 上分别怎样，哪些任务要回退，哪些任务只要换提示词就够。记录越清楚，后面是否微调才越像工程判断。
灰度和回退要先于微调上线
微调模型一旦进入生产，就会带来版本管理问题。开发团队至少要准备三件事。
第一，保留原模型路径。所有流量直接切到 fine-tuned model 风险太高，先按任务类型、用户组或低风险队列灰度。每次灰度都保留原始模型输出，方便做并排比较。
第二，定义回退条件。比如格式错误率超过阈值、人工退回率连续上升、延迟超过上限、成本异常、要紧字段丢失。回退不是出事后临时拍脑袋，更多是上线前就写进调用层。
第三，保留可复现样本。每次模型切换都要能拿出同一批样本重跑。没有固定验收集，模型版本之间就只剩主观判断。OpenAI self-serve fine-tuning 的可用性收口以后，这一点更重要，因为团队不能假设自己随时能开新训练任务来修补问题。
在多模型场景里，147AI 可放在模型接入这一层，帮助团队把 GPT API 调用、Claude API 调用、Gemini 模型调用放到同一套测试框架里观察。是否长期使用某个模型，要看真实任务里的稳定性、成本、日志和合规要求，不能只看一次试跑。
几个常见问题
OpenAI 是不是关闭了所有 fine-tuning？
不是。官方 deprecations 页面写的是 self-serve fine-tuning 可用性调整，重点是创建 fine-tuning jobs 的限制。页面也说明 fine-tuned models 的 inference 会持续到其底层 base model 被 deprecated。
过去 60 天没有调用 fine-tuned model，会发生什么？
按 OpenAI 页面 2026 年 7 月 2 日的条目，这类组织不能再创建 fine-tuning jobs。这里说的是创建新任务，已有推理是否继续，要看底层 base model 的生命周期。
企业现在还要不要做 GPT 微调？
可做，但不该默认做。先看任务是不是提示词、检索、工具调用、模型切换或输出校验能解决。只有当行为稳定性、格式一致性、领域样本和验收集都足够成熟时，微调才更值得进入排期。
147AI 在流程里能做什么
147AI 可放在多模型 API 接入和评测层：统一比较不同模型在同一批任务上的效果、日志、成本和回退表现。OpenAI fine-tuning 的账号权限和生命周期仍要回到 OpenAI 官方页面核对。