Vorname*

Nachname*

Telefon

E-Mail*

Firma*

Position*

Nachricht*

  Mit dem Absenden stimme ich den Datenschutzbestimmungen zu.

Die mit * gekennzeichneten Felder sind Pflichtfelder

SENDEN

Vielen Dank für Ihre Nachricht. Wir werden uns schnellstmöglich mit Ihnen in Verbindung setzen. Freundliche Grüße Ihr statworx Team

Marlon Schumacher

 

Bildnachweis:

AdobeStock 83282923 – Mego-studio

Bei statworx erforschen wir kontinuierlich neue Ideen und Möglichkeiten im Bereich der künstlichen Intelligenz. Die letzten Monate waren von Generativen Modellen geprägt, insbesondere von solchen, die von OpenAI entwickelt wurden (z.B. ChatGPT, DALL-E 2), aber auch von Open-Source-Projekten wie Stable Diffusion. ChatGPT ist ein Text-zu-Text-Modell, während DALL-E 2 und Stable Diffusion Text-zu-Bild-Modelle sind, die auf der Grundlage einer kurzen Textbeschreibung des Benutzers beeindruckende Bilder erstellen. Während der Evaluierung dieser Forschungstrends entdeckten wir eine großartige Möglichkeit, unsere von HP zur Verfügung gestellte GPU-Workstation zu nutzen, damit unsere #statcrew ihre eigenen digitalen Avatare erstellen kann.

Das steckt hinter dem Text-zu-Bild-Generator Stable Diffusion

Text-Bild-Generatoren wie Stable Diffusion und DALL-E 2 basieren auf Diffusionsarchitekturen von künstlichen neuronalen Netzen. Die umfangreichen Trainingsdaten aus dem Internet erfordern oft Monate an Trainingszeit auf Hochleistungsrechnern, um eine optimale Performance zu erreichen. Eine erfolgreiche Implementierung ist daher lediglich durch den Einsatz von Supercomputern möglich. Aber auch nach dem Training benötigen die OpenAI-Modelle immer noch einen Supercomputer, um neue Bilder zu generieren, da ihre Größe die Kapazität von herkömmlichen Computern übersteigt. OpenAI hat Schnittstellen bereitgestellt, um den Zugang zu seinen Modellen zu erleichtern (https://openai.com/product#made-for-developers). Jedoch wurden die Modelle selbst nicht öffentlich freigegeben.

Stable Diffusion hingegen wurde als Text-zu-Bild-Generator entwickelt, ist aber so groß, dass es auf dem eigenen Computer ausgeführt werden kann. Das Open-Source-Projekt ist ein Gemeinschaftsprojekt mehrerer Forschungsinstitute. Seine öffentliche Verfügbarkeit ermöglicht es Forschern und Entwicklern, das trainierte Modell durch sogenanntes fine-tuning für ihre eigenen Zwecke anzupassen. Stable Diffusion ist klein genug, um auf einem Computer ausgeführt zu werden, aber das fine-tuning ist auf einer Workstation (wie der von HP mit zwei NVIDIA RTX8000 GPUs) wesentlich schneller. Obwohl es deutlich kleiner ist als z. B. DALL-E2, ist die Qualität der erzeugten Bilder immer noch hervorragend.

Die genannten Modelle werden durch die Verwendung von Prompts gesteuert, welche eine Beschreibung des gewünschten Bildes in Form von Text enthalten und dadurch das Modell zur Generierung des entsprechenden Bildes angeregt. Für künstliche Intelligenz ist Text direkt nicht verständlich, da alle Algorithmen auf mathematischen Operationen beruhen, die nicht direkt auf Text angewendet werden können.

Daher besteht eine gängige Methode darin, ein so genanntes Embedding zu erzeugen, d. h. Text in mathematische Vektoren umzuwandeln. Das Verständnis des Textes ergibt sich aus dem Training des Übersetzungsmodells von Text zu Embeddings.  Die hochdimensionalen Embedding-Vektoren werden so erzeugt, dass der Abstand der Vektoren zueinander die Beziehung der Originaltexte darstellt. Ähnliche Methoden werden auch für Bilder verwendet, und es werden spezielle Modelle für diese Aufgabe trainiert.

CLIP: Ein hybrides Modell von OpenAI zur Bild-Text-Integration mit kontrastivem Lernansatz

Ein solches Modell ist CLIP, ein von OpenAI entwickeltes Hybridmodell, das die Stärken von Bilderkennungsmodellen und Sprachmodellen kombiniert. Das Grundprinzip von CLIP besteht darin, Embeddings für passende Text- und Bildpaare zu erzeugen. Diese Embedding-Vektoren der Texte und Bilder werden so berechnet, dass der Abstand der Vektordarstellungen der passenden Paare minimiert wird. Eine Besonderheit von CLIP ist, dass es mit Hilfe eines kontrastiven Lernansatzes trainiert wird, bei dem zwei verschiedene Eingaben miteinander verglichen werden und die Ähnlichkeit zwischen ihnen maximiert wird, während die Ähnlichkeit, der nicht übereinstimmenden Paare im selben Durchgang minimiert wird. Dadurch kann das Modell robustere und übertragbare Repräsentationen von Bildern und Texten erlernen, was zu einer verbesserten Leistung bei einer Vielzahl von Aufgaben führt.

Anpassen der Bildgenerierung durch Textual Inversion

Mit CLIP als Vorverarbeitungsschritt der Stable Diffusion-Pipeline, die das Embedding der Prompts erstellt, eröffnet sich eine leistungsstarke und effiziente Möglichkeit, dem Modell neue Objekte oder Stile beizubringen. Dieser Spezialfall des fine-tuning wird als Textual Inversion bezeichnet. Abbildung 1 zeigt diesen Trainingsprozess. Mit mindestens drei Bildern eines Objekts oder Stils und einem eindeutigen Textbezeichner kann Stable Diffusion so gesteuert werden, dass es Bilder dieses spezifischen Objekts oder Stils erzeugt.

Im ersten Schritt wird ein <tag> gewählt, der das Objekt repräsentieren soll.

In diesem Fall ist das Objekt als Johannes definiert, und es werden mehrere Bilder von ihm zur Verfügung gestellt. In jedem Trainingsschritt wird ein zufälliges Bild aus den zur Verfügung gestellten Bildern ausgewählt. Zusätzlich wird eine erklärbare Aufforderung wie „rendering of <tag>“ bereitgestellt, und in jedem Trainingsschritt wird eine zufällige Auswahl dieser Aufforderungen getroffen. Der Teil <tag> wird durch den definierten Begriff (in diesem Fall <Johannes>) ausgetauscht.

Durch Anwendung der Textual Inversion Methode wird das Vokabular des Modells erweitert. Nach Durchführung ausreichender Trainingsiterationen kann das neu feinabgestimmte Modell in die Stable Diffusion-Pipeline integriert werden. Dies führt zu einem neuen Bild von Johannes, wenn der Begriff <Johannes> im Prompt des Nutzers vorkommt. Dem generierten Bild können anschließend je nach Eingabeaufforderung Stile und andere Objekte hinzugefügt werden.

Abbildung 1: Fine-tuning von CLIP mit Textual Inversion.

So sieht es aus, wenn wir KI-generierte Avatare unserer #statcrew erstellen

Wir haben bei statworx allen interessierten Kollegen und Kolleginnen ermöglicht, ihre digitalen Avatare in verschiedensten Kontexten zu positionieren.

Mit der zur Verfügung stehenden HP-Workstation konnten wir die integrierten NVIDIA RTX8000 GPUs nutzen und damit die Trainingszeit im Vergleich zu einer Desktop-CPU um den Faktor 15 reduzieren. Wie man an den Beispielen unten sehen kann, hat es der unserer statcrew viel Spaß gemacht, eine Reihe von Bildern in unterschiedlichen Situationen zu erzeugen. Die folgenden Bilder zeigen ein paar ausgewählte Porträts.

Prompts von links oben nach rechts unten

1. <Andreas> looks a lot like christmas, santa claus, snow
2. Robot <Paul>
3. <Markus> as funko, trending on artstation, concept art, <Markus>, funko, digital art, box (, superman / batman / mario, nintendo, super mario)
4. <Johannes> is very thankful, art, 8k, trending on artstation, vinyl·
5. <Markus> riding a unicorn, digital art, trending on artstation, unicorn, (<Markus> / oil paiting)·
6. <Max> in the new super hero movie, movie poster, 4k, huge explosions in the background, everyone is literally dying expect for him
7. a blonde emoji that looks like <Alex>
8. harry potter, hermione granger from harry potter, portrait of <Sarah>, concept art, highly detailed

Stable Diffusion und Textual Inversion stellen spannende Entwicklungen auf dem Gebiet der künstlichen Intelligenz dar. Sie bieten neue Möglichkeiten für die Erstellung einzigartiger und personalisierter Avatare, sind aber auch auf verschiedene Stile anwendbar. Wenn wir diese und andere KI-Modelle weiter erforschen, können wir die Grenzen des Möglichen erweitern und neue und innovative Lösungen für reale Probleme schaffen.

 

Bilderquelle: Adobe Stock 546181349  Johannes Gensheimer

Es weihnachtet sehr bei statworx: In der Mittagspause laufen Weihnachtslieder, das Büro ist festlich geschmückt und die Weihnachtsfeier war bereits ein voller Erfolg. Aber statworx wäre kein Beratungs- und Entwicklungsunternehmen im Bereich Data Science, Machine Learning und KI, wenn wir unsere Expertise und Leidenschaft nicht auch in unsere Weihnachtsvorbereitungen einbringen würden.

Umgeben vom Duft von frischgebackenen Plätzchen und Weihnachtspunsch, kam uns die Idee, einen KI-basierten Weihnachtsrezept-Generator zu entwickeln, der mithilfe von OpenAI Modellen, Texte jeglicher Art vervollständigen und visualisieren kann. Mit GPT-3 genügt die Beschreibung eines Rezeptes, um daraus eine vollständige Zutatenliste sowie eine Kochanleitung zu generieren. Anschließend wird der komplette Text als Bildbeschreibung an DALL-E 2 übergeben, welches diesen in einem hochauflösenden Bild darstellt. Die Anwendung beider Modelle geht natürlich im Berufsalltag weit über den Unterhaltungswert hinaus, jedoch halten wir ein weihnachtliches und spielerisches Kennenlernen mit den Modellen bei Plätzchen und Glühwein für optimal.

Bevor wir gemeinsam kreativ werden und den Weihnachtsrezept-Generator testen, werfen wir in diesem Blogbeitrag zunächst noch einen kurzen Blick auf die dahintersteckenden Modelle.

Die Blätter fallen aber die KI blüht mithilfe von GPT-3 auf

Das Entwicklungstempo der Large-Language-Models und Text-to-Image Modelle der letzten zwei Jahre hat längst die Schallmauer durchbrochen und auch bei uns alle Mitarbeitenden mitgerissen. Von Avataren und internen Memes über synthetische Daten auf Projekten hat nicht nur die Güte der Ergebnisse einen Wandel herbeigeführt, sondern auch die Handhabung der Modelle. Wo einst performanter Code, statistische Auswertungen und viele griechische Buchstaben umhergeschwirrt sind, findet nun die Bedienung einiger Modelle fast schon in Form eines Austauschs oder einer Interaktion statt. Mittels Texten oder stichworthaltigen Aufforderungen entstehen die sogenannten Prompts.

Abb. 1: Lust auf Weihnachtspunsch mit Schuss? Ausgang für dieses Bild war die Aufforderung “A rifle pointed at a Christmas mug”. Durch viel Ausprobieren und meist unerwartet ausführliche Prompts mit vielen Schlagworten lassen sich die Resultate stark beeinflussen.

Diese Form der Interaktion ist unter anderem dem Sprachmodell GPT-3 zu verdanken, das auf einem Deep Learning Modell basiert. Die Ankunft dieses revolutionären Sprachmodells stellte nicht nur für das Forschungsfeld der Sprachmodellierung (NLP) einen Wendepunkt dar, sondern hat ganz nebenbei einen Paradigmenwechsel in der KI-Entwicklung eingeläutet: Das Prompt-Engineering.

Während viele Bereiche des Machine Learnings davon unberührt bleiben, bedeutete es für andere Bereiche sogar den größten Umbruch seit der Verwendung neuronaler Netze. Nach wie vor werden Wahrscheinlichkeitsverteilungen erlernt, Zielgrößen vorhergesagt, oder Embeddings verwendet, also eine Art komprimiertes neuronales Zwischenprodukt, welches für die Weiterverarbeitung und Informationsgehalt optimiert sind. Für andere Anwendungsfälle, meist kreativer Natur, reicht es nun aus, das gewünschte Resultat in natürlicher Sprache anzugeben und auf das Verhalten der Modelle abzustimmen. Mehr zum Thema Prompt Engineering findet man in diesem Blogbeitrag.

Generell ist die Fähigkeit der sogenannten Transformer Modelle, einen Satz und dessen Worte als dynamischen Kontext zu erfassen, eine der wichtigsten Neuerungen. Stichwort Attention! Worte (in diesem Fall Koch- und Backzutaten) können in verschiedenen Rezepten verschiedene Bedeutungen haben. Und diese Beziehungen kann das Modell nun erfassen. Bei unseren ersten KI-Kochversuchen war dies noch nicht der Fall. Wenn starre Word2Vec Modelle verwendet wurden, konnte es vorkommen, dass Rinderbrühe oder pürierte Tomaten anstelle oder zusammen mit Rotwein empfohlen wurden. Ungeachtet, ob es um Gelee für Plätzchen oder Glühwein ging, da die deftige Verwendung in den Trainingsdaten überwog!

Weihnachtliche Bildgenerierung mit DALL-E 2

In unserem Weihnachtsrezept-Generator verwenden wir DALL-E 2, um anschließend aus dem vervollständigten Text ein Bild zu generieren. Bei DALL-E 2 handelt es sich um ein neuronales Netz, welches hochauflösende Bilder anhand Textbeschreibungen generieren kann. Hierbei gibt es keine Grenzen – die aus den kreativen Worteingaben resultierenden Bilder lassen das Unmögliche möglich erscheinen. Es kommt jedoch auch oft zu Missverständnissen, wie man in einigen folgenden Beispielen erkennen kann.

Abb. 2:  Programmiererfahrene werden hier sofort erkennen: It’s not you, it’s me! Komplex, pedantisch, oder einfach logisch… Programme zeigen uns Fehler oder lose Annahmen meist sofort auf.

Nun wird das Kennenlernen mit dem Modell umso wichtiger, da kleine Änderungen im Prompt oder bestimmte Schlagworte das Resultat stark beeinflussen können. Seiten wie PromptHero sammeln bisherige Ergebnisse samt Prompts (die Erfahrungswerte unterscheiden sich übrigens je nach Modell) und geben Inspiration für hochauflösende generierte Bilder.

Abb. 3: Wir wollten testen, was möglich ist und haben Zimtsterne- und Pfefferkuchen-Hawaii mit Ananas und Schinken zu generiert. Die Ergebnisse bewegen sich noch abseits von Geschmack und Würde.

Und wie würde das Modell einen Kaffee an der Akropolis oder im kanadischen Indian Summer zubereiten? Oder einen Pun(s)ch mit Wumms?

Abb. 4: Packs quite the punch.

Komplexe Technik, informelles Kennenlernen

Genug Theorie und zurück zur Praxis.

Nun ist es an der Zeit, unseren Weihnachtsrezept-Generator zu testen und sich anhand eines Rezept-Namens und einer unvollständigen Liste an gewünschten Zutaten, ein Kochrezept empfehlen zu lassen. Kreative Namen, Beschreibungen und Formen werden ermutigt, unkonventionelle Zutaten streng erwünscht und modellseitig überraschende Interpretationen sind fast schon vorprogrammiert.

Zum Weihnachtsrezept-Generator

Das zur Textvervollständigung verwendete GPT-3 Modell ist so vielfältig, dass ganz Wikipedia nicht einmal 0.1% der Trainingsdaten ausmacht und für mögliche neue Anwendungsfälle kein Ende in Sicht ist. Einfach unsere kleine WebApp zum Generieren von Punsch-, Plätzchen- oder beliebigen Rezepten öffnen und staunen, wie weit die Entwicklungen im Natural Language Processing und Text-to-Image gekommen sind.

Wir wünschen viel Spaß!

Jonas Braun

In der Computer Vision Arbeitsgruppe bei statworx hatten wir uns zum Ziel gesetzt, mit Hilfe von Projekten Computer Vision Kompetenzen aufzubauen. Für die diesjährige statworx Alumni Night, die Anfang September stattfand, entstand die Idee eines Begrüßungsroboters, der die ankommenden Mitarbeitenden und Alumni von statworx mit einer persönlichen Nachricht begrüßen sollte. Für die Realisierung des Projekts planten wir ein Gesichtserkennungsmodell auf einem Waveshare JetBot zu entwickeln. Der Jetbot wird von einem NVIDIA Jetson Nano angetrieben, ein kleiner, leistungsfähiger Computer mit einer 128-Core GPU für die schnelle Ausführung moderner KI-Algorithmen. Viele gängige KI-Frameworks wie Tensorflow, PyTorch, Caffe und Keras werden unterstützt. Das Projekt schien sowohl für erfahrene als auch für unerfahrene Mitglieder:innen der Arbeitsgruppe eine gute Möglichkeit zu sein, Wissen im Bereich Computer Vision aufzubauen und Erfahrungen im Bereich Robotik zu sammeln.

Gesichtserkennung (Face Recognition) mithilfe eines JetBots erfordert die Lösung einer Reihe miteinander verbundenen Problemen:

1. Face Detection: Wo befindet sich das Gesicht auf dem Bild?
   Zunächst muss das Gesicht auf einem gezeigten Bild lokalisiert werden. Nur dieser Teil des Bildes ist relevant für alle folgenden Schritte.
2. Face Embedding: Welche einzigartigen Merkmale hat das Gesicht?
   Anschließend müssen einzigartige Merkmale des Gesichts erkannt und in einem Embedding kodiert werden, anhand derer es von anderen Personen unterschieden werden kann. Eine damit einhergehende Herausforderung ist, dass das Modell lernen muss mit der Neigung des Gesichts oder schlechter Beleuchtung umzugehen. Daher muss vor der Erstellung des Embeddings die Pose des Gesichts ermittelt und so korrigiert werden, dass das Gesicht zentriert ist.
3. Namensermittlung: Welches Embedding ähnelt dem erkannten Gesicht am meisten?
   Das Embedding des Gesichts muss schließlich mit den Embeddings aller Personen, die das Modell bereits kennt, verglichen werden, um den Namen der Person zu bestimmen.
4. UI mit Willkommensnachricht
   Für die Ausgabe der Willkommensnachricht wird eine UI benötigt. Dafür muss zuvor ein Mapping erstellt werden, welches den Namen der zu grüßenden Person der jeweiligen Willkommensnachricht zuordnet.
5. Konfiguration des JetBots
   Im letzten Schritt muss der JetBot konfiguriert und das Modell auf den JetBot übertragen werden.

Das Trainieren eines solchen Gesichterkennungsmodells ist sehr rechenintensiv, da Millionen von Bildern von Tausenden verschiedenen Personen verwendet werden müssen, um ein leistungsfähiges Neuronales Netz zu erhalten. Sobald das Modell jedoch trainiert ist, kann es Embeddings für jedes beliebige (bekannte oder unbekannte) Gesicht erzeugen. Daher konnten wir glücklicherweise auf bestehende Gesichterkennungsmodelle zurückgreifen und mussten lediglich die Embeddings von den Gesichtern unserer Kolleg:innen und Alumni erstellen. Nichtsdestotrotz sollen die Schritte des Trainings kurz erläutert werden, um ein Verständnis dafür zu vermitteln, wie solche Gesichtserkennungsmodelle funktionieren.

Für die Implementierung verwendeten wir das Pythonpaket face_recognition, welche die Gesichtserkennungsfunktionalität von dlib umschließt und so die Arbeit mit ihr erleichtert. Das neuronale Netz selbst wurde auf einem Datensatz von etwa 3 Millionen Bildern trainiert und erreichte auf dem Datensatz „Labeled Faces in the Wild“ (LFW) eine Genauigkeit von 99,38 % und ist damit anderen Modellen überlegen.

Vom Bild zum codierten Gesicht (Face Detection)

Die Lokalisierung eines Gesichts auf einem Bild erfolgt durch den Histogram of Oriented Gradients (HOG) Algorithmus. Dabei wird jeder einzelne Pixel des Bildes mit den Pixeln in der unmittelbaren Umgebung verglichen und durch einen Pfeil ersetzt, der in die Richtung zeigt, in die das Bild dunkler wird. Diese Pfeile stellen die Gradienten dar und zeigen den Verlauf von hell nach dunkel über das gesamte Bild. Um eine übersichtlichere Struktur zu schaffen, werden die Pfeile auf einer höheren Ebene aggregiert. Das Bild (a) wird in kleine Quadrate von je 16×16 Pixeln unterteilt und mit der Pfeilrichtung ersetzt, die am häufigsten vorkommt (b). Anhand der HOG-kodierten Version des Bildes kann nun der Teil des Bildes gefunden werden, der einer HOG-Kodierung eines Gesichts (c) am ähnlichsten ist. Nur dieser Teil des Bildes ist relevant für alle folgenden Schritte.

Abbildung 1: Quelle HOG face pattern: https://commons.wikimedia.org/wiki/File:Dlib_Learned-HOG-Detector.jpg

Mit Embeddings Gesichter lernbar machen

Damit das Gesichtserkennungsmodell unterschiedliche Bilder einer Person trotz Neigung des Gesichts oder schlechter Beleuchtung der gleichen Person zuordnen kann, muss die Pose des Gesichts ermittelt und so projeziert werden, dass sich die Augen und Lippen immer an der gleichen Stelle im Bild befinden. Dabei kommt der Algorithmus Face Landmark Estimation zum Einsatz, welcher mithilfe eines Machine Learning Modells spezifische Orientierungspunkte im Gesicht finden kann. Dadurch können wir Augen und Mund lokalisieren und durch grundlegende Bildtransformationen wie Drehen und Skalieren so anpassen, dass beides möglichst zentriert ist.

Abbildung 2: Face landmarks (links) und Projektion des Gesichts (rechts)

Im nächsten Schritt wird mithilfe eines neuronalen Netzes ein Embedding des zentrierten Gesichtsbilds erstellt. Das neuronale Netz erlernt sinnvolle Embeddings, indem es innerhalb eines Trainingsschrittes drei Gesichtsbilder gleichzeitig betrachtet: Zwei Bilder einer bekannten Person und ein Bild einer anderen Person. Das neuronale Netz erstellt die Embeddings der drei Bilder und optimiert seine Gewichte, sodass die Embeddings der Bilder der gleichen Person angenähert werden, und sich stärker mit dem Embedding der anderen Person unterscheidet. Nachdem dieser Schritt millionenfach für unterschiedliche Bilder von verschiedenen Personen wiederholt wurde, lernt das neuronale Netz repräsentative Embeddings zu erzeugen. Die Netzwerkarchitektur des Gesichtserkennungsmodells von dlib basiert auf dem ResNet-34 aus dem Paper Deep Residual Learning for Image Recognition von He et al., mit weniger Layern und einer um die Hälfte reduzierten Anzahl von Filtern. Die erzeugten Embeddings sind 128-dimensional.

Abgleich mit gelernten Embeddings in Echtzeit

Für unseren Begrüßungsroboter konnten wir glücklicherweise auf das bestehende Modell von dlib zurückgreifen. Damit das Modell die Gesichter der aktuellen und ehemaligen statcrew erkennen kann, mussten nur noch die Embeddings erstellt werden. Dafür haben wir die offiziellen statworx Bilder verwendet und das resultierende Embedding zusammen mit dem Namen der Person abgespeichert. Wird danach ein unbekanntes Bild in das Modell gegeben, erkennt dieses Gesicht, zentriert es und erstellt dafür ein Embedding. Das erstellte Embedding wird anschließend mit den abgespeicherten Embeddings der bekannten Personen verglichen und bei großer Ähnlichkeit wird der Name dieser Person ausgegeben. Ist kein ähnliches Embedding vorhanden, gibt es keine Übereinstimmung mit den gespeicherten Personen. Mehr Bilder einer Person und damit mehrere Embeddings pro Person verbessern die Performanz des Modells. Unsere Tests zeigten jedoch, dass unsere Gesichter auch mit nur einem Bild pro Person recht zuverlässig erkannt wurden. Nach diesem Schritt hatten wir nun ein gutes Modell, welches in Echtzeit Gesichter in der Kamera erkannte und den zugehörigen Namen anzeigte.

Eine herzliche Begrüßung über ein UI

Unser Plan war es den Roboter mit einem kleinen Bildschirm oder einem Lautsprecher auszustatten, auf dem die Begrüßungsnachricht dann zu sehen bzw. zu hören sein sollte. Für den Anfang hatten wir uns dann aber dazu entschieden, den Roboter an einen Monitor anzuschließen und eine UI für den Monitor zu bauen. Deshalb entwickelten wir zunächst lokal eine simple UI. Dafür ließen wir die Begrüßungsnachricht auf einem Hintergrund mit den statworx Firmenwerten anzeigen und projizierten das Kamerabild in die untere rechte Ecke. Damit jede Person eine personalisierte Nachricht erhält, mussten wir eine json-Datei anlegen, welche das Mapping von den Namen zur Willkommensnachricht definiert. Für unbekannte Gesichter hatten wir die Willkommensnachricht „Welcome Stranger!“ angelegt. Aufgrund der vielen Namensvettern bei statworx hatten alle mit dem Namen Alex zusätzlich einen einzigartigen Identifikator erhalten:

Letzte Hürden vor der Inbetriebnahme des Roboters

Da das Modell und die UI bisher nur lokal liefen, blieb nun noch die Aufgabe das Modell auf den Roboter mit integrierter Kamera zu übertragen. Wie wir dann leider feststellen mussten, war dies komplizierter als gedacht. Wir hatten immer wieder mit Arbeitsspeicherproblemen zu kämpfen und mussten den Roboter insgesamt dreimal neu konfigurieren, bis wir erfolgreich das Modell auf dem Roboter zum Laufen bringen konnten. Die Anleitung für die Konfigurieren des Roboters, welche bei uns zum Erfolg geführt hat, befindet sich hier: https://jetbot.org/master/software_setup/sd_card.html. Die Arbeitsspeicherprobleme konnten sich meist mit einem Reboot beheben.

Der Einsatz des Begrüßungsroboters bei der Alumni Night

Unser Begrüßungsroboter war ein voller Erfolg bei der Alumni Night! Die Gäste waren sehr überrascht und freuten sich über die personalisierte Nachricht.

Abbildung 3: Der JetBot im Einsatz bei der statworx-Alumni-Night

Auch für uns als Computer Vision Cluster war das Projekt ein voller Erfolg. Während des Projekts lernten wir viel über Gesichtserkennungsmodelle und allen damit verbundenen Herausforderungen. Die Arbeit mit dem JetBot war besonders spannend und wir planen bereits fürs nächste Jahr weitere Projekte mit dem Roboter. Sarah Sester

Mein Kollege An hat bereits eine Grafik veröffentlicht, die seine Reise bei statworx von Data Science zu Data Engineering dokumentiert. Sein Beitrag zeigt, welche Fähigkeiten Data Engineers für ihre tägliche Arbeit benötigen. Falls dir „Data Engineering“ nichts sagt: es handelt sich dabei um den Bereich, der sich mit der Speicherung, Verarbeitung und Übertragung von Daten auf sichere und effiziente Weise befasst.

In diesem Beitrag werde ich die Anforderungen an diese Tätigkeiten näher erläutern. Da es eine ganze Reihe von Themen zu lernen gibt, schlage ich die folgende Reihenfolge vor:

1. Eine Programmiersprache
2. Die Grundlagen von git und Versionskontrolle
3. Die UNIX-Befehlszeile
4. REST-APIs und Grundlagen von Netzwerkarchitekturen
5. Datenbanksysteme
6. Containerisierung
7. Die Cloud

Auch wenn dies von eurer persönlichen Lernerfahrung abweichen mag, habe ich festgestellt, dass diese Reihenfolge für Anfänger leichter zu handhaben ist. Wenn ihr an einer kurzen Übersicht über die wichtigsten Data-Engineering-Technologien interessiert seid, könnte euch auch dieser Beitrag meines Kollegen Andre zum Thema gefallen.

Programmieren lernen – welche Sprachen brauche ich?

Wie in anderen datenbezogenen Berufen ist das Programmieren für Data Engineers eine Pflichtübung. Neben SQL verwenden Data Engineers auch andere Programmiersprachen, um ihre Probleme zu lösen. Unter dieser Vielzahl an verwendbaren Programmiersprachen ist Python aber sicherlich eine der besten Optionen. Python hat sich zur Lingua Franca für datenverwandte Aufgaben entwickelt und eignet sich perfekt für die Ausführung von ETL-Aufgaben und das Schreiben von Datenpipelines. Die Sprache ist nicht nur relativ leicht zu erlernen und syntaktisch elegant, sondern bietet auch die Integration mit Tools und Frameworks (wie Apache Airflow, Apache Spark, REST-APIs und relationale Datenbanksysteme wie PostgresSQL), die im Data Engineering entscheidend sind.

Neben der Programmiersprache werdet ihr euch wahrscheinlich auch für eine IDE (Integrated Development Environment) entscheiden. Beliebte Lösungen für Python sind PyCharm und VSCode. Unabhängig von der Wahl wird eure IDE euch wahrscheinlich in die Grundlagen der Versionskontrolle einführen, da die meisten IDEs eine grafische Schnittstelle zur Verwendung von git und Versionskontrolle haben. Sobald ihr mit den Grundlagen vertraut seid, könnt ihr euch mit git und Versionskontrolle vertraut machen.

git & Versionskontrollwerkzeuge – Versionierung des Quellcodes

In einem agilen Team arbeiten in der Regel mehrere Data Engineers an einem Projekt. Daher ist es wichtig sicherzustellen, dass alle Änderungen an Datenpipelines und anderen Teilen der Codebasis nachverfolgt, überprüft und integriert werden können. Dies bedeutet in der Regel, dass der Quellcode in einem entfernten Code-Verwaltungssystem wie GitHub versioniert wird und dass alle Änderungen vor der Produktionsbereitstellung vollständig getestet werden.

Ich empfehle euch dringend, git über die Kommandozeile zu erlernen, um das volle Potenzial auszuschöpfen. Obwohl die meisten IDEs Schnittstellen zu git bieten, sind bestimmte Funktionen möglicherweise nicht vollständig verfügbar. Darüber hinaus bietet das Erlernen von git auf der Kommandozeile einen guten Einstieg, um mehr über Shell-Befehle zu erfahren.

Die UNIX-Befehlszeile – eine grundlegende Fähigkeit

Viele der Aufgaben, die in der Cloud oder auf lokalen Servern und anderen Frameworks ausgeführt werden, werden mit Shell-Befehlen und Skripten gesteuert. In diesen Situationen gibt es keine grafischen Benutzeroberflächen, weshalb Data Engineers mit der Befehlszeile vertraut sein müssen, um Dateien zu bearbeiten, Befehle auszuführen und im System zu navigieren. Ob bash, zsh oder eine andere Shell, die Anforderung Skripte zu schreiben und somit ohne eine Programmiersprache wie Python Aufgaben automatisieren zu können, ist unvermeidlich, insbesondere auf Servern ohne grafische Oberfläche. Da Befehlszeilenprogramme in so vielen verschiedenen Szenarien verwendet werden, sind sie auch für REST-APIs und Datenbanksysteme nützlich.

REST APIs & Netzwerke – wie Dienste miteinander kommunizieren

Moderne Anwendungen sind in der Regel nicht als Monolithen konzipiert. Stattdessen sind die Funktionalitäten oft in separaten Modulen enthalten, die als Microservices ausgeführt werden. Dadurch wird die Gesamtarchitektur flexibler, und das Design kann leichter weiterentwickelt werden, ohne dass die Entwickler den Code aus einer großen Anwendung herausziehen müssen.

Wie aber können solche Module miteinander kommunizieren? Die Antwort liegt im Representational State Transfer (REST) über ein Netzwerk. Das gängigste Protokoll, HTTP, wird von Diensten zum Senden und Empfangen von Daten verwendet. Es ist wichtig, die Grundlagen darüber zu lernen, wie HTTP-Anfragen strukturiert sind, welche HTTP-Verben typischerweise zur Erfüllung von Aufgaben verwendet werden und wie man solche Funktionalitäten praktisch in der Programmiersprache seiner Wahl implementiert. Python bietet Frameworks wie fastAPI und Flask. In diesem Artikel findet ihr ein konkretes Beispiel für den Aufbau einer REST-API mit Flask.

Netzwerke spielen hier ebenfalls eine wichtige Rolle, da sie die Isolierung wichtiger Systeme wie Datenbanken und REST-APIs ermöglichen. Das Konfigurieren von Netzwerken kann manchmal notwendig sein, weshalb ihr die Grundlagen kennen solltet. Sobald ihr mit REST-APIs vertraut seid, ist es sinnvoll, sich mit Datenbanksystemen zu beschäftigen, denn REST-APIs speichern oft selbst keine Daten, sondern fungieren als standardisierte Schnittstellen zum Zugriff auf Daten aus einer Datenbank.

Datenbanksysteme – Daten organisieren

Als Data Engineer werdet ihr einen beträchtlichen Teil eurer Zeit mit dem Betrieb von Datenbanken verbringen, entweder um Daten zu sammeln, zu speichern, zu übertragen, zu bereinigen oder einfach nur abzufragen. Daher müssen Data Engineers über gute Kenntnisse in der Datenbankverwaltung verfügen. Dazu gehört, dass man SQL (Structured Query Language), die grundlegende Sprache für die Interaktion mit Datenbanken, fließend beherrscht und sich mit einigen der gängigsten SQL-Dialekte auskennt, darunter MySQL, SQL Server und PostgreSQL. Neben relationalen Datenbanken müssen Data Engineers auch mit NoSQL-Datenbanken („Not only SQL“) vertraut sein, die sich immer mehr zu den bevorzugten Systemen für Big Data und Echtzeitanwendungen entwickeln. Obwohl die Zahl der NoSQL-Engines zunimmt, sollten Data Engineers daher zumindest die Unterschiede zwischen den NoSQL-Datenbanktypen und die Anwendungsfälle verstehen. Wenn ihr Datenbanken und REST-APIs im Griff habt, müsst ihr sie irgendwie bereitstellen. Hier kommen Container ins Spiel.

Containerisierung – Verpackung Ihrer Software

Bei der Containerisierung wird der Softwarecode mit den Betriebssystembibliotheken und Abhängigkeiten, die für die Ausführung des Codes erforderlich sind, zu einer einzigen leichtgewichtigen ausführbaren Datei – einem Container – zusammengefasst. Diese kann konsistent auf jeder Infrastruktur ausgeführt werden. Da Container portabler und ressourceneffizienter sind als virtuelle Maschinen (VMs), haben sie sich de facto zu den Recheneinheiten moderner Cloud-nativer Anwendungen entwickelt. Um besser zu verstehen, wie Container KI-Lösungen skalierbar machen, könnt ihr unser Whitepaper über Container lesen.

Für die Containerisierung von Anwendungen verwenden die meisten Entwickler Docker, ein Open-Source-Tool zum Erstellen von Images und Ausführen von Containern. Zum Verpacken von Code werden fast immer Befehlszeilentools wie das Docker-CLI (Command Line Interface) verwendet. Aber nicht nur Anwendungen oder REST-APIs können containerisiert werden. Data Engineers führen häufig Datenverarbeitungsaufgaben in Containern aus, um die Laufzeitumgebung zu stabilisieren. Solche Aufgaben müssen geordnet und geplant werden, und hier kommen Orchestrierungswerkzeuge ins Spiel.

Orchestrierung – Automatisierung der Datenverarbeitung

Eine der Hauptaufgaben von Data Engineers ist die Erstellung von Datenpipelines mit ETL-Technologien und Orchestrierungs-Frameworks. In diesem Abschnitt könnte man viele Technologien aufzählen, da die Zahl der Frameworks ständig steigt.

Data Engineers sollten einige der bekanntesten kennen oder mit ihnen vertraut sein – wie z.B. Apache Airflow, ein beliebtes Orchestrierungs-Framework für die Planung, Erstellung und Verfolgung von Datenpipelines.

Eine Instanz eines solchen Orchestrierungs-Frameworks selbst zu pflegen, kann recht mühsam sein. Wenn der Technologiestapel wächst, wird die Wartung oft zu einem Vollzeitjob. Um diese Belastung zu verringern, bieten Cloud-Anbieter fertige Lösungen an.

Die Cloud – ohne großen Wartungsaufwand in Produktion

Unter den vielen Cloud-Anbietern ist es sinnvoll, sich für einen der drei großen Anbieter zu entscheiden: Amazon Web Services (AWS), Google Cloud Platform (GCP) und Microsoft Azure. Alle bieten verschiedene Dienste an, um Standardaufgaben des Data Engineering zu lösen, wie z. B. die Aufnahme von Daten, die Planung und Orchestrierung von Datenverarbeitungsschritten, die sichere Speicherung von Daten und deren Bereitstellung für Geschäftsanwender und Datenwissenschaftler. Aufgrund der Fülle der Angebote ist es für Data Engineers sinnvoll, sich bei der Auswahl einer Lösung mit der Preisgestaltung des Anbieters vertraut zu machen.

Wenn ihr z.B. ein gutes Verständnis von Datenbanksystemen habt, sollte das Verständnis von Datenbanksystemen in der Cloud nicht allzu schwierig sein. Bestimmte Technologien wie Apache Spark auf Databricks können jedoch ohne Zugang zur Cloud schwer zu erkunden sein. In diesem Fall würde ich empfehlen, ein Konto bei der Cloud-Plattform eurer Wahl einzurichten und mit dem Experimentieren zu beginnen.

Hoher Aufwand, hohe Belohnung

Fassen wir noch einmal zusammen: Um ein Data Engineer zu werden, sollte man Folgendes lernen:

1. Eine Programmiersprache
2. Die Grundlagen von git und Versionskontrolle
3. Die UNIX-Befehlszeile
4. REST-APIs und Grundlagen von Netzwerkarchitekturen
5. Datenbanksysteme
6. Containerisierung
7. Die Cloud

Auch wenn dies nach viel Lernaufwand klingt, solltet ihr euch nicht entmutigen lassen. Praktisch alle der oben aufgeführten Fähigkeiten sind auf andere Rollen übertragbar, so dass das Erlernen dieser Fähigkeiten euch fast unabhängig von eurem genauen beruflichen Werdegang helfen wird. Wenn ihr wie ich einen Data Science Hintergrund habt, werden euch einige dieser Themen bereits vertraut sein. Ich persönlich finde Netzwerkarchitekturen am schwierigsten zu begreifen, da die Arbeit oft von IT-Fachleuten auf der Kundenseite erledigt wird.

Ihr fragt euch wahrscheinlich, wie ihr in die Praxis einsteigen könnt. Die Arbeit an eigenen Projekten wird euch helfen, die Grundlagen der meisten dieser Schritte zu erlernen. Zu den üblichen Data-Engineering-Projekten gehören die Einrichtung von Datenbanksystemen und die Orchestrierung von Aufträgen zur regelmäßigen Aktualisierung der Datenbank. Es gibt viele öffentlich zugängliche Datensätze auf kaggle und APIs, wie z.B. die coinbase API, aus denen ihr Daten für euer persönliches Projekt ziehen könnt. So könnt Ihr eure ersten Schritte zunächst lokal erarbeiten und das Projekt anschließend in die Cloud migrieren. Thomas Alcock Thomas Alcock Thomas Alcock

Bei statworx befassen wir uns intensiv damit, wie wir von großen Sprachmodellen (LLMs) die bestmöglichen Resultate erhalten. In diesem Blogbeitrag stelle ich fünf Ansätze vor, die sich sowohl in der Forschung als auch in unseren eigenen Experimenten mit LLMs bewährt haben. Während sich dieser Text auf das manuelle Design von Prompts zur Textgenerierung beschränkt, werden Bildgenerierung und automatisierte Promptsuche das Thema zukünftiger Beiträge sein.

Mega-Modelle läuten neues Paradigma ein

Die Ankunft des revolutionären Sprachmodells GPT-3 stellte nicht nur für das Forschungsfeld der Sprachmodellierung (NLP) einen Wendepunkt dar, sondern hat ganz nebenbei einen Paradigmenwechsel in der KI-Entwicklung eingeläutet: Prompt-Learning. Vor GPT-3 war der Standard das Fine-Tuning von mittelgroßen Sprachmodellen wie BERT, was dank erneutem Training mit eigenen Daten das vortrainierte Modell an den gewünschten Anwendungsfall anpassen sollte. Derartiges Fine-Tuning erfordert exemplarische Daten für die gewünschte Anwendung, sowie die rechnerischen Möglichkeiten das Modell zumindest teilweise neu zu trainieren.

Die neuen großen Sprachmodelle wie OpenAIs GPT-3 und BigSciences BLOOM hingegen wurden von ihren Entwicklerteams bereits mit derart großen Mengen an Ressourcen trainiert, dass diese Modelle ein neues Maß an Unabhängigkeit in ihrem Anwendungszweck erreicht haben: Diese LLMs benötigen nicht länger aufwändiges Fine-Tuning, um ihren spezifischen Zweck zu erlernen, sondern erzeugen bereits mithilfe von gezielter Instruktion („Prompt“) in natürlicher Sprache beeindruckende Resultate.

Wir befinden uns also inmitten einer Revolution in der KI-Entwicklung: Dank Prompt-Learning findet die Interaktion mit Modellen nicht länger über Code statt, sondern in natürlicher Sprache. Für die Demokratisierung der Sprachmodellierung bedeutet dies einen gigantischen Schritt vorwärts. Texte zu generieren oder neustens sogar Bilder zu erstellen, erfordert dadurch nicht mehr als rudimentäre Sprachkenntnisse. Allerdings heißt das nicht, dass damit auch überzeugende oder beeindruckende Resultate allen zugänglich sind. Hochwertige Outputs verlangen nach hochwertigen Inputs. Für uns Nutzer:innen bedeutet dies, dass die technische Planung in NLP nicht mehr der Modellarchitektur oder den Trainingsdaten gilt, sondern dem Design der Anweisungen, die Modelle in natürlicher Sprache erhalten. Willkommen im Zeitalter des Prompt-Engineerings.

Abbildung 1: Vom Prompt zur Prognose mit einem großen Sprachmodell

Prompts sind mehr als nur Textschnippsel

Templates erleichtern den häufigen Umgang mit Prompts

Da LLMs nicht auf einen spezifischen Anwendungsfall trainiert wurden, liegt es am Promptdesign dem Modell die genaue Aufgabenstellung zu bestimmen. Dazu dienen sogenannte „Prompt Templates“. Ein Template definiert die Struktur des Inputs, der an das Modell weitergereicht wird. Dadurch übernimmt das Template die Funktion des Fine-Tunings und legt den erwarteten Output des Modells für einen bestimmten Anwendungsfall fest. Am Beispiel einer einfachen Sentiment-Analyse könnte ein Prompt-Template so aussehen:

The expressed sentiment in text [X] is: [Z]

Das Modell sucht so nach einem Token z der, basierend auf den trainierten Parametern und dem Text in Position [X], die Wahrscheinlichkeit des maskierten Tokens an Position [Z] maximiert. Das Template legt so den gewünschten Kontext des zu lösenden Problems fest und definiert die Beziehung zwischen dem Input an Stelle [X] und dem zu vorhersagenden Output an Stelle [Z]. Der modulare Aufbau von Templates ermöglicht die systematische Verarbeitung einer Vielzahl von Texten für den erwünschten Anwendungsfall.

Abbildung 2: Prompt Templates definieren die Struktur eines Prompts.

Prompts benötigen nicht zwingend Beispiele

Das vorgestellte Template ist ein Beispiel eines sogenannten „, da ausschließlich eine Anweisung, ohne jegliche Demonstration mit Beispielen im Template, vorhanden ist. Ursprünglich wurden LLMs von den Entwickler:innen von GPT-3 als „Few-Shot Learners“ bezeichnet, also Modelle, deren Leistung mit einer Auswahl von gelösten Beispielen des Problems maximiert werden kann (Brown et al., 2020). Eine Folgestudie konnte aber zeigen, dass mit strategischem Promptdesign auch 0-Shot Prompts, ohne einer Vielzahl von Beispielen, vergleichbare Leistung erzielen können (Reynolds & McDonell, 2021). Da also auch in der Forschung mit unterschiedlichen Ansätzen gearbeitet wird, stellt der nächste Abschnitt 5 Strategien für effektives Design von Prompt Templates vor.

5 Strategien für effektives Promptdesign

Task Demonstration

Im herkömmlichen Few-Shot Setting wird das zu lösende Problem durch die Bereitstellung von mehreren Beispielen eingegrenzt. Die gelösten Beispielsfälle sollen dabei eine ähnliche Funktion einnehmen wie die zusätzlichen Trainingssamples während des Fine-Tuning Prozesses und somit den spezifischen Anwendungsfall des Modells definieren. Textübersetzung ist ein gängiges Beispiel für diese Strategie, die mit folgendem Prompt Template repräsentiert werden kann:

French: „Il pleut à Paris“

German: „Es regnet in Paris“

French: „Copenhague est la capitale du Danemark“

German: „Kopenhagen ist die Hauptstadt von Dänemark“

[…]

French: [X]
German: [Z]

Die gelösten Beispiele sind zwar gut dazu geeignet das Problemsetting zu definieren, können aber auch für Probleme sorgen. „Semantische Kontamination“ bezeichnet das Problem, dass die Inhalte der übersetzten Sätze als relevant für die Vorhersage interpretiert werden können. Beispiele im semantischen Kontext der Aufgabe produzieren bessere Resultate – und solche außerhalb des Kontexts können dazu führen, dass die Prognose Z inhaltlich „kontaminiert“ wird (Reynolds & McDonell, 2021). Verwendet man das obige Template für die Übersetzung komplexer Sachverhalte, so könnte das Modell in unklaren Fällen wohl den eingegebenen Satz als Aussage über eine europäische Großstadt interpretieren.

Task Specification

Jüngste Forschung zeigt, dass mit gutem Promptdesign auch der 0-Shot Ansatz kompetitive Resultate liefern kann. So wurde demonstriert, dass LLMs gar keine vorgelösten Beispiele benötigen, solange die Problemstellung im Prompt möglichst genau definiert wird (Reynolds & McDonell, 2021). Diese Spezifikation kann unterschiedlich Formen annehmen, ihr liegt aber immer den gleichen Gedanken zugrunde: So genau wie möglich zu beschreiben was gelöst werden soll, aber ohne zu demonstriere wie.

Ein einfaches Beispiel für den Übersetzungsfall wäre folgender Prompt:

Translate from French to German [X]: [Z]

Dies mag bereits funktionieren, die Forscher empfehlen aber den Prompt so deskriptiv wie möglich zu gestalten und auch explizit die Übersetzungsqualität zu nennen:

A French sentence is provided: [X]. The masterful French translator flawlessly translates the sentence to German: [Z]

Dies helfe dem Modell dabei die gewünschte Problemlösung im Raum der gelernten Aufgaben zu lokalisieren.

Abbildung 3: Ein klarer Aufgabenbeschrieb kann die Prognosegüte stark erhöhen.

Auch in Anwendungsfällen ausserhalb von Übersetzungen ist dies empfehlenswert. Ein Text lässt mit einem einfachen Befehl zusammenfassen:

Summarize the following text: [X]: [Z]

Mit konkreterem Prompt sind aber bessere Resultate zu erwarten:

Rephrase this sentence with easy words so a child understands it,
emphasize practical applications and examples: [X]: [Z]

Je genauer der Prompt, desto grösser die Kontrolle über den Output.

Prompts als Einschränkungen

Zu Ende gedacht bedeutet der Ansatz von Kontrolle des Modells schlicht die Einschränkung des Modellverhaltens durch sorgfältiges Promptdesign. Diese Perspektive ist nützlich, denn während dem Training lernen LLMs viele verschiedene Texte fortzuschreiben und können dadurch eine breite Auswahl an Problemen lösen. Mit dieser Designstrategie verändert sich das grundlegende Herangehen ans Promptdesign: vom Beschrieb der Problemstellung zum Ausschluss unerwünschter Resultate durch die Einschränkung des Modellverhaltens. Welcher Prompt führt zum gewünschten Resultat und ausschliesslich zum gewünschten Resultat? Folgender Prompt weist zwar auf eine Übersetzungsaufgabe hin, beinhaltet aber darüber hinaus keine Ansätze zur Verhinderung, dass der Satz durch das Modell einfach zu einer Geschichte fortgesetzt wird.

Translate French to German Il pleut à Paris

Ein Ansatz diesen Prompt zu verbessern ist der Einsatz von sowohl semantischen als auch syntaktischen Mitteln:

Translate this French sentence to German: “Il pleut à Paris.”

Durch die Nutzung von syntaktischen Elementen wie dem Doppelpunkt und den Anführungszeichen wird klar gemacht, wo der zu übersetzende Satz beginnt und endet. Auch drückt die Spezifikation durch sentence aus, dass es nur um einen einzelnen Satz geht. Diese Mittel verringern die Wahrscheinlichkeit, dass dieser Prompt missverstanden und nicht als Übersetzungsproblem behandelt wird.

Nutzung von “memetic Proxies”

Diese Strategie kann genutzt werden, um die Informationsdichte in einem Prompt zu erhöhen und lange Beschreibungen durch kulturell verstandenen Kontext zu vermeiden. Memetic Proxies können in Taskbeschreibungen genutzt werden und nutzen implizit verständliche Situationen oder Personen anstelle von ausführlichen Anweisungen:

A primary school teacher rephrases the following sentence: [X]: [Z]

Dieser Prompt ist weniger deskriptiv als das vorherige Beispiel zur Umformulierung in einfachen Worten. Allerdings besitzt die beschriebene Situation eine viel höhere Dichte an Informationen: Die Nennung eines impliziert bereits, dass das Resultat für Kinder verständlich sein soll und erhöht dadurch hoffentlich auch die Wahrscheinlichkeit von praktischen Beispielen im Output. Ähnlich können Prompts fiktive Gespräche mit bekannten Persönlichkeiten beschreiben, so dass der Output deren Weltbild oder Sprechweise widerspiegelt:

In this conversation, Yoda responds to the following question: [X]

Yoda: [Z]

Dieser Ansatz hilft dabei einen Prompt durch implizit verstandenen Kontext kurz zu halten und die Informationsdichte im Prompt zu erhöhen.  Memetic Proxies finden auch im Promptdesign für andere Modalitäten Verwendung. Bei Modellen zur Bildgenerierung wie DALL-e 2 führt das Suffix „Trending on Artstation“ häufig zu Ergebnissen von höherer Qualität, obwohl semantisch eigentlich keine Aussagen über das darzustellende Bild gemacht werden.

Metaprompting

Als Metaprompting beschreibt das Forscherteam einer Studie den Ansatz Prompts durch Anweisungen anzureichern, die auf die jeweilige Aufgabe zugeschnitten sind. Dies beschreiben sie als Weg ein Modell durch klarere Anweisungen einzuschränken, sodass die gestellte Aufgabe besser gelöst werden kann (Reynolds & McDonell, 2021). Folgendes Beispiel kann dabei helfen mathematische Probleme zuverlässiger zu lösen und den Argumentationsweg nachvollziehbar zu machen:

[X]. Let us solve this problem step-by-step: [Z]

Ähnlich lassen sich Multiple Choice Fragen mit Metaprompts anreichern, sodass das Modell im Output auch tatsächlich eine Option wählt, anstatt die Liste fortzusetzen:

[X] in order to solve this problem, let us analyze each option and choose the best: [Z]

Metaprompts stellen somit ein weiteres Mittel dar Modellverhalten und Resultate einzuschränken.

Abbildung 4: Mithilfe von Metaprompts lassen sich Vorgehensweisen zur Problemlösung festlegen.

Ausblick

Prompt Learning ist ein noch sehr junges Paradigma und das damit eng verbundene Prompt Engineering befindet sich noch in den Kinderschuhen. Allerdings wird die Wichtigkeit von fundierten Fähigkeiten zum Schreiben von Prompts zweifellos nur noch zunehmen. Nicht nur Sprachmodelle wie GPT-3, sondern auch neuste Modelle zur Bildgenerierung verlangen von ihren User:innen solide Kenntnisse im Designen von Prompts, um gute Ergebnisse zu kreieren. Die vorgestellten Strategien sind sowohl in der Forschung als auch in der Praxis erprobte Ansätze zum systematischen Schreiben von Prompts, die dabei helfen, bessere Resultate von großen Sprachmodellen zu erhalten.

In einem zukünftigen Blogbeitrag nutzen wir diese Erfahrungen mit Textgenerierung, um Best Practices für eine weitere Kategorie generativer Modelle zu erschliessen: modernste Diffusionsmodelle zur Bildgenerierung, wie DALL-e 2, Midjourney und Stable Diffusion.

 

Quellen

Brown, Tom B. et al. 2020. “Language Models Are Few-Shot Learners.” arXiv:2005.14165 [cs]. http://arxiv.org/abs/2005.14165 (March 16, 2022).

Reynolds, Laria, and Kyle McDonell. 2021. “Prompt Programming for Large Language Models: Beyond the Few-Shot Paradigm.” http://arxiv.org/abs/2102.07350 (July 1, 2022).

Oliver Guggenbühl Oliver Guggenbühl Oliver Guggenbühl Oliver Guggenbühl

Überwachung von Data-Science-Workflows

Die Zeiten, in denen ein Data Science-Projekt nur aus lose gekoppelten Notebooks für die Datenverarbeitung und das Modelltraining bestand, die die Date Scientists gelegentlich auf ihren Laptops ausführten, sind längst vorbei. Mit zunehmender Reife haben sich die Projekte zu großen Softwareprojekten mit mehreren Beteiligten und Abhängigkeiten sowie unterschiedlichen Modulen mit zahlreichen Klassen und Funktionen entwickelt. Der Data-Science-Workflow, der in der Regel mit der Datenvorverarbeitung, dem Feature-Engineering, dem Modelltraining, dem Tuning, der Evaluierung und schließlich der Inferenz beginnt und als ML-Pipeline bezeichnet wird, wird modularisiert. Diese Modularisierung macht den Prozess skalierbarer und automatisierbar, ergo geeignet für die Ausführung in Container-Orchestrierungssystemen oder in der Cloud-Infrastruktur. Die Extraktion wertvoller modell- oder datenbezogener KPIs kann, wenn sie manuell erfolgt, eine arbeitsintensive Aufgabe sein, umso mehr, wenn sie mit zunehmenden und/oder automatisierten Wiederholungen verbunden ist. Diese Informationen sind wichtig für den Vergleich verschiedener Modelle und die Beobachtung von Trends wie «Distribution-Shift» in den Trainingsdaten. Sie können auch dazu verwendet werden, ungewöhnliche Werte zu erkennen, von unausgewogenen Klassen bis hin zur Löschung von Ausreißern – was auch immer als notwendig erachtet wird, um die Robustheit eines Modells zu gewährleisten. Bibliotheken wie MLFlow können verwendet werden, um all diese Arten von Metriken zu speichern. Außerdem hängt die Operationalisierung von ML-Pipelines stark von der Verfolgung laufbezogener Informationen zur effizienten Fehlerbehebung sowie zur Aufrechterhaltung oder Verbesserung des Ressourcenverbrauchs der Pipeline ab.

Dies gilt nicht nur für die Welt von Data Science. Die heutigen Microservice-basierten Architekturen tragen ebenfalls dazu bei, dass die Wartung und Verwaltung von bereitgestelltem Code eine einheitliche Überwachung erfordert. Dies kann die von einem DevOps-Team benötigten Betriebs- und Wartungsstunden aufgrund eines ganzheitlicheren Verständnisses der beteiligten Prozesse drastisch reduzieren und gleichzeitig fehlerbedingte Ausfallzeiten verringern.

Es ist wichtig zu verstehen, wie verschiedene Formen der Überwachung darauf abzielen, die oben genannten Implikationen anzugehen, und wie modell- und datenbezogene Metriken ebenfalls zu diesem Ziel beitragen können. Zwar hat sich MLFlow als Industriestandard für die Überwachung von ML-bezogenen Metriken etabliert, doch kann auch die Überwachung dieser Metriken zusammen mit allen betrieblichen Informationen interessant sein.

Protokolle vs. Metriken

Protokolle liefern eine ereignisbasierte Momentaufnahme – Metriken geben einen Überblick aus der Vogelperspektive

Ein Protokoll ist eine zu einem bestimmten Zeitpunkt geschriebene Aufzeichnung (z. B. stdout/stderr) eines Ereignisses, das diskontinuierlich und in nicht vordefinierten Intervallen auftritt. Je nach Anwendung enthalten die Protokolle Informationen wie Zeitstempel, Auslöser, Name, Beschreibung und/oder Ergebnis des Ereignisses. Bei den Ereignissen kann es sich um einfache Anfragen oder Benutzeranmeldungen handeln, die der Entwickler des zugrunde liegenden Codes als wichtig erachtet hat. Wenn Sie sich bei diesem Prozess an bewährte Verfahren halten, können Sie sich eine Menge Ärger und Zeit bei der Einrichtung nachgelagerter Überwachungswerkzeuge sparen. Die Verwendung dedizierter Protokollbibliotheken und das Schreiben aussagekräftiger Protokollnachrichten sind hier von Vorteil.

INFO[2021-01-06T17:44:13.368024402-08:00] starting *secrets.YamlSecrets               
INFO[2021-01-06T17:44:13.368679356-08:00] starting *config.YamlConfig                 
INFO[2021-01-06T17:44:13.369046236-08:00] starting *s3.DefaultService                 
INFO[2021-01-06T17:44:13.369518352-08:00] starting *lambda.DefaultService             
ERROR[2021-01-06T17:44:13.369694698-08:00] http server error   error="listen tcp 127.0.0.1:6060: bind: address already in use"

Abb. 1: Ereignisprotokolle in Textform

Obwohl die Datenmenge eines einzelnen Protokolls vernachlässigbar ist, können Protokollströme schnell exponentiell ansteigen. Dies führt dazu, dass die Speicherung jedes einzelnen Protokolls nicht gut skalierbar ist, insbesondere in Form von halbstrukturierten Textdaten. Für Debugging oder Auditing kann es jedoch unvermeidlich sein, Protokolle in unveränderter Form zu speichern. Archivspeicherlösungen oder Aufbewahrungsfristen können hier helfen.

In anderen Fällen können das Parsen und Extrahieren von Protokollen in andere Formate, wie z. B. Schlüssel-Wert-Paare, diesen Einschränkungen entgegenwirken. Auf diese Weise kann ein Großteil der Ereignisinformationen erhalten bleiben, während der Speicherbedarf deutlich geringer ist.

{
  time: "2021-01-06T17:44:13-08:00",
  mode: "reader",
  debug_http_error: "listen tcp 127.0.0.1:6061: bind: address already in use"
  servicePort: 8089,
  duration_ms: 180262
}

Abb. 2: Strukturierte Ereignisprotokolle

Eine andere Form der Verringerung dieses Fußabdrucks kann durch Stichprobenmethoden erfolgen, wobei Metriken die prominentesten Vertreter sind.

Eine Metrik ist ein numerisches Maß für ein bestimmtes Ziel (ein bestimmtes Ereignis), das gleichmäßig über Zeitintervalle verteilt ist. Mathematische Aggregationen wie Summen oder Durchschnittswerte sind gängige Transformationen, die solche Metriken datenmäßig relativ klein halten.

{
   time: "2022-01-06T17:44:13-08:00",
   Duration_ms: 60,
   sum_requests: 500,
   sum_hits_endpoint_1: 250,
   sum_hits_endpoint_2: 117,
   avg_duration: 113,
 }

Abb. 3: Metriken

Metriken eignen sich daher gut für die schrittweise Verringerung der Datenauflösung auf breitere Frequenzen wie tägliche, wöchentliche oder sogar längere Analysezeiträume. Außerdem lassen sich Metriken in der Regel besser über mehrere Anwendungen hinweg vereinheitlichen, da sie im Vergleich zu rohen Protokollnachrichten stark strukturierte Daten enthalten. Dies verringert zwar die zuvor genannten Probleme, geht aber auf Kosten der Granularität. Daher eignen sich Metriken perfekt für hochfrequente Ereignisse, bei denen die Informationen zu einem einzelnen Ereignis weniger wichtig sind. Die Überwachung von Rechenressourcen ist ein Beispiel dafür. Beide Ansätze haben ihre Berechtigung in jeder Überwachungskonfiguration, da die verschiedenen Anwendungsfälle zu den unterschiedlichen Zielen passen. Anhand eines konkreten Beispiels aus einem kleinen Unternehmen lassen sich die Hauptunterschiede verdeutlichen:

Der Gesamtsaldo eines Bankkontos kann im Laufe der Zeit aufgrund von Abhebungen und Einzahlungen (die zu jedem Zeitpunkt erfolgen können) schwanken. Wenn man nur daran interessiert ist, dass sich Geld auf dem Konto befindet, sollte es ausreichen, eine aggregierte Metrik regelmäßig zu verfolgen. Interessiert man sich jedoch für den Gesamtzufluss im Zusammenhang mit einem bestimmten Kunden, ist die Protokollierung jeder Transaktion unumgänglich.

Architektur und Tool-Stack

In den meisten modernen Cloud-Stacks, wie z. B. Azure Appservice, wird die Protokollierung der Infrastruktur und der Anfrageseite mit dem Dienst selbst ausgeliefert. Mit zunehmendem Volumen kann dies jedoch kostspielig werden. Die Definition der Anwendungsfälle, das Verständnis der Bereitstellungsumgebung und die Abstimmung mit der Protokollierungsarchitektur sind Teil der Aufgaben von DevOps-Teams.

Aus der Sicht eines Entwicklers gibt es eine Vielzahl von Open-Source-Tools, die wertvolle Überwachungslösungen liefern können, die nur einen gewissen Aufwand für die Orchestrierung erfordern. Schlankere Setups können nur aus einem Backend-Server wie einer Zeitreihendatenbank und einem Tool zur Visualisierung bestehen. Komplexere Systeme können mehrere Protokollierungssysteme mit mehreren dedizierten Protokollversendern, Alarmmanagern und anderen Zwischenkomponenten umfassen (siehe Abbildung). Einige dieser Werkzeuge können notwendig sein, um Protokolle überhaupt erst zugänglich zu machen oder um verschiedene Protokollströme zu vereinheitlichen. Das Verständnis der Funktionsweise und des Leistungsbereichs der einzelnen Komponenten ist daher von zentraler Bedeutung.

Abb. 4: Überwachungsablauf von Anwendungen, die in einem Kubernetes-Cluster bereitgestellt werden (verändert, aus https://logz.io/blog/fluentd-vs-fluent-bit/)

Datenbank & Entwurf

Protokolle, zumindest wenn sie nach den bewährten Verfahren mit einem Zeitstempel versehen sind, und Metriken sind in der Regel Zeitreihendaten, die in einer Zeitreihendatenbank gespeichert werden können. In Fällen, in denen Textprotokolle unverändert gespeichert werden, verwenden andere Architekturen dokumentenorientierte Speichertypen mit einer leistungsstarken Abfrage-Engine (wie ElasticSearch) als Ergänzung. Neben den speicherbezogenen Unterschieden wird die Backend-Infrastruktur in zwei verschiedene Paradigmen unterteilt: Push und Pull. Diese Paradigmen befassen sich mit der Frage, wer für die anfängliche Aufnahme der Daten verantwortlich ist (Client oder Backend).

Die Entscheidung für das eine oder andere Paradigma hängt vom Anwendungsfall oder der Art der Informationen ab, die persistiert werden sollen. Push-Dienste eignen sich beispielsweise gut für die Ereignisprotokollierung, bei der die Informationen zu einem einzelnen Ereignis wichtig sind. Allerdings sind sie dadurch auch anfälliger für Überlastung durch zu viele Anfragen, was die Robustheit beeinträchtigt. Andererseits sind Pull-Systeme perfekt geeignet, um periodische Informationen abzurufen, die mit der Zusammensetzung von Metriken übereinstimmen.

Dashboard & Warnmeldungen

Um die Daten besser zu verstehen und eventuelle Unregelmäßigkeiten zu erkennen, sind Dashboards sehr nützlich. Überwachungssysteme eignen sich vor allem für einfache, „weniger komplexe“ Abfragen, da die Leistung zählt. Der Zweck dieser Tools ist auf die zu bearbeitenden Probleme spezialisiert, und sie bieten einen begrenzteren Bestand als einige der bekannten Software wie PowerBI. Das macht sie jedoch nicht weniger leistungsfähig in ihrem Einsatzbereich. Tools wie Grafana, das sich hervorragend für den Umgang mit protokollbasierten Metrikdaten eignet, kann sich mit verschiedenen Datenbank-Backends verbinden und maßgeschneiderte Lösungen aus mehreren Quellen erstellen. Tools wie Kibana, die ihre Stärken bei textbasierten Protokoll-Analysen haben, bieten Anwendern ein umfangreiches Abfrage-Toolkit für die Ursachenanalyse und Diagnose. Es ist erwähnenswert, dass beide Tools ihren Anwendungsbereich erweitern, um beide Welten zu unterstützen.

Abb. 5 Grafana Beispiel Dashboard (https://grafana.com/grafana/)

Während sich die Überwachung hervorragend eignet, um Unregelmäßigkeiten zu erkennen (proaktiv) und fehlerhafte Systeme gezielt zu analysieren (reaktiv), können DevOps-Teams sofort handeln, wenn sie über Anwendungsausfälle informiert werden. Alert-Manager bieten die Möglichkeit, nach Ereignissen zu suchen und Alarme über alle möglichen Kommunikationskanäle auszulösen, z. B. über Messaging, Incident-Management-Programme oder per E-Mail.

Scraper, Aggregatoren & Verlader

Da nicht jeder Microservice einen Endpunkt zur Verfügung stellt, an dem Protokolle und protokollbasierte Metriken bewertet oder extrahiert werden können – denken Sie an die Unterschiede zwischen Push und Pull -, müssen Vermittler einspringen. Dienste wie Scraper extrahieren und formatieren Protokolle aus verschiedenen Quellen, Aggregatoren führen eine Art von kombinierten Aktionen (Generierung von Metriken) durch und Shipper können als Push-Dienst für Push-basierte Backends fungieren. Fluentd ist ein perfekter Kandidat, der all die genannten Fähigkeiten in sich vereint und dennoch einen kleinen Fußabdruck beibehält.

End-to-End-Überwachung

Es gibt kostenpflichtige Dienste, die versuchen, ein ganzheitliches System für jede Art von Anwendung, Architektur und unabhängig von Cloud-Anbietern bereitzustellen, was für DevOps-Teams ein entscheidender Vorteil sein kann. Aber auch schlankere Setups können kosteneffiziente und zuverlässige Arbeit leisten.

Wenn man die Notwendigkeit ausschließt, Volltextprotokolle zu sammeln, können viele Standardanwendungsfälle mit einer Zeitreihendatenbank als Backend realisiert werden. InfluxDB ist dafür gut geeignet und einfach aufzusetzen, mit ausgereifter Integrationsfähigkeit in Grafana. Grafana als Dashboard-Tool lässt sich gut mit dem Alter Manager Service von Prometheus kombinieren. Als Vermittler ist fluentd perfekt geeignet, um die textuellen Protokolle zu extrahieren und die notwendigen Transformationen durchzuführen. Da InfluxDB push-basiert ist, kümmert sich fluentd auch darum, dass die Daten in InfluxDB gelangen.

Aufbauend auf diesen Tools deckt die Beispielinfrastruktur alles ab, von der Data Science Pipeline bis zu den später eingesetzten Modell-APIs, mit Dashboards für jeden Anwendungsfall. Bevor ein neuer Trainingslauf für die Produktion freigegeben wird, bieten die eingangs erwähnten ML-Metriken einen guten Einstiegspunkt, um die Legitimität des Modells zu überprüfen. Einfache Nutzerstatistiken, wie die Gesamtzahl der Anfragen und die Anzahl der einzelnen Anfragen, geben einen guten Überblick über die Nutzung des Modells, sobald es eingesetzt wird. Durch die Verfolgung der Antwortzeiten, z. B. eines API-Aufrufs, lassen sich Engpässe leicht aufdecken.

Auf der Ressourcenebene werden die APIs zusammen mit jedem Pipelineschritt überwacht, um Unregelmäßigkeiten wie plötzliche Spitzen im Speicherverbrauch zu beobachten. Durch die Verfolgung der Ressourcen im Zeitverlauf kann auch festgestellt werden, ob die verwendeten VM-Typen über- oder unterausgelastet sind. Durch die Optimierung dieser Metriken lassen sich möglicherweise unnötige Kosten einsparen. Schließlich sollten vordefinierte Fehlerereignisse, wie eine nicht erreichbare API oder fehlgeschlagene Trainingsläufe, einen Alarm auslösen und eine E-Mail versenden.

Abb. 6: Eingesetzte Infrastruktur mit Protokoll-Streams und Monitoring-Stack. 

Die gesamte Architektur, bestehend aus der Überwachungsinfrastruktur, der Data Science Pipeline und den bereitgestellten APIs, kann in einem (verwalteten) Kubernetes-Cluster ausgeführt werden. Aus einer DevOps-Perspektive ist die Kenntnis von Kubernetes bereits die halbe Miete. Dieser Open-Source-Stack kann nach oben und unten skaliert werden und ist nicht an ein kostenpflichtiges Abonnementmodell gebunden, was große Flexibilität und Kosteneffizienz bietet. Außerdem ist das Onboarding neuer Protokoll-Streams, bereitgestellter Anwendungen oder mehrerer Pipelines mühelos möglich. Sogar einzelne Frameworks können ausgetauscht werden. Wenn zum Beispiel Grafana nicht mehr geeignet ist, verwenden Sie einfach ein anderes Visualisierungstool, das sich mit dem Backend integrieren lässt und den Anforderungen des Anwendungsfalls entspricht.

Fazit

Nicht erst seit Anwendungen modularisiert und in die Cloud verlagert wurden, sind Protokollierung und Monitoring zentrale Bestandteile moderner Infrastrukturen. Dennoch verschlimmern sie sicherlich die Probleme, die entstehen, wenn sie nicht richtig eingerichtet sind. Neben der zunehmenden Operationalisierung des ML-Workflows wächst auch die Notwendigkeit für Unternehmen, gut durchdachte Überwachungslösungen einzurichten, um Modelle, Daten und alles um sie herum im Blick zu behalten.

Es gibt zwar dedizierte Plattformen, die für diese Herausforderungen entwickelt wurden, aber die charmante Idee hinter der vorgestellten Infrastruktur ist, dass sie nur aus einem einzigen Einstiegspunkt für Data Science-, MLOps- und Devops-Teams besteht und in hohem Maße erweiterbar ist. Benedikt Müller Benedikt Müller

Im Trend: Künstliche Verbesserung von Gesichtsbildern

Was trägt künstliche Intelligenz dazu bei?

In den letzten Jahren sind Filter in den sozialen Medien extrem beliebt geworden. Mit diesen Filtern kann jede Person ihr Gesicht und die Umgebung auf unterschiedlichste Weise anpassen, was zu unterhaltsamen Ergebnissen führt. Oftmals verstärken die Filter aber auch Gesichtszüge, die einem bestimmten Schönheitsstandard zu entsprechen scheinen. Als KI-Expert:innen haben wir uns gefragt, was wir mit unseren Tools im Bereich der Gesichtsdarstellung erreichen können. Ein Thema, das unser Interesse geweckt hat, ist die Darstellung von Geschlechtern. Wir wurden neugierig: Wie stellt die KI bei der Erstellung dieser Bilder Geschlechterunterschiede dar? Und darüber hinaus: Können wir geschlechtsneutrale Versionen von bestehenden Gesichtern erzeugen?

Verwendung von StyleGAN auf bestehenden Bildern

Als wir darüber nachdachten, welche vorhandenen Bilder wir untersuchen wollten, haben wir uns überlegt: Wie würden unsere eigenen Gesichter bearbeitet aussehen? Außerdem beschlossen wir, auch mehrere Prominente als Input zu verwenden – wäre es nicht faszinierend, weltberühmte Gesichter dabei zu beobachten, wie sie sich in verschiedene Geschlechter verwandeln?

Gegenwärtig stehen textbasierte Bilderzeugungsmodelle wie DALL-E häufig im Mittelpunkt des öffentlichen Diskurses. Die KI-gesteuerte Erstellung fotorealistischer Gesichtsbilder ist jedoch schon seit langem ein Forschungsschwerpunkt, da es offensichtlich eine Herausforderung ist, natürlich aussehende Bilder von Gesichtern zu erzeugen. Auf der Suche nach geeigneten KI-Modellen für unsere Idee haben wir uns für die StyleGAN-Architekturen entschieden, die für die Erzeugung realistischer Gesichtsbilder bekannt sind.

Anpassung von Gesichtsmerkmalen mit StyleGAN

Ein entscheidender Aspekt der Architektur dieser KI ist die Verwendung eines so genannten latenten Raums, aus dem wir die Eingaben des neuronalen Netzes auswählen. Du kannst dir diesen latenten Raum wie eine Landkarte vorstellen, auf der jedes mögliche generierte Gesicht eine bestimmte Koordinate hat. Normalerweise würden wir einfach einen Dartpfeil auf diese Karte werfen und uns darüber freuen, dass die KI ein realistisches Bild erzeugt. Aber wie sich herausstellt, erlaubt uns dieser latente Raum, noch weitere Aspekte der Erzeugung künstlicher Gesichter zu untersuchen. Wenn Du dich von der Position eines Gesichts auf dieser Karte zur Position eines anderen Gesichts bewegst, kannst Du Mischungen der beiden Gesichter erzeugen. Und wenn Du dich in eine zufällige Richtung bewegst, wirst Du auch zufällige Veränderungen im generierten Bild sehen.
Dies macht die StyleGAN-Architektur zu einem vielversprechenden Ansatz für die Erforschung der Geschlechterdarstellung in der KI.

Können wir eine geschlechtsspezifische Richtung isolieren?

Gibt es also Wege, die es uns erlauben, bestimmte Aspekte des erzeugten Bildes zu verändern? Könnte man sich einer geschlechtsneutralen Darstellung eines Gesichts auf diese Weise nähern? In früheren Arbeiten wurden semantisch interessante Richtungen gefunden, die zu faszinierenden Ergebnissen führten. Eine dieser Richtungen kann ein generiertes Gesichtsbild so verändern, dass es ein weiblicheres oder männlicheres Aussehen erhält. Auf diese Weise können wir die Geschlechterdarstellung in Bildern untersuchen.

Der Ansatz, den wir für diesen Artikel gewählt haben, bestand darin, mehrere Bilder zu erstellen, indem wir kleine Schritte in die Richtung des jeweiligen Geschlechts machten. Auf diese Weise können wir verschiedene Versionen der Gesichter vergleichen, und die Leser:innen können zum Beispiel entscheiden, welches Bild einem geschlechtsneutralen Gesicht am nächsten kommt. Außerdem können wir so die Veränderungen genauer untersuchen und unerwünschte Merkmale in den bearbeiteten Versionen ausfindig machen.

Wir stellen der KI unsere eigenen Gesichter vor

Die beschriebene Methode kann verwendet werden, um jedes von der KI erzeugte Gesicht in eine weiblichere oder männlichere Version zu verändern. Es bleibt jedoch eine entscheidende Herausforderung: Da wir unsere eigenen Bilder als Ausgangspunkt verwenden möchten, müssen wir in der Lage sein, die latente Koordinate (in unserer Analogie den richtigen Ort auf der Landkarte) für ein gegebenes Gesichtsbild zu finden. Das hört sich zunächst einfach an, aber die verwendete StyleGAN-Architektur erlaubt uns nur den Weg in eine Richtung, nämlich von der latenten Koordinate zum generierten Bild, nicht jedoch den weg zurück. Glücklicherweise haben sich bereits Forschende mit genau diesem Problem beschäftigt. Unser Ansatz stützt sich daher stark auf das Python-Notebook, das hier zu finden ist. Die Forschenden haben eine weitere „Encoder“-KI entwickelt, die ein Gesichtsbild als Eingabe erhält und die entsprechende Koordinate im latenten Raum findet.

Somit haben wir endlich alle Teile, die wir brauchen, um unser Ziel zu erreichen: die Erforschung verschiedener Geschlechterdarstellungen innerhalb einer KI. In den Fotosequenzen unten ist das mittlere Bild jeweils das ursprüngliche Eingabebild. Auf der linken Seite erscheinen die generierten Gesichter eher weiblich, auf der rechten Seite eher männlich. Ohne weitere Umschweife präsentieren wir die von der KI generierten Bilder unseres Experiments.

Ergebnisse: Fotoserie von weiblich zu männlich

Unbeabsichtigter Bias

Nachdem wir die entsprechenden Bilder im latenten Raum gefunden hatten, erzeugten wir künstliche Versionen der Gesichter. Wir haben sie dann auf Grundlage der gewählten Geschlechterrichtung verändert und so „feminisierte“ und „maskulinisierte“ Gesichter erzeugt. Die Ergebnisse zeigen ein unerwartetes Verhalten der KI: Sie scheint klassische Geschlechterstereotypen nachzubilden.

Breites Lächeln vs. dicke Augenbrauen

Sobald wir ein Bild so bearbeitet haben, dass es weiblicher aussieht, sehen wir allmählich einen sich öffnenden Mund mit einem stärkeren Lächeln und umgekehrt. Zudem werden die Augen in der weiblichen Richtung größer und weiter geöffnet. Die Beispiele von Drake und Kim Kardashian veranschaulichen eine sichtbare Veränderung des Hauttons von dunkler zu heller, wenn man sich entlang der Bildreihe von feminin zu maskulin bewegt. Die gewählte Geschlechterrichtung scheint die Locken in der weiblichen Richtung (im Gegensatz zur männlichen Richtung) zu entfernen, wie die Beispiele von Marylin Monroe und der Co-Autorin dieses Artikels, Isabel Hermes, zeigen.

Wir haben uns auch gefragt, ob eine drastischere Haarverlängerung in Drakes weiblicher Richtung eintreten würde, wenn wir seine Fotoserie nach links erweitern würden. Betrachtet man die allgemeinen Extreme, so sind die Augenbrauen auf der weiblichen Seite ausgedünnt und gewölbt und auf der männlichen Seite gerader und dicker. Augen- und Lippen-Make-up nehmen bei Gesichtern, die sich in die weibliche Richtung bewegen, stark zu, wodurch der Bereich um die Augen dunkler wird und die Augenbrauen dünner werden. Dies könnte der Grund dafür sein, dass wir die von uns erstellten männlichen Versionen als natürlicher empfunden haben als die weiblichen Versionen.

Abschließend möchten wir dich auffordern, die obige Fotoserie genau zu betrachten. Versuche zu entscheiden, welches Bild Du als geschlechtsneutral empfindest, d. h. als ebenso männlich wie weiblich. Warum hast Du dich für dieses Bild entschieden? Hat eines der oben beschriebenen stereotypen Merkmale Deine Wahrnehmung beeinflusst?
Eine Frage, die sich bei Bildserien wie diesen natürlich stellt, ist, ob die Gefahr besteht, dass die KI gängige Geschlechterstereotypen verstärkt.

Ist die KI schuld an der Rekonstruktion von Stereotypen?

Angesichts der Tatsache, dass die angepassten Bilder bestimmte geschlechtsspezifische Stereotypen wiedergeben, wie z. B. ein ausgeprägteres Lächeln bei weiblichen Bildern, könnte eine mögliche Schlussfolgerung sein, dass der Trainingsdatensatz der KI einen Bias aufgewiesen hat. Und in der Tat wurden für das Training des zugrunde liegenden StyleGAN Bilddaten von Flickr verwendet, die die Verzerrungen von der Website übernehmen. Das Hauptziel dieses Trainings war es jedoch, realistische Bilder von Gesichtern zu erstellen. Und obwohl die Ergebnisse vielleicht nicht immer so aussehen, wie wir es erwarten oder wünschen, würden wir behaupten, dass die KI genau das in allen unseren Tests erreicht hat.

Um die Bilder zu verändern, haben wir jedoch die zuvor erwähnte latente Richtung verwendet. Im Allgemeinen ändern diese latenten Richtungen selten nur einen einzigen Aspekt des erzeugten Bildes. Stattdessen werden, wie beim Bewegen in eine zufällige Richtung auf unserer latenten Landkarte, normalerweise viele Elemente des erzeugten Gesichts gleichzeitig verändert. Die Identifizierung einer Richtung, die nur einen einzigen Aspekt eines generierten Bildes verändert, ist alles andere als trivial. Für unser Experiment wurde die gewählte Richtung in erster Linie zu Forschungszwecken erstellt, ohne die genannten Verzerrungen zu berücksichtigen. Sie kann daher neben den beabsichtigten Veränderungen auch unerwünschte Artefakte in die Bilder einbringen. Dennoch kann angenommen werden, dass eine latente Richtung existiert, die es uns ermöglicht, das Geschlecht eines vom StyleGAN erzeugten Gesichts zu verändern, ohne andere Gesichtsmerkmale zu beeinträchtigen.

Insgesamt verwenden die Implementierungen, auf denen wir aufbauen, unterschiedliche KI und Datensätze, und das komplexe Zusammenspiel dieser Systeme erlaubt es uns daher nicht, die KI als einzige Ursache für diese Probleme zu identifizieren. Nichtsdestotrotz legen unsere Beobachtungen nahe, dass es von größter Wichtigkeit ist, bei der Erstellung von Datensätzen die nötige Sorgfalt walten zu lassen, um die Repräsentation verschiedener ethnischer Hintergründe sicherzustellen und Verzerrungen zu vermeiden.

Unbewusste Voreingenommenheit: Blick auf uns selbst

Eine Studie von Richard Russel befasst sich mit der menschlichen Wahrnehmung des Geschlechts in Gesichtern. Welchem Geschlecht würdest Du die beiden Bilder oben intuitiv zuordnen? Es zeigt sich, dass die meisten Menschen die linke Person als männlich und die rechte Person als weiblich wahrnehmen. Schau noch einmal hin. Was unterscheidet die Gesichter? Es gibt keinen Unterschied in der Gesichtsstruktur: Nur die dunkleren Augen- und Mundpartien unterscheiden sich. So wird deutlich, dass ein erhöhter Kontrast ausreicht, um unsere Wahrnehmung zu beeinflussen. Nehmen wir an, unsere Meinung über das Geschlecht kann durch das Auftragen von „Kosmetika“ auf ein Gesicht beeinflusst werden. In diesem Fall müssten wir unser menschliches Verständnis von Geschlechterdarstellungen in Frage stellen und uns damit befassen, ob sie nicht einfach das Produkt unserer lebenslangen Exposition gegenüber stereotypen Bildern sind. Der Studienautor bezeichnet dies als „Illusion des Geschlechts“.
Diese Verzerrung bezieht sich auf die Auswahl der latenten „Geschlechts“-Dimension: Um die latente Dimension zu finden, die das wahrgenommene Geschlecht eines Gesichts verändert, wurden die von StyleGAN generierten Bilder nach ihrem Aussehen in Gruppen eingeteilt. Obwohl dies auf der Grundlage einer anderen KI implementiert wurde, könnte sich die menschliche Voreingenommenheit bei der Geschlechterwahrnehmung durchaus auf diesen Prozess ausgewirkt haben und zu den oben dargestellten Bildreihen durchgesickert sein.

Schluss

Die Geschlechtertrennung überwinden mit StyleGANs

Auch wenn ein StyleGAN an und für sich keine geschlechtsspezifischen Vorurteile verstärkt, so sind Menschen doch unbewusst mit Geschlechterstereotypen behaftet. Geschlechtsspezifische Vorurteile beschränken sich nicht nur auf Bilder – Forscher:innen fanden die Allgegenwart weiblicher Sprachassistenten Grund genug, einen neuen Sprachassistenten zu entwickeln, der weder männlich noch weiblich ist: GenderLess Voice.

Ein Beispiel für einen neueren gesellschaftlichen Wandel ist die Debatte über das Geschlecht, das nicht mehr binär, sondern als Spektrum dargestellt werden kann. Die Idee ist, dass es ein biologisches Geschlecht und ein soziales Geschlecht gibt. Für eine Person, die sich mit einem Geschlecht identifiziert, das sich von dem unterscheidet, mit dem sie geboren wurde, ist es wichtig, in die Gesellschaft aufgenommen zu werden, so wie sie ist.
Eine Frage, die wir als Gesellschaft im Auge behalten müssen, ist, ob der Bereich der KI Gefahr läuft, Menschen jenseits der zugewiesenen binären Geschlechterordnung zu diskriminieren. Tatsache ist, dass in der KI-Forschung das Geschlecht oft binär dargestellt wird. Bilder, die in Algorithmen eingespeist werden, um diese zu trainieren, werden entweder als männlich oder weiblich gekennzeichnet. Geschlechtserkennungssysteme, die auf einer deterministischen Geschlechtszuordnung basieren, können auch direkten Schaden anrichten, indem sie Mitglieder der LGBTQIA+-Gemeinschaft falsch kennzeichnen. Derzeit müssen in der ML-Forschung noch weitere Geschlechtsbezeichnungen berücksichtigt werden. Anstatt das Geschlecht als binäre Variable darzustellen, könnte es als Spektrum kodiert werden.

Erforschung der Geschlechterdarstellung von Frauen und Männern

Wir haben StyleGAN angewandt, um zu untersuchen, wie KI Geschlechterunterschiede darstellt. Konkret haben wir eine Geschlechterrichtung im latenten Raum verwendet. Forscher:innen haben diese Richtung vorher bestimmt, um das männliche und weibliche Geschlecht darzustellen. Wir haben gesehen, dass die generierten Bilder gängige Geschlechterstereotypen wiedergaben – Frauen lächeln mehr, haben größere Augen, längeres Haar und tragen viel Make-up – konnten aber nicht feststellen, dass das StyleGAN-Modell allein diese Verzerrung verbreitet. Erstens wurden die StyleGANs in erster Linie entwickelt, um fotorealistische Gesichtsbilder zu erzeugen und nicht, um die Gesichtszüge vorhandener Fotos nach Belieben zu verändern. Zweitens: Da die von uns verwendete latente Richtung ohne Korrektur für Verzerrungen in den StyleGAN-Trainingsdaten erstellt wurde, sehen wir eine Korrelation zwischen stereotypen Merkmalen und Geschlecht.

Nächste Schritte und Geschlechtsneutralität

Auch haben wir uns gefragt, welche Gesichter wir in den von uns generierten Bildsequenzen als geschlechtsneutral wahrnehmen. Bei Originalbildern von Männern mussten wir in die künstlich erzeugte weibliche Richtung schauen und umgekehrt. Dies war eine subjektive Entscheidung. Wir sehen es als logischen nächsten Schritt an, zu versuchen, die Generierung von geschlechtsneutralen Versionen von Gesichtsbildern zu automatisieren, um die Möglichkeiten der KI im Bereich Geschlecht und Gesellschaft weiter zu erforschen. Dazu müssten wir zunächst das Geschlecht des zu bearbeitenden Gesichts klassifizieren und uns dann bis zu dem Punkt, an dem der Klassifikator keine eindeutige Zuordnung mehr vornehmen kann, dem anderen Geschlecht annähern. Daher können interessierte Leserinnen und Leser die Fortsetzung unserer Reise in einem zweiten Blogartikel in nächster Zeit verfolgen.

Wenn Du dich für unsere technische Umsetzung dieses Artikels interessierst, kannst Du den Code hier finden und ihn mit deinen eigenen Bildern ausprobieren.

Quellen

Bildnachweise
AdobeStock 210526825 – Wayhome Studio
AdobeStock 243124072 – Damir Khabirov
AdobeStock 387860637 – insta_photos
AdobeStock 395297652 – Nattakorn
AdobeStock 480057743 – Chris
AdobeStock 573362719 – Xavier Lorenzo
AdobeStock 575284046 – Jose Calsina
Isabel Hermes, Alexander Müller