### 1. Produktziel
In diesem Projekt war das Ziel, ein KI-basiertes Programm zu entwickeln, welches die Möglichkeit bieten soll, Erstkontakt zu potentiellen Kund:innen über Twitter herzustellen. Hierbei liegt die Smart Funktion im Fokus, mit der man durch Natural Learning Understanding nicht zutreffende Tweets aussortiert und eine automatisierte Werbung/Nachricht verschicken kann. Das Unternehmen hat somit die Fähigkeit und die Kompetenz die Unterhaltung mit den Kaufinteressent:innen vertrieblich zu begleiten.

Im ersten Schritt werden Tweets mit dem Stichwort „phone“ selektiert und es besteht jederzeit die Gelegenheit als Endkund:innen (Handy-Unternehmen) passende Produktinformationen auf Twitter bereitzustellen und über die automatisierte Nachricht erfolgt ein Gesprächsangebot per Link. Dies sind die Bedingungen des Minimal Viable Products. Im zweiten Schritt wird die Version 1 entwickelt, die dann der Integration eines Smart Filters entspricht.

### 2. Architektur und Technologien
#### 2.1 Grundidee des Produktes

Das auftraggebende Unternehmen LivePerson möchte ein Produkt haben, welches seinen Kunden hilft, potenzielle Kund:innen (Leads) über Twitter zu finden. Es soll ein Programm erstellt werden, das zunächst eine Verbindung zur Twitter-API herstellt, damit eine Anfrage gesendet werden kann. Mittels Searchtweets Paket wird eine Anfrage an Twitter gesendet, die auf unserer definierten Query basiert.Mit dem Basic Filter werden irrelevante Tweets wie zum Beispiel:" I want a new phone case" ausgeschlossen. Daher ist ein Smart-Filter erforderlich, um erneut zu bestimmen, ob Kaufinteresse für ein neues Handy besteht.

Nach der Anwendung des Basic Filters und des Smart Filters sollten nur noch Tweets übrig bleiben von Usern, die eine hohe Kaufbereitschaft aufweisen und die für den Kunden des Auftraggebers Leads darstellen.

Wie das Diagramm zeigt, verringert sich nach jeder Ebene die Anzahl an Tweets, die an die nächste Ebene gesendet werden.

#### 2.2 Architekturplan

Wir haben insgesamt 3 Komponenten: Basic Filter, Smart Filter und Reply-Bot. Die Main Klasse steuert die Verbindung zwischen den verschiedenen Komponenten. Der Kernpunkt des Basic Filter ist das Finden der richtigen Query. Bei zu vielen Schlüsselwörtern ist die Anzahl der Tweets, die an den Smartfilter weitergeleitet werden können, sehr begrenzt. Auf der andere Seite, bei zu wenigen Schlüsselwörtern erhalten wir zu viele irrelevante Tweets. Der Basic Filter verwendet das searchtweets-Paket, um Tweets auf der Grundlage unserer definierten Abfrage zu finden.

Der Smartfilter ist ein KI-basiertes Modell, dessen Trainingsdaten auf Tweets basieren, die wir mit unserer Query abgerufen haben und die durch den Basic Filter gekommen sind. Diese Tweets wurden nun von uns mit oder ohne Kaufinteresse gelabelt um unseren Smartfilter mit der Google VertexAI zu trainieren. Google bietet uns einen Endpunkt an, der mit unserem Skript verbunden wird. Der vom Basic Filter gesammelte Inhalt wird über diesen Endpunkt an den Smartfilter weitergeleitet. Im folgenden Abschnitt (2.3) werden wir das Training unseres Modells im Detail besprechen.

Die erneut gefilterten Tweets werden nun an den Reply-Bot weitergeleitet, der unsere vordefinierte Antwort an Twitter sendet. Der Reply-Bot hat eine Auswahl an fünf hinterlegten Antworten, die in unregelmäßigen Abständen an neue Leads gesendet werden.

#### 2.3 Verwendete Technologien
##### 2.3.1 AutoML
Auto-ML steht für automatisiertes maschinelles Lernen. Es unterstützt dabei einzelne Schritte oder auch den kompletten Prozess eines Machine-Learning-Workflows. Für unerfahrene Programmierer:innen können so schnell Ergebnisse erzielt und ausgewertet werden.

Die Vorbereitung der Trainingsdaten erfolgt allerdings durch den Mensch und ist entscheidend für die Qualität der Ergebnisse.

In diesem Projekt wurde die Google Vertex-AI zum Training der Daten verwendet. Es wurde festgestellt, dass das Löschen von Emojis und von Stopp-Wörtern nicht wesentlich zur Verbesserung der Ergebnisse beiträgt. Deshalb wurde schließlich auf das manuelle Reinigen der Trainingsdaten verzichtet. Für dieses Projekt wurde das Training eines Modells, sowie die Vorhersage durch dieses mit Hilfe von der Google Vertex-AI vorgenommen. Auto-ML trifft für das Training eine Auswahl an Machine-Learning-Algorithmen und vergleicht diese und deren Ergebnisse. Google-Cloud bietet an das endgültige Modell auf einem Endpoint bereitzustellen. Neue Daten werden im laufenden Prozess an diesen Endpoint geschickt und durch das vorher trainierte Modell kategorisiert.

##### 2.3.2 Python Pakete und Twitter-API
Für das Projekt wurden die Python-Pakete Searchtweets und Tweepy verwendet. Searchtweets ist eine Library, die Anfragen an die Twitter-Search-API unterstützt und erleichtert. Ein großer Vorteil ist beispielsweise, dass die Pagination der Suchergebnisse automatisch übernommen wird. Die Anfragen an die Search-API werden an den Endpunkt "recent" gestellt und dieser gibt Tweets der letzten 7 Tage zurück. Dieser Endpunkt wurde bewusst gewählt, um Kund:innen zu finden, die sich auch aktuell für den Kauf eines Handys interessieren.

Zum Versenden von Antworten an Kaufinteressent:innen wurde das Python-Paket Tweepy genutzt. Dieses unterstützt ebenfalls den Zugriff auf die Twitter-API und wird häufig bei der Erstellung von Bots verwendet.

##### 2.3.3 Google Cloud Run und Google Cloud Scheduler
Google Cloud Run ist eine Lösung, um Programme container basiert ausführen zu können. Diese dienen zum Verpacken und Bereitstellen von Code und jeglichen Abhängigkeiten. Unser Script wird durch den Cloud Scheduler automatisiert einmalig am Tag abgerufen. Daraufhin bestand die Gegebenheit das Script mit einem Test-Twitter-Account zu verknüpfen, so dass nur die Tweets, die mit diesem Account verfasst wurden, in Betracht gezogen werden.

### 3. Smartfilter: Vorbereitung, Training und Bewertung
#### 3.1 Labelling
Damit das Modell bestmöglich trainiert werden kann, werden Labels für die jeweiligen Tweets benötigt. Dies passierte manuell und umfasste ca. 1400 Tweets. Hierbei wurde ein Glossar angelegt, um die Labels zu definieren und die Tweets eindeutig zuzuordnen. Weist ein Tweet kein Kaufinteresse auf, bekommt er das Label Null. Tweets von Twitter Usern, die entweder ein neues Handygerät suchen oder die mit ihrem jetzigen Modell unzufrieden sind werden als “Kaufinteresse” eingestuft und erhalten das Label 1. Nachdem die Tweets das erste Mal gelabelt wurden, folgte eine zweite Überprüfung durch ein anderes Gruppenmitglied.

#### 3.2 Training des Smartfilter-Modells mittels Vertex AI

| | Erste Modell | Zweite Modell | Dritte Modell |
| ---- | ------------ | ------------- | ------------- |
| Importierter Datensatz als Basis zum Modell-Trainieren | 400 | 740 | 1400 |
| Mit Kaufinteresse | 114 | 530 | 680 |
|Ohne Kaufinteresse| 286 | 210 | 720 |

Mit Hilfe der VertexAI Plattform und dem dort zur Verfügung gestellten Auto-ML Algorithmus trainierten wir unser Smartfilter-Modell. Hierfür wurde die Textklassifizierung für Single-Labelling gewählt und 80 % des Datensatzes wurden für das Training genutzt, während 10 % der Daten zum Testen und weitere 10 % der Daten zum Validieren zurück behalten wurden. Die Datenaufteilung erfolgte per Zufallsprinzip.

In den letzten beiden Sprints des Projektes wurden insgesamt drei Modelle trainiert, die mit einander verglichen wurden, um den dazugehörigen Datensatz fortschreitend von anfänglich 400 bis auf ca. 1400 Tweets zu erweiterten. Während die ersten beiden Modelle zwar nach dem Training definiertes Kaufinteresse mit Label 1 richtig zuordneten, so waren sie kaum in der Lage das Label 0 (kein Kaufinteresse) richtig zu erkennen.

Die Anpassung der Query, welche genutzt wurden, um Tweets für Trainingszwecke aus Twitter zu generieren und welche zwischen dem ersten und zweiten Modell angepasst wurden, um die Menge der Label-1-Tweets zu erhöhen, spiegelt sich in der fast fünffachen Menge dieser Gruppe bei unseren Trainingsdaten wieder. Es wurden beim zweiten Modell 530 anstatt nur 114 Label-1-Tweets importiert. Jedoch verbesserte sich die Fähigkeit unseres Modells Label-0-Tweets richtig einzuordnen erst nachdem wir bei unserem dritten Modell die Tweets mit Label 0 um ca. 500 Stück erhöhten und auf ein mengenmäßiges Gleichgewicht der Trainingsdaten (680/720) achteten.

Die Bewertung unseres finalen Modells durch die GCP fiel bei einem Konfindenzwert von 0,5 folgendermaßen aus:
**Durchschnittliche Precision:** 0,996
**Precision:** 97,1%
**Recall:** 97,1%

Wir testen das Modell manuell mit selbst geschriebenen Tweets, die wir zuvor dem Label 1 und 0 eindeutig zu ordneten.

#### 3.3 Bewertung des Smart Filter Modells
Das dritte Modell hatte sich verglichen mit den beiden Vorgängermodellen sehr verbessert in Bezug auf seine Fähigkeit das Label 0 korrekt einzustufen. So wurden
Label 0 Tweets alle korrekt mit 0, d.h. zu 100% richtig gewertet, während die
Label 1 Tweets noch nicht optimal erkannt werden. In drei aus acht Fällen, d.h. mit einer Fehlerquote von ca. 38% wurde ein mögliches Kaufinteresse übersehen und vom Modell fälschlicherweise mit Label 0 bewertet.

Da unser Produkt Tweets4Leads dem Endkund:innen verspricht, dass durch unseren Smartfilter nur Twitter User mit Kaufinteresse Werbung bzw. Chateinladungen angezeigt bekommen, ist es sehr positiv, dass alle getesteten Tweets mit Label 0 korrekt zugeordnet wurden.

Derzeit werden zwar fast 40 % der Tweets mit Kaufinteresse übersehen, allerdings werden hierfür nicht nur Tweets von Usern mit einbezogen, die bereits auf der ausgesprochenen Suche nach einem neuen Gerät sind, sondern auch die von User, welche mit ihrem jetzigen Gerät unzufrieden sind.

Durch das Trainieren des Modells mit einem größeren Datensatz und/oder auch die Beschränkung auf nur eine Gruppe (z.B. Menschen die explizit nach einem neuen Handy suchen) würde sich die Fehlerquote beim Erkennen von Kaufinteresse reduzieren lassen.

### 4. Möglichkeiten zur Erweiterung des Projektes

Es gibt natürlich noch mehrere Optionen das Produkt zu verbessern und zu erweitern. So ist beispielsweise beim Testen des Sprachmodells aufgefallen, dass das Modell Sätze in denen weibliche und männliche Personen genannt werden, unterschiedlich bewertet, obwohl der restliche Satz identisch ist. Gibt man „My sister needs a new phone“ ein, wird dies als Kaufinteresse gewertet. Setzt man jedoch „brother“ ein, erkennt das Modell kein Interesse. Es wäre also sinnvoll noch einmal den Datensatz zu sichten, um herauszufinden, woher solche Fehlurteile kommen. Es ist auch nicht auszuschließen, dass weitere Unstimmigkeiten zum Vorschein kommen. Um das Vorhersagemodell so genau wie möglich zu machen, sollte es ständig überarbeitet werden.

Außerdem könnte man auch zusätzliche Verbesserungen erzielen, indem man weitere Queries zur Anfrage an Twitter ausprobiert. Eine ausführliche Analyse der einzelnen Stichwörter kann dazu hilfreich sein. Im Laufe des Prozesses ist diesbezüglich aufgefallen, dass nur das Wort “case” ausgeschlossen wird, ein anderes Wort wäre zum Beispiel “wallpaper”. Folglich können verschiedene Kombinationen dieser Suchwörter als Query verwendet werden. Daraufhin müsste jedoch immer wieder ein neuer Datensatz erstellt werden und ein neues Modell-Training erfolgen. Im Anschluss daran können die Modelle verglichen und das bestmöglichste ausgewählt werden.

Grundsätzlich ist auch die Architektur des Produktes erweiterbar. Zum Einen könnte jede der drei Komponenten als eigenständige API-Schnittstelle ausgestaltet werden. Dazu müssten die angefragten Twitter-Daten dann via HTTP an die einzelnen Komponenten übergeben werden. Zum Anderen könnte anstelle der Twitter-Search-API auch die Streaming-API genutzt werden. In diesem Fall müsste das Produkt nicht durch eine Person oder Cloud-Dienst getriggert werden, sondern es würde immer am Twitter-Endpoint „lauschen“ und die passenden, aktuell geposteten Tweets direkt verarbeiten.

Das Projekt ist auch auf andere Stichwörter als „phone“ ausweitbar. Natürlich muss dafür die Query angepasst und ein neuer Datensatz erstellt werden, auf dem dann ein neues Vorhersage-Modell trainiert wird. Die Architektur mit den drei Komponenten ist aber so gestaltet, dass sie sich prinzipiell auch für andere Suchwörter anwenden lässt. Es muss die Query in der Anfrage angepasst werden und das neue Modell auf einem Endpoint bereitgestellt werden, an den dann die Tweets gesendet werden. Es ist aber wichtig zu beachten, dass nicht alle Themengebiete auf Twitter gleich gut repräsentiert sind. Unser Produkt sollte beispielsweise ursprünglich Twitter User herausfiltern, die auf der Suche nach einem neuen Bankkonto waren. Es stellte sich aber heraus, dass sich eher wenige Personen auf der Plattform Twitter nach Empfehlungen für Bankkonten erkundigen. Außerdem ist der Begriff „bank“ mehrdeutig (Bank zum Sitzen – Bank für Geldgeschäfte) und liefert damit auch besonders uneindeutige Suchergebnisse. Das gilt es beim Erschließen von neuen Themenfeldern zu beachten.

### 5. Fazit
Für dieses Projekt hat die Gruppe viele neue Technologien kennengelernt, von Basics wie der Programmiersprache Python, über das Verwenden von Python-Paketen wie beispielsweise Searchtweets und Tweepy, bis hin zur Twitter-Search-API und der Google-Cloud-Platform, vor allem der Google Vertex-AI. Auch das Erstellen und Labeln von Datensätzen und schließlich das Trainieren von Klassifikations-Modellen wurde neu erlernt. Die Studentinnen haben dabei vor allem gelernt sich selbstständig in neue Themenfelder einzuarbeiten.

Ein weiterer wichtiger Bestandteil des Projekts war die Zusammenarbeit als agiles Scrum-Team. Der Arbeitsablauf wurde in Sprints unterteilt und dazu Sprint Plannings und Retrospektiven abgehalten. Selbstständiges und eigenverantwortliches Arbeiten war durch Aufteilung der Tasks gegeben. Auch mit Hilfe des Scrum-Prozesses konnte so das Team immer enger zusammenwachsen und eine gute Arbeitsatmosphäre erreicht werden.

Ausführliche Dokumentationen
---
- [Glossar](https://docs.google.com/document/d/1JEaOahVloje8NVh8k3novPv0UsYnNwDmU1V3n8SWivw/edit)
- [Query Basic Filter](https://docs.google.com/document/d/1JOwszYYraFBJ_guHl_0DUh9dQDGmbCUDOvIk6O22Ad8/edit)