Chatbot, RAG og AI-agent: forskellen er, hvem der må booke

I har set den. Boksen nede i højre hjørne, der siger "Hej! Hvordan kan jeg hjælpe?" og så viser fire knapper: Åbningstider, Book bord, Priser, Kontakt. Trykker man på "Book bord", får man et link til en formular. Skriver man i stedet har I noget ledigt på torsdag omkring syv, svarer den "Beklager, det forstod jeg ikke. Vælg en af mulighederne nedenfor."

Den boks sidder stadig på de fleste danske restaurant- og klinikhjemmesider. Den er tre generationer bagud i forhold til, hvad teknikken kan.

Der bliver talt meget om RAG for tiden, som regel som om det var det samme som "AI, der kan svare på spørgsmål om vores virksomhed". Det passer, og det er alligevel kun mellemtrinnet. Den forskel, der afgør, om en gæst rent faktisk bliver hjulpet, ligger et skridt længere fremme, og den handler ikke om, hvor godt systemet forstår spørgsmålet. Den handler om, hvad systemet må gøre ved det.

Generation ét: træet

Den klassiske webchat er et beslutningstræ. Nogen har siddet i et værktøj og tegnet: hvis den besøgende skriver noget med "åbent" eller "tider", så svar med åbningstidsteksten. Trykker de på knap to, vis formularen. Intet i den kæde forstår sprog. Den matcher nøgleord mod en liste og falder tilbage på "vælg en mulighed", når matchet glipper.

Det virker præcis så længe, gæsten stiller spørgsmålet på den måde, nogen havde forudset. Problemet er, at gæster ikke gør det. De skriver "vi er fire, kan det lade sig gøre i aften, eller er der fuldt", som hverken indeholder "booke" eller "bord". De skriver "hvor sent har I åbent på lørdag". De ringer og taler i to sætninger, før de kommer til sagen. Et træ, der skal dække alt det, kræver hundredvis af grene, og nogen skal vedligeholde hver eneste én.

Derfor endte de fleste af den slags chats som et dyrt link til kontaktformularen.

Generation to: RAG

RAG står for retrieval-augmented generation, cirka "hent først, svar bagefter". Idéen er enkel, og den er god.

I uploader jeres egne tekster: menuen, prislisten, betingelserne, ofte stillede spørgsmål, måske hele hjemmesiden. Systemet klipper dem i stykker og regner hvert stykke om til en vektor, en lang række tal, der repræsenterer, hvad stykket handler om. Når en gæst spørger om noget, bliver spørgsmålet regnet om på samme måde, og systemet henter de stykker frem, der ligger tættest i det talrum. Først da får sprogmodellen lov at arbejde, med gæstens spørgsmål i den ene hånd og de hentede stykker i den anden og besked på at svare ud fra dem.

Det løser to virkelige problemer på én gang. Modellen behøver ikke have lært noget om netop jer, og den behøver ikke finde på. Teksten ligger foran den.

Hos os ligger det indeks hos ElevenLabs, ét per afdeling. Telefonagenten læser fra det under samtalen. Webchat, SMS, mail, Messenger og Instagram læser fra præcis samme indeks via et kald, der kører agentens egen søgning uden at starte en samtale. Det er hele pointen med kun at have ét: en ejer, der lægger den nye vinliste ind i portalen, skal ikke sidde og gætte på, hvilke kanaler der fik den.

Søgningen rangerer træfferne på vektorafstand, og vi sender de fem nærmeste videre, skåret ved 6.000 tegn. Rådataene er noget større. En almindelig søgning kommer tilbage med omkring tyve stykker og cirka 40 kB tekst, hvilket ville drukne en hurtig model og gøre svaret langsomt og snakkesaligt. At vælge fra er en del af arbejdet.

Så langt er RAG udmærket. Og så langt kan systemet stadig ingenting.

Det, RAG aldrig kommer til at kunne svare på

Hentning svarer på spørgsmål, hvis svar står skrevet ned et sted. Det er flere spørgsmål, end man tror. Åbningstider, allergener, parkering, afbestillingsregler, om I har en høj stol, hvad et tjek hos tandplejeren koster. Alt det er tekst, og tekst kan hentes.

Et ledigt bord torsdag klokken syv er ikke tekst.

Det findes ikke i noget dokument, det ændrer sig, mens gæsten skriver, og det eneste sted, sandheden findes, er bookingsystemet. En RAG-chat, der får det spørgsmål, har tre muligheder, og to af dem er dårlige. Den kan sige, at den ikke ved det, hvilket er ærligt og samtidig grunden til, at gæsten ringer i stedet. Den kan finde det nærmeste stykke i indekset, for eksempel "vi har åbent til 22 om torsdagen", og svare ud fra det, hvilket lyder hjælpsomt og ikke besvarer spørgsmålet. Eller også gætter den.

Den tredje er den farlige. En sprogmodel, der har fået til opgave at være hjælpsom, og som mangler en måde at kontrollere fakta på, vil før eller siden skrive "ja da, torsdag nitten nul nul går fint, jeg har booket jer ind". Der er intet booket. Gæsten møder op alligevel.

Det er ikke en teoretisk risiko, og det er ikke noget, man prompter sig ud af. Det er, hvad der sker, når man beder et system, der kun kan producere tekst, om at udføre en handling.

Generation tre: agenten, der må gå ind i jeres systemer

Skridtet, der rent faktisk løser det, er at holde op med at bede modellen svare på spørgsmålet og i stedet give den værktøjer.

Når nogen spørger efter en tid hos os, skriver Kim ikke et svar. Kim kalder check_availability, der går videre til afdelingens bookingsystem: BokaMera, EasyPractice, GastroPlanner, easyTable, en kalender eller vores egen tabel. Systemet svarer med, hvilke tider der findes. Først derefter formulerer modellen en sætning, og den sætning kan kun indeholde tider, systemet selv lige har sagt ja til.

Vil gæsten have en af dem, kaldes create_reservation, og bookingen bliver skrevet ind for alvor. Gæsten får sin bekræftelse. Personalet ser den i det system, de allerede kigger i.

Reglen bag er den hårdeste, vi har, og den står i vores egen kravspecifikation: bekræft aldrig en booking uden et rigtigt ledighedstjek. Derfor er modelvalget noget, vi tester frem for at mene noget om, og derfor kører vi en regressionssuite mod samtaleagenterne, der leder efter netop denne fejl: svar, der lyder som en bekræftelse uden at have en booking bag sig. Vi bedømmer fejlmåden, ikke pointtallet.

Hvorfor "book det" er sværere, end det lyder

Der er en grund til, at chatleverandører stopper ved at linke til jeres formular. At booke rigtigt betyder at tage ansvar for, at to gæster ikke får det samme bord.

To personer kan skrive samtidig. Én ringer, mens en anden chatter. Begge spørger til torsdag nitten nul nul, begge får at vide, at der er ledigt, begge siger ja. Tjekker man ledigheden og skriver bookingen ind som to adskilte trin, når den anden samtale at komme imellem.

I databasen tager hver booking derfor en lås på afdelingen, læser igen, hvor mange pladser der allerede er booket i tidsrummet, sammenligner med maksantallet og afbryder med over_capacity, hvis det ikke går. Først da bliver rækken skrevet. Hvert kald bærer desuden en idempotensnøgle, så en netværksfejl, der sender den samme booking to gange, giver én booking og ikke to.

Intet af det har med sprogmodeller at gøre. Det er almindelig databasedisciplin. Men det er grænsen mellem et system, der taler om bookinger, og et system, der udfører dem, og det er den grænse, kunden mærker.

RAG er der stadig, og det bider stadig

Pointen er ikke, at hentning er forældet. Vi kører det sideløbende, for det svarer på alt, hvad der står skrevet ned, og det er de fleste spørgsmål. Værktøjerne svarer på det, der ændrer sig.

To ting er værd at vide, hvis I selv skal sætte det op.

Kvaliteten af indekset er kvaliteten af svarene, og indekset klager aldrig. Vi opdagede i august, at en URL, der giver 404, alligevel bliver slugt som et dokument: siden bliver skrabet, fejlmeddelelsen indekseret, og et dokument på 109 tegn med teksten "This page doesn't exist" ligger så og konkurrerer om at blive hentet. Alt så rigtigt ud i grænsefladen. Én stavefejl i en adresse i portalen er nok til at lægge vrøvl foran gæsten på samtlige kanaler.

Og et værktøj, der aldrig kan svare noget meningsfuldt, er værre end intet værktøj. Har en afdeling ikke lagt nogen kilder ind, eksponerer vi slet ikke søgefunktionen for modellen. Ellers sidder den og søger, får nul træffere og taber tråden i en samtale, hvor gæsten venter.

Kort fortalt

Tre teknikker, tre forskellige spørgsmål, de kan besvare.

Beslutningstræet kan svare på det, nogen har forudset. RAG kan svare på det, I har skrevet ned. En agent med værktøjer kan svare på det, der gælder lige nu, og kan gøre noget ved det.

Sammenligner I leverandører, er der kun ét spørgsmål, der reelt skiller dem: når gæsten siger ja til torsdag klokken syv, står bookingen så i jeres system, når samtalen er slut? Alt andet er gradsforskelle.

Vil I se det på jeres egen forretning, så book en demo. Tyve minutter, og I får selv lov at ringe til den.