Get startedModels · Experimental · local CPU
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-16. 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
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.
Choose the method
Select Optimize with rewards · experimental and This machine. Reward learning is not calibration: calibration changes a confidence threshold, not model weights.
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.
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