Standaard voorbeelden van deze opstelling zijn bijvoorbeeld computerspellen, waar feedbacksignalen aanwezig zijn zoals winnen, verliezen, en allerlei andere scores. Onderzoekers maken technieken die een systeem toelaten om zelfstandig complexe taken aan te leren, en spellen zijn de ideale testomgeving daarvoor omdat ze tegelijk complexe situaties aanbieden maar toch afgeschermd zijn van de echte wereld (“sandbox” omgevingen). Intrigerende resultaten in dit gebied zijn onder andere behaald door het bedrijf DeepMind, dat een artificiële intelligentie (AI) ontwikkelde om Atari games te spelen.

Resultaten van deze vorm hebben geleid tot een enorme vloedgolf van interesse, die onder andere tot uiting kwam in het ontwikkelen van een platform waarmee onderzoekers hun leer-technieken kunnen uitproberen op vele computerspellen; dit platform heet OpenAI Universe.

Reinforcement learning

In deze blog gaan we enkele concepten verkennen die aan bod komen in het ontwikkelen van dergelijke systemen. We zullen in het bijzonder onze aandacht richten op het gebied van reinforcement learning. Een standaard boek hierover is die van Sutton en Barto (1998). Op het moment dat we deze blog schrijven is een tweede editie van dit boek in aanmaak. In de tweede editie zal er onder andere aandacht gaan naar technieken die ontwikkeld zijn door DeepMind.

In reinforcement learning noemt men het lerende systeem meer specifiek een agent, dus een entiteit die moet ageren (handelen). Deze agent voert acties uit op een omgeving. Op elk ogenblik bevindt de omgeving zich in een welbepaalde toestand. Voor de eenvoud in deze blog zullen we aannemen dat de agent exact kan waarnemen in welke toestand de omgeving zich bevindt. Deze aanname wordt vaak gedaan bij het bestuderen van de basistheorie van reinforcement learning, hoewel deze aanname meestal niet waar is in de echte wereld (hierop komen we later terug).

Op elk ogenblik kiest de agent een actie op basis van de waargenomen toestand (van de omgeving). Deze actie wordt gekozen uit een vaste verzameling van mogelijke acties. De agent past vervolgens de gekozen actie toe op de omgeving, waarna het volgende gebeurt:

• Op basis van de huidige toestand van de omgeving en de toegepaste actie, bepaalt de omgeving een nieuwe toestand voor zichzelf.
• De omgeving stuurt de nieuwe toestand terug naar de agent, gekoppeld met een numeriek feedback signaal.

Na de nieuwe toestand van de omgeving te hebben ontvangen, zal de agent ook voor die toestand een actie kiezen om uit te voeren. Dit proces herhaalt zich typisch voor onbepaalde tijd. De omgeving houdt voortdurend zijn huidige toestand bij. Intuïtief bekeken, door vele acties uit te voeren kan de agent lange paden afleggen in de ruimte van mogelijke toestanden van de omgeving.

Illustratie op Pong

We gaan deze begrippen illustreren met een concreet spel, namelijk, Pong. Dit spel bestaat uit een bal en twee balken, eentje aan de linkerzijde van het scherm en eentje aan de rechterzijde van het scherm. Elke balk kan enkel vertikaal bewegen. De rechterbalk wordt bijvoorbeeld bestuurd door het spel zelf (als opponent), en de linkerbalk door de speler. De speler heeft op elk ogenblik slechts twee toetsen (of acties) ter beschikking: een eerste toets om de balk een beetje omhoog te laten gaan, en een tweede toets om de balk een beetje naar beneden te laten gaan. Het spel verloopt in een beperkt aantal ronden. Aan het begin van een ronde vertrekt de bal vanaf de balk van een van de twee partijen. De tegenpartij moet de bal dan terugkaatsen, waarna de eerste partij ook de bal moet proberen terug te kaatsen, enz. Een ronde eindigt als de bal wordt gemist door een partij.

Op dit spel zouden we reinforcement learning kunnen toepassen, waardoor we de algemene begrippen van reinforcement learning kunnen associëren met meer concrete zaken:

• Het spel is de omgeving.
• Op elk moment bevindt het spel zich in een welbepaalde toestand, waarin onder andere de volgende zaken worden geregistreerd: de huidige positie van de balken, de eerstvolgende bewegingen die zullen worden toegepast op de balken, de positie en bewegingsrichting van de bal, en hoeveel keer elke partij al verloren heeft.
• De speler wordt aangestuurd door de agent, en deze bestuurt bij afspraak bijvoorbeeld steeds de linkerbalk.
• Terwijl de bal beweegt van de ene zijde van het scherm naar de andere zijde, past de agent tijdens elk ogenblik een van de volgende drie acties toe: zijn balk omhoog bewegen, zijn balk omlaag bewegen, en niets doen. De gekozen actie wordt telkens gereflecteerd in de resulterende toestand van het spel.
• De numerieke feedback tijdens elke (tijd)stap kan als volgt uitgewerkt worden. Als geen partij de bal mist dan is de feedback neutraal, uitgedrukt met waarde 0. Als de agent de bal mist dan kan een sterk negatief getal worden gegeven als feedback. Als de opponent de bal mist (waardoor de agent de ronde wint) dan kunnen we een sterk positief getal geven als feedback.

Waarde leren inschatten

In het algemeen is het bij reinforcement learning de bedoeling om de agent acties zodanig te laten kiezen dat gewenste resultaten ontstaan. Bij computerspellen is een gewenst resultaat bijvoorbeeld het spel succesvol beëindigen, of een bepaalde score zo hoog mogelijk maken.

In essentie moet de agent voor elke toestand waarin hij terechtkomt een rangschikking kunnen maken van de acties, volgens hun verkiesbaarheid. Een bekende techniek daarvoor is Q-learning, een leer-algoritme dat (via de numerieke feedbacksignalen) per toestand-actie koppel een getal berekent dat de verkiesbaarheid voorstelt van die actie in die toestand. Dat getal noemt men ook wel de waarde (Engels: value). Men neemt in reinforcement learning theorie vaak aan dat er slechts een eindig aantal toestanden en acties zijn, zodat het systeem voldoende vaak eenzelfde toestand-actie koppel kan uitproberen.

De intuïtie achter de waarde-inschatting is dat de agent leert anticiperen waar de grote positieve feedback signalen zitten, en probeert om daarheen te sturen. Op elk pad dat de agent aflegt in de ruimte van toestanden (van de omgeving) worden alle feedback signalen opgeteld, zowel de positieve als de negatieve, waardoor een soort totaalscore per pad ontstaat. De agent moet op die manier leren wat de beste paden zijn. Er is ook een toevoeging van de tijd-dimensie: een verre toekomstige beloning kan minder waardevol overkomen in het heden dan een kleinere beloning die vlugger kan bekomen worden. De Engelse term hiervoor is discounting.

Men kan de intuïtie van waarde-inschattingen voorstellen als een navigatieprobleem op een kaart. De agent wil bijvoorbeeld naar een bepaald doel toegaan, waar een grote beloning te verkrijgen is. Elke plaats op de kaart stelt een toestand voor, en de agent kan navigeren op de kaart door bepaalde richtingen uit te gaan; deze richtingen komen overeen met de acties uit de reinforcement learning theorie. Tijdens de reis moet de agent echter ook obstakels of gevaren ontwijken, die worden voorgesteld met negatieve feedback signalen. Meestal is de interactie van de agent met de omgeving van onbepaalde duur, zodat de agent steeds beter kan leren navigeren. Om dit effect te bekomen wordt de agent bij het bereiken van het doel teruggestuurd naar een andere startlocatie, om van daaruit opnieuw naar een doel te navigeren.

Verdere stappen

Tot zover hebben we de aandacht gevestigd op enkele basisbegrippen in reinforcement learning. We bespreken nu kort enkele richtingen die men vervolgens zou kunnen verkennen na deze basis.

Niet-determinisme

We zeggen dat een omgeving niet-deterministisch is als, bij het toepassen van een actie op de huidige toestand, de nieuwe toestand niet exact kan voorspeld worden. Anders gezegd: bij het toepassen van een actie op de omgeving kan de nieuwe toestand willekeurig worden gekozen uit een aantal mogelijke opvolger-toestanden. Ongeacht of de echte wereld deterministich is of niet, kan men sowieso taken bedenken voor reinforcement learning die niet-deterministisch zijn vanuit het perspectief van de agent. Bijvoorbeeld, men kan een computerspel ontwikkelen waarbij de beslissingen van een computer-gestuurde opponent worden beïnvloed door willekeurige beslissingen; in Pong zou de opponent bijvoorbeeld op onvoorspelbare momenten zijn balk omhoog of omlaag kunnen sturen. De agent zal in dat geval mogelijk meer aandacht moeten geven aan de beweging van de bal in vergelijking met de beweging van de tegenstander.

In de theorie van reinforcement learning stelt men niet-determinisme bijvoorbeeld voor door een waarschijnlijkheidsverdeling te introduceren waarmee de opvolger-toestanden worden gekozen van elk toestand-actie koppel.

Beperkte waarneming

In de echte wereld kunnen organismen slechts in beperkte mate de omstandigheden waarnemen waarin ze zich bevinden. Hierdoor is de conceptvorming van het organisme over de omgeving eerder beperkt, waardoor het organisme niet exact kan voorspellen wat er in de nabije toekomst zal gebeuren. Vanuit het perspectief van het organisme gedraagt de omgeving zich als het ware niet-deterministisch. Ook bij computerspellen, zoals de Atari spellen bestudeerd door DeepMind, is de agent typisch zeer beperkt in het waarnemen van informatie: de projectie die elk ogenblik verschijnt op het scherm is vaak een vereenvoudigde weergave van de vele achterliggende mechanismen die het spel aansturen.

Het thema van beperkte waarneming wordt ook uitgebreid bestudeerd in de theorie en praktijk van reinforcement learning.  Men modelleert dit bijvoorbeeld via zogenaamde partially observable processen, waarbij de agent op elk ogenblik niet rechtstreeks de toestand van de omgeving kan waarnemen maar slechts een beperkte projectie daarvan.

Conclusie en vooruitblik

Reinforcement learning bestaat al een lange tijd. De recent toegenomen aandacht voor dit thema is onder andere ontstaan door experimenten op computerspellen. Het voordeel van computerspellen is dat deze een veilige testomgeving vormen voor allerlei reinforcement learning technieken. Hierdoor is het mogelijk voor vele onderzoekers om veilig en redelijk goedkoop geavanceerd AI onderzoek te doen.

Maar reinforcement learning wordt ook toegepast in de echte (fysieke) wereld. Een voorbeeld van dit laatste is het besturen van robots in een fabriek. Via geschikte feedback kan een fabrieksrobot leren om vlug en efficiënt te handelen, en om bepaalde problemen of obstakels te vermijden. Er kan bijvoorbeeld een beloning gegeven worden als de robot een voorwerp op een goede plaats zet, en er kan een strafscore worden toegekend als de robot te traag is of ergens tegenaan botst.

De vloedgolf van interesse in AI, zowel rond het thema van reinforcement learning als het thema van deep learning, veroorzaakt een vraag van ondernemers en onderzoekers naar voldoende toegankelijke technieken. Er ontstaan initiatieven om aan deze vraag te voldoen. Bijvoorbeeld, het bedrijf bons.ai heeft een nieuwe manier van programmeren bedacht, genaamd pedagogisch programmeren, waarmee een ontwikkelaar kan aangeven welke kennis een systeem moet aanleren maar zonder concreet te programmeren op welke manier dit moet gebeuren. Een belangrijke component in de methodologie van bons.ai is het geven van feedback aan het lerende systeem, precies zoals dit bij reinforcement learning voorkomt. Het grote voordeel dat bons.ai wil aanbieden aan haar klanten is dat men AI kan inschakelen zonder de technische details te begrijpen van de krachtige technieken. De verwachting is dat er meerdere van dergelijke initiatieven zullen verschijnen om geavanceerde AI technieken breder inzetbaar te maken.

Men zou bijvoorbeeld inzichten kunnen afleiden uit gegevens van overheden. Het is nuttig om dit proces uit te voeren op een computer want we zouden liever niet manueel grote hoeveelheden gegevens lezen om de interessante patronen en verbanden af te leiden. Bovendien valt een inzicht misschien pas op als de gegevens worden gelezen in de goede volgorde, bijvoorbeeld door een aantal stukjes informatie te lezen vlak na elkaar die allemaal eenzelfde interessante patroon bevatten. Men weet typisch niet op voorhand welke patronen aanwezig zijn, dus kan men de gegevens niet sorteren om de patronen er manueel uit te halen. Het vinden van patronen laten we daarom best door een computer gebeuren, die vele mogelijkheden kan overwegen.

In deze blog bespreken we een algemeen idee gebaseerd op principes uit Data Mining. We bespreken concreet het principe van regels. Een regel van de vorm A → B drukt de voorspelling uit dat patroon B voorkomt als patroon A wordt waargenomen. We lezen de regel dus als volgt: “als A dan B”. Dergelijke voorspellingen kunnen gebruikt worden om suggesties te doen, om anomalieën te detecteren, en om automatisch beslissingen te nemen.

We vertrekken vanuit de observatie dat veel gegevens van een overheid in gestructureerde vorm worden opgeslagen. Voorbeelden van dergelijke gegevens zijn:

• de data waarop de identiteitskaart van een persoon is uitgegeven,
• de voorgaande en huidige domicilieadressen van elke burger,
• de hoeveelheid belasting die elke burger heeft betaald per jaar,
• de bijdragen aan de sociale zekerheid die elke werkgever heeft betaald per kwartaal.

Gestructureerde gegevens staan in contrast met vrije tekst, afbeeldingen, video’s, geluid, enz.

Patronen en regels

In het vervolg nemen we voor de eenvoud aan dat elke gestructureerde gegevensbron conceptueel bestaat uit een verzameling van entiteiten, zoals mensen, gebouwen, bedrijven, enz. We bekijken elke entiteit als een verzameling van attributen, waarbij elk attribuut een key-value paar is.

We definiëren een patroon als een combinatie van constraints op individuele attributen. De “support” van een patroon X is het aantal voorkomens (of de relatieve frequentie) van X over alle entiteiten heen. Ter illustratie beschouwen we de volgende tabel:

Elke rij stelt een entiteit voor, in dit geval een persoon. Voorbeelden van patronen zijn:

• Straat = “Straat A”;
• Leeftijd > 35;
• Leeftijd > 35 en Gebied_code = 3000.

De support van deze patronen zijn, respectievelijk: 1 rij, 3 rijen, en 2 rijen.

Als we vanuit de gestructureerde gegevens zouden kunnen leren welke patronen vaak samengaan, kunnen we het ene patroon voorspellen na de observatie van een ander patroon. In het bijzonder zouden we regels kunnen leren van de vorm A → B, waar A en B patronen zijn. Deze regel zegt dat als we patroon A zien dat we dan patroon B verwachten. Bij elke regel hoort een betrouwbaarheidsscore, gedefinieerd als volgt:

De betrouwbaarheid van A → B is de support van het gecombineerde patroon A + B gedeeld door de support van patroon A.

Merk op dat het gecombineerde patroon A + B typisch strenger is dan patroon A, en daardoor enkel kan aanwezig zijn in de entiteiten die reeds voldoen aan patroon A. Daardoor is de support van A + B kleiner of gelijk aan de support van A. Intuïtief bekeken, drukt de betrouwbaarheid uit hoe zeker we zijn om patroon B te voorspellen als we patroon A waarnemen.

In het bovenstaande voorbeeld, zouden we de volgende regels kunnen afleiden uit de gegevens:

• Met 2/2 betrouwbaarheid (100%), als Straat= “Straat B” en Gebied_code = 3000 dan (→) Taal = “Frans”;
• Met 2/3 betrouwbaarheid (66%), als Gebied_code = 3000 dan (→) Taal = “Frans”.

Met regels zouden we de volgende toepassingen kunnen uitwerken:

• Men kan waarden voor een attribuut suggereren op basis van andere attributen. Dit zou men decision support kunnen noemen.
• Wanneer een entiteit wordt aangemaakt (of gewijzigd), kan men controleren dat bepaalde verwachtingen rond de attributen voldaan zijn. Anders gezegd: men kan verwachtingen gebruiken als beperkingen. Schendingen van verwachtingen kunnen gemeld worden als anomalieën.

Beide mechanismen zijn gebaseerd op voorspellingen, zoals we hieronder zullen toelichten. Met kennis van de regel A → B kunnen we suggereren dat patroon B kan toegepast worden nadat patroon A wordt waargenomen. Als een beheerder verantwoordelijk blijft voor de uiteindelijke beslissing, dan bekijken we regels enkel als een suggestie-mechanisme. In de context van anomalie-detectie kunnen we een melding sturen naar de beheerder wanneer een voorspelling wordt geschonden bij een entiteit. Ter illustratie:

• Stel dat de bovenstaande voorbeeld-gegevens van personen uit een enquête zouden komen, en dat mensen soms vergeten hun taal in te vullen. In dat geval zouden we kunnen overwegen om een suggestie-mechanisme aan te bieden dat de taal afleidt uit de straat en de gebiedscode. Natuurlijk hangt het af van de toepassing of de voorgestelde waarden aanvaardbare plaatsvervangers zijn, of dat meer echte gegevens moeten verzameld worden.
• Als een voorbeeld van anomalie-detectie, stel dat we proberen om de volgende entiteit toe te voegen aan de tabel: Staat= “Straat B”, Gebied_code = “3000”, en Taal = “Nederlands”. De eerste regel hierboven zou dan geschonden zijn. Als de betrouwbaarheid van een geschonden regel hoog is, zoals hier (100%), dan zou het nuttig kunnen zijn om de anomalie te melden aan een beheerder. Afhankelijk van de toepassing, zou anomalie-detectie kunnen helpen bij het vinden van administratieve fouten of problemen met entiteiten.

Als een regel voldoende wordt vertrouwd, en de patronen erin voldoende concreet zijn, dan kan de regel ook automatisch worden uitgevoerd om gegevens aan te vullen of te veranderen. Daarom zouden regels een manier kunnen zijn om automatisering te bekomen.

Toepasbaarheid

Men zou regels kunnen leren uit verschillende vormen van gestructureerde gegevens zoals:

1. Standaard tabellen zoals in het bovenstaande voorbeeld.
2. XML of JSON gegevens wanneer de diepte van deze structureren op voorhand begrensd is.
3. Doorlopende “streams” waar gestructureerde formaten worden gebruikt om individuele boodschappen voor te stellen. Het leren van regels over streams kan real-time aanvulling van gegevens of anomalie-detectie mogelijk maken.

Nuttige eigenschappen

We bespreken enkele nuttige eigenschappen van het automatisch afleiden van regels:

Aanvullende opmerkingen

Verwante onderzoeksgebieden

We geven enkele wetenschappelijke onderzoeksgebieden verwant aan het thema in deze blog (Engelstalige terminologie):

• association rule mining,
• inductive logic programming,
• knowledge representation and reasoning.

Slim gokken

In het algemeen zijn er teveel mogelijke patronen en regels om systematisch op te sommen of op te slaan. Maar men kan patronen en regels proberen slim te gokken. Het is in principe ook mogelijk om variaties van bestaande regels te verkennen, ten einde

• meer algemene regels te vinden;
• of om regels met lage betrouwbaarheid om te vormen naar regels met hogere betrouwbaarheid, bijvoorbeeld door een meer specifiek patroon te gebruiken in de preconditie.

Trade-off: betrouwbaarheid en support

Er zit een trade-off tussen betrouwbaarheid en support. Regels gebaseerd op gedetailleerde patronen zouden heel betrouwbaar kunnen zijn, maar helaas met een te kleine support om statistisch significant te zijn. Een kleine support duidt immers op zeldzaamheid van het patroon. Daarom zou men aandacht kunnen besteden aan representaties van patronen die zorgen voor een grotere support. Hulpmiddelen daarvoor zijn:

• beperkingen op getal-attributen kan men weergeven met intervallen (en niet met concrete waarden);
• gebruik maken van de NOT operator (“niet”), om te zeggen dat een attribuut niet een bepaalde waarde heeft;
• gebruik maken van de OR-operator om meerdere specifieke patronen te bundelen.

Bijvoorbeeld, door te zeggen NOT Straat = “Straat Z”, laten we toe dat het straat-attribuut zeer veel waarden kan aannemen, zolang het maar niet “Straat Z” is, zoals: “Straat A”, “Straat B”, “Straat C”, en tal van andere mogelijke waarden. De support van het patroon NOT Straat = “Straat Z” kan daarom heel hoog zijn in een concrete tabel.

We geven nu een voorbeeld van het gebruik van de OR-operator. Beschouw het volgende patroon, waarbij we voor de leesbaarheid telkens een komma schrijven om “and” voor te stellen:

P= (a OR b), (u OR v), (x OR y).

Patroon P vervangt de volgende verzameling van specifieke patronen waarin enkel de  AND-operator wordt gebruikt (ook weer vervangen door komma):

• a, u, x
• a, u, y
• a, v, x,
• a, v, y,
• b, u, x,
• b, u, y
• b, v, x,
• b, v, y.

De support van P kan veel hoger zijn dan de support van de individuele AND-patronen. Dit voorbeeld illustreert bovendien dat een representatie met een geneste OR-operator efficiënter kan zijn voor de opslag van de patronen en regels.

On peut attribuer automatiquement des catégories à petits morceaux de texte, avec Watson Natural Language Classifier de IBM.

Avec Api.ai de Google on peut développer des chatbots qui comprennent les langues naturelles sous forme de texte.

Alvorens we in details treden, willen we graag nog even de aanpak situeren in een groter geheel. Een eerste belangrijke eigenschap van de aanpak is dat deze manueel is: we moeten handmatig een script opstellen van het gedrag (of de redeneringen) van de chatbot. Dit is een ontwerp-oefening, die meestal in teamvorm wordt uitgevoerd, bijvoorbeeld met een ontwerper en een tester. (Opmerking: We bespreken een alternatief voor de manuele aanpak in het addendum van deze blogpost).

In het vervolg van deze blog gaan we verder met de manuele aanpak, waarbij we de dialoog zelf moeten ontwerpen. De ontwerper zorgt er zelf voor dat de gegenereerde uitspraken passend zijn. Dit is een beproefde methode, die al wordt toegepast sinds het ontstaan van chatbots. Essentieel probeert een dergelijke chatbot bepaalde keywords of combinaties van keywords te herkennen. Echter, een moderne toevoeging aan dit principe is de zogenaamde “natural language processing”, waarbij uit training data wordt geleerd welke keywords belangrijk zijn, zonder dat iemand dit manueel moet programmeren.

In de manuele aanpak, bestaat een mogelijke strategie van de ontwerper uit de volgende deeltaken:

• In samenspraak met eindgebruikers, bepaal de intenties die de eindgebruiker zou willen communiceren aan de chatbot. Deze intenties zou men kunnen beschouwen als een soort commando’s die de chatbot zal verstaan en uitvoeren.
• Voor elke intentie moet training data verzameld worden om de keywords (of combinaties daarvan) te leren die kenmerkend zijn voor die intentie. Voor deze training data volstaan fragmenten of losse zinnen (zonder een bijhorend volledig gesprek).
• Bepaal of bij sommige intenties wedervragen moeten gesteld worden, ofwel om de intentie te verduidelijken ofwel om ontbrekende stukjes informatie op te vragen. Dit leidt tot een ontwerp van dialoog flow, bijvoorbeeld in de vorm van een decision tree.

Er zijn talrijke software platformen beschikbaar waarmee men manueel dialoog kan ontwerpen. Enkele voorbeelden: IBM Watson Conversation, Api.ai, Wit.ai, en recast.ai.

Ondiepe dialoog

In de manuele aanpak tot chatbots, kunnen we een onderscheid maken tussen diepe en ondiepe dialoog. Bij (visuele) inspectie van een decision tree of netwerkstructuur van de dialoog, zou men van ondiepe dialoog kunnen spreken als de chatbot eenduidig een antwoord kan geven na slechts één of twee wedervragen gesteld te hebben (of zelfs geen wedervragen, waarbij intenties meteen duidelijk zijn en kunnen afgehandeld worden).

De technische uitleg en demonstratie van chatbot-platformen gebeurt heel vaak met ondiepe dialoogstructuren. Bijvoorbeeld, IBM Watson Conversation heeft de car demo. Daarin speelt de chatbot de rol van intelligente auto. De gebruiker kan vragen om het licht aan of uit te doen (“turn light on/off”); waarbij geen wedervragen van de chatbot nodig zijn. Een ander commando is de radio aanzetten (“turn radio on”). In het geval van de radio vraagt de chatbot eerst naar het type muziek (met keuze uit een vaste lijst); er is dus één wedervraag nodig. Een ander commando is het rijden naar een restaurant (“find food”); in dat geval zal de chatbot twee wedervragen stellen, om (1) het type gerecht en (2) de voorkeurslocatie van het restaurant te vragen. Bij deze car demo komen de wedervragen van de chatbot telkens overeen met het vragen naar een beperkt aantal parameters, waardoor de diepte van de dialoog beperkt blijft.

Een vorige blogpost bespreekt een methode om diepe dialoog te ontwerpen. Echter, diepe dialogen kunnen een uitdaging vormen om te ontwerpen, en vergen vermoedelijk meerdere design- en test-iteraties. Daarom gaan we in de rest van deze blog onze ervaringen bespreken met het ontwerp van ondiepe dialoog. Het blijkt dat dergelijke chatbots relatief overzichtelijk kunnen zijn, en geen volledig team vereisen om te ontwikkelen.

Acties en context

Alvorens we onze ervaring met het ontwikkelen van ondiepe dialoog kunnen toelichten, hebben we nog een paar extra concepten nodig, namelijk, (1) het uitvoeren van acties en (2) context.

Een veelvoorkomend principe bij chatbot-platformen is het koppelen van acties aan intenties. Men herkent dan niet alleen welke intentie er werd opgegeven door de gebruiker (wat nodig is om de dialoog-flow te sturen), maar men roept tegelijk een functie aan op een losstaand systeem. De technische manier om een dergelijke functie-oproep te implementeren gebeurt via een zogenaamde “webhook”, wat een webserver is die data ontvangt van het chatbotplatform. De doorgestuurde data bestaat uit twee delen:

• De naam van de actie die op de webserver moet uitgevoerd worden, en
• De parameters die daarbij nodig zijn.

In de car demo van IBM Watson Conversation, in de intentie van de radio aanzetten, zou een gekoppelde actie bijvoorbeeld kunnen zijn: “play-music”, met een genre-parameter.

Om dergelijke actie-koppelingen mogelijk te maken, gaat de chatbot parameters bijhouden in zijn werkgeheugen. Men kan dit werkgeheugen zien als een verzameling van key-value paren. Elke parameter heeft een unieke naam (de key) en een bijhorende waarde. In het vakjargon duidt men deze verzameling van key-value paren aan als de context (bijvoorbeeld bij Watson Conversation en api.ai).

Vaak laten de chatbot-platformen die acties ondersteunen ook toe om de context aan te passen. Zo wordt het via chat mogelijk voor de eindgebruiker om key-value paren te toe voegen, te verwijderen, of aan te passen. De eindgebruiker kan dit ervaren als flexibel omdat de volgorde van de aanpassingen soms minder van belang is; vooral belangrijk is welke key-value pairs de chatbot in zijn context heeft.

Opmerking

Het koppelen van acties aan intenties lijkt op standaard functie-oproepen met parameters in programmeertalen. Dit idee past dus vrij goed in de denkwereld van programmeurs.

Dimona case

In de Belgische sociale zekerheid zijn bepaalde werkgevers verplicht om een onmiddellijke aangifte te doen van de tewerkstelling van hun werknemers. De naam van een dergelijke aangifte is Dimona, een afkorting van “Déclaration Immédiate/Onmiddellijke Aangifte”. Het begin van de tewerkstelling wordt gemeld via een Dimona-IN, en het aflopen van de tewerkstelling gebeurt met een Dimona-OUT. In beide gevallen zijn drie belangrijke gegevens nodig, namelijk:

• Een identificerend nummer voor de werkgever; we zullen voor de eenvoud veronderstellen dat dit altijd het RSZ-nummer is van de werkgever.
• De identiteit voor de werknemer; we zullen daartoe het rijksregisternummer veronderstellen.
• Een datum. Bij een Dimona-IN hoort een startdatum, en bij een Dimona-OUT een einddatum.

Men zou in principe een chatbot kunnen maken waarmee werkgevers Dimona aangiften kunnen doen, gebaseerd op een eenvoudige dialoog. Voor elk type Dimona aangifte dat de werkgever wil uitvoeren, verstrekt de werkgever de benodigde informatie aan de chatbot. De chatbot begeleidt dit proces nauwgezet door ontbrekende informatie op te vragen. Daartoe volstaat een ondiepe dialoog: de werkgever geeft een commando om een aangifte te doen van type “in” of “out”, en de chatbot moet enkel vragen om ontbrekende gegevens aan te vullen (bijvoorbeeld als de werkgever nog geen rijksregisternummer van de werknemer heeft opgegeven).

Om het verband te leggen naar de bovenstaande algemene uitleg van key-value pairs, bestaat het werkgeheugen van de Dimona chatbot uit:

• het RSZ-nummer van de werkgever,
• het rijksregisternummer van de werknemer,
• een startdatum (enkel nuttig bij Dimona-In), en
• een einddatum (enkel nuttig bij Dimona-Out).

De werkgever kan de gegevens van dit werkgeheugen aanpassen in een willekeurige volgorde. Bijvoorbeeld, men kan eerst het rijksregisternummer geven en pas daarna een datum, of omgekeerd. Hierdoor moet de werkgever enkel de intentionele commando’s kennen van de chatbot, en geen strikte volgorde daarvan.

We hebben dit ontwerp kunnen implementeren met api.ai, maar het zou in principe ook kunnen gebeuren met IBM Watson Conversation.

Conclusie

Als een praktische use case toelaat om de dialoog op een ondiepe manier uit te werken, kan men overwegen om manueel chatbots te ontwikkelen. Een aantal eigenschappen van het manuele ontwerp van ondiepe dialoogstructuren zijn:

• Vele chatbot-platformen ondersteunen dit.
• De overzichtelijkheid ten gevolge van de ondiepe dialoogstructuur maakt het mogelijk om een chatbot te ontwikkelen met een klein team en bescheiden middelen. De technische invalshoek, waarbij intenties worden gezien als functieoproepen (“function calls”) met parameters, past in de denkwereld van programmeurs. Hierdoor kan bestaand IT personeel worden ingeschakeld om chatbots te helpen ontwikkelen.
• Het is relatief eenvoudig om nieuwe intenties toe te voegen, althans als de nieuwe intentie voldoende verschilt van reeds bestaande intenties qua training data.

Echter, zoals opgemerkt in een vorige blog, hebben chatbot-platformen meestal geen ondersteuning voor spellingsfouten. Ofwel wordt van de eindgebruiker vereist dat hij correcte spelling gebruikt, ofwel moet er een automatische correctie gebeuren op voorhand (waarbij men moet opletten om geen verkeerde vervangingen te doen).

Addendum: semi-automatische aanpak

Ter volledigheid merken we op dat er naast de manuele aanpak ook een semi-automatische aanpak bestaat. Bij een semi-automatische oplossing wordt geleerd uit gespreksdata welke uitspraken van eindgebruikers belangrijk of frequent zijn, en bovendien wat een gepast antwoord daarop zou kunnen zijn. We vermelden graag het woordje “semi” omdat men relevante gespreksdata moet verzamelen of opzoeken (vaak een niet-geringe inspanning).

Een voorbeeld van een semi-automatische chatbot is Chatterbot. De training data bestaat uit (zin, antwoord)-koppels. Telkens als een eindgebruiker iets schrijft wordt de input vergeleken met de zinnetjes in de data; het antwoord bij het best passende zinnetje wordt teruggegeven. De voortzetting van de dialoog gebeurt eerder op een adhoc manier, waardoor weinig controle is op de kwaliteit van het gesprek. Voor chatbots in de context van overheden is het evenwel belangrijk om correct en voorspelbaar te zijn, waardoor we voorlopig minder geïnteresseerd zijn in dergelijke adhoc chatbots.

Ter volledigheid merken we op dat een nieuwe categorie van een semi-automatische chatbots wordt vertegenwoordigd door Amelia van IpSoft. Dit product is gebaseerd op principes van het menselijk brein, en behoort tot de state of the art. De training bestaat uit het toelaten aan Amelia om echte chatconversaties mee te lezen, tussen bijvoorbeeld een medewerker en een klant. Geleidelijk leert Amelia hoe een gesprek moet opgebouwd worden, en welke acties zij mag (of moet) ondernemen. Op dat moment kan zij zelf in contact treden met klanten. Dit product lijkt voorlopig vrij uniek te zijn op de markt. We kunnen echter nog niet uitweiden over onderwerp, omdat de principes en kosten-baten verhoudingen van Amelia ons nog niet bekend zijn.

Met chatbot-technologie kan je bestaande toepassingen of websites verrijken met een interactieve ervaring voor de eindgebruiker. Bijvoorbeeld, aan een website kan men een chatvenster toevoegen waarmee de eindgebruiker eenvoudige vragen kan doorgeven aan de chatbot. Als de chatbot reeds kan antwoorden op veelgestelde vragen, kan de toegankelijkheid van de website worden verhoogd.

Deze toepassing brengt ons naar zogenaamde “frequently asked questions”, afgekort FAQ. Een FAQ is een verzameling van (veelgestelde) vragen met bijhorende antwoorden (https://en.wikipedia.org/wiki/FAQ).

Men treft FAQs vaak aan op websites. Bijvoorbeeld, er bestaat een FAQ over de elektronische identiteitskaart (eID): https://faq-eid.belgium.be//. We gebruiken eID als voorbeeld in deze blog, maar de behandelde concepten zijn algemeen toepasbaar.

Het nadeel van een FAQ is echter dat deze manueel moet doorzocht worden. Dat kan ofwel door stap voor stap alle vragen te overlopen, ofwel door te zoeken met de juiste keywords, namelijk, de woorden die effectief voorkomen in de FAQ.

Met chatbot-technologie kunnen we dit manuele zoekproces iets flexibeler maken. Het resultaat zullen we een FAQ-chatbot noemen. We beschrijven hieronder de concepten en een methodologie om dit te doen.

Flexibiliteit in verwoording en dialoog

Een eerste conceptuele stap van FAQ naar chatbot, is toelaten dat eenzelfde vraag op verschillende manieren kan verwoord worden. Dit hoeft niet beperkt te zijn tot het herkennen van synoniemen voor eenzelfde woord.  We kunnen immers toelaten dat twee zinnen met een compleet verschillende structuur ook als eenzelfde vraag worden geïnterpreteerd. Bijvoorbeeld, in de context van technische problemen met eID zouden de volgende verwoordingen kunnen verwijzen naar telkens hetzelfde probleem:

• Ik heb een probleem met authentificatie in Firefox
• Hallo, de authentificatie in Firefox werkt niet
• Ik heb een probleem met mijn eID in Firefox

De bijhorende vraag zou eenduidig kunnen verwoord worden als: “Er is een probleem bij het aanmelden via eID in de Firefox webbrowser”.

In het ideale geval weten we op elke vraag meteen een geschikt antwoord; of anders gezegd, voor elk probleem weet de chatbot een oplossing. Maar een tweede belangrijke conceptuele stap, is erkennen dat we op sommige vragen niet meteen een gepast antwoord kunnen geven. Vragen van eindgebruikers kunnen soms te vaag zijn. In de context van technische problemen met eID, kunnen volgende verwoordingen als vaag worden gezien:

Bij vage vragen willen we graag zelf bijkomende vragen stellen aan de eindgebruiker om het onderwerp van de vraag verder af te bakenen. Er ontstaat dan een diepere dialoog-structuur. Verdergaand op de bovenstaande vage vraag “probleem help”, zou het gesprek bijvoorbeeld als volgt kunnen verlopen:

• Gebruiker: Probleem help
• Chatbot: Welk operating systeem gebruikt u?
• Gebruiker: Windows 10
• Chatbot: Heeft u de eID QuickInstall procedure gevolgd?
• Gebruiker: Bedankt, ik zal dat eens proberen
• Chatbot: Graag gedaan.

Met geschikte wedervragen is het mogelijk om de eindgebruiker zo goed mogelijk te helpen.

Dialoog als netwerkstructuur

De bovenstaande principes, van flexibele verwoording en dialoog, kunnen worden uitgewerkt in een flowchart of netwerkstructuur. De knopen in dit netwerk stellen samenvattingen voor van wat de eindgebruiker heeft gezegd. Aan de knopen kunnen we tekstballonnetjes hangen om te specifiëren wat de chatbot moet zeggen als die knoop wordt bereikt. Zo’n tekstballonnetje definiëert dus de output van een knoop.

In een dergelijk netwerk duiden we altijd een start-knoop aan: hier begint het gesprek. Verder trekken we ook bogen van de ene knoop naar de andere om aan te geven hoe het gesprek wordt gestuurd als de eindgebruiker bepaalde woorden of volgorden van woorden ingeeft. Een boog zal typisch meerdere variaties bevatten van zinnetjes, om de flexibiliteit te verhogen waarmee de eindgebruiker het gesprek kan sturen. Bij een boog van knoop A naar knoop B zeggen we dat A de source knoop is, en B de target knoop.

Met elk nieuw bericht van de eindgebruiker, bewegen we doorheen de structuur van het netwerk, van de ene context-knoop naar de andere. Men kan de knopen ook bekijken als de gedachten van de chatbot. Tijdens een gesprek bezoekt de chatbot dan meerdere opeenvolgende gedachten: bij elk nieuw bericht van de eindgebruiker krijgt de chatbot een beter beeld van wat gezegd is en waarover de eindgebruiker wil praten.

Nota over training

In de praktijk moet de netwerkstructuur van de dialoog worden geïmplementeerd via een chatbot-technologie. De zinnetjes op een boog van knoop A naar knoop B worden training data voor de chatbot-technologie. De bedoeling is dat de technologie veralgemeningen gaat leren, door aan te leren welke woorden en combinaties van woorden de verschillende zinnetjes kenmerken. Als later tijdens een echt chat-gesprek we ons bevinden in knoop A, en de eindgebruiker schrijft een zinnetje dat lijkt op de zinnetjes die wij hebben opgeschreven (op de bogen die vertrekken vanuit A), dan kunnen we doelbewust bewegen naar een bepaalde target knoop van A. Hierop komen we later terug.

Context-afhankelijke interpretatie

De bovenstaande voorstelling van dialoog als een netwerkstructuur laat in principe toe dat we aan eenzelfde zin (of woord) van de eindgebruiker een andere betekenis toekennen afhankelijk van de knoop. Dit lijkt heel natuurlijk, maar niet alle chatbot-technologieën ondersteunen dit. Toch willen we graag benadrukken dat dit een belangrijk aspect kan zijn van een helpdesk-achtige chatbot die moet kunnen omgaan met vage zinnetjes (of woorden) van eindgebruikers.

Bijvoorbeeld, stel dat we een chatbot willen maken die technische vragen moet beantwoorden van werknemers in een IT bedrijf. Stel dat deze werknemers onder andere de volgende twee problemen kunnen hebben:

1. Een probleem met Internetverbinding, waarbij werknemers het woord “web browser” of “browser” willen vermelden.
2. Een probleem met een data tool (bijvoorbeeld voor boekhouding), waarin een bepaald onderdeel van de user interface wordt aangeduid met “data browser” of gewoon “browser”.

Het woord “browser” heeft dus in twee verschillende contexten een compleet andere betekenis.

In het gedachtegoed dat we de eindgebruiker een flexibele interactie willen aanbieden via de chatbot, zou het niet kloppen om werknemers te vragen om steeds “web browser” te zeggen in de context van een internet probleem, of steeds “data browser” te zeggen in de context van een probleem met de data tool. Immers, de eindgebruiker heeft mogelijk al kenbaar gemaakt in een voorgaande zin binnen welke context de vraag zich afspeelt. Het is in principe redundant om “web” en “data” te vermelden (hoewel het is toegelaten).

Ontwikkelingsproces

We beschrijven hieronder een concreet stappenplan om een chatbot op te stellen als gids voor technische informatie, zoals die voorkomt in een FAQ.

Een eerste ruwe versie van de chatbot kan bekomen worden door een FAQ als basis te gebruiken:

• Zet de (eenduidige) vragen van de FAQ om naar vragen die vertrekken vanuit de start-knoop. Als we veronderstellen dat elke vraag in de FAQ uniek is, dan krijgt elke vraag typisch een eigen target-knoop. De output van een target-knoop voor vraag Q bevat het antwoord dat de FAQ geeft op vraag Q.
• Opgelet, bij een technische FAQ is het antwoord soms een lange procedure. In dat geval kan de output (het antwoord van de chatbot) best bestaan uit een korte samenvatting en een link naar een document met meer gedetailleerde informatie. De link kan bijvoorbeeld naar de oude FAQ zijn, die mag blijven bestaan naast de chatbot.

Vervolgens gaan we deze eerste versie flexibeler maken, zodat de eindgebruiker niet exact dezelfde terminologie moet gebruiken als de oorspronkelijke FAQ. Bovendien willen we toelaten dat aan het begin van het gesprek ook vragen mogen gesteld worden die minder eenduidig zijn als die in de FAQ. Daartoe kunnen we transcripts (chatlogs) verzamelen van conversaties tussen eindgebruikers en echte helpdeskmedewerkers. We maken eerst een selectie van transcripts die overeenkomen met de beoogde inhoud van de chatbot. We zetten vervolgens elke geselecteerde transcript om naar een of meerdere dialoog-paden.  Zo’n dialoog-pad ziet eruit als volgt:

• In het begin voegen we de start-knoop toe; deze is altijd dezelfde. Men zou deze “start” of “début” kunnen noemen.
• Elke zin van de gebruiker blijft in principe (letterlijk) staan. Maar deze mag ook herschreven en lichtjes verbeterd worden. Herschrijvingen kunnen aanleiding geven tot verschillende training labels tussen twee opeenvolgende knopen, en dus meerdere dialoog-paden (ook al worden dezelfde knopen bezocht).
• Op elk moment dat de helpdeskmedewerker een antwoord geeft, maken we een dialoog-knoop:
  1. Het label van de knoop is een professionele, en bondige, samenvatting van hetgeen reeds aan bod is gekomen.
  2. De output van de knoop is de reactie van de medewerker. Zoals eerder gezegd, als het antwoord te lang is dan kan er ook gewoon een link worden gegeven naar een ander document (zoals de oude FAQ).
• Bij het omzetten van een nieuw transcript, proberen we knopen te hergebruiken uit omzettingen van vorige transcripts, indien die vorige knopen van toepassing zouden zijn. Redenen om knopen te hergebruiken zijn: (1) niet ingaan op elke nuance die eindgebruikers vermelden, ten einde onbelangrijke details te negeren en de dialoog beter te leiden, (2) specifieke antwoorden/outputs hergebruiken en optimaliseren (qua spelling en inhoud). Bij het invoegen van een knoop maken we dus de overweging of we een nieuwe knoop maken of een oude knoop hergebruiken.

Nota bij gebruik van transcripts

We werken best met transcripts (chatlogs) waarin de eindgebruiker telkens enkele korte zinnen (één of twee) schrijft alvorens de medewerker reageert.

• Dit helpt de onderliggende chatbot software bij het matchen van toekomstige zinnetjes van eindgebruikers. Chatbot software maakt vaak gebruik van woorden en woord-volgorden, en het is eenvoudiger om te veralgemenen uit de training data als deze geen lange zinnen bevat. Het blijft in het ideale geval wel mogelijk dat de eindgebruiker nog lange zinnen mag schrijven aan de chatbot, omdat de chatbot in essentie daarin toch op zoek gaat naar de aangeleerde woorden en woord-volgorden.
• Bovendien is deze aanname nuttig bij het opstellen van knopen uit transcripts, waar voor elke knoop een duidelijke samenvatting moet genoteerd worden van wat er reeds gezegd is in het gesprek. Als we vertrekken vanuit een source knoop, en we willen een target knoop maken, is het eenvoudiger om slechts enkele korte zinnen van de eindgebruiker samen te vatten (die werden geschreven na de source knoop).

Mogelijke aanbevelingen

FAQ-chatbots zijn een flexibele manier om met FAQ gegevens om te gaan, wat betekent dat deze chatbots zodanig kunnen opgesteld worden dat ze (1) voorspelbaar en (2) zo correct mogelijk zijn. Deze eigenschappen staan in contrast met andere soorten chatbots, die vooral plezierig en onvoorspelbaar moeten overkomen via humor of icoontjes.

Voorspelbaarheid en correctheid lijken wenselijke eigenschappen voor een eerste generatie chatbots in de context van een overheid.

Technische opmerkingen

• De bovenstaande concepten, rond dialoog-netwerken en context-afhankelijke interpretatie van zinnen, worden goed ondersteund door de chatbot-technologie Api.ai (https://api.ai).
• Het is te verkiezen om correcte spelling te gebruiken in het opstellen van de chatbot zelf, omdat correcte spelling een handig referentiepunt is waarop toekomstige uitbreidingen van data kunnen afgestemd worden. Opgelet: chatbot-technologieën bieden niet altijd ondersteuning voor het omgaan met spellingsfouten. Bijgevolg, om spellingsfouten toe te laten bij de input van eindgebruikers, kan het nodig zijn om automatisch spellingscorrecties te doen op de input alvorens deze door te sturen aan de chatbot.

Avec ‘Watson Conversation’ de IBM on peut développer des chatbots qui comprennent les langues naturelles sous forme de texte.