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

Architectuurplaat (idee van Jeroen)

Vandaag aan de slag gegaan met de architectuurplaat. Een plaat waarop je voor alle stappen de beschikbare Microsoft technieken beschrijft indien die er zijn en indien die er niet zijn de alternatieve technieken of waar neer deze wel verwacht worden. Tijdens het maken van deze plaat ben ik er achter gekomen dat er over een aantal cruciale stappen nog veel kennis ontbreekt. De ontbrekende informatie probeer ik deze sprint te verzamelen naast het doel dat er gesteld is.

 

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.