Chatbot, RAG og AI-agent: forskjellen er hvem som får booke

Dere har sett den. Boksen nede i høyre hjørne som sier "Hei! Hvordan kan jeg hjelpe deg?" og så viser fire knapper: Åpningstider, Book bord, Priser, Kontakt. Trykker man på "Book bord", får man en lenke til et skjema. Skriver man i stedet har dere noe ledig på torsdag rundt sju, svarer den "Beklager, jeg forsto ikke. Velg et av alternativene under."

Den boksen sitter fortsatt på de fleste norske restaurant- og klinikksider. Den ligger tre generasjoner bak det teknikken klarer.

Det snakkes mye om RAG nå, som regel som om det var det samme som "AI som kan svare på spørsmål om bedriften vår". Det stemmer, og det er likevel bare mellomsteget. Forskjellen som avgjør om en gjest faktisk blir hjulpet, ligger ett steg lenger fram, og den handler ikke om hvor godt systemet forstår spørsmålet. Den handler om hva systemet får lov til å gjøre med det.

Generasjon én: treet

Den klassiske nettchatten er et beslutningstre. Noen har sittet i et verktøy og tegnet: hvis den besøkende skriver noe som inneholder "åpent" eller "tider", svar med åpningstidsteksten. Trykker de på knapp to, vis skjemaet. Ingenting i den kjeden forstår språk. Den matcher nøkkelord mot en liste og faller tilbake på "velg et alternativ" når treffet uteblir.

Det fungerer akkurat så lenge gjesten stiller spørsmålet på den måten noen hadde forutsett. Problemet er at gjester ikke gjør det. De skriver "vi er fire stykker, går det i kveld eller er det fullt", som verken inneholder "booke" eller "bord". De skriver "hvor sent har dere åpent på lørdag". De ringer og prater i to setninger før de kommer til saken. Et tre som skal dekke alt det, trenger hundrevis av greiner, og noen må vedlikeholde hver eneste én.

Derfor endte de fleste slike chattene opp som en dyr lenke til kontaktskjemaet.

Generasjon to: RAG

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

Dere laster opp deres egne tekster: menyen, prislisten, vilkårene, vanlige spørsmål, kanskje hele nettstedet. Systemet klipper dem opp i biter og regner om hver bit til en vektor, en lang rekke tall som representerer hva biten handler om. Når en gjest spør om noe, regnes spørsmålet om på samme måte, og systemet henter fram de bitene som ligger nærmest i det tallrommet. Først da får språkmodellen jobbe, med gjestens spørsmål i den ene hånden og de hentede bitene i den andre, og beskjed om å svare ut fra dem.

Det løser to virkelige problemer på én gang. Modellen trenger ikke ha lært noe om akkurat dere, og den trenger ikke å finne på. Teksten ligger foran den.

Hos oss ligger den indeksen hos ElevenLabs, én per avdeling. Telefonagenten leser fra den under samtalen. Nettchat, SMS, e-post, Messenger og Instagram leser fra nøyaktig samme indeks via et kall som kjører agentens eget søk uten å starte en samtale. Det er hele poenget med å bare ha én: en eier som legger inn den nye vinlisten i portalen, skal slippe å lure på hvilke kanaler som fikk den.

Søket rangerer treffene på vektoravstand, og vi sender videre de fem nærmeste, kuttet ved 6 000 tegn. Rådataene er atskillig større. Et vanlig søk kommer tilbake med rundt tjue biter og cirka 40 kB tekst, som ville druknet en rask modell og gjort svaret tregt og pratsomt. Å velge bort er en del av jobben.

Så langt er RAG utmerket. Og så langt kan systemet fortsatt ingenting gjøre.

Det RAG aldri kommer til å kunne svare på

Henting svarer på spørsmål som har svaret skrevet ned et sted. Det er flere spørsmål enn man tror. Åpningstider, allergener, parkering, avbestillingsregler, om dere har barnestol, hva en time hos tannpleier koster. Alt det er tekst, og tekst kan hentes.

Et ledig bord torsdag klokka sju er ikke tekst.

Det finnes ikke i noe dokument, det endrer seg mens gjesten skriver, og det eneste stedet sannheten finnes, er bookingsystemet. En RAG-chat som får det spørsmålet, har tre valg, og to av dem er dårlige. Den kan si at den ikke vet, som er ærlig og samtidig grunnen til at gjesten ringer i stedet. Den kan finne nærmeste bit i indeksen, for eksempel "vi har åpent til 22 på torsdager", og svare ut fra det, som høres hjelpsomt ut og ikke besvarer spørsmålet. Eller så gjetter den.

Det tredje er det farlige. En språkmodell som har fått i oppgave å være hjelpsom, og som mangler en måte å kontrollere fakta på, vil før eller siden skrive "ja visst, torsdag nitten null null går fint, jeg har booket dere inn". Ingenting er booket. Gjesten kommer likevel.

Dette er ikke en teoretisk risiko, og det er ikke noe man prompter seg bort fra. Det er hva som skjer når man ber et system som bare kan produsere tekst, om å utføre en handling.

Generasjon tre: agenten som får gå inn i systemene deres

Steget som faktisk løser det, er å slutte å be modellen svare på spørsmålet og i stedet gi den verktøy.

Når noen spør etter en tid hos oss, skriver ikke Kim et svar. Kim kaller check_availability, som går videre til avdelingens bookingsystem: BokaMera, EasyPractice, GastroPlanner, easyTable, en kalender, eller vår egen tabell. Systemet svarer med hvilke tider som finnes. Først deretter formulerer modellen en setning, og den setningen kan bare inneholde tider systemet selv nettopp har sagt ja til.

Vil gjesten ha en av dem, kalles create_reservation, og bookingen skrives inn på ordentlig. Gjesten får bekreftelsen sin. De ansatte ser den i systemet de allerede ser på.

Regelen bak er den strengeste vi har, og den står i vår egen kravspesifikasjon: bekreft aldri en booking uten en virkelig tilgjengelighetssjekk. Derfor er modellvalget noe vi tester i stedet for å mene noe om, og derfor kjører vi en regresjonssuite mot samtaleagentene som leter etter nettopp denne feilen: svar som høres ut som en bekreftelse uten å ha en booking bak seg. Vi vurderer feilmåten, ikke poengsummen.

Hvorfor "book det" er vanskeligere enn det høres ut

Det er en grunn til at chatleverandører stopper ved å lenke til skjemaet deres. Å faktisk booke betyr å ta ansvar for at to gjester ikke får samme bord.

To personer kan skrive samtidig. Én ringer mens en annen chatter. Begge spør om torsdag nitten null null, begge får høre at det er ledig, begge sier ja. Sjekker man tilgjengeligheten og skriver inn bookingen som to atskilte steg, rekker den andre samtalen å komme imellom.

I databasen tar derfor hver booking en lås på avdelingen, leser om hvor mange plasser som allerede er booket i tidsrommet, sammenligner mot maksantallet og avbryter med over_capacity hvis det ikke går. Først da skrives raden. Hvert kall bærer dessuten en idempotensnøkkel, slik at en nettverksfeil som sender samme booking to ganger, gir én booking og ikke to.

Ingenting av dette har med språkmodeller å gjøre. Det er vanlig databasedisiplin. Men det er grensen mellom et system som snakker om bookinger og et system som utfører dem, og det er den grensen kunden merker.

RAG er fortsatt der, og det biter fortsatt

Poenget er ikke at henting er utdatert. Vi kjører det parallelt, for det svarer på alt som står skrevet ned, og det er de fleste spørsmålene. Verktøyene svarer på det som endrer seg.

To ting er verdt å vite hvis dere tenker å sette det opp selv.

Kvaliteten på indeksen er kvaliteten på svarene, og indeksen klager aldri. Vi oppdaget i august at en URL som gir 404, likevel svelges som et dokument: siden skrapes, feilmeldingen indekseres, og et dokument på 109 tegn med teksten "This page doesn't exist" ligger så og konkurrerer om å bli hentet. Alt så riktig ut i grensesnittet. Én feilstavet adresse i portalen holder for å legge tull foran gjesten på samtlige kanaler.

Og et verktøy som aldri kan svare noe meningsfullt, er verre enn ikke noe verktøy. Har en avdeling ikke lagt inn noen kilder, eksponerer vi ikke søkefunksjonen for modellen i det hele tatt. Ellers sitter den og søker, får null treff og mister tråden i en samtale der gjesten venter.

Kort sagt

Tre teknikker, tre ulike spørsmål de kan besvare.

Beslutningstreet kan svare på det noen har forutsett. RAG kan svare på det dere har skrevet ned. En agent med verktøy kan svare på det som gjelder akkurat nå, og kan gjøre noe med det.

Sammenligner dere leverandører, er det bare ett spørsmål som virkelig skiller dem: når gjesten sier ja til torsdag klokka sju, står bookingen da i systemet deres når samtalen er over? Alt annet er gradsforskjeller.

Vil dere se det på deres egen virksomhet, så book en demo. Tjue minutter, og dere får ringe den selv.