JacobB˚athandZacBauer,SchoolofIndustrialEngineeringandManagement,KTHRoyalInstituteofTechnology,Stockholm,Sweden Tr¨aningavuppgiftsorienteradedialogsystemmedReinforcementLearningTrainingtaskorienteddialogsystemswithReinforcementLearning

(1)

GRUNDNIVÅ, 15 HP

STOCKHOLM SVERIGE 2020,

Träning av uppgiftsorienterade dialogsystem med Reinforcement Learning

Training task oriented dialog systems with Reinforcement Learning

JACOB BÅTH ZAC BAUER

KTH

SKOLAN FÖR INDUSTRIELL TEKNIK OCH MANAGEMENT

(2)

Tr¨aning av uppgiftsorienterade dialogsystem med Reinforcement Learning

Training task oriented dialog systems with Reinforcement Learning

Jacob B˚ath and Zac Bauer, School of Industrial Engineering and Management, KTH Royal Institute of Technology, Stockholm, Sweden

Abstract—Machine learning methods are often dependent on access to large amounts of data which is why alternatives are of big interest. The purpose of this work is to examine how efficient, in terms of speed and quality, a task oriented chatbot can be trained with reinforcement learning (”RL”), and see how these dialogs differ from rule based and supervised learning methods. Instead of using a dataset, dialogs are simulated with a user simulator which interacts with the chatbot. The result shows that RL has good potential to replace or complement other methods, since the implemented model can train a chatbot to optimal performance within a few minutes. The dialogs generated by the chatbot may seem trivial but the flexible nature of RL lets the bot adjust its behaviour according to what users prefer.

Sammanfattning– M˚anga maskininlärningsmetoder kräver ofta stora mängder data vilket väcker fr˚agan kring huruvida alternativ som s˚a kallad reinforcement learning (”RL”), vilket är en mindre dataintensiv metod, kan uppn˚a samma kvalitet. Syftet med denna rapport är att undersöka hur effektivt, med avseende p˚a tid och kvalitet, en uppgiftsorienterad chatbot kan tränas med RL, samt hur denna chatbots dialoger skiljer sig fr˚an en som tränats med supervised learning eller är helt regelbaserad.

Detta görs genom att skapa en enkel användarsimulering som chatboten interagerar med för att successivt bli bättre. Resultatet tyder p˚a att RL visar god potential att ersätta eller användas som komplement till andra metoder, d˚a den implementerade modellen kan träna en chatbot till optimal niv˚a p˚a n˚agra f˚a minuter.

Dialogerna som skapas med chatboten kan verka triviala men RL inneb¨ar att chatboten enkelt kan anpassa sitt beteende utefter anv¨andares preferenser.

I. INTRODUKTION

Intresset för Artificiell Intelligens (”AI”) har växt kraftigt under 2000-talet och flera av de specifika tekniska uttryck som förknippas med AI är nu allmänt kända [1]. Samtidigt är teknologier förknippade med AI kontroversiella där Professor Spyros Makridakis menar p˚a att det finns fyra scenarion i vilka individer visualiserar sig; den oro som identifieras bland merparten av individer kopplas till att AI kommer leda till högre arbetslöshet enligt Makridakis. Han ser dock snarare att den förändring i arbetskraftsfördelningen som skedde i samband med b˚ade den industriella och den digitala revolu- tionen kommer fortsätta och att fler istället kommer arbeta inom tjänstesektorn [2]. Denna omfördelning p˚a grund av AI har redan börjat enligt Cameron Smith genom ”chatbots”

d¨ar anst¨allda kan fokusera p˚a mer komplexa uppgifter och

¨overl¨amna tidigare arbetsuppgifter till botar [3].

Utvecklingsmetoder för chatbotar syftar däremot inte längre enbart till att skapa en bot som klarar ett Turing-test; numera

är det mer intressant att jämföra metoder med avseende p˚a prestanda, tiden de tar att träna och mängden data som krävs.

Uppgiftssorienterade dialogsystem är ett omr˚ade som utforskas med avseende p˚a dessa avvägningar. Den enklaste lösningen innefattar en ”state tracker” som bygger p˚a fördefinierade regler och genom dessa avgör vilket ”state” konversationen befinner sig i och vilken ”output” den ska generera. Svaren baseras p˚a en svarsbank för svar med ifyllnadsfält. Denna metod är dock inte att föredra eftersom det är tidskrävande att sätta upp reglerna samt att den blir inflexibel och icke skalbar [4]. Exempelvis om ett existerande system med fördefinierade regler skulle nyttjas inom ett nytt omr˚ade skulle regler behöva definieras p˚a nytt. De flesta andra alternativ implementerar n˚agon form av maskininlärning där det i m˚anga fall, exempelvis med supervised och unsupervised learning, krävs en stor mängd träningsdata. Ett alternativ till detta är reinforcement learning (”RL”) som istället baseras p˚a att lära sig av sina misstag genom interaktioner med användaren.

Williams et. al. kom fram till att Hybrid Code Networks (”HCN”), en kombination av fördefinierade regler specifi- cerade för användningsomr˚adet och en supervised learning- modell, genererade bra resultat till en förh˚allandevis liten ansträngning fr˚an utvecklarnas sida [4]. I samma arbete implementerades en RL-modell, koden finns dock inte publicerad.

Därför syftar detta arbete till att implementera denna RL- modell och svara p˚a fr˚ageställningen Hur effektivt - med avseende p˚a tid och kvalitet - en chatbot kan tränas med reinforcement learning, samt hur denna chatbots dialoger skiljer sig fr˚an en som tränats med supervised learning eller

¨ar helt regelbaserad?

Syftet är därför att se hur väl lämpat RL är för ett Uppgift- sorienterat Dialogsystem (”UDS”) och även titta p˚a om det innebär att en mindre mängd - om ens n˚agon - träningsdata krävs innan ett system testas. De sv˚arigheter som identifierats berör dialogsimulering och evaluering. P˚a grund av tidsbegränsningar i projektet kommer chatboten som utvecklas inte kunna testas under en längre tid av riktiga användare vilket leder till att dialoger kommer behövas simuleras. Detta omr˚ade anses g˚a utanför projektets fokusomr˚ade och därför kommer

(3)

endast en enklare användarsimulator utvecklas. Det dialogsystem som tas fram kommer utspela sig i en restaurangbokn- ingsmiljö vilket är ett vanligt test-domän för UDS:er. Eftersom fr˚ageställningen inte syftar till att leverera en slutprodukt för användare kommer systemet inte kopplas upp mot ett API eller en databas för att generera riktiga rekommendationer. Istället kommer funktionaliteten av ett API-anrop ligga kvar för att simulera detta.

Trots att projektet implementeras p˚a ett begränsat omr˚ade anses det vara intressant för forskare och företag som utvecklar eller undersöker UDS:er. Framförallt riktar sig arbetet ˚at de som saknar eller har en begränsad mängd data och som potentiellt skulle vilja involvera en chatbot i sin kundsupport, vilket inte sällan är fallet för SMEs (small and medium- sized enterprises). Arbetet kommer därför ocks˚a svara p˚a fr˚ageställningen Hur kan en chatbot implementeras och skapa affärsnytta för ett företag med begränsade resurser och kompetens inom omr˚adet?

Beroende p˚a hur stor eller liten kompetens företaget har inom chatbotar kan samarbete med andra parter vara värdefullt. Den tredje delfr˚ageställningen kommer därför att vara: När ett företag bestämmer huruvida man bör samarbeta med ett annat företag eller inte, vilka är det mest kritiska fr˚agor man bör ta ställning till?.

Arbetets tre fr˚agest¨allningar ¨ar s˚aledes:

1) Hur effektivt - med avseende p˚a tid och kvalitet - en chatbot kan tränas med reinforcement learning, samt hur denna chatbots dialoger skiljer sig fr˚an en som tränats med supervised learning eller är helt regelbaserad?

2) Hur kan en chatbot implementeras och skapa affärsnytta för ett företag med begränsade resurser och kompetens inom omr˚adet?

3) När ett företag bestämmer huruvida man bör samarbeta med ett annat företag eller inte, vilka är det mest kritiska fr˚agor man bör ta ställning till?

Starkt fokus kommer ligga p˚a den f¨orsta av dessa tre fr˚agest¨allningar.

Rapporten kommer först g˚a igenom grundläggande teori för HCN och RL och även ta upp relaterade arbeten. Metod för implementeringen, inklusive hur modellen fungerar i detalj, kommer sedan förklaras. Därefter presenteras resultatet i form av hur chatboten förbättras efter varje dialog och visa ett urval av dialoger fr˚an olika steg i träningen. En diskussion förs sedan där detta resultat tolkas och hur det kan skilja sig fr˚an en regelbaserad chatbot eller en tränad med supervised learning (vilket kommer refereras till som RNN (recurrent neural network)). Därefter sker en analys av affärs- och samhällsrelaterade aspekter tas upp där fr˚ageställning 2 och 3 behandlas.

II. TEORI

A. Hybrid code networks (HCN)

HCN innebär att kombinera supervised machine learning - för detta arbete ett recurrent neural network (RNN) - med domänspecifik kunskap. Att enbart ha ett RNN kräver stora mängder data medan att enbart bygga en modell med domänspecifik kunskap kräver mycket manuellt arbete, samt

är en s˚adan modell inte anpassningsbar. Vid en hybrid kan man minska datamängden genom att ge modellen viss vägledning specifikt för den uppgift som ska lösas. Det kan ske genom att lyssna särskilt p˚a vissa typer av ord och ha fördefinierade format p˚a svar. Det här arbetets chatbot kommer endast generera 16 olika yttranden som alla är korta meningar.

B. Reinforcement learning (RL)

Agenten (modellen i detta fall) f˚ar en belöning baserat p˚a hur bra den presterar för varje slutförd dialog. Belöningen kan vara utformad p˚a m˚anga olika sätt, exempelvis kan den vara 1 om agenten lyckas med sin uppgift och -1 om den misslyckas.

Agenten utforskar olika sekvenser av handlingar och justerar sig för att uppn˚a maximal belöning. Denna justering kan ske p˚a olika sätt men en vanlig metod för chatbotar är ”policy gradient”. Policyn genererar sannolikheter för att agenten ska välja en viss handling i ett givet tillst˚and.

Supervised learning och RL kan kombineras genom att för varje dialog justera hur policyn uppdateras. I supervised learning baseras uppdateringen p˚a hur l˚angt modellens output var ifr˚an det rätta svaret enligt datasetet. I RL finns däremot inget rätt svar utan istället uppdateras policyn för att maximera belöningen.

Den typ av RL-teknik som används i detta arbete är policy gradient som innebär att en policy optimeras med avseende p˚a belöning. Policyn är i detta fall ett neuralt nätverk. Efter varje avslutad dialog uppdateras sedan policyns parametrar enligt

~

w ← ~w + α(X

t

∇_w_~log π(a_t|s_t))(G − b) (1)

där α är ”learning rate”, π är policyn, at är den genererade frasen fr˚an chatboten givet st vilket är användarens yttrande, G är dialogens totala belöning vilket kallas return och b är

”baseline”. Baselinen spelar ingen roll för hur bra chatboten blir i slutändan men kan p˚askynda lärandet avsevärt [5]. En enkel baseline är att beräkna genomsnittlig return för tidigare dialoger, intuitivt kan man d˚a tänka att nya dialoger med en högre return G än baseline b f˚ar sina beteenden förstärkta (ökad sannolikhet att ske igen), medan beteenden minskar för det omvända.

III. RELATERADE ARBETEN

I stora drag finns tv˚a olika typer av maskininlärnings- metoder som används för att kontrollera dialoger, där den ena använder neurala nätverk för att bearbeta vad användaren sagt och sedan svara [6]. För att skapa bra dialoger är det dock viktigt för chatboten att komma ih˚ag vad som sagts tidigare och det m˚aste man i dessa modeller programmera manuellt.

Ett annat alternativ är att använda RNN:s som använder tidigare utdata som indata i nästkommande ord eller mening [7].

Det gör att vad som tidigare sagts automatiskt tas hänsyn till vid nästa ord- eller meningsgenerering.

RNN-modeller kan sedan kombineras med RL [4], bland annat finns det exempel p˚a ett arbete d¨ar en uppgiftsorienterad chatbot skapades med ett RNN och sedan med RL [4].

Ju mer modellen tr¨anades med RNN innan desto snabbare

(4)

förbättrades modellen när RL sedan implementerades. Kod- implementeringar och data för Williams et al. arbete finns tillgängligt men inte RL-implementeringen, utan denna syftar detta arbete till att göra.

För att träna chatboten med RL räcker dock inte ett dataset med färdiga dialoger, utan användarens svar m˚aste bero p˚a vad chatboten sagt. Det kan antingen göras genom att träna chatboten online där mänskliga användare g˚ar in och interagerar med chatboten. Detta är dock tidskrävande d˚a RL kräver m˚anga dialoger för att kunna bli bra, dessutom g˚ar det inte att träna om chatboten p˚a samma dataset om man senare ändrar delar i koden.

Alternativet är att simulera en användare vilket g˚ar att göra p˚a m˚anga olika sätt. Ett problem med den metoden är dock att det är sv˚art att jämföra olika chatbotars prestationer när de tränas med olika simuleringar. Det finns förslag p˚a standardiserade simuleringar [8], dock anses dessa vara un- derm˚aligt konstruerade och onödigt komplicerade för detta arbete. Istället kommer en egen relativt enkel regelbaserad simulering konstrueras för att kunna träna chatboten med RL.

IV. METOD

A. Grundkod fr˚an Github

Grundkoden som chatboten bygger p˚a finns tillgänglig p˚a Github [9]. Denna kod innehöll redan behandling av data, RNN-modell samt träning- och testfunktioner. Pytorch [10]

användes för att bygga RNN-modellen och användes därför ocks˚a för ny kod som skrevs.

Figur 1 visar hur chatboten är konstruerad. Detta är ett HCN och best˚ar av ett RNN, domänspecifik kod och en ”entity extraction (steg 4)” som känner igen entiteter (kök, pris, plats och antal personer) i en fras.

Iterationen börjar med att användaren säger n˚agot (steg 1).

Denna fras parametriseras sedan med bag of words-vektorer (steg 2) och en word embedding (steg 3). I koden som detta arbete bygger p˚a användes Googles 300-dimensionella word embedding [11]. I steg 4 känns entiteter igen genom att söka igenom frasen efter entiteter som förekommit n˚agon g˚ang i bAbi-datasetet (förklaras under egen rubrik). Denna lösning begränsar modellen till att endast känna igen vissa entiteter och gör det omöjligt att uppfatta nya. En bättre lösning är till exempel att ha ett neuralt nätverk som kan tränas till att ocks˚a kunna uppfatta nya entiteter, dock är det i sig en omfattande uppgift och g˚ar utanför detta arbetes fokusomr˚ade. I steg 5 ser modellen till att komma ih˚ag vilka entiteter som registrerats, det vill säga vilken information chatboten f˚att och saknar. Det kan sedan användas för filtret mellan steg 9 och 10 som till exempel hindrar chatboten fr˚an att fr˚aga om saker användaren redan sagt.

I steg 6 sammanfogas tidigare parametriseringar av användarens fras till en ”feature vector” som utgör input till RNN:et i steg 7. Steg 8 visar hur output fr˚an iterationen innan används som input i nästa steg, vilket gör det neurala nätverket till ”recurrent”. Steg 9 och 10 genererar sedan en fördelning över vilken fras chatboten bör välja i steg 11. Om RL används väljs en fras med sannolikhet enligt den fördelning som genererats, annars väljs den med högsta värdet.

Steg 13-16 förklarar sedan hur en API-förfr˚agan kan göras.

Det är dock inget som kommer göras i denna uppgift utan istället har chatboten frasen ”api call” till sin användning för att signalera att den vill göra en API-förfr˚agan. Det viktiga

¨ar att chatboten har all information innan den g¨or detta vilket

är n˚agot man kan styra genom filtret mellan steg 9 och 10 eller l˚ata boten lära sig själv, till exempel genom att ge return G = 0 om en API-förfr˚agan gjorts utan all information. I steg 17 skickas den slutgiltiga frasen till användaren som sen kan svara p˚a nytt och p˚abörja nästa iteration.

B. Implementering av reinforcement learning

För att göra koden kompatibel med RL behövdes först n˚agra funktioner läggas till eller ändras för att läsa in och behandla data p˚a rätt sätt. Detta krävdes eftersom RNN var byggt för att observera konversationer medan RL interagerar med en användare eller simulering.

Nästa steg var att ändra funktionen (ekvation (1) under teori) för att uppdatera det neurala nätverkets parametrar. Detta gjordes i samma träningsfunktion som RNN-modellen vilket gjorde det smidigt att kunna alternera mellan de tv˚a olika mod- ellerna. Funktionen kräver en bak˚atpropagering som gjordes med Pytorchs autograd.backwards() [12] d˚a den är effektiv och enkel att använda. Optimeringsfunktionen för att uppdatera parametrarna som användes var Adadelta [13] eftersom den automatiskt anpassar learning rate. Denna implementerades med Pytorchs Optim-paket [14].

Returnen G best¨amdes enligt

G = 0.95^t−1 (2)

för lyckade dialoger där t är antalet yttranden fr˚an boten. För misslyckade dialoger sattes G = 0. En dialog räknas som misslyckad om chatboten väljer att vara tyst eller säga ”you’re welcome” utan att följande är uppfyllt:

• chatboten har all information (anv¨andarens val av k¨ok, plats, prisniv˚a, antalet personer)

• anv¨andaren har sagt ”THANK YOU”

Tanken med detta är att ”you’re welcome” är botens sätt signalera att den är klar och avslutar dialogen. ”THANK YOU” fungerar som motsvarande för användaren och kan endast ske om boten uppfyllt användarens ärende. Baselinen valdes till den genomsnittliga returnen G p˚a de 100 senaste dialogerna.

C. bAbi-dataset

I den rapport och kod som ligger till grund för detta arbete nyttjades The (5) dialog bAbI tasks som används för end- to-end UDS:er i en miljö för restaurangbokningar [4]. Detta dataset best˚ar av lyckade dialoger mellan en chatbot och en simulerad användare. Dialogerna var lyckade i det avseendet att chatboten lyckades slutföra en bokning för användaren utan konstiga beteenden, till exempel onödiga upprepningar. Denna chatbot har endast 16 olika fraser till sin användning och kan inte generera n˚agra andra svar än dessa, p˚a s˚a sätt ligger uppgiften i att säga rätt sak vid rätt tillfälle. De 16 fraserna är manuellt konstruerade och anpassade efter uppgiften att göra

(5)

Fig. 1. Modellbeskrivning baserad p˚a figur 1 i Williams et. al. [4]. Trapetsoider innebär python-kod, svarta rektanglar är träningsbara komponenter och de ljusa sm˚a rektanglarna i steg 6 representerar sammansatta vektorer som är input till RNN:et.

restaurangreservationer och kan ses i tabell I. Dessa är även de fraser som detta arbetes chatbot kommer använda sig av.

Det är bland annat denna typ av manuellt arbete i kombination med användning av neurala nätverk som gör modellen till ett HCN.

Williams et. al. [4] använde även loggar fr˚an deras företags (Microsofts) textbaserade kundsupport för RL-delen av projektet. En RNN-modell tränas genom att observera dialoger medan en RL-modell tränas genom interaktion. Tyvärr finns det för detta arbete inte tillg˚ang till n˚agon kundsupport som i Williams et. al. fall eller n˚agot liknande. Istället kommer en simulerad användare skapas vilken RL-modellen kan interagera med. Att simulera en användare innebär givetvis en del begränsningar d˚a det är sv˚art att f˚a dialogerna lika varierade som vid interaktion med riktiga och m˚anga olika människor.

D. Anv¨andarsimulator

En användarsimulator kan skapa m˚anga olika sätt och ju mer varierade fraser den kan generera desto bättre. Om fraserna blir för lika varandra eller om det inte finns tillräckligt m˚anga blir det sv˚arare för chatboten att generalisera dessa fraser och p˚a s˚a sätt först˚a vad en helt ny fras betyder när chatboten senare interagerar med en människa.

I detta arbete skapades en simulering som fungerar enligt f¨oljande:

1) Börja med att välja en hälsningsfras fr˚an tabell (förklaras nedan).

2) L¨as in chatbotens fras/replik.

3) Om fras fr˚an (2) ¨ar ”you’re welcome” eller ”SILENT”

avslutas dialogen direkt. Annars: baserat p˚a fras fr˚an (2),

SILENT

any preference on a type of cuisine?

api call

great let me do the reservation hello what can i help you with today?

here it is

how many people would be in your party?

i’m on it

is there anything else i can help you with?

ok let me look into some options for you sure is there anything else to update?

sure let me find an other option for you what do you think of this option:

where should it be?

which price range are you looking for?

you’re welcome

TABLE I

CHATBOTENS16OLIKA SVARSALTERNATIV.

välj slumpmässigt svar fr˚an tabell. Om svaret inneh˚aller en entitet (kök, pris, antal personer, plats) slumpas dessa fr˚an alla de olika entiteter som förekommit i bAbi- datasetet. Börja om fr˚an (2).

Tabellen best˚ar av 16 olika kolumner där varje representerar en av chatbotens olika fraser. Kolumnerna inneh˚aller sedan olika fraser som simulatorn väljer slumpmässigt ifr˚an (i den kolumn som motsvarar vad chatboten sagt). Dessa fraser har formulerats av författarna själva och försöker vara s˚a varierande som möjligt men fortfarande vara en rimlig replik p˚a chatbotens fras. Simuleringen kan p˚a s˚a sätt ses som en samarbetsvillig användare som inte har för avsikt att göra det sv˚arare för chatboten, till exempel genom att säga n˚agot helt

(6)

irrelevant. Antalet fraser per kolumn varierade mellan ungefär 10-20 stycken beroende p˚a vilken fras det handlade om. Om till exempel chatboten fr˚agar ”where should it be?” förväntas variationen p˚a svaren vara lägre än till exempel ”hello what can i help you with today?”; ju högre variation desto fler olika fraser har lagts in. Denna metod för simulering valdes d˚a den

är relativt enkel att skapa och integrera med resten av koden, samt lätt att modifiera och utöka.

För att undvika att chatboten testades mot samma bot som den tränades p˚a skapades för varje träning en tränings- och testsimulator. Detta gjordes genom att slumpartat dela upp de manuellt skapade svaren i varje kolumn; träningssimulatorn tog 80 procent av svaren (fraserna i varje tabellkolumn) och testsimulatorn resten. För att chatboten ska kunna föra lyckade dialoger med test-simulatorn krävs s˚aledes att den lyckas generalisera fr˚an de fraser som använts i träningen. Till exempel, om simuleringen p˚a fr˚agan ”any preference on a type of cuisine?” svarat ”I like italian”, ska chatboten kunna först˚a att meningen ”I adore italian” ocks˚a innebär att användaren vill ha italiensk mat.

E. Tr¨aning av modellen

Chatboten tränades sedan och jämförelser gjordes med att träna med och utan filter. Till exempel kan filtret ta bort fr˚agan

”where should it be?” om en plats redan har nämnts. Detta filter fanns i grundkoden men är inte absolut nödvändigt d˚a chatboten kan lära sig att fr˚agan i exemplet inte hjälper den att slutföra en lyckad dialog. Träningar gjordes även med RNN enbart för att kunna jämföra dialogerna med den RL-tränade chatboten.

F. Test och evaluering

I grundkoden testades RNN med bAbI-datasetet genom att beräkna antalet svar som stämde överens med chatbotens genererade svar. Det valdes att inte testa den RL-tränade modellen p˚a samma sätt d˚a den teoretiskt sett skulle kunna hitta bättre sätt att avsluta dialogen än vad som gjordes i bAbI-datan. Istället observerades utvecklingen av return per avslutad dialog och andelen lyckade dialoger med den tränade modellen.

G. Studie av SMEs och aff¨arsnytta

För att f˚a en bild av hur digitaliserade SMEs i Sverige är i dagsläget har tv˚a rapporter av Tillväxtanalys, Myndigheten för tillväxtpolitiska utvärderingar och analyser studerats. Den ena - Företagens digitala mognad 2018 [15] - ger en bild hur

”digitalt mogna” svenska företag är i dagsläget och den andra - Framtidens digitala kompetensbehov – en delphiinspirerad studie[16] - fokuserar mer p˚a vilka teknologier som används och troligtvis kommer dominera i framtiden. Informationen i dessa rapporter anses mycket trovärdig och neutral.

Studien kring hur företag bör tänka kring samarbeten har i första hand baserats p˚a M. Schillings bok Strategic Man- agement of Technological Innovation [17]. Boken inneh˚aller ett utförligt kapitel om samarbeten i samband med innovation där teorier och modeller fr˚an olika discipliner - till exempel

0 1,000 2,000 3,000 4,000

0 0.2 0.4 0.6 0.8 1

Antal dialoger

ReturnG(rullandegenomsnitt)

Filter Utan filter

Fig. 2. Rullande genomsnitt p˚a de 100 senaste dialogerna.

0 1,000 2,000 3,000 4,000

0 0.2 0.4 0.6 0.8 1

Antal dialoger

Andellyckadedialoger(rullandegenonsnitt)

Filter Utan filter

Fig. 3. Rullande genomsnitt p˚a de 100 senaste dialogerna.

organisation och projektledning - kombineras. Denna studie kommer därför inte direkt anknyta till n˚agon vedertagen teori eller modell utan kommer istället koppla till den teori som läggs fram i Schillings bok.

Undersökningen av affärsnytta har sin grund i vad författarna anser vore en rimlig tillämpning, samt vad som presenterats i rapporten Framtidens digitala kompetensbehov – en delphiinspirerad studie. Resonemangen stärks sedan med observationer fr˚an olika internetkällor.

Istället för att separat presentera resultatet för denna litter- aturstudie kommer fakta och resonemang tas upp samtidigt under rubriken Affärs- och samhällsrelaterade perspektiv i diskussions-delen.

V. RESULTAT

Figur 2 och 3 visar returnen G och antalet lyckade dialoger baserat p˚a hur m˚anga dialoger som modellen tr¨anats p˚a.

Filtret g¨or att modellen konvergerar snabbare ¨aven om b˚ada

(7)

varianter konvergerar i slutändan. En return p˚a ungefär 0.7- 0.8 är optimalt; högre niv˚aer kräver att användare ger mer information p˚a färre antalet meddelande vilket inte görs i simuleringen, men är självklart möjligt i verkligheten.

Tabell II, III och IV visar dialoger under olika delar av träningen. Dialogerna är skapade med test-simulatorn som genererar annorlunda fraser än de som chatboten tränats med.

Tr¨aningarna tog ungef¨ar tre minuter.

Tabell V visar en dialog med den RNN-tr¨anade chatboten.

Användarens fraser kommer fr˚an en lyckad dialog i bAbi- datasetet och därför finns ocks˚a ett facit till vad boten ska svara. Efter varje fras fr˚an användaren genererar chatboten ett svar och sedan beräknas hur stor andel av alla dessa svar som stämde överens med facit (den lyckade dialog som fanns i bAbi-datasetet). I denna dialog hade boten 100 procent rätt och därmed stämmer dialogen exakt överens med den som finns i bAbi-datasetet. Ingen RL har använts för denna chatbot utan denna dialog kommer användas för att diskutera skillnader i dialogen med RL-boten och RNN-boten.

User: Howdy Bot: here it is

User: actually i would prefer it in a cheap price range Bot: where should it be?

User: paris please Bot: api call User: SILENCE

Bot: i’m on it User: cool Bot: SILENT

TABLE II

DIALOG MED TEST-SIMULATOR EFTER10DIALOGER(UTAN FILTER).

G = 0.

User: good evening Bot: where should it be

User: in madrid please

Bot: how many people would be in your party?

User: eight please

Bot: any preference on a type of cuisine?

User: i want korean food Bot: great let me do the reservation

User: THANK YOU Bot: where should it be?

User: in madrid please Bot: great let me do the reservation

User: THANK YOU

Bot: ok let me look into some options for you User: amazing

Bot: which price range are you looking for?

User: something moderate Bot: where should it be?

User: in madrid please

User: eight please Bot: api call User: SILENCE

Bot: here it is User: THANK YOU Bot: you’re welcome

TABLE III

G = 0.57.

User: good evening

Bot: which price range are you looking for?

User: something expensive

User: six please Bot: where should it be?

User: in bangkok please Bot: any preference on a type of cuisine?

User: could i please have french food Bot: api call

User: SILENCE Bot: great let me do the reservation

User: THANK YOU Bot: you’re welcome

TABLE IV

G = 0.74.

User: hi

Bot: hello what can i help you with today?

User: can you make a restaurant reservation in bombay with french food in a cheap price range

Bot: i’m on it User: SILENCE

User: we will be six

Bot: ok let me look into some options for you User: SILENCE

Bot: what do you think of this option:

User: it’s perfect Bot: api call User: SILENCE Bot: great let me do the reservation

User: thanks

Bot: is there anything else i can help you with?

User: no thank you Bot: you’re welcome

TABLE V

DIALOG MEDRNN-MODELLENS CHATBOT.

VI. ANALYS OCHDISKUSSION

A. Teknisk analys

1) Analys av dialoger: Tabell II visar en dialog i början av träningen där chatboten mer eller mindre väljer fras slumpmässigt. När träningen börjar är policyn (sanno- likhetsfördelningen över vilken fras boten väljer baserat p˚a vad användaren sagt) likformigt fördelad, det vill säga 1/16 för varje fras. Om chatboten inte lyckas med en dialog blir returnen G = 0 vilket gör att ingen uppdatering sker av de vikter i det neurala nätverket som policyn är parametriserad av. Detta beror p˚a att G−b i ekvation 1 blir 0 vilket gör att uppdateringen av vikterna blir ~w ← ~w + 0. S˚a länge ingen dialog lyckas kommer därför chatboten generera en slumpmässig fras, men s˚a fort en dialog lyckats kommer vikterna justeras n˚agot.

Fortsatta misslyckade dialoger kommer sedan ha en baseline b > 0 vilket gör att om en dialog misslyckas kommer G−b < 0 och därför uppdatera vikterna ~w i det neurala nätverket s˚a att sannolikheten för beteendet (vilka fraser chatboten valde beroende p˚a vad användaren sagt) i denna dialog minskar. I tabell II är baselinen fortfarande 0 och policyn är konstant, vilket kan ses i de osammanhängande fraserna; att svara ”here it is” utan att ha f˚att n˚agon information om vad användaren vill ha eller ens gjort ett ”api call” är givetvis inget önskvärt

(8)

beteende.

Tabell III visar en lyckad dialog men där vissa onödiga beteenden förekommer. Chatboten har här först˚att att den m˚aste ha olika typ av information (kök, antal personer, pris och plats) innan den föresl˚ar n˚agot genom ”here it is”. Däremot fortsätter den att ställa fr˚agor om saker den redan vet; användaren m˚aste till exempel säga tre g˚anger att den vill göra bokningen i Madrid.

Det är mycket möjligt att en mänsklig användare skulle avfärda en chatbot som ställer samma fr˚aga onödigt m˚anga g˚anger. Detta är dock under träningens tidiga skede och senare under träningen - se tabell IV - ställer inte chatboten upprepade fr˚agor p˚a samma sätt. Här ställs varje fr˚aga en g˚ang och s˚a fort chatboten har all information görs reservationen. Returnen G

är här 0.74 vilket är optimalt för denna dialog, ett högre värde skulle kräva att användaren gav mer information per fras s˚a att bokningen kan göras snabbare.

Dialogen i tabell IV kan visserligen verka trivial; chatboten ger ingen bekräftelse till användaren att den har uppfattat dennes önskem˚al utan fr˚agar direkt om mer information. Detta beror p˚a att returnen G minskar för varje ny fras chatboten använder och därför försöker den s˚a snabbt som möjligt f˚a all information, göra reservationen och sen avsluta dialogen.

I return-funktionen är det möjligt att införa regler som gör att returnen ökar för visst typ av beteende, till exempel att bekräftelse p˚a att informationen har registrerats. Detta kräver dock manuellt arbete vilket kan vara sv˚art och ta l˚ang tid. Ett alternativ kan vara att göra en mer avancerad simulering eller l˚ata chatboten vid detta stadie börja konversera med mänskliga användare. Det är möjligt att dessa avslutar konversationen när chatboten inte bekräftar att den uppfattat den information man angivit, utan bara fortsätter ställa fr˚agor. Detta gör att chatboten kan lära sig att detta beteende inte är optimalt och att det är fördelaktigt att använda fraser som ”hello what can i help you with today” och ”i’m on it”.

Dialogen som den är nu kan tyckas möjlig att genomföra med en chatbot med n˚agra enkla regler, till exempel:

1) Fr˚aga efter information som saknas.

2) G¨or restaurangreservationen.

3) Avsluta dialogen.

Om m˚alet med chatboten ¨ar att skapa dialoger likt den i tabell IV skulle denna typ av regelbaserad bot kunna fungera.

Däremot kan den inte justera sitt beteende automatiskt om den misslyckas att slutföra dialoger med användare, varför RL- chatboten kan vara att föredra framför en regelbaserad i ett s˚adant fall. Dessutom skulle reglerna behöva göras om för varje ny domän chatboten används i medan RL-modellen är betydligt mer flexibel.

Tabell V inneh˚aller en dialog med en chatbot endast tränad med RNN. Här finns inget incitament för boten att slutföra dialogen s˚a snabbt som möjligt, utan istället försöker den efter- likna beteende den har observerat i lyckade dialoger. Dialogen

är fr˚an bAbi-datasetet och därför skiljer sig användarens fraser fr˚an den simulerade användaren som RL-boten interagerar med. Det är änd˚a uppenbart att RNN-boten använder fraser som bekräftar att den uppfattat användarens information, till exempel ”ok let me look into some options for you”.

2) Analys av träningstid: Arbetet syftar bland annat till att undersöka hur snabbt och till vilken kvalitet en chatbot kan tränas med RL. Resultatet visar att samtliga undersökta modeller snabbt konvergerar till optimalt beteende. Om filtret används hindras chatboten fr˚an att ställa fr˚agor om information den redan har eller föresl˚a en restaurang utan att ha all information, vilket gör att träningen g˚ar betydligt snabbare eftersom chatboten m˚aste lära sig detta själv annars. Att filtret hjälper är tydligt men spelar inte s˚a stor roll i sammanhanget av en simulator eftersom träningen g˚ar snabbt änd˚a. Däremot

är det viktigt att notera eftersom det kan spela en avgörande roll vid träning av en mer komplicerad chatbot. Om träning med RL enbart skulle ta för l˚ang tid kan filter göra stor nytta.

Om inte heller en användarsimulering är möjlig och boten direkt skulle behövas tränas med riktiga människor kan ett filter innebära en avgörande förbättring. Figur 3 (bl˚a linje) visar hur andelen lyckade dialoger g˚ar mot 100 procent redan efter 300 dialoger. Det betyder att även om inte chatboten fungerar optimalt hjälper den fortfarande användaren att utföra sitt ärende. Det bör även vara möjligt - i alla fall för denna uppgift - för utvecklarna av boten att själva interagera med den s˚a m˚anga g˚anger under rimlig tid.

Det intressanta är inte exakt hur snabb varje träning är utan det är magnituden som är relevant. I detta fall handlade det om minuter vilket f˚ar anses bra d˚a det förmodligen inte utgör ett hinder för utvecklingen av en chatbot. Det är enkelt att testa flera olika implementeringar och är inget problem att träna om modellen om s˚a önskas. RL-metoder i andra domän kan behöva dagar till m˚anader i träningstid vilket gör tiden till en stor begränsning. Dock är en RL-implementering mer komplex

än till exempel en regelbaserad modell, vilket självklart är n˚agot som ocks˚a bör tas hänsyn till. Om chatboten endast ska verka i en specifik domän och den endast förväntas föra triviala dialoger kan en regelbaserad chatbot vara att föredra.

B. Aff¨ars- och samh¨allsrelaterade perspektiv

1) SMEs och digital mognad: Detta projekt faller under samlingsnamnet automatiseringsteknologier, vilket är en av de tre digitala teknologier som har identifierats av Myndigheten för tillväxtpolitiska utvärderingar och analyser [15]. För att företag ska kunna nyttja dessa teknologier till sin fulla potential krävs en hög digital mognad. Ett m˚att p˚a digital mognad är det OECD-index som tagits fram och mäter utifr˚an dimensionerna ICT Capabilities, ICT Sophistication och Web Maturity hur digitalt moget ett företag är. Vad som har kunnat konstateras utifr˚an detta index är att företag vars kärnaktivitet inte involverar eller direkt beror av dessa dimensioner har en l˚ag digital mognad, dessutom hamnar SME-segmentet efter de stora företagen [15]. En anledning till att dessa har en generellt bättre digital mognad trots att det inte tillhör kärnaktiviteten skulle kunna bero p˚a att en större organisation kräver mer utvecklade system. Utöver detta har en större organisation mer resurser som kan allokeras till omr˚aden som inte tillhör kärnverksamheten men som kan bidra med affärsnytta.

Problemet som uppst˚ar för SME-sektorerna som ligger efter i digitaliseringen är att experterna samtidigt ser hur vardagliga uppgifter inom omr˚aden som kundsupport är de som är mest

(9)

sannolika att automatiseras inom tio ˚ar. Samtidigt anser ex- perter att det nödvändigtvis inte är de mest digitalt mogna sektorerna som kommer förändras mest inom denna tidsperiod [16]. Den framtid som m˚anga av dessa företag därför kommer kunna förvänta sig innebär att de i viss utsträckning kommer behöva använda automatiseringsteknologier som chatbotar. Av denna anledning kan chatbotar som liknar detta projekt vara ett bra alternativ för dessa företag d˚a de är förh˚allandevis enkla att anpassa efter användningsomr˚adet samt att de inte kräver samma mängd data som andra alternativ.

2) Samarbeta eller utveckla p˚a egen hand: Om dessa företag bestämmer sig för att börja tillämpa en ny teknologi kan de antingen välja att göra det helt p˚a egen hand eller samarbeta med ett eller flera andra företag. Det finns d˚a flera saker att ta hänsyn till och det kan ofta göra stora skillnad - avseende bland annat kostnad, tid och kvalitet - beroende p˚a vad som väljs.

Om företaget väljer att utveckla teknologin helt p˚a egen hand st˚ar detta ensamt för alla kostnader och risker och projektet kan bli dyrt. All ny kunskap som krävs, vilken företaget i detta fall inte besitter fr˚an början, behöver ocks˚a förvärvas vilket gör att processen ocks˚a kan ta l˚ang tid. En fördel med att inte samarbeta är att företaget har full kontroll

över produkten, dock är det mer relevant för n˚agot som tillhör ens kärnkompetens. Att utveckla n˚agot nytt p˚a egen hand passar vanligtvis bättre för företag som redan har erfarenhet inom omr˚adet.

Outsourcing skulle kunna ses som motsats till att företaget utvecklar p˚a egen hand. Det lämpar sig ofta om aktiviteten inte är n˚agot man redan är duktig p˚a och att det inte tillhör n˚agot som är viktigt för ens konkurrenskraft. Detta kan l˚ata passande för de företag som diskuterats, men ett problem

är att outsourcing ofta innebär att företaget utesluts fr˚an processen vilket gör att det inte förvärvar n˚agon ny kunskap.

Vet företaget att aktiviteten endast krävs för en begränsad tid skulle det inte vara n˚agon större fara, s˚a är dock inte fallet med digitalisering. Chatboten f˚ar snarare ses som ett första steg i en digital transformation och därmed kan företag ha stor nytta av att bygga kompetens inom omr˚adet samtidigt.

Istället föresl˚as det att välja n˚agot mellan utveckling p˚a egen hand och outsourcing. Även om dessa alternativ kan ses som motsatser - vilket gör spannet mellan alternativen brett - bör en mer exakt grad av samarbete anpassas för varje specifikt företag. Det är en balansg˚ang mellan ”capability complementation” och ”capability transfer”; till en början kanske just kompletteringen är det viktigaste för att f˚a ig˚ang chatboten men det l˚angsiktiga m˚alet bör även vara att företaget lär sig alltmer för att inte blir för beroende av annan part.

Datavetaren Dr. Bettina Horster [18] tycker inte att SMEs bör arbeta helt p˚a egen hand i början av sin digitala transformation eftersom det krävs s˚a mycket expertis. Istället föresl˚ar Horster att företagen hittar en partner som kan göra det ˚at dem eller ˚atminstone hjälpa till. Det kan vara s˚a lite som en workshop tillsammans vilket kan hjälpa en p˚a rätt väg och säkerställa att företaget inte börjar p˚a helt fel sätt. Horster rekommenderar även att börja lätt, till exempel med en aktivitet som inte är avgörande för företaget, till

exempel en chatbot som komplement i kundsupporten. Digital transformation behöver inte vara smärtsam för ett företag utan kan istället vara n˚agot som sker steg för steg. Att börja lätt och samarbeta med n˚agon med mer expertis är ett bra första steg för SMEs.

3) Affärsnytta: När ett företag väl väljer att implementera en chatbot för kundsupport är det viktigt att reflektera över hur stor del den kan och bör ersätta. ˚Asikter kring andelen av dagens jobb som kommer att automatiseras varierar kraftigt, där en modell tyder p˚a att 53 procent av alla jobb kommer att automatiseras i Sverige [16]. Samtidigt möter denna modell mycket kritik. Enligt modellen anses exempelvis fotomodell- yrket vara sannolikt att automatiseras. Detta anses orimligt och beror troligen p˚a de antaganden som har gjorts för modellen.

Istället för att ersätta hela yrken bör automatiseringen ses som ett komplement till mänskligt arbete [16]. En chatbot kan potentiellt ersätta en hel kundsupport men fr˚agan är om ett företag vill ge upp sin förm˚aga att göra ett personligt intryck. Det kan även visa sig att mängden arbete som krävs för att skapa en chatbot som klarar av alla komplicerade uppgifter inte är värt det. Därför är det viktigt att tänka p˚a att marginalnyttan m˚aste överstiga marginalkostnaden.

Istället för att l˚ata en chatbot sköta en hel kundsupport kan den som ett första steg ersätta en FAQ-sida. Inte sällan tycker användare att dessa är sv˚ara att navigera p˚a grund av all information som finns p˚a denna sida och trots det misslyckas svara p˚a den fr˚aga man har [19]. Det gör att användare undviker FAQ-sidor och istället försöker kontakta företaget direkt, till exempel genom att ringa vilket lätt blir tidskrävande för företaget [20]. En chatbot skulle kunna lösa problemet genom att användare direkt kan ställa en fr˚aga istället för att leta upp sin fr˚aga bland alla andra, samtidigt som företaget inte behöver lägga tid p˚a att svara p˚a samma fr˚agor om igen.

Faqbot är ett företag som bland annat hjälper företag att ersätta FAQ-sidor med chatbotar. De har även insett att m˚anga företag som inte haft en FAQ-sida innan änd˚a kan ha stor nytta av denna hjälp. Ett exempel är en kund som är inne p˚a en hemsida för kläder och ser en tröja som hen gillar, men skulle helst ha den i en annan färg. För att ta reda p˚a om det finns krävs normalt ett samtal till en butik, vilket en chatbot skulle kunna svara p˚a istället vilket ger kunden ett snabbare svar och personalen i butiken slipper bli avbruten [20].

Beroende p˚a typ av företag kan det sen ocks˚a vara viktigt att möjliggöra vidarekoppling till en mänsklig support om chatboten inte klarar av uppgiften. Ett exempel är hur Mavenoid, ett företag vars produkt är en uppgiftsorienterad AI-plattform för teknisk support, baserar sin produkt p˚a denna idé - enklare och ˚aterkommande problem kan en bot lösa medan det alltid

är möjligt att f˚a kontakt med en människa. Detta lämnar mer utrymme för den mänskliga kundsupporten att hantera de mer komplicerade uppgifterna och dessa kunder f˚ar d˚a snabbare svar p˚a sina fr˚agor genom en personlig support. P˚a s˚a sätt är det möjligt att b˚ade öka effektiviteten och kundnöjdheten [21].

Allt detta förutsätter däremot att chatboten är av tillräckligt god kvalitet ur b˚ade ett dialog-perspektiv och ett prob- lemlösnings-perspektiv. Om chatboten skulle prestera d˚aligt i n˚agot av dessa avseenden skulle det leda till att kunderna väljer den mänskliga kundsupporten i en majoritet av

(10)

fallen. Samtidigt anses feltoleransen vara hög i enkla arbetsuppgifter i jämförelse med mer komplicerade som exempelvis självkörande bilar [16]. Om kunderna har alternativet att kopplas vidare har inte chatboten speciellt stor p˚averkan p˚a kundnöjdheten. Däremot förutsätter detta att processen med en chatbot och att sen kopplas vidare fortfarande är effektivare än att vänta p˚a mänsklig kundsupport fr˚an början eller att skill- naden inte är signifikant. Om alternativet att kopplas vidare däremot finns ger det upphov till ett annat problem kring vad som är ett godtagbart resultat efter att chatboten integrerats i kundsupporten. Om chatboten klarar av att lösa ett problem

är kundsupporten med en chatbot redan effektivare än en utan dock skulle chatboten i jämförelse med andra chatbotar anses vara misslyckad. Problemet liknar det för en ”word predictor”

där ett godtagbart resultat omkring 40 procent verkar rimligt, men vidare tester skulle behöva genomföras för att fastställa hur användbar funktionen verkligen är [22].

4) Etiska aspekter: Transparens kring huruvida en person pratar med en bot eller riktig människa tas ofta upp som en viktig aspekt gällande chatbotar [23]. Till exempel i en kundsupport kan en kund känna sig lurad om den börjar misstänka att hen pratar med en bot och inte en riktig människa. Att inte vara tydlig med det fr˚an början är n˚agot som kan skapa misstro hos kunden. Det är bättre att vara uppriktig och gärna ocks˚a förklara chatbotens förm˚agor och begränsningar, vilket kan göra kunden mer förl˚atande d˚a chatbotar sällan förväntas prestera exakt som en människa.

En annan viktig aspekt för utvecklarna av en chatbot är att se till att den inte bryter mot lagar och regler. Rasism, diskriminering och kränkningar bör inte vara acceptabelt för chatbotar p˚a samma sätt som för människor. Om en chatbot ges för stor frihet är det viktigt att det finns verktyg för att förhindra eller upptäcka s˚adant beteende. Ett känt exempel p˚a detta är Microsofts Twitterbot Tay som började uttrycka sig rasistiskt efter att ha observerat och sedan härmat andra användare p˚a Twitter [24]. Det här arbetets chatbot löper inte denna risk d˚a den har förbestämda fraser, men skulle meningarna genereras av boten själv blir detta en viktig del att ta hänsyn till.

C. Framtida arbete

P˚a grund av arbetets begränsningar i b˚ade fokusomr˚ade och tid finns det m˚anga omr˚aden som skulle kunna vara intressant för vidare studier. Det mest uppenbara skulle vara att l˚ata riktiga användare interagera med chatboten över en längre tidsperiod och använda denna data som dataunderlag för test. D˚a skulle det även vara relevant att inkludera ett riktigt boknings-API för att generera riktiga förslag. Eftersom detta test skulle sträcka sig över en längre tidsperiod skulle det

även kunna vara intressant att bygga ut användarsimulatorn, alternativt hitta en ny som bättre liknar en mänsklig användare.

Det skulle vara intressant b˚ade i syfte att se hur resultatet förändras och även för att undersöka om ett mer komplett paket för UDS:er kan utvecklas som inneh˚aller b˚ade simulator och chatbot.

Det hade även varit givande att göra en studie av företag som redan implementerat chatbots i sin kundtjänst och undersöka

vilka förändringar de upplevt i b˚ade kundnöjdhet och väntetid.

Det skulle även vara intressant att se om det är n˚agra oväntade förändringar de upplevt efter implementeringen eller hur det p˚averkat kundsupporten i sin helhet. Ett annat forskning- somr˚ade skulle kunna vara att jämföra system med FAQ och UDS:er d˚a de fyller samma funktion. I samband med dessa studier skulle man kunna se om det g˚ar att ta fram en miniminiv˚a för success-raten ur ett kundperspektiv.

VII. SLUTSATS

Denna studie syftade till att undersöka hur effektivt - avseende tid och kvalitet - RL är för träning av uppgiftsorienterade chatbotar och hur dialogerna denna skapar skiljer sig fr˚an regelbaserade och RNN-modeller. Vad som kan konstateras är att RL visar god potential att ersätta andra träningsmetoder, d˚a den implementerade modellen kunde träna en chatbot till optimal p˚a n˚agra f˚a minuter. Dialogerna blev visserligen väldigt korta d˚a chatboten hade incitament att s˚a snabbt som möjligt bli klar. Det är möjligt att en mänsklig användare snabbt skulle avfärda boten d˚a den inte visade n˚agon bekräftelse p˚a att den uppfattat n˚agon information.

Dialogerna verkade ocks˚a s˚a triviala att en regelbaserad bot lika g¨arna skulle kunna fungera. Den RNN-tr¨anade chatboten

˚a andra sidan hade inget incitament att snabbt avsluta dialogen och kunde därför visa mer bekräftelse till användaren och p˚a s˚a sätt verka mer människolik. Däremot kan man se denna RL-chatbot som en förtränad version som sen kan börja interagera med mänskliga användare. Den kan d˚a - utan n˚agon modifiering av koden - lära sig att mer människolikt beteende och mer bekräftelse ökar sannolikheten för lyckade dialoger.

P˚a s˚a sätt är den ett intressant alternativ till en regelbaserad chatbot och även en RNN-tränad bot som kräver data p˚a lyckade dialoger.

Chatboten som skapades har potential att ersätta ett företags FAQ-sida som ofta ignoreras av kunder d˚a dessa är sv˚ara att navigera och ofta saknar svar p˚a kundens fr˚aga. M˚anga kunder tar istället direkt kontakt med företaget vilket kan vara tidskrävande för b˚ada parter. En chatbot som ersätter en FAQ- sida kan därför skapa affärsnytta genom att avlasta företagets kundsupport och samtidigt hjälpa kunderna snabbare.

När ett företag som har l˚ag eller ingen kompetens inom omr˚adet bestämmer sig för att implementera en chatbot kan samarbete med ett annat företag vara till stor nytta. Tv˚a kritiska fr˚agor som man d˚a bör ta ställning till är:

• Hur ser kompetensen ut inom f¨oretaget idag? Generellt:

ju lägre kompetens desto högre grad av samarbete bör sökas. Även om kompetensen är hög bör bolaget försöka hitta ett lättare samarbete för att maximera resultatet.

• Ar kompetensen inom omr˚adet viktig för företaget tem-¨ porärt eller permanent? Generellt: om endast temporärt kan outsourcing vara tillräckligt och om permanent bör företaget söka ett samarbete som möjliggör att de kan lära sig om tekniken samtidigt. Chatbotar kan dock ses som ett första steg i en digital transformation och därför bör de flesta företag undvika full outsourcing och ˚atminstone ha n˚agon form av lärandeprocess ig˚ang.

(11)

REFERENCES

[1] E. A. C. of Expertise, 2019 EDELMAN AI SURVEY, 2019.

[Online]. Available: https://www.edelman.com/sites/g/files/aatuss191/

files/2019-03/2019 Edelman AI Survey Whitepaper.pdf

[2] S. Makridakis, “The forthcoming artificial intelligence (ai) revolution:

Its impact on society and firms,” pp. 8,19, 01 2017.

[3] C. Smith, “An employee’s best friend? how ai can boost employee engagement and performance,” Strategic HR Review, vol. 18, no. 1, pp.

17–20, 2019.

[4] J. D. Williams, K. Asadi, and G. Zweig, “Hybrid code networks:

practical and efficient end-to-end dialog control with supervised and reinforcement learning,” CoRR, vol. abs/1702.03274, 2017. [Online].

Available: http://arxiv.org/abs/1702.03274

[5] R. J. Williams, “Simple statistical gradient-following algorithms for connectionist reinforcement learning,” Machine learning, vol. 8, no. 3-4, pp. 229–256, 1992.

[6] T. Wen, M. Gasic, N. Mrksic, L. M. Rojas-Barahona, P. Su, S. Ultes, D. Vandyke, and S. J. Young, “A network-based end-to-end trainable task-oriented dialogue system,” CoRR, vol. abs/1604.04562, 2016.

[Online]. Available: http://arxiv.org/abs/1604.04562

[7] H. Mei, M. Bansal, and M. R. Walter, “Coherent dialogue with attention-based language models,” CoRR, vol. abs/1611.06997, 2016.

[Online]. Available: http://arxiv.org/abs/1611.06997

[8] W. Shi, K. Qian, X. Wang, and Z. Yu, “How to build user simulators to train rl-based dialog systems,” Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), 2019. [Online]. Available:

http://dx.doi.org/10.18653/v1/d19-1206

[9] J. Ohmura, “Hybrid-code-networks,” Apr. 2018. [Online]. Available:

https://github.com/jojonki/Hybrid-Code-Networks

[10] “torch.nn.” [Online]. Available: https://pytorch.org/docs/stable/nn.html [11] “Google word2vec,” 2020. [Online]. Available: https://code.google.com/

archive/p/word2vec/

[12] “torch.autograd.” [Online]. Available: https://pytorch.org/docs/stable/

autograd.html

[13] M. D. Zeiler, “ADADELTA: an adaptive learning rate method,” CoRR, vol. abs/1212.5701, 2012. [Online]. Available: http://arxiv.org/abs/1212.

5701

[14] “torch.optim.” [Online]. Available: https://pytorch.org/docs/stable/optim.

html

[15] M. för tillväxtpolitiska utvärderingar och analyser, Företagens digitala mognad 2018, 2018.

[Online]. Available: https://www.tillvaxtanalys.se/download/18.

62dd45451715a00666f19db3/1586366155443/pm 2019 12.pdf [16] F. digitala kompetensbehov – en delphiinspirerad studie, Myndigheten

för tillväxtpolitiska utvärderingar och analyser, 2020.

[17] M. Schilling, Strategic Management of Technological Innovation, 01 2016.

[18] B. Horster, “How smes can approach digital transformation,” Dec 2018. [Online]. Available:

https://www.dotmagazine.online/issues/digital-production/

blockchain-and-Iot/how-smes-can-approach-digital-transformation [19] D. MacPherson, “No more faqs: Create purposeful

information for a more effective user experience,”

2020. [Online]. Available: https://alistapart.com/article/

no-more-faqs-create-purposeful-information-for-a-more-effective-user/

-experi/

[20] “how we went from making faq-pages into chatbots, even for companies without faq-pages,” 2020. [Online]. Available: https://chatbotslife.

com/how-we-went-from-making-faq-pages-into-chatbots-even-for/

-companies-without-faq-pages-8bc42148934f

[21] S. Lilja, “Customer support needs less talk, more troubleshooting,” 2018. [Online]. Available: https://blog.mavenoid.com/

customer-support-needs-less-talk-more-troubleshooting/

[22] K. Trnka and K. McCoy, “Evaluating word prediction: Framing keystroke savings,” in Proceedings of ACL-08: HLT, Short Papers.

Columbus, Ohio: Association for Computational Linguistics, June 2008, pp. 261–264. [Online]. Available: https://www.aclweb.org/anthology/

P08-2066

[23] T. Reddy, “The code of ethics for ai and chatbots that every brand should follow - watson blog,”

2020. [Online]. Available: https://www.ibm.com/blogs/watson/2017/10/

the-code-of-ethics-for-ai-and-chatbots-that-every-brand-should-follow

[24] E. Hunt, “Tay, microsoft’s ai chatbot, gets a crash course in racism from twitter,” 2020. [On- line]. Available: https://www.theguardian.com/technology/2016/mar/24/

tay-microsofts-ai-chatbot-gets-a-crash-course-in-racism-from-twitter

Jacob B˚ath född i april 1995, Stockholm. Jacob studerar sista ˚aret av sin kandidat inom Industriell ekonomi vid Kungliga Tekniska Högskolan (KTH) och ämnar därefter ta sin mastersutbildning inom maskininlärning.

Zac Bauer född i juni 1997, Stockholm. Zac studerar sista ˚aret av sin kandidat inom Industriell ekonomi vid Kungliga Tekniska Högskolan (KTH) och ämnar därefter ta sin mastersutbildning inom maskininlärning.

F¨orfattarna har bidragit lika mycket till arbetet.

(12)

www.kth.se