Computer-vision system for predatory wildlife identification

The trigger

The conservation organization had accumulated about 3TB of camera-trap footage over 18 months. They could afford to review roughly 10% of it. The reviewers were specialist conservation biologists at $100+/hour — pulling them off field work to watch night-IR video at 4× speed was the wrong use of their time, but funder reporting requirements meant somebody had to do it.

The funder pressure was the trigger. A multi-year grant renewal required reporting on predator-presence numbers across the whole monitored region, not extrapolated from a 10% sample. Without full-coverage data, the renewal was at risk. The grant was the organization's largest single funding source.

The harder problem underneath: one of the predator species the organization was monitoring is visually similar to a large co-occurring herbivore. Volunteer reviewers misidentified them in roughly 20% of frames. The grant's predator-presence number would have been inflated if we just ran more eyeballs at the problem without addressing the misidentification rate. The Conservation Director was specific: "I need accurate numbers, not just more numbers."

The internal data team had attempted two prior ML approaches. One used a generic image-classification model fine-tuned on a small labeled set; it hit 76% accuracy and stalled because of training-data scarcity. The other tried a commercial wildlife-ID API; it returned "large carnivore" for most predator frames without species-level resolution.

The week-one discovery

Week zero we mapped the data. 47 camera-trap units across 8 sites, averaging 1.2GB per unit per day. Footage quality varied wildly: night IR vs day color vs partial-frame captures vs blown highlights at sunrise. Some cameras had occlusion problems (grass growing in front of the lens in late summer); some had vibration from being mounted on living trees.

Expert review accuracy on a holdout set was 92%. That number startled the team — even the specialists got it wrong 8% of the time. The accuracy gap meant our model didn't need to beat humans on every frame; it needed to be reliably above 88% with the false-positives flagged for human review.

The labeled training data we needed didn't exist as a single resource. Public datasets had general carnivore labels but not species-specific labels for our predator. The organization had ~6,000 expert-labeled frames from prior research. We supplemented with about 34,000 frames from public conservation datasets (eMammal, iWildCam, Snapshot Serengeti) filtered to the relevant predator + herbivore species. Total labeled training set: ~40,000 frames.

The hardest discovery: visual similarity wasn't uniform. The predator and the herbivore look similar in frontal poses at typical camera-trap distance, but distinctly different in profile or partial-frame. That fact would shape the architecture.

The architecture decisions

**Ensemble vs single foundation model.** A single fine-tuned ResNet-50 hit 89% on our holdout set. Tempting to ship. We tested an ensemble of three models (a fine-tuned ResNet for general carnivore detection, a specialist binary classifier for predator-vs-similar-herbivore, and an EfficientNet for fine-grained features like fur pattern and ear shape). The ensemble hit 93%. The 4-point gap was the engineering decision: ensemble for the per-species-specialist accuracy story, accept the 3× inference cost.

**Custom preprocessing vs feed-raw-frames.** Camera-trap data has well-known degradations: night-IR exposure variations, camera shake on tree mounts, partial-frame captures when animals move fast. We built a preprocessing layer with lighting normalization (CLAHE on IR frames), frame stabilization (optical flow on adjacent frames in a clip), and occlusion detection (mask out grass / branch overlay). Preprocessing added 4 points of accuracy on the holdout — measurably more than any single model architecture change.

**PyTorch vs TensorFlow.** The client's data team was PyTorch. Our team was historically more TensorFlow but the maintenance hand-off mattered. We went with PyTorch. We had to retool one of our internal training pipelines to PyTorch in week 1, which cost us 2 days, but the post-handoff transition was clean.

**Confidence-thresholded human review.** Two options: ship a fully-automated pipeline that returns a species label for every frame (with the implicit "trust the model"), or ship a hybrid where low-confidence predictions go to a human review queue. We argued for the hybrid because of the 8% expert-baseline error rate — even a perfect model would still be wrong on the genuinely hard frames where humans were also wrong. The confidence-flagged review queue became the training-data flywheel: human corrections feed back as new labeled data, model accuracy improves over time. This was the highest-leverage architecture decision of the engagement.

**Sagemaker vs self-managed.** Sagemaker for training (Spot instances brought cost down ~70% on the longer training runs); Lambda for inference at modest scale. We documented the upgrade path to dedicated GPU instances for the day inference volume justifies it.

The build

Weeks 2-5 ran daily training cycles. First-generation models trained on 40,000 frames hit 86% on the holdout. Generation two added the preprocessing layer and hit 90%. Generation three was the ensemble — 93%.

The four architecture iterations were instructive. We tried a transformer-based vision model (ViT-Base) in iteration two; it tied the ResNet on accuracy but trained 4× slower and didn't justify the cost at our data scale. We tried a contrastive-learning pretraining approach in iteration three; it gave a small boost (~1 point) but added an entire pretraining pipeline the client's team would have to maintain. We kept it simple: fine-tuned ResNet ensemble with the preprocessing layer, which the data team can retrain and redeploy without exotic infrastructure.

Week 5 surprise: classification accuracy was 91.2% on the holdout but the human-review queue still rejected 4% of high-confidence predictions. Investigation found a recurring camera angle (one unit was mounted slightly tilted, putting the animal lower in frame than other units) that was over-represented in training and led to mis-calibrated confidence scores. We added a "production-distribution-shift" detector that flagged frames whose feature distribution differed from the training set; those frames got auto-routed to human review regardless of confidence score.

Week 6 was confidence-threshold tuning. We swept the threshold from 0.5 to 0.95 against the holdout and found the sweet spot at 0.78: at that threshold, the auto-accepted predictions had 96% accuracy (better than human expert review at 92%) and the human-review queue absorbed ~22% of frames. The volume was tractable — the conservation biologists could review 22% of frames in their normal time budget.

The cutover

Week 7: the pipeline deployed behind their existing S3 footage-drop. Camera-trap units uploaded daily as before. The pipeline ingested, preprocessed, ran the ensemble inference, and emitted three outputs per frame: predicted species, confidence score, and a flag for human review if confidence was below threshold OR the production-distribution-shift detector fired.

By week 8 the full 3TB backlog had been processed. The conservation biologists were reviewing only the ~22% of confidence-flagged frames — about 660 hours of work versus the 3,000+ hours full manual review would have taken. The grant-reporting deadline came in week 10. The report shipped with full-coverage data for the first time in the organization's history.

Ninety days later

Ninety days post-handoff: the human-flagged retraining loop has moved overall accuracy from 91.2% to 94.8%. The mechanism is simple — every week, the previous week's human-flagged frames feed back into the training set as new labels. The data team runs a retraining cycle monthly. Each cycle has produced 0.3-0.5 points of accuracy improvement, exactly as we'd modeled.

Full-coverage reporting is now feasible for every grant cycle. The Conservation Director's quote — "we went from sampling footage to processing all of it" — is operational reality. The grant was renewed.

Infrastructure costs settled at ~$2,400/month at current volume (training + inference). Training is the larger line item because the team is on a monthly retrain cadence. Inference is a flat ~$400/month thanks to Sagemaker's pricing economics on batch endpoints. Compared to the alternative — $300K+/year for additional specialist reviewer hours — the math closed in week 1.

What we'd do differently

We should have built the production-distribution-shift detector earlier. It was a week-5 hotfix; it should have been a week-2 design item. Training data distribution always drifts from production data distribution. Building the detector as a first-class artifact makes the system robust against this from day one.

The decision to ship as an ensemble of small models instead of a single large model was correct but felt unusual. We'd defend it again on any vision engagement where the client team will own retraining post-handoff: smaller models are tractable for non-MLOps teams to retrain. A large foundation model would have given us 1-2 more accuracy points but locked the client into a specialist-only retraining workflow.

The confidence-thresholded human review pattern is the highest-leverage thing we shipped. We'd ship it on every classification engagement where the cost of false positives is non-trivial. The flywheel effect (human corrections → retraining → better accuracy → fewer human corrections) compounds over time and is the dominant story 6 months in.