Chatbot, RAG och AI-agent: skillnaden är vem som får boka

Ni har sett den. Rutan nere i högra hörnet som säger "Hej! Hur kan jag hjälpa dig?" och sedan visar fyra knappar: Öppettider, Boka bord, Priser, Kontakt. Trycker man på "Boka bord" får man en länk till ett formulär. Skriver man istället har ni nåt ledigt på torsdag runt sju svarar den "Jag förstod tyvärr inte. Välj ett av alternativen nedan."

Den rutan sitter fortfarande på de flesta svenska restaurang- och klinikhemsidor. Den är tre generationer efter vad tekniken klarar.

Just nu pratas det mycket om RAG, oftast som om det vore samma sak som "AI som kan svara på frågor om vårt företag". Det är sant, och det är ändå bara mellansteget. Den skillnad som avgör om en gäst faktiskt blir hjälpt ligger ett steg längre fram, och den handlar inte om hur väl systemet förstår frågan. Den handlar om vad systemet får göra åt den.

Generation ett: trädet

Den klassiska webbchatten är ett beslutsträd. Någon har suttit i ett verktyg och ritat: om besökaren skriver något som innehåller "öppet" eller "tider", svara med öppettidstexten. Om besökaren trycker på knapp två, visa formuläret. Inget i den kedjan förstår språk. Den matchar nyckelord mot en lista och faller tillbaka på "välj ett alternativ" när matchningen missar.

Det fungerar precis så länge gästen ställer frågan på det sätt som någon förutsåg. Problemet är att gäster inte gör det. De skriver "vi är fyra pers, går det bra ikväll eller är det fullt", vilket innehåller varken "boka" eller "bord". De skriver "hur sent har ni på lördag". De ringer och pratar i två meningar innan de kommer till saken. Ett träd som ska täcka det behöver hundratals grenar, och någon måste underhålla varenda en.

Därför blev de flesta sådana chattar i praktiken en dyr länk till kontaktformuläret.

Generation två: RAG

RAG står för retrieval-augmented generation, ungefär "hämta först, svara sedan". Idén är enkel och den är bra.

Ni laddar upp era egna texter: menyn, prislistan, villkoren, vanliga frågor, kanske hela hemsidan. Systemet klipper sönder dem i stycken och räknar om varje stycke till en vektor, en lång rad siffror som representerar vad stycket handlar om. När en gäst ställer en fråga räknas frågan om på samma sätt, och systemet plockar fram de stycken som ligger närmast i den där sifferrymden. Först då får språkmodellen jobba, med gästens fråga i ena handen och de hämtade styckena i den andra, och instruktionen att svara utifrån dem.

Det löser två verkliga problem på en gång. Modellen behöver inte ha lärt sig något om just er, och den behöver inte hitta på. Den har texten framför sig.

Hos oss ligger det indexet hos ElevenLabs, ett per anläggning. Telefonagenten läser ur det under samtalet. Webbchatten, SMS, mejlen, Messenger och Instagram läser ur exakt samma index via ett anrop som kör agentens egen sökning utan att starta ett samtal. Det är hela poängen med att bara ha ett: en ägare som lägger in sin nya vinlista i portalen ska inte behöva undra vilka kanaler som fått den.

Sökningen rankar träffarna på vektoravstånd och vi skickar vidare de fem närmaste, kapade vid 6 000 tecken. Rådatan är betydligt större än så. En vanlig sökning kommer tillbaka med ett tjugotal stycken och runt 40 kB text, vilket skulle dränka en snabb modell och göra svaret långsamt och pratigt. Att välja bort är en del av jobbet.

Så långt är RAG utmärkt. Och så långt kan systemet fortfarande ingenting göra.

Vad RAG aldrig kommer att kunna svara på

Hämtning svarar på frågor vars svar står nedskrivet någonstans. Det är en större mängd frågor än man tror. Öppettider, allergener, parkering, avbokningsregler, om ni har högstol, vad en tandhygienistkontroll kostar. Allt det är text, och text kan hämtas.

Ett ledigt bord på torsdag klockan sju är inte text.

Det finns inte i något dokument, det ändrar sig medan gästen skriver, och det enda stället där sanningen finns är bokningssystemet. En RAG-chatt som får frågan har tre alternativ, och två av dem är dåliga. Den kan säga att den inte vet, vilket är ärligt och samtidigt anledningen till att gästen ringer istället. Den kan hitta närmaste stycke i indexet, till exempel "vi har öppet till 22 på torsdagar", och svara utifrån det, vilket låter hjälpsamt och inte besvarar frågan. Eller så gissar den.

Det tredje är det farliga. En språkmodell som fått i uppgift att vara hjälpsam och som saknar ett sätt att kontrollera fakta kommer förr eller senare att skriva "javisst, torsdag nitton noll noll går bra, jag har bokat in er". Ingenting har bokats. Gästen kommer ändå.

Det här är inte en teoretisk risk och det är inte något man promptar bort. Det är vad som händer när man ber ett system som bara kan producera text att utföra en handling.

Generation tre: agenten som får ringa in i era system

Steget som faktiskt löser det är att sluta be modellen svara på frågan och istället ge den verktyg.

När någon frågar efter en tid hos oss skriver Kim inte ett svar. Kim anropar check_availability, som går vidare till anläggningens bokningssystem: BokaMera, EasyPractice, GastroPlanner, easyTable, en kalender, eller vår egen tabell. Systemet svarar med vilka tider som finns. Först därefter formulerar modellen en mening, och den meningen kan bara innehålla tider som systemet självt just har sagt ja till.

Vill gästen ha en av dem anropas create_reservation, och bokningen skrivs in på riktigt. Gästen får sin bekräftelse. Personalen ser den i systemet de redan tittar i.

Regeln bakom det är den hårdaste vi har och den står i vår egen kravspec: bekräfta aldrig en bokning utan en verklig tillgänglighetskontroll. Det är därför modellvalet är en fråga vi testar snarare än tycker om, och varför vi kör en regressionssvit mot samtalsagenterna som letar efter exakt det här felet: svar som låter som en bekräftelse utan att ha en bokning bakom sig. Vi bedömer felsättet, inte poängen.

Varför "boka" är svårare än det låter

Det finns en anledning till att chattleverantörer stannar vid att länka till ert formulär. Att faktiskt boka betyder att man tar ansvar för att två gäster inte får samma bord.

Två personer kan skriva samtidigt. En ringer och en chattar. Bägge frågar om torsdag nitton noll noll, bägge får höra att det är ledigt, bägge säger ja. Kollar man tillgängligheten och skriver in bokningen som två separata steg hinner det andra samtalet emellan.

I databasen tar därför varje bokning ett lås på anläggningen, läser om hur många täckningar som redan är bokade i tidsintervallet, jämför mot maxantalet och avbryter med over_capacity om det inte går. Först då skrivs raden. Varje anrop bär dessutom en idempotensnyckel, så att ett nätverksfel som gör att samma bokning skickas två gånger ger en bokning och inte två.

Ingenting av det har med språkmodeller att göra. Det är vanlig databasdisciplin. Men det är gränsen mellan ett system som svarar om bokningar och ett system som utför dem, och det är den gränsen kunden märker.

RAG är fortfarande där, och det biter fortfarande

Poängen är inte att hämtning är föråldrat. Vi kör det parallellt, för det svarar på allt som står nedskrivet, och det är merparten av frågorna. Verktygen svarar på det som ändrar sig.

Två saker är värda att veta om man tänker sätta upp det själv.

Kvaliteten på indexet är kvaliteten på svaren, och indexet klagar inte. Vi upptäckte i augusti att en URL som ger 404 ändå sväljs som ett dokument: sidan skrapas, felmeddelandet indexeras, och ett dokument på 109 tecken med texten "This page doesn't exist" ligger sedan och konkurrerar om att bli hämtat. Allt såg rätt ut i gränssnittet. En felstavad adress i portalen räcker för att lägga nonsens framför gästen på samtliga kanaler.

Och ett verktyg som aldrig kan svara något meningsfullt är värre än inget verktyg. Har en anläggning inte lagt in några källor exponerar vi inte sökfunktionen alls för modellen. Annars sitter den och söker, får noll träffar och tappar tråden i ett samtal där gästen väntar.

Kort sagt

Tre tekniker, tre olika frågor de kan besvara.

Beslutsträdet kan svara på det någon har förutsett. RAG kan svara på det ni har skrivit ner. En agent med verktyg kan svara på det som gäller just nu, och kan göra något åt det.

Om ni jämför leverantörer är det bara en fråga som skiljer dem åt på riktigt: när gästen säger ja till torsdag klockan sju, står bokningen då i ert system när samtalet är slut? Allt annat är gradskillnader.

Vill ni se det på er egen verksamhet, boka en demo eller läs vad som händer i ert bokningssystem.