# After Training

You are now close to deploying your model — it’s the point where you turn “numbers” into a model that actually works in your real workflow.

***

## 1) Find Your Training Output (weights + config + names) <a href="#id-1-find-output" id="id-1-find-output"></a>

When training ends, the log/status messages show where outputs are written.

In AugeLab Studio, training outputs are typically created in a folder named:

XXX\_config

right next to your dataset folder (XXX is your dataset folder name).

Typical structure:

```
XXX_config/
    XXX.names
	XXX.cfg
	backup/
		XXX_last.weights  (if available)
		XXX_best.weights  (if available)
```

At minimum, you should keep these together:

* Weights file: `.weights` (sometimes there is also a best vs last style file)
* Config file: `.cfg`
* Class names file: `.names`

{% hint style="warning" %}
Do not rename/reorder classes in your `.names` file after training unless you also remap label IDs. Class order must match label IDs.
{% endhint %}

<details>

<summary>Which weights should I use: best vs last?</summary>

If your training reports mAP during training, many YOLO/Darknet workflows keep a “best so far” checkpoint.

* Use best when mAP improved and then later dropped (overfitting).
* Use last if training ended while mAP was still improving and stable.

If you don’t have a “best” file, pick the final weights first, then validate.

</details>

***

## 2) Validate the Model Before You Deploy <a href="#id-2-validate-before-deploy" id="id-2-validate-before-deploy"></a>

Before you wire the model into production logic, do a fast validation pass.

Recommended validation sets:

* Validation set: 30–100 images that represent real life (good + bad lighting, blur, clutter, edge cases)
* Short videos or images: short video from the real camera (if you will deploy on a fixed camera)

What you are looking for:

* The model detects the right object consistently
* The boxes are “good enough” for your logic (not necessarily perfect)
* False positives are acceptable (or can be filtered)
* Rare-but-important cases are detected

{% hint style="warning" %}
High mAP can still fail in production if your validation split was too small or too clean. The validation set / real footage check is what prevents that.
{% endhint %}

***

## 3) Load the Model Into a Studio (Inference) <a href="#id-3-load-into-graph" id="id-3-load-into-graph"></a>

In AugeLab Studio, the usual next step is to build (or update) a `.pmod` scenario that runs inference.

### A) Use “Object Detection - Custom” (recommended) <a href="#id-3a-use-object-detection-custom" id="id-3a-use-object-detection-custom"></a>

Use this node when you want to run your own YOLO/Darknet-trained model inside a workflow.

Workflow:

1. Add Object Detection - Custom to your graph (AI Applications category).
2. In the block UI:
   * Click Open Weight File and select your `.weights`
   * Click Open Config File and select your `.cfg`
   * Click Open Class File and select your `.names`
3. Select which classes you want to detect (checkbox list).
4. Set Confidence Threshold (start around 0.5–0.8 and tune).
5. Connect an image source to the block input and preview the output image.

Outputs you can use in your logic:

* Output image with drawn detections
* Object Count
* Object Locations / Sizes
* Object Classes
* Rectangles

{% hint style="info" %}
If “Object Detection - Custom” is not available, your build may not have CUDA/OpenCV DNN support enabled. Try the CPU block below, or install the required modules from the Module Downloader (see [ai-training.md](/key-features/train-custom-ai-models-with-training-window.md)).
{% endhint %}

### B) Use “Object Detection - Custom (CPU)” (fallback) <a href="#id-3b-use-object-detection-custom-cpu" id="id-3b-use-object-detection-custom-cpu"></a>

Use this block when you want the same workflow but without GPU acceleration.

* It uses CPU inference, so it will be slower.
* The setup is the same: weights + cfg + names.

***

## 4) Tune Thresholds (what actually matters) <a href="#id-4-tune-thresholds" id="id-4-tune-thresholds"></a>

Most “deployment quality” improvements come from threshold tuning, not from running training longer.

Start with these practical steps:

* Increase confidence threshold if you see too many false positives.
* Decrease confidence threshold if you miss objects.
* Evaluate on the golden set and at least one real camera clip.

{% hint style="warning" %}
Do not tune on a single image. Always tune on a small set. Otherwise you will “overfit your threshold” to one scene.
{% endhint %}

***

## 5) Package for Sharing / Reproducibility <a href="#id-5-package" id="id-5-package"></a>

If you want the model to be usable later (or by someone else), package it intentionally.

Recommended folder layout:

```
my_model_release/
	model.weights
	model.cfg
	classes.names
	README.txt
	validation_set/   (optional)
```

What to write in the README:

* What dataset the model was trained on (version/date)
* What classes mean (if ambiguous)
* Recommended confidence threshold range
* Known failure cases (glare, tiny objects, extreme occlusion)

{% hint style="info" %}
If your `.pmod` scenario references these resources, consider keeping them as relative project resources so the scenario remains portable. See also: [headless-studio](/key-features/headless.md) (missing-resource load behavior).
{% endhint %}

***

## 6) If It Fails in Production (what to do next) <a href="#id-6-if-it-fails" id="id-6-if-it-fails"></a>

When a model fails after deployment, the fix is usually one of these (in this order):

1. Collect the failures (save frames that show the miss/false-positive)
2. Label them correctly
3. Retrain or fine-tune with the new data

This is how models get robust.

<details>

<summary>Common failure modes and the fastest fix</summary>

* False positives on background texture → add negatives from that exact environment
* Misses on small objects → increase input size (if GPU allows) and collect more small-object examples
* Misses under glare/blur → add those cases intentionally to the dataset (do not rely only on augmentation)
* Boxes are consistently too loose/tight → fix annotation style consistency, then retrain

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.augelab.com/key-features/train-custom-ai-models-with-training-window/after-training.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
