Sprint 5 onderzoek en conclusie (concept)

Afgelopen week diep in de features functie van LUIS gedoken. Het doel van deze sprint was:

Hoe dynamisch kunnen we de cypher* query generen op basis van het LUIS result.

De conclusie van het onderzoek is:

  • Antwoord type classificatie** toepassen d.m.v. vele intents
  • Features verder uitbreiden en toepassen voor relatie en onderwerp herkenning in een vraag van een gebruiker.

Er is onderzoek nodig naar wat de gevonden problemen voor invloed hebben op deze oplossing.

Verdieping

Meerdere intents

Het opmerkelijkst is dat om deze methode succesvol te maken is juist het gebruik van meerdere intents nodig. Eerst was de gedachte dat het beter was om 1 intent voor alle vragen te maken. 1 intent zou minder configureerwerk betekenen en ervoor zorgen dat het beperkt blijft tot 1 luis model (Omdat de max 80 intents is per luis model). Juist blijken de meerdere intents erg handig voor antwoord type classificatie waardoor de vragen beantwoord kunnen worden.

Hier ben ik ook pas 1 dag voor het einde van de sprint achter gekomen. Dus het onderzoek hierna wordt mogelijk doorgeschoven naar volgende sprint. Eerst was mijn conclusie was dat het antwoord type classificatie via een ander neuraal network moest worden gedaan.

Features

Daarnaast heb ik ook ontdekt hoe belangrijk de features zijn. Elk woord (onderwerp, relatie) wat je LUIS goed wilt laten classificeren naar een niet standaard entity moet in de features staan. Anders negeert of classificeert LUIS deze zoals LUIS denkt dat logisch is. Hierbij een voorbeeld van een koe *** die niet als dier is geclassificeerd is en daarom als encyclopedie item wordt herkent waar ik niets mee kan. (omdat niet alle dieren als encyclopedie item worden herkend)

Uitdagingen

De tegengekomen problemen zijn:

In de cypher query en in C# staat nog te veel hardcoded. Er wordt nog niet gewerkt met properties in de graph database. Hierin verwacht ik ook nieuwe problemen tegen te komen.

Voor relatie matching zijn er synoniemen nodig omdat de relatie die herkent wordt door LUIS ook bijv een synoniem kan zijn van de naam die wordt gebruikt in de graph database. Het toevoegen zal hoe dan ook veel tijd kosten. Indien het geautomiseerd wordt moet het ook worden nagekeken.

 

* Cypher is de query language voor de graph database Neo4J.

**Antwoord type classificatie houdt in dat een zin wordt geanalyseerd (in de moelijkste vorm) en daarbij bepaald wordt wat een gebruiker terug verwacht. Bijv een nummer:datum (dus 2017). Of een locatie:stad (bijv breda). Hieronder staat het meest gebruikte model van Li & Roth

*** Op dit moment van de afstudeerstage wordt gebruik gemaakt van een demo dierendatabase zodat er geen domein specifieke problemen moeten worden opgelost.

Sprint 5 doel en aanpak

Afgelopen donderdag is er na aanleiding van het resultaat van de sprint demo overleg geweest tussen Hans, Jeroen en mij. Hierin hebben we bekeken wat we uit de LUIS api kunnen halen en een een doel gezet voor deze sprint:

Hoe dynamisch kunnen we de cypher query generen op basis van het LUIS result.

Dit ga ik aanpakken door meerdere methodes op te zetten die het resultaat van LUIS kunnen converteren naar een cypher query.

Daarnaast hebben we besproken wat we voor deze sprint out of scope houden. Dat is:

  • Antwoord formuleren
  • Vraag formuleren m.b.v. chat(bot)

Ook ga ik kijken of het mogelijk is om alles naar 1 intentie te verplaatsen in LUIS. Dit houdt in dat er niet per vraag een intent hoeft te worden opgesteld.
Daarnaast is de dataset iets aangepast en wordt deze gecontroleerd door Hans zodat ik het niet onnodig moeilijk maak.

 

LUIS Trainingsmethode

In het 2e deel van vorige week heb ik mij gefocust op het vragen beantwoorden met LUIS. Hierin heb ik meerdere methoden uitgeprobeerd.

  1. Volledige vraag
  2. Soort vraag

De methoden

Methode 1 houd in dat er voor elke vraag een intent wordt aangemaakt.* Elke vraag heeft dan 1-3 voorbeeldzinnen. Dit ziet er als volgt uit:

De intents

De voorbeeld tekst zodat LUIS de intent kan herkennen

Deze methode zou heel veel werk kosten aan de LUIS kant, database kant en C# kant omdat alle vragen handmatig moeten worden toegevoegd. Via een API is dit mogelijk simpeler te maken maar alsnog moeten alle vragen van te voren verzonnen worden.

Methode 2 zit slimmer in elkaar door elke vraag te categoriseren*.

De intents

De voorbeeld zinnen

Voordeel van deze methode is dat alleen het dier (voorbeeldcasus is over een dierendatabase) uit de zin moet worden gehaald. LUIS is hier erg goed in na het trainen hier op. Nadeel blijft dat er voor elk type vraag in LUIS, C# en database kant wijzigingen moeten worden gemaakt.

* Er zit een limitatie van 30 intents op LUIS. Dit zou betekenen dat je vele modellen moet maken en efficient moet zoeken waar de vraag staat.

Zinsontleding

Afgelopen week heb ik ook gekeken of zinsontleding mogelijk is met LUIS. Door LUIS te trainen op zinsonderdelen. Dit heb ik zo wel gedaan met entities (verb, subject, question word) als met features. Uit beide kwam onvoldoende resultaat om er mee verder te kunnen. Wel werkte de feature functie bijzonder goed en herkende alles perfect na het trainen. Bijv de question words (who, what, how, etc..) werden perfect herkend. Helaas was het niet mogelijk om dit toe te passen voor werkwoorden even als onderwerpen (dit zijn er simpelweg te veel).

LUIS trainen

De zinnen/vragen/tekst die mensen typen in de bot worden automatisch opgeslagen en geclassificeerd volgens de bestaande kennis die LUIS heeft. Ik heb hierin onderzoek gedaan om te kijken wat hier mogelijk mee was via de API. Uit dit onderzoek blijkt dat het mogelijk is om via de API de tekst die mensen in typen is op te halen met daarbij de classificatie van LUIS. Daarnaast kunnen ook voorbeeld zinnen worden toegevoegd via de API en kan LUIS via de API getrained worden na dat de zinnen zijn toegevoegd.

Hierdoor kan je (bijna) vol automatisch de bot slimmer maken. Helemaal verstandig is dit niet omdat je wel wil zien wat er kan.  Wel kan je door middel van deze API een eigen interface maken waarmee je in korte tijd alles kan modereren wat de bot doet i.p.v. werken met de bestaande LUIS interface die niet gericht is op dit soort werkzaamheden.

Deze week

Door te snel lezen heb ik een mail verkeerd geinterpreteerd de sprint review niet door gegaan. Deze is naar woensdag verplaatst. Daarna zal pas echt het werk voor deze sprint beginnen. In de tussen tijd werk ik aan andere LUIS trainingsmethoden en mijn verslag.

Knowledge Based QA

Maandag en dinsdag heb ik een stuk onderzoek gedaan naar Knowledge-based QA omdat ik hier weinig beeld van had.  Hieruit kwam weer een ander database type naar voren (Triple Store).  Hierin heb ik ook gekeken of het mogelijk was om met de “standaard” query language SPARQL te queryen op een bestaande Microsoft SQL database.  Na een hoop uitzoek werk met Richard en Bram kregen we D2RQ (SPARQL to relationale database) eindelijk werkend.  Helaas verbruikte deze tool  alleen zo veel ram/cpu dat ik niet voldoende heb kunnen testen of dit bruikbaar is indien het nodig is.

Om dat dit aanvoelde alsof ik veel ging afwijken van mijn sprint doel heb ik overleg met Jeroen en daarna met Hans gehad en ga mij nu weer focussen op LUIS.  Hierin focus ik mij  op welke manieren en met welke resultaten LUIS gebruikt kan worden om verschillende dieren vragen te beantwoorden.

 

Onderzoek? Onderzoek!

Onderzoek – LUIS

Om goed LUIS (de service van Microsoft die intenties uit zinnen kan ontdekken) te trainen heb ik veel onderzoek gedaan deze week. Hierin was ik opzoek naar een methode om LUIS te trainen om verschillende vragen te herkennen. Hierin was ik bijvoorbeeld opzoek naar een standaard zins opbouw voor simpele vragen, zodat dit geleerd kon worden aan LUIS om te kijken hoe de tool hierop reageert. Dit leverde geen succes op. LUIS herkende af en toe een zins onderdeel maar vaak ook niet. LUIS is nog niet afgeschreven. Zeker niet voor dat we een keuze hebben gemaakt over het “Question Answering Model”. Daarover hieronder meer.

Onderzoek – Architectuur (plaat)

Ook heb ik onderzoek gedaan om te kijken welke stappen en technieken allemaal komen kijken bij het beantwoorden van vragen. Dit om een architectuurplaat te kunnen maken en daarmee weer een duidelijk beeld te creëren voor mij en voor het team. Deze is nog niet af en is ook helemaal afhankelijk van de te maken keuzes.

Tijdens dit onderzoek kwam naar voren dat naast de intentie van de zin, de intentie van de vraag en het type antwoord moet worden bepaald. Hiervoor zijn andere tools nodig. Dit kan zo wel als simpele vorm met Regex of in een slimme vorm met machine learning. Toen ik meer informatie zocht over het bepalen van het gewenste antwoord kwam ik deze video tegen.  Hierin kwam ik er niet alleen achter dat er nog veel meer stappen benodigd waren voor het beantwoorden van een vraag maar ook dat ik de afgelopen weken zonder bewust er van te zijn dat er meer methodes waren gekozen voor de IR (information retrieval) methode. Dit houdt dat je uit de zin een aantal keywords haalt en met deze gaat zoeken, daarna “rank” je de resultaten en geef je een antwoord. Hierbij kan je denken aan wat Google onder andere doet. Er zijn ook andere methodes zoals Knowledge Based en een combinatie van deze twee (Hybride). Knowledge Based houdt in dat de zin begrepen wordt door de computer en uit de zin dingen als Tijd, locaties, entiteiten en datums kan halen en deze gebruikt om in gestructureerde databases te zoeken. IR is er op gericht om om te gaan met ongestructureerde data.

De keuze van deze methode is zo cruciaal omdat het invloed heeft op welke vragen er beantwoord kunnen worden, welke tools er voor nodig zijn en hoe het database model er moet komen te zien en of er wel een nieuwe database nodig is.

Vervolg

We moeten nu een aantal stappen terug nemen en met het team een beslissing nemen over de volgende kwesties:

Welk type “Question answering model” wordt er gekozen?

Welk type vragen moeten er worden ondersteund?

Hierbij is het belangrijk rekening te houden met de business case waarvoor deze opdracht is uitgezet.

Als de keuzes hierin zijn genomen zal ik hier meer over schrijven.

 

Leuke links

Simpele uitleg over Neural Networks (deel 1/2)

Omdat ik mij ook bezig houdt met de wel/geen javascript framework discussie een (“speld”/”onion”) artikel erover

Sprint 3 review & Sprint 4 planning

Vandaag de eerste sprint review gehad. Veel tips gehad voor de volgende sprint. Bijvoorbeeld eerder aangeven als het sprint doel (mogelijk) niet gehaald wordt. Daarnaast niet alleen demo maar ook een presentatie geven zo dat er een leidende draad is waar in je al je punten kan vertellen die je gedaan hebt in de afgelopen sprint.

Voor de volgende sprint ga ik het onderzoek focussen op welke onderdelen komen er kijken bij NLP (en eventueel welke (Microsoft) tooling is er beschikbaar voor deze onderdelen). Hiervoor heeft Jeroen een voorbeeld gegeven van een architectuurplaat. Voor het praktijk stuk van de sprint wil ik gaan focussen op het implementeren van de keyword API van microsoft om zo meer vragen te kunnen stellen. Dit wordt eerst overlegd met de product owner zodat we allemaal dezelfde gedachten hebben.