Nadat we het werk hebben gedaan om gestructureerde gegevens uit de ongestructureerde gegevens te halen, via NLP en tekstverwerking, kunnen we nog steeds profiteren van het gebruik van natuurlijke taalverwerking om meer inzichten te krijgen.

In het vorige blog, hebben we enkele voorbeelden besproken van hoe NLP ongestructureerde documenten en stukjes tekst kan groeperen om ze op een gestructureerde manier te krijgen. We kunnen nog steeds NLP gebruiken om inzicht te krijgen in deze data.

In deze blog zal ik het hebben over hoe het gebruik van een semantische parseermethode een minder ervaren gebruiker kan helpen hun gegevensvragen om te zetten in geavanceerde databasequery's, en hoe het kan helpen bij het detecteren van fouten in gegevenssets.

NLP voor databases

In de supply chain-sector (evenals in andere sectoren) vormen databases een groot deel van de dagelijkse bedrijfsvoering. Ze bevatten waardevolle informatie en kunnen op elk moment worden ingeroepen. Databases houden allerlei soorten informatie op bedrijfsniveau bij, zoals inventaris en operationele informatie zoals de stuklijsten van duizenden producten.

De manier waarop NLP dit proces kan verbeteren, is door de gegevens voor te bereiden die bestemd zijn voor databases zoals in de eerste sectie, en door een coherente structuur te genereren en het gebruiksgemak van de gegevens erin te vergemakkelijken.

Semantische parsering

Een zeer databasespecifiek voorbeeld voor databasebeheer en NLP is semantisch ontleden.

Semantische parsing stelt gebruikers die minder ervaring hebben met database-omgevingen en programmeertalen zoals SQL (Structured Query Language) in staat om te praten en te werken met relationele databases.

Eenvoudige vragen kunnen worden vertaald in complexere vragen door de semantische ontleding van de vragen. Dit soort modellen staan ​​echter nog in de kinderschoenen en moeten nog op grotere schaal worden ontwikkeld.

Een voorbeeld van hoe semantisch ontleden zou kunnen werken, wordt getoond in de volgende afbeelding. Het is een voorbeeld van de SPArC dataset, een contextafhankelijke/multi-turn versie van de Spin taak, geschreven door Yale-studenten. Op basis van beschikbare datasets wordt een model gemaakt waarmee de gebruiker eenvoudige vragen kan vertalen naar complexere SQL-query's.

Ten slotte kan een meer praktisch voorbeeld worden gevonden van hoe een gebruiker SParC op zijn eigen schema kan uitvoeren hier.

Foutdetectie in datasets

De gegevens die in een database, of interne gegevensbron zoals Excel, worden geplaatst, bevatten niet altijd de juiste gegevens. Interne onbewerkte gegevens, bijvoorbeeld gegevens die uit een systeem worden gehaald, of interne platte bestanden, kunnen onvolledig en ongestructureerd zijn.

Verschillende modellen kunnen worden toegepast om deze onvolledige gegevens te vinden, te labelen en de gegevens in verschillende categorieën te verdelen, en gevolgd door een analyse van de gegevens.

In deze sectie zal ik een beetje afwijken van puur NLP-toepassingen. Omdat NLP meestal op grotere stukken tekst wordt uitgevoerd, moeten we naar andere voorbeelden kijken. Omdat de volgende voorbeelden sterk gerelateerd zijn aan het onderwerp datamanagement voor supply chain-bedrijven, heb ik besloten ze in de blog op te nemen.

Hoewel er algemeen bekende methoden zijn, zoals het vinden van ontbrekende waarden, kunnen andere statistische en machine learning-voorbeelden ook worden gebruikt om inconsistenties in gegevens te vinden.

Fout detectie

Met foutdetectie bedoel ik het vinden van stukjes tekst en informatie die afwijken van de algemene context. Het vinden van deze fouten kan ofwel worden gedaan door statistische methoden, waarbij men de uitbijters van een bepaalde dataset kan zoeken, en andere (deep learning) methoden die gegevens vinden die niet relevant zijn voor de andere aanwezige gegevens.

Een use case van de statistische uitbijtermethode zou de dagelijkse omzet van een lokaal bedrijf kunnen zijn. Als ze elke dag een constante omzet hebben, maar op een dag door onvoorziene redenen weinig omzet lijken te hebben gehad, zou de omzet van die dag een uitschieter zijn.

In tekstuele gegevens konden dergelijke afwijkingen ook worden gevonden. In een grotere dataset kunnen we scannen om te zien welke producten waarschijnlijk niet relevant zijn voor de kernactiviteiten.

De meeste fouten in datasets komen uit drie soorten fouten. Het eerste type is transcriptiefouten; deze fouten zijn meestal het gevolg van typefouten, herhaling en verwijdering. Het tweede type is transpositie, waarbij getallen verkeerd worden gerangschikt. Een leuk weetje is dat als je een getal in de verkeerde volgorde schrijft, het verschil tussen dat getal en het oorspronkelijke getal altijd deelbaar is door 9.

Een derde veel voorkomende manier om fouten in te voeren zijn unitisatie- en/of representatiefouten.

Er zou een model kunnen worden gemaakt dat leert welke producten eerder deel uitmaken van de set en welke producten niet. In praktijkscenario's kunnen deze woorden/gegevens worden gemarkeerd en handmatig worden verwijderd door de adviseur.

Voorbeelden

Neurale netwerken gebruiken om fouten in spreadsheets te vinden: Zoeken waar getallen worden ingevoerd in plaats van formules.

Deze fouten kunnen behoorlijk kostbaar zijn. Omdat gegevens in de toeleveringsketen elke dag veranderen, ontwikkelen zich meerdere spreadsheets en andere gegevensbronnen. Het is belangrijk dat de gegevens in die gegevensbron ook evolueren.

Opmaakfouten in gestructureerde datasets vinden: Bijvoorbeeld ten onrechte schriftelijke data (verschillende formaten), ontbrekende haakjes of andere interpunctie zoals extra spaties.

In sommige gevallen kunnen deze fouten onschuldig zijn, aangezien de meeste programmeeromgevingen verschillende invoerformaten lijken te herkennen. In databases en in SQL worden datums in verschillende formaten herkend.

Andere fouten, zoals extra spaties, kunnen moeilijker zijn omdat deze tekenreekswaarden kunnen worden gegroepeerd voor gegevensaggregatie.

Het vinden van deze gegevens kan de consultant van supply chain-software veel tijd besparen bij het opzetten van de software in ontwikkeling en zelfs bij het live gaan in productie.

Het kan de adviseur helpen om beschadigde of geknoeide gegevens te vinden, gegevens die op de verkeerde plaatsen worden gevonden. Een soort gegevensdiagnose kan worden ingesteld tot:

• Vind geknoeid met of beschadigde gegevens, gegevens die op de verkeerde plaatsen worden gevonden.
• Bespaar de adviseur en de klant veel tijd in de go-live fase.
• Stel gegevensdiagnostiek in voor de klant, aangezien menselijk toezicht op elke gegevensinvoer in de meeste gevallen bijna onmogelijk is

String matching en bewerkingsafstand: Een tweede voorbeeld zijn verschillende varianten van het schrijven van de gegevens (transcriptiefouten).

Het gebeurt vaak wanneer gegevens handmatig en met kleine spelfouten worden ingevoerd.

Een van de vele oplossingen voor dit probleem zou het matchen van strings kunnen zijn. Ik zal het hebben over string-matching in het algemeen, en een meer specifiek voorbeeld genaamd de "FuzzyWuzzy" -bibliotheek in Python.

FuzzyWuzzy is een voorgecodeerde module die data-engineers kunnen toepassen in hun code die de Levenshtein Distance gebruikt. De Levenshtein Distance is een algoritme dat een getal berekent dat aangeeft hoe verschillend strings zijn.

In de praktijk kan dit worden gebruikt door een set gegevens te definiëren die als correct wordt geaccepteerd. Nieuwe invoergegevens kunnen via de bibliotheek worden geanalyseerd om te zien welke tekenreeksen in de oorspronkelijke gegevensset en de invoergegevensset het meest overeenkomt.

Als beperkt voorbeeld kunnen we verwijzen naar de koffie-industrie. Het kan zijn dat sommige gegevens onjuist zijn gespeld, maar het kan ook zijn dat ze op een andere manier zijn geschreven. Hetzelfde drankje kan worden geschreven als een 'Latte', of als een 'Cafe Latte'.

Stel je voor dat we de volgende beperkte dataset hebben:

• Espresso
• Cappuccino
• Stained
• melk
• Ijskoffie

En in de geknoeide dataset zijn er verschillende stukjes gegevens die onjuist zijn geschreven:

Met het gemarkeerde voorbeeld zouden we kunnen denken dat dit een grote afstand is, maar als we het vergelijken met het voorbeeld Macchiato krijgen we een Levenshtein-afstand van 8. Omdat Latte al in beide strings wordt gevonden, is de afstand veel kleiner dan bij andere voorbeelden {Espresso : 10, Cappuccino: 9, IJskoffie: 10}.

Dit is een eenvoudig, maar naar mijn mening sterk voorbeeld. Dit is iets wat een consultant handmatig zou kunnen doen, maar dat veel tijd zou kunnen besparen als het geautomatiseerd zou worden gedaan. Een consultant kan altijd de controle van gewijzigde items doen, maar hoeft het eigenlijke werk niet zelf te doen. In de praktijk gaan NLP en string-matching veel dieper dan dit, dit voorbeeld is ook minder gebaseerd op machine learning dan andere voorbeelden die je zou kunnen vinden.

Voor een voorbeeld van hoe de FuzzyWuzzy-bibliotheek in de praktijk wordt gebruikt, kunt u terecht op: dit artikel.

Volgende blogs

De volgende blogs zouden heel interessant moeten zijn.

Ik zal het hebben over hoe NLP de toeleveringsketen ten goede kan komen wanneer toegepast op externe gegevens.

Er zijn meerdere krachtige mogelijkheden om NLP op externe gegevens te gebruiken.

Om te beginnen kunnen we sentimentanalyse gebruiken om het algemene sentiment van uw publiek/klanten over uw product en/of bedrijf te ontdekken. Aangezien dit meestal zal worden toegepast op beoordelingen en sociale media, zal dit over het algemeen van toepassing zijn op B2C (business-to-consumer) ondernemingen.

Een andere mogelijkheid is het webschrapen van ander nieuws, markttrends en andere informatieve websites die informatie beschikbaar hebben over de supply chain-sector. Het automatiseren van het schrapen van deze informatie zal veel tijd besparen bij het bijhouden van de algemene evolutie van de sector en concurrenten, en kan gerichte, relevante informatie geven.