SWITCH

The problem

Object detectors are benchmarked on clean data and deployed onto dirty data. In production, input quality drifts — a camera lens fogs, bitrate drops, lighting changes, a sensor ages — and detection accuracy degrades with it. The usual response is to pick the largest model you can afford and accept the cost, or pick a fast one and accept the misses.

Both are static answers to a dynamic problem. Model variants have genuinely different accuracy/latency trade-offs, and which trade-off is correct depends on conditions that change at runtime.

Approach

SWITCH treats detector selection as a control problem and closes a MAPE-K loop — Monitor, Analyse, Plan, Execute over a shared knowledge base — around a measurable signal. Model lifecycles are managed through the UPISAS framework for self-adaptive systems, with data processing synchronised across distributed containers.

• Monitor. Every incoming frame is scored with BRISQUE, a no-reference image quality metric — no pristine reference image required, which is the whole point, because in production there isn't one.
• Analyse. Scores feed an N-size buffer rather than being acted on frame by frame. This is the difference between a working controller and a useless one: without smoothing, a momentary quality spike triggers a model swap, and the system spends its time chattering between variants instead of detecting anything.
• Plan. Five YOLOv5 variants, from Nano to X-Large, were profiled and sorted into performance tiers by how well each holds up under noise — so the mapping from quality regime to model is grounded in measured robustness rather than assumed to track model size.
• Execute. The serving layer swaps in the chosen variant.

Deployment

Built as Dockerised microservices behind a FastAPI interface handling asynchronous image ingestion, so the quality assessor, the adaptation controller and the inference workers scale and fail independently, and model swaps happen without stalling the intake path.

• Telemetry — quality scores, chosen variant, latency, detection counts — streamed into Elasticsearch.
• Kibana dashboards for inspecting switching behaviour after the fact, which is how you actually find out whether an adaptation policy is sensible or just busy.
• Containerised end to end, so an experiment is a compose file rather than a setup ritual.

Results

Benchmarked against standard rate-based adaptation — strategies that switch on a fixed schedule or on throughput rather than on input quality — the quality-driven approach held higher detection confidence while using measurably less compute.

The reason is straightforward once stated: rate-based adaptation has no idea whether the current input is hard or easy, so it either over-provisions on clean frames or under-provisions on degraded ones. Reserving the heavyweight variants for the frames that actually need them buys accuracy and saves compute at the same time, rather than trading one against the other.