Generated banner for Tao Run Deft Object Detection
Generated logo for Tao Run Deft Object Detection

Tao Run Deft Object Detection

NVIDIAOfficialCreated by NVIDIA Corporation

  • Skill
  • Workflow
  • Software development
  • Apache-2.0
  • Medium risk
  • Has scripts

From the author

Run the full DEFT smart-data-augmentation loop for NVIDIA TAO Grounding DINO object detection: zero-shot baseline inference, KPI analysis, per-class gap analysis, SigLIP embedding of weak images, unique-neighbor mining against a source pool, ODVG dataset staging, and retraining — repeated for a fixed number of iterations. Also prepares the source pool the loop mines from, as a separate run: Co-DETR pseudo-labeling, folding to the target classes, KITTI→COCO→ODVG conversion, and embedding. Use for prompts like "run the DEFT OD loop", "run smart data augmentation for grounding dino", "mine and retrain my detection model", "improve OD mAP with gap analysis and mining", "prep the source pool", or "pseudo-label my unlabeled images for mining"; do not use for standalone TAO training, one-off inference, or gap analysis alone.
— the description by NVIDIA Corporation

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill executes a multi-stage, iterative workflow designed to improve object detection model performance through smart data augmentation. It manages a complete loop including zero-shot baseline inference, KPI analysis, per-class gap analysis, SigLIP-based embedding, unique-neighbor mining from a source pool, dataset staging, and retraining. The skill also provides a separate invocation for preparing the source pool, which involves pseudo-labeling raw images with Co-DETR, remapping classes, and converting data formats. It operates as a state-managed loop, ensuring consistency across iterations and providing automated reporting.

What it does

  • Performs zero-shot baseline inference and KPI analysis on Grounding DINO models.
  • Conducts per-class gap analysis to identify model weaknesses.
  • Mines unique, high-value training samples from a prepared source pool using SigLIP embeddings.
  • Stages mined data into the ODVG format for iterative model retraining.
  • Prepares source pools by pseudo-labeling raw images and converting them to the required ODVG format.
  • Maintains a persistent state machine to track progress and ensure auditability across training iterations.

When to use it

  • When you need to improve the mAP of a Grounding DINO model through iterative data mining.
  • When you have a large pool of unlabeled images that need to be pseudo-labeled and mined for training.
  • When you want to automate the gap analysis, mining, and retraining cycle.
  • When you need to prepare a source pool of images for use in a DEFT-based detection workflow.

Advantages

  • Automates complex, multi-step data augmentation and training loops.
  • Reduces manual effort in identifying and labeling high-value training data.
  • Ensures consistent data processing and state management across iterations.
  • Provides clear visibility into model performance trends through automated KPI reporting.

Usage examples

“run the DEFT OD loop”
The agent initiates the iterative mining and retraining process, starting with baseline inference and gap analysis.
“prep the source pool”
The agent runs the Co-DETR pseudo-labeling and embedding pipeline to prepare your raw images for future mining.
“mine and retrain my detection model”
The agent performs gap analysis, mines new samples from the source pool, stages the data, and triggers a retraining iteration.
“improve OD mAP with gap analysis and mining”
The agent executes the full DEFT loop to identify performance gaps and iteratively grow the training dataset to boost mAP.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/tao-run-deft-object-detection/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip tao-run-deft-object-detection.zip -d .agents/skills

Documentation by NVIDIA Corporation

Skill: tao-run-deft-object-detection

Standalone install? If this session was not initialized by the TAO skill bank plugin, run the tao-setup skill first (host preflight, credentials, cross-skill discovery).

Execution Contract

Treat this as a disk-backed state machine, not as a prose recipe.

  1. Preserve every explicit user value. epoch 1 means train.num_epochs=1; a spec value or documented default applies only when the user did not supply that parameter. Show the source of every run parameter (user, spec, or default) in the Pre-Flight Summary.

  2. After the user approves the Summary, initialize deft_state.json once with scripts/init_deft_state.py. Never hand-author or reinitialize it on resume.

  3. Run every bundled or inline host-Python command through scripts/deft_python.sh. On startup, after context compaction, before every stage, and before any completion claim, run:

    <skill_root>/scripts/deft_python.sh \
      <skill_root>/scripts/audit_deft_run.py --results-dir "${RESULTS_DIR}"

    If it prints DEFT_RUN_STATUS=INVALID, stop and repair the listed disk inconsistency; do not launch another stage. Read the path printed as read_before_action before continuing.

  4. Invoke the mapped underlying skill after reading the DEFT overlay. Do not replace a missing or unread stage reference, or a failed skill call, with guessed shell commands, inline Python, a different output tree, or fabricated data.

  5. Commit every stage with scripts/commit_stage.py; it verifies artifacts, updates deft_state.json, appends exactly one ordered loop_log.jsonl event, and rolls back if its audit fails.

  6. Claim the loop complete only when this exits zero:

    <skill_root>/scripts/deft_python.sh \
      <skill_root>/scripts/audit_deft_run.py \
      --results-dir "${RESULTS_DIR}" --require-complete

Context Discipline

  • Load references just in time. Run the audit, read only its read_before_action file and the current stage's named section, then act. Never preload all references.

  • Redirect verbose train, inference, and Docker output to files. Inspect at most the final 40 lines or a one-line artifact check; never print a full spec, state file, or loop log into the conversation.

  • A Skill-tool call loads stage instructions; it does not start a background orchestrator. Continue the documented stage in the parent immediately after it returns.

When to Use This Skill

Use this skill when the user wants an agent to run the full smart-data-augmentation loop for a TAO Grounding DINO detection model: zero-shot baseline, gap analysis, mining, dataset growth, and retraining across N iterations.

  • "Run the DEFT OD loop"

  • "Run smart data augmentation for grounding dino"

  • "Mine more training data for my detection model and retrain"

  • "Improve detection mAP with gap analysis and unique-neighbor mining"

Also use it to prepare the source pool, which is a separate run that completes before the loop launches (see ## Two Invocations: Prep, Then Loop):

  • "Prep the source pool"

  • "Pseudo-label my unlabeled images for mining"

  • "Build the mining pool from these raw images"

Do not use this skill for a single standalone TAO training run, one-off inference, or gap analysis alone. Invoke the relevant leaf skill directly instead.

Scope: Grounding DINO + ODVG

This loop targets Grounding DINO with ODVG training annotations (tmm_odvg.jsonl + labelmap.json), matching the reference pipeline. dataset.train_data_sources is a list; each iteration appends one new ODVG source rather than rewriting a combined CSV. DINO and RT-DETR (COCO) are not supported by this workflow — use the leaf skills directly for those.

The loop does not train at baseline. It evaluates the supplied zero-shot / pretrained checkpoint as iteration 0 and only trains from iteration 1 onward, once mining has produced data to add.

Two Invocations: Prep, Then Loop

The source pool is prepared by its own run, before the loop launches. They are separate because a pool is prepped once and then serves many loop runs — coupling them would re-label and re-embed the same images on every launch.

InvocationDoesProduces
"Prep the source pool"Co-DETR pseudo-labels raw pool images, folds to the target classes, converts KITTI→COCO→ODVG, verifies, embedscoco.json, odvg/, source_embeddings.parquet, pool_report.json
"Run the DEFT loop"baseline → iterationscheckpoints, KPI, the mAP trend

Follow references/prep-source-pool.md for the first. The loop then takes those four paths as inputs; Pre-Flight validates them and init_deft_state.py pins them, so a run cannot reach mine with no corpus to search.

Launch Intake

Do not ask which platform to run on. This workflow supports one: every stage launches with docker run, and its compatibility line requires docker plus the nvidia-container-toolkit. The bank's rule in AGENTS.md is to treat a single supported platform as the selection and only ask when an application supports several — asking here would offer a choice that nothing downstream can act on.

Read tao-run-on-docker's ## Credentials section.

Never ask for or read credential values. Check only whether the required environment variable is set; if unset, tell the user which variable to export.

Agent Behavior

There is exactly one user gate: pre-flight confirmation. Print the Pre-Flight Summary (see references/preflight.md), then STOP and wait for explicit approval ("go", "yes", "looks good"). Do not launch any side-effecting step before that approval.

After the gate, the skill is fully autonomous. Run the entire loop without asking for confirmation. Only stop if a step fails with an unrecoverable error or a hard-stop gate fires. Print a one-line status update at each stage milestone.

Auto-mode required. The post-gate loop fires constant side-effecting calls; without auto-accept mode it stalls on the first prompt. Remind the user at the Pre-Flight Summary to enable auto-mode (shift+tab) before approving.

Non-zero command rule. Never repeat an unchanged failed command. Read the final error block, map it to the loaded stage reference, make one evidence-based correction, and rerun its documented verification. If the reference does not cover the failure, commit status=error and halt.

Revised plan. If any run parameter changes after the Summary was shown, re-run Pre-Flight and show an updated Summary before proceeding.

Workflow

Full detail in references/pipeline-and-state.md.

  1. Pre-Flight. Run every check in references/preflight.md. Resolve workspace, specs, annotations, the zero-shot checkpoint, the source-pool embedding parquet, and container images. Hard stop only on missing input you cannot resolve yourself.

  2. Prep (once, before baseline). If the source pool is not already labeled and embedded, pseudo-label it with Co-DETR, fold the predictions onto the user's target classes, convert KITTI→COCO→ODVG, and embed the pool. Skip any step whose output already exists — no script does this for you, so check before each step. See references/prep-source-pool.md.

  3. Baseline (iter_0) — no training. Run inference with the supplied zero-shot / pretrained checkpoint, then kpi_analyze. Seed train_grounding_dino.yaml from the user's template for later iterations to extend.

  4. Iterate. For each iteration 1..max_iterations, run the seven stages in order: gap_analysis → embed → mine → stage → train → inference → kpi_analyze. Each iteration's gap_analysis consumes the previous phase's inference labels. Between stages run the audit and follow its one-line disk-backed next action.

  5. Stop when max_iterations is reached or a hard-stop gate fires. mAP is reported, not gated — the loop does not early-exit on a metric target.

  6. The report renders itself. results/DEFT_Loop_Report.md is written by init_deft_state.py and re-rendered by every accepted commit_stage.py call. Do not spawn a subagent for it and do not compose it by hand; to refresh it out of band, run scripts/render_report.py --results-dir "${RESULTS_DIR}".

All stages run inline in the parent context. Prefer invoking the underlying tao-skill-bank:* skills via the Skill tool, layering loop conventions on top via the matching references/*.md overlay.

Using Bundled Scripts

Run bundled scripts through <skill_root>/scripts/deft_python.sh. Resolve every path argument to an absolute host path first. Use commit_stage.py for all state and log writes. See references/scripts-and-agents.md.

Stage Reference Modules

Each stage maps to one underlying skill or to bundled glue. Read only the current stage's overlay, then invoke.

The overlays are written against two loop variables that Pre-Flight sets and every stage uses: N, the current iteration number, and PHASE, which is baseline or iter${N}. They are stated here because a stage overlay is read on its own — see references/preflight.md for the full set.

If an overlay is missing, stop and ask the user to reinstall the plugin — the loop cannot run a stage whose settings it does not have. If a mapped skill is unavailable, do not stop and do not improvise: fall back to the overlay's documented docker run as described in references/scripts-and-agents.md, and commit that stage with --execution-path direct-container instead of the documented skill. The overlay carries everything the invocation needs, so the fallback produces the same artifacts.

On a runtime without a Skill tool (Codex, for example), the mapped skills are still on disk under the plugin root: read skills/<layer>/<name>/SKILL.md there for the invocation contract, then run it through the direct-container fallback above, committing the stage with --execution-path direct-container. On such a runtime that fallback is the expected route for every stage, not an exception.

StageOverlayUnderlying skill
prep (once)references/prep-source-pool.mdtao-skill-bank:tao-train-codetr + tao-generate-image-embeddings (+ bundled glue)
gap_analysisreferences/tao-analyze-gaps-od-map.mdtao-skill-bank:tao-analyze-gaps-od-map
embedreferences/tao-generate-image-embeddings.mdtao-skill-bank:tao-generate-image-embeddings
minereferences/tao-mine-od-images.mdtao-skill-bank:tao-mine-od-images
stagereferences/stage-mined-data.md(bundled glue — no leaf skill)
train, inferencereferences/grounding-dino.mdtao-skill-bank:tao-train-grounding-dino
kpi_analyzereferences/tao-analyze-detection-kpi.mdtao-skill-bank:tao-analyze-detection-kpi

Path rule (invariant). Record absolute host paths under ${RESULTS_DIR}. Mount "$WORKSPACE:$WORKSPACE" with identical host and container paths. TAO's update_results_dir appends the task name to results_dir, so passing results_dir=X to train writes X/train/ and to inference writes X/inference/. Never append the subdirectory yourself.

Data, Pre-Flight, Pipeline, and State References

TopicReference
Data contract, ODVG layout, source pool, output treereferences/data-layout.md
One-time source-pool prep (pseudo-label, remap, convert, embed)references/prep-source-pool.md
Pre-Flight checks, defaults, Summary templatereferences/preflight.md
Pipeline stages, state schema, loop-end sequencereferences/pipeline-and-state.md
Bundled scripts, glue, the report renderer, stage tablereferences/scripts-and-agents.md

max_iterations defaults to 1 — one mine, train and score pass, the smallest run that yields a comparison against the baseline. Confirm it with the user when they have not said how many iterations they want; an unattended run takes the default rather than stopping to ask.

Gating

Run the full Pre-Flight, print the Summary, then STOP at the one user gate. After approval, run the baseline and the seven-stage iteration pipeline.

Hard-stop and never auto-retry on: any stage status=error; a missing or zero-row source-pool embedding parquet; a zero-row mining result when weak images were present; a missing ODVG annotation source; an image/annotation mismatch after staging; or a train exit that emits no new iteration checkpoint. The loop stops when max_iterations is reached or an unrecoverable gate fires. Each terminal path commits loop_stop through commit_stage.py, then follows the loop-end sequence in references/pipeline-and-state.md.

Files

references/grounding-dino.md

DEFT OD — Train / Inference Stage Overlay

Layers loop conventions on top of tao-skill-bank:tao-train-grounding-dino. Read that skill's SKILL.md for the full spec reference. This file documents only the loop-specific paths, arguments, and commit contract.

results_dir appends the task name

TAO's update_results_dir appends the task name to whatever results_dir you pass:

PassTrain writesInference writes
results_dir=${RESULTS_DIR}/iter${N}${RESULTS_DIR}/iter${N}/train/${RESULTS_DIR}/iter${N}/inference/

Never append /train or /inference yourself — doing so produces iter${N}/train/train/.

The checkpoint and the container are version-coupled

A Grounding DINO checkpoint only loads into a TAO image whose model definition matches the architecture it was trained with. There is no "just use the pinned image" answer: confirm the pairing in Pre-Flight, because the failure lands after the container has started and looks like a checkpoint problem rather than a config one.

class_embed_bias must match the checkpoint

ContrastiveEmbed (the class_embed head) takes a bias argument that defaults to False, sourced from the spec as model.class_embed_bias. A checkpoint trained with class_embed_bias: True carries 13 extra tensors, and omitting the field at inference fails with:

RuntimeError: Error(s) in loading state_dict for GDINOPlModel:
  Unexpected key(s) in state_dict:
    model.model.transformer.decoder.class_embed.{0..5}.bias
    model.model.transformer.enc_out_class_embed.bias
    model.model.class_embed.{0..5}.bias

Only class_embed.*.bias keys unexpected, and nothing else, means exactly this — set model.class_embed_bias: True in the inference spec (and any spec that loads that checkpoint). It is not a corrupt checkpoint, not a backbone mismatch, and not a driver/CUDA problem: load_state_dict compares parameter names in pure Python before any kernel runs, so drivers cannot add or remove a bias. Genuine CUDA faults look different — no kernel image is available, cuDNN errors, device-side asserts.

The field is easy to lose because it is absent from the shipped infer.yaml template and defaults to the value the checkpoint does not use.

log_scale must be set, and a wrong value fails silently

ContrastiveEmbed.forward scales the visual·text similarity before the sigmoid:

res = visual_feat @ text_feat.transpose(-1, -2)
if isinstance(self.log_scale, nn.Parameter): res = res * self.log_scale.exp()
elif self.log_scale == 'auto':               res = res / math.sqrt(visual_feat.shape[-1])

With model.log_scale: null neither branch fires and there is no scaling at all. Raw dot products of 256-dim features reach the sigmoid unscaled and saturate: every detection scores 1.000, conf_threshold filters nothing, and every one of num_select slots is written for every image.

Unlike class_embed_bias, this does not error: the run exits 0 with a full set of label files. null is the schema default and is absent from the shipped infer.yaml, so it is the out-of-the-box failure.

Symptom: exactly num_select boxes per image, every score at ~1.000. The boxes are fine; only the confidences are meaningless. Set model.log_scale: auto, or the learnable float the checkpoint trained with — a checkpoint carrying no log_scale tensor trained with auto.

Left unnoticed this poisons the whole loop: gap analysis sees overwhelming FP, precision collapses to ~0 on every image, and every image is flagged weak — so mining gets no signal while the underlying detector is working.

Confirming a pairing

Read the architecture straight out of the checkpoint rather than guessing:

ck = torch.load(ckpt, map_location="cpu", weights_only=False)
sd = ck.get("state_dict", ck)
# backbone: patch_embed.proj.weight (96,3,4,4) -> embed_dim 96 -> swin_tiny_224_1k
# num_queries: query_embed.weight rows
# enc/dec layers: max index in {encoder,decoder}.layers.N.
# class_embed bias present? -> model.class_embed_bias must be True

Then set model.backbone, num_queries, enc_layers, dec_layers, num_feature_levels, class_embed_bias, and log_scale to match. A mismatch on any of these surfaces as Unexpected key(s), Missing key(s), or size mismatch at load time.

NVIDIA ships the authoritative spec with the checkpoint

The NGC download carries experiment.yaml alongside the .pth. Its model block is the authority for everything below, including both traps documented above:

model:
  backbone: swin_tiny_224_1k
  num_feature_levels: 4
  dec_layers: 6
  enc_layers: 6
  num_queries: 900
  dropout_ratio: 0.0
  dim_feedforward: 2048
  log_scale: auto
  class_embed_bias: True

Keep that file next to the checkpoint. When a spec and a checkpoint disagree, this is the tiebreaker — it is NVIDIA's own configuration for these exact weights, not a value recovered by inspecting tensors.

Reference inference spec

Both traps above are settings, not code, and settings that live only in prose are settings nobody applies. They are therefore held in assets/overlays/grounding_dino_inference.yaml and applied on every run:

INFER_SPEC="${RESULTS_DIR}/<phase>/infer_grounding_dino.yaml"

<skill_root>/scripts/deft_python.sh <skill_root>/scripts/apply_spec_overrides.py \
  --spec "$INFER_SPEC" \
  --apply-workflow-defaults <skill_root>/assets/overlays/grounding_dino_inference.yaml \
  --set inference.checkpoint=<checkpoint> \
  --set inference.num_gpus="$NUM_GPUS" \
  --set results_dir="${RESULTS_DIR}/<phase>" \
  --set dataset.infer_data_sources.image_dir="[<config.kpi_images_dir>]" \
  --set dataset.infer_data_sources.captions='["bicycle", "car", "person", "road_sign"]' \
  --set dataset.max_labels=4 \
  --require-no-mandatory-under inference

The overlay pins inference.conf_threshold: 0.0 (keep the full PR curve — gap analysis and KPI both score these labels), log_scale: auto, class_embed_bias: true, batch_size: 8 and the model geometry. What stays in --set is the checkpoint, the paths, the GPU count, and — deliberately — captions and max_labels.

captions is never pinned in the overlay, because it is the label map and belongs to the run's class set, not to the stage. It must list every class the ground truth contains, not just the classes being trained: a class present in the ground truth and absent from captions can never be predicted, so every one of its boxes is a false negative and its objects resurface as false positives on whichever caption the model matches instead. max_labels must equal len(captions).

captions order is the label map. Grounding DINO has no class list; it assigns a detection to a class by the position of the caption token it matched. Reorder the list and every prediction is relabeled, silently and consistently — the run still exits 0, the box count barely moves, and only the per-class KPI reveals it. The order must match the one the checkpoint was trained against; the reference uses alphabetical, which is also what the ODVG labelmap emitted by the prep stage produces. Do not sort it by class frequency or by the order the user happened to list their classes in.

Nothing about this is enforced by TAO, so check it before every inference:

<skill_root>/scripts/deft_python.sh <skill_root>/scripts/verify_class_contract.py \
  --inference-spec "$INFER_SPEC" \
  --kpi-mapping "$CLASS_MAPPING" \
  --state "${RESULTS_DIR}/deft_state.json" \
  --labelmap "${RESULTS_DIR}/iter${N}/tmm/annotations/labelmap.json"

It compares the caption list against the KPI classes, the staged ODVG labelmap order, max_labels, and the run's target classes, and exits non-zero naming both sides of any disagreement. At baseline there is no staged labelmap yet, so drop --labelmap. --classes is not its replacement — it is an independent fourth source and takes the path to the pool's classes.yaml, not a class list. Pass it in every phase.

inference.color_map in the reference spec is cosmetic — it only tints images_annotated/.

Baseline inference (iter_0)

No training at baseline. Score the user-supplied zero-shot / pretrained checkpoint:

docker run --rm --name "deft_${PHASE}_infer" --gpus all --shm-size=8g --user "$(id -u):$(id -g)" $DOCKER_IDENTITY \
  -v "$WORKSPACE:$WORKSPACE" $EXTRA_MOUNTS -w "$WORKSPACE" \
  "$TAO_PYT_IMAGE" \
  grounding_dino inference -e "$INFER_SPEC" \
  results_dir="${RESULTS_DIR}/baseline" \
  inference.checkpoint="$ZERO_SHOT_CHECKPOINT" \
  inference.num_gpus="$NUM_GPUS"

Wait on the labels, the same way training does — results_dir gains the action name, so both the labels and status.json sit under inference/:

LAUNCH_MARKER="${RESULTS_DIR}/<phase>/.inference_launched"
mkdir -p "$(dirname "$LAUNCH_MARKER")" && touch "$LAUNCH_MARKER"
# ... launch the container ...

<skill_root>/scripts/deft_python.sh <skill_root>/scripts/await_stage.py \
  --newer-than "$LAUNCH_MARKER" \
  --status-json "${RESULTS_DIR}/<phase>/inference/status.json" \
  --status-contains "finished successfully"

Labels land in ${RESULTS_DIR}/baseline/inference/labels/. The same wait applies to each iteration's inference with <phase> set to iter${N}.

Also copy the user's train-spec template to ${RESULTS_DIR}/train_grounding_dino.yaml. Iteration 1 extends that copy; nothing trains from it at baseline.

Iteration train

Build the spec first. Every flag below is load-bearing: the script refuses to emit a spec that cannot train.

<skill_root>/scripts/deft_python.sh <skill_root>/scripts/prepare_val_split_for_train.py \
  --coco "<pool>/coco.json" --out "${RESULTS_DIR}/val_coco.json"

<skill_root>/scripts/deft_python.sh <skill_root>/scripts/prepare_spec_for_train.py \
  --previous-spec        "<template or assets/train_grounding_dino.yaml>" \
  --output-spec          "${RESULTS_DIR}/iter${N}/train_grounding_dino.yaml" \
  --tmm-image-dir        "${RESULTS_DIR}/iter${N}/tmm/images" \
  --tmm-odvg-file        "${RESULTS_DIR}/iter${N}/tmm/annotations/tmm_odvg.jsonl" \
  --tmm-label-map-file   "${RESULTS_DIR}/iter${N}/tmm/annotations/labelmap.json" \
  --val-image-dir        "<pool images>" \
  --val-json-file        "${RESULTS_DIR}/val_coco.json" \
  --pretrained-model-path "<config.zero_shot_checkpoint>" \
  --num-epochs "$NUM_EPOCHS" --learning-rate "$LEARNING_RATE"
FlagWhy it is not optional
--pretrained-model-pathLeft unset, training starts from no pretrained weights, reports success, and emits a model that detects nothing. The failure surfaces only at KPI, a full training run later.
--val-*Validation is mandatory and the COCO must be 0-based — see above.
--tmm-label-map-fileAlso the source of dataset.max_labels, which must equal the class count. Hardcoding it silently drops classes from captions when the target set changes size.

Then:

docker run --rm --name "deft_iter${N}_train" --gpus all --shm-size=8g --user "$(id -u):$(id -g)" $DOCKER_IDENTITY \
  -v "$WORKSPACE:$WORKSPACE" $EXTRA_MOUNTS -w "$WORKSPACE" \
  "$TAO_PYT_IMAGE" \
  grounding_dino train -e "${RESULTS_DIR}/iter${N}/train_grounding_dino.yaml" \
  results_dir="${RESULTS_DIR}/iter${N}" \
  train.num_gpus="$NUM_GPUS"

Wait on the artifact, never on a process name. pgrep -f "grounding_dino train" matches the waiting shell's own command line, so the wait never ends.

Take a launch marker first, and pass it as --newer-than. Without it a retry of a failed job is satisfied instantly by the checkpoint and success line the previous attempt left behind:

LAUNCH_MARKER="${RESULTS_DIR}/iter${N}/train/.launched"
mkdir -p "$(dirname "$LAUNCH_MARKER")" && touch "$LAUNCH_MARKER"
# ... launch training ...

<skill_root>/scripts/deft_python.sh <skill_root>/scripts/await_stage.py \
  --newer-than "$LAUNCH_MARKER" \
  --status-json "${RESULTS_DIR}/iter${N}/train/status.json" \
  --status-contains "finished successfully"

gdino_model_latest.pth is deliberately not an --artifact here: training rewrites it at every checkpoint interval, so a wait naming it returns at the first interval and the stage is read as finished several epochs early. status.json is the only artifact that appears once, at the end.

results_dir and train.num_gpus are Hydra overrides, not flags. Everything else must already be in the spec — do not add further overrides on the command line.

Never write automl_policy or a workflow: key into the spec. TAO's Hydra ExperimentConfig schema does not recognize them and the run fails at config-merge time. Plain docker run … train is already non-AutoML.

Every iteration fine-tunes the base checkpoint, not the previous one

train.pretrained_model_path stays pointed at the original base checkpoint on every iteration. It is inherited from the spec template and prepare_spec_for_train.py never touches it. That is deliberate, and it is the single most surprising property of this loop:

  • What grows across iterations is the dataset (dataset.train_data_sources gains one mined ODVG source per iteration), not the weights.

  • The previous iteration's checkpoint is used only for inference and the gap analysis that follows it — never as a training initialisation.

Do not "improve" this by chaining pretrained_model_path to iter{N-1}'s checkpoint. That converts the run into continual fine-tuning, which compounds drift across iterations and makes any mAP change unattributable — you could no longer tell whether iteration N improved because the mined data helped or because it inherited N-1's state.

Required output: a newly emitted checkpoint under ${RESULTS_DIR}/iter${N}/train/ (gdino_model_latest.pth). A non-zero exit, a TAO status of FAILURE, or a run that emits no new checkpoint is a hard stop — never run inference against a checkpoint written before the failure, and never reuse the previous iteration's checkpoint as if it were this iteration's.

Iteration inference

docker run --rm --name "deft_${PHASE}_infer" --gpus all --shm-size=8g --user "$(id -u):$(id -g)" $DOCKER_IDENTITY \
  -v "$WORKSPACE:$WORKSPACE" $EXTRA_MOUNTS -w "$WORKSPACE" \
  "$TAO_PYT_IMAGE" \
  grounding_dino inference -e "$INFER_SPEC" \
  results_dir="${RESULTS_DIR}/iter${N}" \
  inference.checkpoint="${RESULTS_DIR}/iter${N}/train/gdino_model_latest.pth" \
  inference.num_gpus="$NUM_GPUS"

Inference label format

TAO writes one KITTI-style .txt per image into inference/labels/, plus annotated images into inference/images_annotated/. Each detection line is 15 fields plus a trailing score:

<class_name> 0.00 0 0.00 <x1> <y1> <x2> <y2> 0.00 0.00 0.00 0.00 0.00 0.00 0.00 <score>

Boxes are absolute xyxy. Detections below inference.conf_threshold are already dropped at write time, so it bounds what every later stage can see: a downstream threshold composes with this one rather than replacing it, and no stage can recover a box inference did not write.

That is the reason to keep it at 0.0. The labels then carry the full curve, and gap analysis and KPI are free to pick any threshold independently — including scoring the same labels repeatedly at several thresholds, which costs a re-run of KPI rather than a re-run of inference. A non-zero value here forecloses that permanently and silently compounds with whatever a later stage applies.

Commit

# train
<skill_root>/scripts/deft_python.sh <skill_root>/scripts/commit_stage.py \
  --results-dir "${RESULTS_DIR}" --iter-label "iter${N}" --stage train \
  --execution-path skill \
  --checkpoint "${RESULTS_DIR}/iter${N}/train/gdino_model_latest.pth" \
  --training-spec "${RESULTS_DIR}/iter${N}/train_grounding_dino.yaml" \
  --duration-sec "$(( SECONDS - started ))" \
  --summary "trained iter${N}: <epochs> epochs, <N> data sources"

Use that --summary as written. Training prints val_mAP and val_mAP50 as it runs; do not carry them into the summary. They score the model against the validation split of the staged mined data, whose labels are Co-DETR pseudo-labels, so they measure agreement with the teacher rather than accuracy — and a summary is rendered into the report, where that sits beside the KPI mAP and reads like a competing accuracy figure. The loop's accuracy metric comes from kpi_analyze alone.

# inference
<skill_root>/scripts/deft_python.sh <skill_root>/scripts/commit_stage.py \
  --results-dir "${RESULTS_DIR}" --iter-label "<phase>" --stage inference \
  --execution-path skill \
  --inference-labels-dir "${RESULTS_DIR}/<phase>/inference/labels" \
  --duration-sec "$(( SECONDS - started ))" \
  --summary "inference: <N> label files"

commit_stage.py records inference_labels_dir under the phase. The next iteration's gap_analysis reads that path from state — never hardcode it.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs Python

The author says: Requires docker + nvidia-container-toolkit and one or more CUDA GPUs. Workflows declare additional requirements.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • References to credential files
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA Corporation
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/tao-run-deft-object-detection · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA Corporation or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download tao-run-deft-object-detection.zip