Vision-agent

Problem

Meget forretningssoftware har ingen API. Gamle ERP-skærme, offentlige portaler, fjernskriveborde og leverandørværktøjer kan kun bruges, som et menneske bruger dem: ved at se på skærmen og trykke på taster. Det gør dem til den sværeste del af ethvert automatiseringsprojekt. Jeg ville vide, hvor langt en lille model på en almindelig pc kan komme ved bare at se på skærmen, og hvad der skal til for at lade den handle sikkert.

Hvad jeg byggede

Tre versioner, der hver tester én idé, på et browserbaseret, turbaseret spil. Et spil er en god testbænk: skærmen ændrer sig hele tiden, reglerne er klare, og et forkert træk koster ingenting.

Observatøren kigger kun. Et første gennemløb sender ét helt skærmbillede til en lokal vision-sprogmodel, der finder de dele af skærmen, der betyder noget, og returnerer deres koordinater. Derefter beskærer hvert kig kun de områder til ét lille billede, og modellen rapporterer tilstanden som JSON, cirka én gang i sekundet.

Agenten handler også. Den finder spilområdet, og ved hvert kig returnerer modellen tilstanden og én foreslået handling, et tastetryk eller et klik, som JSON. Klik mappes tilbage fra det beskårne billede til rigtige skærmkoordinater. Handling er slået fra, når den starter: den kører i observatørtilstand, indtil jeg slår udførelse til, holder en minimumspause mellem handlinger og stopper øjeblikkeligt, hvis musen skubbes op i et hjørne.

Læreren dropper sprogmodellen. Den kobler sig på browseren via Chrome DevTools, læser tallene på skærmen med OCR, omsætter dem til en simpel tilstand og lærer, hvilken tast der skal trykkes på, med Q-learning, belønnet for skade givet og straffet for skade taget. Det, den lærer, gemmes mellem kørsler.

Tankerne bag

Designet følger samme regel som mit andet arbejde: brug modellen, hvor der er brug for forståelse, og faste regler, hvor tallene skal være rigtige. Vision-modellen er god til det åbne spørgsmål om, hvad der er på skærmen, og hvad der skal gøres nu. At læse et præcist tal af en bjælke gøres bedre med OCR og et mønstertjek, som er billigt og enten matcher eller fejler.

At se på hele skærmen én gang og derefter kun på de dele, der betyder noget, holder hvert kig lille, og det er det, der gør en 9B-model på en hjemme-pc hurtig nok til at følge med. At sammenligne modellens beslutninger med en lært politik viser afvejningen: modellen kan handle fornuftigt fra første sekund, men er langsom, mens reinforcement learning er hurtig og billig pr. skridt, men kun så god som den tilstand, den får.

Status

Alle tre versioner kører fra ende til anden på min egen pc. Observatøren rapporterer skærmens tilstand cirka én gang i sekundet, agenten spiller sig gennem skærme på egen hånd, når den er slået til, og læreren bygger op og gemmer sin egen tabel over, hvad der virker.

Hvor det er nyttigt, og hvad der er næste skridt

Den samme løkke (kig, foreslå, handl kun gennem en lås) passer til arbejde, hvor skærmen er den eneste grænseflade:

Dataindtastning i ældre systemer, hvor agenten læser et dokument eller en skærm og udfylder et andet system, der ikke har nogen API.

Overvågning, med observatøren alene: den holder øje med et dashboard, en kø eller en produktionsskærm og giver besked, når noget ændrer sig, uden nogensinde at røre det.

Test, hvor den går gennem en applikation, som en bruger ville, og rapporterer, hvad den ser.

Til det er de næste skridt en log over hvert kig og hver handling til revision, en fast liste over tilladte handlinger pr. opgave, et bekræftelsestrin før alt, der skriver data, og at køre observatøren på en rigtig forretningsskærm, før agenten får lov at handle på en.