自动化再训练循环
将一次部署转变为可重复的循环:包括运行手册、脚本化的晋级门禁、支持回滚的自动发布,以及每周审查。
第一次部署是一个项目;此后的每次部署都是一个流程。把循环写成脚本的团队会在留出集告警触发时,于一个下午内完成再训练;没有脚本的团队则会在压力下凭记忆重建流程,并发布性能退化的版本。本课程将使用药片模型完整演练一次循环,包括微调、门禁检查和发布,并编写运行手册,让下次操作成为例行流程。
实践操作
闭环:每个步骤都有人负责#
如果你学过前面的课程,就能免费获得模型溯源信息:模型的 运行信息 卡片会标明其父模型和固定的数据集版本,数据集的 模型 标签页会列出每个版本训练出的所有模型,部署页面则会链接到当前提供服务的模型。准确率下降时,从部署开始逆向追溯。

智能体会自动完成收集步骤。收集不确定检测结果会通过你的部署进行预测,并将检测置信度处于指定范围内的图像复制到审核数据集中;捕获并提醒会保存符合条件的图像并向 Slack 发送消息。工作流会在你点击 运行 时执行,因此要把运行工作流纳入每周审核。

完整示例:药丸模型的一个完整周期#
1. 从已部署的模型微调。在 Platform 中,在 我的模型 下选择已部署的模型,启用 保存数据集版本,并明确设置优化器。在本地执行相同步骤时:
from ultralytics import YOLO
model = YOLO("pills-v1.pt") # 已部署模型的 best.pt
model.train(data="medical-pills.yaml", epochs=5, imgsz=320, optimizer="SGD", lr0=0.001, name="v2-finetune")这是从训练、查看和微调运行课程中进行的微调:mAP50-95 从 0.659 提升到 0.687。
2. 与已部署模型进行门控比较。在课程 6 中复用 gate.py,使用留出集和两个检查点:
DATA = "medical-pills.yaml" # 你的留出数据集 YAML 或 ul:// URI
BASELINE, CANDIDATE = "pills-v1.pt", "pills-v2.pt" # 已部署模型与重新训练的候选模型PASS mAP50-95 0.659 -> 0.687 beats noise
PASS every class keeps 90% of its AP (weak: none)
PASS inference 4.0 ms within 100 ms
verdict: ship the candidate门控检查以 0 退出,因此 CI 可以继续执行发布步骤。(本演示使用 medical-pills 验证集划分作为留出集;在生产环境中,请使用模型从未见过的留出版本。)
3. 发布模型。将候选模型上传或训练到同一工作区,然后让 CI 通过 ultralytics-platform SDK 调用 替换模型,并确认当前提供服务的模型:
import time
from ultralytics_platform import Platform
OWNER, DEPLOYMENT = "your-username", "pill-detector-st-ghislain"
PROJECT, NEW_MODEL = "pill-inspection", "v2-finetune"
with Platform() as client: # reads ULTRALYTICS_API_KEY
body = {"action": "replace", "project": PROJECT, "model": NEW_MODEL}
reply = client.deployments.update(OWNER, DEPLOYMENT, body=body)
print(reply["status"], "-", reply["message"]) # "deploying" while the new model starts
while (deployment := client.deployments.retrieve(OWNER, DEPLOYMENT)["deployment"])["status"] == "deploying":
time.sleep(15)
print(f"status={deployment['status']} model={deployment.get('model')}")
if deployment.get("model") != NEW_MODEL: # a failed rollout leaves the previous model serving
raise SystemExit("Replacement failed; the previous model is still live")针对一个桩 API 进行测试,该 API 首次报告 deploying,随后报告 ready;程序会输出:
deploying - Replacement model is deploying
status=ready model=v2-finetunedeployments.update 会使用 action: "replace" 发送 PATCH /api/deployments/{owner}/{deployment};新模型就绪前,旧模型会继续提供服务。轮询程序会持续检查 retrieve,直到状态不再是 deploying,然后检查当前提供服务的模型,因为失败的部署也会以 ready 结束,只是仍使用旧模型。回滚时,只需在同一脚本中将 NEW_MODEL 设为之前的版本。随 ultralytics 一同发布的 ul cloud 命令行工具封装了相同的 API,API 参考中记录了所有调用。
4. 重置基线。使用新的检查点和全新的历史记录文件,运行课程 8 中的 holdout_check.py。
编写运行手册#
# Retraining runbook: pill-detector
## Trigger
- Holdout mAP50-95 more than 1 point below baseline for 2 consecutive weeks, OR
- Batch Annotation edit rate above 25% on a new batch.
## Steps
1. Collect: Save to dataset from Monitoring, plus the "Collect Uncertain Detections" agent into pill-review.
2. Label: Batch Annotation with the deployed model at the swept threshold; review every image; record the edit rate.
3. Merge into the training dataset; rerun the duplicate check, class audit, and Clustering.
4. Create dataset version v(n+1) with a description of what changed.
5. Fine-tune from the deployed model with Save Dataset Version on; optimizer SGD, lr0 0.001.
6. Run gate.py against the deployed model on the holdout. Stop here on any FAIL.
7. ML lead approves; CI runs release.py.
8. Watch endpoint_check.py for 24 hours; start a new holdout baseline.
## Rollback
- Run release.py with NEW_MODEL set to the previous version. Never delete that model while it's the rollback target.
## Owner
- ML lead approves step 7. On-call runs steps 1-6 and 8.在日历上安排每周一次的 15 分钟审核,围绕两个问题展开:有没有任何指标变红(端点检查、留出集、编辑率)?部署有没有变化,原因是什么?大多数时候,两个问题的答案都是否,会议五分钟就能结束。一个典型季度如下:
Week 1 : Holdout alert. Collect, label, retrain, gate, release v(n+1).
Week 2-3 : Quiet. Checks green.
Week 4 : New defect class requested. Label, new version, retrain v(n+2).
Week 5-7 : Quiet.
Week 8 : Second plant in Poland. Check regions; add an endpoint in europe-central2.
Week 9-11: Quiet.
Week 12 : Quarterly holdout refresh and review.常见问题#
症状:发布出现问题,之前的模型却不见了。解决方法:项目中至少保留最近两个生产模型。删除模型会将其移至回收站;永久删除模型还会移除任何仍在使用该模型的部署。
症状:你计划进行 10%/50%/100% 的金丝雀发布,但“替换模型”会一次性切换所有流量。解决方法:每个端点只提供一个模型。进行金丝雀发布时,请将候选模型部署到第二个端点,并通过你自己的路由器拆分流量;之后再替换模型并删除第二个端点。
症状:每个候选模型都通过了门控,但生产环境中的表现仍然退化。解决方法:只有使用任何运行都未曾训练过的留出版本,门控结果才可靠。请将留出数据保存在独立的私有数据集中,绝不要将它合并到训练数据中。
显示解答
药丸生产线的完整周期示例。触发条件:夜班留出集检查的指标下降了 0.05。收集:将 180 个夜班 Monitoring 示例保存到 pill-review,再从“收集不确定检测结果”智能体获取 120 个示例;使用已部署的 v2-finetune 以 0.35 的阈值进行批量标注,编辑率为 18%;审核并合并;审计通过;版本为 v6: +300 night-shift frames。从 v2-finetune 微调 v3-night,使用 SGD、lr0 0.001、训练 20 轮。在包含 100 张夜班图像的 300 张留出集上进行门控检查:mAP50-95 从 0.66 提升到 0.71,没有弱势类别,耗时 4 ms:通过。release.py 与 NEW_MODEL = "v3-night" 报告 status=ready model=v3-night;holdout_check.py 写入新的 0.71 基线。v2-finetune 仍保留在项目中作为回滚目标,运行手册、门控检查和发布脚本一并提交。