Spil- og robotbranchen fik styr på upålidelige autonome enheder for tyve år siden. De tegnede vejene på forhånd. Det er værd at vide, før man køber en AI-agent. Men der findes en form mere, og den passer bedre til den måde, arbejdet faktisk kommer ind i en lille virksomhed: én ting ad gangen og ofte med dage imellem.
I Løkken hængte sig selv skrev jeg om orkestrering og koreografi som de to former, der er tilbage, når den simple agentløkke ikke holder. I denne uge faldt jeg over et lille Rust-bibliotek, Bonsai, som minder om, at der findes en tredje, og at den er ældre end begge. Den kommer fra robotter og computerspil og hedder et behavior tree, et adfærdstræ.
Jeg bruger ét eksempel hele vejen, så forskellene kan ses. En kundemail kommer ind. Den skal sorteres, der skal skrives et udkast til svar, en medarbejder skal godkende det, og så skal det sendes. En model er god til de to første trin. Den skal ikke selv trykke send.
Træet: Vejene er tegnet på forhånd
En fjende i et computerspil skal virke levende, men den må aldrig gøre noget, spildesigneren ikke har forudset. Løsningen blev et træ. Hver gren er en handling, og hver handling svarer kun én af tre ting: Lykkedes, fejlede eller er stadig i gang. Resten bestemmes af, hvordan grenene er sat sammen.
Bonsai har de klassiske byggeklodser. En sekvens kører trinene i rækkefølge og stopper ved første fejl. Et valg prøver alternativerne et ad gangen, indtil ét lykkes. Dertil kommer betingelser, løkker, tidsgrænser og grene, der kører samtidig.
Kundemailen ser sådan ud som træ: Sorter mailen. Skriv et udkast. Vent på godkendelse, højst to dage. Send. Fejler sorteringen, går mailen til en medarbejder. Løber tiden ud, får chefen besked.
Modellen sidder i to blade. Den kan svare forkert, og så går træet den vej, der er tegnet for fejl. Men den kan ikke finde på et trin, der ikke er tegnet. Det er hele pointen, og det er også et værn mod prompt injection: En kundemail, der beder modellen sende kundelisten til en fremmed adresse, kan få et blad til at fejle. Den kan ikke skabe den gren, der sender noget.
Træet har to svagheder. Den første er, at det gennemløbes igen og igen. Et spil spørger træet mange gange i sekundet, hvad der skal ske nu, og det giver mening, når fjenden står foran spilleren. Det giver mindre mening, når man venter to dage på en godkendelse. Den anden er, at træet kun ved, hvor sagen står, så længe programmet kører. Det er tænkt til en robot, der løser en opgave nu, ikke til en sag, der skal overleve en genstart på fredag.
Dirigenten: Nogen vælger næste skridt
Orkestrering er den form, de fleste AI-agenter sælges i. En motor kender forløbet og kalder trinene. I den ene udgave er motoren en graf, som et menneske har tegnet. Så minder det om træet, bare med bedre hukommelse, fordi de seriøse motorer skriver hvert trin ned og kan genoptage efter et nedbrud.
I den anden udgave er dirigenten selv en model. Den får en liste over værktøjer og bestemmer, hvilket der skal bruges nu. Det er den form, der ser mest imponerende ud i en demo, og den kan ingen tegne på forhånd. Det kan være det rigtige til en opgave, der virkelig er åben. Det er sjældent det rigtige til en kundemail.
Dansen: Hver del reagerer på det, der står i loggen
Den tredje form har jeg bygget flere af mine egne systemer på i år. Den hedder koreografi, og værktøjet er cross.stream, forkortet xs.
xs er en hændelseslog. Alt, hvad der sker, skrives i bunden af en lang liste, og intet bliver overskrevet. Ved siden af loggen kører små programmer, som xs kalder aktører. En aktør lytter efter bestemte slags hændelser, gør sit arbejde og skriver en ny hændelse. Det er hele mekanikken.
Kundemailen bliver til fire små dansere. Den første skriver «mail modtaget». Sorteringen lytter efter netop det, spørger modellen og skriver «mail sorteret som reklamation». Udkastet lytter efter sorterede mails og skriver «udkast klar». Så sker der ingenting, indtil medarbejderen trykker godkend på telefonen, og det bliver også en hændelse. Afsenderen lytter efter godkendelser og sender.
Ingen af dem kender hinanden. Ingen af dem spørger, om der er sket noget. De sover, indtil hændelsen kommer, og venter derfor gratis hele weekenden. Det er præcis den forskel, et ja på telefonen gjorde for mine egne udgivelser.
Hvad dansen gør bedre end træet
Tre ting.
Den overlever. Loggen ligger på disken. Genstartes maskinen, læser xs loggen igen, og aktørerne fortsætter, hvor de slap. Et træ husker sin plads i hukommelsen. En log husker den på disken.
Den kan vokse uden at blive skrevet om. Vil økonomi have besked om alle reklamationer over 10.000 kroner, skriver man en ny aktør, der lytter efter sorterede mails. Intet eksisterende ændres. I et træ skal grenen sættes ind et bestemt sted, og så skal hele træet testes igen.
Den står til regnskab. Hvert modelkald, hvert svar og hver godkendelse står i loggen i den rækkefølge, de skete. Da jeg lod en model bygge sine egne værktøjer, lå der efter et døgn 416 hændelser, og jeg kunne se præcis, hvad den var blevet bedt om, hvad den svarede, og hvad hvert kald gav. I xs er koden i øvrigt selv en hændelse, så man også kan se, hvilken version af en aktør der kørte, da noget gik galt.
Hvad træet gør bedre end dansen
Det skal siges lige så tydeligt, for det er her, koreografi plejer at blive solgt for hårdt.
Træet kan tegnes, og tegningen er sand. I dansen findes forløbet kun som summen af, hvem der lytter efter hvad. Spørger nogen, hvor en sag står, skal svaret samles fra loggen. Det kan xs godt, fordi hændelserne er ordnet efter emne, så hele historien for én sag kan læses på én gang. Men det er et svar, man skal bygge.
Træet kan ikke gå i ring. To aktører, der reagerer på hinandens hændelser, kan sende bolden frem og tilbage uden ende. Ingen har tegnet ringen, fordi ingen har tegnet noget.
Det, der i dansen svarer til træets tegnede veje, er et lukket ordforråd. Man bestemmer på forhånd, hvilke hændelser der overhovedet kan ske, og alt andet afvises, før det skrives. Modellen kan så kun skrive «sorteret som reklamation» eller «sorteret som spørgsmål». Den kan ikke skrive «send kundelisten». Værnet sidder ikke i grenene, men i ordene. Det er en svagere garanti end træets, fordi den intet siger om rækkefølgen. Men den er der, og den kan læses.
Man ender med lidt af hver
I praksis er det sjældent enten-eller. Et kort, fast forløb, hvor rækkefølgen betyder alt, kan sagtens være et lille træ inde i én aktør. Dansen bestemmer, hvornår det sættes i gang, og loggen husker, hvad det gav. Det er hele idéen bag det, der kaldes compound AI systems: Modellen er et trin i et program, ikke programmet.
Hverken Bonsai eller xs er noget, en mindre virksomhed selv skal installere. Bonsai er et lille bibliotek til droner og spil, og xs er et lille open source-projekt. Pointen er formen, ikke pakken. Det er den, man skal kunne genkende, når en leverandør præsenterer en agent.
Hvad en virksomhed skal spørge om
- Hvem vælger næste skridt? Er svaret «modellen», skal I have en meget god grund. Er svaret «et træ» eller «en graf», så bed om at se den.
- Hvad kan modellen overhovedet få systemet til at gøre? Svaret skal være en liste. Er det en beskrivelse, er grænsen ikke tegnet.
- Hvad sker der, mens I venter på et menneske? Kører der noget hele weekenden for at spørge, om chefen har svaret?
- Hvad sker der ved en genstart? Fortsætter sagen, hvor den slap, eller starter den forfra?
- Kan I se bagefter, hvad modellen fik, og hvad den svarede? Hvis ikke, kan I hverken forklare en fejl over for en kunde eller rette den.
Robotterne fandt ud af det for tyve år siden: Et system, der skal handle alene, skal have sine veje tegnet. Den lille virksomhed har brug for det samme, bare med en log, der husker, og med plads til at vente til mandag.