Semi-supervised learning is one of those areas where the theoretical benefit is easy to state and the practical implementation is hard to get right. The promise: you have a large pool of unlabeled data and a small labeled set, and the model can bootstrap from both. The reality: without careful implementation choices, the pseudo-labels the model generates on unlabeled data are noisy enough to degrade training rather than improve it.
For small ML teams without the engineering capacity for a full semi-supervised pipeline, the most practical entry point is not running a full semi-supervised training loop. It's using your partially-trained model as a pre-labeler to accelerate manual annotation on your unlabeled pool. This pseudo-labeling approach gives you most of the annotation efficiency benefit with a fraction of the implementation complexity.
The core loop
The working approach has four stages. First, label a small seed set manually: 2,000 to 5,000 frames depending on your class count and visual complexity. This needs to be high-quality, human-reviewed annotation, not a quick pass. Train your initial model on this seed set.
Second, run your trained model on a larger unlabeled pool and generate pseudo-labels. Filter by confidence: keep only the predictions where the model is above a threshold you've calibrated to correspond to roughly 88 to 92% accuracy on your seed set validation split. These high-confidence pseudo-labels become the next annotation batch.
Third, route the high-confidence batch through your annotation tool as pre-labeled frames. Annotators correct rather than draw from scratch, using the model's predictions as a starting point. This is where the efficiency gain shows up: frames that needed two minutes to label from scratch take 30-45 seconds to correct from a reasonably accurate pseudo-label.
Fourth, add the corrected frames to your labeled set, retrain, and repeat. Each iteration produces a model with more labeled data that generates better pseudo-labels on the next unlabeled batch.
What breaks this approach
The most common failure mode is setting the confidence threshold too low. A 0.6 confidence pseudo-label on a five-class detection model is often wrong. Adding large quantities of wrong pseudo-labels to your training set creates a confirmation loop where the model gets better at the wrong answer, not the right one. The threshold calibration work described in the confidence calibration article is the prerequisite for pseudo-labeling to work reliably.
The second failure mode is class imbalance in the pseudo-labeled pool. If your model was trained on a seed set that underrepresents rare classes, it won't generate confident pseudo-labels for those classes. The pseudo-labeling loop preferentially adds frames for well-represented classes and starves the rare class categories. Monitor the class distribution of your pseudo-labeled additions each cycle and supplement with targeted manual labeling on underrepresented categories.
When to use active learning instead
Pseudo-labeling works well when your unlabeled pool has high similarity to your seed set. When you have genuinely new scene types or rare events in the unlabeled pool, active learning is a better use of limited labeling budget. Active learning queries the model for frames it's uncertain about, concentrating human attention on exactly the distribution gaps that pseudo-labeling would skip.
In practice, most small teams use both in combination: active learning to identify the hard cases and distribute labeling budget to where it creates the most model improvement, and pseudo-labeling to accelerate the labeling of the confident cases at scale. The combination gives you coverage on both the long tail and the bulk distribution.
Managing pseudo-label quality over iterations
The quality of pseudo-labels improves as the labeled set grows, but that improvement is not linear. Early iterations with a seed model trained on 2,000 to 3,000 frames produce pseudo-labels that require significant correction. Iterations three through five, after the labeled set has grown to 8,000 to 12,000 frames, typically produce pre-labels that need only minor adjustments on the majority of frames. The iteration where pseudo-labeling starts to save more time than it costs to review is not iteration one; it's usually iteration two or three once the model has seen enough diversity to generalize.
Track the average correction time per frame across iterations. If it's not decreasing, the pseudo-labeling loop is not compounding, and you should investigate whether your confidence threshold is calibrated correctly or whether the unlabeled pool is distributing shifted data that the seed model can't generalize to.
Avoiding pseudo-label confirmation bias
The structural risk in pseudo-labeling is that errors in the seed model get amplified rather than corrected. If your seed model consistently misclassifies a particular object under certain lighting conditions, the high-confidence predictions it generates in those conditions will reflect that misclassification, and annotators reviewing pre-labeled frames may accept the wrong label at a higher rate than they'd catch it from scratch, because the pre-label anchors their judgment.
The mitigation is a separate held-out validation set that's never used as a source of pseudo-labels. After each retraining iteration, evaluate the model on the validation set and compare per-class accuracy metrics. If a class is getting worse on the validation set while pseudo-labeling for that class is nominally proceeding, it's a signal that pseudo-label confirmation bias is active for that class and targeted human review is needed before the next iteration adds more pseudo-labels for it.
Infrastructure requirements for a small team
A four-iteration pseudo-labeling cycle for a 20,000-frame target dataset requires the following: a GPU for inference (a single mid-range GPU runs inference on 20,000 frames in under an hour), an annotation tool that accepts pre-labeled batch uploads, a labeled data storage convention that tracks which iteration each frame was labeled in, and a retraining job that runs on a weekly cadence. None of these require significant infrastructure investment beyond what a small ML team doing standard object detection work would already have. The bottleneck in practice is almost always the annotation review throughput rather than the engineering infrastructure, which makes the correction workflow efficiency -- how fast annotators can review pre-labeled frames versus label from scratch -- the primary lever on cycle time.
Start your annotation pipeline
