Data Science, Machine Learning und KI
Kontakt

Heute feiern wir den jährlichen Christopher Street Day – das europäische Äquivalent zu Gay Pride oder Pride Parades, um für die Rechte von LGBTQIA+ Menschen und gegen Diskriminierung und Ausgrenzung zu kämpfen.

Seit 1969, als die erste Demonstration auf der Christopher Street in New York City stattfand, haben wir bereits viele Fortschritte gemacht: Heute ist die gleichgeschlechtliche Ehe in 30 Ländern rechtlich vollzogen und anerkannt, und das „unbestimmte“ Geschlecht ist in 20 Ländern rechtlich anerkannt.

Allerdings steht Homosexualität in vielen Ländern immer noch unter Strafe und selbst in fortschrittlicheren Ländern kommt es immer noch zu Gewalt gegen queere Menschen. Trotz der bereits erzielten Fortschritte ist es also noch ein weiter Weg bis zur Gleichstellung queerer Menschen. Der Christopher Street Day hat also nach wie vor seine Berechtigung: Als Protest gegen Ungerechtigkeit und als Zeichen für eine bunte, vielfältige und tolerante Gesellschaft.

Vorurteile in der KI – Ein sehr reales Problem

In den letzten Jahren haben die Themen Diskriminierung und Vorurteile noch an Relevanz gewonnen, denn mit der Digitalisierung schleichen sich diese Vorurteile auch in die Schlüsseltechnologie unserer Zukunft ein: Künstliche Intelligenz. Intelligente Computersysteme, die aus Daten lernen und unsere Gesellschaft verändern werden, wie wir es noch nie erlebt haben. Es ist von entscheidender Bedeutung, dass sie mit unterschiedlichen Datensätzen und unter Mitwirkung einer Vielzahl von Entwickler:innen programmiert werden. Andernfalls besteht die Gefahr, dass sie voreingenommene und diskriminierende KI-Systeme entwickeln.

Die Kontroverse um die Veröffentlichung von Googles Chatbot „Allo“ ist ein Paradebeispiel für diese potenzielle Falle. Google veröffentlichte Allo, seine neue Messaging-App, im Jahr 2016 mit großem Tamtam. Die App enthielt einen Chatbot namens „Smart Reply“, der auf der Grundlage früherer Interaktionen Antworten auf Nachrichten vorschlägt. Es stellte sich jedoch schnell heraus, dass der Bot gegenüber Frauen voreingenommen war und dazu neigte, abfällige und sexuell eindeutige Antworten auf Nachrichten von Nutzerinnen vorzuschlagen. Dieser Vorfall unterstreicht die Notwendigkeit für Unternehmen, bei der Entwicklung von KI stärker auf die potenziellen Risiken von Voreingenommenheit zu achten. Diversität muss in jeder Phase des Prozesses berücksichtigt werden, von der Datenerfassung über die Entwicklung von Algorithmen bis hin zu Nutzertests.

In der Tat gab es viele weitere Vorfälle von KI-Diskriminierung gegenüber Frauen und People of Color, wie z. B. Amazons Rekrutierungstool, das systematisch männliche Bewerber bevorzugte, oder Facebooks Kennzeichnungssystem für Bilder, das einen dunkelhäutigen Mann fälschlicherweise als Primaten identifizierte. Aber nicht nur Frauen und People of Color leiden unter Vorurteilen in der KI, auch die queere Community ist davon betroffen.

Case Study: DALL-E 2

Werfen wir dazu einen Blick auf DALL-E 2, das von OpenAI entwickelt wurde. Es ist eine der neuesten und bahnbrechendsten KI-Technologien, die es gibt. DALL-E 2 ist eine KI, die auf der Grundlage von Textbeschreibungen realistische Bilder und Kunstwerke erzeugt.

Um zu prüfen, wie voreingenommen oder gleichberechtigt diese KI-Lösung gegenüber queeren Menschen ist, habe ich DALL-E 2 angewiesen, Bilder auf der Grundlage des Eingabetextes „ein glückliches Paar“ mit verschiedenen Kunststilanweisungen (z. B. Ölgemälde oder digitale Kunst) zu erzeugen.

Wenn Ihr Euch die Ergebnisse anseht, seht Ihr, dass nur Bilder von heterosexuellen Paaren erzeugt wurden. Auch die Bilder, die auf dem Text „eine glückliche Familie“ basieren, unterscheiden sich in dieser Hinsicht nicht – es sind keine gleichgeschlechtlichen Eltern auf den Bildern zu sehen.

Um also ein Bild eines homosexuellen Paares zu erhalten, versuche ich, dem KI-Modell eine spezifischere Beschreibung zu geben: „ein glückliches queeres Paar“. Wie Ihr sehen könnt, hat DALL-E 2 schließlich einige Bilder von gleichgeschlechtlichen Paaren erzeugt. Aber auch hier scheint das System voreingenommen zu sein – es wurde kein einziges Bild eines lesbischen Paares erzeugt.

Die Ursachen der Diskriminierung bei Technologien wie DALL-E 2

Haben wir jetzt also die Bestätigung, dass KI homophob ist? Nicht so ganz. Es geht hier nicht um Homophobie oder Sexismus auf Seiten von DALL-E oder GPT-3. Diese Systeme reproduzieren die Strukturen und Hierarchien unserer Gesellschaft. Sie wiederholen nur, was sie in der Vergangenheit gelernt haben. Wenn wir diese Vorurteile ändern und Chancengleichheit schaffen wollen, müssen wir diese Systeme auf eine integrative Weise trainieren.

Warum genau sind KI-Systeme wie DALL-E 2 also voreingenommen und was können wir dagegen tun? Die Antwort auf diese Frage besteht aus drei Teilen:

  • den Daten,
  • dem Ziel,
  • und den Entwickler:innen.

#1 Daten

Erstens: KI-Systeme lernen nur das, was in den Daten enthalten ist. Wenn die Trainingsdaten verzerrt sind, ist auch die KI verzerrt. DALL-E 2 wurde mit Tausenden von Online-Bildbeschreibungspaaren aus dem Internet trainiert. Aufgrund historischer, sozialer und ethnischer Gegebenheiten, gibt es viel mehr heterosexuelle Paarbilder mit der Beschreibung „ein glückliches Paar“ als homosexuelle Paarbilder im Internet. DALL-E 2 hat also herausgefunden, dass die Beschreibung „ein glückliches Paar“ mit größerer Wahrscheinlichkeit mit heterosexuellen Paaren auf einem Bild assoziiert wird.

#2 Ziel

Zweitens: Damit ein KI-Algorithmus wie DALL-E 2 aus Daten lernen kann, braucht er ein Ziel zur Optimierung, eine Definition von Erfolg und Misserfolg. Genauso wie Ihr in der Schule gelernt habt, indem Ihr Eure Noten optimiert habt. Eure Noten haben Euch gezeigt, ob Ihr erfolgreich wart oder nicht, und was Ihr noch lernen müsst oder nicht.

In ähnlicher Weise lernt auch der Algorithmus, indem er sich die Daten ansieht und herausfindet, was mit Erfolg verbunden ist. Welche Situation führt zum Erfolg? Wenn wir also eine unvoreingenommene und faire künstliche Intelligenz schaffen wollen, müssen wir auch darüber nachdenken, welche Zielsetzung wir ihr geben. Wir müssen ihr sagen, dass sie sich vor Voreingenommenheit, Vorurteilen und Diskriminierung in Acht nehmen muss. Für DALL-E 2 könnte man zum Beispiel eine bestimmte Diversitätskennzahl in die Leistungsbewertungskriterien aufnehmen.

#3 Entwickler:innen

Drittens ist es die Entwickler:innengemeinschaft, die direkt oder indirekt, bewusst oder unbewusst ihre eigenen Vorurteile in die KI-Technologie einbringt. Sie wählen die Daten aus, sie definieren das Optimierungsziel und sie gestalten die Nutzung von KI. Meistens bringen sie ihre Voreingenommenheit nicht aktiv in diese Systeme ein. Wir alle leiden jedoch unter Vorurteilen, derer wir uns nicht bewusst sind. Diese Voreingenommenheit ist ein Versuch unseres Gehirns, die unglaublich komplexe Welt um uns herum zu vereinfachen. Die derzeitige Gemeinschaft der KI-Entwickler:innen besteht zu über 80 % aus weißen Cis-Männern. KI wird von einer sehr homogenen Gruppe entworfen, entwickelt und bewertet. Die Werte, Ideen und Vorurteile, die sich in KI-Systeme einschleichen, sind daher buchstäblich engstirnig.

Mögliche Lösungen für das Problem

Der entscheidende Schritt zu einer gerechteren und unvoreingenommeneren KI ist also eine vielfältige und integrative KI-Entwicklungsgemeinschaft. Unterschiedliche Menschen können die blinden Flecken und Vorurteile der anderen besser überprüfen.

Wenn wir über unsere eigenen Vorurteile nachdenken und gemeinsam daran arbeiten, die Vergangenheit nicht nur zu extrapolieren, sondern vorsichtig und kritisch aus ihr zu lernen, können wir die Welt zu einem viel vielfältigeren, integrativeren und gleichberechtigteren Ort machen. Nur dann können wir hoffen, KI-Technologien zu entwickeln, die wirklich inklusiv und fair sind.

Unsere Bemühungen um Diversität in der Entwicklung und am Arbeitsplatz

Wir bei statworx versuchen auch unser Bestes, um uns weiterzubilden und unseren Horizont zu erweitern. Wir engagieren uns aktiv für die Aufklärung der Gesellschaft im Bezug auf künstliche Intelligenz, z.B. in unserer Initiative AI & Society. Erst kürzlich habe ich im Namen der Initaitive zum Thema „Vorurteile in KI abbauen“ einen Blogartikel veröffentlicht und bei der Konferenz „Unfold“ in Bern einen Vortrag dazu gehalten.

Darüber hinaus haben wir uns entschlossen, die Charta der Vielfalt zu unterzeichnen. Die Charta der Vielfalt ist eine Arbeitgebendeninitiative zur Förderung von Vielfalt in Unternehmen und Institutionen. Ziel der Initiative ist es, die Anerkennung, Wertschätzung und Einbeziehung von Vielfalt in der Arbeitswelt in Deutschland voranzubringen. Für uns bei statworx ist dies ein Weg, um unseren Werten als Unternehmen gerecht zu werden, die auf Vielfalt, Inklusivität und Teamarbeit beruhen.

FYI: 20% dieses Artikels wurden vom KI Text Generator von neuroflash geschrieben. Livia Eichenberger Livia Eichenberger Livia Eichenberger Livia Eichenberger

Das erwartet dich:

Die Enter_Zukunft_IT ist eine Karrieremesse des Career Centers und des Fachbereichs Informatik & Mathematik der Goethe-Universität Frankfurt.

Wir sind mit einem eigenen Stand und gleich mehreren Kolleg:innen vertreten und freuen uns schon auf den Austausch mit interessierten Studierenden. Gerne stellen wir die verschiedenen Einstiegsmöglichkeiten bei statworx – vom Praktikum bis zur Festanstellung – vor und berichten aus unserem Arbeitsalltag

Die Teilnahme an der Messe ist für Besucher:innen kostenfrei.

Das erwartet dich:

Das Ziel der Messe ist es, Studierende der Studiengänge Wirtschaftsinformatik, Wirtschaftsmathematik und Data Science mit Unternehmen zu vernetzen.

Wir sind daher mit einem eigenen Stand vertreten und stellen statworx zudem im Rahmen einer kurzen Präsentation vor. 

Bei gutem Wetter findet die Messe in diesem Jahr draußen statt. Die Teilnahme an der Messe ist kostenfrei. Eine Vorab-Anmeldung ist nicht notwendig. Komm einfach vorbei und sprich uns an. 

 

Das erwartet dich:

Die konaktiva an der Technischen Universität Darmstadt ist eine der ältesten und größten studentisch organisierten Unternehmenskontaktmessen Deutschlands. Getreu dem Motto „Studierende treffen Unternehmen“ bringt sie jedes Jahr angehende Absolvent:innen und Unternehmen zusammen.

Auch wir sind dieses Jahr mit einem eigenen Stand und gleich mehreren Kolleg:innen vertreten und wir freuen uns schon auf den Austausch mit interessierten Studierenden. Gerne stellen wir die verschiedenen Einstiegsmöglichkeiten bei statworx – vom Praktikum bis zur Festanstellung – vor und berichten aus unserem Arbeitsalltag.

Darüber hinaus besteht die Möglichkeit uns im Rahmen von vorterminierten Einzelgesprächen abseits des Messetrubels näher kennen zu lernen und individuelle Fragen zu klären.

Die Teilnahme an der Messe ist für Besucher:innen kostenfrei.

Das erwartet dich:

Die Big Data World ist wieder zurück, 250+ Aussteller, 250+ Sprecher:innen und somit viele aufschlussreiche Vorträge und Informationen rund um die Themen AI & Analytics. Wir sind auch Teil dieser spannenden Messe und freuen uns auf Ihren Besuch an unserem Stand – M18. Bei uns können Sie Künstliche Intelligenz direkt erleben…

Egal, wo Sie in Ihrer Reise zum datengetriebenen Unternehmen stehen: Es ist immer Luft nach oben. Tools und Technik im BI & Analytics sowie im Feld der Künstlichen Intelligenz entwickeln sich rasant und damit auch die Möglichkeiten mit innovativen Use Cases Wertschöpfungspotenziale auszunutzen.

Ob Chief Data Officer oder Data Scientist, IT-Expert:in oder Anwender:in aus dem Businessbereich – wir beantworten Ihnen gerne alle Fragen – von der Strategie bis zur Implementierung.

Sie brauchen noch ein Ticket? Kein Problem, über diesen Ticketlink können Sie sich kostenlos anmelden.

Wir freuen uns darauf Sie zu sehen!

Das erwartet dich:

Dieses Event wird von AI Frankfurt Rhein-Main e.V. und dem Business Angels Frankfurt Rhein-Main e.V. veranstaltet. Das Event wendet sich an Start-ups aus ganz Deutschland.  

Für den KI-Sprechtag haben wir unsere AI Partner & Friends eingeladen. Dazu gehören AI Frankfurt Rhein-Main e.V., Business Angels Frankfurt Rhein-Main, NVIDIA Inception Program, Start Hub Hessen, Hessian.AI und AI Startup Rising.  

KI ist wichtig für euer Start-up und ihr sucht nach Kontakten und Know- how? Dann nehmt am KI-Sprechtag teil und erhaltet an einem Nachmittag umfassende Infos zu folgenden Topics: 

  • Intro: Stefan Jäger (AI Frankfurt Rhein-Main), Marcel Isbert (KI-Bundesverband) und Frank Müller (BA-FRM)  
  • Ist mein KI-Businessmodell sinnvoll? (Sebastian Heinz, STATWORX) 
  • KI-Infrastruktur: Welche? Wo? Aufwand? (Jochen Papenbrock, NVIDIA) 
  • Wie finde ich Investoren für mein KI-Startup? (Frank Müller, BA-FRM) 
  • Networking via wonder.me 

Beim KI-Sprechtag könnt ihr unseren Expert:innen all eure Fragen zum Thema KI stellen. Meldet euch jetzt an!

 

Hier kannst Du dich kostenlos zum Event anmelden: Anmeldung

Das erwartet dich:

START Summit ist Europas größte von Studierenden organisierte Konferenz für Unternehmertum und Technologie. Ziel ist es, Innovation aktiv zu fördern, indem mehr als 5000 Startups, Investoren, Unternehmen und junge Talente zusammengebracht werden.

Auch wir sind dieses Jahr bei der START Summit dabei, welche das erste mal seit 25 Jahren als Hybrid-Event stattfindet. Als Sponsor des START Hack vergeben wir AI Coachings für fünf Hackathon Teams, die eine Idee im Bereich AI erarbeitet haben und weiterentwickeln möchten.
Bei diesem Event kommen Founder, Investoren, Studierende und Unternehmen zusammen, ganz im Sinne der Innovation. Daher freuen wir uns auf zwei bzw. drei sehr interessante, informative und innovative Tage.

Hier kannst Du Tickets für das Event erwerben.

Einleitung

Jeder Data-Science- und KI-Experte wird Ihnen sagen: Reale Data Science und KI-Initiativen bringen verschiedene Herausforderungen mit sich, auf die weder praktische Programmierwettbewerbe noch theoretische Vorlesungen vorbereiten können. Und manchmal – erschreckend oft [1, 2] – führen diese Probleme in der Praxis dazu, dass vielversprechende KI-Projekte oder ganze KI-Initiativen scheitern. Seit geraumer Zeit wird eine rege Diskussion über die eher technischen Fallstricke und mögliche Lösungen geführt. Zu den bekannteren Problemen gehören z. B. isolierte Daten, schlechte Datenqualität, zu unerfahrene oder unterbesetzte DS & KI-Teams, unzureichende Infrastruktur für das Training und die Bereitstellung von Modellen. Ein weiteres Problem ist, dass zu viele Lösungen aufgrund organisatorischer Probleme nie in die Produktion überführt werden.

Erst in letzter Zeit hat sich der Fokus des Diskurses mehr auf strategische Fragen verlagert. Meiner Meinung nach wird diesen Aspekten jedoch immer noch nicht die Aufmerksamkeit zuteil, die sie verdienen.

Deshalb möchte ich in diesem Beitrag meine Meinung zu den wichtigsten (nicht-technischen) Gründen für das Scheitern von DS & KI-Initiativen darlegen. Darüber hinaus werde ich Ihnen verschiedene Ansätze zur Lösung dieser Probleme vorstellen. Ich bin Data & Strategy Consultant bei STATWORX und ich bin sicher, dass dieser Artikel eher subjektiv ist. Er spiegelt meine persönlichen Erfahrungen mit den Problemen und Lösungen wider, auf die ich gestoßen bin. 

Problem Nr. 1: Mangelnde Verknüpfung von Projektumfang und tatsächlichem Business-Problem Problem 1

Ein Problem, das viel häufiger auftritt, als man denken würde, ist die Fehlanpassung der entwickelten Data Science und KI-Lösungen an die tatsächlichen Geschäftsbedürfnisse. Das fertige Produkt erfüllt vielleicht genau die Aufgabe, die das DS- und KI-Team lösen wollte, aber die Anwender:innen suchen eventuell nach einer Lösung für eine ähnliche, aber deutlich andere Aufgabe.

Zu wenig Austausch durch indirekte Kommunikationskanäle oder das Fehlen einer gemeinsamen Sprache und eines gemeinsamen Referenzrahmens führt oft zu grundlegenden Missverständnissen. Das Problem ist, dass ironischerweise nur eine extrem detaillierte, effektive Kommunikation solche subtilen Probleme aufdecken kann.

Die Einbeziehung zu weniger oder selektiver Perspektiven kann zu einem bösen Erwachen führen

In anderen Fällen unterscheiden sich einzelne Teilprozesse oder die Arbeitsweisen einzelner Nutzenden sehr stark. Oft sind sie so unterschiedlich, dass eine Lösung, die für einen der Anwender:innen/Prozesse von großem Nutzen ist, für alle anderen kaum Vorteile bringt (die Entwicklung von Lösungsvarianten ist zwar manchmal eine Option, aber bei weitem nicht so kosteneffizient).

Wenn Sie Glück haben, stellen Sie dies bereits zu Beginn eines Projekts bei der Erhebung der Anforderungen fest. Wenn man Pech hat, kommt das böse Erwachen erst beim breiteren Nutzertest oder gar bei der Einführung, wenn sich herausstellt, dass die Nutzer:innen oder Expert:innen, die die bisherige Entwicklung beeinflusst haben, keinen allgemeingültigen Input geliefert haben und das entwickelte Werkzeug daher nicht allgemein einsetzbar ist.

Wie Sie diesem Problem entgegenwirken können:

  • Führen Sie ein strukturiertes und gründliches Requirements Engineering durch. Nehmen Sie sich die Zeit, mit so vielen Expert:innen und Nutzer:innen wie möglich zu sprechen, und versuchen Sie, alle impliziten Annahmen so explizit wie möglich zu machen. Obwohl das Requirements Engineering aus dem Wasserfall-Paradigma stammt, kann es leicht für die agile Entwicklung angepasst werden. Die ermittelten Anforderungen dürfen einfach nicht als endgültige Produktmerkmale verstanden werden, sondern als Elemente für Ihr anfängliches Backlog, die ständig (neu) bewertet und (neu) priorisiert werden müssen.
  • Definieren Sie unbedingt Erfolgsmessungen. Tun Sie dies vor Projektbeginn, am besten in Form von objektiv quantifizierbaren KPIs und Benchmarks. Dies trägt wesentlich dazu bei, das Geschäftsproblem bzw. den Geschäftswert, der der angestrebten Lösung zugrunde liegt, zu ermitteln.
  • Erstellen Sie, wann immer möglich und so schnell wie möglich, Prototypen, Mock-ups oder sogar Storyboards. Präsentieren Sie diese Lösungsentwürfe so vielen Testnutzern wie möglich. Diese Methoden erleichtern das Einholen von offenem und präzisem Nutzerfeedback, das in die weitere Entwicklung einfließt. Achten Sie darauf, dass Sie eine für die Gesamtheit der Nutzer repräsentative Stichprobe einbeziehen.

Problem Nr. 2: Effizienz- und Ressourcenverluste durch nicht strukturierte Data Science- und KI-Maßnahmen Problem 2

Dezentralisierte Data Science- & KI-Teams entwickeln ihre Anwendungsfälle oft mit wenig bis gar keinem Austausch oder Abgleich zwischen den aktuellen Anwendungsfällen und Backlogs der Teams. Dies kann dazu führen, dass verschiedene Teams versehentlich und unbemerkt (Teile) der gleichen (oder sehr ähnlichen) Lösung entwickeln.

In den meisten Fällen wird, wenn eine solche Situation entdeckt wird, eine der redundanten DS & KI-Lösungen eingestellt oder es werden keine zukünftigen Mittel für die weitere Entwicklung oder Wartung bereitgestellt. So oder so, die redundante Entwicklung von Anwendungsfällen führt immer zu einer direkten Verschwendung von Zeit und anderen Ressourcen ohne oder mit nur minimalem Zusatznutzen.

Problematisch ist auch die fehlende Abstimmung des Use Case Portfolios eines Unternehmens auf die allgemeine Geschäfts- oder KI-Strategie. Dies kann hohe Opportunitätskosten verursachen: Anwendungsfälle, die nicht zur allgemeinen KI-Vision beitragen, können unnötigerweise wertvolle Ressourcen blockieren. Außerdem werden potenzielle Synergien zwischen strategisch wichtigeren Anwendungsfällen (Use Cases) möglicherweise nicht voll ausgeschöpft. Und schließlich könnte der Aufbau von Kompetenzen in Bereichen erfolgen, die von geringer oder gar keiner strategischen Bedeutung sind.

Wie Sie diesem Problem entgegenwirken können:

  • Kommunikation ist der Schlüssel. Deshalb sollte es immer eine Reihe von Möglichkeiten für die Data-Science-Expert:innen innerhalb eines Unternehmens geben, sich zu vernetzen und ihre Erfahrungen und Best Practices auszutauschen – insbesondere bei dezentralen DS & KI-Teams. Damit dies funktioniert, ist es wichtig, eine Arbeitsatmosphäre der Zusammenarbeit zu schaffen. Der freie Austausch von Erfolgen und Misserfolgen und damit die interne Verbreitung von Kompetenzen kann nur ohne Konkurrenzdenken gelingen.
  • Eine weitere Möglichkeit, das Problem zu entschärfen, ist die Einrichtung eines zentralen Ausschusses, der mit der Verwaltung des DS und KI Use Case Portfolios der Organisation betraut ist. Diesem Ausschuss sollten Vertreter:innen aller (dezentralen) Data Science und KI-Abteilungen sowie der Geschäftsleitung angehören. Gemeinsam überwacht der Ausschuss die Abstimmung von Use Cases und der KI-Strategie, um Redundanzen zu vermeiden und Synergien voll auszuschöpfen.

Problem Nr. 3: Unrealistisch hohe Erwartungen an den Erfolg von Data Science und KI Problem 3

Es mag paradox klingen, aber ein zu großer Optimismus in Bezug auf die Möglichkeiten und Fähigkeiten von Data Science und KI kann dem Erfolg abträglich sein. Denn zu optimistische Erwartungen führen oft dazu, dass die Anforderungen unterschätzt werden, wie z. B. die für die Entwicklung benötigte Zeit oder der Umfang und die Qualität der benötigten Datenbasis.

Gleichzeitig sind die Erwartungen in Bezug auf die Modellgenauigkeit oft zu hoch, ohne dass man die Grenzen des Modells und die grundlegenden Mechanismen von Machine Learning kennt. Diese Unerfahrenheit kann dazu führen, dass viele wichtige Tatsachen nicht erkannt werden, einschließlich, aber nicht beschränkt auf die folgenden Punkte: die unvermeidliche Extrapolation historischer Muster auf die Zukunft; die Tatsache, dass externe Paradigmenwechsel oder Schocks die Generalisierbarkeit und Leistung von Modellen gefährden; die Komplexität der Harmonisierung von Vorhersagen mathematisch nicht verwandter Modelle; die geringe Interpretierbarkeit naiver Modelle oder die Dynamik der Modellspezifikationen aufgrund von Umschulungen.

DS & KI sind einfach keine Wunderwaffe, und zu hohe Erwartungen können dazu führen, dass die Begeisterung in tiefe Ablehnung umschlägt. Die anfänglichen Erwartungen werden fast zwangsläufig nicht erfüllt und weichen daher oft einer tiefgreifenden und undifferenzierten Ablehnung von DS & KI. Dies kann in der Folge dazu führen, dass weniger auffällige, aber nützliche Anwendungsfälle keine Unterstützung mehr finden.

Wie Sie diesem Problem entgegenwirken können:

  • Versuchen Sie in Ihrer Kommunikation mit Stakeholdern stets realistische Perspektiven zu vermitteln. Achten Sie darauf, eindeutige Botschaften und objektive KPIs zu verwenden, um Erwartungen zu steuern und Bedenken so offen wie möglich anzusprechen.
  • Die Weiterbildung der Stakeholder und des Managements in den Grundlagen von Machine Learning und KI versetzt sie in die Lage, realistischere Einschätzungen und damit sinnvollere Entscheidungen zu treffen. Technisch fundiertes Wissen ist oft nicht notwendig. Konzeptuelles Fachwissen auf einem relativ hohen Abstraktionsniveau ist ausreichend (und glücklicherweise viel leichter zu erlangen).
  • Schließlich sollte, wann immer möglich, ein PoC vor einem vollwertigen Projekt durchgeführt werden. Dies ermöglicht es, empirische Hinweise auf die Durchführbarkeit des Use Cases zu sammeln und hilft bei der realistischen Einschätzung der erwarteten Leistung, die anhand relevanter (vordefinierter!) KPIs gemessen wird. Wichtig ist es auch, die Ergebnisse solcher Tests ernst zu nehmen. Bei einer negativen Prognose sollte nie einfach davon ausgegangen werden, dass sich mit mehr Zeit und Aufwand alle Probleme des PoC in Luft auflösen werden.

Problem Nr. 4: Ressentiments und grundsätzliche Ablehnung von Data Science und KI Problem 4

Eine unsichtbare, aber nicht zu unterschätzende Hürde liegt in den Köpfen der Menschen. Dies gilt sowohl für die Belegschaft als auch für das Management. Oft werden vielversprechende Data Science und KI-Initiativen aufgrund von tief verwurzelten, aber undifferenzierten Vorbehalten ausgebremst. Das richtige Mindset ist entscheidend.

Obwohl DS und KI in aller Munde sind, fehlt es in vielen Unternehmen noch an echtem Management-Engagement. Häufig werden zwar Lippenbekenntnisse zu DS & KI abgegeben und erhebliche Mittel investiert, aber die Vorbehalte gegenüber KI bleiben bestehen.

Begründet wird dies oft mit den inhärenten Verzerrungen und Unsicherheiten von KI-Modellen und ihrer geringen direkten Interpretierbarkeit. Hinzu kommt manchmal eine generelle Abneigung, Erkenntnisse zu akzeptieren, die nicht mit der eigenen Intuition übereinstimmen. Die Tatsache, dass die menschliche Intuition oft viel stärkeren – und im Gegensatz zu KI-Modellen nicht quantifizierbaren – Verzerrungen unterliegt, wird in der Regel ignoriert.

Data Science & KI-Initiativen brauchen die Akzeptanz und Unterstützung der Belegschaft

Dies führt dazu, dass (Entscheidungs-)Prozesse und Organisationsstrukturen (z.B. Rollen, Verantwortlichkeiten) nicht so angepasst werden, dass DS & KI-Lösungen ihren (vollen) Nutzen entfalten können. Dies wäre aber notwendig, denn Data Science & KI ist nicht einfach eine weitere Softwarelösung, die sich nahtlos in bestehende Strukturen integrieren lässt.

DS & KI ist eine disruptive Technologie, die unweigerlich ganze Branchen und Organisationen umgestalten wird. Unternehmen, die sich diesem Wandel verweigern, werden auf lange Sicht wahrscheinlich genau an diesem Paradigmenwechsel scheitern. Die Ablehnung des Wandels beginnt bei scheinbaren Kleinigkeiten, wie der Umstellung des Projektmanagements von der Wasserfallmethode auf eine agile, iterative Entwicklung. Ungeachtet der allgemein positiven Aufnahme bestimmter Veränderungsmaßnahmen wird manchmal eine völlig irrationale Ablehnung der Reform bestehender (noch) funktionierender Prozesse festgestellt. Dabei wäre genau das notwendig, um – zugegebenermaßen erst nach einer Phase der Neujustierung – langfristig wettbewerbsfähig zu sein.

Während Vision, Strategie und Strukturen von oben nach unten verändert werden müssen, kann das operative Tagesgeschäft nur von unten nach oben, durch die Mitarbeitenden, revolutioniert werden. Das Engagement des Managements und das beste Werkzeug der Welt sind nutzlos, wenn die Endnutzer:innen nicht in der Lage oder willens sind, es anzunehmen. Die allgemeine Unsicherheit über die langfristige KI-Roadmap und die Angst, durch Maschinen ersetzt zu werden, schüren Ängste, die dazu führen, dass DS & KI-Lösungen nicht in den Arbeitsalltag integriert werden. Dies ist natürlich mehr als problematisch, da nur die (richtige) Anwendung von KI-Lösungen einen Mehrwert schafft.

Wie Sie diesem Problem entgegenwirken können:

  • Es überrascht nicht, dass ein solides Change Management der beste Ansatz ist, um die KI-feindliche Denkweise zu entschärfen. Dies sollte nicht nur ein nachträglicher Gedanke, sondern ein integraler Bestandteil jeder DS & KI-Initiative und es sollten Verantwortlichkeiten für diese Aufgabe zugewiesen werden. Eine frühzeitige, umfassende, detaillierte und klare Kommunikation ist unerlässlich. Welche Schritte werden voraussichtlich wann und wie genau umgesetzt? Denken Sie daran, dass es schwer ist, einmal verlorenes Vertrauen wiederzugewinnen. Daher sollten alle Unklarheiten in der Planung angesprochen werden. Entscheidend ist es, bei allen Beteiligten ein Grundverständnis für die Sache zu schaffen und die Notwendigkeit der Veränderung zu verdeutlichen (z.B. weil sonst die Wettbewerbsfähigkeit gefährdet ist, Erfolgsgeschichten oder Misserfolge der Konkurrenz). Darüber hinaus ist der Dialog mit den Betroffenen von großer Bedeutung. Feedback sollte frühzeitig eingeholt und nach Möglichkeit umgesetzt werden. Bedenken sollten immer gehört und respektiert werden, auch wenn sie nicht berücksichtigt werden können. Falsche Versprechungen sind jedoch strikt zu vermeiden; stattdessen sollte man versuchen, die Vorteile von DS & KI in den Vordergrund zu stellen.
  • Neben der Einsicht in die Notwendigkeit von Veränderungen ist auch die grundsätzliche Fähigkeit zur Veränderung wichtig. Die Angst vor dem Unbekannten oder Unverständlichen ist uns Menschen inhärent. Daher kann Bildung – nur auf dem für die jeweilige Rolle notwendigen Abstraktions- und Tiefenniveau – einen großen Unterschied machen. Entsprechende Schulungsmaßnahmen sind keine einmalige Angelegenheit; der Aufbau von aktuellem Wissen und die Ausbildung im Bereich Data Science & KI müssen langfristig sichergestellt werden. Die allgemeine Datenkompetenz der Belegschaft muss ebenso sichergestellt werden, wie die Auf- oder Umschulung von technischen Expert:innen. Die Mitarbeitenden müssen eine realistische Chance erhalten, neue und attraktivere Beschäftigungsmöglichkeiten zu erhalten, indem sie sich weiterbilden und sich mit DS & KI beschäftigen. Das wahrscheinlichste Ergebnis sollte niemals sein, dass sie durch DS & KI ihren alten Arbeitsplatz (teilweise) verlieren, sondern muss als Chance und nicht als Gefahr wahrgenommen werden; Data Science & KI müssen Perspektiven schaffen und dürfen sie nicht verderben.
  • Übernehmen oder adaptieren Sie die Best Practices von DS & KI-Führungskräften in Bezug auf die Definition von Rollen- und Kompetenzprofilen, die Anpassung von Organisationsstrukturen und Wertschöpfungsprozessen. Bewährte Ansätze können als Blaupause für die Reformierung Ihrer Organisation dienen und so sicherstellen, dass Sie auch in Zukunft wettbewerbsfähig bleiben.

Schlussbemerkungen

Wie Sie vielleicht bemerkt haben, bietet dieser Blogbeitrag keine einfachen Lösungen. Das liegt daran, dass die Probleme, um die es hier geht, komplex und mehrdimensional sind. Dieser Artikel hat high-level Ansätze zur Entschärfung der angesprochenen Probleme geliefert, aber es muss betont werden, dass diese Probleme einen ganzheitlichen Lösungsansatz erfordern. Dies erfordert eine klare KI-Vision und eine daraus abgeleitete solide KI-Strategie, nach der die Vielzahl der notwendigen Maßnahmen koordiniert und gesteuert werden kann.

Deshalb muss ich betonen, dass wir das Stadium, in dem experimentelle und unstrukturierte Data Science und KI-Initiativen erfolgreich sein können, längst verlassen haben. DS & KI darf nicht als technisches Thema behandelt werden, das ausschließlich in Fachabteilungen stattfindet. Es ist an der Zeit, KI als strategisches Thema anzugehen. Wie bei der digitalen Revolution werden nur Organisationen, in denen KI das Tagesgeschäft und die allgemeine Geschäftsstrategie vollständig durchdringt und reformiert, langfristig erfolgreich sein. Wie oben beschrieben, birgt dies zweifelsohne viele Fallstricke, stellt aber auch eine unglaubliche Chance dar.

Wenn Sie bereit sind, diese Veränderungen zu integrieren, aber nicht wissen, wo Sie anfangen sollen, helfen wir von STATWORX Ihnen gerne. Besuchen Sie unsere Website und erfahren Sie mehr über unser Angebot im Bereich AI Strategy!

Quellen

[1] https://www.forbes.com/sites/forbestechcouncil/2020/10/14/why-do-most-ai-projects-fail/?sh=2f77da018aa3 [2] https://blogs.gartner.com/andrew_white/2019/01/03/our-top-data-and-analytics-predicts-for-2019/

Lea Waniek

Lea Waniek

Management Summary

Im Kundenlebenszyklus gilt es, den Kunden zum richtigen Zeitpunkt mit dem richtigen Angebot zu kontaktieren. Dabei sollen aktive Kunden zu einem weiteren Einkauf motiviert oder inaktive Kunden reaktiviert werden. Der Retailer kann seinen Kunden hierzu vielfältige Angebot machen, bspw. durch individuelle Produktempfehlungen, kundenspezifische Rabattaktionen oder ereignisbasierte Marketingaktionen. Häufig ist das Ziel dabei, möglichst die Kunden auszuwählen, mit denen Umsatz bei möglichst geringen Kosten generiert werden kann.

Zur Lösung dieser Herausforderung haben wir bei STATWORX hierzu für einen Kunden aus dem Einzelhandel einen ganzheitlichen Ansatz entwickelt. Auf Basis von Kundenstamm- und Transaktionsdaten haben wir verschiedene state-of-the-art Methoden des Machine Learnings und der künstlichen Intelligenz genutzt, um Kundengruppen individuell und automatisiert auf verschiedenen Kanälen ansprechen zu können. Unser Kunde hatte zwei zentrale Herausforderungen im Direktmarketing identifiziert, die durch die bisher verwendeten Methoden nicht zufriedenstellend gelöst werden konnten:

  1. Customer Churn & Retention: Wann und wie sollten inaktive Kunden gezielt angesprochen werden, um eine Abwanderung möglichst effizient zu verhindern? (Outbound Marketing)
  2. Next Basket Prediction: Welche Produkte sollten aktiven Kunden empfohlen werden, die sie zu einem Folgekauf anregen können? (Inbound Marketing)

Für die Kundenreaktivierung wird zunächst die Kaufwahrscheinlichkeit aller Kunden für einen definierten Zeitraum in der Zukunft ermittelt. Diese Prognose dient dazu, Kunden, die eine sehr hohe Wahrscheinlichkeit für einen Kauf haben, für das weitere Prozedere auszuschließen. Denn diese Kunden müssen ohnehin nicht im Rahmen einer Kampagne reaktiviert werden. Genauso können Kunden ausgeschlossen werden, die eine sehr niedrige Kaufwahrscheinlichkeit aufweisen, da eine Reaktivierung dieser Kunden grundsätzlich wenig erfolgversprechend ist.

Im Anschluss an diesen ersten Schritt wird ein zweites Machine Learning Modell angewendet, das für jeden Kunden individuell aus einer im Vorhinein definierten Auswahl an Rabattgutscheinen den jeweils optimalen Gutschein selektiert.

Die Newsletter, inklusive der entsprechenden Rabattgutscheine, werden automatisiert an die Kunden versendet. Daraufhin wird die Aktivität der Kunden im Aktionszeitraum beobachtet und als Trainingsmenge in das zweite Modell eingespeist sowie die Kampagne anhand der Aktivierungs- und Reaktionsquoten evaluiert.

Zur Empfehlung weiterer Produkte an aktive Kunden wird ein state-of-the-art Modell aus der aktuellen Forschung genutzt. Das Modell nutzt rekurrente neuronale Netze (RNN), um die gesamte Kaufhistorie des Kunden berücksichtigen zu können. Es erlernt nicht nur die dynamische Repräsentation der Kunden, sondern erfasst auch globale sequentielle Merkmale über alle Warenkörbe hinweg. Basierend auf diesem Modell können Newsletter mit kundenindividuellen Produktempfehlungen versendet werden.

Mithilfe dieser beiden Ansätze können die Retail-Kunden in allen Phasen des Kundenlebenszyklus‘ optimal angesprochen, der manuelle Aufwand bei der Kundenauswahl und Versendung des Contents signifikant reduziert und der zur Aktion zugeordnete Umsatz gesteigert werden.

Motivation

Für jedes Retail-Unternehmen ist es ein wichtiges Ziel, Kosten zu reduzieren und Umsätze zu erhöhen, um schlussendlich den Gewinn zu maximieren. Dies fängt beim Einkauf an, geht weiter über eine margenoptimierte Preissetzung und endet mit einer gezielten Kundenansprache.

Im Kundenlebenszyklus gilt es, den Kunden zum richtigen Zeitpunkt mit dem richtigen Angebot zu kontaktieren. Dabei sollen aktive Kunden zu einem weiteren Einkauf motiviert oder inaktive Kunden reaktiviert bzw. deren Abwanderung zu einem Konkurrenten verhindert werden. Der Retailer kann seinen Kunden hierzu vielfältige Angebot machen, bspw. durch individuelle Produktempfehlungen, kundenspezifische Rabattaktionen oder ereignisbasierte Newsletter.

Ziel ist dabei, möglichst solche Kunden auszuwählen, mit denen Umsatz bei möglichst geringen Kosten generiert werden kann. Zu den Kosten zählen dabei nicht nur reine Werbekosten, sondern auch indirekte Kosten, die z.B. dann entstehen, wenn der Retailer aktive Kunden mit einem Rabattgutschein anspricht. Dies führt zu keiner Umsatzsteigerung, da diese Kunden auch ohne Rabattgutschein eingekauft hätten. Weiterhin entstehen bei dem Retailer Kosten, wenn Personen für Werbeaktionen selektiert werden, deren tatsächliche Kaufwahrscheinlichkeit gegen Null tendiert.

„I know that half of marketing is wasted – my problem is that I just don’t know which half.”

John Wanamaker

Zur Lösung dieser Herausforderung benötigt der Retailer somit einen Ansatz, um die richtigen Kunden zum richtigen Zeitpunkt mit dem richtigen Content anzusprechen. STATWORX hat hierzu für einen Kunden aus dem Einzelhandel einen ganzheitlichen Ansatz entwickelt. Auf Basis von Kundenstamm- und Transaktionsdaten haben wir verschiedene state-of-the-art Methoden des Machine Learnings und der künstlichen Intelligenz nutzt, um Kundengruppen individuell und automatisiert auf verschiedenen Kanälen ansprechen zu können. Dadurch konnte das Unternehmen seinen manuellen Aufwand bei der Kundenauswahl und Versendung des Contents signifikant reduzieren und gleichzeitig den der Aktion zugeordneten Umsatz steigern.

Challenge

Aufgrund bisheriger Erfahrungen im Direktmarketing hatte unser Kunde zwei zentrale Herausforderungen identifiziert, die durch die bisherigen verwendeten Methoden nicht zufriedenstellend gelöst werden konnten:

  1. Customer Churn & Retention: Wann und wie sollten inaktive Kunden gezielt angesprochen werden, um eine Abwanderung möglichst effizient zu verhindern? Genauer gesagt, welche Kunden müssen zu einem gegebenen Zeitpunkt kontaktiert und welche Anreize sollte man ihnen für den nächsten Einkauf bieten? (Outbound Marketing)
  2. Next Basket Prediction: Welche Produkte sollten aktiven Kunden empfohlen werden, die sie zu einem Folgekauf anregen können? (Inbound Marketing)

Um diese Fragestellungen modellgetrieben beantworten zu können, bedarf es einer umfangreichen Datenbasis. Für diese müssen alle relevanten Informationen aus den vorliegenden Datenquellen extrahiert, miteinander verknüpft und in geeigneter Form aggregiert werden. So soll eine umfassende zentrale Datenbank auf Kundenebene entstehen, die für die oben genannten Fragestellungen sowie auch weitere Problemstellungen verwendet werden kann. Zu dieser Datenbasis gehören in diesem Fall die Artikel- und Kundenstammdaten, historischen Transaktionsdaten, Kundenaktionsdaten, Standortdaten sowie Informationen aus externen Datenquellen.

Für unseren Kunden war es außerdem von besonderer Relevanz, die sich aus den Fragestellungen ergebenden Schritte möglichst automatisiert ablaufen zu lassen und dementsprechend in die eigene IT-Infrastruktur zu integrieren. Somit müssen alle Schritte von der Datenextraktion & -aufbereitung hin zum Versand der individuellen Newsletter regelmäßig automatisiert ablaufen, bzw. ereignisbasiert angestoßen werden.

Zusätzlich sollte auch die Wartbarkeit und eine manuelle Nutzung der Data Pipeline und der Modelle durch die interne Data Science Abteilung gewährleistet sein. Insbesondere das auf Kundenebene zu aggregierende Data Warehouse soll der Abteilung, über die beiden Problemstellungen hinaus, als Datengrundlage für Ad-hoc-Analysen oder für weitere eigene Modelle und Analysen dienen.

Solution

Die eingangs beschriebenen Fragestellungen unterscheiden sich vor allem in der Art ihrer Komplexität. Bei der Kundenreaktivierung liegt die Herausforderung vor allem in der Entwicklung der Data Pipeline und der Datenaufbereitung. Beim Produkt-Recommender stellt hingegen die Entwicklung der Methodik die größte Herausforderung dar.

Im Bereich der Kundenreaktivierung wird der auf Kundenebene aggregierte Datensatz zunächst dazu verwendet, die Kaufwahrscheinlichkeit aller Kunden für einen definierten Zeitraum in der Zukunft zu ermitteln. Diese Prognose dient dazu, Kunden, die eine sehr hohe Wahrscheinlichkeit für einen Kauf haben, für das weitere Prozedere auszuschließen. Der Grund hierfür ist, dass diese Kunden ohnehin nicht im Rahmen einer Kampagne reaktiviert werden müssen. Genauso können Kunden ausgeschlossen werden, die eine sehr niedrige Kaufwahrscheinlichkeit aufweisen, da eine Reaktivierung dieser Kunden grundsätzlich wenig erfolgsversprechend ist.

Im Anschluss an diesen ersten Schritt wird ein zweites Machine Learning Modell angewendet, das für jeden Kunden individuell aus einer im Vorhinein definierten Auswahl an Rabattgutscheinen den jeweils optimalen Gutschein selektiert. Ferner kann die Menge der zu reaktivierenden Kunden anhand verschiedener Kennzahlen eingeschränkt werden. Die zu reaktivierenden Kunden werden nach Vertriebslinie und Versandart unterteilt und die Mailings bzw. Newsletter inklusive der entsprechenden Rabattgutscheine automatisiert an die Kunden versendet. Daraufhin wird die Aktivität der Kunden im Aktionszeitraum beobachtet und als Trainingsmenge in das zweite Modell eingespeist. Außerdem wird die Kampagne anhand der Aktivierungs- und Reaktionsquoten evaluiert.

Zur Empfehlung weiterer Produkte an aktive Kunden wird ein state-of-the-art Modell aus der aktuellen Forschung genutzt. Das DREAM Modell [2] nutzt rekurrente neuronale Netze (RNN), um die gesamte Kaufhistorie des Kunden berücksichtigen zu können. DREAM erlernt nicht nur die dynamische Repräsentation der Kunden, sondern erfasst auch globale sequentielle Merkmale über alle Warenkörbe hinweg. Diese Darstellung kann die Interessen der Kunden dynamisch, zu verschiedenen Zeitpunkten repräsentieren und mit den globalen sequentiellen Merkmalen aller Warenkörbe des Benutzers im Laufe der Zeit in Verbindung setzen. Hierdurch kann ein deutlich realistischeres Modell zur Produktempfehlung angewendet werden, was sich auch in signifikant besseren Trefferquoten zwischen den vorhergesagten und tatsächlichen Warenkörben widerspiegelt.

Data Warehouse als Basis

Das Data Warehouse bildet die Datenbasis für alle verwendeten Modelle. Es enthält alle Datenpunkte, mit denen die Kaufwahrscheinlichkeiten prognostiziert, Produktempfehlungen erzeugt und verschiedenste Analysen und Visualisierungen erstellt werden können. Im Rahmen der Integration der verschiedenen Datenquellen werden zunächst alle gesperrten und gelöschten Kunden sowie Personen, die der Direktwerbung nicht zugestimmt haben, aus dem Kundenstamm entfernt.

Der Kundenstamm wird durch Kundenkartendaten, die Kundenadressen und die geographischen Informationen der Postleitzahlen angereichert. Darüber hinaus werden Postrückläufer ohne E-Mail-Adresse und/oder ohne E-Mail Opt-in aus dem Datensatz entfernt.

Abschließend werden die Filialinformationen der Stammfiliale der Kunden angefügt. Die Filialinformationen bestehen aus geographischen Informationen, Daten zu den Filialflächen und externen Konsumdaten. Ergänzt werden diese Daten durch die in diesem Projekt berechneten Distanzen zum nächstgelegenen Konkurrenten. Neben den Stammdaten der Kunden werden die Transaktionsdaten zusammengefasst. Jeder verkaufte Artikel wird durch weitere Informationen aus dem Artikelstamm ergänzt und auf Bon-Ebene aggregiert.

Diesem Datensatz können nun die ebenfalls auf Bon-Ebene vorliegenden Informationen aus dem Kundenbonusprogramm hinzugefügt werden. Der Datensatz wird daraufhin auf Kundenebene aggregiert. Von besonderer Bedeutung ist dabei, dass bei den beiden Aggregationsschritten die Kaufhistorie bis auf Artikelebene für die Produktempfehlung erhalten bleibt. Dazu wird eine Spalte erstellt, in der in einer verschachtelten Liste alle Warenkörbe und die darin enthaltenen Artikel eines jeden Kunden aufgelistet sind.

Ergänzend wird die Kauffrequenz pro Kunde berechnet, repräsentiert als die durchschnittliche Anzahl an Tagen zwischen den einzelnen Einkäufen.

Customer Churn & Retention Modell

Basierend auf dem historischen Kaufverhalten wird ein XGBoost-Modell [1] trainiert, um die Wahrscheinlichkeit der Kunden mindestens einen Kauf in den nächsten 3 Monaten zu tätigen, vorhersagen zu können. Das trainierte Modell wird auf alle im Data Warehouse enthaltenen Kunden angewendet. Anschließend können bspw. die Top 5% der Kunden mit den höchsten Kaufwahrscheinlichkeiten aus dem Datensatz ausgeschlossen werden. So wird vermieden, dass ohnehin aktive Kunden, die keine Reaktivierung benötigen, angeschrieben werden und einen Rabattgutschein erhalten. Ebenso werden auch alle Kunden mit einer sehr niedrigen Kaufwahrscheinlichkeit herausgefiltert. Darüber hinaus werden alle Kunden ausgeschlossen, die schon in der vorherigen Mailing Aktion kontaktiert wurden.

Abbildung 1: Prozessdarstellung des Customer Churn & Retention Programmes

Basierend auf der Aktivierung der Kunden, die im Aktionszeitraum der vergangenen Kampagnen kontaktierten wurden, wird ein weiteres XGBoost-Modell trainiert. Dieses Modell sagt die Wahrscheinlichkeit mindestens einen Kauf zu tätigen für verschiedene Rabattgutscheine voraus, für jeden von Modell 1 nicht ausgeschlossenem Kunden, bzw. für eine zufällige Auswahl der nicht ausgeschlossenen Kunden. Die folgende Auswahl der anzuschreibenden Kunden sowie der optimalen Rabatthöhe erfolgt auf Basis des gewünschten Mailing Volumens und des Erwartungswertes des Warenkorbes je Rabattgutschein und Kunde.

Die durch das Modell 1 priorisierte Auswahl an Kunden kann durch die Vorgabe einer Mindestkaufwahrscheinlichkeit und/oder eines Mindesterwartungswertes des Warenkorbes weiter eingeschränkt werden.

Bei der Auswahl der optimalen Rabattkombination, basierend auf dem Erwartungswert, wird gleichzeitig auf die Kaufwahrscheinlichkeit und auf die zu erwartenden Kosten des Gutscheins optimiert. Hierfür wird das durchschnittliche Volumen der historischen Warenkörbe für jeden Kunden individuell berechnet und die vorhergesagte Kaufwahrscheinlichkeit des Kunden und der Rabattkombination dem Modell 2 entnommen. Für Kunden mit weniger als vier Einkäufen im Beobachtungszeitraum wird der durchschnittliche Warenkorb aller betrachteten Kunden eingesetzt.

Next Basket Prediction Modell

Das Modell zur Generierung von Produktempfehlungen nutzt eine ähnliche Data Pipeline wie das Customer Churn & Retention Modell. Zunächst wird die im Data Warehouse vorhandene Kaufhistorie dazu genutzt, das Modell zu trainieren. Anschließend kann das Modell zu jedem beliebigen Zeitpunkt für alle Kunden individuelle Kaufempfehlungen bzw. Vorhersagen über den nächsten Warenkorb ausgeben. Hierbei kann definiert werden wie viele Produkte als Empfehlung ausgegeben werden sollen. Diese Empfehlungen sind nach der Kaufwahrscheinlichkeit absteigend sortiert, sodass auch im Nachhinein noch eine weitere Selektion möglich ist.

Anschließend können nach verschiedenen Regeln diejenigen Kunden ausgewählt werden, die einen Newsletter mit ihrer persönlichen Kaufempfehlung erhalten sollen. Welche Kunden das sind wird mit der Marketingabteilung individuell abgestimmt und laufend angepasst. Auch der Einbezug des ersten Modells zur Berechnung der Kaufwahrscheinlichkeiten aus dem Customer Churn & Retention Modell ist hierbei eine Option.

Abbildung 2: Prozessdarstellung des Empfehlungssystems

Automatisierter Versand

Nachdem die anzuschreibenden Kunden durch das Modell identifiziert wurden, können diese mit dem individuellen Rabattgutschein bzw. der Produktempfehlungen über eine API-Schnittstelle an den Dienstleister übergeben werden, der den E-Mail- und Post-Versand übernimmt.

Im Rahmen des Customer Churn & Retention Modells wird zusätzlich noch einer zufällig ausgewählten Anzahl an Kunden ein ebenso zufälliger Rabattgutschein zugesendet, um einen Vergleich zu dem trainierten Modell zu haben. Beim Produktempfehlungsmodell besteht diese Möglichkeit ebenfalls.

Sobald der Versand abgeschlossen ist, stellt der Dienstleister über die API-Schnittstelle eine Datei zur Verfügung, aus der der Versanderfolg ersichtlich wird. Dadurch kann bei der Evaluation sichergestellt werden, dass auch nur solche Kunden betrachtet werden, die tatsächlich einen Rabattgutschein bzw. eine Kaufempfehlung bekommen haben.

Evaluation

Um den Erfolg des Kundenreaktivierungsprogramms überprüfen zu können und neue Trainingsdaten für Modell 2 zu erhalten, werden die auf Kundenebene aggregierten Daten aus dem Data Warehouse auf die in der letzten Aktion kontaktierten Kunden selektiert. Anschließend wird überprüft, ob die Kunden aktiv waren oder sogar den Rabattgutschein genutzt haben.

Da die Aktivität des Kunden im Beobachtungszeitraum die Zielgröße beider Modelle ist, kann zur Evaluation eine zusätzliche Kontrollgruppe genutzt werden. Für diese wird die Aktivität im Beobachtungszeitraum ebenfalls beobachtet. Somit kann festgestellt werden, ob durch die kundenindividuellen Rabattgutscheine generell die Aktivität der Kunden erhöht werden kann. Genauso können bei der Evaluation auch die durch das Modell ausgewählten Kunden und Rabattgutscheine mit den zufällig ausgewählten Kunden und Rabattgutscheinen verglichen werden, um die Wirksamkeit der Kunden- und Rabattauswahl zu überprüfen.

Für das Empfehlungsmodell muss der Erfolg auf eine andere Weise gemessen werden. Es reicht nicht mehr aus, dass ein Kunde überhaupt einen Kauf im Beobachtungszeitraum tätigt. Vielmehr liegt der Fokus darauf, zu messen, ob der Kunde mindestens ein Produkt der ihm zuvor durch das Modell empfohlenen Produkte bei seinem nächsten Einkauf im Warenkorb liegen hat.

Um dies zu bestimmen, haben wir die sogenannte Hit Rate definiert. Ein Hit liegt vor, wenn der Kunde mindestens ein Produkt aus dem empfohlenen Warenkorb kauft. Die Hit Rate beschreibt demzufolge den Anteil erfolgreicher Empfehlungen (Hits) an der Gesamtzahl der Empfehlungen.

Um auch hier die modellbasierten Hits in das Verhältnis zu zufälligen Hits setzen zu können, wird ebenfalls eine Kontrollgruppe betrachtet. Für diese wurden zwar auch Kaufempfehlungen berechnet, allerdings kein Newsletter dazu versendet. So kann die Hit Rate des Modells mit der Hit Rate in der Kontrollgruppe verglichen und der Erfolg des Modells gemessen werden.

Impact

Mit unserem modellgetriebenen und automatisierten Ansatz konnten im Unternehmen sowohl Prozesse als auch Ergebnisse im Direktmarketing verbessert werden.

Angefangen mit der Integration einer Vielzahl an Datenquellen zu einem Data Warehouse auf Kundenbasis, steht dem Unternehmen nun eine täglich aktualisierte Datenbasis zur Verfügung, die nicht nur für die Customer Churn & Retention und Next Basket Prediction Modelle genutzt wird. Auch für weitere Modelle, Ad-hoc-Analysen und Business Intelligence Anwendungen wird dieses Data Warehouse im Unternehmen eingesetzt.

Durch unseren Ansatz konnte der manuelle Aufwand bei der Ansprache von Kunden auf vielen Ebenen reduziert und oftmals sogar komplett automatisiert werden. Beispiele hierfür sind die automatisierte Identifikation und Auswahl der geeigneten Kunden für eine Rabattaktion oder einen Newsletter mit Produktempfehlungen, die automatisierte Überprüfung der Kunden bezüglich konsistenter Kontaktdaten, Sperrvermerken oder Löschungen, und die automatisierte Versandabwicklung mit einem externen Dienstleister. All diese nun automatisierten Schritte mussten zuvor durch Mitarbeitende manuell und mit erhöhtem Zeitaufwand erledigt werden.

Darüber hinaus gibt es auch Aufgaben, die manuell überhaupt nicht durchführbar sind. Ein Beispiel hierfür ist die individuell auf den Kunden abgestimmte Auswahl von Produktempfehlungen. Hier können nun Newsletter mit einer standardisierten Produktauswahl für alle Kunden durch Newsletter mit einer individuellen Produktauswahl ersetzt werden.

Nicht nur der Aufwand im Direktmarketing konnte reduziert werden, sondern auch die Ergebnisse der verschiedenen Maßnahmen haben sich verbessert. Durch die gezielte Ansprache inaktiver oder selten aktiver Kunden, konnten solche Kunden zurückgewonnen werden, die den Retailer aus den Augen verloren hatten, zur Konkurrenz gewechselt waren oder einen Anreiz benötigten, um wieder beim Retailer einzukaufen. Mithilfe unserer modellgetriebenen Identifikation der zur Ansprache geeigneten Kunden und der Auswahl individuell passender Rabattgutscheine konnten Streuverluste minimiert werden. Einerseits wurden Versandkosten für Kunden eingespart, die auf die Rabattgutscheine gar nicht reagieren und von unserem Modell aussortiert werden. Andererseits wurden auch Kosten für Rabattgutscheine eingespart, die von regelmäßig einkaufenden Kunden eingelöst werden, die auch ohne einen Rabattgutschein Einkäufe getätigt hätten und nun ebenfalls nicht mehr in die Rabattaktionen miteinbezogen werden.

Ferner konnten mit der Bestimmung des gewinnoptimalen Rabattgutscheins individuell je Kunde die Kosten und Gewinne aus den Rabattaktionen selbst weiter optimiert werden.

Nachdem es uns gelungen war mithilfe des Customer Churn & Retention Ansatzes kostenoptimal Kunden zurückzugewinnen, galt es nun diese Kunden auch zu weiteren Käufen anzuregen. Hierbei konnte die Next Basket Prediction dem Unternehmen helfen, automatisiert und individuell die zurückgewonnenen Kunden, aber auch regelmäßig aktive Kunden, interessante Produkte zu präsentieren und so die Kunden weiter regelmäßig zum Besuch des Retailers zu motivieren, zu weiteren Ankäufen anregen und eine tiefergehende Bindung zum Kunden aufzubauen.

Fazit & Ausblick

Mit den beiden modellgetriebenen Ansätzen konnten wir dem Einzelhändler dabei helfen, seine Kundenansprache in den verschiedenen Phasen des Kundenlebenszyklus zu optimieren und automatisieren, bei einer gleichzeitigen Kostensenkung und Umsatzsteigerung.

Durch unseren ganzheitlichen Ansatz steht dem Einzelhändler ein Data Warehouse zur Verfügung, das er einerseits für weitergehende Analysen oder Business Intelligence Anwendungen nutzen kann, mit dem er andererseits aber auch weitere Aufgaben im Marketingbereich durch modellgetriebene Ansätze optimieren und automatisieren kann.

Mit der fortschreitenden Digitalisierung haben die Kunden mittlerweile den Anspruch an die Unternehmen, mit individuellem Content angesprochen zu werden. Dieser Trend wird sich auch in Zukunft fortsetzen, sodass es gilt die im Unternehmen vorhandenen Datenquellen zu nutzen, um diesen Wunsch des Kunden zu erfüllen und ihn seinen Bedürfnissen entsprechend zu kontaktieren.


Quellen

[1] Chen, Tianqi / Guestrin, Carlos (2016) „Xgboost: A scalable tree boosting system“, In: Proceedings of the 22nd ACM SIGKDD international conference on knowledge discovery and data mining, S. 785-794

[2] Yu, Feng, et al. (2016) „A dynamic recurrent model for next basket recommendation“, In: Proceedings of the 39th International ACM SIGIR conference on Research and Development in Information Retrieval, S. 729-732

 

Niklas Junker Niklas Junker Niklas Junker

Did you ever want to make your machine learning model available to other people, but didn’t know how? Or maybe you just heard about the term API, and want to know what’s behind it? Then this post is for you!

Here at STATWORX, we use and write APIs daily. For this article, I wrote down how you can build your own API for a machine learning model that you create and the meaning of some of the most important concepts like REST. After reading this short article, you will know how to make requests to your API within a Python program. So have fun reading and learning!

What is an API?

API is short for Application Programming Interface. It allows users to interact with the underlying functionality of some written code by accessing the interface. There is a multitude of APIs, and chances are good that you already heard about the type of API, we are going to talk about in this blog post: The web API.

This specific type of API allows users to interact with functionality over the internet. In this example, we are building an API that will provide predictions through our trained machine learning model. In a real-world setting, this kind of API could be embedded in some type of application, where a user enters new data and receives a prediction in return. APIs are very flexible and easy to maintain, making them a handy tool in the daily work of a Data Scientist or Data Engineer.

An example of a publicly available machine learning API is Time Door. It provides Time Series tools that you can integrate into your applications. APIs can also be used to make data available, not only machine learning models.

API Illustration

And what is REST?

Representational State Transfer (or REST) is an approach that entails a specific style of communication through web services. When using some of the REST best practices to implement an API, we call that API a „REST API“. There are other approaches to web communication, too (such as the Simple Object Access Protocol: SOAP), but REST generally runs on less bandwidth, making it preferable to serve your machine learning models.

In a REST API, the four most important types of requests are:

  • GET
  • PUT
  • POST
  • DELETE

For our little machine learning application, we will mostly focus on the POST method, since it is very versatile, and lots of clients can’t send GET methods.

It’s important to mention that APIs are stateless. This means that they don’t save the inputs you give during an API call, so they don’t preserve the state. That’s significant because it allows multiple users and applications to use the API at the same time, without one user request interfering with another.

The Model

For this How-To-article, I decided to serve a machine learning model trained on the famous iris dataset. If you don’t know the dataset, you can check it out here. When making predictions, we will have four input parameters: sepal length, sepal width, petal length, and finally, petal width. Those will help to decide which type of iris flower the input is.

For this example I used the scikit-learn implementation of a simple KNN (K-nearest neighbor) algorithm to predict the type of iris:

# model.py
from sklearn import datasets
from sklearn.model_selection import train_test_split
from sklearn.neighbors import KNeighborsClassifier
from sklearn.metrics import accuracy_score
from sklearn.externals import joblib
import numpy as np


def train(X,y):

    # train test split
    X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3)

    knn = KNeighborsClassifier(n_neighbors=1)

    # fit the model
    knn.fit(X_train, y_train)
    preds = knn.predict(X_test)
    acc = accuracy_score(y_test, preds)
    print(f'Successfully trained model with an accuracy of {acc:.2f}')

    return knn

if __name__ == '__main__':

    iris_data = datasets.load_iris()
    X = iris_data['data']
    y = iris_data['target']

    labels = {0 : 'iris-setosa',
              1 : 'iris-versicolor',
              2 : 'iris-virginica'}

    # rename integer labels to actual flower names
    y = np.vectorize(labels.__getitem__)(y)

    mdl = train(X,y)

    # serialize model
    joblib.dump(mdl, 'iris.mdl')

As you can see, I trained the model with 70% of the data and then validated with 30% out of sample test data. After the model training has taken place, I serialize the model with the joblib library. Joblib is basically an alternative to pickle, which preserves the persistence of scikit estimators, which include a large number of numpy arrays (such as the KNN model, which contains all the training data). After the file is saved as a joblib file (the file ending thereby is not important by the way, so don’t be confused that some people call it .model or .joblib), it can be loaded again later in our application.

The API with Python and Flask

To build an API from our trained model, we will be using the popular web development package Flask and Flask-RESTful. Further, we import joblib to load our model and numpy to handle the input and output data.

In a new script, namely app.py, we can now set up an instance of a Flask app and an API and load the trained model (this requires saving the model in the same directory as the script):

from flask import Flask
from flask_restful import Api, Resource, reqparse
from sklearn.externals import joblib
import numpy as np

APP = Flask(__name__)
API = Api(APP)

IRIS_MODEL = joblib.load('iris.mdl')

The second step now is to create a class, which is responsible for our prediction. This class will be a child class of the Flask-RESTful class Resource. This lets our class inherit the respective class methods and allows Flask to do the work behind your API without needing to implement everything.

In this class, we can also define the methods (REST requests) that we talked about before. So now we implement a Predict class with a .post() method we talked about earlier.

The post method allows the user to send a body along with the default API parameters. Usually, we want the body to be in JSON format. Since this body is not delivered directly in the URL, but as a text, we have to parse this text and fetch the arguments. The flask _restful package offers the RequestParser class for that. We simply add all the arguments we expect to find in the JSON input with the .add_argument() method and parse them into a dictionary. We then convert it into an array and return the prediction of our model as JSON.

class Predict(Resource):

    @staticmethod
    def post():
        parser = reqparse.RequestParser()
        parser.add_argument('petal_length')
        parser.add_argument('petal_width')
        parser.add_argument('sepal_length')
        parser.add_argument('sepal_width')

        args = parser.parse_args()  # creates dict

        X_new = np.fromiter(args.values(), dtype=float)  # convert input to array

        out = {'Prediction': IRIS_MODEL.predict([X_new])[0]}

        return out, 200

You might be wondering what the 200 is that we are returning at the end: For APIs, some HTTP status codes are displayed when sending requests. You all might be familiar with the famous 404 - page not found code. 200 just means that the request has been received successfully. You basically let the user know that everything went according to plan.

In the end, you just have to add the Predict class as a resource to the API, and write the main function:

API.add_resource(Predict, '/predict')

if __name__ == '__main__':
    APP.run(debug=True, port='1080')

The '/predict' you see in the .add_resource() call, is the so-called API endpoint. Through this endpoint, users of your API will be able to access and send (in this case) POST requests. If you don’t define a port, port 5000 will be the default.

You can see the whole code for the app again here:

# app.py
from flask import Flask
from flask_restful import Api, Resource, reqparse
from sklearn.externals import joblib
import numpy as np

APP = Flask(__name__)
API = Api(APP)

IRIS_MODEL = joblib.load('iris.mdl')


class Predict(Resource):

    @staticmethod
    def post():
        parser = reqparse.RequestParser()
        parser.add_argument('petal_length')
        parser.add_argument('petal_width')
        parser.add_argument('sepal_length')
        parser.add_argument('sepal_width')

        args = parser.parse_args()  # creates dict

        X_new = np.fromiter(args.values(), dtype=float)  # convert input to array

        out = {'Prediction': IRIS_MODEL.predict([X_new])[0]}

        return out, 200


API.add_resource(Predict, '/predict')

if __name__ == '__main__':
    APP.run(debug=True, port='1080')

Run the API

Now it’s time to run and test our API!

To run the app, simply open a terminal in the same directory as your app.py script and run this command.

python run app.py

You should now get a notification, that the API runs on your localhost in the port you defined. There are several ways of accessing the API once it is deployed. For debugging and testing purposes, I usually use tools like Postman. We can also access the API from within a Python application, just like another user might want to do to use your model in their code.

We use the requests module, by first defining the URL to access and the body to send along with our HTTP request:

import requests

url = 'http://127.0.0.1:1080/predict'  # localhost and the defined port + endpoint
body = {
    "petal_length": 2,
    "sepal_length": 2,
    "petal_width": 0.5,
    "sepal_width": 3
}
response = requests.post(url, data=body)
response.json()

The output should look something like this:

Out[1]: {'Prediction': 'iris-versicolor'}

That’s how easy it is to include an API call in your Python code! Please note that this API is just running on your localhost. You would have to deploy the API to a live server (e.g., on AWS) for others to access it.

Conclusion

In this blog article, you got a brief overview of how to build a REST API to serve your machine learning model with a web interface. Further, you now understand how to integrate simple API requests into your Python code. For the next step, maybe try securing your APIs? If you are interested in learning how to build an API with R, you should check out this post. I hope that this gave you a solid introduction to the concept and that you will be building your own APIs immediately. Happy coding!

 

Jannik Klauke

Jannik Klauke

Did you ever want to make your machine learning model available to other people, but didn’t know how? Or maybe you just heard about the term API, and want to know what’s behind it? Then this post is for you!

Here at STATWORX, we use and write APIs daily. For this article, I wrote down how you can build your own API for a machine learning model that you create and the meaning of some of the most important concepts like REST. After reading this short article, you will know how to make requests to your API within a Python program. So have fun reading and learning!

What is an API?

API is short for Application Programming Interface. It allows users to interact with the underlying functionality of some written code by accessing the interface. There is a multitude of APIs, and chances are good that you already heard about the type of API, we are going to talk about in this blog post: The web API.

This specific type of API allows users to interact with functionality over the internet. In this example, we are building an API that will provide predictions through our trained machine learning model. In a real-world setting, this kind of API could be embedded in some type of application, where a user enters new data and receives a prediction in return. APIs are very flexible and easy to maintain, making them a handy tool in the daily work of a Data Scientist or Data Engineer.

An example of a publicly available machine learning API is Time Door. It provides Time Series tools that you can integrate into your applications. APIs can also be used to make data available, not only machine learning models.

API Illustration

And what is REST?

Representational State Transfer (or REST) is an approach that entails a specific style of communication through web services. When using some of the REST best practices to implement an API, we call that API a „REST API“. There are other approaches to web communication, too (such as the Simple Object Access Protocol: SOAP), but REST generally runs on less bandwidth, making it preferable to serve your machine learning models.

In a REST API, the four most important types of requests are:

For our little machine learning application, we will mostly focus on the POST method, since it is very versatile, and lots of clients can’t send GET methods.

It’s important to mention that APIs are stateless. This means that they don’t save the inputs you give during an API call, so they don’t preserve the state. That’s significant because it allows multiple users and applications to use the API at the same time, without one user request interfering with another.

The Model

For this How-To-article, I decided to serve a machine learning model trained on the famous iris dataset. If you don’t know the dataset, you can check it out here. When making predictions, we will have four input parameters: sepal length, sepal width, petal length, and finally, petal width. Those will help to decide which type of iris flower the input is.

For this example I used the scikit-learn implementation of a simple KNN (K-nearest neighbor) algorithm to predict the type of iris:

# model.py
from sklearn import datasets
from sklearn.model_selection import train_test_split
from sklearn.neighbors import KNeighborsClassifier
from sklearn.metrics import accuracy_score
from sklearn.externals import joblib
import numpy as np


def train(X,y):

    # train test split
    X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3)

    knn = KNeighborsClassifier(n_neighbors=1)

    # fit the model
    knn.fit(X_train, y_train)
    preds = knn.predict(X_test)
    acc = accuracy_score(y_test, preds)
    print(f'Successfully trained model with an accuracy of {acc:.2f}')

    return knn

if __name__ == '__main__':

    iris_data = datasets.load_iris()
    X = iris_data['data']
    y = iris_data['target']

    labels = {0 : 'iris-setosa',
              1 : 'iris-versicolor',
              2 : 'iris-virginica'}

    # rename integer labels to actual flower names
    y = np.vectorize(labels.__getitem__)(y)

    mdl = train(X,y)

    # serialize model
    joblib.dump(mdl, 'iris.mdl')

As you can see, I trained the model with 70% of the data and then validated with 30% out of sample test data. After the model training has taken place, I serialize the model with the joblib library. Joblib is basically an alternative to pickle, which preserves the persistence of scikit estimators, which include a large number of numpy arrays (such as the KNN model, which contains all the training data). After the file is saved as a joblib file (the file ending thereby is not important by the way, so don’t be confused that some people call it .model or .joblib), it can be loaded again later in our application.

The API with Python and Flask

To build an API from our trained model, we will be using the popular web development package Flask and Flask-RESTful. Further, we import joblib to load our model and numpy to handle the input and output data.

In a new script, namely app.py, we can now set up an instance of a Flask app and an API and load the trained model (this requires saving the model in the same directory as the script):

from flask import Flask
from flask_restful import Api, Resource, reqparse
from sklearn.externals import joblib
import numpy as np

APP = Flask(__name__)
API = Api(APP)

IRIS_MODEL = joblib.load('iris.mdl')

The second step now is to create a class, which is responsible for our prediction. This class will be a child class of the Flask-RESTful class Resource. This lets our class inherit the respective class methods and allows Flask to do the work behind your API without needing to implement everything.

In this class, we can also define the methods (REST requests) that we talked about before. So now we implement a Predict class with a .post() method we talked about earlier.

The post method allows the user to send a body along with the default API parameters. Usually, we want the body to be in JSON format. Since this body is not delivered directly in the URL, but as a text, we have to parse this text and fetch the arguments. The flask _restful package offers the RequestParser class for that. We simply add all the arguments we expect to find in the JSON input with the .add_argument() method and parse them into a dictionary. We then convert it into an array and return the prediction of our model as JSON.

class Predict(Resource):

    @staticmethod
    def post():
        parser = reqparse.RequestParser()
        parser.add_argument('petal_length')
        parser.add_argument('petal_width')
        parser.add_argument('sepal_length')
        parser.add_argument('sepal_width')

        args = parser.parse_args()  # creates dict

        X_new = np.fromiter(args.values(), dtype=float)  # convert input to array

        out = {'Prediction': IRIS_MODEL.predict([X_new])[0]}

        return out, 200

You might be wondering what the 200 is that we are returning at the end: For APIs, some HTTP status codes are displayed when sending requests. You all might be familiar with the famous 404 - page not found code. 200 just means that the request has been received successfully. You basically let the user know that everything went according to plan.

In the end, you just have to add the Predict class as a resource to the API, and write the main function:

API.add_resource(Predict, '/predict')

if __name__ == '__main__':
    APP.run(debug=True, port='1080')

The '/predict' you see in the .add_resource() call, is the so-called API endpoint. Through this endpoint, users of your API will be able to access and send (in this case) POST requests. If you don’t define a port, port 5000 will be the default.

You can see the whole code for the app again here:

# app.py
from flask import Flask
from flask_restful import Api, Resource, reqparse
from sklearn.externals import joblib
import numpy as np

APP = Flask(__name__)
API = Api(APP)

IRIS_MODEL = joblib.load('iris.mdl')


class Predict(Resource):

    @staticmethod
    def post():
        parser = reqparse.RequestParser()
        parser.add_argument('petal_length')
        parser.add_argument('petal_width')
        parser.add_argument('sepal_length')
        parser.add_argument('sepal_width')

        args = parser.parse_args()  # creates dict

        X_new = np.fromiter(args.values(), dtype=float)  # convert input to array

        out = {'Prediction': IRIS_MODEL.predict([X_new])[0]}

        return out, 200


API.add_resource(Predict, '/predict')

if __name__ == '__main__':
    APP.run(debug=True, port='1080')

Run the API

Now it’s time to run and test our API!

To run the app, simply open a terminal in the same directory as your app.py script and run this command.

python run app.py

You should now get a notification, that the API runs on your localhost in the port you defined. There are several ways of accessing the API once it is deployed. For debugging and testing purposes, I usually use tools like Postman. We can also access the API from within a Python application, just like another user might want to do to use your model in their code.

We use the requests module, by first defining the URL to access and the body to send along with our HTTP request:

import requests

url = 'http://127.0.0.1:1080/predict'  # localhost and the defined port + endpoint
body = {
    "petal_length": 2,
    "sepal_length": 2,
    "petal_width": 0.5,
    "sepal_width": 3
}
response = requests.post(url, data=body)
response.json()

The output should look something like this:

Out[1]: {'Prediction': 'iris-versicolor'}

That’s how easy it is to include an API call in your Python code! Please note that this API is just running on your localhost. You would have to deploy the API to a live server (e.g., on AWS) for others to access it.

Conclusion

In this blog article, you got a brief overview of how to build a REST API to serve your machine learning model with a web interface. Further, you now understand how to integrate simple API requests into your Python code. For the next step, maybe try securing your APIs? If you are interested in learning how to build an API with R, you should check out this post. I hope that this gave you a solid introduction to the concept and that you will be building your own APIs immediately. Happy coding!

 

Jannik Klauke

Jannik Klauke