Chatbot

En erfaringsrapport samt beskrivelse av proof-of-concept

En chatbot er enkelt forklart et dataprogram hvor mennesker kan samhandle i ved hjelp av språk, vanligvis tekstbasert, men tale er også mulig. Chatbots brukes gjerne i dialogsystemer for å avlaste kundeservice og support. Spesielt i situasjoner der det er mange gjentagende spørsmål.

Meninger om hvordan en chatbot bør oppføre seg er litt delt, der ytterpunktene er at noen velger å få chatboten til å oppføre seg så menneskelignende som mulig, der andre nærmest ser på en chatbot som en slags søkemotor. Førstnevnte menneskelignende tilnærming virker å være mest brukt. Felles er at en chatbot må forstå (1) vanlig språk, for eksempel setninger formulert som spørsmål, (2) forstå hvilket (informasjons)behov brukeren har, og (3) gi korrekt svar til brukeren.

Noen få eksempler på chatbots er Siri, Google Assistant , DNB kundeservice chat og KommuneKari.

Leverandører

I løpet av 2017 og 2018 har Trondheim Kommune fått besøk av flere chatbot-leverandører som har presentert sine løsninger. Felles for løsningene var at det krever en del menneskelig innsats for å få systemet til å svare korrekt på spørsmål, samt at det tar en del tid før svarene er på plass.

Med mindre et menneske aktivt har lagt inn et svaralternativ til et spørsmål, vil ikke chatboten kunne svare på en henvendelse. Typisk vil ubesvarte henvendelser havne i en kø, som da knyttes til svar av et menneske. Over tid vil svaralternativene bli flere, samt at flere spørsmål vil bli knyttet til samme svar. I tillegg er noen chatboter designet for å lære å knytte lignende spørsmål til svar, både som del av frontend- og backendløsningen. Dette markedsføres gjerne som kunstig intelligens.

Litt forenklet sett er hovedoppgaven til en chatbot å tolke teksten som kommer inn og knytte dette til et relevant svar som så blir presentert for brukeren.

Både utvalgte spørsmålsalternativ samt svar ligger i en database. Når et spørsmål blir knyttet til et svaralternativ, svarer chatboten med det som er lagret. Noen ganger som tekst, noen ganger som en peker til websiden informasjonen er hentet fra.

Siden svarene er lagret i en database, og ikke blir hentet “live” fra en kilde, vil ikke chatboten få med seg endringer på kildeinformasjonen, som kan resultere i feil svar. For eksempel når åpningstider blir oppdatert på websiden, blir det ikke automatisk fanget opp av chatbot (dette må oppdateres i chatboten i tillegg til der informasjonen hentes fra). Databasen og brukeren vil få et utdatert svar, noe som er veldig uheldig.

I det andre tilfellet, der brukeren får en lenke, er brukeropplevelsen dårligere. Dette fordi man må forlate chatvinduet og selv finne frem til riktig svar som står en eller annen plass på siden man er blitt pekt til.

Vi synes ikke at disse to alternativene gir en god nok brukeropplevelse.

Utprøving av Dialogflow

Trondheim kommune er Googlekunde, og chatbotsystemet Dialogflow er inkludert som en del av pakken. Det er blitt gjennomført noen interne tester med Dialogflow, der chatboten ble lært opp til å kunne svare på spørsmål som hvordan skrive reiseregning, hvordan fylle ut skjema for syke barn, hvordan å be om permisjon og så videre.

Det er forholdsvis lett å lage en enkel chatbot. Integrasjoner er predefinert og enkel å sette opp. Utfordringen med Dialogflow er som hos de andre verktøyene: svarene blir lagret i Dialogflow, og ved oppdatert informasjon vil chatboten svare med utdatert informasjon. En mulighet for å unngå det er bruk av “webhooks”, som leder til et websted framfor å svare med tekst fra databasen. Vi har ikke undersøkt dette nærmere.

Det å sette opp en chatbot med både eksempelspørsmål og reelle svar tar en del tid. Det blir mye klipping og liming, samt strukturering. Menneskeressurser som kunne ha blitt brukt på en annen måte…

Selvlærende, selvoppdaterende chatbot

Besøk fra leverandører samt “in house” eksperimentering gav innsikt, som igjen ledet til definisjon av en studentoppgave ved NTNU.

Målet var å lage en selvlærende chatbot som har svar på alt som finnes på www.trondheim.kommune.no, og som oppdaterer seg selv dersom kildeinformasjon endrer seg. Alt dette dette basert på designmønsteret Model-view-controller (MVC), for å lett kunne bytte ut komponenter ved behov.

En gruppe bestående av 6 bachelorstudenter valgte oppgaven og har brukt vårsemesteret 2019 på å sette seg inn i problemstillingen samt ferdigstille en prototype.

I oppgaven var følgende definert som hovedmål til en kommunal chatbot:

svare korrekt på spørsmål som angår kommunen og kommunens tjenester
minst mulig bruk av mennesker som ressurs

For å kunne utføre oppgaven, er følgende unødvendig:

svare på spørsmål som ikke omfattes av førstnevnte
menneskelignende samtale
kunne svare med “smalltalk” som en dialog om været, eller vitser
flotte grafiske elementer
...

Selv om noen av disse punktene kan være morsomme eller “kjekt å ha”, har de lite med hovedmålene å gjøre. Først når det viktigste er løst tilstrekkelig bør man eventuelt begynne å tenke på alt rundt. Å kunne gjøre forbedringer etterpå, fordrer riktig bruk programvaredesignprinsipper fra starten av. Det nytter ikke å ha et veldig fint brukergrensesnitt eller en knallbra smalltalk-modul dersom chatboten ikke klarer å svare på det som er kommunerelevant.

Kontekst er veldig viktig for å kunne svare riktig, og konteksten for en kommunal chatbot er nettopp kommunale tjenester og kommunal informasjon. På samme måte som man ikke kan forvente et faglig korrekt svar på et snekkerspørsmål når man stiller det spørsmålet til en maler, bør man heller ikke forvente at en kommunal chatbot klarer å svare på ting som ikke har med kommunen å gjøre.

Proof of concept

For studentoppgaven ble det definert at chatboten skulle være en slags foredlet søkemotor, og ikke en “menneskelignende samtalepartner”.

Dersom man starter med antakelsen at all kommunerelevant informasjon har funnet sin vei til www.trondheim.kommune.no, er kunnskapsbasen definert. Det å finne fram til riktig informasjon ved bruk av vanlig nøkkelordbasert søk kan være en utfordring, og der byr chatbots på flere muligheter ettersom vanlig språk kan bli anvendt.

Løsningen som ble laget består av 3 moduler; informasjonssamleren, datamodellen og språkprosesseringsmodulen. Alle moduler er generiske, som vil si ikke spesifikt laget for Trondheim Kommune sitt websted, og systemet er mulig å bli installert på få timer og med minimal konfigurering.

Systemet består av 6 hovedkomponenter:

En web scraper som har som oppgave å trekke ut tilgjengelig informasjon fra en informasjonskilde
En kunnskapsbase som lagrer og indekserer informasjon slik at det blir lett tilgjengelig for spørring
En språkprosesseringsmodul som interpreterer spørsmål fra sluttbrukere og som gjennomfører søk i kunnskapsbasen
En webside som gir muligheter for manuelle endringer til kunnskapsbasen
En chatbot integrasjon, slik at sluttbrukere kan kommunisere med chatboten.
En API som tar seg av dataflyten mellom de forskjellige komponenter

Informasjonssamleren/Web scraper

Som forklart har en chatbot en database med svar, samt logikk til å skjønne hvordan å koble et spørsmål til riktig svar gjennom bruk av språk. En vanlig framgangsmåte er å bruke mennesker til å definere både eksempelspørsmål samt svar, for å så utvide dette over tid.

Siden et mål er å sørge for at minst mulig menneskekraft blir bruk, ble det bygget en “web scraper” som samler all tilgjengelig tekst på www.trondheim.kommune.no for å danne en kunnskapsbase. For å unngå at svar-databasen og kilden kommer i utakt dersom informasjon blir oppdatert, kjøres crawleren hver natt. Dette tar ca 20 minutter.

Crawleren er bygget så generisk som mulig, for å kunne gjenbrukes på andre nettsteder dersom ønskelig.

Kunnskapsbase

I kunnskapsbasen lagres hvert avsnitt som informasjonssamleren trekker ut fra websiden som et mulig svar.

Basen er basert på en “Non-Relational Database” der data er lagret på en ustrukturert måte og uten uttalte relasjoner mellom dataobjektene, mens databasen fremdeles har en spørremåte for å kunne trekke ut informasjon, blant annet ved hjelp av “partial matching”.

Språkprosessering

Språkprosessering (Engelsk: Natural Language Processing, or NLP) handler om hvordan mennesker og maskiner oppfatter naturlig språk. Naturlig språk er veldig forståelig for mennesker, men er vanskelig å tolke for maskiner. Språkprosessering er krevende. Tekst kan ha forskjellige tolkninger i forskjellige kontekst.

Det er utarbeidet en språkprosesseringsmodul som tolker spørsmålet som brukeren stiller. Nøkkelord har forskjellig “søkeverdi” avhengig av om det er artikkel, adjektiv, verb, osv. Modulen “trekker fra hverandre” søkestrengen i en prosess som heter for “tokenisation”, “part-of-speech tagging” og “lemmatisering” og gir de forskjellige deler en vekt. Vekting blir brukt til gjenfinning av lignende konsepter i kunnskapsbasen.

Søkestrenger blir rensket på en måte slik at det er mulig å finne igjen relevante svar. I prosessen fjernes betydningsløse ord.

Dersom søket ikke leder til svar, brukes en synonymdatabase basert på Wordnet samt et manuelt definert ordsett for å utvide søket. Et eksempel kan være at noen søker på “pipe”, men får treff på “skorstein”.

En detaljert forklaring på hvordan språk blir håndtert finnes i bacheloroppgaven til studentene.

Admingrensesnitt

En webside som gir muligheter for manuelle endringer til kunnskapsbasen.

Det er mulig å justere vekt på verdier samt legge til synonymer.

Integrasjon

Det ble ikke vektlagt integrasjon. Integrasjonen er dog meget enkel å få til, det er kun en tekststreng som input og en tekststreng som output.

I testfasen foregikk integrasjonen gjennom Dialogflow (der kun string in og string ut ble brukt, ingen prosesseringslogikk eller NLP) med Slack.

Dataflyt API

APIen for å ordne dataflyt. Naturlig språk inn, prosessering, gjenfinning av svar, eventuelt en runde gjennom synonymer, og så gi ett eller flere svar tilbake som string og URL og vise til brukeren.

Testing

Ut ifra nettsidestatistikk ser vi at omtrent 60% av informasjonsbehovet til våre brukere er sentrert rundt 20 spørsmål.

Chatboten er designet slik at den svarer med et avsnitt samt en URL.

Chatboten klarer å svare med korrekt avsnitt til 79% av spørsmålene, og riktig URL i 95%.

Konklusjon

Vi har nå et generisk chatbot rammeverk, som klarer å svare riktig på en stor andel av de mest stilte spørsmål, og det tilnærmet uten konfigurering. Det er fullt mulig å endre vektene på søkeord for å øke treffprosenten. Det er også lagt opp til at dagens svakheter (se nedenfor) på en relativ enkel måte kan bli forbedret.

Det tar noen få timer å få installert de nødvendige moduler, og etter det er det er bare å peke til URL’en www.trondheim.kommune.no (eller annen plass), vente på at crawleren er ferdig, noe som tar omtrent 20 minutter, og deretter er kunnskapsbasen klar til bruk.

I proof-of-concept fasen ble det ikke utviklet en integrasjon mot eksisterende chatprogrammer. API’en til kunnskapsbasen er ganske enkel: send en string med et spørsmål og få en string med et svar inkludert URL tilbake. I tilfeller der flere svaralternativ blir vurdert som like sannsynlig, blir flere svar sendt.

Produktets styrker:

• Relativt høy svarpresisjon

• Mulighet til å manuelt oppdatere vektene i kunnskapsbasen

• Gjenbrukbar. Det krever minimalt med konfigurering før en ny kunnskapsbase er på plass.

• MVC arkitektur er blitt brukt og derfor er systemet enkel å forbedre over tid

• Produktet er språk-agnostisk. Kildeinformasjonen definerer hvilket språk som kan bli brukt for gjenfinning.

Produktets svakheter:

• Systemet antar at måten kildeinformasjonen er presentert på gir mening som svar dersom et avsnitt plukkes ut. Dette fordi alle avsnitt er ansett som svar.

• Det er ikke implementert et mekanisme for å håndtere kontekst. Det vil si at hvert spørsmål blir sett på individuelt og uten sammenheng med tidligere spørsmål eller svar.

• System er delvis avhengig av at brukeren bruker noenlunde samme ordlyd som svaralternativet. Språkprosesseringmodellen er token-basert, er derfor må det være en match. Vi bruker wordnet for automatiske synonymer dersom hoved-token ikke samsvarer, men det resulterer ikke alltid i riktig svar.

• I dagens versjon er det ikke lagt til en stavekontroll, men det er enkelt å implementere som tillegg.

Veien videre

Integrasjonen til Slack, gjennom Dialogflow ble brukt for funksjonstesting. Vi har stor tro på tilnærmingen som ble brukt som teknologisk bakgrunn i studentprosjektet funker i produksjon.

Vi kommer til å utvikle en mer innbyggerrettet integrasjon som kan brukes på kommunens webside. Kildekode vil bli oppdatert fortløpende.

Trondheim Kommune ønsker å takke studentgruppen bestående av: Tinus Sola Flagstad, Martin Bondkall Gjerde, Thomas Andre Skaaheim, Torjus Tønnessen Iveland, Vegar Andreas Bergum og Anders Mølster Hopland for deres meget bra arbeid med oppgaven!

Kildekode og installasjonsmanual

Kildekode med GPL3.0 lisens, samt installasjonsmanual finner du her:

https://github.com/Trondheim-kommune/chatbot

Report abuse