yolo-training
GitHub针对YOLO26模型训练问题的诊断与优化技能,涵盖mAP提升、过拟合分析、超参数调优及各类任务(检测、分割等)的训练指导。
Trigger Scenarios
Install
npx skills add fcakyon/claude-codex-settings --skill yolo-training -g -y
SKILL.md
Frontmatter
{
"name": "yolo-training",
"description": "This skill should be used when user asks to \"improve my mAP\", \"why is my model overfitting\", \"my training is diverging\", \"read my results.csv\", \"interpret my training curves\", \"my AP50 is good but AP50-95 is bad\", \"my recall is low\", \"how do I pick learning rate\", \"which augmentations should I use\", \"should I use a bigger model\", \"tune hyperparameters\", or asks how to train YOLO26 for detection, instance or semantic segmentation, pose, OBB, classification, or depth."
}
YOLO26 training
Read the run before changing anything. The results.csv and confusion matrix usually name the
problem already.
Order of operations
Ordered by cost to try, cheapest first, not by size of the potential win.
- Epochs and schedule. Undertrained looks like every other problem, and it costs nothing but time to rule out.
- Augmentation. The knob for the generalization gap, at no extra compute per epoch.
- Loss weights and LR. Cheap, and the curves usually say which one is wrong.
- Model size. Scale up when train loss is still falling at the end of the schedule and the train and val curves sit close together. That is underfitting, and it is the only case a bigger model reliably fixes.
- Resolution. Compute scales with the square of
imgsz, so 640 to 1280 is roughly 4x the training budget, and pretrained weights transfer worse the further you move from the size they were fit at. Justify it with the object sizes in your data, not as a default first move. - Data, label quality and class balance. The highest ceiling and the slowest to move. The package ships no dataset-analysis tooling, so any audit here is your own script plus looking at images. Worth it once the cheap knobs are spent.
Diagnostic loop
import pandas as pd
df = pd.read_csv("runs/detect/train/results.csv")
df.columns = df.columns.str.strip()
print(df.tail(10)[["epoch", "train/box_loss", "val/box_loss", "metrics/mAP50(B)", "metrics/mAP50-95(B)"]])
print("best epoch:", df["metrics/mAP50-95(B)"].idxmax(), "of", len(df))
Then read, in this order:
| Read | Question it answers |
|---|---|
| best epoch vs total epochs | undertrained, overtrained, or right |
| train loss vs val loss trend | which side of the generalization gap |
| mAP50 vs mAP50-95 | classification and recall vs localization |
| P vs R at the operating point | over-suppression vs over-firing |
| per-class AP spread | one broken class or a general weakness |
| confusion matrix background row and column | false positives vs missed detections |
references/diagnostics.md maps each pattern to a cause and a knob, and lists what to rule
out before turning that knob. Read it before recommending a change.
references/task-notes.md covers detect, segment, semantic, pose, obb, classify, and depth
specifics.
Defaults that will surprise you
These produce "I changed X and nothing happened". All six are current defaults.
optimizer=autoignoreslr0andmomentum. It is the default. It picksMuSGDat lr 0.01 whenceil(len(dataset) / max(batch, nbs)) * epochsexceeds 10000, otherwiseAdamWat0.002 * 5 / (4 + nc), and forceswarmup_bias_lr=0. Crossing that iteration count silently changes optimizer between two runs you meant to compare. Settinglr0while leavingoptimizer=autodoes nothing. Setoptimizer=AdamWoroptimizer=SGDexplicitly first.nbs=64normalizes the loss, so batch does not scale LR the way you assume. Below 64 the trainer accumulates gradients to an effective 64. Dropping batch 64 to 16 changes almost nothing about the effective step.close_mosaic=10turns off mosaic for the last 10 epochs. The late jump in mAP is that switch, not convergence. On a 20-epoch run it is half the schedule, and on a 10-epoch run mosaic never runs at all.- Fitness for detect is mAP50-95 alone, weights
[0, 0, 0, 1].best.ptandpatienceignore precision, recall, and mAP50 completely. Segment and pose sum both heads, classify uses(top1 + top5) / 2, semantic uses mIoU. A run whose precision is climbing while mAP50-95 is flat will still early-stop. max_det=300truncates validation on dense scenes. Above roughly 300 objects per image your recall ceiling is an artifact.- YOLO26
end2endmodels decode without NMS, soioudoes nothing on them.agnostic_nmsstill applies, the predictor passes it into the head, so only the IoU threshold is dead.
Starting recipe
Fine-tuning a pretrained checkpoint on a normal custom dataset:
yolo train model=yolo26s.pt data=my-data.yaml epochs=200 imgsz=640 batch=16 \
optimizer=AdamW lr0=0.001 lrf=0.01 cos_lr=True warmup_epochs=3 \
patience=50 close_mosaic=20
Deviate on evidence from the charts, one axis at a time. It differs from the shipped defaults
because epochs=100 is short for a small dataset, patience=100 never fires inside 100 epochs,
and close_mosaic=10 is too short a clean tail once epochs rise.
Change one thing per run and keep seed fixed. Run-to-run noise on a small dataset is often
0.5 to 1.0 mAP, so a 0.3 mAP "improvement" from a single run is not a result. Confirm anything
under about 1 point across three seeds.
Version History
- c4b9424 Current 2026-08-20 04:54


