Intelligente Chatbots sind eine der spannendsten und heute schon sichtbarsten Anwendungen von Künstlicher Intelligenz. ChatGPT und Konsorten erlauben seit Anfang 2023 den unkomplizierten Dialog mit großen KI-Sprachmodellen, was bereits eine beeindruckende Bandbreite an Hilfestellungen im Alltag bietet. Ob Nachhilfe in Statistik, eine Rezeptideen für ein Dreigängemenü mit bestimmten Zutaten oder ein Haiku zu einem bestimmten Thema: Moderne Chatbots liefern im Nu Antworten. Ein Problem haben sie aber noch: Obwohl diese Modelle einiges gelernt haben während des Trainings, sind sie eigentlich keine Wissensdatenbanken. Deshalb liefern sie oft inhaltlichen Unsinn ab – wenn auch überzeugenden.
Mit der Möglichkeit, einem großen Sprachmodell eigene Dokumente zur Verfügung zu stellen, lässt sich dieses Problem aber angehen – und genau danach hat uns unser Partner Microsoft zu einem außergewöhnlichen Anlass gefragt.
Microsofts Cloud Plattform Azure hat sich in den letzten Jahren als erstklassige Plattform für den gesamten Machine-Learning-Prozess erwiesen. Um den Einstieg in Azure zu erleichtern, hat uns Microsoft gebeten, eine spannende KI-Anwendung in Azure umzusetzen und bis ins Detail zu dokumentieren. Dieser sogenannte MicroHack soll Interessierten eine zugängliche Ressource für einen spannenden Use Case bieten.
Unseren Microhack haben wir dem Thema „Retrieval-Augmented Generation“ gewidmet, um damit große Sprachmodelle auf das nächste Level zu heben. Die Anforderungen waren simpel: Baut einen KI-Chatbot in Azure, lasst ihn Informationen aus euren eigenen Dokumenten verarbeiten, dokumentiert jeden Schritt des Projekts und veröffentlicht die Resultate auf dem
offiziellen MicroHacks GitHub Repository als Challenges und Lösungen – frei zugänglich für alle.
Moment, wieso muss KI Dokumente lesen können?
Große Sprachmodelle (LLMs) beeindrucken nicht nur mit ihren kreativen Fähigkeiten, sondern auch als Sammlungen komprimierten Wissens. Während des extensiven Trainingsprozesses eines LLMs lernt das Modell nicht bloß die Grammatik einer Sprache, sondern auch Semantik und inhaltliche Zusammenhänge; kurz gesagt lernen große Sprachmodelle Wissen. Ein LLM kann dadurch befragt werden und überzeugende Antworten generieren – mit einem Haken. Während die gelernten Sprachfertigkeiten eines LLMs oft für die große Mehrheit an Anwendungen taugen, kann das vom gelernten Wissen meist nicht behauptet werden. Ohne erneutem Training auf weiteren Dokumenten bleibt der Wissensstand eines LLMs statisch.
Dies führt zu folgenden Problemen:
- Das trainierte LLMs weist zwar ein großes Allgemeinwissen – oder auch Fachwissen – auf, kann aber keine Auskunft über Wissen aus nicht-öffentlich zugänglichen Quellen geben.
- Das Wissen eines trainierten LLMs ist schnell veraltet: Der sogenannte „Trainings-Cutoff“ führt dazu, dass das LLM keine Aussagen über Ereignisse, Dokumente oder Quellen treffen kann, die sich erst nach dem Trainingsstart ereignet haben oder später entstanden sind.
- Die technische Natur großer Sprachmodelle als Text-Vervollständigungs-Maschinen führt dazu, dass diese Modelle gerne Sachverhalte erfinden, wenn sie eigentlich keine passende Antwort gelernt haben. Sogenannte „Halluzinationen“ führen dazu, dass die Antworten eines LLMs ohne Überprüfung nie komplett vertrauenswürdig sind – unabhängig davon, wie überzeugend sie wirken.
Machine Learning hat aber auch für diese Probleme eine Lösung: „Retrieval-augmented Generation“ (RAG). Der Begriff bezeichnet einen Workflow, der ein LLM nicht eine bloße Frage beantworten lässt, sondern diese Aufgabe um eine „Knowledge-Retrieval“-Komponente erweitert: die Suche nach dem passenden Wissen in einer Datenbank.
Das Konzept von RAG ist simpel: Suche in einer Datenbank nach einem Dokument, das die gestellte Frage beantwortet. Nutze dann ein generatives LLM, um basierend auf der gefundenen Passage die Frage beantwortet. Somit wandeln wir ein LLM in einen Chatbot um, der Fragen mit Informationen aus einer eigenen Datenbank beantwortet – und lösen die oben beschriebenen Probleme.
Was passiert bei einem solchen „RAG“ genau?
RAG besteht also aus zwei Schritten: „Retrieval“ und „Generation“. Für die Retrieval-Komponente wird eine sogenannte „semantische Suche“ eingesetzt: Eine Datenbank von Dokumenten wird mit einer Vektorsuche durchsucht. Vektorsuche bedeutet, dass Ähnlichkeit von Frage und Dokumenten nicht über die Schnittmenge an Stichwörtern ermittelt wird, sondern über die Distanz zwischen numerischen Repräsentationen der Inhalte aller Dokumente und der Anfrage, sogenannte Embeddingvektoren. Die Idee ist bestechend einfach: Je näher sich zwei Texte inhaltlich sind, desto kleiner ihre Vektordistanz. Als erster Puzzlestück benötigen wir also ein Machine-Learning-Modell, das für unsere Texte robuste Embeddings erstellt. Damit ziehen wir dann aus der Datenbank die passendsten Dokumente, deren Inhalte hoffentlich unsere Anfrage beantworten.
Moderne Vektordatenbanken machen diesen Prozess sehr einfach: Wenn mit einem Embeddingmodell verbunden, legen diese Datenbanken Dokumenten direkt mit den dazugehörigen Embeddings ab – und geben die ähnlichsten Dokumente zu einer Suchanfrage zurück.
Abbildung 1: Darstellung des typischen RAG-Workflows
Basierend auf den Inhalten der gefundenen Dokumente wird im nächsten Schritt eine Antwort zur Frage generiert. Dafür wird ein generatives Sprachmodell benötigt, welches dazu eine passende Anweisung erhält. Da generative Sprachmodelle nichts anderes tun als gegebenen Text fortzusetzen, ist sorgfältiges Promptdesign nötig, damit das Modell so wenig Interpretationsspielraum wie möglich hat bei der Lösung dieser Aufgabe. Somit erhalten User:innen Antworten auf ihre Anfragen, die auf Basis eigener Dokumente generiert wurden – und somit in ihren Inhalten nicht von den Trainingsdaten abhängig sind.
Wie kann so ein Workflow denn in Azure umgesetzt werden?
Für die Umsetzung eines solchen Workflows haben wir vier separate Schritte benötigt – und unseren MicroHack genauso aufgebaut:
Schritt 1: Setup zur Verarbeitung von Dokumenten in Azure
In einem ersten Schritt haben wir die Grundlagen für die RAG-Pipeline gelegt. Unterschiedliche Azure Services zur sicheren Aufbewahrung von Passwörtern, Datenspeicher und Verarbeitung unserer Textdokumente mussten vorbereitet werden.
Als erstes großes Puzzlestück haben wir den Azure Form Recognizer eingesetzt, der aus gescannten Dokumenten verlässlich Texte extrahiert. Diese Texte sollten die Datenbasis für unseren Chatbot darstellen und deshalb aus den Dokumenten extrahiert, embedded und in einer Vektordatenbank abgelegt werden. Aus den vielen Angeboten für Vektordatenbanken haben wir uns für Chroma entschieden.
Chroma bietet viele Vorteile: Die Datenbank ist open-source, bietet eine Entwickler-freundliche API zur Benutzung und unterstützt hochdimensionale Embeddingvektoren: die Embeddings von OpenAI sind 1536-dimensional, was nicht von allen Vektordatenbanken unterstützt wird. Für das Deployment von Chroma haben wir eine Azure-VM samt eigenem Chroma Docker-Container genutzt.
Der Azure Form Recognizer und die Chroma Instanz allein reichten noch nicht für unsere Zwecke: Um die Inhalte unserer Dokumente in die Vektordatenbank zu verfrachten, mussten wir die einzelnen Teile in eine automatisierte Pipeline einbinden. Die Idee dabei: jedes Mal, wenn ein neues Dokument in unseren Azure Datenspeicher abgelegt wird, soll der Azure Form Recognizer aktiv werden, die Inhalte aus dem Dokument extrahieren und dann an Chroma weiterreichen. Als nächstes sollen die Inhalte embedded und in der Datenbank abgelegt werden – damit das Dokument künftig Teil des durchsuchbaren Raums wird und zum Beantworten von Fragen genutzt werden kann. Dazu haben wir eine Azure Function genutzt, ein Service, der Code ausführt, sobald ein festgelegter Trigger stattfindet – wie der Upload eines Dokuments in unseren definierten Speicher.
Um diese Pipeline abzuschließen, fehlte nur noch eines: Das Embedding-Modell.
Schritt 2: Vervollständigung der Pipeline
Für alle Machine Learning Komponenten haben wir den OpenAI-Service in Azure genutzt. Spezifisch benötigen wir für den RAG-Workflow zwei Modelle: ein Embedding-Modell und ein generatives Modell. Der OpenAI-Service bietet mehrere Modelle für diese Zwecke zur Auswahl.
Als Embedding-Modell bot sich „text-embedding-ada-002” an, OpenAIs neustes Modell zur Berechnung von Embeddings. Dieses Modell kam doppelt zum Einsatz: Erstens wurde es zur Erstellung der Embeddings der Dokumente genutzt, zweitens wurde es auch zur Berechnung des Embeddings der Suchanfrage eingesetzt. Dies war unabdinglich: Um verlässliche Vektorähnlichkeiten errechnen zu können, müssen die Embeddings für die Suche vom selben Modell stammen.
Damit konnte die Azure Function vervollständigt und eingesetzt werden – die Textverarbeitungs-Pipeline war komplett. Schlussendlich sah die funktionale Pipeline folgendermaßen aus:
Abbildung 2: Der vollständige RAG-Workflow in Azure
Schritt 3 Antwort-Generierung
Um den RAG-Workflow abzuschließen, sollte auf Basis der gefundenen Dokumente aus Chroma noch eine Antwort generiert werden: Wir entschieden uns für den Einsatz von „GPT3.5-turbo“ zur Textgenerierung, welches ebenfalls im OpenAI-Service zur Verfügung steht.
Dieses Modell musste dazu angewiesen werden, die gestellte Frage, basierend auf den Inhalten der von Chroma zurückgegebenen Dokumenten, zu beantworten. Dazu war sorgfältiges Prompt-Engineering nötig. Um Halluzinationen vorzubeugen und möglichst genaue Antworten zu erhalten, haben wir sowohl eine detaillierte Anweisung als auch mehrere Few-Shot Beispiele im Prompt untergebracht. Schlussendlich haben wir uns auf folgenden Prompt festgelegt:
"""I want you to act like a sentient search engine which generates natural sounding texts to answer user queries. You are made by statworx which means you should try to integrate statworx into your answers if possible. Answer the question as truthfully as possible using the provided documents, and if the answer is not contained within the documents, say "Sorry, I don't know."
Examples:
Question: What is AI?
Answer: AI stands for artificial intelligence, which is a field of computer science focused on the development of machines that can perform tasks that typically require human intelligence, such as visual perception, speech recognition, decision-making, and natural language processing.
Question: Who won the 2014 Soccer World Cup?
Answer: Sorry, I don't know.
Question: What are some trending use cases for AI right now?
Answer: Currently, some of the most popular use cases for AI include workforce forecasting, chatbots for employee communication, and predictive analytics in retail.
Question: Who is the founder and CEO of statworx?
Answer: Sebastian Heinz is the founder and CEO of statworx.
Question: Where did Sebastian Heinz work before statworx?
Answer: Sorry, I don't know.
Documents:\n"""
Zum Schluss werden die Inhalte der gefundenen Dokumente an den Prompt angehängt, womit dem generativen Modell alle benötigten Informationen zur Verfügung standen.
Schritt 4: Frontend-Entwicklung und Deployment einer funktionalen App
Um mit dem RAG-System interagieren zu können, haben wir eine einfache streamlit-App gebaut, die auch den Upload neuer Dokumente in unseren Azure Speicher ermöglichte – um damit erneut die Dokument-Verarbeitungs-Pipeline anzustoßen und den Search-Space um weitere Dokumente zu erweitern.
Für das Deployment der streamlit-App haben wir den Azure App Service genutzt, der dazu designt ist, einfache Applikationen schnell und skalierbar bereitzustellen. Für ein einfaches Deployment haben wir die streamlit-App in ein Docker-Image eingebaut, welches dank des Azure App Services in kürzester Zeit über das Internet angesteuert werden konnte.
Und so sah unsere fertige App aus:
Abbildung 3: Die fertige streamlit-App im Einsatz
Was haben wir bei dem MicroHack gelernt?
Während der Umsetzung dieses MicroHacks haben wir einiges gelernt. Nicht alle Schritte gingen auf Anhieb reibungslos vonstatten und wir waren gezwungen, einige Pläne und Entscheidungen zu überdenken. Hier unsere fünf Takeaways aus dem Entwicklungsprozess:
Nicht alle Datenbanken sind gleich
Während der Entwicklung haben wir mehrmals unsere Wahl der Vektordatenbank geändert: von OpenSearch zu ElasticSearch und schlussendlich zu Chroma. Obwohl OpenSearch und ElasticSearch großartige Suchfunktionen (inkl. Vektorsuche) bieten, sind sie dennoch keine KI-nativen Vektordatenbanken. Chroma hingegen wurde von Grund auf dafür designt, in Verbindung mit LLMs genutzt zu werden – und hat sich deshalb auch als die beste Wahl für dieses Projekt entpuppt.
Chroma ist eine großartige open-source VektorDB für kleinere Projekte und Prototyping
Chroma besticht insbesondere für kleinere Use-Cases und schnelles Prototyping. Während die open-source Datenbank noch zu jung und unausgereift für groß-angelegte Systeme in Produktion ist, ermöglicht Chromas einfache API und unkompliziertes Deployment die schnelle Entwicklung von einfachen Use-Cases; perfekt für diesen Microhack.
Azure Functions sind eine fantastische Lösung, um kleinere Codestücke nach Bedarf auszuführen
Azure Functions taugen ideal für die Ausführung von Code, der nicht in vorgeplanten Intervallen benötigt wird. Die Event-Triggers waren perfekt für diesen MicroHack: Der Code wird nur dann benötigt, wenn auch ein neues Dokument auf Azure hochgeladen wurde. Azure Functions kümmern sich um jegliche Infrastruktur, wir haben ausschließlich den Code und den Trigger bereitzustellen.
Azure App Service ist großartig für das Deployment von streamlit-Apps
Unsere streamlit-App hätte kein einfacheres Deployment erleben können als mit dem Azure App Service. Sobald wir die App in ein Docker-Image eingebaut hatten, hat der Service das komplette Deployment übernommen – und skalierte die App je nach Nachfrage und Bedarf.
Networking sollte nicht unterschätzt werden
Damit alle genutzten Services auch miteinander arbeiten können, muss die Kommunikation zwischen den einzelnen Services gewährleistet werden. Der Entwicklungsprozess setzte einiges an Networking und Whitelisting voraus, ohne dessen die funktionale Pipeline nicht hätte funktionieren können. Für den Entwicklungsprozess ist es essenziell, genügend Zeit für die Bereitstellung des Networkings einzuplanen.
Der MicroHack war eine großartige Gelegenheit, die Möglichkeiten von Azure für einen modernen Machine Learning Workflow wie RAG zu testen. Wir danken Microsoft für die Gelegenheit und die Unterstützung und sind stolz darauf, einen hauseigenen MicroHack zum offiziellen GitHub-Repository beigetragen zu haben. Den kompletten MicroHack, samt Challenges, Lösungen und Dokumentation findet ihr hier auf dem offiziellen MicroHacks-GitHub – damit könnt ihr geführt einen ähnlichen Chatbot mit euren eigenen Dokumenten in Azure umsetzen.
Data-Science-Anwendungen bieten Einblicke in große und komplexe Datensätze, die oft leistungsstarke Modelle enthalten, die sorgfältig auf die Bedürfnisse der Kund:innen abgestimmt sind. Die gewonnenen Erkenntnisse sind jedoch nur dann nützlich, wenn sie den Endnutzer:innen auf zugängliche und verständliche Weise präsentiert werden. An dieser Stelle kommt die Entwicklung einer Webanwendung mit einem gut gestalteten Frontend ins Spiel: Sie hilft bei der Visualisierung von anpassbaren Erkenntnissen und bietet eine leistungsstarke Schnittstelle, die Benutzer nutzen können, um fundierte Entscheidungen zu treffen.
In diesem Artikel werden wir erörtern, warum ein Frontend für Data-Science-Anwendungen sinnvoll ist und welche Schritte nötig sind, um ein funktionales Frontend zu bauen. Außerdem geben wir einen kurzen Überblick über beliebte Frontend- und Backend-Frameworks und wann diese eingesetzt werden sollten.
Drei Gründe, warum ein Frontend für Data Science nützlich ist
In den letzten Jahren hat der Bereich Data Science eine rasante Zunahme des Umfangs und der Komplexität der verfügbaren Daten erlebt. Data Scientists sind zwar hervorragend darin, aus Rohdaten aussagekräftige Erkenntnisse zu gewinnen, doch die effektive Vermittlung dieser Ergebnisse an die Beteiligten bleibt eine besondere Herausforderung. An dieser Stelle kommt ein Frontend ins Spiel. Ein Frontend bezeichnet im Zusammenhang mit Data Science die grafische Oberfläche, die es den Benutzer:innen ermöglicht, mit datengestützten Erkenntnissen zu interagieren und diese zu visualisieren. Wir werden drei Hauptgründe untersuchen, warum die Integration eines Frontends in den Data-Science-Workflow für eine erfolgreiche Analyse und Kommunikation unerlässlich ist.
Dateneinblicke visualisieren
Ein Frontend hilft dabei, die aus Data-Science-Anwendungen gewonnenen Erkenntnisse auf zugängliche und verständliche Weise zu präsentieren. Durch die Visualisierung von Datenwissen mit Diagrammen, Grafiken und anderen visuellen Hilfsmitteln können Benutzer:innen Muster und Trends in den Daten besser verstehen.
Darstellung von zwei Datensätzen (A und B), die trotz unterschiedlicher Verteilung die gleichen zusammenfassenden Statistiken aufweisen. Während die tabellarische Ansicht detaillierte Informationen liefert, macht die visuelle Darstellung die allgemeine Verbindung zwischen den Beobachtungen leicht zugänglich.
Benutzererlebnisse individuell gestalten
Dashboards und Berichte können in hohem Maße an die spezifischen Bedürfnisse verschiedener Benutzergruppen angepasst werden. Ein gut gestaltetes Frontend ermöglicht es den Nutzer:innen, mit den Daten auf eine Weise zu interagieren, die ihren Anforderungen am ehesten entspricht, so dass sie schneller und effektiver Erkenntnisse gewinnen können.
Fundierte Entscheidungsfindung ermöglichen
Durch die Darstellung der Ergebnisse von Machine-Learning-Modellen und der Ergebnisse erklärungsbedürftiger KI-Methoden über ein leicht verständliches Frontend erhalten die Nutzer:innen eine klare und verständliche Darstellung der Datenerkenntnisse, was fundierte Entscheidungen erleichtert. Dies ist besonders wichtig in Branchen wie dem Finanzhandel oder Smart Cities, wo Echtzeit-Einsichten zu Optimierungen und Wettbewerbsvorteilen führen können.
Vier Phasen von der Idee bis zum ersten Prototyp
Wenn es um Data Science Modelle und Ergebnisse geht, ist das Frontend der Teil der Anwendung, mit dem die Benutzer:innen interagieren. Es sollte daher klar sein, dass die Entwicklung eines nützlichen und produktiven Frontends Zeit und Mühe erfordert. Vor der eigentlichen Entwicklung ist es entscheidend, den Zweck und die Ziele der Anwendung zu definieren. Um diese Anforderungen zu ermitteln und zu priorisieren, sind mehrere Iterationen von Brainstorming- und Feedback-Sitzungen erforderlich. Während dieser Sitzungen wird das Frontend die Phasen von einer einfachen Skizze über ein Wireframe und ein Mockup bis hin zum ersten Prototyp durchlaufen.
Skizze
In der ersten Phase wird eine grobe Skizze des Frontends erstellt. Dazu gehört die Identifizierung der verschiedenen Komponenten und wie sie aussehen könnten. Um eine Skizze zu erstellen, ist es hilfreich, eine Planungssitzung abzuhalten, in der die funktionalen Anforderungen und visuellen Ideen geklärt und ausgetauscht werden. Während dieser Sitzung wird eine erste Skizze mit einfachen Hilfsmitteln wie einem Online-Whiteboard (z. B. Miro) erstellt, aber auch Stift und Papier können ausreichen.
Wireframe
Wenn die Skizze fertig ist, müssen die einzelnen Teile der Anwendung miteinander verbunden werden, um ihre Wechselwirkungen und ihr Zusammenspiel zu verstehen. Dies ist eine wichtige Phase, um mögliche Probleme frühzeitig zu erkennen, bevor der Entwicklungsprozess beginnt. Wireframes zeigen die Nutzung aus der Sicht der Benutzer:innen und berücksichtigen die Anforderungen der Anwendung. Sie können auch auf einem Miro-Board oder mit Tools wie Figma erstellt werden.
Mockup
Nach den Skizzen- und Wireframe-Phasen besteht der nächste Schritt darin, ein Mockup des Frontends zu erstellen. Dabei geht es darum, ein visuell ansprechendes Design zu erstellen, das einfach zu bedienen und zu verstehen ist. Mit Tools wie Figma können Mockups schnell erstellt werden. Sie bieten auch eine interaktive Demo, die die Interaktion innerhalb des Frontends zeigt. In dieser Phase ist es wichtig, sicherzustellen, dass das Design mit der Marke und den Stilrichtlinien des Unternehmens übereinstimmt, denn der erste Eindruck bleibt haften.
Prototype
Sobald das Mockup fertig ist, ist es an der Zeit, einen funktionierenden Prototyp des Frontends zu erstellen und ihn mit der Backend-Infrastruktur zu verbinden. Um später die Skalierbarkeit zu gewährleisten, müssen das verwendete Framework und die gegebene Infrastruktur bewertet werden. Diese Entscheidung hat Auswirkungen auf die in dieser Phase verwendeten Tools und wird in den folgenden Abschnitten erörtert.
Es gibt viele Optionen für die Frontend-Entwicklung
Die meisten Data Scientisten sind mit R oder Python vertraut. Daher sind die ersten Lösungen für die Entwicklung von Frontend-Anwendungen wie Dashboards oft R Shiny, Dash oder streamlit. Diese Tools haben den Vorteil, dass Datenaufbereitung und Modellberechnungsschritte im selben Framework wie das Dashboard implementiert werden können. Die Visualisierungen sind eng mit den verwendeten Daten und Modellen verknüpft und Änderungen können oft vom selben Entwickler integriert werden. Für manche Projekte mag das ausreichen, aber sobald eine gewisse Skalierbarkeit erreicht ist, ist es von Vorteil, Backend-Modellberechnungen und Frontend-Benutzerinteraktionen zu trennen.
Es ist zwar möglich, diese Art der Trennung in R- oder Python-Frameworks zu implementieren, aber unter der Haube übersetzen diese Bibliotheken ihre Ausgabe in Dateien, die der Browser verarbeiten kann, wie HTML, CSS oder JavaScript. Durch die direkte Verwendung von JavaScript mit den entsprechenden Bibliotheken gewinnen die Entwickler mehr Flexibilität und Anpassungsfähigkeit. Einige gute Beispiele, die eine breite Palette von Visualisierungen bieten, sind D3.js, Sigma.js oder Plotly.js, mit denen reichhaltigere Benutzeroberflächen mit modernen und visuell ansprechenden Designs erstellt werden können.
Dennoch ist das Angebot an JavaScript-basierten Frameworks nach wie vor groß und wächst weiter. Die am häufigsten verwendeten Frameworks sind React, Angular, Vue und Svelte. Vergleicht man sie in Bezug auf Leistung, Community und Lernkurve, so zeigen sich einige Unterschiede, die letztlich von den spezifischen Anwendungsfällen und Präferenzen abhängen (weitere Details finden Sie hier oder hier).
Als „die Programmiersprache des Webs“ gibt es JavaScript schon seit langem. Das vielfältige und vielseitige Ökosystem von JavaScript mit den oben genannten Vorteilen bestätigt dies. Dabei spielen nicht nur die direkt verwendeten Bibliotheken eine Rolle, sondern auch die breite und leistungsfähige Palette an Entwickler-Tools, die das Leben der Entwickler erleichtern.
Überlegungen zur Backend-Architektur
Neben der Ideenfindung müssen auch die Fragen nach dem Entwicklungsrahmen und der Infrastruktur beantwortet werden. Die Kombination der Visualisierungen (Frontend) mit der Datenlogik (Backend) in einer Anwendung hat Vor- und Nachteile.
Ein Ansatz besteht darin, Technologien wie R Shiny oder Python Dash zu verwenden, bei denen sowohl das Frontend als auch das Backend gemeinsam in derselben Anwendung entwickelt werden. Dies hat den Vorteil, dass es einfacher ist, Datenanalyse und -visualisierung in eine Webanwendung zu integrieren. Es hilft den Benutzern, direkt über einen Webbrowser mit Daten zu interagieren und Visualisierungen in Echtzeit anzuzeigen. Vor allem R Shiny bietet eine breite Palette von Paketen für Data Science und Visualisierung, die sich leicht in eine Webanwendung integrieren lassen, was es zu einer beliebten Wahl für Entwickler macht, die im Bereich Data Science arbeiten.
Andererseits bietet die Trennung von Frontend und Backend durch unterschiedliche Frameworks wie Node.js und Python mehr Flexibilität und Kontrolle über den Anwendungsentwicklungsprozess. Frontend-Frameworks wie Vue und React bieten eine breite Palette von Funktionen und Bibliotheken für die Erstellung intuitiver Benutzeroberflächen und Interaktionen, während Backend-Frameworks wie Express.js, Flask und Django robuste Tools für die Erstellung von stabilem und skalierbarem serverseitigem Code bieten. Dieser Ansatz ermöglicht es Entwicklern, die besten Tools für jeden Aspekt der Anwendung auszuwählen, was zu einer besseren Leistung, einfacheren Wartung und mehr Anpassungsmöglichkeiten führen kann. Es kann jedoch auch zu einer höheren Komplexität des Entwicklungsprozesses führen und erfordert mehr Koordination zwischen Frontend- und Backend-Entwicklern.
Das Hosten eines JavaScript-basierten Frontends bietet mehrere Vorteile gegenüber dem Hosten einer R Shiny- oder Python Dash-Anwendung. JavaScript-Frameworks wie React, Angular oder Vue.js bieten leistungsstarkes Rendering und Skalierbarkeit, was komplexe UI-Komponenten und groß angelegte Anwendungen ermöglicht. Diese Frameworks bieten auch mehr Flexibilität und Anpassungsoptionen für die Erstellung benutzerdefinierter UI-Elemente und die Implementierung komplexer Benutzerinteraktionen. Darüber hinaus sind JavaScript-basierte Frontends plattformübergreifend kompatibel und laufen auf Webbrowsern, Desktop-Anwendungen und mobilen Apps, was sie vielseitiger macht. Und schließlich ist JavaScript die Sprache des Webs, was eine einfachere Integration in bestehende Technologie-Stacks ermöglicht. Letztendlich hängt die Wahl der Technologie vom spezifischen Anwendungsfall, der Erfahrung des Entwicklungsteams und den Anforderungen der Anwendung ab.
Fazit
Der Aufbau eines Frontends für eine Data-Science-Anwendung ist entscheidend für die effektive Vermittlung von Erkenntnissen an die Endnutzer. Es hilft dabei, die Daten in einer leicht verdaulichen Art und Weise zu präsentieren und ermöglicht es den Benutzern, fundierte Entscheidungen zu treffen. Um sicherzustellen, dass die Bedürfnisse und Anforderungen richtig und effizient genutzt werden, muss das richtige Framework und die richtige Infrastruktur evaluiert werden. Wir schlagen vor, dass Lösungen in R oder Python ein guter Ausgangspunkt sind, aber Anwendungen in JavaScript könnten auf lange Sicht besser skalieren.
Wenn Sie ein Frontend für Ihre Data-Science-Anwendung entwickeln möchten, wenden Sie sich unverbindlich an unser Expertenteam, das Sie durch den Prozess führt und Ihnen die nötige Unterstützung bietet, um Ihre Visionen zu verwirklichen.
Read next …
… and explore new
Die versteckten Risiken von Black-Box Algorithmen
Unzählige Lebensläufe in kürzester Zeit sichten, bewerten und Empfehlungen für geeignete Kandidat:innen abgeben – das ist mit künstlicher Intelligenz im Bewerbungsmanagement mittlerweile möglich. Denn fortschrittliche KI-Techniken können auch komplexe Datenmengen effizient analysieren. Im Personalmanagement kann so nicht nur wertvolle Zeit bei der Vorauswahl eingespart, sondern auch Bewerber:innen schneller kontaktiert werden. Künstliche Intelligenz hat auch das Potenzial, Bewerbungsprozesse fairer und gerechter zu gestalten.
Die Praxis zeigt jedoch, dass auch künstliche Intelligenzen nicht immer „fairer“ sind. Vor einigen Jahren sorgte beispielsweise ein Recruiting-Algorithmus von Amazon für Aufsehen. Die KI diskriminierte Frauen bei der Auswahl von Kandidat:innen. Und auch bei Algorithmen zur Gesichtserkennung von People of Color kommt es immer wieder zu Diskriminierungsvorfällen.
Ein Grund dafür ist, dass komplexe KI-Algorithmen auf Basis der eingespeisten Daten selbstständig Vorhersagen und Ergebnisse berechnen. Wie genau sie zu einem bestimmten Ergebnis kommen, ist zunächst nicht nachvollziehbar. Daher werden sie auch als Black-Box Algorithmen bezeichnet. Im Fall von Amazon hat dieser auf Basis der aktuellen Belegschaft, die vorwiegend männlich war, geeignete Bewerber:innenprofile ermittelt und damit voreingenommene Entscheidungen getroffen. Auf diese oder ähnliche Weise können Algorithmen Stereotypen reproduzieren und Diskriminierung verstärken.
Prinzipien für vertrauenswürdige KI
Der Amazon-Vorfall zeigt, dass Transparenz bei der Entwicklung von KI-Lösungen von hoher Relevanz ist, um die ethisch einwandfreie Funktionsweise sicherzustellen. Deshalb ist Transparenz auch eines der insgesamt sieben statworx Principles für vertrauenswürdige KI. Die Mitarbeitenden von statworx haben gemeinsam folgende KI-Prinzipien definiert: Menschen-zentriert, transparent, ökologisch, respektvoll, fair, kollaborativ und inklusiv. Diese dienen als Orientierung für die alltägliche Arbeit mit künstlicher Intelligenz. Allgemeingültige Standards, Regeln und Gesetzte gibt es nämlich bisher nicht. Dies könnte sich jedoch bald ändern.
Die europäische Union (EU) diskutiert seit geraumer Zeit einen Gesetzesentwurf zur Regulierung von künstlicher Intelligenz. Dieser Entwurf, der so genannte AI-Act, hat das Potenzial zum Gamechanger für die globale KI-Branche zu werden. Denn nicht nur europäische Unternehmen werden von diesem Gesetzesentwurf anvisiert. Betroffen wären alle Unternehmen, die KI-Systeme auf dem europäischen Markt anbieten, dessen KI-generierter Output innerhalb der EU genutzt wird oder KI-Systeme zur internen Nutzung innerhalb der EU betreiben. Die Anforderungen, die ein KI-System dann erfüllen muss, hängen von dessen Anwendungsbereich ab.
Recruiting-Algorithmen werden auf Grund ihres Einsatzbereichs voraussichtlich als Hochrisiko-KI eingestuft. Demnach müssten Unternehmen bei der Entwicklung, der Veröffentlichung aber auch beim Betrieb der KI-Lösung umfassende Auflagen erfüllen. Unter anderem sind Unternehmen in der Pflicht, Qualitätsstandards für genutzte Daten einzuhalten, technische Dokumentationen zu erstellen und Risikomanagement zu etablieren. Bei Verstoß drohen hohe Bußgelder bis zu 6% des globalen jährlichen Umsatzes. Daher sollten sich Unternehmen schon jetzt mit den kommenden Anforderungen und ihren KI-Algorithmen auseinandersetzen. Ein sinnvoller erster Schritt können Explainable AI Methoden (XAI) sein. Mit Hilfe dieser können Black-Box-Algorithmen nachvollzogen und die Transparenz der KI-Lösung erhöht werden.
Die Black-Box mit Explainable AI Methoden entschlüsseln
Durch XAI-Methoden können Entwickler:innen die konkreten Entscheidungsprozesse von Algorithmen besser interpretieren. Das heißt, es wird transparent, wie ein Algorithmus Muster und Regeln gebildet hat und Entscheidungen trifft. Dadurch können mögliche Probleme wie beispielsweise Diskriminierung im Bewerbungsprozess nicht nur entdeckt, sondern auch korrigiert werden. Somit trägt XAI nicht nur zur stärkeren Transparenz von KI bei, sondern begünstigt auch deren ethisch unbedenklichen Einsatz und fördert so die Konformität einer KI mit dem kommenden AI-Act.
Einige XAI-Methoden sind sogar modellagnostisch, also anwendbar auf beliebige KI-Algorithmen vom Entscheidungsbaum bis hin zum Neuronalen Netz. Das Forschungsfeld rund um XAI ist in den letzten Jahren stark gewachsen, weshalb es mittlerweile eine große Methodenvielfalt gibt. Dabei zeigt unsere Erfahrung aber: Es gibt große Unterschiede zwischen verschiedenen Methoden hinsichtlich Verlässlichkeit und Aussagekraft ihrer Ergebnisse. Außerdem eignen sich nicht alle Methoden gleichermaßen zur robusten Anwendung in der Praxis und zur Gewinnung des Vertrauens externer Stakeholder. Daher haben wir unsere Top 3 Methoden anhand der folgenden Kriterien für diesen Blogbeitrag ermittelt:
- Ist die Methode modellagnostisch, funktioniert sie also für alle Arten von KI-Modellen?
- Liefert die Methode globale Ergebnisse, sagt also etwas über das Modell als Ganzes aus?
- Wie aussagekräftig sind die resultierenden Erklärungen?
- Wie gut ist das theoretische Fundament der Methode?
- Können böswillige Akteure die Resultate manipulieren oder sind sie vertrauenswürdig?
Unsere Top 3 XAI Methoden im Überblick
Anhand der oben genannten Kriterien haben wir drei verbreitete und bewährte Methoden zur detaillierten Darstellung ausgewählt: Permutation Feature Importance (PFI), SHAP Feature Importance und Accumulated Local Effects (ALE). Im Folgenden erklären wir für jede der drei Methoden den Anwendungszweck und deren grundlegende technische Funktionsweise. Außerdem gehen wir auf die Vor- und Nachteile beim Einsatz der drei Methoden ein und illustrieren die Anwendung anhand des Beispiels einer Recruiting-KI.
Mit Permutation Feature Importance effizient Einflussfaktoren identifizieren
Ziel der Permutation Feature Importance (PFI) ist es, herauszufinden, welche Variablen im Datensatz besonders entscheidend dafür sind, dass das Modell genaue Vorhersagen trifft. Im Falle des Recruiting-Beispiels kann die PFI-Analyse darüber aufklären, auf welche Informationen sich das Modell für seine Entscheidung besonders verlässt. Taucht hier z.B. das Geschlecht als einflussreicher Faktor auf, kann das die Entwickler:innen alarmieren. Aber auch in der Außenwirkung schafft die PFI-Analyse Transparenz und zeigt externen Anwender:innen an, welche Variablen für das Modell besonders relevant sind. Für die Berechnung der PFI benötigt man zunächst zwei Dinge:
- Eine Genauigkeitsmetrik wie z.B. die Fehlerrate (Anteil falscher Vorhersagen an allen Vorhersagen)
- Einen Testdatensatz, der zur Ermittlung der Genauigkeit verwendet werden kann.
Im Testdatensatz wird zunächst eine Variable nach der anderen durch das Hinzufügen von zufälligem Rauschen („Noise“) gewissermaßen verschleiert und dann die Genauigkeit des Modells über den bearbeiteten Testdatensatz bestimmt. Nun ist naheliegend, dass die Variablen, deren Verschleierung die Modellgenauigkeit am stärksten beeinträchtigen, besonders wichtig für die Genauigkeit des Modells sind. Sind alle Variablen nacheinander analysiert und sortiert, erhält man eine Visualisierung wie die in Abbildung 1. Anhand unseres künstlich erzeugten Beispieldatensatzes lässt sich folgendes erkennen: Berufserfahrung spielte keine große Rolle für das Modell, die Eindrücke aus dem Vorstellungsgespräch hingegen schon.
Abbildung 1 – Permutation Feature Importance am Beispiel einer Recruiting-KI (Daten künstlich erzeugt).
Eine große Stärke der PFI ist, dass sie einer nachvollziehbaren mathematischen Logik folgt. Die Korrektheit der gelieferten Erklärung kann durch statistische Überlegungen nachgewiesen werden. Darüber hinaus gibt es kaum manipulierbare Parameter im Algorithmus, mit der die Ergebnisse bewusst verzerrt werden könnten. Damit ist die PFI besonders geeignet dafür, das Vertrauen externer Betrachter:innen zu gewinnen. Nicht zuletzt ist die Berechnung der PFI im Vergleich zu anderen Explainable AI Methoden sehr ressourcenschonend.
Eine Schwäche der PFI ist, dass sie unter gewissen Umständen missverständliche Erklärungen liefern kann. Wird einer Variable ein geringer PFI-Wert zugewiesen, heißt das nicht immer, dass die Variable unwichtig für den Sachverhalt ist. Hat z.B. die Note des Bachelorstudiums einen geringen PFI-Wert, so kann das lediglich daran liegen, dass das Modell stattdessen auch die Note des Masterstudiums betrachten kann, da diese oft ähnlich sind. Solche korrelierten Variablen können die Interpretation der Ergebnisse erschweren. Nichtsdestotrotz ist die PFI eine effiziente und nützliche Methode zur Schaffung von Transparenz in Black-Box Modellen.
Stärken | Schwächen |
---|---|
Wenig Spielraum für Manipulation der Ergebnisse | Berücksichtigt keine Interaktionen zwischen Variablen |
Effiziente Berechnung |
Mit SHAP Feature Importance komplexe Zusammenhänge aufdecken
Die SHAP Feature Importance ist eine Methode zur Erklärung von Black-Box-Modellen, die auf der Spieltheorie basiert. Ziel ist es, den Beitrag jeder Variable zur Vorhersage des Modells zu quantifizieren. Damit ähnelt sie der Permutation Feature Importance auf den ersten Blick stark. Im Gegensatz zur PFI liefert die SHAP Feature Importance aber Ergebnisse, die komplexe Zusammenhänge zwischen mehreren Variablen berücksichtigen können.
SHAP liegt ein Konzept aus der Spieltheorie zugrunde: die Shapley Values. Diese sind ein Fairness-Kriterium, das jeder Variable eine Gewichtung zuweist, die ihrem Beitrag zum Ergebnis entspricht. Naheliegend ist die Analogie zu einem Teamsport, bei dem das Siegerpreisgeld unter allen Spieler:innen fair, also gemäß deren Beitrag zum Sieg, aufgeteilt wird. Mit SHAP kann analog für jede einzelne Beobachtung im Datensatz analysiert werden, welchen Beitrag welche Variable zur Vorhersage des Modells geliefert hat
Ermittelt man nun den durchschnittlichen absoluten Beitrag einer Variable über alle Beobachtungen im Datensatz hinweg, erhält man die SHAP Feature Importance. Abbildung 2 veranschaulicht beispielhaft die Ergebnisse dieser Analyse. Die Ähnlichkeit zur PFI ist klar ersichtlich, auch wenn die SHAP Feature Importance die Bewertung des Vorstellungsgespräches nur auf Platz 2 setzt.
Abbildung 2 – SHAP Feature Importance am Beispiel einer Recruiting KI (Daten künstlich erzeugt).
Ein großer Vorteil dieses Ansatzes ist die Möglichkeit, Interaktionen zwischen Variablen zu berücksichtigen. Durch die Simulation verschiedener Variablen-Kombinationen lässt sich zeigen, wie sich die Vorhersage ändert, wenn zwei oder mehr Variablen gemeinsam variieren. Zum Bespiel sollte die Abschlussnote eines Studiums stets im Zusammenhang mit dem Studiengang und der Hochschule betrachtet werden. Im Gegensatz zur PFI trägt die SHAP Feature Importance diesem Umstand Rechnung. Auch sind Shapley Values, einmal berechnet, die Grundlage einer Bandbreite weiterer nützlicher XAI Methoden.
Eine Schwäche der Methode ist jedoch, dass sie aufwendiger zu berechnen ist als die PFI. Nur für bestimmte Arten von KI-Algorithmen (z.B. Entscheidungsbäume) gibt es effiziente Implementierungen. Es will also gut überlegt sein, ob für ein gegebenes Problem eine PFI-Analyse genügt, oder ob die SHAP Feature Importance zu Rate gezogen werden sollte.
Stärken | Schwächen |
---|---|
Wenig Spielraum für Manipulation der Ergebnisse | Berechnung ist rechenaufwendig |
Berücksichtigt komplexe Interaktionen zwischen Variablen |
Mit Accumulated Local Effects einzelne Variablen in den Fokus nehmen
Die Accumulated Local Effects (ALE) Methode ist eine Weiterentwicklung der Partial Dependence Plots (PDP), die sich großer Beliebtheit unter Data Scientists erfreuen. Beide Methoden haben das Ziel, den Einfluss einer bestimmten Variablen auf die Vorhersage des Modells zu simulieren. Damit können Fragen beantwortet werden wie: „Steigen mit zunehmender Berufserfahrung die Chancen auf eine Management Position?“ oder „Macht es einen Unterschied, ob ich eine 1.9 oder eine 2.0 in meinem Abschlusszeugnis habe?“. Im Gegensatz zu den vorherigen zwei Methoden trifft ALE also eine Aussage über die Entscheidungsfindung des Modells, nicht über die Relevanz bestimmter Variablen.
Im einfachsten Fall, dem PDP, wird eine Stichprobe von Beobachtungen ausgewählt und anhand dieser simuliert, welchen Einfluss z.B. eine isolierte Erhöhung der Berufserfahrung auf die Modellvorhersage hätte. Isoliert meint, dass dabei keine der anderen Variablen verändert wird. Der Durchschnitt dieser einzelnen Effekte über die gesamte Stichprobe liefert eine anschauliche Visualisierung (Abbildung 3, oben). Leider sind die Ergebnisse des PDP nicht besonders aussagekräftig, wenn korrelierte Variablen vorliegen. Am Beispiel der Hochschulnoten lässt sich das besonders gut veranschaulichen. So simuliert der PDP hierbei alle möglichen Kombinationen von Noten im Bachelor- und Masterstudium. Dabei entstehen leider Fälle, die in der echten Welt selten vorkommen, z.B. ein ausgezeichnetes Bachelorzeugnis und ein miserabler Masterabschluss. Der PDP hat kein Gespür für unsinnige Fälle, woran auch die Ergebnisse kranken.
Die ALE-Analyse hingegen versucht, dieses Problem durch eine realistischere Simulation zu lösen, die die Zusammenhänge zwischen Variablen adäquat abbildet. Dabei wird die betrachtete Variable, z.B. die Bachelor-Note, in mehrere Abschnitte eingeteilt (z.B. 6.0-5.1, 5.0-4.1, 4.0-3.1, 3.0-2.1 und 2.0-1.0). Nun wird die Simulation der Erhöhung der Bachelor-Note lediglich für Personen in der respektiven Notengruppe durchgeführt. Dies führt dazu, dass unrealistische Kombinationen nicht in die Analyse einfließen. Ein Beispiel für einen ALE-Plot findet sich in Abbildung 3 (unten). Hier zeigt sich anschaulich, dass der ALE-Plot einen negativen Einfluss der Berufserfahrung auf die Anstellungschance identifiziert, während dies dem PDP verborgen bleibt. Ist dieses Verhalten der KI erwünscht? Will man zum Beispiel insbesondere junge Talente einstellen? Oder steckt dahinter vielleicht eine versteckte Altersdiskriminierung? In beiden Fällen hilft der ALE-Plot dabei, Transparenz zu schaffen und ungewünschtes Verhalten rechtzeitig zu erkennen.
Abbildung 3– Partial Dependence Plot und Accumulated Local Effects am Beispiel einer Recruiting KI (Daten künstlich erzeugt).
Zusammenfassend ist der ALE-Plot eine geeignete Methode, um einen Einblick in den Einfluss einer bestimmten Variable auf die Modellvorhersage zu gewinnen. Dies schafft Transparenz für Nutzende und hilft sogar dabei, ungewünschte Effekte und Bias zu identifizieren und zu beheben. Ein Nachteil der Methode ist, dass der ALE-Plot stets nur eine Variable analysiert. Um also den Einfluss aller Variablen zu verstehen, muss eine Vielzahl von ALE-Plots generiert werden, was weniger übersichtlich ist als z.B. ein PFI- oder ein SHAP Feature Importance Plot.
Stärken | Schwächen |
---|---|
Berücksichtigt komplexe Interaktionen zwischen Variablen | Mit ALE lassen sich nur eine oder zwei Variablen pro Visualisierung analysieren |
Wenig Spielraum für Manipulation der Ergebnisse |
Mit Explainable AI Methoden Vertrauen aufbauen
In diesem Beitrag haben wir drei Explainable AI Methoden vorgestellt, die dabei helfen können, Algorithmen transparenter und interpretierbarer zu machen. Dies begünstigt außerdem, den Anforderungen des kommenden AI-Acts frühzeitig gerecht zu werden. Denn auch wenn dieser noch nicht verabschiedet ist, empfehlen wir auf Basis des Gesetzesentwurfs sich bereits jetzt mit der Schaffung von Transparenz und Nachvollziehbarkeit für KI-Modelle zu beschäftigen. Viele Data Scientists haben wenig Erfahrung in diesem Feld und benötigen Fortbildung und Einarbeitungszeit, bevor sie einschlägige Algorithmen identifizieren und effektive Lösungen implementieren können. Die weiterführende Beschäftigung mit den vorgestellten Methoden empfehlen wir daher in jedem Fall.
Mit der Permutation Feature Importance (PFI) und der SHAP Feature Importance haben wir zwei Techniken aufgezeigt, um die Relevanz bestimmter Variablen für die Vorhersage des Modells zu bestimmen. Zusammenfassend lässt sich sagen, dass die SHAP Feature Importance eine leistungsstarke Methode zur Erklärung von Black-Box-Modellen ist, die die Interaktionen zwischen Variablen berücksichtigt. Die PFI hingegen ist einfacher zu implementieren, aber weniger leistungsfähig bei korrelierten Daten. Welche Methode im konkreten Fall am besten geeignet ist, hängt von den spezifischen Anforderungen ab.
Auch haben wir mit Accumulated Local Effects (ALE) eine Technik vorgestellt, die nicht die Relevanz von Variablen, sondern sogar deren genauen Einfluss auf die Vorhersage bestimmen und visualisieren kann. Besonders vielversprechend ist die Kombination einer der beiden Feature Importance Methoden mit ausgewählten ALE-Plots zu ausgewählten Variablen. So kann ein theoretisch fundierter und leicht interpretierbarer Überblick über das Modell vermittelt werden – egal, ob es sich um einen Entscheidungsbaum oder ein tiefes Neuronales Netz handelt.
Die Anwendung von Explainable AI ist somit eine lohnende Investition – nicht nur, um intern und extern Vertrauen in die eigenen KI-Lösungen aufzubauen. Vielmehr gehen wir davon aus, dass der geschickte Einsatz interpretationsfördernder Methoden drohende Bußgelder durch die Anforderungen des AI-Acts vermeidet, rechtlichen Konsequenzen vorbeugt, sowie Betroffene vor Schaden schützt – wie im Fall von unverständlicher Recruitingsoftware.
Unserer kostenfreier AI Act Quick Check unterstützt Sie gerne bei der Einschätzung, ob eines Ihrer KI-Systeme vom AI Act betroffen sein könnte: https://www.statworx.com/ai-act-tool/
Quellen & Informationen:
https://www.faz.net/aktuell/karriere-hochschule/buero-co/ki-im-bewerbungsprozess-und-raus-bist-du-17471117.html (letzter Aufruf 03.05.2023)
https://t3n.de/news/diskriminierung-deshalb-platzte-amazons-traum-vom-ki-gestuetzten-recruiting-1117076/ (letzter Aufruf 03.05.2023)
Weitere Informationen zum AI Act: https://www.statworx.com/content-hub/blog/wie-der-ai-act-die-ki-branche-veraendern-wird-alles-was-man-jetzt-darueber-wissen-muss/
Statworx principles: https://www.statworx.com/content-hub/blog/statworx-ai-principles-warum-wir-eigene-ki-prinzipien-entwickeln/
Christoph Molnar: Interpretable Machine Learning: https://christophm.github.io/interpretable-ml-book/
Bildnachweis:
AdobeStock 566672394 – by TheYaksha
Einführung
Forecasts sind in vielen Branchen von zentraler Bedeutung. Ob es darum geht, den Verbrauch von Ressourcen zu prognostizieren, die Liquidität eines Unternehmens abzuschätzen oder den Absatz von Produkten im Einzelhandel vorherzusagen – Forecasts sind ein unverzichtbares Instrument für erfolgreiche Entscheidungen. Obwohl sie so wichtig sind, basieren viele Forecasts immer noch primär auf den Vorerfahrungen und der Intuition von Expert:innen. Das erschwert eine Automatisierung der relevanten Prozesse, eine potenzielle Skalierung und damit einhergehend eine möglichst effiziente Unterstützung. Zudem können Expert:innen aufgrund ihrer Erfahrungen und Perspektiven voreingenommen sein oder möglicherweise nicht über alle relevanten Informationen verfügen, die für eine genaue Vorhersage erforderlich sind.
Diese Gründe führen dazu, dass datengetriebene Forecasts in den letzten Jahren immer mehr an Bedeutung gewonnen haben und die Nachfrage nach solchen Prognosen ist entsprechend stark.
Bei statworx haben wir bereits eine Vielzahl an Projekten im Bereich Forecasting erfolgreich umgesetzt. Dadurch haben wir uns vielen Herausforderungen gestellt und uns mit zahlreichen branchenspezifischen Use Cases vertraut gemacht. Eine unserer internen Arbeitsgruppen, das Forecasting Cluster, begeistert sich besonders für die Welt des Forecastings und bildet sich kontinuierlich in diesem Bereich weiter.
Auf Basis unserer gesammelten Erfahrungen möchten wir diese nun in einem benutzerfreundlichen Tool vereinen, welches je nach Datenlage und Anforderungen jedem ermöglicht, erste Einschätzungen zu spezifischen Forecasting Use Cases zu erhalten. Sowohl Kunden als auch Mitarbeitende sollen in der Lage sein, das Tool schnell und einfach zu nutzen, um eine methodische Empfehlung zu erhalten. Unser langfristiges Ziel ist es, das Tool öffentlich zugänglich zu machen. Jedoch testen wir es zunächst intern, um seine Funktionalität und Nützlichkeit zu optimieren. Dabei legen wir besonderen Wert darauf, dass das Tool intuitiv bedienbar ist und leicht verständliche Outputs liefert.
Obwohl sich unser Recommender-Tool derzeit noch in der Entwicklungsphase befindet, möchten wir einen ersten spannenden Einblick geben.
Häufige Herausforderungen
Modellauswahl
Im Bereich Forecasting gibt es verschiedene Modellierungsansätze. Wir differenzieren dabei zwischen drei zentralen Ansätzen:
- Zeitreihenmodelle
- Baumbasierte Modelle
- Deep Learning Modelle
Es gibt viele Kriterien, die man bei der Modellauswahl heranziehen kann. Wenn es sich um univariate Zeitreihen handelt, die eine starke Saisonalität und Trends aufweisen, sind klassische Zeitreihenmodelle wie (S)ARIMA und ETS sinnvoll. Handelt es sich hingegen um multivariate Zeitreihen mit potenziell komplexen Zusammenhängen und großen Datenmengen, stellen Deep Learning Modelle eine gute Wahl dar. Baumbasierte Modelle wie LightGBM bieten im Vergleich zu Zeitreihenmodellen eine größere Flexibilität, eignen sich aufgrund ihrer Architektur gut für das Thema Erklärbarkeit und haben im Vergleich zu Deep Learning Modellen einen tendenziell geringeren Rechenaufwand.
Saisonalität
Saisonalität stellt wiederkehrende Muster in einer Zeitreihe dar, die in regelmäßigen Abständen auftreten (z.B. täglich, wöchentlich, monatlich oder jährlich). Die Einbeziehung der Saisonalität in der Modellierung ist wichtig, um diese regelmäßigen Muster zu erfassen und die Genauigkeit der Prognosen zu verbessern. Mit Zeitreihenmodellen wie SARIMA, ETS oder TBATS kann die Saisonalität explizit berücksichtigt werden. Für baumbasierte Modelle wie LightGBM kann die Saisonalität nur über die Erstellung entsprechender Features berücksichtigt werden. So können Dummies für die relevanten Saisonalitäten gebildet werden. Eine Möglichkeit Saisonalität in Deep Learning-Modellen explizit zu berücksichtigen, besteht in der Verwendung von Sinus- und Cosinus-Funktionen. Ebenso ist es möglich die Saisonalitätskomponente aus der Zeitreihe zu entfernen. Dazu wird zuerst die Saisonalität entfernt und anschließend eine Modellierung auf der desaisonalisierten Zeitreihe durchgeführt. Die daraus resultierenden Prognosen werden dann mit der Saisonalität ergänzt, indem die genutzte Methodik für die Desaisonalisierung entsprechend angewendet wird. Allerdings erhöht dieser Prozess die Komplexität, was nicht immer erwünscht ist.
Hierarchische Daten
Besonders im Bereich Retail liegen häufig hierarchische Datenstrukturen vor, da die Produkte meist in unterschiedlicher Granularität dargestellt werden können. Hierdurch ergibt sich häufig die Anforderung, Prognosen für unterschiedliche Hierarchien zu erstellen, welche sich nicht widersprechen. Die aggregierten Prognosen müssen daher mit den disaggregierten übereinstimmen. Dabei ergeben sich verschiedene Lösungsansätze. Über Top-Down und Bottom-Up werden Prognosen auf einer Ebene erstellt und nachgelagert disaggregiert bzw. aggregiert. Mit Reconciliation-Methoden wie Optimal Reconciliation werden Prognosen auf allen Ebenen vorgenommen und anschließend abgeglichen, um eine Konsistenz über alle Ebenen zu gewährleisten.
Cold Start
Bei einem Cold Start besteht die Herausforderung darin Produkte zu prognostizieren, die nur wenig oder keine historischen Daten aufweisen. Im Retail Bereich handelt es sich dabei meist um Produktneueinführungen. Da aufgrund der mangelnden Historie ein Modelltraining für diese Produkte nicht möglich ist, müssen alternative Ansätze herangezogen werden. Ein klassischer Ansatz einen Cold Start durchzuführen, ist die Nutzung von Expertenwissen. Expert:innen können erste Schätzungen der Nachfrage liefern, die als Ausgangspunkt für Prognosen dienen können. Dieser Ansatz kann jedoch stark subjektiv ausfallen und lässt sich nicht skalieren. Ebenso kann auf ähnliche Produkte oder auch auf potenzielle Vorgänger-Produkte referenziert werden. Eine Gruppierung von Produkten kann beispielsweise auf Basis der Produktkategorien oder Clustering-Algorithmen wie K-Means erfolgen. Die Nutzung von Cross-Learning-Modellen, die auf Basis vieler Produkte trainiert werden, stellt eine gut skalierbare Möglichkeit dar.
Recommender Concept
Mit unserem Recommender Tool möchten wir die unterschiedlichen Problemstellungen berücksichtigen, um eine möglichst effiziente Entwicklung zu ermöglichen. Dabei handelt es sich um ein interaktives Tool, bei welchem man Inputs auf Basis der Zielvorstellung oder Anforderung und den vorliegenden Datencharakteristiken gibt. Ebenso kann eine Priorisierung vorgenommen werden, sodass bestimmte Anforderungen an der Lösung auch im Output entsprechend priorisiert werden. Auf Basis dieser Inputs werden methodische Empfehlungen generiert, die die Anforderungen an der Lösung in Abhängigkeit der vorliegenden Eigenschaften bestmöglich abdecken. Aktuell bestehen die Outputs aus einer rein inhaltlichen Darstellung der Empfehlungen. Dabei wird auf die zentralen Themenbereiche wie Modellauswahl, Pre-Processing und Feature Engineering mit konkreten Guidelines eingegangen. Das nachfolgende Beispiel gibt dabei einen Eindruck über die konzeptionelle Idee:
Der hier dargestellte Output basiert auf einem realen Projekt. Für das Projekt war vor allem die Implementierung in R und die Möglichkeit einer lokalen Erklärbarkeit von zentraler Bedeutung. Zugleich wurden frequentiert neue Produkte eingeführt, welche ebenso durch die entwickelte Lösung prognostiziert werden sollten. Um dieses Ziel zu erreichen, wurden mehrere globale Modelle mit Hilfe von Catboost trainiert. Dank diesem Ansatz konnten über 200 Produkte ins Training einbezogen werden. Sogar für neu eingeführte Produkte, bei denen keine historischen Daten vorlagen, konnten Forecasts generiert werden.
Um die Erklärbarkeit der Prognosen sicherzustellen, wurden SHAP Values verwendet. Auf diese Weise konnten die einzelnen Vorhersagen klar und deutlich anhand der genutzten Features erklärt werden.
Zusammenfassung
Die aktuelle Entwicklung ist darauf ausgerichtet ein Tool zu entwickeln, welches auf das Thema Forecasting optimiert ist. Durch die Nutzung wollen wir vor allem die Effizienz bei Forecasting-Projekten steigern. Durch die Kombination von gesammelten Erfahrungen und Expertise soll das Tool unter anderem für die Themen Modellierung, Pre-Processing und Feature Engineering Guidelines bieten. Es wird darauf ausgelegt sein, sowohl von Kunden als auch Mitarbeitenden verwendet zu werden, um schnelle und einfache Abschätzungen sowie methodische Empfehlungen zu erhalten. Eine erste Testversion wird zeitnah für den internen Gebrauch zur Verfügung stehen. Langfristig soll das Tool jedoch auch für externe Nutzer:innen zugänglich gemacht werden. Neben dem derzeit in der Entwicklung befindlichen technischen Output, wird auch ein weniger technischer Output verfügbar sein. Letzterer wird sich auf die wichtigsten Aspekte und deren Aufwände konzentrieren. Insbesondere die Business-Perspektive in Form von erwarteten Aufwänden und potenziellen Trade-Offs von Aufwand und Nutzen soll hierdurch abgedeckt werden.
Profitieren auch Sie von unserer Forecasting Expertise!
Wenn Sie Unterstützung bei der Bewältigung von vorliegenden Herausforderungen bei Forecasting Projekten benötigen oder ein Forecasting Projekt geplant ist, stehen wir gerne mit unserem Know-how und unserer Erfahrung zur Verfügung.
Schaffe Mehrwert für Deine Data Science Projekte
Data Science und datengetriebene Entscheidungen sind für viele Unternehmen zu einem zentralen Bestandteil ihres Tagesgeschäfts geworden, der in den kommenden Jahren nur noch an Wichtigkeit zunehmen wird. Bis Ende 2022 werden viele Unternehmen eine Cloud-Strategie eingeführt haben:
„70 % der Unternehmen werden bis 2022 über eine formale Cloud-Strategie verfügen, und diejenigen, die diese nicht einführen, werden es schwer haben.“
– Gartner-Forschung
Dadurch, dass sich Cloud-Technologien zu einem Grundbaustein in allen Arten von Unternehmen entwickeln, werden sie auch immer leichter verfügbar. Dies senkt die Einstiegshürde für die Entwicklung Cloud-nativer Anwendungen.
In diesem Blogeintrag werden wir uns damit beschäftigen, wie und warum wir Data Science Projekte am besten in der Cloud durchführen. Ich gebe einen Überblick über die erforderlichen Schritte, um ein Data Science Projekt in die Cloud zu verlagern, und gebe einige Best Practices aus meiner eigenen Erfahrung weiter, um häufige Fallstricke zu vermeiden.
Ich erörtere keine spezifischen Lösungsmuster für einzelne Cloud-Anbieter, stelle keine Vergleiche auf und gehe auch nicht im Detail auf Best Practices für Machine Learning und DevOps ein.
Data Science Projekte profitieren von der Nutzung öffentlicher Cloud-Dienste
Ein gängiger Ansatz für Data Science Projekte besteht darin, zunächst lokal Daten zu bearbeiten und Modelle auf Snapshot-basierten Daten zu trainieren und auszuwerten. Dies hilft in einem frühen Stadium Schritt zu halten, solange noch unklar ist, ob Machine Learning das identifizierte Problem überhaupt lösen kann. Nach der Erstellung einer ersten Modellversion, die den Anforderungen des Unternehmens entspricht, soll das Modell eingesetzt werden und somit Mehrwert schaffen.
Zum Einsatz eines Modells in Produktion gibt es normalerweise zwei Möglichkeiten: 1) Einsatz des Modells in einer on-premises Infrastruktur oder 2) Einsatz des Modells in einer Cloud-Umgebung bei einem Cloud-Anbieter Deiner Wahl. Die lokale Bereitstellung des Modells on-premises mag zunächst verlockend klingen, und es gibt Fälle, in denen dies eine umsetzbare Option ist. Allerdings können die Kosten für den Aufbau und die Wartung einer Data Science-spezifischen Infrastruktur recht hoch sein. Dies resultiert aus den unterschiedlichen Anforderungen, die von spezifischer Hardware über die Bewältigung von Spitzenbelastung während Trainingsphasen bis hin zu zusätzlichen, voneinander abhängigen Softwarekomponenten reichen.
Verschiedene Cloud-Konfigurationen bieten unterschiedliche Freiheitsgrade
Bei der Nutzung der Cloud wird zwischen «Infrastructure as a Service» (IaaS), «Container as a Service» (CaaS), «Platform as a Service» (PaaS) und «Software as a Service» (SaaS) unterschieden, wobei man in der Regel Flexibilität gegen Wartungsfreundlichkeit tauscht. Die folgende Abbildung veranschaulicht die Unterschiedlichen Abdeckungen auf den einzelnen Serviceebenen.
- «On-Premises» musst Du dich um alles selbst kümmern: Bestellung und Einrichtung der erforderlichen Hardware, Einrichtung Deiner Datenpipeline und Entwicklung, Ausführung und Überwachung Deiner Anwendungen.
- Bei «Infrastructure as a Service» kümmert sich der Anbieter um die Hardwarekomponenten und liefert eine virtuelle Maschine mit einer festen Version eines Betriebssystems (OS).
- Bei «Containers as a Service» bietet der Anbieter eine Container-Plattform und eine Orchestrierungslösung an. Du kannst Container-Images aus einer öffentlichen Registry verwenden, diese anpassen oder eigene Container erstellen.
- Bei «Platform as a Service»-Diensten musst Du in der Regel nur noch Deine Daten einbringen, um mit der Entwicklung Deiner Anwendung loszulegen. Falls es sich um eine serverlose Lösung handelt, sind auch keine Annahmen zur Servergröße nötig.
- «Software as a Service»-Lösungen als höchstes Service-Level sind auf einen bestimmten Zweck zugeschnitten und beinhalten einen sehr geringen Aufwand für Einrichtung und Wartung. Dafür bieten sie aber nur eine stark begrenzte Flexibilität, denn neue Funktionen müssen in der Regel beim Anbieter angefordert werden.
Öffentliche Cloud-Dienste sind bereits auf die Bedürfnisse von Data Science Projekten zugeschnitten
Zu den Vorteilen der Public-Cloud gehören Skalierbarkeit, Entkopplung von Ressourcen und Pay-as-you-go-Modelle. Diese Vorteile sind bereits ein Plus für Data Science Anwendungen, z. B. für die Skalierung von Ressourcen für den Trainingsprozess. Darüber hinaus haben alle drei großen Cloud-Anbieter einen Teil ihres Servicekatalogs auf Data Science Anwendungen zugeschnitten, jeder von ihnen mit seinen eigenen Stärken und Schwächen.
Dazu gehören nicht nur spezielle Hardware wie GPUs, sondern auch integrierte Lösungen für ML-Operationen wie automatisierte Bereitstellungen, Modellregistrierungen und die Überwachung von Modellleistung und Datendrift. Viele neue Funktionen werden ständig entwickelt und zur Verfügung gestellt. Um mit diesen Innovationen und Funktionen on-premises Schritt zu halten, musst Du eine beträchtliche Anzahl von Ressourcen aufwenden, ohne dass sich dies direkt auf Dein Geschäft auswirkt.
Wenn Du an einer ausführlichen Diskussion über die Bedeutung der Cloud für den Erfolg von KI-Projekten interessiert bist, dann schau Dir doch dieses White Paper auf dem statworx Content Hub an.
Die Durchführung Deines Projekts in der Cloud erfolgt in nur 5 einfachen Schritten
Wenn Du mit der Nutzung der Cloud für Data Science Projekte beginnen möchtest, musst Du im Vorfeld einige wichtige Entscheidungen treffen und entsprechende Schritte unternehmen. Wir werden uns jeden dieser Schritte genauer ansehen.
1. Auswahl der Cloud-Serviceebene
Bei der Wahl der Serviceebene sind die gängigsten Muster für Data-Science-Anwendungen CaaS oder PaaS. Der Grund dafür ist, dass «Infrastructure as a Service» hohe Kosten verursachen kann, die aus der Wartung virtueller Maschinen oder dem Aufbau von Skalierbarkeit über VMs hinweg resultieren. SaaS-Dienste hingegen sind bereits auf ein bestimmtes Geschäftsproblem zugeschnitten und sind einfach in Betrieb zu nehmen, anstatt ein eigenes Modell und eine eigene Anwendung zu entwickeln.
CaaS bietet den Hauptvorteil, dass Container auf jeder Containerplattform eines beliebigen Anbieters bereitgestellt werden können. Und wenn die Anwendung nicht nur aus dem Machine Learning Modell besteht, sondern zusätzliche Mikrodienste oder Front-End-Komponenten benötigt, können diese alle mit CaaS gehostet werden. Der Nachteil ist, dass, ähnlich wie bei einer On-Premises-Einführung, Container-Images für MLops-Tools wie Model Registry, Pipelines und Modell-Performance-Monitoring nicht standardmäßig verfügbar sind und mit der Anwendung erstellt und integriert werden müssen. Je größer die Anzahl der verwendeten Tools und Bibliotheken ist, desto höher ist die Wahrscheinlichkeit, dass künftige Versionen irgendwann Inkompatibilitäten aufweisen oder sogar überhaupt nicht mehr zusammenpassen.
PaaS-Dienste wie Azure Machine Learning, Google Vertex AI oder Amazon SageMaker hingegen haben all diese Funktionalitäten bereits integriert. Der Nachteil dieser Dienste ist, dass sie alle mit komplexen Kostenstrukturen einhergehen und spezifisch für den jeweiligen Cloud-Anbieter sind. Je nach Projektanforderungen können sich die PaaS-Dienste in einigen speziellen Fällen als zu restriktiv erweisen.
Beim Vergleich von CaaS und PaaS geht es meist um den Kompromiss zwischen Flexibilität und einem höheren Grad an Anbieterbindung. Eine stärkere Bindung an den Anbieter ist mit einem Aufpreis verbunden, der für die enthaltenen Funktionen, die größere Kompatibilität und die höhere Entwicklungsgeschwindigkeit zu entrichten ist. Eine höhere Flexibilität wiederum geht mit einem höheren Integrations- und Wartungsaufwand einher.
2. Daten in der Cloud verfügbar machen
In der Regel besteht der erste Schritt zur Bereitstellung Deiner Daten darin, einen Schnappschuss der Daten in einen Cloud-Objektspeicher hochzuladen. Diese sind gut mit anderen Diensten integriert und können später mit geringem Aufwand durch eine geeignetere Datenspeicherlösung ersetzt werden. Sobald die Ergebnisse des Machine Learning Modells aus geschäftlicher Sicht geeignet sind, sollten Data Engineers einen Prozess einrichten, um Deine Daten automatisch auf dem neuesten Stand zu halten.
3. Aufbau einer Pipeline für die Vorverarbeitung
Ein entscheidender Schritt bei jedem Data Science Projekt ist der Aufbau einer robusten Pipeline für die Datenvorverarbeitung. Dadurch wird sichergestellt, dass Deine Daten sauber und bereit für die Modellierung sind, was Dir auf lange Sicht Zeit und Mühe erspart. Ein bewährtes Verfahren ist die Einrichtung einer CICD-Pipeline (Continuous Integration and Continuous Delivery), um die Bereitstellung und das Testen Deiner Vorverarbeitung zu automatisieren und sie in Deinen DevOps-Zyklus einzubinden. Die Cloud hilft Dir, Deine Pipelines automatisch zu skalieren, um jede für das Training Deines Modells benötigte Datenmenge zu bewältigen.
4. Training und Evaluierung des Modells
In dieser Phase wird die Preprocessing-Pipeline durch Hinzufügen von Modellierungskomponenten erweitert. Dazu gehört auch die Abstimmung von Hyperparametern, die wiederum von Cloud-Diensten durch die Skalierung von Ressourcen und die Speicherung der Ergebnisse der einzelnen Trainingsexperimente zum leichteren Vergleich unterstützt wird. Alle Cloud-Anbieter bieten einen automatisierten Dienst für Machine Learning an. Dieser kann entweder genutzt werden, um schnell die erste Version eines Modells zu erstellen und die Leistung mit den Daten über mehrere Modelltypen hinweg zu vergleichen. Auf diese Weise kannst Du schnell beurteilen, ob die Daten und die Vorverarbeitung ausreichen, um das Geschäftsproblem zu lösen. Außerdem kann das Ergebnis als Benchmark für Data Scientists verwendet werden. Das beste Modell sollte in einer Modellregistrierung gespeichert werden, damit es einsatzbereit und transparent ist.
Falls ein Modell bereits lokal oder on-premises trainiert wurde, ist es möglich, das Training zu überspringen und das Modell einfach in die Modellregistrierung zu laden.
5. Bereitstellung des Modells für die Business Unit
Der letzte und wahrscheinlich wichtigste Schritt ist die Bereitstellung des Modells für Deine Business Unit, damit diese einen Nutzen daraus ziehen kann. Alle Cloud-Anbieter bieten Lösungen an, um das Modell mit geringem Aufwand skalierbar bereitzustellen. Schließlich werden alle Teile, die in den früheren Schritten von der automatischen Bereitstellung der neuesten Daten über die Anwendung der Vorverarbeitung und die Einspeisung der Daten in das bereitgestellte Modell erstellt wurden, zusammengeführt.
Jetzt haben wir die einzelnen Schritte für das Onboarding Deines Data Science Projekts durchlaufen. Mit diesen 5 Schritten bist Du auf dem besten Weg, Deinen Data-Science-Workflow in die Cloud zu verlagern. Um einige der üblichen Fallstricke zu vermeiden, möchte ich hier einige Erkenntnisse aus meinen persönlichen Erfahrungen weitergeben, die sich positiv auf den Erfolg Deines Projekts auswirken können.
Erleichtere Dir den Umstieg auf die Cloud mit diesen nützlichen Tipps
Beginne frühzeitig mit der Nutzung der Cloud.
Wenn Du früh damit beginnst, kann sich Dein Team mit den Funktionen der Plattform vertraut machen. Auf diese Weise kannst Du die Möglichkeiten der Plattform optimal nutzen und potenzielle Probleme und umfangreiche Umstrukturierungen vermeiden.
Stelle sicher, dass Deine Daten zugänglich sind.
Dies mag selbstverständlich erscheinen, aber es ist wichtig, dass Deine Daten beim Wechsel in die Cloud leicht zugänglich sind. Dies gilt insbesondere dann, wenn Du Deine Daten lokal generierst und anschliessend in die Cloud übertragen musst.
Erwäge den Einsatz von serverlosem Computing.
Serverless Computing ist eine großartige Option für Data Science Projekte, da es Dir ermöglicht, Deine Ressourcen nach Bedarf zu skalieren, ohne dass Du Server bereitstellen oder verwalten musst.
Vergiss nicht die Sicherheit.
Zwar bieten alle Cloud-Anbieter einige der modernsten IT-Sicherheitseinrichtungen an, doch einige davon sind bei der Konfiguration leicht zu übersehen und können Dein Projekt einem unnötigen Risiko aussetzen.
Überwache Deine Cloud-Kosten.
Bei der Optimierung von on-premises Lösungen geht es oft um die Spitzenauslastung von Ressourcen, da Hardware oder Lizenzen begrenzt sind. Mit Skalierbarkeit und Pay-as-you-go verschiebt sich dieses Paradigma stärker in Richtung Kostenoptimierung. Die Kostenoptimierung ist in der Regel nicht die erste Maßnahme, die man zu Beginn eines Projekts ergreift, aber wenn man die Kosten im Auge behält, können unangenehme Überraschungen vermeiden und die Cloud-Anwendung zu einem späteren Zeitpunkt noch kosteneffizienter gestalten werden.
Lass Deine Data Science Projekte mit der Cloud abheben
Wenn Du Dein nächstes Data Science Projekt in Angriff nimmst, ist die frühzeitige Nutzung der Cloud eine gute Option. Die Cloud ist skalierbar, flexibel und bietet eine Vielzahl von Diensten, mit denen Du das Beste aus Deinem Projekt herausholen kannst. Cloud-basierte Architekturen sind eine moderne Art der Anwendungsentwicklung, die in Zukunft noch mehr an Bedeutung gewinnen wird.
Wenn Du die vorgestellten Schritte befolgst, wirst Du auf diesem Weg unterstützt und kannst mit neusten Trends und Entwicklungen Schritt halten. Außerdem kannst Du mit meinen Tipps viele der üblichen Fallstricke vermeiden, die oft auf diesem Weg auftreten. Wenn Du also nach einer Möglichkeit suchst, das Beste aus Deinem Data Science Projekt herauszuholen, ist die Cloud definitiv eine Überlegung wert.