Data Science, Machine Learning und KI
Kontakt

In den letzten drei Beiträgen dieser Serie haben wir erklärt, wie man ein Deep-Learning-Modell trainiert, um ein Auto anhand seiner Marke und seines Modells zu klassifizieren, basierend auf einem Bild des Autos (Teil 1), wie man dieses Modell aus einem Docker-Container mit TensorFlow Serving einsetzt (Teil 2) und wie man die Vorhersagen des Modells erklärt (Teil 3). In diesem Beitrag lernt ihr, wie ihr mit Dash eine ansprechende Oberfläche um unseren Auto-Modell-Classifier herum bauen könnt.

Wir werden unsere Machine Learning-Vorhersagen und -Erklärungen in ein lustiges und spannendes Spiel verwandeln. Wir präsentieren den Anwender*innen zunächst ein Bild von einem Auto. Die Anwender*innen müssen erraten, um welches Automodell und welche Marke es sich handelt – das Machine-Learning-Modell wird das Gleiche tun. Nach 5 Runden wird ausgewertet, wer die Automarke besser vorhersagen kann: die Anwender*innen oder das Modell.

Inhalt

Das Tech Stack: Was ist Dash?

Dash ist, wie der Name schon sagt, eine Software zum Erstellen von Dashboards in Python. In Python, fragen ihr euch? Ja – ihr müsst nichts direkt in HTML oder Javascript programmieren (obwohl ein grundlegendes Verständnis von HTML sicherlich hilfreich ist). Eine hervorragende Einführung findet ihr in dem ausgezeichneten Blogpost meines Kollegen Alexander Blaufuss.

Um das Layout und Styling unserer Web-App zu vereinfachen, verwenden wir auch Dash Bootstrap Components. Sie folgen weitgehend der gleichen Syntax wie die standardmäßigen Dash-Komponenten und fügen sich nahtlos in das Dash-Erlebnis ein.

Denkt daran, dass Dash für Dashboards gemacht ist – das heißt, es ist für Interaktivität gemacht, aber nicht unbedingt für Apps mit mehreren Seiten. Mit dieser Info im Hinterkopf werden wir in diesem Artikel Dash an seine Grenzen bringen.

Organisation ist alles – Die Projektstruktur

Um alles nachbauen zu können, solltet ihr euch unser GitHub-Repository ansehen, auf dem alle Dateien verfügbar sind. Außerdem könnt ihr alle Docker-Container mit einem Klick starten und loslegen.

Die Dateien für das Frontend selbst sind logischerweise in mehrere Teile aufgeteilt. Es ist zwar möglich, alles in eine Datei zu schreiben, aber man verliert leicht den Überblick und daher später schwer zu pflegen. Die Dateien folgen der Struktur des Artikels:

  1. In einer Datei wird das gesamte Layout definiert. Jeder Button, jede Überschrift, jeder Text wird dort gesetzt.
  2. In einer anderen Datei wird die gesamte Dashboard-Logik (sogenannte Callbacks) definiert. Dort wird z. B. definiert, was passieren soll, nachdem die Benutzer*innen auf eine Schaltfläche geklickt hat.
  3. Wir brauchen ein Modul, das 5 zufällige Bilder auswählt und die Kommunikation mit der Prediction and Explainable API übernimmt.
  4. Abschließend gibt es noch zwei Dateien, die die Haupteinstiegspunkte (Entry Points) zum Starten der App sind.

Erstellen der Einstiegspunkte – Das große Ganze

Beginnen wir mit dem letzten Teil, dem Haupteinstiegspunkt für unser Dashboard. Wenn ihr wisst, wie man eine Web-App schreibt, wie z. B. eine Dash-Anwendung oder auch eine Flask-App, ist euch das Konzept einer App-Instanz vertraut. Vereinfacht ausgedrückt, ist die App-Instanz alles. Sie enthält die Konfiguration für die App und schließlich das gesamte Layout. In unserem Fall initialisieren wir die App-Instanz direkt mit den Bootstrap-CSS-Dateien, um das Styling überschaubarer zu machen. Im gleichen Schritt exponieren wir die zugrundeliegende Flask-App. Die Flask-App wird verwendet, um das Frontend in einer produktiven Umgebung zu bedienen.

# app.py
import dash
import dash_bootstrap_components as dbc

# ...

# Initialize Dash App with Bootstrap CSS
app = dash.Dash(
    __name__,
    external_stylesheets=[dbc.themes.BOOTSTRAP],
)

# Underlying Flask App for productive deployment
server = app.server

Diese Einstellung wird für jede Dash-Anwendung verwendet. Im Gegensatz zu einem Dashboard benötigen wir eine Möglichkeit, mit mehreren URL-Pfaden umzugehen. Genauer gesagt, wenn die Benutzer*innen /attempt eingibt, wollen wir ihm erlauben, ein Auto zu erraten; wenn er /result eingibt, wollen wir das Ergebnis seiner Vorhersage anzeigen.

Zunächst definieren wir das Layout. Bemerkenswert ist, dass es zunächst grundsätzlich leer ist. Ihr findet dort eine spezielle Dash Core Component. Diese Komponente dient dazu, die aktuelle URL dort zu speichern und funktioniert in beide Richtungen. Mit einem Callback können wir den Inhalt auslesen, herausfinden, welche Seite die Benutzer*innen aufrufen möchte, und das Layout entsprechend rendern. Wir können auch den Inhalt dieser Komponente manipulieren, was praktisch eine Weiterleitung auf eine andere Seite ist. Das leere div wird als Platzhalter für das eigentliche Layout verwendet.

# launch_dashboard.py
import dash_bootstrap_components as dbc
import dash_core_components as dcc
import dash_html_components as html
from app import app

# ...

# Set Layout
app.layout = dbc.Container(
    [dcc.Location(id='url', refresh=False),
     html.Div(id='main-page')])

Die Magie geschieht in der folgenden Funktion. Die Funktion selbst hat ein Argument, den aktuellen Pfad als String. Basierend auf dieser Eingabe gibt sie das richtige Layout zurück. Wenn die Benutzer*innen zum Beispiel zum ersten Mal auf die Seite zugreift, ist der Pfad / und das Layout daher start_page. Auf das Layout werden wir gleich noch im Detail eingehen; beachtet zunächst, dass wir an jedes Layout immer eine Instanz der App selbst und den aktuellen Spielzustand übergeben.

Damit diese Funktion tatsächlich funktioniert, müssen wir sie mit dem Callback Decorator schmücken. Jeder Callback benötigt mindestens eine Eingabe und mindestens eine Ausgabe. Eine Änderung des Inputs löst die Funktion aus. Der Eingang ist einfach die oben definierte Ortskomponente mit der Eigenschaft Pathname. Einfach ausgedrückt, aus welchem Grund auch immer sich der Pfad ändert, wird diese Funktion ausgelöst. Die Ausgabe ist das neue Layout, gerendert in dem zuvor zunächst leeren div.

# launch_dashboard.py
import dash_html_components as html
from dash.dependencies import Input, Output
from dash.exceptions import PreventUpdate

# ...

@app.callback(Output('main-page', 'children'), [Input('url', 'pathname')])
def display_page(pathname: str) -> html:
    """Function to define the routing. Mapping routes to layout.

    Arguments:
        pathname {str} -- pathname from url/browser

    Raises:
        PreventUpdate: Unknown/Invalid route, do nothing

    Returns:
        html -- layout
    """
    if pathname == '/attempt':
        return main_layout(app, game_data, attempt(app, game_data))

    elif pathname == '/result':
        return main_layout(app, game_data, result(app, game_data))

    elif pathname == '/finish':
        return main_layout(app, game_data, finish_page(app, game_data))

    elif pathname == '/':
        return main_layout(app, game_data, start_page(app, game_data))

    else:
        raise PreventUpdate

Layout – Schön & Shiny

Beginnen wir mit dem Layout unserer App – wie soll sie aussehen? Wir haben uns für ein relativ einfaches Aussehen entschieden. Wie ihr in der Animation oben sehen könnt, besteht die App aus drei Teilen: dem Header, dem Hauptcontent und dem Footer. Der Header und der Footer sind auf jeder Seite gleich, nur der Hauptinhalt ändert sich. Einige Layouts aus dem Hauptcontent sind in der Regel eher schwierig zu erstellen. Zum Beispiel besteht die Ergebnisseite aus vier Boxen. Die Boxen sollten immer die gleiche Breite von genau der Hälfte der verwendeten Bildschirmgröße haben, können aber je nach Bildgröße in der Höhe variieren. Sie dürfen sich aber nicht überlappen, usw. Von den Cross-Browser-Inkompatibilitäten ganz zu schweigen.

Ihr könnt euch sicher vorstellen, dass wir leicht mehrere Arbeitstage damit hätten verbringen können, das optimale Layout zu finden. Glücklicherweise können wir uns wieder einmal auf Bootstrap und das Bootstrap Grid System verlassen. Die Hauptidee ist, dass ihr so viele Zeilen wie ihr wollt (zwei, im Fall der Ergebnisseite) und bis zu 12 Spalten pro Zeile (ebenfalls zwei für die Ergebnisseite) erstellen könnt. Die Begrenzung auf 12 Spalten basiert auf der Tatsache, dass Bootstrap die Seite intern in 12 gleich große Spalten aufteilt. Ihr müsst nur mit einer einfachen CSS-Klasse definieren, wie groß die Spalte sein soll. Und was noch viel cooler ist: Ihr könnt mehrere Layouts einstellen, je nach Bildschirmgröße. Es wäre also nicht schwierig, unsere App vollständig responsive zu machen.

Um auf den Dash-Teil zurückzukommen, bauen wir eine Funktion für jedes unabhängige Layout-Teil. Den Header, den Footer und eine für jede URL, die die Benutzer*innen aufrufen könnte. Für den Header sieht das so aus:

# layout.py
import dash_bootstrap_components as dbc
import dash_html_components as html

# ...

def get_header(app: dash.Dash, data: GameData) -> html:
    """Layout for the header

    Arguments:
        app {dash.Dash} -- dash app instance
        data {GameData} -- game data

    Returns:
        html -- html layout
    """
    logo = app.get_asset_url("logo.png")

    score_user, score_ai = count_score(data)

    header = dbc.Container(
        dbc.Navbar(
            [
                html.A(
                    # Use row and col to control vertical alignment of logo / brand
                    dbc.Row(
                        [
                            dbc.Col(html.Img(src=logo, height="40px")),
                            dbc.Col(
                                dbc.NavbarBrand("Beat the AI - Car Edition",
                                                className="ml-2")),
                        ],
                        align="center",
                        no_gutters=True,
                    ),
                    href="/",
                ),
                # You find the score counter here; Left out for clarity
            ],
            color=COLOR_STATWORX,
            dark=True,
        ),
        className='mb-4 mt-4 navbar-custom')

    return header

Auch hier seht ihr, dass wir die App-Instanz und den globalen Spieldatenstatus an die Layout-Funktion übergeben. In einer perfekten Welt müssten wir mit keiner dieser Variablen im Layout herumspielen. Leider ist das eine der Einschränkungen von Dash. Eine perfekte Trennung von Layout und Logik ist nicht möglich. Die App-Instanz wird benötigt, um dem Webserver mitzuteilen, dass er das STATWORX-Logo als statische Datei ausliefern soll.

Natürlich könnte man das Logo von einem externen Server ausliefern, das machen wir ja auch für die Fahrzeugbilder, aber nur für ein Logo wäre das ein bisschen zu viel des Guten. Für die Spieldaten müssen wir den aktuellen Punktestand des Benutzers und der KI berechnen. Alles andere ist entweder normales HTML oder Bootstrap-Komponenten. Wer sich damit nicht auskennt, den kann ich noch einmal auf den Blogpost von meinem Kollegen Alexander verweisen oder auf eines der zahlreichen HTML-Tutorials im Internet.

Callbacks – Reaktivität einführen

Wie bereits erwähnt, sind Callbacks das Mittel der Wahl, um das Layout interaktiv zu gestalten. In unserem Fall bestehen sie hauptsächlich aus der Handhabung des Dropdowns sowie der Button Klicks. Während die Dropdowns relativ einfach zu programmieren waren, bereiteten uns die Buttons einige Kopfschmerzen.

Einem guten Programmierstandard folgend, sollte jede Funktion genau eine Verantwortung haben. Deshalb haben wir für jeden Button einen Callback eingerichtet. Nach einer Art Eingabevalidierung und Datenmanipulation ist das Ziel, die Benutzer*innen auf die folgende Seite umzuleiten. Während die Eingabe für den Callback das Button-Klick-Ereignis und möglicherweise einige andere Eingabeformulare ist, ist die Ausgabe immer die Location-Komponente, um die Benutzer*innen weiterzuleiten. Leider erlaubt Dash nicht, mehr als einen Callback zum gleichen Ausgang zu haben. Daher waren wir gezwungen, die Logik für jede Schaltfläche in eine Funktion zu quetschen.

Da wir die Benutzereingaben auf der Versuchsseite validieren mussten, haben wir die aktuellen Werte aus dem Dropdown an den Callback übergeben. Während das für die Versuchsseite einwandfrei funktionierte, funktionierte die Schaltfläche auf der Ergebnisseite nicht mehr, da keine Dropdowns zur Übergabe an die Funktion verfügbar waren. Wir mussten ein verstecktes, nicht funktionierendes Dummy-Dropdown in die Ergebnisseite einfügen, damit die Schaltfläche wieder funktionierte. Das ist zwar eine Lösung und funktioniert in unserem Fall einwandfrei, aber für eine umfangreichere Anwendung könnte es zu kompliziert sein.

Data Download – Wir brauchen Autos

Jetzt haben wir eine schöne App mit funktionierenden Buttons und so weiter, aber die Daten fehlen noch. Wir müssen Bilder, Vorhersagen und Erklärungen in die App einbinden.

Die High-Level-Idee ist, dass jede Komponente für sich alleine läuft – zum Beispiel in einem eigenen Docker-Container mit eigenem Webserver. Alles ist nur lose über APIs miteinander gekoppelt. Der Ablauf ist der folgende:

  • Schritt 1: Abfrage einer Liste aller verfügbaren Auto-Images. Wähle zufällig 5 aus und fordere diese Bilder vom Webserver an.
  • Schritt 2: Sende für alle 5 Bilder eine Anfrage an die Vorhersage-API und parse das Ergebnis aus der API.
  • Schritt 3: Sende wiederum für alle 5 Bilder eine Anfrage an die Explainable-API und speichere das zurückgegebene Bild.

Kombiniert nun jede Ausgabe in der GameData-Klasse.

Aktuell speichern wir die GameData-Instanz als globale Variable. Das erlaubt uns, von überall darauf zuzugreifen. Das ist zwar theoretisch eine schlaue Idee, funktioniert aber nicht, wenn mehr als eine Benutzerin versucht, auf die App zuzugreifen. Derdie zweite Benutzerin wird den Spielstatus vom ersten sehen. Da wir planen, das Spiel auf Messen auf einer großen Leinwand zu zeigen, ist das für den Moment in Ordnung. In Zukunft könnten wir das Dashboard mit Shiny Proxy starten, so dass jeder Benutzer seinen eigenen Docker-Container mit einem isolierten globalen Status erhält.

Data Storage – Die Autos parken

Die native Dash-Methode besteht darin, benutzerspezifische Zustände in einer Store-Komponente zu speichern. Das ist im Grunde dasselbe wie die oben erläuterte Location-Komponente. Die Daten werden im Webbrowser gespeichert, ein Callback wird ausgelöst, und die Daten werden an den Server gesendet. Der erste Nachteil ist, dass wir bei jedem Seitenwechsel die gesamte Spieldateninstanz vom Browser zum Server übertragen müssen. Das kann ziemlich viel Traffic verursachen und verlangsamt das gesamte App-Erlebnis.

Außerdem müssen wir, wenn wir den Spielzustand ändern wollen, dies über einen Callback tun. Die Beschränkung auf einen Callback pro Ausgabe gilt auch hier. Unserer Meinung nach macht es nicht allzu viel aus, wenn Sie ein klassisches Dashboard haben; dafür ist Dash gedacht. Die Verantwortlichkeiten sind getrennt. In unserem Fall wird der Spielstatus von mehreren Komponenten aus aufgerufen und verändert. Wir haben Dash definitiv an seine Grenzen gebracht.

Eine weitere Sache, die ihr im Auge behalten solltet, wenn ihr euch entscheidet, eure eigene Microservice-App zu bauen, ist die Performance der API-Aufrufe. Anfänglich haben wir die berühmte requests Bibliothek verwendet. Während wir große Fans dieser Bibliothek sind, sind alle Anfragen blockierend. Daher wird die zweite Anfrage ausgeführt, sobald die erste abgeschlossen ist. Da unsere Anfragen relativ langsam sind (bedenkt, dass im Hintergrund vollwertige neuronale Netze laufen), verbringt die App viel Zeit mit Warten. Wir haben asynchrone Aufrufe mit Hilfe der Bibliothek aiohttp implementiert. Alle Anfragen werden nun parallel verschickt. Die App verbringt weniger Zeit mit Warten, und der Benutzer ist früher bereit zum Spielen.

Fazit und Hinweise

Auch wenn die Web-App einwandfrei funktioniert, gibt es ein paar Dinge, die zu beachten sind. Wir haben Dash verwendet, wohl wissend, dass es als Dashboarding-Tool gedacht ist. Wir haben es bis an die Grenzen und darüber hinaus getrieben, was zu einigen suboptimalen interessanten Design-Entscheidungen führte.

Zum Beispiel könnt ihr nur einen Callback pro Ausgabeparameter setzen. Mehrere Callbacks für dieselbe Ausgabe sind derzeit nicht möglich. Da das Routing von einer Seite zur anderen im Wesentlichen eine Änderung des Ausgabeparameters (‚url‘, ‚pathname‘) ist, muss jeder Seitenwechsel durch einen Callback geleitet werden. Das erhöht die Komplexität des Codes exponentiell.

Ein weiteres Problem ist die Schwierigkeit, Zustände über mehrere Seiten hinweg zu speichern. Dash bietet mit der Store Component die Möglichkeit, Benutzerdaten im Frontend zu speichern. Das ist eine hervorragende Lösung für kleine Apps; bei größeren steht man schnell vor dem gleichen Problem wie oben – ein Callback, eine Funktion zum Schreiben in den Store, reicht einfach nicht aus. Entweder ihr nutzt den globalen Zustand von Python, was schwierig wird, wenn mehrere Benutzer gleichzeitig auf die Seite zugreifen, oder ihr bindet einen cache ein.

In unserer Blogserie haben wir Ihnen gezeigt, wie ihr den gesamten Lebenszyklus eines Data-Science-Projekts durchlauft, von der Datenexploration über das Modelltraining bis hin zur Bereitstellung und Visualisierung. Dies ist der letzte Artikel dieser Serie, und wir hoffen, ihr habt beim Erstellen der Anwendung genauso viel gelernt wie wir.

Um das Durchblättern der vier Artikel zu erleichtern, sind hier die direkten Links:

  1. Transfer Learning mit ResNet
  2. Deployment von TensorFlow-Modellen in Docker mit TensorFlow Serving
  3. Erklärbarkeit von Deep Learning Modellen mit Grad-CAM

NLP (engl. für Natural Language Processing) beschreibt allgemein das computergestützte Verarbeiten von menschlicher Sprache. Dies umfasst neben der geschriebenen auch die gesprochene Sprache. Die Ziele, die mit NLP verfolgt werden, lassen sich in zwei übergeordnete Kategorien einordnen: Verstehen von Sprache und Erzeugen von Sprache. Die technische Herausforderung ist bei beiden Zielen, unstrukturierte Informationen in Form von Texten in ein Format zu transferieren, das maschinell verarbeitet werden kann. Das bedeutet konkret, dass Texte in einem Zahlenformat repräsentiert werden müssen, welches der Computer verstehen kann.  

Noch vor wenigen Jahren war dies nur für einige wenige Technologiekonzerne möglich. Dabei hatten diese Firmen drei entscheidende Vorteile:

  • Zugang zu riesigen Mengen an unstrukturierten Textdaten
  • Fachleute, die in der Lage sind, cutting-edge Technologien zu entwickeln
  • Rechenkapazitäten, um die Menge an unstrukturierten Daten verarbeiten zu können

In diesem Artikel zeigen wir verschiedene Anwendungsgebiete von NLP und erklären, wie sich innerhalb nur weniger Jahre die Markteintrittsbarrieren so weit gesenkt haben, dass heute jedes Unternehmen NLP für eigene Lösungen nutzen kann.

Inhaltsverzeichnis

In welchen Bereichen kann NLP eingesetzt werden?

Computergestützte Sprachverarbeitung ist ein sehr abstrakter Begriff. Verständlicher wird der Begriff, wenn man ihn in die Anwendungsgebiete herunterbricht. Dabei wird für jeden Teilbereich ein anderes, spezialisiertes Modell für die Sprachverarbeitung angewandt. Zu beachten ist dabei, dass Aufgaben, die einem Menschen eher leichtfallen, wie z.B. das Erkennen von Emotionen, auch für eine Maschine im NLP Bereich tendenziell eher einfach sind.. Andersherum sind auch kompliziertere Aufgaben, wie das Übersetzen von Texten, für den Computer eine tendenziell schwieriger zu lösende Aufgabe. Die sechs wichtigsten Anwendungen von NLP und die damit lösbaren Businessprobleme werden nachfolgend beleuchtet.

Sequenzklassifizierung

Das klassische Beispiel für NLP ist die Sequenzklassifizierung. Ziel ist es, Textsequenzen einer von mehreren vorher definierten Klassen zuzuordnen. Ein Beispiel für Klassen sind Emotionen (freudig, wütend, erheitert, usw.). Dem Computer wird ein Text vorgelegt und er muss selbstständig entscheiden, welche Emotion der Autor mit seinem Text ausdrücken wollte. Weitere Beispiele sind das Zuordnen eines Texts zu einem bekannten Autor oder das Klassifizieren von Dokumentarten.

Bei der Sequenzklassifizierung ist zu beachten, dass eine Sequenz aus einem Text beliebiger Länge bestehen kann. Eine Sequenz kann aus einem einzigen Wort (Sequenz von Buchstaben), einem Satz, einem Paragraphen, oder aber aus einem kompletten Dokument bestehen. Ein Beispiel für eine kürzere Sequenz wäre eine Urlaubsbewertung.

Anwendungsbeispiel 1:

Ein Reiseportal möchte spezifisch Kunden mit einer negativen Urlaubserfahrung in einer Marketingkampagne ansprechen. Dazu werden vorhandene Kundenbewertungen in drei Klassen unterteilen – Positiv, Neutral und Negativ. Jede Bewertung wird automatisch einer dieser Klassen zugeordnet.

Wobei längere Dokumente beispielsweise Postsendungen beliebiger Art sein könnten.

Anwendungsbeispiel 2:

Die Logistik-Abteilung einer internationalen Firma prozessiert verschiedene Dokumentarten in unterschiedlichen Teams. Dazu werden aktuell Postsendungen manuell selektiert und sortiert. Zukünftig werden diese automatisch einer Kategorie zuordnen. Als Kategorien könnten Eingehende Rechnungen, Lieferscheine sowie andere Anfragen definiert werden

Frage-Antwort Modelle

Bei Frage-Antwort Problemen wird dem Computer eine möglichst große Anzahl an Textkorpora zur Verfügung gestellt. Ziel ist es, auf Fragen, die von einem Person verfasst wurden, eine inhaltlich korrekte Antwort zu geben, die auf Informationen der Textkorpora basiert. Die Schwierigkeit dieser Aufgabe variiert, je nachdem wie konkret die benötigten Informationen im Text sind. Die einfachste Lösung ist  die komplette Extraktion vorhandener Textstellen. Darauf aufbauend kann die extrahierte Information in eine grammatikalisch korrekte Antwort verpackt werden. Am komplexesten zu implementieren sind logische Schlussfolgerungen basierend auf den vorhandenen Informationen.

Ein gegebener Text könnte beispielsweise die Struktur eines Firmengeländes beschreiben. Es werden dabei Gebäude A, B und C erwähnt. Eine mögliche Frage könnte lauten „Wie viele Gebäude sind auf dem Firmengelände vorhanden?“ Eine logische Schlussfolgerung des Computers wäre die Erkenntnis, dass das Gelände aus insgesamt 3 Gebäuden besteht, ohne, dass die Zahl an sich erwähnt wurde.

Anwendungsbeispiel 3:

Eine mittelständische Firma beobachtet seit längerer Zeit einen kontinuierlichen Anstieg an Kundenanfragen. Bei vielen dieser Anfragen handelt es sich um Auskunftsanfragen zu Informationen. Die Firma beschließt, einen Chatbot zu entwickeln. Basierend auf internen Supportdokumenten können Kunden nun selbstständig, automatisch Fragen an den Chatbot stellen und beantworten lassen.

Generierung von Texten

Basierend auf einem gegebenen Text soll möglichst genau das nächste passende Wort vorhergesagt werden. Der so entstandene Text kann wiederum zur Vorhersage von einem weiteren Wort benutzt werden. Dieser Vorgang kann beliebig oft wiederholt werden, um beliebig lange Texte zu erzeugen. Dabei ist es möglich, Texte mit beliebigen Sprachfeinheiten zu generieren. So kann ein bestimmter Akzent oder Dialekt modelliert werden, aber auch eine einfache oder komplexere Sprache verwendet werden, je nach Zielgruppe. Die größte Herausforderung ist, dass Text sowohl inhaltlich als auch sprachlich fehlerfrei sein sollte.

Anwendungsbeispiel 4:

Ein Hersteller eines Dokumentenverwaltungssystems möchte das Auffinden von Dokumenten einfacher gestalten. In der eingebauten Suchmaske wird der Suchbegriff automatisch mit weiteren passenden Wörtern ergänzt.

Erkennen von Satzgliedern

Bei dem Erkennen von Satzgliedern, auch Named Entity Recognition (NER) ist das Ziel, ein oder mehrere Wörter in einem Satz einer Klasse zuzuordnen. Als mögliche Satzglieder können grammatikalische Einheiten definiert werden. Dabei wird ein Satz gegliedert nach Subjekt, Prädikat, Objekt usw. Oft werden anstelle von grammatikalischen Einheiten benutzerdefinierte Entitäten gewählt. Oft sind die gesuchten Entitäten z.B. Orte, natürliche Personen, Firmen oder Zeiten. Wenn ein Mensch eine Entscheidung treffen muss, zu welcher Kategorie ein Satzglied gehört, greifen wir automatisch auf Regeln (wie z.B. Grammatikregeln) zurück. Bei NER soll der Computer lernen, auf ähnliche Entscheidungsregeln zurückzugreifen. Allerdings werden diese Regeln nicht explizit vorgegeben, stattdessen muss der Computer sich diese selbstständig erarbeiten.

Anwendungsbeispiel 5:

Ein Hedgefonds analysiert automatisch die eingereichten vierteljährlichen Berichte welche bei der Börsenaufsicht eingereicht werden. Ziel ist es, automatisch Zusammenfassungen der Geschäftsaktivität der Firma zu erstellen. So besteht die Liste der zu extrahierenden Identitäten aus Geschäftsart, Geschäftsbereich, Geschäftsführer usw.

Zusammenfassungen

Die Aufgabe, eine Zusammenfassung eines Textes zu erstellen, kann man sich exakt wie die Aufgabenstellung früher im Deutschunterricht vorstellen. Das Ziel ist es, eine möglichst echt wirkende, menschliche Zusammenfassung mit allen relevanten Inhalten zu erstellen. Dabei müssen selbstverständlich geltende Rechtschreib- und Grammatikregeln eingehalten werden. Die Herausforderung dabei ist es, dem Computer beizubringen wichtige und relevante Inhalte von unwichtigen Inhalten zu trennen.

Anwendungsbeispiel 6:

Eine Onlinenachrichtenagentur hat durch Analyse des Nutzungsverhalten der Website herausgefunden das immer weniger Leute die Artikel komplett bis zum Ende durchlesen. Um Lesern das extrahieren von relevanten Informationen zu erleichtern, soll automatisch eine Zusammenfassung für vorhandene und neuen Artikeln erstellt werden. Die Zusammenfassung soll in Länge und Sprachkomplexität abhängig vom Nutzerprofil erstellt werden.

Übersetzungen

Beim Anwendungsfall einer Textübersetzung soll der Text von einer Sprache in eine andere transferieren werden, unter Einhaltung der geltenden Rechtschreib- und Grammatikregeln und ohne den Inhalt zu verändern. Dabei hat der Computer ähnliche Probleme mit dem Übersetzen von Texten wie ein Mensch. Es muss stets die Balance zwischen inhaltlicher und grammatikalischer Korrektheit gehalten werden, ohne sich dabei vom Originaltext zu entfernen.

Anwendungsbeispiel 7:

Ein national agierender Zulieferbetrieb möchte seinen Absatzmarkt international erweitern. Dazu müssen alle vorhandenen technischen Spezifikationen in die Sprache der Zielmärkte übersetzt werden. Eine besondere Herausforderung besteht in der Übersetzung von technischen, branchenspezifischen Vokabular.

Wie haben sich die NLP-Modelle entwickelt?

Die Geschichte von NLP-Modellen lässt sich in drei Epochen unterteilen: Naive Modelle, statische Vektormodelle und dynamische Vektormodelle.

In den Anfängen von NLP Modellen wurde versucht, den Sinn von Texten durch das Zählen von Wörtern oder Wortpaaren zu ermitteln. Dazu war ein sehr intensives Vorbearbeiten der Texte notwendig. Das eigentliche Rechnen der Modelle, basierend auf den Zählständen, ist (mit heutigen Computern) äußerst schnell zu bewerkstelligen. Allerdings geht durch das Zählen der Wörter jeglicher Kontext verloren.

Der nächste Entwicklungsschritt waren statische Vektormodelle. Der Gedanke hinter diesen Modellen ist, dass jedes Wort durch einen Vektor, also eine Zahlenreihe, repräsentiert wird. Diese Zahlenreihen werden meist durch Zuhilfenahme von Deep Learning Modellen berechnet. Sie dienen anschließend als Eingabe für ein weiteres Modell, z.B. wiederum ein Deep Learning Modell, dass die Zahlenreihe nutzt, um damit die eigentliche Aufgabe, z.B. die Klassifikation der Texte, zu lösen. Durch Zuhilfenahme der Vektoren war es möglich, den Kontext von Wörtern besser zu erfassen. D.h. bei dem Berechnen eines Vektors für ein Wort werden andere, dieses Wort umgebende Wörter, mitbetrachtet. Allerdings sind die Vektoren für ein gleich geschriebenes Wort noch identisch, unabhängig von der eigentlichen Bedeutung. Bei dem unten gezeigten Beispiel wäre der Vektor für ‚Bank‘ jeweils der gleiche.

Ich sitze auf der Bank. (Bank = Sitzgelegenheit)

Ich bringe mein Geld zur Bank. (Bank = Geldhaus)

Das berechnen der Vektoren sowie des Modells ist sehr zeit- und rechenintensiv. Allerdings gestaltet sich die Vorhersage, durch den fehlenden Kontext der Vektoren, noch sehr effizient.

Die aktuellste Generation von NLP Modellen ist ähnlich der zweiten Generation, allerdings werden nun Vektoren mit Bezug auf den Kontext des Wortes berechnet. Somit würde in dem obenstehenden Beispiel für die Sitzbank ein anderer Vektor berechnet werden als für das Geldhaus. Das macht sowohl die Berechnung des Modells als auch die Vorhersage sehr rechenintensiv.

Wieso ist NLP so relevant geworden?

Den Beginn der „New-Area of NLP“ hat Google Ende 2018 mit dem sogenannten BERT Modell eingeläutet (hier geht es zum offiziellen GitHub repository). Seitdem erscheinen monatlich Anpassungen und Weiterentwicklungen des Modells von Universitäten, aber auch anderen Firmen wie Facebook und natürlich von Google selbst. Die Mehrheit dieser Modelle steht der breiten Masse kostenfrei zur Verfügung – fast immer ist die Verwendung auch für den kommerziellen Zweck freigegeben.

Die Performance dieser neusten Generation von NLP Modellen ist in vielen Bereichen auf Augenhöhe mit, oder bereits über, den Ergebnissen, die von Menschen erzielt werden können.

Die Forschung hat Datensätze für verschiedene Aufgaben und Teilbereiche der Sprachverarbeitung entwickelt. Diese Aufgaben wurden zunächst von Menschen gelöst, um einen Referenzwert zu schaffen, der von Computern geschlagen werden soll. Mittlerweile sind NLP Modelle in der Lage, in fast allen Bereichen nahezu menschliche Ergebnisse zu liefern.

Zu beachten ist, dass die Datensätze sehr generalistisch sind. Jeder dieser Benchmark-Datensätze versucht in seinem Teilbereich eine möglichst große Abdeckung zu erlangen, um eine möglichste gute, generelle Aussage über die Performance zu treffen. Businessprobleme hingegen sind meist deutlich konkreter. So kann es sein, dass ein Modell sehr gut in der Lage ist, die generelle Stimmung von Texten aller Art zu erfassen und somit eine gute, hohe Bewertung in diesem Bereich erlangt.

Ein Businessproblem könnte sein, dass die Stimmung von Kundenbeiträgen in sozialen Netzwerken oder von eingehenden Emails von Kundenbeschwerden zu bewerten. Von einem menschlichen Standpunkt aus gesehen, sind beide Aufgaben sehr ähnlich. Für eine Maschine kann es einen großen Unterscheid machen, ob es sich um kurze, informellen Texte, wie Beiträge aus sozialen Medien, oder um längere, formelle Texte, wie E-Mails, handelt. Eine Evaluation der Modelle auf das Business-Problem ist unerlässlich.

Wie ist NLP so gut anwendbar geworden?

Bis vor wenigen Jahren gab es in der Entwicklung von künstlicher Intelligenz,  und speziell für den Teilbereich NLP, drei grundlegende Probleme, die die Entwicklung und Adaption dieser Modelle erschwert hat. Die Probleme hingen mit der Ressourcenallokation in den drei Bereichen Daten, Rechenleistung und Humankapital zusammen. Alle drei Punkte wurden durch das Vortrainieren von Modellen deutlich entschärft.

Die großen, relevanten Firmen in der NLP-Modellentwicklung investieren in diese Ressourcen und stellen im Anschluss diese vortrainierten Modelle meist kostenfrei zur Verfügung. Die Modelle sind bereits sehr gut im generellen Verstehen von Texten, aber lassen meist noch Raum für Verbesserungen bei spezifischen Problemen. Der Löwenanteil an Ressourcen wird jedoch für den ersten Teil, dem generalistischen Repräsentieren von Text, benötigt. Diese vortrainierten Modelle lassen sich nun mit Verhältnis wenig Aufwand auf bestimmte Businessprobleme feinabstimmen. Durch das Feinabstimmten können exzellente Ergebnisse mit minimalstem Aufwand und geringen Kosten erzielt werden.

Einstiegsbarriere: Datenverfügbarkeit

Mit zunehmender Komplexität der Modelle wächst der Bedarf an Daten, welche für das Training benötigt werden, exponentiell. Die Performance dieser Modelle kommt durch das Betrachten des Kontextes eines Wortes zustande. Folglich ist es notwendig, dass ein Modell möglichst viele Wörter in möglichst vielen Kombinationen sieht. Durch das Internet gibt es Zugriff auf sehr große Textsammlungen. So wurde das vorhin erwähnte BERT Modell auf diversen Büchern mit zusammen etwa 800 Millionen Wörtern sowie der kompletten englischsprachigen Plattform Wikipedia mit etwa 2,5 Milliarden Wörtern trainiert.

Einstiegsbarriere: Rechenleistung

Aus dem immer weiter ansteigenden Bedarf an Daten sowie der ansteigenden Modellkomplexität ergibt sich ein immer größerer Bedarf an Rechenleistung. Dabei lassen sich einige Punkte beobachten. Die Leistung von Computern steigt jedes Jahr massiv an, man spricht von einer Verdoppelung der Rechenleistung etwa alle zwei Jahre. Gleichzeitig wird Rechenleistung immer günstiger. Seit dem Siegeszug von Cloudanbietern wurde der Zugang zu Rechenleistung demokratisiert. Extrem performante und spezialisierte Computercluster sind nun nicht mehr nur für große Firmen, sondern für jedermann bei einer minutengenauen Abrechnung verfügbar.

Einstiegsbarriere: Talentakquisition

In den Anfängen von KI war es notwendig, entweder selbst ein kompetitives Entwicklungsteam innerhalb der eigenen Organisation aufzubauen oder die komplette Entwicklung von spezialisierten Firmen einzukaufen. Dadurch war es erforderlich, finanziell sehr stark in Vorleistung zu gehen, um nach einer oft mehrjährigen Entwicklungszeit ein fertiges KI-Produkt in Betrieb nehmen zu können. Oft sind solche Projekte fehlgeschlagen oder haben einen zu geringen Mehrwert gestiftet. Finanzielle Investitionen mit solch einem Risikoprofil waren meist nur für große multinationale Unternehmen möglich. Die meisten der neu entwickelten NLP-Modelle sind heutzutage frei zugänglich, auch für kommerzielle Zwecke. Somit ist es möglich, innerhalb von Wochen, anstatt Monaten oder Jahren, einen Machbarkeitsnachweis zu bekommen. Die Einführungszeit eines kompletten Produktes hat sich von Jahren auf Monate reduziert. Iterationen in der Produktentwicklung sind nun sehr schnell möglich, mit einem geringen initialen Investment.

Welche Herausforderung bestehen weiterhin?

Viele der ursprünglich vorhandenen Probleme wurden entschärft oder komplett gelöst. Diese Entwicklungen haben vor allem den Zeitaufwand bis zum Abschluss einer Machbarkeitsstudie extrem verkürzt. 

Modell

Aktuell sind vortrainierte Modelle von einer Vielzahl an Firmen und Anbietern vorhanden. Diese werden laufend weiterentwickelt und oft wird nach einigen Monaten eine neuere, verbesserte Version veröffentlicht. Außerdem werden von ein- und demselben Modell zum gleichen Zeitpunkt mehrere Versionen veröffentlicht. Diese unterscheiden sich oftmals in der Komplexität oder der Sprache.

Es ist extrem wichtig, in der Anfangsphase eines NLP-Projekts Modelle zu sondieren und zu evaluieren. Grundsätzlich lässt sich die Performance in zwei verschiedene Dimensionen aufteilen: Die Qualität der Ergebnisse und die Ausführungsgeschwindigkeit.

Die Qualität von Modellergebnisse zu beurteilen, ist je nach Aufgabe häufig anspruchsvoll. Bei der Klassifizierung von Emotionen lässt sich meistens eindeutig bestimmen, ob das Modell richtig oder falsch lag. Das Beurteilen von Zusammenfassungen ist deutlich schwieriger. Es ist sehr wichtig in der Anfangsphase eines Projektes ein Gütemaß zu bestimmen, das technisch umsetzbar ist, aber auch das Businessproblem widerspiegelt.

Die zweite Dimension der Modellperformance ist die Ausführungsgeschwindigkeit. Diese umfasst sowohl die benötigte Zeit für das Training als auch für die Vorhersage. Dabei ist es sehr wichtig, frühzeitig den Anspruch an das Modell mit allen Projektpartnern abzustimmen. So hat ein Modell, welches live und innerhalb von Millisekunden Anfragen beantworten muss, andere Eigenschaften als ein Modell, welches einmal pro Tag über Nacht Ergebnisse berechnet.

Daten

Das Thema Daten ist generell bei KI und vor allem im Bereich NLP ein zweischneidiges Schwert. Einerseits sind Daten generell vorhanden und es existieren Computersysteme, die in der Lage sind, diese zu verarbeiten. Durch das Vortrainieren von Modellen wird uns ein Großteil der Arbeit mit Daten abgenommen. Andererseits sind vortrainierte Modelle immer darauf ausgelegt, möglichst gut in einer Vielzahl von Aufgaben zu funktionieren. Oft liefern die vortrainieren Modelle ohne eine Feinabstimmung bereits gute, aber keine herausragenden Ergebnisse.

Die Feinabstimmung erfolgt meist in zwei Dimensionen. Das Modell muss zunächst auf Spracheigenheiten und Feinheiten angepasst werden – das kann spezielles Vokabular sein, aber auch Slang und Dialekt. So gibt es einen großen Unterschied zwischen Beiträgen aus den Sozialen Medien und Anleitungen für produktionstechnische Verfahren.

Die zweite Dimension bezieht sich auf die eigentliche Aufgabenstellung. Um eine herausragende Leistung zu erlangen, müssen Modelle immer auf das Businessproblem abgestimmt werden. Ein Modell, das übersetzen kann, unterscheidet sich erheblich von einem Modell, das Emotionen klassifizieren kann. Für diese Feinabstimmung werden Texte/Daten benötigt, welche auf die Zielsprache und das Zielproblem abgestimmt sind. Die Texte müssen aufbereitet und dem Modell zugeführt werden. Je nach Komplexität und Qualität der Daten kann dies noch immer ein aufwendiger Prozess sein.

Rechenleistung

Der Fakt, dass Computer immer besser werden und Rechenleistung immer günstiger wird, ist einer der Hauptgründe für die Adaption von KI. Wie bereits mehrfach erwähnt, ist es durch vortrainierte Modelle nicht mehr notwendig, den Löwenanteil der Rechenleistung selbst zu erbringen. Computerleistung wird lediglich für die Datenverarbeitung und die Feinabstimmung der Modelle benötigt. Dies ist ein Bruchteil von der Rechenleistung, die für das komplette Training von Anfang bis Ende benötigt wird. Dennoch ist es meist mehr als ein Standard-Computer in einer angemessenen Zeit bewerkstelligen könnte. Daher wird für die Feinabstimmung meist auf Cloudcomputing zurückgegriffen. Cloudressourcen werden in der Regel minutengenau abgerechnet und sind daher sehr kostengünstig. Allerdings unterscheidet sich der Ablauf eines Trainings mittels Cloudcomputing deutlich von einem Training in einem Standard-Rechenzentrum, weswegen in diesem Bereich Wissen in der eigenen Organisation entweder aufgebaut oder von externen Dienstleistern eingekauft werden muss.

Was können wir in der Zukunft von NLP erwarten?

Vom gesamten Bereich der künstlichen Intelligenz wird an NLP aktuell am aktivsten geforscht. Es sind in den nächsten Monaten und Jahren noch einige interessante Entwicklungen zu erwarten und derzeit zeichnen sich zwei Entwicklungen mit sehr interessanten praktischen Implikationen ab.

Wir erwarten kurz- bis mittelfristig den praktischen Einsatz von sogenannten Zero-Shot Modellen. Diese Modelle sind für ein gewisses Aufgabengebiet wie Sequenzklassifikation trainiert. Die Neuheit ist, dass diese Modelle sehr gute Ergebnisse liefern, ohne jeweils domänenspezifische Daten gesehen zu haben. Somit entwickeln diese Modelle eine Art „generelle“ Intelligenz. Damit wird die Feinabstimmung von Modellen deutlich einfacher oder entfällt komplett.

Der nächste zu erwartende Schritt sind sogenannte General Purpose Modelle. Diese Art von Modellen können jedes Aufgabengebiet auf ungesehenen Daten lösen, wodurch die komplette Feinabstimmung entfallen würde. Erste Versuche mit diesen Modellen scheinen sehr gute Ergebnisse zu liefern, allerdings sind die Modelle extrem groß und stellen sehr hohe Anforderungen an die Rechenleistung. Damit ist die Inbetriebnahme dieser Modelle aktuell äußerst schwer und teuer. Noch gibt es nahezu keine praktischen Einsatzgebiete. Wir erwarten in den nächsten Jahren deutliche Sprünge hinsichtlich Praktikabilität und Performance.

Zusammenfassung

Die jüngsten Entwicklungen in dem Bereich der Sprachprozessierung sind beeindruckend und schnell zugleich. Den Startschuss der neusten Entwicklungen gab Google mit der Veröffentlichung des BERT-Modells vor knapp zwei Jahren und seitdem werden in einem Wochenrhythmus neue Modelle von Firmen und Universitäten rund um die Welt veröffentlicht. Diese Modelle verbessern oft die Ergebnisse von vorhandenen Problemen oder ermöglichen es, vorhandene Ressourcen effizienter einzusetzen. Probleme welche vor zwei Jahren noch als unlösbar galten sind nun oft sehr gut lösbar und auch im Hinblick auf einzusetzende Ressourcen und Entwicklungszeit erschwinglich. Die notwendige Zeit, eine Machbarkeitsstudie zu erstellen, wurde extrem verkürzt.

 

As a data scientist, it is always tempting to focus on the newest technology, the latest release of your favorite deep learning network, or a fancy statistical test you recently heard of. While all of this is very important, and we here at STATWORX are proud to use the latest open-source machine learning tools, it is often more important to take a step back and have a closer look at the problem we want to solve.

In this article, I want to show you the importance of framing your business question in a different way – the data science way. Once the problem is clearly defined, we are more than happy to apply the newest fancy algorithm. But let’s start from the beginning!

The Initial Problem

Management View

Let’s assume for a moment that you are a data scientist here at STATWORX. Monday morning, at 10 o’clock the telephone rings, and a manager of an international bank is on the phone. After a bit of back and forth, the bank manager explains that they have a problem with defaulting loans and they need a program that predicts loans which are going to default in the future. Unfortunately, he must end the call now, but he’ll catch up with you later. In the meanwhile, you start to make sense of the problem.

Data Scientist View

While it’s clear for the bank manager that he provided you with all necessary information, you grab another cup of coffee, lean back in your chair and recap the problem:

  • The bank lends money to customers today
  • The customer promises the bank to pay back the loan bit by bit over the next couple of months/years
  • Unfortunately, some of the customers are not able to do so and are going to default on the loan

So far everything is fine. The bank will give you data of the past and you are instructed to make a prediction. Fair enough, but what specifically was there to predict again? Do they need to know whether every single loan is going to default or not? Are they more concerned about the default trend throughout the whole bank?

Data Science Explanation

From a data science perspective, we differentiate between two sorts of problems: Classification and Regression tasks. The way we prepare the data and the models we apply are inherently different between the two tasks. Classification problems, as the name suggested, assign data points into a specific category. For bank loans, one approach could be to construct two categories:

  • The loan defaulted
  • The loan is still performing

On the other hand, the output of a Regression problem is a continuous variable. In this case, this could be:

  • The percentage of loans which are going to default in a given month
  • The total amount of money the bank will lose in a given month

From now on, it’s paramount to evaluate with the clients what problem they actually want to solve. While it’s a lot of fun to play around with the best tech stack, it is of the highest importance to never forget about the business needs of the client. I’ll present you two possible scenarios, one for the classification and one for the regression case.

Regression and Classification Task

Scenario Classification Problem

Management View

For the next day, you set up a phone conference with the manager and decision-makers of the bank to discuss the overall direction of the project. The management board of the bank decided that it is more important to focus on the default prediction of single loans, instead of the overall default trend. Now you know that you have to solve a classification problem. Further, you ask the board what exactly they expect from the model.

Manager A: I want to have the best performing model possible!

Manager B: As long as it predicts reality as accurate as possible, I’m happy 🙂

Manager C: As long as it catches every defaulted loan for sure…

Manager A: … but of course, it should not predict too many loans wrong!

Data Scientist View

You try to match every requirement from the bank. Understandably, the bank wants to have the perfect model, which makes little to no mistakes. Unfortunately, there is always an error. You are still unsure which error is worse for the bank. To properly continue your work, it is important to define with the client which problem exactly to solve and, therefore, which error to minimize. Some options could be:

  • Catch every loan that will default
  • Make sure the model does not classify a performing loan as a defaulted loan
  • Some kind of weighted average between both of them

Have a look at the right chart above to see how it could look like.

Data Science Explanation

To generate predictions, you have to train a model on the given data. To tell the model how well it performed and to punish it for mistakes, it is necessary to define an error metric. The choice of the error metric always depends on the business case. From a technical point of view, it is possible to model nearly every business case, however, there are four metrics that are used in most classification problems.

    \[Accuracy = frac{# : correctly : classified : loans}{# : loans}\]

This metric measures, as the name suggests, how accurate the model can predict the loan status. While this is the most basic metric one can think of, it’s also a dangerous one. Let’s say the bank tells us that roughly 5% of the loans on the balance sheet default. If, for some reason, our model never predicts defaults. In other words, the model classifies every loan as a non-defaulting loan. The accuracy is immediately 95/100 = 95%. For datasets where the classes are highly imbalanced, it is usually a good idea to discard accuracy.

    \[Recall = frac{# : correctly : classified : defaulted : loans }{# : all : in : reality : defaulted : loans}\]


Optimizing the machine learning algorithm for recall would ensure that the algorithm catches as many defaulted loans as possible. On the flip side, an algorithm that predicts perfectly all defaulted loans as a default is often the result that the algorithm predicts too many loans as defaulted. Many loans that are not going to default are also flagged as default.

    \[Precision = frac{# : correctly : classified : defaulted : loans}{# : all : as : default : predicted : loans}\]


High precision ensures that all of the loans the algorithm flags as a default are classified correctly. This is done at the expense of the overall amount of loans which are flagged as default. Therefore, it might not be possible to flag every loan which is going to default as a default, but the loans which are flagged as defaults are most likely really going to default.

    \[F-beta : score = (1+beta^2) * frac{Precision * Recall}{(beta^2 * Precision) * Recall}\]


Empirically speaking, an increase in recall is almost always associated with a decrease in precision and vice versa. Often, it is desired to balance precision and recall somehow. This can be done with the F-beta score.

Scenario Regression Problem

Management View

During the phone conference (same one as in the classification scenario), the decision-makers from the bank announced that they want to predict the overall default trends. While that’s already important information, you evaluate with the client what exactly their business need is. At the end you’ll end up with a list of requirements:

Manager A: It’s important to match the overall trend as close as possible.

Manager B: During normal times, I won’t pay too much attention to the model. However, it is absolute necessary that the model performs well in extreme market situations.

Manager C: To make it as easy and convenient to use as possible and to be able to explain it to the regulating agency, it has to be as explainable as possible.

Data Science View

Similar to the last scenario, there is again a tradeoff. It is a business problem to define which error is worse. Is every deviation from the ground truth equally bad? Is a certain stability of the prediction error important? Does the client care about the volatility of the forecast? Does a baseline exists?

Have a look at the left chart above to see how it could look like.

Data Science Explanation

Once again, there are several metrices one can choose from. The best metric always depends on the business need. Here are the most common ones:

    \[Mean : Absolut : Error = frac{1}{n} sum(actual : output - predicted : output)\]


The Mean Absolute Error (MAE) calculates, as the name suggests, how far the predictions are off in absolute terms. While the number is easy to interpret, it treats every deviation in the same way. On a 100-day time interval, being every day off by 1 unit is the same as predicting everything, every day right but being one day off by 100 units.

    \[Mean : Squared : Error = frac{1}{n} sum(actual : output - predicted : output)^2\]


The Mean Squared Error (MSE) also calculates the difference between the actual and the predicted output. This time, the deviation is weighted. Extreme values are worse compared to many small errors.

    \[R^2 = 1 - frac{MSE(model)}{MSE(baseline)}\]


The R^2 compares the model to evaluate against a simple baseline model. The advantage is that the output is easy to interpret. A value of 1 describes the perfect model, while a value close to 0 (or even negative) describes a model with room for improvement. This metric is commonly used among economists and econometricians and, therefore, in some industries a metric to consider. However, it is also relatively easy to get a high R^2, which makes it hard to compare.

    \[Mean : Absolute : Percentage : Error = frac{1}{n} sum frac{actual : output - predicted : output}{actual : output} * 100\]


The Mean Absolute Percentage Error (MAPE) measures the absolute deviation from the predicted values. On the contrary to the MAE, the MAPE displays them in relative terms, which makes it very easy to interpret and to compare. The MAPE has its own set of drawbacks and caveats. Fortunately, my colleague Jan already wrote an article about it. Check it out if you want to learn more about it here

Conclusion

In either one of the cases, the classification or the regression case, the “right” answer to the problem depends on how the problem is actually defined. Before applying the latest machine learning algorithm, it is crucial that the business question is well defined. A strong collaboration with the client team is necessary and is the key to achieving the best result for the client. There is no one-size-fits-all data science solution. Even though the underlying problem is the same for every stakeholder in the bank, it might be worth it to train several models for every department. It all boils down to the business needs!

We still haven’t covered several other problems, which might arise in subsequent steps. How is the default of a loan defined? What is the prediction horizon? Do we have enough data to cover all business cycles? Is the model just used internally or do we have to explain the model to a regulating agency? Should we optimize the model for some kind of internal resource constraints? To discuss this and more, feel free to reach out to me at dominique.lade@statworx.com or send me a message via LinkedIn.

As a data scientist, it is always tempting to focus on the newest technology, the latest release of your favorite deep learning network, or a fancy statistical test you recently heard of. While all of this is very important, and we here at STATWORX are proud to use the latest open-source machine learning tools, it is often more important to take a step back and have a closer look at the problem we want to solve.

In this article, I want to show you the importance of framing your business question in a different way – the data science way. Once the problem is clearly defined, we are more than happy to apply the newest fancy algorithm. But let’s start from the beginning!

The Initial Problem

Management View

Let’s assume for a moment that you are a data scientist here at STATWORX. Monday morning, at 10 o’clock the telephone rings, and a manager of an international bank is on the phone. After a bit of back and forth, the bank manager explains that they have a problem with defaulting loans and they need a program that predicts loans which are going to default in the future. Unfortunately, he must end the call now, but he’ll catch up with you later. In the meanwhile, you start to make sense of the problem.

Data Scientist View

While it’s clear for the bank manager that he provided you with all necessary information, you grab another cup of coffee, lean back in your chair and recap the problem:

So far everything is fine. The bank will give you data of the past and you are instructed to make a prediction. Fair enough, but what specifically was there to predict again? Do they need to know whether every single loan is going to default or not? Are they more concerned about the default trend throughout the whole bank?

Data Science Explanation

From a data science perspective, we differentiate between two sorts of problems: Classification and Regression tasks. The way we prepare the data and the models we apply are inherently different between the two tasks. Classification problems, as the name suggested, assign data points into a specific category. For bank loans, one approach could be to construct two categories:

On the other hand, the output of a Regression problem is a continuous variable. In this case, this could be:

From now on, it’s paramount to evaluate with the clients what problem they actually want to solve. While it’s a lot of fun to play around with the best tech stack, it is of the highest importance to never forget about the business needs of the client. I’ll present you two possible scenarios, one for the classification and one for the regression case.

Regression and Classification Task

Scenario Classification Problem

Management View

For the next day, you set up a phone conference with the manager and decision-makers of the bank to discuss the overall direction of the project. The management board of the bank decided that it is more important to focus on the default prediction of single loans, instead of the overall default trend. Now you know that you have to solve a classification problem. Further, you ask the board what exactly they expect from the model.

Manager A: I want to have the best performing model possible!

Manager B: As long as it predicts reality as accurate as possible, I’m happy 🙂

Manager C: As long as it catches every defaulted loan for sure…

Manager A: … but of course, it should not predict too many loans wrong!

Data Scientist View

You try to match every requirement from the bank. Understandably, the bank wants to have the perfect model, which makes little to no mistakes. Unfortunately, there is always an error. You are still unsure which error is worse for the bank. To properly continue your work, it is important to define with the client which problem exactly to solve and, therefore, which error to minimize. Some options could be:

Have a look at the right chart above to see how it could look like.

Data Science Explanation

To generate predictions, you have to train a model on the given data. To tell the model how well it performed and to punish it for mistakes, it is necessary to define an error metric. The choice of the error metric always depends on the business case. From a technical point of view, it is possible to model nearly every business case, however, there are four metrics that are used in most classification problems.

    \[Accuracy = frac{# : correctly : classified : loans}{# : loans}\]

This metric measures, as the name suggests, how accurate the model can predict the loan status. While this is the most basic metric one can think of, it’s also a dangerous one. Let’s say the bank tells us that roughly 5% of the loans on the balance sheet default. If, for some reason, our model never predicts defaults. In other words, the model classifies every loan as a non-defaulting loan. The accuracy is immediately 95/100 = 95%. For datasets where the classes are highly imbalanced, it is usually a good idea to discard accuracy.

    \[Recall = frac{# : correctly : classified : defaulted : loans }{# : all : in : reality : defaulted : loans}\]


Optimizing the machine learning algorithm for recall would ensure that the algorithm catches as many defaulted loans as possible. On the flip side, an algorithm that predicts perfectly all defaulted loans as a default is often the result that the algorithm predicts too many loans as defaulted. Many loans that are not going to default are also flagged as default.

    \[Precision = frac{# : correctly : classified : defaulted : loans}{# : all : as : default : predicted : loans}\]


High precision ensures that all of the loans the algorithm flags as a default are classified correctly. This is done at the expense of the overall amount of loans which are flagged as default. Therefore, it might not be possible to flag every loan which is going to default as a default, but the loans which are flagged as defaults are most likely really going to default.

    \[F-beta : score = (1+beta^2) * frac{Precision * Recall}{(beta^2 * Precision) * Recall}\]


Empirically speaking, an increase in recall is almost always associated with a decrease in precision and vice versa. Often, it is desired to balance precision and recall somehow. This can be done with the F-beta score.

Scenario Regression Problem

Management View

During the phone conference (same one as in the classification scenario), the decision-makers from the bank announced that they want to predict the overall default trends. While that’s already important information, you evaluate with the client what exactly their business need is. At the end you’ll end up with a list of requirements:

Manager A: It’s important to match the overall trend as close as possible.

Manager B: During normal times, I won’t pay too much attention to the model. However, it is absolute necessary that the model performs well in extreme market situations.

Manager C: To make it as easy and convenient to use as possible and to be able to explain it to the regulating agency, it has to be as explainable as possible.

Data Science View

Similar to the last scenario, there is again a tradeoff. It is a business problem to define which error is worse. Is every deviation from the ground truth equally bad? Is a certain stability of the prediction error important? Does the client care about the volatility of the forecast? Does a baseline exists?

Have a look at the left chart above to see how it could look like.

Data Science Explanation

Once again, there are several metrices one can choose from. The best metric always depends on the business need. Here are the most common ones:

    \[Mean : Absolut : Error = frac{1}{n} sum(actual : output - predicted : output)\]


The Mean Absolute Error (MAE) calculates, as the name suggests, how far the predictions are off in absolute terms. While the number is easy to interpret, it treats every deviation in the same way. On a 100-day time interval, being every day off by 1 unit is the same as predicting everything, every day right but being one day off by 100 units.

    \[Mean : Squared : Error = frac{1}{n} sum(actual : output - predicted : output)^2\]


The Mean Squared Error (MSE) also calculates the difference between the actual and the predicted output. This time, the deviation is weighted. Extreme values are worse compared to many small errors.

    \[R^2 = 1 - frac{MSE(model)}{MSE(baseline)}\]


The R^2 compares the model to evaluate against a simple baseline model. The advantage is that the output is easy to interpret. A value of 1 describes the perfect model, while a value close to 0 (or even negative) describes a model with room for improvement. This metric is commonly used among economists and econometricians and, therefore, in some industries a metric to consider. However, it is also relatively easy to get a high R^2, which makes it hard to compare.

    \[Mean : Absolute : Percentage : Error = frac{1}{n} sum frac{actual : output - predicted : output}{actual : output} * 100\]


The Mean Absolute Percentage Error (MAPE) measures the absolute deviation from the predicted values. On the contrary to the MAE, the MAPE displays them in relative terms, which makes it very easy to interpret and to compare. The MAPE has its own set of drawbacks and caveats. Fortunately, my colleague Jan already wrote an article about it. Check it out if you want to learn more about it here

Conclusion

In either one of the cases, the classification or the regression case, the “right” answer to the problem depends on how the problem is actually defined. Before applying the latest machine learning algorithm, it is crucial that the business question is well defined. A strong collaboration with the client team is necessary and is the key to achieving the best result for the client. There is no one-size-fits-all data science solution. Even though the underlying problem is the same for every stakeholder in the bank, it might be worth it to train several models for every department. It all boils down to the business needs!

We still haven’t covered several other problems, which might arise in subsequent steps. How is the default of a loan defined? What is the prediction horizon? Do we have enough data to cover all business cycles? Is the model just used internally or do we have to explain the model to a regulating agency? Should we optimize the model for some kind of internal resource constraints? To discuss this and more, feel free to reach out to me at dominique.lade@statworx.com or send me a message via LinkedIn.