Recommend training config
Overview
Reads an object detection evaluation report and writes a training config for the next run. A small, fixed set of rules checks what the report measured (how much worse small objects score than large ones, and which error type costs the most Average Precision) and changes the input size, the epoch count, or the box loss weight to address it.
The output binds straight to a train node’s Hyperparameters input, so the loop closes without anyone transcribing numbers by hand. The badge lists the changes it made.
Prerequisites
How it works
FAQ
Which rules can change the config?
Three. When AP on small objects is under 70% of AP on large ones, the input size steps up to the next of 640, 800, 960, and 1280. When missed objects or loose boxes are the costliest error type, the epoch count grows by half, up to 300. When loose boxes are the costliest error and the framework is YOLO, the box loss weight grows by 20%.
Why does it recommend no change even though it found problems?
Some findings have no training setting that honestly fixes them. Recall that drops in crowded images, classes with under 10% of the objects of the largest class, and wrong-class, background, or duplicate errors as the costliest type are all label or data problems. They are written to the run log, and the badge says there is no config change.
What happens when I leave Current training config empty?
The rules start from the selected train node’s default values, and the output holds only the changed keys. When nothing changes, the output is an empty mapping. Paste the config you trained with to get a complete config back.
Why does my current config fail to load?
It must be a YAML mapping of keys to values. A list or plain text is rejected.
Does it work with reports from older evaluations?
Yes. A rule whose chart is missing from the report simply doesn’t fire, and the rest still run.
Which keys does it never touch?
Dataset and run wiring such as data, model, num_classes, __include__, dataloader paths, and eval_interval. The train node owns them, and a recommendation that touched one would silently point training at the wrong data.
Inputs
Object detection evaluation report to draw the recommendation from. Generic reports are not supported. Key: REPORT_ID.
Which train node the recommended config is written for. Config keys differ between frameworks. Key: TRAIN_FRAMEWORK.
Options:
- YOLO (
yolo) - DEIM (
deim) - EdgeCrafter (
edgecrafter) - Grounding DINO (
grounding_dino)
The config used for the evaluated run. Recommendations are merged over it, so anything not recommended is preserved. Leave empty to start from framework defaults. Key: BASE_CONFIG.
Outputs
Training config with the recommended changes merged in, ready to bind to a train node’s Hyperparameters input. Shown as an artifact. Key: CONFIG.
What the report suggests changing. Shown on the node as a badge. Key: SUMMARY.
Models and configuration
Set Training framework to the train node you’ll bind the output to. The train nodes spell the same settings differently, and not all of them expose the same knobs.
Only YOLO exposes a box-regression weight the node can move. For the others, dominant localization error lengthens the schedule and stops there.
JSON config
Machine-readable node interface for automation and advanced usage.