Sprint 7 – Neo4j amsterdam

Vrijdag 17 november ben ik bij een training van Neo4j geweest. Neo4j is een bedrijf dat een tool heeft gemaakt om graph databases te maken. In deze ochtend heb ik veel geleerd over graph databases en cypher. De documentatie van deze training is per mail beschikbaar.

Sprint 7 vragen opstellen

Voor sprint 6 was de vraag om 10 vragen op te stellen die de bot kon beantwoorden. Deze taak was niet duidelijk over gekomen. Deze heb ik uiteindelijk in sprint 7 uitgevoerd en dan ook gelijk op het domein waarop we de chatbot willen toepassen namelijk ziekenhuizen. Voor de vragen heb ik gefocust op de top taken (de meest gevraagde informatie, dus niet de FAQ).

 

Sprint 7 intent oplossing uitwerken

In sprint 7 ben ik bezig geweest met de “intent” oplossing uitwerken. Dit is een van de mogelijke paden die we hebben gekozen. Het houdt in dat we in graph databases niet naar de relatie kijken maar alleen naar de nodes.

De vragen die de chatbot moet ondersteunen heb ik van verschillende ziekenhuis websites gehaald en andere komen van overleg met Jeroen.

Ook heb ik de google maps api toegevoegd zo dat er reistijd kan worden berekend naar een adres als deze vraag gesteld wordt.

Dit is goed gelukt op het gebied van functionaliteit. Op het gebied van code moet er nog het een en ander worden verbeterd. Dit ga ik zelf doen en zal ik ook hulp vragen aan collega’s.

Sprint 6 & 7 MSSQL graph

In sprint 6 en 7 heb ik gekeken of we de overstap kunnen maken van Neo4J naar Azure MSSQL graph. Dit zo dat alles binnen Azure kan worden gedeployed. In sprint 6 was de conclusie dat dit niet mogelijk was omdat niet alle gegevens bekend waren om de query uit te voeren. Neo4j kan prima queries uitvoeren als niet alle gegevens bekend zijn.

In sprint 7 is de aanpak veranderd en heb ik opnieuw getest of het mogelijk was om MSSQL graph te gebruiken. Dit bleek nog niet mogelijk omdat deze technologie nog geen graph traversal ondersteunt. De relaties moeten direct naast elkaar liggen en dat is mijn model niet zo.  Dit is ook in mijn model niet mogelijk.

Door de vernieuwde aanpak in sprint 7 is het wel interessant geworden om te kijken naar Azure Cosmos Db. Hiervoor moet gekeken worden naar de query taal gremlin. Dit hoop ik in sprint 8 te kunnen doen.

 

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.