Chatbot, RAG ja tekoälyagentti: ero on siinä, kuka saa varata

Olette nähneet sen. Oikeassa alakulmassa oleva laatikko, joka sanoo "Hei! Miten voin auttaa?" ja näyttää sitten neljä painiketta: Aukioloajat, Varaa pöytä, Hinnat, Yhteystiedot. Painamalla "Varaa pöytä" saa linkin lomakkeeseen. Jos sen sijaan kirjoittaa onko torstaina seitsemän aikaan mitään vapaana, se vastaa "Valitettavasti en ymmärtänyt. Valitse jokin alla olevista vaihtoehdoista."

Se laatikko istuu edelleen useimmilla ravintoloiden ja klinikoiden sivuilla. Se on kolme sukupolvea jäljessä siitä, mihin tekniikka pystyy.

RAG:sta puhutaan nyt paljon, useimmiten kuin se olisi sama asia kuin "tekoäly, joka osaa vastata kysymyksiin yrityksestämme". Se pitää paikkansa, ja silti kyse on vasta välivaiheesta. Se ero, joka ratkaisee, saako asiakas oikeasti apua, on askeleen edempänä, eikä se liity siihen, kuinka hyvin järjestelmä ymmärtää kysymyksen. Se liittyy siihen, mitä järjestelmä saa asialle tehdä.

Ensimmäinen sukupolvi: puu

Klassinen verkkochat on päätöspuu. Joku on istunut työkalun ääressä ja piirtänyt: jos kävijä kirjoittaa jotain, jossa lukee "auki" tai "ajat", vastaa aukioloaikatekstillä. Jos hän painaa painiketta kaksi, näytä lomake. Mikään tuossa ketjussa ei ymmärrä kieltä. Se vertaa avainsanoja listaan ja putoaa takaisin vaihtoehtovalikkoon, kun osuma jää saamatta.

Se toimii täsmälleen niin kauan kuin asiakas esittää kysymyksen sillä tavalla, jonka joku osasi ennakoida. Ongelma on, etteivät asiakkaat tee niin. He kirjoittavat "meitä on neljä, onnistuuko tänä iltana vai onko täyttä", jossa ei lue "varaa" eikä "pöytä". He kirjoittavat "kuinka myöhään olette auki lauantaina". He soittavat ja puhuvat kaksi virkettä ennen kuin pääsevät asiaan. Puu, joka kattaisi kaiken tuon, tarvitsee satoja haaroja, ja jonkun on ylläpidettävä jokaista.

Siksi useimmista tällaisista chateista tuli käytännössä kallis linkki yhteydenottolomakkeeseen.

Toinen sukupolvi: RAG

RAG tulee sanoista retrieval-augmented generation, suunnilleen "hae ensin, vastaa sitten". Ajatus on yksinkertainen, ja se on hyvä.

Te lataatte omat tekstinne: ruokalistan, hinnaston, ehdot, usein kysytyt kysymykset, ehkä koko sivuston. Järjestelmä pilkkoo ne paloiksi ja muuntaa jokaisen palan vektoriksi, pitkäksi numerojonoksi, joka edustaa sitä, mistä pala kertoo. Kun asiakas kysyy jotain, kysymys muunnetaan samalla tavalla, ja järjestelmä poimii ne palat, jotka ovat lähimpänä siinä numeroavaruudessa. Vasta sitten kielimalli pääsee töihin, asiakkaan kysymys toisessa kädessä ja haetut palat toisessa, ohjeenaan vastata niiden pohjalta.

Se ratkaisee kaksi todellista ongelmaa kerralla. Mallin ei tarvitse olla oppinut mitään juuri teistä, eikä sen tarvitse keksiä. Teksti on sen edessä.

Meillä tuo indeksi on ElevenLabsilla, yksi toimipistettä kohti. Puhelinagentti lukee sitä kesken puhelun. Verkkochat, tekstiviesti, sähköposti, Messenger ja Instagram lukevat täsmälleen samaa indeksiä kutsulla, joka ajaa agentin oman haun käynnistämättä keskustelua. Juuri siinä on koko idea siinä, että indeksejä on vain yksi: yrittäjän, joka lisää uuden viinilistan portaaliin, ei pidä joutua miettimään, mitkä kanavat sen saivat.

Haku järjestää osumat vektorietäisyyden mukaan, ja me välitämme viisi lähintä, katkaistuna 6 000 merkkiin. Raakadataa on selvästi enemmän. Tavallinen haku palauttaa parisenkymmentä palaa ja noin 40 kB tekstiä, mikä hukuttaisi nopean mallin ja tekisi vastauksesta hitaan ja jaarittelevan. Karsiminen on osa työtä.

Tähän asti RAG on erinomainen. Ja tähän asti järjestelmä ei vielä osaa tehdä mitään.

Se, mihin RAG ei koskaan pysty vastaamaan

Haku vastaa kysymyksiin, joiden vastaus on kirjoitettu johonkin. Niitä on enemmän kuin luulisi. Aukioloajat, allergeenit, pysäköinti, peruutusehdot, onko teillä syöttötuolia, mitä suuhygienistin tarkastus maksaa. Kaikki tuo on tekstiä, ja tekstiä voi hakea.

Vapaa pöytä torstaina kello seitsemän ei ole tekstiä.

Sitä ei ole missään dokumentissa, se muuttuu sillä välin kun asiakas kirjoittaa, ja ainoa paikka, jossa totuus on, on varausjärjestelmä. RAG-chatilla on tuohon kysymykseen kolme vaihtoehtoa, ja kaksi niistä on huonoja. Se voi sanoa, ettei tiedä, mikä on rehellistä ja samalla juuri syy siihen, että asiakas soittaa sen sijaan. Se voi löytää indeksistä lähimmän palan, esimerkiksi "torstaisin olemme auki kello 22 asti", ja vastata sen pohjalta, mikä kuulostaa avuliaalta eikä vastaa kysymykseen. Tai sitten se arvaa.

Kolmas on se vaarallinen. Kielimalli, jonka tehtäväksi on annettu olla avulias ja jolta puuttuu keino tarkistaa tosiasioita, kirjoittaa ennemmin tai myöhemmin "toki, torstai kello 19 sopii, olen varannut teille pöydän". Mitään ei ole varattu. Asiakas tulee silti paikalle.

Tämä ei ole teoreettinen riski eikä sellainen, josta selviää kehotteita hiomalla. Näin käy, kun järjestelmää, joka osaa vain tuottaa tekstiä, pyydetään suorittamaan toimenpide.

Kolmas sukupolvi: agentti, joka saa mennä järjestelmiinne

Askel, joka oikeasti ratkaisee asian, on lakata pyytämästä mallia vastaamaan kysymykseen ja antaa sille sen sijaan työkalut.

Kun joku kysyy meiltä aikaa, Kim ei kirjoita vastausta. Kim kutsuu check_availability-työkalua, joka menee edelleen toimipisteen varausjärjestelmään: BokaMera, EasyPractice, GastroPlanner, easyTable, kalenteri tai meidän oma taulumme. Järjestelmä vastaa, mitä aikoja on. Vasta sen jälkeen malli muotoilee virkkeen, ja siinä virkkeessä voi olla vain aikoja, joille järjestelmä itse juuri antoi luvan.

Jos asiakas haluaa jonkin niistä, kutsutaan create_reservation, ja varaus kirjataan oikeasti. Asiakas saa vahvistuksensa. Henkilökunta näkee sen siinä järjestelmässä, jota se jo katsoo.

Taustalla oleva sääntö on kovin meillä oleva, ja se on kirjattu omaan määrittelyymme: älä koskaan vahvista varausta ilman todellista saatavuustarkistusta. Siksi mallivalinta on meille testaamisen eikä mielipiteen asia, ja siksi ajamme puheagentteja vasten regressiosarjaa, joka etsii juuri tätä virhettä: vastauksia, jotka kuulostavat vahvistukselta ilman varausta takanaan. Arvioimme virheen tavan, emme pistemäärää.

Miksi "varaa se" on vaikeampaa kuin miltä kuulostaa

On syy siihen, miksi chat-toimittajat pysähtyvät linkkiin teidän lomakkeeseenne. Oikeasti varaaminen tarkoittaa vastuun ottamista siitä, etteivät kaksi asiakasta saa samaa pöytää.

Kaksi ihmistä voi kirjoittaa samaan aikaan. Yksi soittaa toisen chatatessa. Molemmat kysyvät torstaita kello 19, molemmille kerrotaan että on vapaata, molemmat sanovat kyllä. Jos saatavuuden tarkistaminen ja varauksen kirjaaminen ovat kaksi erillistä vaihetta, toinen keskustelu ehtii väliin.

Tietokannassa jokainen varaus ottaa siksi lukon toimipisteeseen, lukee uudelleen, kuinka monta paikkaa aikavälille on jo varattu, vertaa enimmäismäärään ja keskeyttää virheellä over_capacity, jos tila ei riitä. Vasta sitten rivi kirjoitetaan. Jokainen kutsu kantaa lisäksi idempotenssiavainta, joten verkkovirhe, joka lähettää saman varauksen kahdesti, tuottaa yhden varauksen eikä kahta.

Millään tästä ei ole tekemistä kielimallien kanssa. Se on tavallista tietokantakuria. Mutta siinä kulkee raja järjestelmän, joka puhuu varauksista, ja järjestelmän, joka tekee niitä, välillä, ja juuri sen rajan asiakas huomaa.

RAG on yhä mukana, ja se puree yhä

Pointti ei ole, että haku olisi vanhentunut. Ajamme sitä rinnalla, koska se vastaa kaikkeen, mikä on kirjoitettu ylös, ja se on kysymyksistä valtaosa. Työkalut vastaavat siihen, mikä muuttuu.

Kaksi asiaa kannattaa tietää, jos aiotte pystyttää tämän itse.

Indeksin laatu on vastausten laatu, eikä indeksi valita koskaan. Huomasimme elokuussa, että 404-virheen antava osoite nielaistaan silti dokumentiksi: sivu kaavitaan, virheilmoitus indeksoidaan, ja 109 merkin dokumentti tekstillä "This page doesn't exist" jää kilpailemaan haetuksi tulemisesta. Käyttöliittymässä kaikki näytti oikealta. Yksi väärin kirjoitettu osoite portaalissa riittää tuomaan hölynpölyn asiakkaan eteen kaikilla kanavilla.

Ja työkalu, joka ei voi koskaan vastata mitään mielekästä, on huonompi kuin ei työkalua lainkaan. Jos toimipiste ei ole lisännyt lähteitä, emme näytä hakutoimintoa mallille ollenkaan. Muuten se jää hakemaan, saa nolla osumaa ja kadottaa langan keskustelussa, jossa asiakas odottaa.

Lyhyesti

Kolme tekniikkaa, kolme erilaista kysymystä, joihin ne pystyvät vastaamaan.

Päätöspuu vastaa siihen, minkä joku on ennakoinut. RAG vastaa siihen, minkä olette kirjoittaneet ylös. Työkaluilla varustettu agentti vastaa siihen, mikä pitää paikkansa juuri nyt, ja osaa tehdä sille jotain.

Jos vertailette toimittajia, vain yksi kysymys erottaa ne oikeasti: kun asiakas sanoo kyllä torstaille kello seitsemän, onko varaus järjestelmässänne siinä vaiheessa kun keskustelu päättyy? Kaikki muu on asteen eroa.

Jos haluatte nähdä tämän omassa toiminnassanne, varatkaa esittely. Kaksikymmentä minuuttia, ja pääsette itse soittamaan sille.