Was Vornamen über uns verraten – Eine Spurensuche in Azure Machine Learning Studio


Wer bereits in irgendeiner Art und Weise mit Online-Formularen zu tun gehabt hat, kennt vielleicht die Situation: Sobald Daten abgefragt werden, die nicht unmittelbar verifiziert werden, geben User oftmals falsche Informationen ein. Aus Sicht der Benutzer verständlich, ist doch ein Formular meist nur lästiges Mittel zum Zweck um zum eigentlich gewünschten Ergebnis zu kommen, aus Sicht des Bearbeiters hinter dem Schreibtisch jedoch ärgerlich, immerhin hat dieser oftmals einen konkreten Grund warum er gewisse Daten abfragt, der durch falschen Input torpediert wird. Während eMail-Adressen noch relativ leicht verifiziert werden können, ist dies bei Adressen bereits schwieriger, ist doch eine (laufend zu aktualisierende) Adressdatenbank notwendig die – möchte man seinen Dienst oder sein Produkt global zur Verfügung stellen – noch dazu für viele Länder funktionieren muss. Ganz verzichtet wird bei den meisten Online-Services auf eine Prüfung des Vornamens, immerhin existieren derart viele verschiedene Namen in unterschiedlichen Schreibweisen, dass es relativ aufwendig ist, eine Namensdatenbank zu erstellen und zu warten, speziell, wenn sie global ausgelegt ist.

Wenn konventionelle Methoden nicht weiterhelfen, wird schnell der Ruf nach einer der aktuell stark forcierten Lieblingsproblemlösungsmethode der IT laut: Machine Learning! Die Frage die sich stellt ist: Lassen sich mit Machine Learning gewisse Strukturen in Namen erlernen, sodass es dem Computer möglich ist, zwischen einem konventionellen Vornamen und zufällig zusammengewürfelten Zeichenketten zu unterscheiden? Kann man auch einen Schritt weitergehen und eventuell noch mehr Informationen aus einem Vornamen lesen, etwa ob dieser eher Männern oder Frauen zugeordnet wird, aus welchem Sprachraum er stammt und ob sein Träger möglicherweise älter oder jünger ist? Die Antwort vorweg: Man kann (bis zu einem gewissen Grad) und mit Azure Machine Learning Studio geht das auch relativ schnell und unkompliziert.

Modelle trainieren und auswerten

Die Demo eines in Azure Machine Learning Studio implementierten “Name Analyzer” gibt es hier: http://inqubu.com/nameanalyzer. Das Frontend wurde in Visual Studio 2015 mit AngularJS,  jQuery und C3.js entwickelt, das Backend basiert auf Azure API Management (um CORS-Probleme zu verhindern) und die als Webservice zur Verfügung gestellten, in Azure Machine Learning Studio trainierten Modelle.

nameanalyzer

Gibt man einen Vornamen in das Suchfeld ein und drückt “Analyze”, wird eine REST-API aufgerufen, die Wahrscheinlichkeiten dafür zurückgibt, ob der Name real oder erfunden ist, ob er eher männlich oder weiblich ist und ob er aus dem deutschen, englischen, italienischen, französischen, iberischen, slawischen, arabischen, afrikanischen oder asiatischem Raum stammen könnte. Die Modelle für diese Vorhersage können sehr schnell und einfach in Azure Machine Learning Studio erstellt werden. Azure Machine Learning Studio (AMLS) ist eine Drag&Drop-Oberfläche, über die Daten hochgeladen, Modelle trainiert und daraus REST-Webservices erstellt werden können. Es ist erstaunlich wenig Aufwand notwendig um vorherzusagen, ob ein Name männlich oder weiblich ist, folgender Ablauf genügt dazu:

mls_screenshot

Das Experiment besteht aus mehreren miteinander verbundenen Modulen. An der Spitze sieht man eine direkt in AMLS hochgeladene CSV-Datei, die Namen als unabhängig und das Geschlecht (m,f) als abhängig Variable beinhaltet (einen Namensdatensatz um die Demo nachbauen zu können gibt es hier). Im nächsten Modul wird ein Python-Script ausgeführt, das die Namen in einzelne Buchstaben aufspaltet und auf eine Länge von maximal 10 normiert. Der Input, um unser Modell zu trainieren sieht damit wie folgt aus:

mls_names

Wie man sieht, beinhaltet die Eingabe nur kategoriale Variablen. Das limitiert in gewisser Weise die Modelle, die für das Training verwenden können. Es gäbe die Möglichkeit, den Input numerisch zu kodieren um die Namen auch für zB Neuronale Netze verwertbar zu machen (eine der einfachsten Methoden dazu wäre One-Hot encoding), allerdings versuchen wir das Modell bewusst einfach und verständlich zu halten und wählen daher Two-class Boosted Decision Trees als Trainingsmethode. Das Grundprinzip hinter Decision Trees ist, dass aus den Eingabedaten ein Baum erstellt wird, der von der Wurzel beginnend durchlaufen wird und eine Vielzahl an Verzweigungen beinhaltet. An jeder Verzweigung (split) wird eine Frage gestellt (zB.: Ist der erste Buchstabe ein A?) und entsprechend der Antwort folgt man der passenden Verzweigung bis man an einen “Blattknoten” (leaf node) gelangt – der Blattknoten beinhaltet die Klassifizierung (also zB.: Name ist männlich).
Bei “Boosted Decision Trees” wird nun nicht nur ein Baum sondern mehrere erstellt, wobei zunächst der erste Baum durchlaufen und überprüft wird, ob die Vorhersage korrekt ist (ob also weibliche Namen tatsächlich als weiblich vorhergesagt werden). Liegt der Baum falsch, wird ein zweiter Baum durchlaufen, der die Fehler des vorherigen Baums korrigiert. Der Clou ist, dass die Trainingsdaten derart modifiziert werden, sodass die Attribute, die im vorherigen Baum zu einer falschen Klassifizierung geführt haben, im nächsten Baum stärker gewichtet werden (das ist übrigens der Unterschied zu “Decision Forrests” bei der mehrere Bäume unabhängig voneinander eine Vorhersage angeben und der gewichtete Durchschnitt aller Bäume als Resultat zurückgegeben wird). Man kann in AMLS übrigens praktisch alle Ausgaben visualisieren, indem man auf den Output-Knoten klickt und “Visualize” auswählt – so lässt sich verdeutlichen, wie unser Baum tatsächlich aussieht.

 

mls_visualizemls_treeDas vorletzte Modul “Score Model” verlangt als Input ein trainiertes Modell und Testdaten. Testdaten sind genauso strukturiert wie unsere Trainingsdaten, beinhaltet aber andere Namen. Der Sinn dahinter ist, dass man feststellen möchte, wie gut das Modell das Geschlecht von Namen vorhersagt, die es zuvor noch nie gesehen hat (genau das zeichnet Machine Learning aus). Würde unser Modell sehr gut für unsere Trainingsdaten aber nicht für andere Namen funktionieren, spricht man von “overfitting” (auch “overtraining” genannt) – das Modell passt sich also zu genau an die Struktur der Trainingsdaten an, generalisiert aber nicht. Insbesondere Decision Trees neigen zu “overfitting” – um das zu verhindern, gibt es verschiedene Techniken die je nach Machine Learning Methode unterschiedlich sind. Bei Entscheidungsbäumen kann man zB die Tiefe des Baumes (vom Wurzel- bis zum Blattknoten) einschränken – das verhindert, dass unser Baum zu detailliert wird, hat aber den Nachteil, dass die Vorhersagegenauigkeit (“accuracy”) sinkt. In AMLS stehen für jedes Modell eine Vielzahl an Parameter zur Verfügung, die man abändern kann um die Güte des Modells zu erhöhen, man spricht hierbei auch von “Hyperparameter Optimization”.

Das letzte Modul beinhaltet schließlich die Evaluierung. Hier wird visualisiert, wie “gut” unser Modell ist, wie genau also die Vorhersagen getroffen werden.

mls_evaluation

Eine beliebte Evaluierungsvisualisierung binärer Klassifizierungsprobleme ist eine ROC-Kurve (Receiver Operating Characteristic). Die ROC-Kurve stellt die vom Decision Tree richtig klassifizierten Daten (True Positive Rate) den falsch klassifizierten (False Positive Rate) gegenüber. Liegt unsere Kurve genau auf der grau eingezeichneten Diagonalen, bedeutet das, dass unser Modell für jeden richtig klassifizierten Namen auch jeweils einen falsch klassifiziert hat – das entspricht also einer Trefferquote von 50% und ist damit nicht besser als Zufall. Unser Modell ist etwas klüger: Steigert man die True Positive Rate (geht man also auf der Kurve von links unten nach oben), steigt zwar auch die Anzahl der falsch klassifizierten Namen, jedoch bedeutend langsamer als die Anzahl der richtig zugeordneten Daten. Unser Geschlechtsklassifikator hat 373 unserer Männernamen aus den Testdaten korrekt als männlich eingestuft und 365 korrekt als weiblich. 97 Namen wurden als Männernamen eingestuft obwohl sie Frauennamen sind, 70 als Frauennamen obwohl sie männlich sind, das entspricht einer Genauigkeit (“Accuracy“) von 81,5%: (373+365)/(373+70+97+365). “Precision” gibt an, wie viele der vom Modell als “männlich” identifizierten Namen auch tatsächlich männlich sind, nämlich 373/(373+97) = 79,4%. “Recall” stellt die richtig als männlich eingestuften Namen den insgesamt vorhandenen männlichen Namen gegenüber: 373/(373+70) = 84,2%. Der “F1 Score” schlussendlich ist das Harmonische Mittel aus Precision und Recall. Es errechnet sich aus 2*Precision*Recall/(Precision + Recall) und entspricht in unserem Beispiel daher 2*0,842*0,794/(0,842+0,794) = 81,7%.

Generell gilt, dass jedes Modell nur so gut ist wie die zugrunde liegenden Daten. Für das Training des “Name Analyzer” wurden insgesamt rund 5.000 verschiedene Namen verwendet – und hierbei nicht aus jedem Kulturkreis. Indische Namen etwa fehlen gänzlich, weshalb zum Beispiel der Name “Satya” als “weiblich” klassifiziert wird. Der Modell hat durch viele Namen aus dem deutschen, italienischen oder spanischen Sprachraum gelernt, dass Namen, die auf “a” enden sehr oft weiblich sind. Wie der Entscheidungsbaum klassifiziert, lässt sich klar verdeutlichen, wenn man den Namen “Donald” eingibt – dieser wird richtigerweise als männlich und aus dem englischen Raum kommend eingestuft. Ändert man den Namen zu “Donaldo”, wird dieser als männlich und “Iberisch” klassifiziert. Ändert man ihn abermals auf “Donalda” ab, ändert sich das Geschlecht auf weiblich, der Sprachraum auf Englisch. Offensichtlich ist die Endung “o” nicht nur stark ausschlaggebend für die männliche Klassierung sondern auch für den Herkunftsraum (es gibt deutlich mehr Namen die auf “o” enden in Spanien oder Portugal als im angloamerikanischen Raum) während die Endung “a” vom Modell im Hinblick auf die Herkunft als wenige relevant erachtet wird, weshalb die ursprüngliche Zuordnung (Donald = Englisch) beibehalten wird.

Vom Modell zum Webservice

Ein Modell in AMLS ist schön und gut, praktisch nützlich ist es aber nur, wenn wir es auch direkt in einer Applikation verwenden können. Glücklicherweise nimmt uns AMLS einen großen Teil der Arbeit an, denn mit einem Klick auf “Set up as webservice” in der unteren Menüleiste kann aus dem Experiment sehr schnell ein Webservice generiert werden ohne selbst ein Backend schreiben zu müssen. AMLS generiert dazu nicht nur eine API sondern stellt auch gleich Beispielcode in C#, Python und R bereit.

mls_restapi

Etwas komplizierter wird die Sache, wenn man via JavaScript die API nutzen möchte, hier verhindert die Same-Origin-Policy den direkten Zugriff. Da das Backend von Azure verwaltet wird und man daher keinen direkten Zugriff auf den Access-Control-Allow-Origin response headers hat, muss man den Umweg via Azure API Management nehmen. Dieses Video von Josh Twist erklärt kurz und bündig, wie hier vorzugehen ist.

Abschließend ist zu erwähnen, dass auch Machine Learning kein Allheilmittel zur Eingabevalidierung ist. Zwar würde unser Modell verhindern, dass Zeichenketten wie “usfdiwb” oder “Vogelhaus” als Vornamen durchgehen, wenn sich ein User namens Peter allerdings als Michael ausgibt, würde die Fake-Name-Erkennung logischerweise nicht anschlagen. Nicht zu unterschätzen ist jedoch die Außenwirkung eines solchen Services, zeigt sie doch dem User, dass das Unternehmen offensichtlich innovative Technologien einsetzt um ihre Dienste “smart” zu machen. Vorsicht und ein gewisser Toleranzspielraum ist dennoch geboten, ein als falsch klassifizierter richtiger Name könnte Benutzer unnötigerweise vergraulen – hier sollte jedenfalls mehr Zeit aufgewendet werden um False-Positives des Modells möglichst gering zu halten.
Durchwegs interessant könnte auch die nachträgliche automatisierte Geschlechter-Klassifizierung in einer Datenbank sein, wenn zwar die Vornamen, nicht aber das Geschlecht erhoben wurden. Typischerweise würde man hier einen “confidence threshold” definieren, ab der die Klassifizierung automatisch stattfindet (zB 90%). Ist die “confidence” für einen Namen zu gering (das Modell sich also zu unsicher) wird der Name entweder nicht klassifiziert oder zu manuellen Bearbeitung weitergeleitet.

Comments (1)
  1. sehr cooles Projekt 🙂

Comments are closed.

Skip to main content