AIVA: van duizenden detecties naar een handvol situaties

AIVA brengt camerabewaking terug van duizenden detecties naar een handvol onderbouwde situaties: in 24 uur beeld van 10 camera's bleven er 10 over die de operator moest zien.

Camerabewaking levert vandaag vooral werk op. Detectieregels genereren duizenden meldingen, waarvan maar een klein deel ertoe doet. Het aantal camera's groeit sneller dan het aantal centralisten dat ze kan volgen. En elke camera vraagt eigen zones, tijdvakken en regels voor wat normaal is; dat instellen schaalt slecht.

In dit artikel leggen we uit hoe AIVA werkt: de drie analyselagen, de agents die de diepe analyse doen, de pipeline eronder en waarom de kosten meebewegen met wat er gebeurt in plaats van met het aantal camera's.

Drie analyselagen, elk duurder en slimmer dan de vorige

AIVA analyseert beeld in drie lagen. Elke laag is langzamer en duurder per beeld, maar ziet ook minder beelden, omdat de laag ervoor al het grootste deel heeft weggefilterd. Zo komt het zware werk alleen terecht bij beelden waar iets speelt.

1. Traditionele detectie (ongeveer 10 ms per beeld). Bewegingsdetectie en objectdetectie kijken naar elk beeld: beweegt er iets, is het een persoon of een voertuig, en waar staat het? Deze laag is snel en goedkoop en draait continu op elke camera.
2. Snelle beeldanalyse, "System 1" (ongeveer 150 ms per beeld). Alleen beelden met activiteit gaan door. Een visueel model toetst ze aan regels die bij de situatie horen: hoort deze persoon hier op dit tijdstip, staat dit voertuig op een plek waar het niet mag?
3. Diepe analyse (ongeveer 15 seconden per venster). Wat de tweede laag verdacht vindt, wordt bekeken als een venster van beelden over tijd en over camera's heen. Hier ontstaan de context, het patroon en het rapport.

In de pilotdata van 24 uur over 10 camera's verwerkte de eerste laag 2,8 miljoen beelden. Daarvan gingen er 62.000 (ongeveer 2%) naar de snelle analyse, en 420 vensters naar de diepe analyse. Tien situaties werden doorgezet naar de operator.

De diepe analyse: een team van agents dat het draaiboek volgt

In de derde laag werkt niet één model, maar een klein team van agents met elk een eigen rol. Ze toetsen een situatie aan het draaiboek van de klant, zoals een ervaren centralist dat zou doen.

• Orchestrator. Ontvangt het verrijkte event uit de tweede laag en bepaalt welk draaiboek geldt, welke camera's erbij horen en welk tijdvenster bekeken moet worden.
• Protocol-agent. Haalt het draaiboek van de klant erbij en controleert welke aanpak daarin staat.
• Analyse-agent. Beoordeelt de beelden, eerdere passages van dezelfde persoon of hetzelfde voertuig, en wat aangrenzende camera's zagen.
• Verificatie-agent. Is het bewijs niet sluitend, dan gaat de vraag terug naar de orchestrator voor extra beelden of een ander tijdvenster.
• Rapportage-agent. Zet de conclusie, de aanbevolen actie en de bewijsbeelden in een rapport voor de operator.

De operator beoordeelt het rapport: bevestigd of vals alarm. Dat oordeel gaat terug het systeem in en scherpt de regels aan, zodat dezelfde valse melding de volgende keer eerder wordt weggefilterd.

De pipeline: losse services rond Kafka, dus schaalbaar per stap

Onder de drie lagen ligt een pipeline van losse services die via Apache Kafka met elkaar praten. Elke stap kan apart worden opgeschaald, zonder dat de rest hoeft te veranderen.

1. Opvangen. Camerastreams komen binnen via RTSP. Een frame publisher pakt beelden op een ingestelde framerate, slaat het beeld op in de database en zet alleen een lichte verwijzing op Kafka. Over de berichtenbus gaan dus geen zware beelden, alleen kenmerken en verwijzingen.
2. Voorfilteren. De eerste laag (beweging en objectdetectie) leest die verwijzingen, beoordeelt het beeld en zet het resultaat erbij. Beelden zonder activiteit gaan niet verder naar de taalmodellen.
3. Bundelen. Apache Flink bundelt de beelden per camera tot korte reeksen, zodat een model een fragment over tijd ziet in plaats van losse foto's. Meerdere camera's kunnen worden samengevoegd tot één beeld, zodat het model ook verbanden tussen camera's kan leggen.
4. Analyseren en melden. Het visuele model analyseert de reeksen, de agents maken er een situatie van, en een aparte service zet het resultaat om in een melding voor de operator.

Schalen gaat per stap. De workers van een stap delen het werk via Kafka: komen er camera's bij, dan zet je meer workers neer op de stap die het zwaarst belast wordt. Bij elke stap ligt vast hoe ze omgaat met storingen: een bericht wordt pas afgevinkt als het verwerkt is, en een camera die wegvalt wordt opnieuw opgepakt. De cijfers in dit artikel komen uit 24 uur beeldmateriaal van 10 camera's dat zo door de hele pipeline is gegaan.

Kosten volgen de incidenten, niet het aantal camera's

De dure rekenkracht zit in de taalmodellen, en die draaien alleen waar iets gebeurt. Daardoor groeien de kosten mee met het aantal incidenten, niet met het aantal camera's.

• De eerste laag draait op elke camera, op gewone hardware en zonder tokens. Dit is het enige deel dat meegroeit met het aantal camera's, en het is per beeld het goedkoopst.
• De snelle analyse ziet ongeveer 2% van de beelden. Hier worden de eerste tokens verbruikt, voor een korte toets van ongeveer 150 ms per beeld.
• De diepe analyse gebruikt de meeste tokens per keer, maar draaide in de pilotdata 420 keer in 24 uur, over 10 camera's: minder dan twee keer per camera per uur.

Voor een rustig object betekent dit lage, voorspelbare kosten. Op een drukke nacht stijgt het verbruik, maar dan levert het systeem ook het meeste op: precies op dat moment haalt het de situaties eruit die een operator anders zou missen.

De prijsopbouw volgt dezelfde logica. Dekking, de detectie en snelle analyse op elke camera, is een vast bedrag per groep camera's. De diepe analyse van incidenten valt binnen een afgesproken hoeveelheid, en continue diepe analyse tijdens een lopend incident of evenement wordt per uur afgerekend, alleen als die wordt ingezet.