Optimize vision-model weights with rewards

This experimental path uses reviewed annotations to reward sampled model outputs and update the vision model itself.

Source reviewed 2026-09-23. Availability depends on your installation, permissions, and compatible runtimes. A supported path is not a guarantee of model quality or production readiness.

Outcome

A candidate only if weight-update and validation checks pass. The observed local rehearsal regressed and was withheld; no beneficial RL gain has been demonstrated.

Start here

What you need to know first

Check the inputs below before starting. If you are new, begin with the first-project guide. A dataset holds media and labels; a model produces results; a deployment makes a selected model version callable. Creating one does not create the others.

Bring these inputs

Exact ready trainable PyTorch checkpoint
Reviewed data with matching classes
Local CPU runtime

Expected output and limits

Weight-update evidence
A withheld result or an unverified candidate

Core workflow

01
Select a trainable version
Choose an exact ready model with a saved PyTorch checkpoint and the same classes as your reviewed dataset. An inference-only ONNX artifact is not enough.
02
Choose the method
Select Optimize with rewards · experimental and This machine. Reward learning is not calibration: calibration changes a confidence threshold, not model weights.
03
Inspect the attempt
Follow the bounded updates. The report records tensor changes and starting versus candidate validation reward. Invalid output, unchanged weights, or lower reward blocks publication.
04
Evaluate independently
If a candidate is saved, test it on independent reviewed data before any release. Passing a validation reward check is not proof of real-world improvement.

What this surface supports

On-policy vision-weight updates
Detection and segmentation reward
Recorded update evidence
Non-regression publication guard

Expert section

Contracts, signals, and failure modes

Use this section when you are defining acceptance criteria, automating the surface, or reviewing whether its output is safe to promote downstream.

Quality and operating signals

Changed tensor count
Gradient norms
Starting and candidate validation reward

Common failure modes

Missing trainable weights
Changed class schema
Validation reward regression

Expert release checklist

Inputs and dependencies are pinned to immutable versions.
Acceptance metrics include critical classes and operating slices.
Failure, retry, cost, and rollback behavior are understood.
The resulting artifact has an owner and a downstream review path.

Engineering safeguards

Experimental, not guaranteed improvement
Original model and deployment remain unchanged
Local CPU only