TDWI

<p>Neuronale Netze sind für Außenstehende häufig von einer mystischen Aura umgeben. Sie werden regelmäßig in Verbindung mit menschlichen Gehirnen gebracht, und ihnen wird eine sich verselbständigende Intelligenz zugeschrieben. Das macht sie für viele mysteriös und suspekt. Um ein wenig zur Entmystifizierung beizutragen, widmen wir uns in diesem Blogpost den grundlegenden Prinzipien, auf denen der Trainingsprozess eines neuronalen Netzes beruht. Der Post richtet sich insbesondere an interessierte Personen mit wenig Vorwissen, und wir werden daher auf alle mathematische Details verzichten.</p><p>Im Folgenden präzisieren wir zunächst die Ausgangssituation. Dann lernen wir die Feedback-Schleife kennen, welche das Herzstück des Trainings darstellt. Im Anschluss betrachten wir die grundsätzlichen Fragen, die ein Algorithmus zum Trainieren eines neuronales Netzes beantworten sollte. Abschließend beschäftigen wir uns damit, wie das Training mit einer großen Anzahl an Daten funktionieren kann und wann das Training eines neuronalen Netzes eigentlich abgeschlossen ist.</p><h2>Die Ausgangssituation</h2><p>Um die Komplexität überschaubar zu halten, betrachten wir das neuronale Netz schlicht als eine Black Box mit einer Anzahl verschiedener Regler. Unsere Black Box „Neuronales Netz“ (BB-NN) verfügt über die Fähigkeit, Aussagen über einen bestimmten Sachverhalt zu treffen. In unserer Vorstellung können wir an den Reglern drehen und dadurch die Aussagen der BB-NN beeinflussen. In der Sprache der neuronalen Netze entsprechen die Regler der BB-NN den <em>Gewichten</em> des Netzwerks</p><p>Konkret stellen wir uns dabei folgende Situation vor: Wir zeigen unserer BB-NN ein Bild von einer Person und erhalten von ihr eine Aussage darüber, ob die abgebildete Person eine Brille trägt oder nicht. Hierbei ist wichtig festzuhalten, dass diese Aussage natürlich richtig oder falsch sein kann. Zu Beginn weiß unsere BB-NN noch nichts darüber, was wir eigentlich von ihr haben wollen, und sie wird mit hoher Wahrscheinlichkeit jede Menge falsche Aussagen treffen.</p><p>Unter Trainieren verstehen wir in unserem Kontext nun, die Regler unserer BB-NN so einzustellen, dass sie möglichst viele richtige Aussagen macht. Also möglichst häufig erkennt, ob die Person im Bild eine Brille trägt oder nicht. Wir gehen im Folgenden davon aus, dass wir eine große Anzahl an geeigneten Bildern besitzen, die wir unserer BB-NN zeigen und dabei anschließend überprüfen können, ob die von ihr getroffene Aussage — „trägt Brille“ oder „trägt keine Brille“ — korrekt ist. In der Praxis bedeutet dies, dass wir zum Trainieren eines neuronalen Netzes üblicherweise eine große Menge gelabelter Daten benötigen.</p><h2>Die Feedback-Schleife</h2><p>Der Hauptmechanismus zum Trainieren unserer BB-NN kann durch die Feedback-Schleife</p><p><img width="250" height="102" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KTP1OfUiS6e1aQ8k4Axf" alt="Grafik Feedback-Schleife" /></p><p>visualisiert werden. Die grundlegende Idee hierbei ist, dass wir unserer BB-NN die Bilder zeigen und uns deren Aussagen zu den einzelnen Bildern notieren. Anschließend überprüfen wir die Korrektheit aller so erhaltener Aussagen. Im nächsten Schritt drehen wir an den Reglern unserer BB-NN mit dem Ziel, eine größere Anzahl korrekter Aussagen zu erhalten. Danach wiederholen wir diesen Vorgang. Dabei hoffen wir, dass wir die Regler nach und nach so einstellen können, dass wir mehr und mehr korrekte Aussagen von unserer BB-NN erhalten. In der Sprache der neuronalen Netze wird ein einzelner Durchlauf durch die Feedback-Schleife häufig als eine <em>Epoche</em> bezeichnet. Je größer also die Anzahl der Epochen eines neuronalen Netzes ist, desto länger wurde es trainiert.</p><h2>Trainingsalgorithmen</h2><p>Natürlich ist man in der Praxis nicht selbst damit beschäftigt, die Feinjustierung der verschiedenen Regler eines neuronales Netzes von Hand durchzuführen. Hierfür gibt es eine Vielzahl von Algorithmen, welche diese Aufgabe für uns übernehmen und zum Trainieren neuronaler Netze eingesetzt werden. Dabei bildet die Feedback-Schleife typischerweise das Fundament dieser Algorithmen. Die entscheidende Frage an dieser Stelle ist natürlich: Wie sollen die Regler eigentlich neu eingestellt werden? Oder allgemeiner: Wie soll das Update durchgeführt werden?</p><p>Aus der Vogelperspektive betrachtet, sollte ein Algorithmus zum Trainieren unserer BB-NN also mindestens eine Aussage über zwei Dinge liefern:</p><ul><li>In welche Richtung müssen die Regler gedreht werden?</li><li>Wie weit müssen die Regler gedreht werden?</li></ul><p>Die erschöpfende Antwort auf die erste Frage findet sich in der Mathematik — genauer in der Lösungstheorie von Optimierungsproblemen. An dieser Stelle halten wir aber einfach nur fest, dass es grundsätzlich möglich ist, eine mathematisch fundierte Aussage darüber zu treffen, in welche Richtung die Regler gedreht werden sollten.</p><p>(Interessierte Leser/innen sind eingeladen, sich als Einstieg in die zugrundeliegende Mathematik mit dem <a href="https://de.wikipedia.org/wiki/Gradientenverfahren" target="_blank">Gradientenverfahren</a>  auseinander zu setzen.)</p><p>Damit bleibt die Frage, wie weit wir die Regler drehen sollen. In der Sprache der neuronalen Netze entspricht “wie weit drehen” der sogenannten <em>Learning Rate</em>. Generell ist es dabei schwierig von DER Learning Rate zu sprechen, da bei der Auswahl der Learning Rate unter anderem auch folgende Fragen relevant sind:</p><ul><li>Sollte man am Anfang einen fixen Wert wählen; also die Regler in jeder Epoche gleich weit drehen, oder ist es besser, die Rate im Laufe des Trainings anzupassen?</li><li>Sollte man einen Wert festlegen, der für alle Regler gilt, oder ist es sinnvoller, verschiedene Werte für unterschiedliche Regler zu verwenden?</li></ul><p>Alle diese Fragen sind Gegenstand aktueller Forschung in diesem Fachbereich und können daher nicht pauschal beantwortet werden. Verschiedene Algorithmen verwenden hier unterschiedliche Strategien. Dabei ist ein zentrales Ziel aller Algorithmen, stets die Geschwindigkeit des Lernvorgangs zu erhöhen.</p><h2>Große Datenmengen</h2><p>Die Feedback-Schleife liefert uns eine erste gute Vorstellung davon, wie das Training eines neuronales Netzes funktioniert. In der Praxis werden neuronale Netze normalerweise mit einer sehr großen Anzahl an Daten trainiert. Dies hat zur Folge, dass ein Durchlauf durch die Feedback-Schleife mit dem gesamten Datensatz sehr teuer, d.h. sehr rechenaufwändig werden kann. Dies ist ein Grund, aus dem viele Algorithmen bei jedem einzelnen Durchlauf durch die Feedback-Schleife lediglich einen Teil der Daten, eine sogenannte <em>Batch</em>, verwenden. Dabei wird die Batch in jeder Epoche neu per Zufall aus den Daten zusammengestellt.</p><p>Die Feinjustierung des neuronalen Netzes basiert also in jeder Epoche lediglich auf einem Teil der Daten. Jedoch wird das neuronale Netz im Laufe des Trainings nach und nach immer wieder mit den gesamten Daten konfrontiert. Algorithmen, die diesen Mechanismus verwenden, erkennt man typischerweise an dem Zusatz <em>stochastic</em>.</p><h2>Genug trainiert</h2><p>An dieser Stelle lehnen wir uns kurz zurück, um darüber nachzudenken, was das Ziel des Trainings unserer BB-NN eigentlich ist: Wir wollen von unserer BB-NN am Ende eine möglichst korrekte Aussage über unbekannte Bilder bekommen. Also solche Bilder, die im Lernprozess keine Rolle gespielt haben. Überspitzt formuliert: Es ist uns ziemlich egal, wie genau unsere BB-NN die Bilder während des Trainings zuordnen kann. Wir wollen wissen, wie gut sie neue Bilder einordnen kann.</p><p>In einem Extremfall könnte unsere BB-NN während des Trainings einfach alle Bilder auswendig gelernt haben — und damit immer perfekt zuordnen. Eine Konsequenz aus der Spezialisierung eines neuronalen Netzes auf die Daten aus dem Training ist häufig, dass es anschließend Schwierigkeiten hat, mit unbekannten Daten umzugehen. Die Gefahr des Auswendiglernens während des Trainings wird in der Sprache der neuronalen Netze als <em>Overfitting</em> bezeichnet. Es stellt sich also die Frage, ob und wie man während des Trainings beobachten kann, ob das neuronale Netz einfach auswendig lernt.</p><h2>Aufteilung des Datensatzes</h2><p>Typischerweise wird aus diesem Grund ein Teil der vorhandenen Daten vor dem Lernprozess zur Seite gelegt und nicht beim Training berücksichtigt. Man spricht hierbei vom <em>training dataset</em> und <em>validation dataset</em>. Die Feedback-Schleife wird nun lediglich mithilfe der Daten des training dataset durchgeführt. Nach wie vor überprüfen wir dabei, wie gut das neuronale Netz diese vorhersagen kann. Verbessern sich diese Vorhersagen im Verlauf des Trainings, ist dies zunächst ein guter Indikator dafür, dass das Training funktioniert. Zusätzlich zum Abschneiden auf dem training dataset überprüfen wir aber außerdem noch, wie gut das neuronale Netz das validation dataset vorhersagen kann.</p><p>In unserem Beispiel würden wir demnach vor dem Training einen Teil der Bilder zur Seite legen. Beim Durchlaufen der Feedback-Schleife würden wir unsere BB-NN auch dazu nutzen, Aussagen über die beiseite gelegten Bilder zu treffen. Diese Bilder dürfen keinen direkten Einfluss darauf haben, wie die Regler in der Update-Phase neu justiert werden. Die Feinjustierung des neuronalen Netzes muss ausschließlich auf Basis der Trainingsdaten stattfinden.</p><p>Als Daumenregel kann man nun formulieren: Beende das Training, wenn das neuronale Netz beginnt, bessere Vorhersagen über das training dataset zu machen als über das validation dataset. Hinter diesem Abbruchkriterium steckt die Idee, das Training genau dann zu beenden, wenn das neuronale Netz anfängt, die Daten des training datasets auswendig zu lernen und dadurch schlicht zu verhindern, dass es sich auf das training dataset spezialisiert.</p><p>In der Praxis ist es üblich, neben dem validation dataset noch ein <em>test dataset</em> zu verwenden. Auch dieser Datensatz wird vor Beginn des Trainings abgespalten und zur Seite gelegt. Die Daten des test datasets werden nach Abschluss des Trainings lediglich einmal dazu benutzt, herauszufinden wie gut das fertig trainierte neuronale Netz auf ungesehenen Daten funktioniert. Für diese Daten gilt: Sie dürfen keinerlei Einfluss auf den gesamten Trainingsprozess des Netzes haben. Insbesondere dürfen sie auch nicht für das Abbruchkriterium des Trainings verwendet werden.</p><h2>Fazit</h2><p>In diesem Blogpost haben wir uns mit der Frage auseinandergesetzt, wie man ein neuronales Netz trainiert. Dazu haben wir die Feedback-Schleife kennengelernt, welche typischerweise dem Training zugrunde liegt. Wir haben uns Gedanken darüber gemacht, welche Antworten ein Algorithmus zum Training eines neuronalen Netzes liefern muss. Abschließend haben wir uns dem Thema Overfitting gewidmet und ein Abbruchkriterium für die Feedback-Schleife und damit des Trainings kennengelernt.</p><p>Ich hoffe, euch hat der kurze Ausflug in die Welt der neuronalen Netze gefallen. Wenn ihr mehr zum Thema künstliche Intelligenz erfahren möchtet, einfach <a href="/leistungen/kuenstliche-intelligenz">hier</a>  klicken.</p><p>Ihr habt Fragen zum Blogpost? Dann schreibt mir doch einfach einen Kommentar oder eine Mail.</p>

Wie trainiert man eigentlich neuronale Netze?

<h2>Einleitung</h2><p>Künstliche Intelligenz (KI) findet sich heutzutage scheinbar überall. Bereits ohne den derzeitigen Hype-Faktor um KI ist der Begriff nur schwer zu greifen. Viele Unternehmen sehen sich unter Zugzwang, KI als neue Technologie einzusetzen und deren Potentiale auszuschöpfen. Große Internet(!)-Konzerne haben das Geld, die Daten und Expertise in Data Science und zeigen, welche innovativen Produkte damit heute möglich sind.</p><p>Schon lange ist es zuverlässig möglich, Spam-E-Mails automatisch zu erkennen. Aktuelle KI-Technologien erlauben es Maschinen heute, E-Mails auch inhaltlich zu verstehen. Dadurch ergeben sich neue Möglichkeiten E-Mails automatisiert zu verarbeiten.</p><p>Darum geht es in diesem Artikel.</p><h2>Die Situation</h2><p>Stellen wir uns folgende Situation vor: die ACME Mobilfunkgesellschaft erhält täglich mehrere Tausend Kunden-E-Mails mit unterschiedlichsten Anliegen. Beim Großteil der Anliegen (~80%) handelt es sich um einfache Sachverhalte wie „Stammdatenänderung“, „Vertragsänderungen“ oder „Kündigungen“. Die restlichen ~20% der E-Mails sind komplexere Anliegen, etwa individuelle offene Fragen.</p><p>Um diese E-Mails zu verarbeiten und zu beantworten hat ACME eine eigene Customer-Support-Abteilung mit 952 Mitarbeiten. Je weiter ACME es schafft, die einfachen Sachverhalte automatisiert zu bearbeiten, desto mehr Zeit haben die Mitarbeiter, um individuelle Kundenanfragen personalisiert und kompetent zu beantworten.</p><p>Die Support-Abteilung hat ein typisches CRM-System, welches die Abteilung unterstützt. Es ist regelbasiert, d.h. E-Mails wurden lediglich nach bestimmten Schlagworten wie „Kündigung“ oder „Vertragsänderung“ durchsucht, um deren Intention zu erkennen. Das war bis vor kurzem kaum anders möglich.</p><p>Heute erlaubt es jedoch moderne NLP-Technologie, Systeme zu entwickeln, die den Kontext von E-Mails begreifen können. Diesen Fortschritt könnte ACME nutzen, um E-Mails verlässlicher einzuordnen und zu verarbeiten und Schritt für Schritt auch komplexere Sachverhalte zu automatisieren. Es ist sogar möglich geworden, mehrere Intentionen aus einer Freitext-E-Mail zuverlässig zu erkennen.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BRLAfgR6TwOURO4wJWwK"><img width="250" height="90" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BRLAfgR6TwOURO4wJWwK" alt="Textklassifizierung" /></a> </p><h2>Das KI-System</h2><p>Im Customer-Support bietet sich für Unternehmen häufig eine gute Möglichkeit, iterativ ein KI-System einzuführen und weiterzuentwickeln.</p><p>Das Ziel ist es hierbei mithilfe des KI-Systems, die automatisierte Verarbeitung von E-Mails zu verbessern. In der ersten Ausbaustufe könnte das System zunächst in der Lage sein, das Anliegen von Kunden-E-Mails zu erkennen und diese automatisiert an die richtige Stelle im Unternehmen weiterzuleiten.</p><p>Sobald dieses Basissystem produktiv ist, könnte dann begonnen werden, es inkrementell zu erweitern. Denkbar wären hier z.B. folgende Features:</p><ul><li>vorausgefüllte E-Mail Templates für Support-Mitarbeiter zur Beantwortung der E-Mails</li><li>sofortige, personalisierte und individuelle Rückmeldung des Systems an den Kunden</li><li>automatisierte Beantwortung einfacher Anfragen</li><li>automatisierte Bearbeitung einfacher Aufgaben, z.B. Update der Kundendaten bei Adressänderung</li></ul><p>Ein zusätzlicher Mehrwert kann darüber hinaus oft durch automatisierte Analysen der Kundenanfragen generiert werden.</p><ul><li>Welche Probleme hat die Kundschaft an einem bestimmten Tag beschäftigt?</li><li>Welche Probleme können frühzeitig erkannt und behoben werden?</li></ul><p>Unsere Projekterfahrung hat gezeigt, dass KI-unterstützte Support-Arbeitsplätze zu einer drastischer Verkürzung der Bearbeitungszeit von Kundenanfragen führen können. Durch Minimierung repetitiver Aufgaben kann zudem die Mitarbeiterzufriedenheit deutlich gesteigert werden.</p><h2>Löst KI jetzt alle Probleme?</h2><p>Häufig herrscht leider eine falsche Erwartungshaltung. KI wird mit menschlicher Intelligenz verglichen – davon sind wir aber noch weit entfernt. KI kann derzeit repetitive Aufgaben erlernen, aber noch lange nicht denken wie ein Mensch.</p><p>In einem ersten Impuls besteht die initiale Idee für ein KI-System oft darin, sehr komplexe Prozesse im Herzstück eines Unternehmens zu verbessern. Dies ist meist dem Hintergedanken geschuldet, sofort den maximalen Nutzen aus der neuen Technologie zu ziehen. Häufig befinden sich an diesen Stellen des Unternehmens auch tatsächlich große Hebel mit enormen Potenzialen, die perspektivisch genutzt werden können. Jedoch ist die Vorstellung, solche Prozesse durch ein KI-System zu verbessern, in vielen Fällen unrealistisch.</p><p>Dies liegt daran, dass die meisten relevanten Unternehmensprozesse meist schon über Jahre hinweg ohne KI, aber mit enormem Know-How-Einsatz sehr stark optimiert wurden. Zusätzlich fehlt oft jegliche Erfahrung mit KI-Systemen und die vorhandene IT-Infrastruktur ist nicht darauf vorbereitet, komplexe KI-Systeme zu entwickeln. Es kann daher fraglich sein, ob unter diesen Rahmenbedingungen ein erfolgreicher Schritt in Richtung KI möglich ist.</p><p>Eine Alternative hierzu ist es, zunächst an einem einfachen End-to-End KI-System Erfahrung über deren Entwicklung und Lebenszyklus zu sammeln. Neben dem gewünschten Erfahrungsaufbau zu KI-Systemen und einer Weiterentwicklung der IT-Infrastruktur, kann auch so bereits zusätzlicher Business Value mit KI generiert werden.</p><h2>Vorgehensweise</h2><p>Es ist ratsam, den abgegrenzten Use Case zunächst ohne zu viele Abhängigkeiten zu starten. Oft beobachten wir, dass erste Ziele zu hoch gesteckt werden und man sich in der Komplexität der Aufgabe verliert. Daher sollte der Fokus ausdrücklich darauf liegen, ein KI-System produktiv zu nehmen und dessen Lebenszyklus zu verstehen.</p><p>Für unser vorheriges Beispiel im Customer Support könnte dies bedeuten, dass man sich zunächst z.B. auf das Erkennen von Stammdatenänderung, Vertragsverlängerung und offenen Fragen konzentriert und die dafür nötige Infrastruktur aufbaut.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jR558MWIRDi73rXf2Y7h"><img loading="lazy" width="250" height="75" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jR558MWIRDi73rXf2Y7h" alt=" Künstliche Intelligenz" /></a> </p><p>Grundlage für die Entwicklung des Basissystems sind die folgenden vier Kernpunkte:</p><ul><li>Daten beschaffen und labeln</li><li>KI-System integrieren</li><li>Das Machine-Learning-Modell</li><li>Human assisted Feedback Loop</li></ul><p>Diese Kernpunkte werden wir nun etwas genauer beleuchten.</p><p><strong>Daten beschaffen und labeln</strong><br /> Ein entscheidender Schritt für KI-Systeme ist die Verfügbarkeit einer geeigneten Datenbasis. Um ein KI-System zur E-Mail Klassifikation zu trainieren, werden gelabelte Kunden-E-Mails benötigt. Das sind E-Mails, die bereits in eine Kategorie eingeordnet sind. Hierbei kann es in der Praxis eine erste Herausforderung sein, geeignete Kategorien festzulegen. Während z.B. „Stammdatenänderung“ noch recht generisch sind, spielt darüber hinaus schnell der konkrete Unternehmenskontext eine große Rolle.</p><p>Um das KI-System zu trainieren, wird insbesondere eine ausreichende Anzahl von E-Mails je Kategorie benötigt, um verlässliche Resultate erhalten zu können. Deswegen kann es sinnvoll sein, zunächst mit einer kleineren Menge an Kategorien zu starten, um diese dann später um weitere Kategorien zu ergänzen.</p><p><strong>KI-System integrieren</strong><br /> Ein häufig unterschätzter Fakt ist, dass KI-Systeme letztendlich Softwareprojekte sind. Um tatsächlich Business Value mithilfe eines KI-Systems zu generieren, muss es in Produktion gebracht werden. KI-Systeme enthalten zwar eine Machine-Learning-Komponente, diese ist allerdings nur ein Teil des Gesamtsystems. Bei allem Hype um all die neuen Möglichkeiten, die Neuronale Netze und moderne Technologien bieten, sollte daher das Gesamtbild nicht aus dem Blick verloren werden.</p><p>Auf den Use Case bezogen bedeutet dies, dass das Machine-Learning-Modell auf eine geeignete Weise deployed werden muss. Darüber hinaus müssen die eingehenden Kunden-E-Mails zum Modell gebracht werden, um diese dort zu klassifizieren. Anschließend sollten die klassifizierten E-Mails – mit dem entsprechenden Label versehen – an die richtige Stelle zur Weiterverarbeitung weitergeleitet werden. Die Gesamtheit all dieser Komponenten ist das eigentliche KI-System, welches dann auch in der Lage ist, einen Mehrwert zu generieren.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Yxu8EVRYRlaepRgX56bw"><img loading="lazy" width="250" height="93" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Yxu8EVRYRlaepRgX56bw" alt="Künstliche Intelligenz" /></a> </p><p><strong>Das Machine-Learning-Modell</strong><br /> Für viele Use Cases ist die Aufgabe ein geeignetes Machine-Learning-Modell zu finden äußerst komplex. Je nach Anforderung kann hier auch ein Deep-Learning-Modell – ein Modell basierend auf Neuronalen Netzen – erforderlich sein. Um ein solches Modell selbst zu entwickeln, wird ausreichend Data Science Know-How benötigt. Typischerweise gibt es hierfür eine Explorationsphase von ein paar Wochen, in denen Modelle evaluiert und schließlich ein erster Modell-Prototyp entwickelt wird.</p><p>Glücklicherweise ist E-Mail-Klassifikation schlicht Textklassifikation und das Problem ist im Deep-Learning-Bereich schon sehr gut verstanden. Daher besteht ein Vorteil unseres Beispiel-Use-Cases darin, dass es bereits fertige Modelle gibt, die man direkt verwenden kann. Es ist also möglich, für das vorgeschlagene Basis-KI-System ein bestehendes Open-Source-Modell zu verwenden, das von Data-Science-Experten unter Beachtung aktueller Best Practises entwickelt wurde.</p><p>Ein fertiges Modell kann beispielsweise aus dem beliebten Python-Modul spaCy entnommen und direkt trainiert werden.</p><p><strong>Human assisted Feedback Loop</strong><br /> Auch KI-Systeme machen Fehler. Sobald das KI-System produktiv ist, werden einige der eintreffenden E-Mails falsch klassifiziert werden. Das ist völlig normal und wird sich erfahrungsgemäß auch nicht vollständig vermeiden lassen. Auch ein Mensch wird in der Praxis Schwierigkeiten haben, alle eintreffenden Kunden-E-Mails stets korrekt einzuordnen. Und eine Gruppe von Personen wird bei einzelnen E-Mails unterschiedlicher Meinung sein, welche Klassifizierung richtig ist.</p><p>Ein KI-System kann sein volles Potenzial dann entfalten, wenn es sich regelmäßig weiter verbessern kann. Es ist sinnvoll, die klassifizierten E-Mails des Systems von einem Menschen verifizieren zu lassen. Dabei ist es wichtig, falsch zugeordnete E-Mails nicht einfach verärgert hinzunehmen, sondern diese mit dem richtigen Label zu versehen. Solche händisch korrigierten E-Mails sind sehr wertvoll und können gemeinsam mit den restlichen klassifizierten E-Mails dazu verwendet werden, die Anzahl an gelabelten E-Mails immer weiter zu vergrößern.</p><p>Dadurch vergrößert sich die Datengrundlage für das Training der Machine-Learning-Komponente ständig. Ab einer gewissen Menge an zusätzlichen Daten lohnt es sich, die Komponente erneut zu trainieren, um diese zu verbessern. Idealerweise ist das KI-System so konstruiert, dass es sich selbst regelmäßig neu trainiert und deployed.</p><p>So kann das KI-System immer besser und die Anzahl an händischen Korrekturen immer weiter reduziert werden.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HoI6c90QeOTokeERUM7h"><img loading="lazy" width="250" height="148" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/HoI6c90QeOTokeERUM7h" alt="Künstliche Intelligenz" /></a> </p><h2>Fazit</h2><p>Es ist sinnvoll, zunächst ein einfaches KI-System vollständig umzusetzen und dieses inkrementell weiter zu entwickeln. KI-Systeme sind Softwareprojekte, welche eine Machine-Learning-Komponente beinhalten. Um einen wirklichen Mehrwert zu erzeugen benötigt man neben Data Science Know-How auch Wissen über Daten-Pipelines und Continuous-Deployment-Strategien. Es ist ratsam, anhand eines einfachen KI-Systems und out-of-the-box Modells Erfahrung über den Lebenszyklus von KI-Systemen zu sammeln. Mit den daraus gewonnenen Erkenntnissen fällt es dann deutlich leichter, komplexere KI-Systeme zu entwickeln.</p><p>Wenn Sie mehr zum Thema NLP in unserem Blog lesen wollen, empfehlen wir den Artikel <a href="/wissens-hub/blog/natural-language-processing-basics" target="_blank"> NLP-Basics </a> . Allgemeine Informationen zum Thema KI haben wir auf <a href="/leistungen/kuenstliche-intelligenz" target="_blank"> codecentric.ai </a>  zusammengestellt.</p>

Kunden-E-Mails effizient verarbeiten – mit künstlicher Intelligenz

<p>Noch vor kurzer Zeit war E-Mail-Klassifikation mittels Deep Learning nur mit Spezialwissen und ausreichend Data Science Know-how möglich. Heute existieren sehr gute Open-Source-Bibliotheken mit fertigen Deep-Learning-Modellen, welche sehr weit optimiert sind und aktuellen Best Practices folgen. Mithilfe solcher Modelle kann man sofort und ohne viel Data Science Know-how Deep-Learning zur E-Mail-Klassifikation einsetzen.</p><p>Im Folgenden trainieren wir ein Deep-Learning-Modell der Open-Source-Bibliothek <a href="https://spacy.io/" target="_blank">spaCy</a> , um E-Mails zu klassifizieren. Das Beispiel ist so gedacht, dass es in einem Jupyter Notebook Schritt für Schritt nachvollzogen werden kann.</p><p>Warum es für Unternehmen hilfreich sein kann, sich mich E-Mail-Klassifikation zu beschäftigen, haben wir bereits im Blogpost <a href="/wissens-hub/blog/kunden-e-mails-effizient-verarbeiten-mit-kuenstlicher-intelligenz" target="_blank">Kunden-E-Mails effizient verarbeiten – mit Künstlicher Intelligenz </a>  beschrieben.</p><h2>Wie gehen wir vor?</h2><p>Unser Beispiel besteht aus vier Schritten:</p><h3>Daten beschaffen</h3><p>In der Praxis ist es häufig aufwändig einen Datensatz zu erstellen. Möchte man ein Modell zur Klassifikation von E-Mails aus einem spezifischen Unternehmenskontext trainieren, führt daran aber kein Weg vorbei. Neben dem Zusammenstellen der E-Mails gehört hierzu auch die Auswahl geeigneter Kategorien. Um brauchbare Ergebnisse erhalten zu können, benötigt man ausreichend (= mehrere Hundert) E-Mails pro Kategorie.</p><h3>Daten vorbereiten</h3><p>Typischerweise liegen die Daten nicht direkt in einem geeigneten Format vor. Daher ist es normalerweise notwendig, die Daten zunächst geeignet vorzubereiten. Ziel ist ein Datenformat, das einerseits statistische Analysen des Datensatzes erlaubt und mit dem andererseits leicht ein Modell trainiert werden kann.</p><h3>Modell trainieren</h3><p>Wir verwenden das in spaCy integrierte Deep-Learning Modell <code>textcat</code>. spaCy ist eine mächtige Open-Source Bibliothek für Python, die dafür gebaut wurde, Anwendungen im NLP-Bereich zu entwickeln. Um direkt loslegen zu können, beinhaltet spaCy bereits vortrainierte Sprachmodelle. Unsere Erfahrung zeigt, dass viele Use Cases bereits mit diesen Modellen umgesetzt werden können und es sich meistens nicht lohnt, ein eigenes Modell von Grund auf neu zu entwickeln.</p><h3>Modell evaluieren</h3><p>Abschließend überprüfen wir, wie gut das trainierte Modell neue E-Mails klassifiziert.</p><p>Fangen wir also an: Zunächst brauchen wir einen geeigneten Datensatz an E-Mails.</p><h2>Daten beschaffen</h2><p>Für unser Beispiel verwenden wir das öffentlich verfügbare <code>omqdata</code> Datenset, welches <a href="https://www.dfki.de/~neumann/resources/omqdata.html" target="_blank">hier</a>  heruntergeladen werden kann. Der Datensatz besteht aus E-Mails, die von Kunden an den Support eines Multimedia-Software-Unternehmens geschickt wurden.</p><p>Die E-Mails sind bereits anhand von Fehlermeldungen wie <code>"Fehlercode -9 beim Start des Programmes"</code> oder <code>"Altes Programm soll unter Windows 7 installiert werden"</code> in Kategorien eingeteilt. Verwandte Fehlermeldungen sind in Kategoriegruppen zusammengefasst. So sind zum Beispiel in Kategoriegruppe 6 die Fehlermeldungen <code>"Fehlercode -9 beim Start des Programmes"</code>, <code>"Fehler 9000 bei der Programminstallation"</code> und <code>"Programm startet nicht"</code> zu finden.</p><p>Im Folgenden gehe ich davon aus, dass der Datensatz heruntergeladen wurde und in einem Ordner entpackt vorliegt. Das XML-File <code>omq_public_interactions.xml</code> unseres Datensatzes enthält die E-Mails. Diese sind anhand von 41 unterschiedlichen Fehlermeldungen eingeordnet. Im XML-File <code>omq_public_categories.xml</code> befindet sich die Zuordnung der Fehlermeldungen in 20 Kategoriegruppen.</p><p><code>xml</code>-Files sind für die weiteren Schritte unhandlich. Wir bereiten daher im nächsten Schritt unsere Daten zur Weiterverarbeitung vor.</p><h2>Daten vorbereiten</h2><p>Um die Daten vorzubereiten, verwenden wir die Python-Module</p><div>

```python
import os
import pandas as pd
import numpy as np
import random
from bs4 import BeautifulSoup
```

</div><p>Außerdem bezeichnen wir mit <code>PATH_TO_DATA</code> den Pfad zum Ordner mit unserem Beispieldatensatz. Die E-Mails und Kategorien können dann mithilfe des Code-Blocks</p><div>

```python
def get_nice_text(item):
    text = item.getText()
    text = text.replace('\r',' ')
    text = text.replace('\n','')
    return text.strip()
 
with open(os.path.join(PATH_TO_DATA,'omq_public_interactions.xml'), 'rb') as f:
    soup = BeautifulSoup(f.read(), 'html.parser')
 
mails = soup.find_all("text")
categories = soup.find_all("category")
 
rows = []
for item, cat in zip(mails, categories):
    text = get_nice_text(item)
    categories = cat.getText().split(',')
    if len(categories) > 0:
        category = random.choice(categories)
    else:
        category = np.nan
    rows = rows + [[text, categories, category]]
 
df = pd.DataFrame(rows, columns=['text', 'categories', 'category'])
```

</div><p>geparsed und in einem Pandas Dataframe gespeichert werden.</p><p>Im Datensatz befinden sich neun E-Mails, die mehr als einer Kategorie zugeordnet sind. Für unser Beispiel haben wir für die neun E-Mails einfach zufällig eine der Kategorien ausgewählt. Dadurch liegt nun ein Datensatz vor, in dem jede E-Mail genau einer Kategorie zugeordnet ist.</p><p>In der Praxis kann Multiklassifikation sinnvoll sein. Kunden können beispielsweise mehr als ein Anliegen in einer E-Mail beschreiben. Grundsätzlich kann das spaCy Modell mit Multiklassifikation umgehen, dies würde aber den Rahmen unseres Beispiels sprengen.</p><p>Es ist oft hilfreich, die Daten als Pandas DataFrame vorliegen zu haben, um das Datenset zu explorieren und statistische Analysen zu machen. So kann man zum Beispiel über</p><div>

```python
df.categories.value_counts()
```

</div><p>sehen, wie viele E-Mails jeder Kategorie im Datensatz enthalten sind.</p><p>Grundsätzlich ist es sinnvoll, die Daten zu untersuchen, bevor man ein Modell damit trainiert. Die Analyse des Datensatzes ist aber nicht Gegenstand dieses Blogposts. Wer mehr über Datenanalyse und spaCy wissen möchte, kann zum Beispiel <a href="/wissens-hub/blog/natural-language-processing-basics" target="_blank">hier</a>  fündig werden.</p><p>Mit dem nachfolgenden Code-Block schreiben wir die Zuordnung der Kategorien in Kategoriegruppen in ein weiteres Pandas DataFrame.</p><div>

```python
with open(os.path.join(PATH_TO_DATA, 'omq_public_categories.xml'), 'rb') as f:
    soup = BeautifulSoup(f, 'html.parser')
 
categoryGroups = soup.find_all('categorygroup')
 
rows = []
for group in categoryGroups:
    group_id = group['id']    
    categories = group.find_all('category')
    cat_ids = []
    for cat in categories:
        cat_id = cat['id']
        cat_ids.append(cat_id)
        cat_text = get_nice_text(cat)
    rows = rows + [[group_id, cat_ids, cat_text]]
 
df_cat = pd.DataFrame(rows, columns=['group_id', 'cat_ids', 'cat_text'])
```

</div><p>Im letzten Schritt ordnen wir nun allen E-Mails die zugehörige Kategoriegruppe zu.</p><div>

```python
def get_encode_dic():
    encode_dic = {}
    for index, row in df_cat.iterrows():
        for cat_id in row.cat_ids:
            encode_dic[cat_id] = row.group_id
    return encode_dic
 
encode_dic = get_encode_dic()
df['category_group'] = df.category.map(encode_dic)
```

</div><p>Es ist eine gute Praxis, keine „Jupyter Notebook Monolithen“ zu bauen und das erste Notebook hier zu beenden. Die Ergebnisse der Datenvorbereitung können über den Befehl</p><div>

```python
df.to_pickle(os.path.join(PATH_TO_DATA, 'processed_mails.pkl'))
```

</div><p>gespeichert werden. Wir verwenden nun die <code>processed_mails</code> im nächsten Notebook, um ein Modell zu trainieren. Das Modell soll E-Mails der korrekten Kategoriegruppe zuordnen.</p><h2>Modell trainieren</h2><p>Wir verwenden die Python-Module</p><div>

```python
import os
import spacy
import pandas as pd
 
from spacy import displacy
from spacy.util import minibatch, compounding, decaying
 
from sklearn.model_selection import StratifiedShuffleSplit
```

</div><p>Zunächst laden wir mit dem Befehl</p><div>

```python
df = pd.read_pickle(os.path.join(PATH_TO_DATA, 'processed_mails.pkl'))
```

</div><p>die gerade vorbereiteten E-Mail-Daten in unser Notebook. Bevor wir mit dem Training des Modells beginnen, teilen wir den Datensatz via</p><div>

```python
X_all = df.text
y_all = df.category_group
 
seed = 42
sss = StratifiedShuffleSplit(n_splits=1, test_size=0.15, random_state=seed)
for train_index, test_index in sss.split(X_all, y_all):
    X_train, X_test = X_all.iloc[train_index], X_all.iloc[test_index]
    y_train, y_test = y_all.iloc[train_index], y_all.iloc[test_index]
```

</div><p>in Trainings- und Testdaten auf. So haben wir später noch E-Mails übrig, mit denen wir unser trainiertes Modell evaluieren können.</p><p>spaCy erwartet die eingehenden Trainingsdaten in einem bestimmten Format, in welches wir unsere Trainingsdaten via</p><div>

```python
cats = df.category_group.unique()
 
def get_catlist(y):
    cat_list = []
    for _, val in y.iteritems():
        categories = {'cats': {cat: 0.0 for cat in cats}}
        if val in cats:
            categories['cats'][val] = 1.0
        cat_list.append(categories)
    return cat_list
 
data_train = list(zip(X_train.values, get_catlist(y_train)))
```

</div><p>überführen können.</p><p>spaCy verfügt über ein vortrainiertes deutsches Sprachmodell, das wir im Folgenden verwenden möchten. Dieses muss zum Beispiel via</p><div>

```bash
python -m spacy download de_core_news_sm
```

</div><p>über die Konsole heruntergeladen werden. Danach laden wir mit</p><div>

```python
nlp = spacy.load('de_core_news_sm')
```

</div><p>das deutsche Sprachmodell in unser Notebook und aktivieren über</p><div>

```python
if 'textcat' not in nlp.pipe_names:
    textcat = nlp.create_pipe('textcat')
    nlp.add_pipe(textcat, last=True)
```

</div><p>das spaCy-Modell <code>textcat</code> zur Textklassifizierung. Als nächstes fügen wir über</p><div>

```python
for cat in cats:
    textcat.add_label(cat)
```

</div><p>die Kategorien unserer E-Mails hinzu. Jetzt können wir mit dem Training beginnen.</p><p>Da wir lediglich die Textklassifizierung trainieren und das Sprachmodell ansonsten nicht verändern möchten, schalten wir alles andere während des Trainings aus. Der folgende Code-Block trainiert <code>textcat</code> mit <code>n_iter</code> Durchläufen durch den Trainingsdatensatz.</p><div>

```python
other_pipes = [pipe for pipe in nlp.pipe_names if pipe != 'textcat']
 
n_iter = 10
with nlp.disable_pipes(*other_pipes):  
    optimizer = nlp.begin_training()
    print("Training the model...")
    print('{:^5}'.format('LOSS'))
    for i in range(n_iter):
        losses = {}
        dropout = decaying(0.6, 0.2, 1e-4)
        batches = minibatch(data_train, size=compounding(1., 16., 1.001))
        for batch in batches:
            texts, annotations = zip(*batch)
            nlp.update(texts, annotations, sgd=optimizer, drop=next(dropout), losses=losses)
        print('{0:.3f}'.format(losses['textcat']))
```

</div><p>spaCy bietet verschiedene Möglichkeiten, Einfluss auf das Training zu nehmen und verschiedene fortgeschrittene Techniken zum Trainieren einzusetzen. Wer sich dafür interessiert, kann <a href="https://spacy.io/usage/training#tips" target="_blank">hier</a>  fündig werden. Je nach Projektkontext gilt es aber frühzeitige Optimierungen zu vermeiden. Ein solides Modell in Produktion ist oft besser als Ideen für ein optimiertes Modell im Jupyter Notebook.</p><h2>Evaluation</h2><p>Unser Modell können wir nun mithilfe der Testdaten evaluieren. Durch</p><div>

```python
def keywithmaxval(d):
    v=list(d.values())
    k=list(d.keys())
 
    return k[v.index(max(v))]
 
y_pred = []
for _, text in X_test.iteritems():
    doc = nlp(text)
    cat_pred = keywithmaxval(doc.cats)
    y_pred.append(cat_pred)
```

</div><p>erhalten wir die Vorhersagen unseres trainierten Modells für die E-Mails des Testdatensatzes. Nun können wir mittels</p><div>

```python
import matplotlib.pyplot as plt
import seaborn as sns;
from sklearn.metrics import classification_report, confusion_matrix
 
mat = confusion_matrix(y_test, y_pred, labels=cats)
plt.figure(figsize = (10,7))
sns.set(font_scale=1.2)
sns.heatmap(mat, square=True, annot=True, cbar=False, cmap="YlGnBu",annot_kws={"size": 13}, xticklabels=cats, yticklabels=cats)
plt.xlabel('Predicted label')
plt.ylabel('True label')
plt.show()
 
print(classification_report(y_test, y_pred, labels=cats))
```

</div><p>einerseits eine <a href="https://en.wikipedia.org/wiki/Confusion_matrix" target="_blank">Confusion Matrix</a>  und einen classification_report mit den Werten für Accuracy, Recall und F1-Score zu allen Kategorien erhalten. Anhand dieser Metriken kann man die Qualität des Modells in einer ersten Iteration ganz gut beurteilen.</p><p>Für unser vorliegendes Beispiel bekomme ich mit <code>n_iter = 25</code> die folgende Confusion Matrix.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/plud0f5qRMSQbigNN12r"><img width="250" height="248" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/plud0f5qRMSQbigNN12r" alt /></a> </p><p>Die Ergebnisse sind für den vorliegenden kleinen Datensatz schon ganz gut. So wird zum Beispiel die Kategoriegruppe 12 <code>"Problemen mit der Registrierung der Software"</code> recht zuverlässig erkannt.</p><p>Auffällig ist Kategoriegruppe 16 <code>"Kein Brenner gefunden"</code>. Hier wurden zwar alle vier im Testdatensatz enthaltenen E-Mails richtig erkannt, jedoch sind auch viele andere E-Mails fälschlicherweise dieser Kategoriegruppe zugeordnet. Um die Ergebnisse weiter zu verbessern gibt es verschiedene Möglichkeiten. Die wirksamste Möglichkeit ist bei Deep-Learning-Modellen in der Regel, dass man “einfach” mit einem größeren Datensatz trainiert. Insbesondere sind für einige Kategoriegruppen etwa von 1, 13, und 18 fast gar keine E-Mails im Datensatz vorhanden.</p><p>Für eine wirklich fundierte Beurteilung der Qualität des Modells reicht unser Beispieldatensatz leider nicht aus.</p><h2>Fazit</h2><p>In diesem Blogpost haben wir gesehen, dass es mithilfe von Open-Source-Bibliotheken wie spaCy heute möglich ist, ohne viel Data Science Know-how mit modernen Deep-Learning-Modellen E-Mails zu klassifizieren. Dabei wird sich der grundsätzliche Ablauf für einen anderen Datensatz nur minimal ändern.</p><p>Die Hürde für Softwareprojekte mit Deep-Learning-Anteil ist dadurch deutlich niedriger geworden. Es ist möglich, einen echten Mehrwert mit Deep-Learning zu erzeugen, ohne in einer Explorationsphase von mehreren Wochen mit viel Spezialwissen zunächst Modelle zu entwickeln und zu evaluieren.</p><p>Wer mehr über NLP erfahren möchte findet <a href="https://www.youtube.com/watch?v=GmLsb-o7hvM" target="_blank">hier</a>  ein passendes Video.</p><p>Mehr Informationen zum Thema Künstliche Intelligenz haben wir auf <a href="/leistungen/kuenstliche-intelligenz" target="_blank"> codecentric.ai </a>  zusammengestellt.</p>

E-Mail-Klassifizierung mit SpaCy

<p>Noch vor kurzer Zeit war der Einsatz von künstlicher Intelligenz (KI) nur mit großem Aufwand und ausreichend Spezialwissen möglich. Hauptsächlich große Internet-Konzerne wie Google, Apple und Facebook hatten das Geld, die Daten und die Expertise, um mittels KI innovative Produkte und Services zu entwickeln und damit Geld zu verdienen.</p><p>Inzwischen ist die Eintrittshürde für den Einsatz von KI erheblich gesunken. Aktuelle Entwicklungen, vor allem im Bereich von Cloud-Computing-Diensten, ermöglichen es nun auch kleinen und mittelständischen Unternehmen (KMU), kosteneffizient KI anzuwenden. Dabei heißt KI einzusetzen heutzutage nicht mehr zwingend in Forschung zu investieren, sondern sie in vielen Fällen schlicht anzuwenden.</p><p>Ein möglicher Anwendungsfall in diesem Kontext ist die KI-unterstützte (Teil-)Automatisierung der Qualitätskontrolle von Bauteilen basierend auf Bilderkennung, mit dem wir uns in diesem Artikel beschäftigen.</p><h2>Die Situation</h2><p>Der mittelständische ACME Zulieferungsbetrieb produziert täglich Bauteile in hoher Stückzahl und liefert diese in Großaufträgen an seine Kunden aus. Die Kunden von ACME legen großen Wert auf Qualität, und bereits wenige fehlerhafte Bauteile können zur Ablehnung eines gesamten Auftrags und damit zu großen Verlusten für ACME führen.</p><p>Aus diesem Grund hat ACME strenge Qualitätskontrollen etabliert. Hier werden unter hohem menschlichen Einsatz alle produzierten Bauteile manuell überprüft. Der Großteil der manuell überprüften Teile ist dank dieser Sorgfalt fehlerfrei. Die fehlerhaften Bauteile müssen dagegen häufig im Detail überprüft werden, da neben der Beurteilung auch der Grund für den Fehler gefunden werden muss. Für diese Begutachtung ist mehrjährige Erfahrung und dediziertes Domänen-Wissen notwendig.</p><p>Zur Kontrolle von Bauteilen und zur Qualitätssicherung beschäftigt ACME 53 Mitarbeiter*innen. Je weiter ACME es schafft, einfache Sachverhalte und Standardfälle automatisiert zu bearbeiten, desto mehr Zeit haben die Mitarbeiter*innen, um Spezialfälle zu beurteilen und Fehlerursachen zu verstehen.</p><p>ACME verfügt nicht über KI-Know-how. Die Firma hat auch kein Bestreben in ein ungewisses Feld wie KI-Forschung zu investieren und sieht auch keinen Bedarf eine Data-Science-Abteilung aufzubauen. Stattdessen möchte sich ACME nach wie vor darauf fokussieren, seinen Status als Hidden Champion auszubauen. Hierfür investiert ACME regelmäßig in aktuelle Zukunftstechnologie.</p><p>Durch Cloud-Computing-Dienste bietet sich für ACME eine gute Möglichkeit, moderne KI-Technologie einzusetzen und iterativ ein KI-System in der Qualitätskontrolle einzuführen – ganz ohne hohes Anfangsinvestment in KI-Forschung. Schritt für Schritt kann der Grad an Automatisierung weiter ausgebaut werden. So können perspektivisch nicht nur Fehler, sondern auch Fehlertypen automatisiert erkannt werden.</p><h2>Ein KI-System in der Qualitätskontrolle</h2><p>Das grundsätzliche Ziel für ein (teil-)automatisiertes System zur Qualitätskontrolle von Bauteilen basierend auf Bilderkennung ist es, den Automatisierungsgrad der Qualitätskontrolle schrittweise zu erhöhen. In der ersten Stufe sortiert das System neu produzierter Bauteile mittels einer KI-Komponente in die Klassen „okay“, „defect“ und „unclear“. Die Idee ist im folgenden Bild dargestellt.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/GSzoG9Z9RJiEqDfFQb7O"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/GSzoG9Z9RJiEqDfFQb7O" alt="Teil-automatisiertes KI-System zur Qualitätskontrolle mit menschlicher Entscheidungshilfe bei unsicheren KI-Entscheidungen" width="346" height="223" /></a> <p>Teil-automatisiertes KI-System zur Qualitätskontrolle mit menschlicher Entscheidungshilfe bei unsicheren KI-Entscheidungen</p></div><p>In der Kategorie „unclear“ finden sich alle Bauteile, deren Qualität die KI nicht mit ausreichender Sicherheit bestimmen konnte. Das Maß an notwendiger Sicherheit lässt sich von außen vorgeben. So können z.B. nur solche Entscheidungen der KI akzeptiert werden, welche mit über 98 % Wahrscheinlichkeit getroffen wurden.</p><p>Nach dieser Beurteilung durch die KI sollten die mit „okay“ klassifizierten Bauteile perspektivisch ohne menschliche Eingriffe akzeptiert werden. Bauteile, welche durch die KI nur mit unzureichender Sicherheit klassifiziert und damit „unclear“ sind, müssen manuell nachbearbeitet werden. Die Bauteile in der Klasse „defect“ sind Gegenstand manueller Bearbeitung von Spezialist*innen. Hier liegt das Hauptaugenmerk auf Analyse des Fehlers und der Erforschung der Fehlerursachen.</p><p>Entscheidend für die Weiterentwicklung und Verbesserung des Systems ist dabei, dass alle Daten, die durch manuelle Bearbeitung entstehen, gesammelt werden. So eröffnet sich einerseits die Möglichkeit einen Feedback-Loop zu schaffen und die KI in regelmäßigen Abständen auf mehr Daten zu trainieren und so zu verbessern. Andererseits entsteht eine wertvolle Datenbasis, welche zukünftige weitere Ausbaustufen des Systems erlaubt.</p><h2>Vorgehensweise</h2><p>Es ist ratsam, zunächst mit einem abgegrenzten Use Case ohne zu viele Abhängigkeiten zu starten. Oft beobachten wir, dass in den ersten Feldversuchen die Ziele zu hoch gesteckt werden und man sich in der Komplexität der Aufgabe verliert. So ist es in der Praxis meistens unrealistisch, direkt in den ersten Schritten einen hohen Grad an Automatisierung anzustreben.</p><p>Anstatt sehr viel Zeit und Geld in die Entwicklung des „perfekten“ KI-Modells zu investieren, ist es häufig erfolgsversprechender, zunächst ein (teil-)automatisiertes System zu entwickeln. Dabei liegt der Fokus darauf das System tatsächlich in den bestehenden Prozess zu integrieren, um den Return on Investment schnellstmöglich zu erreichen. In dieser Phase treten typischerweise die eigentlichen Probleme auf, die gelöst werden müssen, bevor ein Mehrwert erzielt werden kann.</p><p>Grundlage für die Entwicklung ein erstes Basissystem sind die folgenden drei Kernpunkte:</p><ul><li>Daten beschaffen und labeln</li><li>Woher kommt die KI?</li><li>Integration in den Prozess</li></ul><p>Diese werden wir nun etwas genauer beleuchten.</p><h3>Daten beschaffen und labeln</h3><p>Ein entscheidender Schritt für KI-Systeme ist die Verfügbarkeit einer geeigneten Datenbasis. Um ein KI-System zur Qualitätskontrolle zu trainieren, werden gelabelte Bilder von Bauteilen benötigt. Für die erste Ausbaustufe sind das Bilder, die bereits in eine Kategorie „okay“ oder „defect“ eingeordnet sind. Für weitere Ausbaustufen etwa für die Erkennung von Fehlertypen wird eine ausreichende Anzahl von Bildern je Kategorie benötigt, um verlässliche Resultate erhalten zu können.</p><p>In vielen Fällen bildet die gelabelte Datenbasis den eigentlichen Wert des KI-Systems. So ist etwa ein gutes fachliches Verständnis der Domäne notwendig, um geeignete Kategorien und Gruppen von Fehlertypen festzulegen. Daher kann es für den ersten Schritt auch sinnvoll sein, das System ohne gut funktionierende KI zu integrieren und schlichtweg Daten zu sammeln.</p><h3>Woher kommt die KI?</h3><p>Die traditionelle Entwicklung eines KI-Modells ist häufig mit großen Schmerzen und Aufwand verbunden. Dies entspricht in vielen Fällen nach wie vor der Realität. Eigene KI-Modelle von Grund auf selbst zu entwickeln, ist in den meisten Fällen eine nicht zu unterschätzende Aufgabe. In der Praxis führt dieses Unterfangen viele Unternehmen in eine <a href="/wissens-hub/blog/wie-man-data-science-projekte-nicht-in-die-poc-sackgasse-manoevriert" target="_blank">Sackgasse</a>  und das damit verbundene Investment zahlt sich nicht aus.</p><p>Hier spielt der Teilbereich „Bilderkennung mit KI“ jedoch eine Sonderrolle, denn dieser gehört zu den am Besten gelösten Problemen im gesamten KI-Umfeld. So stellen heute viele Cloud-Anbieter bereits ausgereifte KI-Services wie zum Beispiel <a href="https://github.com/naxty/gcp-automated-quality-inspection" target="_blank">AutoML (Google Cloud)</a> , <a href="/wissens-hub/blog/bildklassifikation-mit-amazon-sagemaker" target="_blank">Sagemaker</a> <span><a href="/wissens-hub/blog/bildklassifikation-mit-amazon-sagemaker"> (Amazon Webservices)</a>  und <a href="https://azure.microsoft.com/de-de/services/cognitive-services/" target="_blank">Cognitive Services (Microsoft Azure)</a>  zur Verfügung. Dies eröffnet die Möglichkeit, aktuelle KI-Technologien zu verwenden, ohne in Forschung und Entwicklung investieren zu müssen und ohne tiefes Spezialwissen aufzubauen.</span></p><p>Auf diese Weise kann man mit fundiertem Basiswissen bereits in wenigen Schritten ein State-of-the-art-KI-Modell zur Bildklassifikation basierend auf einem eigenen Datensatz trainieren. Das resultierende KI-Modell ist für viele Anwendungsfälle „gut genug“, um einen Mehrwert zu erzielen und kann daher zur Integration in den Prozess verwendet werden.</p><p>Es ist grundsätzlich denkbar und oft auch möglich für konkrete Anwendungsfälle bessere Modelle zu entwickeln. Dies erfordert jedoch tiefgreifendes Spezialwissen und ist typischerweise mit erheblichem Aufwand und damit Kosten verbunden. Oft stehen hier Kosten und Nutzen in keinem sinnvollen Verhältnis.</p><p>Bei einem „eigenen“ Modell müssen zudem viele technische Themen wie z. B. das Deployment des Modells und Versionierung selbst gelöst werden, welche der Cloud-Anbieter in seinem Service out-of-the-box mitbringt.</p><h3>Integration in den Prozess</h3><p>Wenn mit einem KI-System die Qualitätskontrolle schrittweise automatisiert werden soll, besteht die eigentliche Herausforderung nicht darin ein KI-Modell zu entwickeln, sondern darin dieses System tatsächlich in den Gesamtprozess zu integrieren. Hierbei ist unbestritten, dass das System Fehler machen wird und typischerweise ist es auch mit einem KI-System nicht wirtschaftlich eine Fehlerrate von 0 % anzustreben. Ein KI-System bietet dagegen häufig die Möglichkeit, eine tolerierbare Fehlerrate effizienter zu erreichen.</p><p>Unserer Erfahrung nach ist dabei entscheidend, das System von Anfang an nicht mit dem Gedanken „Mensch kontrolliert Maschine“ oder „Mensch überprüft die Entscheidungen der Maschine“, sondern mit dem Grundsatz „Maschine entscheidet und der Mensch unterstützt den Prozess“ aufzusetzen, um die Effizienzgewinne mittelfristig auch tatsächlich realisieren zu können.</p><p>„Die Maschine entscheidet“ kann in diesem Fall auch heißen, Bauteile als „unclear“ zu klassifizieren und damit an einen Menschen zu übergeben. Entscheidend ist es, als „okay“ klassifizierten Bauteile so zu akzeptieren und eine etwaige Fehlerrate in Kauf zu nehmen.</p><p>Um die notwendige Akzeptanz der Entscheidungen KI-Systems zu gewährleisten und die Fehlerrate des Systems periodisch zu überprüfen, sind regelmäßige Benchmarks essenziell. Oft genügt es, den Benchmark nur mit der KI-Komponente digital durchzuführen. Dies kann unabhängig von der Produktion der Bauteile durchgeführt werden. Zudem liefern diese Tests Informationen darüber, wie der Schwellenwert für die Akzeptanz der KI-Entscheidungen im System justiert werden soll.</p><h2>Fazit</h2><p>In der Qualitätskontrolle bietet sich für viele mittelständische Unternehmen heute eine gute Möglichkeit, aktuelle KI-Technologie einzusetzen. KI ist nun in vielen Bereichen greifbar geworden, nicht zuletzt durch aktuelle Weiterentwicklungen von Public-Cloud-Diensten. Dadurch bedeutet die Verwendung von KI nicht mehr zwingend in Forschung zu investieren und tiefes Spezialwissen aufzubauen, sondern bewährte Technologie einzusetzen.</p><p>Die Nutzung von Cloud-Diensten senkt die Eintrittsbarriere erheblich und ermöglicht es insbesondere nicht Software-affinen Unternehmen, sich auf ihre Wertschöpfungskette zu konzentrieren. Auf diese Weise kann KI in vielen Fällen zu einem sinnvollen Investment in aktuelle Zukunftstechnologien werden.</p><p>Unserer Herangehensweise an KI-Projekte haben wir in unserem <a href="https://www.codecentric.de/wissens-hub/webinare/webinar-data-science-projekte" target="_blank">On-Demand-Webinar (Deutsch)</a>  vorgestellt.</p><p>Jetzt einen unverbindlichen Austausch anfordern über <a href="mailto:ki@codecentic.de">ki@codecentic.de</a> .</p>

KI für KMU: (Teil-)Automatisierung der Qualitätskontrolle von Bauteilen

<p>Warum gelingt es Data-Science-Initiativen häufig nicht, einen echten Mehrwert zu schaffen? Wir haben einige Ursachen dafür ausgemacht. In diesem Blogpost stellen wir vier typische Fallen für Data-Science-Projekte vor und geben Tipps, wie Du sie umschiffen kannst.</p><p><strong>Hinweis: Dieser Artikel erschien ursprünglich im Softwerker-Magazin Vol. 14. <a href="https://www.codecentric.de/wissens-hub/softwerker/softwerker-14" target="_blank">Das gesamte Heft kann hier als PDF heruntergeladen werden</a> .</strong></p><p>Seien wir ehrlich: Obwohl der <a href="/wissens-hub/blog?q=ki">Künstliche-Intelligenz</a> -Hype aktuell überall zu spüren ist, gelingt es den meisten Unternehmen derzeit noch nicht, mit ihren Data-Science-Initiativen einen Mehrwert für sich oder ihre Kunden zu schaffen. Im Gegenteil: Wir erleben oft, dass sehr viel Budget in Data-Science-Projekte investiert wird, aber nach dem x-ten Proof of Concept (PoC) noch kein Geld verdient wurde.</p><p>In vielen Fällen beobachten wir sogar, dass Data-Science-Projekte nicht fortgeführt werden und stattdessen abrupt enden, obwohl es eigentlich erfolgreiche Proofs of Concept gab. Bevor der erste Euro verdient wurde, wird stattdessen häufig schon ein weiterer Proof of Concept gestartet. So hangeln sich die Data Scientists von PoC zu PoC und werden irgendwann mit der unangenehmen Wahrheit konfrontiert, dass trotz aller Bemühungen kein Business Value geschaffen wurde. Da auch wir und unsere Data Scientists regelmäßig an solchen Projekten beteiligt sind, sind wir diesem Problem auf den Grund gegangen und möchten im Folgenden einige Erkenntnisse teilen.</p><h2>Abgrenzung</h2><p>Der Artikel fokussiert sich auf die Verprobung einer Idee im Data-Science-Kontext, mit dem Ziel, daraus ein Produkt zu entwickeln und damit Geld zu verdienen. Neben diesem Fokus kann es für Data-Science-Projekte auch das Ziel geben, neue Technologien kennenzulernen und deren Potenzial abzuschätzen. Dabei steht eventuell zunächst nicht die kommerzielle Nutzung dieser Technologie im Vordergrund. Solche Projekte benötigen in der Regel eine andere Steuerung, etwa über die Begrenzung des Budgets oder der Zeit für das Projekt.</p><h3>Quellen</h3><p>Während wir die nachfolgend beschriebenen Situationen in unserem Projektalltag regelmäßig antreffen, basieren die empfohlenen Lösungsansätze auf Ideen und Konzepten verschiedenster Quellen im Kontext von „Lean Product Development“. Maßgeblich inspiriert wurde der Artikel insbesondere durch die Arbeiten, die in den Referenzen <a href="https://developers.google.com/machine-learning/guides/rules-of-ml/" target="_blank">[1]</a>  <a href="https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf" target="_blank">[2]</a>  <a href="http://theleanstartup.com/book" target="_blank">[3]</a>  <a href="https://multithreaded.stitchfix.com/blog/2019/03/11/FullStackDS-Generalists/" target="_blank">[4]</a>  <a href="http://lpd2.com/" target="_blank">[5]</a>  aufgeführt sind (s. Artikelende).</p><h2>Fokus auf den Business Case</h2><p>Viele Data-Science-Projekte starten ohne ausreichend geschärften Business Case. Das ist zunächst einmal nicht unbedingt schlimm. Problematisch kann es jedoch werden, wenn der Business Case in der Anfangsphase des Projekts nicht weiter verfeinert und geschärft wird. Idealerweise unterstützt bereits der PoC dabei, den eigentlichen Business Case zu validieren.</p><p>Ein Beispiel: Die Churn Rate beschreibt den Anteil der Bestandskunden eines Unternehmens, die innerhalb eines Zeitfensters das Unternehmen verlassen. Eine Churn Rate von 2 % pro Monat bedeutet zum Beispiel, dass das Unternehmen jeden Monat 2 % seiner Bestandskunden verliert. Um gesund zu bleiben, ist es für das Unternehmen sehr wichtig, diese Churn Rate zu kompensieren – etwa durch Neukundengewinnung. Typischerweise ist das Gewinnen neuer Kunden jedoch deutlich teurer, als Bestandskunden zu halten. Um gezielt diejenigen Kunden anzusprechen, die für das Unternehmen interessant sind, aber potentiell abwandern, ist daher Churn Prediction ein weit verbreiteter Anwendungsfall.</p><p>Nehmen wir an, wir möchten validieren, ob es sinnvoll ist, Churn Prediction zu betreiben. Einem ersten Impuls folgend, wird ein PoC mit der Frage  „Können wir Churn vorhersagen?” oder „Wie gut können wir Churn vorhersagen?“ gestartet. Zur Beantwortung der ersten Frage benötigt man streng genommen keinen PoC, denn die Antwort ist schlicht: „Ja!“. Die zweite Frage ist schon besser, führt aber immer noch etwas an der eigentlichen Kernfrage „Kann ich mit Churn-Prediction einen Mehrwert für das Unternehmen schaffen?“ vorbei.</p><p>In einem PoC herauszufinden, dass man für 40 % aller Kunden Churn korrekt vorhersagen kann, ist nur ein Teilaspekt, denn eine Genauigkeit von 40 % kann je nach Kontext gut oder schlecht sein. Um wirklich eine Vorstellung davon zu entwickeln, wie die 40 % einzuschätzen sind, muss man den zugrundeliegenden Business Case genauer untersuchen. Dazu gehört es einerseits, konkrete Maßnahmen zu finden, mit denen man potentiellen Churn möglicherweise verhindern kann. Andererseits müssen konkrete Annahmen zu Kosten und Nutzen dieser Maßnahmen getroffen und validiert werden.</p><p>Ein Ziel des PoCs wäre es dann, konkrete Annahmen darüber zu treffen, was eigentlich passieren muss, dass mit der zugrundeliegenden Idee – z. B. Churn Prediction  –  ein Mehrwert geschaffen werden kann. Ein Schritt, der in diese Richtung führt, ist es, statt lediglich die Genauigkeit des Modells zu betrachten, eine konkrete Business-Metrik zu entwickeln. Die Genauigkeit des Modells oder andere Modelleigenschaften spielen hierbei natürlich eine Rolle, sind aber nur Faktoren neben Größen wie „Kosten für Neukundengewinnung“ oder „Kosten für Gutscheine, um die Kunden zu behalten“, um den Business Case zu beurteilen.</p><p>In der Anfangsphase ist es dazu häufig notwendig, pragmatische Annahmen für verschiedene Faktoren zu treffen. Im Beispiel Churn Prediction ist es etwa sehr schwer vorherzusagen, wie viele Kunden aufgrund eines Gutscheins letztlich nicht kündigen werden. Dennoch spielt dieser Anteil eine große Rolle für den Erfolg der Idee und es ist wichtig, diese Größe in einer Business-Metrik transparent zu machen. Das Ziel ist es, eine initiale Metrik zu entwickeln, die auf konkreten Annahmen beruht. Basierend auf neuen Erkenntnissen und im Projektverlauf kann die Metrik dann stets iterativ verfeinert und die Annahmen können validiert werden.</p><p>Ohne Fokussierung auf den Business Case wird häufig zu spät oder gar nicht in Betracht gezogen, was überhaupt alles passieren muss, um tatsächlich Geld mit der Ausgangs-Idee zu verdienen. Oft beobachten wir, dass diese Fragen bewusst zum Projektstart ausgeklammert werden. In vielen Fällen führt diese Unklarheit aber letztlich dazu, dass die Data-Science-Initiative nach dem PoC nicht fortgeführt wird. Es fehlt eine Vision für das Produkt, um der Data-Science-Initiative den nötigen Vorschub zu leisten.</p><h2>Mindset zum Projektbeginn</h2><p>Es macht sehr viel Spaß, sich mit KI und neuronalen Netzen zu beschäftigen. Fast täglich werden wir mit neuen Möglichkeiten konfrontiert, die uns KI eröffnet. Darum ist es sehr wichtig, sich ständig daran zu erinnern, dass KI und andere Technologien im Kontext von Data-Science-Projekten lediglich ein Hilfsmittel dafür sind, einen Mehrwert für Kunden zu schaffen.</p><p>Startet ein Data-Science-Projekt mit einem Proof of Concept und der oben beschriebenen Fragestellung:  „Wie gut können wir Kündigungen vorhersagen?“ – oder allgemeiner: „Wie gut ist es möglich, mit KI XYZ zu erreichen?“ – ist diese sehr interessant und es ist äußerst spannend, sich mit der Frage zu beschäftigen. Ein solcher Projektstart führt jedoch regelmäßig dazu, dass im PoC exzessive Modelloptimierung betrieben wird.</p><p>In der Anfangsphase des Projekts ist es meistens nicht nötig, das vermeintlich beste Modell zu entwickeln. Dennoch werden häufig direkt am Anfang sehr viele Ressourcen in die Modelloptimierung investiert. Die folgenden Gründe sprechen gegen dieses Vorgehen:</p><ul><li>Ein Modell kann beliebig lange weiteroptimiert werden und es gibt oft einen unerschöpflichen Ideenpool, wie das Modell weiter verbessert werden könnte.</li><li>Der Aufwand zur Verbesserung des Modells wächst typischerweise exponentiell und es ist oft noch nicht klar, ob eine Verbesserung der Genauigkeit von 84 auf 87 % wirtschaftlich und überhaupt notwendig ist.</li><li>Neben einem Modell benötigt man noch eine Vielzahl weiterer Software-Komponenten, etwa zum Deployen des Modells und zur Auslieferung der Vorhersageergebnisse, um tatsächlich einen Mehrwert zu generieren.</li></ul><p>Pragmatisch gesehen benötigt man, um weiter zu kommen, im ersten Schritt lediglich ein Modell, das schlicht gut genug ist. Die Beurteilung von „gut genug“ kann anhand der oben beschriebenen Business-Metrik erfolgen. Modell-Metriken sind dabei nur ein Faktor in der eigentlichen Business-Metrik und oft entscheiden letztlich ganz andere Faktoren darüber, ob sich mit der Idee überhaupt Geld verdienen lässt.</p><p>Eine Empfehlung ist es daher, bereits vom ersten Projekttag an das Gesamtbild nicht aus dem Blick zu verlieren und sich regelmäßig die Frage zu stellen:  „Ist das, was ich gerade vorhabe, notwendig, um herauszufinden, ob ich mit der Idee einen Mehrwert schaffen kann?”</p><h2>Schnell Erfahrung sammeln</h2><p>Zu einem gewissen Zeitpunkt befindet sich das Projekt hoffentlich in der Situation, dass ein erstes Modell vorliegt und die Business-Metrik einen relevanten Mehrwert erwarten lässt. Hier basiert die Business-Metrik häufig zwar nicht auf validierten Annahmen, dennoch ist an dieser Stelle ein entscheidender Punkt im Projekt erreicht: Spätestens jetzt geht es darum, damit zu beginnen, die Annahmen hinter dem Business Case zu validieren.</p><p>Eine mögliche Falle, in die das Projekt in dieser Situation geraten kann, sind offene Diskussionen über Vermutungen, wie das Modell noch weiter verbessert werden kann oder Hypothesen über den zugrundeliegenden Business Case. Der Grund dafür ist, dass die Diskussionen in vielen Fällen schlicht zu keinem Ziel führen können. Das liegt daran, dass die relevantesten Erkenntnisse nur noch mit Feedback von echten Nutzern und Daten erlangt werden können.</p><p>Um möglichst schnell von hypothetischen „Was wäre, wenn“-Diskussionen zu „Was ist, wenn“-Erkenntnissen zu gelangen, gilt es daher, die gesamte Energie darauf zu konzentrieren, einen ersten Prototyp zu bauen und diesen unter realen Bedingungen zu testen. Hierbei geht es darum herauszufinden, ob sich der erwartete Mehrwert tatsächlich realisieren lässt. Also unter anderem die Annahmen der Business-Metrik zu validieren und zu testen, ob das Modell auf echten Daten ebenso zuverlässig und genau funktioniert wie auf den Beispieldaten.</p><p>Ein entscheidender Aspekt hierbei ist, so schnell wie möglich ein tragfähiges Fundament für den Business Case zu schaffen. Je länger die Validierung der Annahmen verzögert wird, desto länger basieren Entscheidungen und Weiterentwicklungen auf nicht validierten Annahmen. Dies führt in der Regel dazu, dass die Geschwindigkeit, mit der Anpassungen vorgenommen werden können, immer weiter sinkt und Letztere zusätzlich immer teurer und damit schmerzhafter werden.</p><p>Außerdem treten – sobald es darum geht, einen Prototyp zu bauen, diesen in eine IT-Infrastruktur zu integrieren und ihn mit Kunden zu testen – regelmäßig technische Herausforderungen auf, die bis dahin oft nicht absehbar waren. Manchmal verändern diese Herausforderungen den gesamten Business Case und in seltenen Fällen scheitert die gesamte Idee etwa daran, dass etwa Aspekte des Datenschutzes nicht erfüllt werden können.</p><p>Gelingt die Integration des Prototyps, stellt sich bei der Validierung typischerweise schnell heraus, dass der Business Case nicht von ein paar Prozent Modellgenauigkeit abhängt, sondern andere Faktoren einen viel größeren Einfluss haben. Umso schmerzlicher ist es, wenn diese Lernerfahrungen erst viel später gemacht werden und stattdessen zunächst viele Ressourcen in die Modelloptimierung investiert wurden.</p><p>Unsere Empfehlung ist es daher, möglichst schnell nicht mehr „discussion-driven“, sondern „experiment-driven“ zu arbeiten und validierte Erkenntnisse über den Business Case zu sammeln.</p><h2>Zusammenstellung des Projektteams</h2><p>Wenn man die bisher genannten Punkte im Projekt berücksichtigen möchte, zeigt sich schnell, dass hierfür eine Vielzahl unterschiedlicher Fähigkeiten, Kenntnisse und Erfahrungen nötig ist.</p><p>Data-Science-Projekte werden allerdings häufig mit einem Team gestartet, in dem ein stark akademisch geprägtes Mindset überwiegt. Dies führt regelmäßig dazu, dass nicht der Kundennutzen oder der Business Case im Vordergrund steht, sondern die Begeisterung für KI und neuronale Netze und damit die Technologie. Das wiederum fördert einen Fokus auf Modelloptimierung und eine große Bereitschaft im Team, den zugrundeliegenden Business Case nicht zu hinterfragen.</p><p>Oft haben Data Scientists keinen Hintergrund in Softwareentwicklung. Das allein ist zunächst kein Problem, da Data-Science-Expertise als solche wichtig für das Projekt ist. Besteht das Team jedoch überwiegend aus Data Scientists ohne Software-Engineering-Hintergrund, stellt die Entwicklung eines Prototyps das Team in vielen Fällen vor eine schwer lösbare Aufgabe und es ist schlicht nicht zu erwarten, dass ein solches Team einen schlanken Prototyp entwickelt, der schnell iterativ angepasst werden kann.</p><p>Fehlt die Expertise für Produktentwicklung im Team, gelingt es in vielen Fällen nicht, eine belastbare Produktvision zu erarbeiten. Dadurch verschiebt sich häufig der Fokus im Laufe des Projekts und verlagert sich vom Ziel, Kundennutzen schaffen, hin zu anderen technischen Zielen wie Modelloptimierung. Dies führt regelmäßig dazu, dass die Idee nach dem Nachweis der technischen Machbarkeit nicht weiterverfolgt wird und nach einem Abschlussvortrag in der Schublade verschwindet.</p><p>Nach unserer Erfahrung benötigt das Team bereits von Anfang an Expertise im Bereich Data/Software Engineering und Produktentwicklung. So kann es einerseits gelingen, den Übergang von der Validierung des Business Case zur Entwicklung eines Prototyps ohne unüberwindbare Reibungseffekte zu gestalten, da Themen wie Data Pipelines, Deployment des Modells und Auslieferung der Ergebnisse an die Nutzer direkt mitgedacht werden können. Andererseits kann aktiv an der Produktvision gearbeitet werden und der fachliche Input zur Erstellung einer Business-Metrik ist im Team vorhanden. Letztlich geht es darum, das Team so aufzustellen, dass der Fokus auf dem eigentlichen Ziel liegt: mit einem neuen Produkt Geld zu verdienen.</p><p>Wir empfehlen daher, das Team so zu gestalten, dass es alle notwendigen Fähigkeiten besitzt, um dieses primäre Ziel zu erreichen. Als zugrundeliegendes Paradigma gilt hierbei, alle Rahmenbedingungen so zu setzen, dass möglichst schnelle Feedback-Zyklen möglich sind. Dafür ist es insbesondere notwendig, dass das Team alle Entscheidungen im Projektkontext selbst treffen kann. Dazu gehören einerseits technische Entscheidungen, aber auch Entscheidungen zur Produktvision und die Möglichkeit, direkten Kontakt zu Kunden herzustellen, um Feedback einholen zu können.</p><h2>Fazit</h2><p>Typischerweise entsteht der größte Mehrwert für Kunden beim ersten Schritt von keiner Lösung zu einer Lösung. Um den Schritt mit dem Kunden zu gehen, muss die Lösung nicht optimal, sondern lediglich gut genug sein. In diesem Artikel haben wir aufgezeigt, welche Rahmenbedingungen in Data-Science-Projekten regelmäßig dazu führen, dass der Schritt zum Kunden sehr spät oder gar nicht gegangen wird. Da fehlendes Kundenfeedback häufig zu vorschnellen und kostenintensiven Optimierungen führt und nicht validierte Annahmen schlicht bedeuten, zu lange und aufwändig am Kunden vorbei zu entwickeln, ist es hilfreich, sich regelmäßig auf das primäre Ziel des Projekts zu fokussieren.</p><p>Der Artikel liefert keine Blaupause für Data-Science-Projekte; er zeigt lediglich auf, welche Bedingungen problematisch sein können, wenn es darum geht, das Ziel – ein erfolgreiches Data-Science-Produkt – zu erreichen. Bei der Umsetzung konkreter Projekte sind unterschiedlichste Rahmenbedingungen vorhanden, die verschiedenste Anpassungen der Vorgehensweise verlangen. Oft ist es nur sehr schwer oder gar nicht möglich, diese Rahmenbedingungen zu verändern. Das Ziel dieses Artikels war es daher, eine generelle Sensibilität zu schaffen, um im nächsten Projekt ein paar hinderliche Rahmenbedingungen gezielt hinterfragen zu können.</p><p>Unsere Herangehensweise an Data-Science-Projekte präsentieren wir in unserem kostenlosen <a href="https://www.codecentric.de/wissens-hub/webinare/webinar-data-science-projekte" target="_blank">On-Demand-Webinar (Deutsch)</a> . Außerdem zeigen wir in unserem <a href="/en/knowledge-hub/blog/dish-o-tron-no-more-dirty-dishes-ai" target="_blank">Deep-Learning Tutorial: DISH-O-TRON (Englisch)</a>  (mit einem Augenzwinkern) wie man von einer Data-Science-Idee bis zum Ende-zu-Ende Prototypen kommt.</p><p>Jetzt einen unverbindlichen Austausch anfordern über <a href="mailto:ki@codecentic.de">ki@codecentic.de</a> .</p><h3>Referenzen & Link-Tipps</h3><p>[1] <a href="https://developers.google.com/machine-learning/guides/rules-of-ml/" target="_blank">https://developers.google.com/machine-learning/guides/rules-of-ml/</a> <br /> [2] <a href="https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf" target="_blank">https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf</a> <br /> [3] <a href="http://theleanstartup.com/book" target="_blank">http://theleanstartup.com/book</a> <br /> [4] <a href="https://multithreaded.stitchfix.com/blog/2019/03/11/FullStackDS-Generalists/" target="_blank">https://multithreaded.stitchfix.com/blog/2019/03/11/FullStackDS-Generalists/</a> <br /> [5] <a href="http://lpd2.com/" target="_blank">http://lpd2.com/</a> <br /> [6] <a href="/wissens-hub/blog">codecentric Blog</a></p>

Wie man Data-Science-Projekte nicht in die PoC-Sackgasse manövriert

KI in der Praxis: Fehlerhafte Bauteile mit AutoML in der Google Cloud identifizieren

<p>Heutzutage steht fast alles, was mit den Labels „künstliche Intelligenz (KI)“ oder „Machine Learning (ML)“ versehen ist, für Fortschritt. Seltsamerweise schließt diese Assoziation jedoch häufig die Themen Daten und Dateninfrastruktur nicht ausreichend mit ein, und das, obwohl ML-Systeme typischerweise in hohem Maße von einer geeigneten Dateninfrastruktur abhängig sind. Um tatsächlich Mehrwert mit einem ML-System zu erzeugen, sind insbesondere (automatisierte) Daten-Pipelines erforderlich, die das System solide in die IT-Landschaft integrieren.</p><p><strong>Hinweis: Dieser Artikel erschien ursprünglich im Softwerker-Magazin Vol. 16. <a href="https://www.codecentric.de/wissens-hub/softwerker/softwerker-16" target="_blank">Das gesamte Heft kann hier als PDF heruntergeladen werden</a> .</strong></p><h2>Eine Wahrheit über Data-Science-Projekte</h2><p>Betrachten wir die folgende Situation: Ein Data-Science-Projekt startet mit einem Proof of Concept (PoC) und einem versierten Projektteam, das direkt anfängt, in schnellen Iterationen Erkenntnisse zu liefern. Nach Ablauf der Timebox des PoC ist es tatsächlich gelungen, vielversprechende Ergebnisse zu erzielen. So gibt es die Gelegenheit, diese Ergebnisse vor „wichtigen Entscheidungsträger*innen“ zu präsentieren. Nachdem das Projektteam die Präsentation mit Bravour gemeistert hat, wird immer deutlicher: Die Idee ist ein Volltreffer! Alle fühlen sich großartig.</p><p>Unter der Haube wurden die vielversprechenden Data-Science-Ergebnisse jedoch auf einem lokalen Rechner mit Daten-Dumps (CSV-Dateien oder Excel-Tabellen) aus mehreren Datenquellen erzielt. Die Daten-Dumps wurden vorab von einer SQL-Expertin mit einer speziellen Abfolge magischer SQL Queries sorgfältig von Hand erzeugt. Dieses Vorgehen ist oft richtig, und es ist sehr sinnvoll, zunächst mit Daten-Dumps zu arbeiten, um schnell Erkenntnisse zu erlangen. Das beschriebene Vorgehen ist aber auch zweifellos eine Abkürzung.</p><p>Die Abkürzung wird dann zum Problem, wenn sie nicht transparent ist. Noch schlimmer, wenn sie nicht so kommuniziert ist, dass der zugrunde liegende Trade-off von „den Entscheidungsträger*innen“ verstanden wurde. Denn der Trade-off für die schnellen Einsichten und Ergebnisse während des PoC besteht in der Regel darin, weder die zugrunde liegende Dateninfrastruktur noch den Aufbau geeigneter Daten-Pipelines während des PoC anzugehen. Spätestens nachdem nun alle die erfolgreiche Präsentation gesehen haben und jetzt sofort einen Mehrwert innerhalb weniger Tage erwarten, müssen wir der Wahrheit ins Auge sehen: Wir haben eine Abkürzung genommen. Bevor wir tatsächlich Mehrwert generieren können, müssen wir noch einiges nachlegen.</p><h2>Eine schwere Bürde für Data-Science-Projekte</h2><p>Da es, wie in unserer fiktiven Geschichte skizziert, möglich ist, kurzfristige, aber sichtbare Erfolge zu erzielen, treibt der KI-Hype Unternehmen oft dazu, eine Reihe von Data-Science-Projekte zu starten. Jedoch wird häufig nicht zeitgleich ein Bewusstsein dafür geschaffen, welche Implikationen der (gewünschte) Produktiveinsatz eines ML-Systems für die Dateninfrastruktur hat. Klar ist: Um Ideen zu validieren, müssen die potentiell bestehenden Unzulänglichkeiten der Infrastruktur nicht alle zuerst gelöst werden. Ein Problem entsteht aber regelmäßig dann, wenn sich nicht alle Beteiligten darüber im Klaren sind, dass die Entwicklung eines Ende-zu-Ende-Prototyps oder gar eines produktionstauglichen ML-Systems – je nach vorhandener Dateninfrastruktur – ein sehr anspruchsvoller nächster Schritt nach einem PoC sein kann.</p><p>Im schlimmsten Fall führt dies zu der bizarren Situation, dass ein Data-Science-Projektteam nach dem PoC vor der Aufgabe steht, die unternehmensweiten Herausforderungen in Sachen Daten und Dateninfrastruktur ganz nebenbei mit zu lösen. Bei dem (verzweifelten) Versuch, Mehrwert zu schaffen, sieht sich das Projektteam dabei mit unlösbaren Aufgaben konfrontiert und es gibt wenig oder gar kein Verständnis für die Schwierigkeiten des Teams bei den Stakeholdern und damit häufig auch keine Unterstützung. Dies führt regelmäßig zu Frustration beim Projektteam und letztlich zum Scheitern der einst so vielversprechenden Idee, da kein Mehrwert in der erwarteten Zeit erzeugt werden konnte.</p><p>Im übertragenen Sinne versucht das Team, einen Sportwagen (das State-of-the-Art-KI-Modell) auf einem Waldweg (der Dateninfrastruktur) zu fahren und alle Außenstehenden fragen sich, warum das Team nicht einfach in voller Geschwindigkeit fährt. So entsteht häufig der Eindruck, dass es einfach nicht möglich ist, mit Data-Science-Projekten tatsächlich einen Mehrwert zu generieren.</p><h2>Daten – eine Frage der Einstellung</h2><p>Historisch gesehen ist der Aufbau einer neuen Dateninfrastruktur mit großen Schmerzen für Unternehmen verbunden. Dies liegt daran, dass sie typischerweise mit enormen Investitionen von Zeit und Geld (und Nerven) verbunden ist. Darüber hinaus gibt es verschiedene Architekturen, z. B. Data Lakes (siehe <a href="https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/" target="_blank">hier</a>  und <a href="https://jamesdixon.wordpress.com/2014/09/25/data-lakes-revisited/" target="_blank">hier</a> ), <a href="https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html" target="_blank">Data Lakehouses</a> , <a href="https://martinfowler.com/articles/data-monolith-to-mesh.html" target="_blank">Data Meshes</a>  und natürlich das <a href="https://www.oracle.com/de/database/what-is-a-data-warehouse/" target="_blank">klassische Data Warehouse</a>  mit jeweils unterschiedlichen Vorteilen und Kompromissen, die es zu berücksichtigen gilt.</p><table><tbody><tr><th><strong>Ein kleiner Exkurs: Data Warehouse, Data Lake, Data Mesh, Data Lakehouse</strong></th></tr><tr><td> <p>Das zentrale <strong>Data Warehouse</strong> wird klassisch zur Konsolidierung großer, strukturierter Datenmengen aus verschiedenen Quellen verwendet und deckt einen Großteil der Einsatzzwecke etwa aus dem Reporting und Controlling sehr gut ab. Die typischerweise darin enthaltenen strukturierten Daten sind jedoch einerseits oft ohne nennenswerte Historie und andererseits stark aggregiert und daher regelmäßig nicht ausreichend für Data-Science-Anwendungsfälle.</p><p>Das dauerhafte Speichern großer Datenmengen in einer Data-Warehouse-Lösung ist meistens sehr teuer und damit unwirtschaftlich; hier liefert ein <strong>Data Lake</strong> einen möglichen Ausweg. Die Idee ist es, die großen (unstrukturierten) Datenmengen – wie z. B. Sensordaten – für potentielle Data-Science-Anwendungsfälle der Zukunft in günstigen Speicherformaten (oft in der Cloud) vorzuhalten. In Kombination mit passenden Data-Processing-Tools kann auf diese Weise ein Self- Service geschaffen werden, der es unterschiedlichen Nutzergruppen erlaubt, eigenständig und flexibel benötigte Daten nach ihren jeweiligen Wünschen zu untersuchen und passend weiterzuverarbeiten.</p><p>In der Praxis kann der Data-Lake-Ansatz jedoch zu einem „Dump and forget“ aller verfügbaren Daten in den Data Lake führen. Damit ist es für potentielle Konsumenten der Daten – welche die Daten ggf. erst mit einer Verzögerung von Monaten oder Jahren verwenden wollen – häufig schwer bis unmöglich, die Daten ohne substantielle Hilfe selbständig zu verwenden. Unter anderem an diese Herausforderung knüpft die Idee des <strong>Data Meshes</strong> an. Hier wird u. a. die Verantwortung für die Qualität und Nutzbarkeit der Daten an die Produzenten der Daten übertragen. Eine Aufgabe dabei ist es, insbesondere den Wahrheitsgehalt und die Vertrauenswürdigkeit der Daten zu garantieren. So erhalten die Daten den Stellenwert eines (internen) Produkts, das den Usern (Konsumenten) möglichst anwenderfreundlich zur Verfügung gestellt wird.</p><p>Orthogonal dazu steht die Idee des <strong>Lakehouse</strong> mit dem Ziel, die Konzepte von Data Lake und Data Warehouse zu einem gemeinsamen System zu verschmelzen. Das Zielsystem soll einerseits schnelle Exploration und Validierung potentieller Data-Science-Ideen unterstützen, aber andererseits auch ETL-Strecken von den Rohdaten bis zur aggregierten und strukturierten Sicht für Data Warehouses ermöglichen. Dabei setzen alle Anwendungen auf derselben Infrastruktur und insbesondere einer gemeinsamen Datenbasis auf.</p></td></tr></tbody></table><p>Den eigentlichen Kern und damit das Fundament zur Realisierung der durch eine der Architekturen in Aussicht gestellten Verbesserung sind jedoch ausdrücklich nicht die technischen Feinheiten. Denn im Kern geht es um die Frage, welchen Stellenwert Daten im Unternehmen haben und insbesondere darum, den Umgang und die Bedeutung mit und von Daten im Unternehmen zu verändern. Dieser Wandel ist wahrscheinlich der wichtigste Schritt bei der Umsetzung der Architekturen und damit entscheidend dabei, mit Data-Science-Projekten dauerhaft Mehrwert zu generieren.<br /> Die Erkenntnis, dass die Etablierung einer geeigneten „Data Culture“ im Unternehmen den zentralen Schritt in Richtung Mehrwert mit ML-Systemen darstellt, ist zwar nicht neu, aber nach unserer Beobachtung noch nicht ausreichend in der Breite adaptiert.<br /> Dabei gibt es jedoch (mindestens) zwei Gründe, die für ein Umdenken beim Thema Daten sprechen.</p><h4>1. Schnellere Zykluszeit für die Validierung von Ideen</h4><p>Es liegt auf der Hand, dass ein PoC (wie oben beschrieben) schnell erste Erkenntnisse darüber liefert, ob eine Idee vielversprechend ist oder nicht. Ohne eine geeignete Dateninfrastruktur ist es jedoch in der Regel schwierig und kostspielig, eine Idee anschließend auch mittels eines Ende-zu-Ende-Prototyps zu validieren.</p><p>Dies führt in der Regel zu langwierigen Diskussionen darüber, ob und wann mit der Validierung welcher Idee begonnen werden soll, ohne in dieser Zeit tatsächlich wertvolle Erkenntnisse über die Ideen selbst zu gewinnen. Dabei ermöglicht es eine geeignete Dateninfrastruktur insbesondere durch schnelle Ende-zu-Ende-Validierung und Experimente, Ideen schneller zu verwerfen. So muss über diese Ideen nicht ständig neu diskutiert werden und der Fokus kann leichter auf potentiell erfolgreiche Ideen gelegt werden. Die grundsätzliche Fähigkeit, Ideen mit schnellen Ende-zu-Ende-Prototypen und Experimenten zu validieren, ist insbesondere für die Entwicklung erfolgreicher ML-Systeme wichtig, da diese typischerweise aus vielen beweglichen Teilen bestehen und sich das System häufig über mehrere Teile des Unternehmens erstreckt.</p><p>Für ein Ende-zu-Ende-System müssen (Roh-)Daten geeignet aufbereitet werden, ein passendes ML-Modell entwickelt, trainiert und deployt werden und schließlich die durch das Modell generierten Erkenntnisse genau dort in einer brauchbaren Form zur Verfügung gestellt werden, wo diese schließlich einen Mehrwert liefern können. Darüber hinaus gilt es, noch weitere Herausforderungen wie Monitoring, Versionierung und Validierung mitzudenken.</p><h4>2. Der eigentliche Wert ist die Fähigkeit, ML-Algorithmen produktiv einzusetzen</h4><p>Typischerweise gibt es in Unternehmen eine Fülle von Ideen, wie Data Science und Machine Learning genutzt werden könnten, um Mehrwert zu erzeugen. Meistens sind auch bekannte ML-Algorithmen vorhanden, die bereits von anderen erfolgreich verwendet werden, um die gleiche oder eine ähnliche Idee umzusetzen. Es gibt daher oft berechtigten Grund zu der Annahme, dass dieser bekannte Algorithmus mindestens gut genug für eine erste Ver- sion des gewünschten ML-Systems ist.</p><p>Tatsächlich sind viele State-of-the-Art-Algorithmen und ML-Modelle heutzutage frei verfügbar:</p><ul><li>XGBoost, ein effizientes, flexibles und portables Gradient- Boosting-Framework, welches das Rückgrat für zahlreiche erfolgreiche ML-Systeme bildet.</li><li>ResNet, ein KI-Modell für moderne Bildklassifikation, ist in verschiedenen Open-Source-Frameworks wie Tensorflow und PyTorch implementiert und direkt einsatzbereit.</li><li>BERT, ein KI-Modell für Natural Language Processing, ebenfalls Open Source und in PyTorch and TensorFlow frei verfügbar.</li><li>Darüber hinaus stehen viele Algorithmen und Modelle auch „as a service“ bei Public-Cloud-Anbietern zur Verfügung und können dort direkt eingesetzt und oft sogar auf eigenen Daten feinjustiert werden.</li></ul><p>Zur Umsetzung der vorhandenen Ideen fehlt daher häufig nicht das Wissen über einen geeigneten Algorithmus, sondern es fehlt die Verfügbarkeit von Daten und insbesondere die Fähigkeit, den Algorithmus schmerzlos als ML-System Ende-zu-Ende in die Unternehmensinfrastruktur zu integrieren. Diese Punkte entscheiden am Ende daher regelmäßig darüber, ob mit einer Idee ein Mehrwert erzeugt werden kann – und nicht, ob ein passender Algorithmus gefunden wurde.</p><h2>Daten neu denken</h2><p>Wie schon erwähnt, ist das Überdenken von Daten und Dateninfrastruktur kein (rein) technisches Problem und beginnt typischerweise mit den Fragen:</p><ul><li>Welche Daten sind verfügbar?</li><li>Welche Qualität haben die Daten?</li><li>Wem gehören die Daten?</li><li>Wer kontrolliert den Zugriff auf die Daten?</li><li>Wer ist für die Daten und ihre Qualität verantwortlich?</li><li>Wie ist die Beziehung zwischen Datenproduzenten und Datenkonsumenten?</li><li>Wie kann diese (entscheidende) Beziehung verbessert werden?</li></ul><p>Ein Hauptantrieb für die Beantwortung dieser Fragen besteht darin, Wege zu finden, um die gesamte End-to-End-Zykluszeit zur Entwicklung von ML-Systemen zu reduzieren – indem beispielsweise die Verfügbarkeit, die Verarbeitungsgeschwindigkeit und die Qualität der Daten sukzessive verbessert werden.</p><p>In den meisten Fällen empfehlen wir, ausdrücklich nicht zu versuchen, alle Infrastrukturprobleme im Voraus zu lösen und danach mit Data-Science-Projekten zu starten. Im Gegenteil: Viele Schwierigkeiten werden erst offenbar, sobald die ersten ML-Systeme entwickelt werden, und sind vorab unbekannt. Daher ist es ist meist unmöglich, geeignete Lösungen für diese Schwierigkeiten zu finden, ohne konkrete Anwendungen zu implementieren und dabei zu lernen.</p><p>Letztlich gilt es, das Thema Daten in großem Maßstab zu überdenken, aber von Use Case zu Use Case im Kleinen umzusetzen. Dies ermöglicht zum einen die Validierung verschiedener technischer Ansätze. Zum anderen (und das ist wahrscheinlich wichtiger) erlaubt es uns, unsere Denkweise über die Bedeutung von Daten Schritt für Schritt zu ändern. In diesem Stadium bietet die Nutzung einer Cloud-Infrastruktur eine gute Möglichkeit, schnell und ohne große Vorlaufzeit und Anfangsinvestition zu arbeiten. Der Schwerpunkt liegt hier zunächst auf der Ende-zu-Ende-Umsetzung von Use Cases und insbesondere auf der Entwicklung produktionstauglicher ML-Systeme. Sobald tatsächlich mehrere Use Cases umgesetzt sind und einen Mehrwert schaffen, kann eine Vereinheitlichung der zugrunde liegenden Dateninfrastruktur möglicherweise einen zusätzlichen Mehrwert bieten.</p><h2>Data-Science-Projekte neu denken</h2><p>Data-Science-Projekte werden häufig mit einem Team aus Data Scientists gestartet. Während das auf den ersten Blick sinnvoll erscheint, verbergen sich in der Praxis hinter dem Begriff Data Scientist oft die unterschiedlichsten Skill Sets. Regelmäßig führt dies dazu, dass im Projektteam die Schwerpunkte der Fähigkeiten auf der Erstellung von ML-Modellen und deren Optimierung liegen, während die Themen Softwareentwicklung, Data Engineering und Produktentwicklung nur schwach vertreten sind.</p><p>In diesem Fall ist es häufig nicht zu erwarten, dass das Projektteam die verschiedenen Trade-offs, die im PoC eingegangen wurden und insbesondere deren Implikationen auf die Weiterentwicklung der Idee – etwa in Richtung eines Ende-zu-Ende Prototyps – transparent in Richtung „der Entscheidungsträger*innen“ kommunizieren kann. Zudem stellt die eigentliche Entwicklung eines solchen Prototyps das Team in vielen Fällen vor eine schwer lösbare Aufgabe, und es ist oft schlicht nicht zu erwarten, dass so ein schlanker Prototyp entsteht, der später schmerzlos iterativ angepasst werden kann.</p><p>Fehlt ausreichend Expertise für Produktentwicklung im Team, gelingt es in vielen Fällen zudem nicht, eine belastbare Produktvision für die Data-Science-Idee zu erarbeiten. Oft führt dies dazu, dass in Präsentationen vor „den Entscheidungsträger*innen“ der Fokus auf dem ML-Modell und den generellen Modell-Metriken liegt, wohingegen die Fragen „Was muss alles passieren, dass Geld verdient werden kann?“ und „Wie genau führen die Erkenntnisse des Modells nun eigentlich zu Mehrwert?“ zu stark in den Hintergrund rücken.</p><p>Wir empfehlen daher, Data-Science-Projekte in der Regel ausdrücklich nicht mit einem PoC und der Frage „Wie gut ist es möglich, mit KI XYZ zu erreichen?“ zu starten, sondern sich von Anfang an die Frage „Was ist notwendig, um mit der Idee XYZ einen Mehrwert zu generieren?“ zu stellen. Bei der Beantwortung spielt das KI-Modell natürlich eine Rolle, ist aber dann nur ein Faktor neben allen anderen Herausforderungen, die gemeistert werden müssen, um Mehrwert zu generieren. Entscheidend ist es dabei, das Team so aufzustellen, dass alle notwendigen Fähigkeiten vorhanden sind, um die ursprüngliche Idee wirklich Ende-zu-Ende validieren zu können. Ein Modell alleine ist hierfür in vielen Fällen nicht ausreichend.</p><h2>Zusammenfassung</h2><p>Während alle über KI sprechen, braucht es am Ende viel mehr als Data Science und ML-Algorithmen, um produktionstaugliche ML-Systeme zu entwickeln und Mehrwert zu schaffen. Insbesondere setzt nachhaltiger Erfolg mit ML-Systemen und KI mehr voraus als clevere Algorithmen – er erfordert eine Änderung der Einstellung zum Thema Daten, Dateninfrastruktur und einen ganzheitlichen Blick auf die mögliche Wertschöpfungskette des ML-Systems. Der wahre Wert für Unternehmen im Kontext von ML-Systemen liegt am Ende meistens nicht im Algorithmus, sondern in den zugrunde liegenden Daten und der Fähigkeit, diese Algorithmen schnell in Form eines ML-Systems auf der Dateninfrastruktur umzusetzen.</p><p>Ein Big-Bang-Ansatz, um die Dateninfrastruktur zu ändern oder damit zu beginnen, alle verfügbaren Daten an einem einzigen Ort zusammenzufassen, ist oft ein unnötig schwieriges Unterfangen. Meistens ist es erfolgversprechender, das Thema Daten erst einmal zu überdenken – von Use Case zu Use Case – und unterwegs Schritt für Schritt eine geeignete Dateninfrastruktur aufzubauen und insbesondere eine neue Datenkultur zu schaffen.</p>

KI, Daten und Infrastruktur – ML-Systeme schnell Ende-zu-Ende verproben und umsetzen

KI in der Praxis: Fehlerhafte Bauteile mit Rekognition auf AWS identifizieren

> **Hinweis:** Dieser Blog-Post wurde mit LLM-unterstützung von Englisch auf Deutsch übersetzt.

Seit einiger Zeit besteht für europäische Datenteams die zentrale Herausforderung darin, Innovation mit strenger Regulierung in Einklang zu bringen. Häufig erscheinen leistungsfähige Tools zuerst in den USA, während unser Bedarf an DSGVO-Compliance und Datensouveränität eine lokale Präsenz erfordert.

Deshalb ist der offizielle Start von [MotherDuck](https://motherduck.com/) in der AWS-Region Frankfurt am 24. September (eu-central-1) eine spannende Entwicklung für die hiesige Data-Community[^1]. Als offizieller Launch-Partner haben wir die Plattform im Vorfeld ihres Europastarts getestet. Unser Fazit ist klar: Das ist weit mehr als nur ein neuer Cloud-Standort. Es steht für eine neue, effizientere Philosophie der Analytik für kleine bis mittelgroße Datenmengen.

Bevor wir auf die fünf wichtigsten Gründe für unsere positive Einschätzung eingehen, beantworten wir zunächst die Grundsatzfrage:

## What the Duck Is MotherDuck?

Um den Mehrwert von [MotherDuck](https://motherduck.com/) wirklich zu verstehen, lohnt sich ein Blick auf die Basis: [DuckDB](https://duckdb.org/).

Im Kern ist DuckDB für Analytics das, was SQLite für transaktionale Datenbanken ist – eine leistungsfähige, serverlose, eingebettete Daten-Engine. Sie läuft „in-process“ und macht damit komplexe Client-Server-Architekturen überflüssig. Es gibt keinen Server zu installieren, keine Instanz zu konfigurieren. Diese Einfachheit, kombiniert mit konstant starken Platzierungen in Performance-Benchmarks wie [ClickBench](https://benchmark.clickhouse.com/)[^2], hat zu einer weiten Verbreitung geführt (über 30k GitHub‑Stars) und einer großen Entwickler-Community.

Während DuckDB lokal auf dem Rechner glänzt, benötigen Unternehmensumgebungen zusätzliche Fähigkeiten für Zusammenarbeit, Sicherheit und Skalierung. Genau hier setzt MotherDuck an. Die Plattform erweitert DuckDB um produktionsreife, cloudbasierte Funktionen, darunter:
- Zentrale Autorisierung und Benutzerverwaltung
- Dauerhafter, persistenter Cloud‑Speicher
- Intelligentes Caching und Query‑Skalierung

Wie es MotherDucks Gründer Jordan Tigani häufig formuliert: „Während DuckDB deinen Laptop in eine persönliche Analytics‑Engine verwandelt, skaliert MotherDuck deinen Laptop mit dualer Ausführung in die Cloud.“ Kurz gesagt: MotherDuck liefert die kollaborative, enterprise‑taugliche Ebene, mit der Teams die volle Power von DuckDB sicher und skalierbar nutzen können. Mehr zur dualen Ausführung weiter unten.

Der architektonische Ansatz, eine starke lokale Engine mit einer schlanken, kollaborativen Cloud‑Schicht zu kombinieren, macht die Plattform besonders überzeugend. Basierend auf unserer Evaluation sind dies die fünf Gründe, warum wir uns über diese Entwicklung freuen:

## Ihre Daten sind wahrscheinlich nicht so groß, wie Sie denken

Die Datenbranche war mehr als ein Jahrzehnt lang von „Big Data“ besessen. Doch wie die Gründer von MotherDuck argumentieren, ist [Big Data tot](https://motherduck.com/blog/big-data-is-dead/). Die Realität ist oft einfacher: Die wenigsten Unternehmen arbeiten im Petabyte‑Maßstab von Google oder Meta. Viele Analytics‑Workloads basieren auf Datenmengen im Giga- bis niedrigen Terabyte‑Bereich. Dafür braucht es nicht zwingend massive, komplexe, verteilte Systeme.

Aktuelle Laptops und Einzelserver sind enorm leistungsfähig – oder, wie es DuckDB‑Erfinder Hannes Mühleisen nennt: Wir haben ein „[verlorenes Jahrzehnt der kleinen Daten](https://duckdb.org/2025/05/19/the-lost-decade-of-small-data.html)“ erlebt. MotherDuck und DuckDB sind genau für diese Realität kleiner und mittelgroßer Datenmengen ausgelegt. Sie liefern die Leistung verteilter Systeme ohne deren Overhead, Kosten und Komplexität – und ermöglichen effiziente Verarbeitung dort, wo es am meisten Sinn ergibt.

## Fokus auf Einfachheit und Performance

Einer der größten Hindernisse in der Datenanalyse ist oft das Setup. Traditionelle Systeme erfordern Server‑Installationen, Instanz‑Konfigurationen und Berechtigungsmanagement, bevor überhaupt die erste Abfrage läuft. Die Mission von DuckDB ist es, diese Reibung vollständig zu entfernen.

Es gibt keine Server zu betreiben. Bibliothek installieren und loslegen. Diese radikale Einfachheit, gepaart mit einer sehr schnellen Query‑Engine, verkürzt die Time‑to‑Insight deutlich. Von einer 10‑GB‑Parquet‑Datei zu aussagekräftigen Ergebnissen in Sekunden statt Stunden (abhängig von Hardware und Datenlayout). MotherDuck überträgt diese Philosophie auf die Team‑Zusammenarbeit und liefert die nötige Infrastruktur für produktionsreife Datenanwendungen – ohne die Komplexität wieder einzuführen, die DuckDB ursprünglich abgeschafft hat.

## Vereinfachtes und sicheres Data Sharing

Ein häufiges Problem in kollaborativer Analytik ist der manuelle Austausch von Datenfiles, etwa per CSV‑Export – eine Praxis, die bis heute viele Data‑Science‑ und KI‑Projekte einleitet. Das erzeugt Datensilos, wirft Sicherheitsfragen auf und führt zu Versionskonflikten mit inkonsistenten Datensätzen, die über mehrere Teammitglieder verstreut sind.

MotherDuck adressiert das direkt, indem es das Paradigma vom Teilen von Daten hin zum Teilen des Zugriffs auf Daten verschiebt. Anstatt Kopien zu erzeugen, arbeiten Teams an einer einzigen, konsistenten Single Source of Truth.

Das Sharing‑Modell, zugänglich über eine Weboberfläche und programmgesteuert über Standard‑SQL‑Befehle (z. B. GRANT/REVOKE), macht „lästige CSV‑Exporte“ überflüssig und bietet einen sauberen Weg zur Zusammenarbeit.

## Reichhaltiges Partner‑Ökosystem

Der Wert einer Datenplattform hängt direkt davon ab, wie gut sie sich in bestehende Tools einer Organisation integrieren lässt. MotherDuck verfolgt eine „Bring Your Own Tools“‑Philosophie – im Kontrast zu monolithischeren Plattformen.

Die Plattform wird von einem reichhaltigen, wachsenden [Partner‑Ökosystem](https://motherduck.com/ecosystem/) unterstützt, das zahlreiche Open‑Source‑Projekte und kommerzielle SaaS‑Lösungen umfasst. Diese Verpflichtung zur Interoperabilität ermöglicht es Organisationen, einen Best‑of‑Breed‑Stack passgenau zusammenzustellen, statt sich in eine Einheitslösung zwängen zu lassen.

## Hybride Ausführung: Lokale Geschwindigkeit, Cloud‑Skalierung

Das vielleicht technisch innovativste Merkmal ist der Ansatz der hybriden Ausführung. Der intelligente Abfrageplaner von MotherDuck kann einen einzelnen Query‑Plan zwischen einer lokalen DuckDB‑Instanz und dem MotherDuck‑Cloud‑Service aufteilen.

So vereint das Modell das Beste beider Welten: die interaktive Geschwindigkeit und niedrige Latenz der lokalen Verarbeitung mit der Skalierbarkeit und der dauerhaften Speicherung der Cloud. Indem Teile einer Abfrage auf dem Rechner der Nutzerin bzw. des Nutzers laufen, minimiert die Architektur den Datentransfer – das reduziert von Haus aus sowohl die Latenz als auch die Cloud‑Compute‑Kosten.

Dieses leistungsfähige, hybride Modell erstreckt sich sogar auf moderne Webanwendungen, in denen DuckDB direkt im Browser (via WebAssembly) laufen kann, während MotherDuck im Backend größere, geteilte Datensätze bereitstellt.

# Fazit

SQLite hat die Welt der transaktionalen Datenbanken revolutioniert. Als leistungsfähige, serverlose, dateibasierte Datenbank ist sie heute integraler Bestandteil unzähliger Anwendungen und Geräte – Beispiele finden sich [hier](https://www.sqlite.org/famous.html).

Wir sind überzeugt, dass DuckDB im Analytics‑Bereich eine ähnliche Rolle einnehmen wird. Es bringt dieselben Prinzipien von Einfachheit und hoher Performance in eine Domäne, die lange von Komplexität geprägt war. MotherDuck dient als Katalysator, der dieses Potenzial skaliert – und DuckDB von einer persönlichen Power‑Engine zu einer tragfähigen, kollaborativen Plattform für moderne Datenteams macht.

Der offizielle Launch in Frankfurt ist ein wichtiger Meilenstein für Datenanalyse in Europa. Wir sind stolz, als Launch‑Partner dabei zu sein – und freuen uns auf die innovativen Lösungen, die unsere Kundinnen und Kunden mit dieser Technologie bauen werden.

Was kommt als Nächstes? Wenn Sie Ihre Datenplattform modernisieren möchten oder prüfen wollen, wie dieser Ansatz Ihrem Team nutzen kann, unterstützen wir Sie gerne. Kontaktieren Sie uns für ein unverbindliches Gespräch zu Ihrem konkreten Use Case.

[^1]: Wie bei jedem Cloud‑Service sollten Kundinnen und Kunden prüfen, ob Metadaten der Control‑Plane (z. B. Service‑Logs, Metriken, Authentifizierungs‑/Nutzungstelemetrie) die Region verlassen. Unabhängig davon muss jede Organisation die datenschutzrechtliche Zulässigkeit des Hostings personenbezogener Daten bei MotherDuck in AWS Frankfurt (eu-central-1) selbst bewerten.
[^2]: Benchmarks sind stets mit Vorsicht zu interpretieren. Die Hintergründe erläutert DuckDB‑Co‑Creator Hannes Mühleisen ausführlich [hier](https://hannes.muehleisen.org/publications/DBTEST2018-performance-testing.pdf): „On Performance‑Testing in Database Systems“.



5 Gründe, warum wir uns über den Motherduck Launch in AWS Frankfurt freuen

Die erste Welle ist durch. Copilot-Lizenzen sind gekauft, ein CompanyGPT steht, ein paar Meetings werden per KI zusammengefasst. In vielen Chefetagen stellt sich jetzt die richtige Frage: Was hat das eigentlich gebracht? Die Time-to-Market für die eigenen Kernprodukte hat sich um keinen einzigen Tag verkürzt. Es entstand keine datengetriebene KI-Company, denn es wurde kein Fundament gebaut sondern Pflaster geklebt.

Oft ist es kein technologisches Versagen, sondern ein organisatorisches. Wer KI einfach auf kaputte, von Silos geprägte Prozesse kippt, macht diese nicht besser, sondern es noch schwerer, sie anzupassen.

Die Prinzipien dahinter sind nicht neu. Silos einreißen, Durchlaufzeiten messen, Ergebnisse statt Aktivität: das predigen Lean-Denker seit Jahrzehnten.[^1] Neu ist die Konsequenz. KI ermöglicht erstmals autonome Lernsysteme. Der Abstand zwischen lernenden und nicht-lernenden Organisationen wächst damit schneller als je zuvor.

Da die Lerngeschwindigkeit einer Organisation heute über ihr Überleben entscheidet,[^2] braucht es einen ehrlichen Blick auf die eigene KI-Strategie. Drei Reifegrade helfen bei der Einordnung: KI als Pflaster, KI als Hebel und KI als Betriebssystem.

Wer heute lernt, wie ein echter KI-Hebel im eigenen Kerngeschäft funktioniert, profitiert vom Zinseszins dieses Wissens. Wer weiter nur isolierte Pflaster klebt, häuft organisatorische Schulden an.

## 1. KI als Pflaster

Ein KI-Pflaster ist der Versuch, ein lokales Problem zu optimieren, ohne das globale System zu adressieren.

KI ist keine Lösung. KI ist ein Verstärker. Sie skaliert exakt das, was bereits da ist. Trifft KI auf exzellente, schlanke Prozesse, skaliert sie diese Exzellenz. Trifft sie auf das Gegenteil, produziert sie mehr vom Falschen, nur schneller.

Die häufigste Illusion dabei ist die Geschwindigkeit.

In den meisten etablierten Unternehmen ist die aktive Arbeitszeit an einer Aufgabe gar nicht das Problem. Die Realität ist: Etwa 85 Prozent der Zeit verbringt eine Aufgabe im Wartezustand. Warten auf Zuarbeit anderer Teams, warten auf Freigaben, warten auf das nächste Meeting des Steering Committee.[^3]

Mit KI die reine Bearbeitungszeit verschiedener Schritte zu halbieren, ändert an der Time-to-Market kaum etwas. Die Arbeit staut sich lediglich schneller vor der nächsten organisatorischen roten Ampel.

Zwei Ausprägungen des Pflaster-Klebens aus der Praxis:

**Die 30%-Illusion in der Entwicklung**
Das Versprechen lautet oft, Softwareentwickler würden dank GenAI massiv schneller Code schreiben. Doch das reine Tippen von Code war in reifen Organisationen nie der Flaschenhals. Die Praxis zeigt aktuell ein anderes Bild: Junioren generieren nun Code-Massen in Rekordzeit. Die teuren Senior-Entwickler werden zu Vollzeit-Reviewern, die tagelang den produzierten „AI-Slop" bereinigen müssen, bevor er in Produktion darf. Der Engpass wurde nicht aufgelöst, sondern an die teuerste Stelle im Prozess verschoben.

**Die Abhak-Illusion im Fachbereich**
Ein sicheres Company-GPT wird bereitgestellt. Die Teams laden nun ihre gewohnten, oft fehlerhaften Excel-Sheets hoch, lassen sie zusammenfassen und arbeiten ansonsten exakt so weiter wie bisher. Sheets rein, Sheets raus, per E-Mail weiterschicken. Das Häkchen KI ist gesetzt. Die Art und Weise, wie Geschäftsentscheidungen getroffen werden, bleibt unangetastet.

Dabei sind solche Pflaster nicht per se wertlos. Sie können im ersten Schritt Vertrauen schaffen, Berührungsängste abbauen und erste Lernerfahrungen liefern. Zum Problem werden sie erst, wenn sie anstatt einer echten Strategie kommen und nach zwölf Monaten KI-Initiative das Pflaster das Einzige ist, was steht.

## 2. KI als Hebel

Ein KI-Hebel funktioniert grundlegend anders als ein Pflaster. Er verändert messbar, wie das Unternehmen Geld verdient oder spart. Genau deshalb fasst ihn oft niemand an. Er erfordert Mut, klare Rückendeckung vom C-Level und eine Fehlerkultur, die Experimente im Kerngeschäft zulässt. Ohne das bleibt der Fokus auf harmlosen Chatbots fürs Intranet, statt die relevanten Kernprozesse in der Logistik oder im Einkauf anzugehen.

Wer verstehen will, was ein echter Hebel im Markt anrichtet, kann zum Beispiel auf den Finanzsektor schauen. Die Blaupause liefert das algorithmische Trading.

Ein Pflaster im Trading wäre eine KI, die der Händlerin die aktuellen Finanzberichte blitzschnell zusammenfasst. Die Entscheidung trifft aber weiterhin der Mensch. Der Hebel hingegen ist das System, das in Millisekunden autonom Entscheidungen trifft und Orders direkt ausführt. Er greift die Kernwertschöpfung an. Das Ergebnis ist bekannt. Wer im Trading heute noch manuell freigibt, ist längst pleite. Was dort bereits Realität ist, öffnet sich jetzt in der Logistik, im Pricing und im Vertrieb.

Natürlich ist diese Autonomie ohne Leitplanken gefährlich. Das zeigt die Geschichte des Algo-Tradings mit seinen Flash Crashes deutlich. Wer einen Kernprozess an KI übergibt, braucht Governance: Entscheidungsgrenzen, Notbremsen und menschliche Eskalationspfade.

Ein Beispiel näher am Unternehmensalltag ist der Fashion Retail. Hier steht eine geschäftskritische Entscheidung im Zentrum: Welche Mengen werden je Artikel, Farbe und Größe bestellt, bei welchem Lieferanten und zu welchem Zeitpunkt? Früher basierte das auf Excel, Erfahrungswerten und simplen Nachbestellregeln. Heute übergeben immer mehr Retailer diese Kernentscheidung schrittweise an KI-Systeme. Der Weg dorthin war nicht trivial: Daten mussten strukturiert und Vertrauen aufgebaut werden. Am Anfang musste jede Bestellentscheidung noch manuell bestätigt werden. Am Ende definieren Einkäufer nur noch Regeln fürs Gesamtsystem und betrachten Ausreißer – das alte System wird abgeschaltet.[^4]

Der Bau eines solchen Hebels erfordert eine radikale Umkehr der Logik: nicht bei der Technologie starten, sondern bei der Entscheidung.[^5]

> ### Decision-first: Vier Fragen für den Hebel
>
> 1. **Welche konkrete Entscheidung wollen wir verbessern?** Nicht "Wo können wir KI einsetzen?", sondern "Wo verlieren wir Geld, Zeit oder Kunden durch schlechte Entscheidungen?"
> 2. **Wie messen wir den Effekt?** Nicht die Modellgenauigkeit, sondern harte Kennzahlen mit direktem Business-Impact.
> 3. **Wer trägt Verantwortung?** Nicht das KI-Team, sondern der Fachbereich, der die Entscheidung heute trifft.
> 4. **Was schalten wir danach ab?** Wenn nach dem Projekt nichts abgeschaltet wurde — kein altes Excel, kein manueller Prozess — war es ein Pflaster.

Der entscheidende Schritt bei der Implementierung ist nicht der Go-Live des KI-Systems. Es ist das konsequente Abschalten alter Entscheidungswege. Das kann ein IT-System sein, ein Freigabeprozess oder ein Excel-Sheet. Im Trading kam dieser Punkt, als die erfahrenen Händler erkannten, dass manuelles Handeln in vielen Kontexten keinen Sinn mehr hat. Ein echter Hebel tut weh, wenn man ihn wegnimmt. Er verändert einen Prozess und damit auch die Organisation drum herum. Aber eben nur einen Ausschnitt.

## 3. KI als Betriebssystem

Ein erfolgreicher KI-Hebel ist anfangs eine Insel. Der optimierte Bereich wird datengetrieben und schnell, der Rest der Organisation kommt nicht mit. Echtzeit-Entscheidungen prallen so plötzlich auf starre Jahresplanung und Silo-Budgets.

Ein typischer Reflex des Managements an diesem Punkt ist die organisatorische Flucht: Das Leuchtturm-Projekt wird als „digitales Schnellboot" oder Innovation Lab ausgegründet, fernab des trägen Kerngeschäfts. Das kapselt den Erfolg zwar ab, löst aber das Problem nicht. Der Kern des Unternehmens bleibt unangetastet und veraltet weiter.

Echte Transformation bedeutet, genau diesen Kern anzugreifen. In einem Start-up mit fünf Leuten wissen alle sofort Bescheid, wenn ein wichtiger Kunde droht abzuspringen. Jeder passt seine Entscheidungen an, um das zu verhindern. Jede Entscheidung profitiert vom gesamten Wissen der Organisation, in Echtzeit. Im Konzern fließen viele Informationen überhaupt nicht über Bereichsgrenzen. Und auf Managementebene tauchen sie stark verspätet in monatlichen Reportings auf. Der Verlust eines Großkunden erscheint als Randnotiz im nächsten Monatsbericht. Die Lernzyklen sind um ein Vielfaches langsamer. Das gesammelte Wissen steht für kurzfristige Entscheidungen schlicht nicht zur Verfügung.

KI als Betriebssystem schließt diese Lücke. Nicht indem alle alles mitbekommen, sondern indem die Systeme es tun. Wenn der Einkauf Überbestände meldet, passt das Pricing die Rabatte an, noch bevor ein Mensch ein Excel-Sheet öffnet. Die Logistik sieht das Signal und steuert die Lieferkette nach. Jeder Zyklus lernt vom letzten, ohne manuellen Übergabeprozess dazwischen.

Die Daten dafür existieren in den meisten Organisationen bereits. Sie stecken in ERP-Systemen, CRM-Tools, Datenbanken. Nur erreichen sie Entscheidungsträger über Monatsreports und weitergeleitete Excel-Sheets, Wochen zu spät und durch mehrere Managementebenen gefiltert.

KI-Systeme brauchen keine Meetings und keine Reportketten. Aber sie brauchen ein Datenökosystem, das diesen Namen verdient: Daten als eigenständiges Gut mit klaren Qualitätsstandards, nicht als zufälliges Abfallprodukt von Prozessen. Das bedeutet eiserne Data Governance und das unsexy, teure Aufräumen historisch gewachsener Legacy-Daten. Wer dieses Fundament nicht hat, wird es spätestens jetzt spüren. Durch KI werden sich Unternehmen mit belastbarer Datenbasis deutlicher von denen absetzen, die Daten weiterhin als Nebenprodukt behandeln.[^6]

Damit verschiebt sich die Rolle der Menschen im Unternehmen. Sie bedienen nicht mehr die KI, sondern definieren die Leitplanken, innerhalb derer das System selbst entscheidet.

Ein solches Betriebssystem lässt sich nicht per Big-Bang-Projekt ausrollen. Es wächst organisch. Es entsteht, indem man den ersten schmerzhaften Hebel baut und die Organisation zwingt, das dahinterliegende Fundament aufzuräumen.

## 4. Realitätscheck

Pflaster, Hebel, Betriebssystem: Wo steht die eigene Organisation? Vier Tests helfen bei der ehrlichen Einordnung.

**Der Schmerz-Test**
Der Stecker der aktuellen KI-Lösung wird gedanklich testweise gezogen. Kehren die Teams am nächsten Tag unbeeindruckt zum alten Prozess zurück, existiert nur ein Pflaster. Ein echter ausgeschalteter Hebel hinterlässt operative Panik und Handlungsunfähigkeit im Kerngeschäft.

**Der Silo-Test**
Der Weg zur KI-Lösung verlief ohne eine einzige Anpassung der Organisation oder der Datenstrukturen. Das ist kein Beweis für eine exzellente IT, sondern der garantierte Nachweis für ein lokales Pflaster. Echte Hebel erzwingen strukturelle Veränderungen und das Einreißen von Silos.

**Der Geschwindigkeits-Test**
Die Zeitmessung beginnt bei der Hypothese und endet beim ersten echten KI-Experiment am Markt. Dauert dieser Zyklus länger als wenige Wochen, dominiert die Wartezeit. Das System skaliert Liegezeiten, keine Innovation. Die Organisation lernt schlichtweg zu langsam.

**Der Kultur-Test**
Die Innovation findet ausschließlich in einem isolierten Schatten-Team oder einem Innovation Lab statt. Das Kerngeschäft bleibt unangetastet. Damit wurde die Ausgründung gedanklich bereits vollzogen und der Kern des Unternehmens nicht adressiert.

## 5. Fazit

Der ehrlichste Test bleibt der einfachste: Was wurde abgeschaltet? Kein altes System weg, kein Excel ersetzt, kein Freigabeprozess gestrichen. Dann steht nach zwölf Monaten KI-Initiative nur ein Pflaster.

Der Weg beginnt nicht mit einem Masterplan. Er beginnt mit einer einzigen Entscheidung im Kerngeschäft, die heute schlecht oder zu langsam getroffen wird. Die vier Decision-first-Fragen identifizieren sie. Der Realitätscheck prüft bei jeder KI-Initiative, jedem Quartal, jedem Budget-Review, ob das Ergebnis ein Pflaster ist oder ein Hebel.

Jeder Hebel, der heute steht, beschleunigt den nächsten. Jeder, der nicht gebaut wird, macht den Rückstand aufwändiger aufzuholen.

**Du willst dich mit uns direkt darüber austauschen? Triff uns am Stand MM-21 auf der [data:unplugged](https://www.data-unplugged.de/) am 26. und 27. März 2026 in Münster – dem größten Festival für Daten & KI in Europa!**

[^1]: Vgl. Reinertsen, *The Principles of Product Development Flow*, 2009. Grundlagenwerk zu Flow-Metriken, Cost of Delay und Feedback-Loops in der Produktentwicklung.

[^2]: Vgl. DORA AI Capabilities Model 2025. KI wirkt als Verstärker: Sie skaliert die Stärken leistungsfähiger Organisationen ebenso wie die Schwächen dysfunktionaler.

[^3]: Vgl. Vacanti, *When Will It Be Done?*, 2018; Leopold, *Agilität neu denken*, 2. Aufl. 2022. Beide dokumentieren Flow-Effizienzen unter 15 % in typischen Organisationen.

[^4]: Basierend auf Erfahrungen des Autors in der Domäne. Zur eingesetzten Technologie: https://www.codecentric.de/referenzen/aifora-produktentwicklung-skalieren

[^5]: Der Decision-first-Ansatz wird ausführlich beschrieben in: Marcel Mikl, *Decision-first statt Data-first*, Softwerker. https://www.codecentric.de/wissens-hub/softwerker/softwerker-spezial-daten-ki-effektiv-nutzen

[^6]: Im Kontext von Software-Delivery ist dieser Effekt bereits gut belegt: Laut DORA AI Capabilities Model 2025 hat KI bei niedrigem Data Ecosystem Health keinen nachweisbaren Effekt auf die Organisationsperformance. Bei hohem ist der Effekt stark positiv (S. 22-23).



KI-Pflaster statt KI-Strategie

<p>Typically your favorite machine learning model doesn’t care whether or not your input dataset is professionally and technically correct. However, particularly for machine learning algorithms, the all-encompassing truth <em>garbage in, garbage out</em> holds true and hence it is strongly advised to validate datasets before feeding them into a machine learning algorithm.</p><p>Generally, validating datasets is a tedious task since we have to write a plethora of checks to ensure that the dataset contains all required columns and that the columns contain only expected values. Having written many dataset tests by hand, I was quite happy to stumble upon the Python library <a href="https://github.com/great-expectations/great_expectations" target="_blank">great_expectations</a> , which is a promising tool to validate datasets in a painless way.</p><p>In this blogpost, I want to introduce <code>great_expectations</code> and share some of my thoughts about why I think this tool is helpful in the toolset of every data person.</p><h2>The problem – why validate datasets?</h2><p>From a high-level point of view there are (at least) two kinds of problems occurring while engineering a dataset. First, there are more or less obvious technical errors such as missing rows or columns and wrong datatypes. Second, even when the actual data pipelines are solid and the datasets are put together in a technically correct way, there are often issues with degeneration of data over time. Here, too, we have obvious changes, e.g. additional categories in a categorical column. However, many changes in the data often go undetected. For example:</p><ul><li>the values of a binary column might be approximately evenly distributed between 0 and 1 at the beginning and the distibution could become skewed over time.</li><li>the mean value and standard deviation of sensor data emitted by a physical sensor could drift over time.</li></ul><p>Obvious changes in the data or mistakes while engineering the dataset typically lead to errors in the machine learning pipeline and hence are addressed as soon as they occur. The silent changes, however, are more subtle and they potentially impair the performance of the machine learning model visualized in the following picture.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5htfswGESOu7OlK6XzbD"><img width="250" height="141" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5htfswGESOu7OlK6XzbD" alt="validating datasets: data degeneration" /></a> </p><p>For this reason data monitoring and validation of datasets is crucial when operating machine learning systems.</p><p>In the following, we will look at a small example to introduce <code>great_expectations</code> as a tool for dataset validation.</p><h2>Small example</h2><p>In our example, we use the public domain <a href="https://www.kaggle.com/ajay1735/hmeq-data" target="_blank">hmeq-dataset</a>  from Kaggle. The context of the dataset is automation of the decision-making process for approval of lines of credit. However, in this blogpost we are not interested in the machine learning aspect of the problem. Instead, our goal is to use this dataset in order to show some ideas of the <code>great_expectations</code> library.</p><p>In this small example, we will take a short look at:</p><ul><li>Basic table expectations</li><li>Expectations for categorical data</li><li>Expectations for numeric data</li><li>Saving expectations and validating other datasets</li></ul><h3>Preliminaries</h3><p>The recommended way to follow the small example is to create a fresh <code>Python 3.8</code> environment and install <code>great_expectations</code> and <code>jupyter</code> via</p><div>

```bash
pip install great_expectations
pip install jupyter
```

</div><p>Then, we start a <code>jupyter-notebook</code> and import the library with</p><div>

```python
import great_expectations as ge
```

</div><p>Because <code>great_expectations</code> wraps the popular <a href="https://pandas.pydata.org" target="_blank">pandas</a>  Python library, we can use <code>pandas</code> functionality to import datasets. Hence, we may use</p><div>

```python
df = ge.read_csv('hmeq.csv')
```

</div><p>to read the dataset. In our example, we want to simulate a situation where we generate expectations for a dataset and then apply these expectations to validate, for example, a newer version of the dataset. For this reason, we execute</p><div>

```python
df = df.sample(frac=1).reset_index(drop=True)
split = int(len(df)/2)
df1 = df[:split]
df2 = df[split:]
```

</div><p>to shuffle the dataset and split it into two subsets. Now, we can create expectations using <code>df1</code> and validate the dataset <code>df2</code>.</p><h3>Basic table expectations</h3><p>We can generate hypotheses for the table with <code>great_expectations</code>. For example, we can use</p><div>

```python
min_table_length = 2500
max_table_length = 3500
df1.expect_table_row_count_to_be_between(min_table_length, max_table_length)
```

</div><p>if we have an idea how many rows our dataset should have. Typically, we require specific feature columns in our dataset for our machine learning algorithm. We can create expectations for columns to exist via</p><div>

```python
feature_columns = ['LOAN', 'VALUE', 'JOB', 'YOJ', 'CLNO', 'DEBTINC']
for col in feature_columns:
    df1.expect_column_to_exist(col)
```

</div><p>Table expectations provide simple sanity checks for the dataset. <code>great_expectations</code> manages all expectations in a <code>json</code> file. We can print all established expecations with</p><div>

```python
df1.get_expectation_suite()
```

</div><p>So far the <code>json</code> file should look something like this:</p><div>

```bash
{'data_asset_name': None,
 'expectation_suite_name': 'default',
 'meta': {'great_expectations.__version__': '0.8.7'},
 'expectations': [{'expectation_type': 'expect_table_row_count_to_be_between',
   'kwargs': {'min_value': 2500, 'max_value': 3500}},
  {'expectation_type': 'expect_column_to_exist', 'kwargs': {'column': 'LOAN'}},
  {'expectation_type': 'expect_column_to_exist',
   'kwargs': {'column': 'VALUE'}},
  {'expectation_type': 'expect_column_to_exist', 'kwargs': {'column': 'JOB'}},
  {'expectation_type': 'expect_column_to_exist', 'kwargs': {'column': 'YOJ'}},
  {'expectation_type': 'expect_column_to_exist', 'kwargs': {'column': 'CLNO'}},
  {'expectation_type': 'expect_column_to_exist',
   'kwargs': {'column': 'DEBTINC'}}],
 'data_asset_type': 'Dataset'}
```

</div><h3>Expectations for categorical data</h3><p>Besides checking the whole dataframe, we can also address specific columns. As an example of categorical data, we use the column <code>'JOB'</code>. First, we employ</p><div>

```python
df1.expect_column_values_to_be_of_type('JOB', 'object')
```

</div><p>to expect the correct dtype which typically is <code>'object'</code> in case of categorical data. Next, we can create an expectation for the expected values in the column with</p><div>

```python
expected_jobs = ['Other', 'ProfExe', 'Office', 'Mgr', 'Self', 'Sales']
df1.expect_column_values_to_be_in_set('JOB', expected_jobs)
```

</div><p>A very nice feature of <code>great_expectations</code> is the possibility to create expectations concerning the distribution of the column values. For this purpose we start by creating a categorical partition of the data.</p><div>

```python
expected_job_partition = ge.dataset.util.categorical_partition_data(df1.JOB)
```

</div><p>Then, we can use</p><div>

```python
df1.expect_column_chisquare_test_p_value_to_be_greater_than('JOB', expected_job_partition)
```

</div><p>to prepare a <a href="https://en.wikipedia.org/wiki/Chi-squared_test" target="_blank">Chi-squared test</a>  for comparing categorical distributions.</p><h3>Expectations for numeric data</h3><p>As an example of numeric data, we use the column <code>'LOAN'</code>. Again, we start with</p><div>

```python
df1.expect_column_values_to_be_of_type('LOAN', 'int64')
```

</div><p>to prepare a check for the correct dtype. In addition, we can use expectations such as</p><div>

```python
df1.expect_column_mean_to_be_between('LOAN', 10000, 20000)
df1.expect_column_max_to_be_between('LOAN', 50000, 100000)
df1.expect_column_min_to_be_between('LOAN', 1000, 5000)
```

</div><p>to ensure that min, max and mean of our data are in our expected ranges. Moreover, we can create a continuous partition of the data with</p><div>

```python
expected_loan_partition = ge.dataset.util.continuous_partition_data(df1.LOAN)
```

</div><p>and use</p><div>

```python
df1.expect_column_bootstrapped_ks_test_p_value_to_be_greater_than('LOAN', expected_loan_partition)
```

</div><p>to prepare a bootstrapped <a href="https://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test" target="_blank">Kolmogorov-Smirnov test</a>  for comparing continuous distributions.</p><h3>Save expectations and validate other datasets</h3><p>So far we have defined multiple expectations regarding the dataset <code>df1</code>. In practice, we would require additional expectations concerning other columns of our dataset. For the purpose of our (small) example we stop here. We can save the json file containing our expectations via</p><div>

```python
df1.save_expectation_suite('some_expectations.json')
```

</div><p>In our workflow, we can (and usually should) place the file <code>some_expectations.json</code> under version control. Now, we can use the expecations to validate other datasets.</p><div>

```python
df2.validate(expectation_suite='some_expectations.json', only_return_failures=True)
```

</div><p>In this case, we do not expect to encounter any errors because we randomly split the dataset into two subsets. However, we can see the validation come into play, for example, by dropping a column</p><div>

```python
df2_missing = df2.drop(columns=['LOAN'])
df2_missing.validate(expectation_suite='some_expectations.json', only_return_failures=True)
```

</div><p>or by setting a loan value which is too small</p><div>

```python
df2_min_low = df2.copy()
df2_min_low.at[4, 'LOAN'] = 10
df2_min_low['LOAN'] = df2_min_low['LOAN'].astype('int64')
df2_min_low.validate(expectation_suite='some_expectations.json', only_return_failures=True)
```

</div><h2>Conclusion</h2><p>In the example, we only covered a small subset of the available features of <code>great_expectations</code>. The tool offers more functionality such as</p><ul><li>more built-in expectations and even custom expecations</li><li>ways to integrate into data pipelines, e.g. with support for Spark</li><li>web-based data profiling and exploration</li><li>slack notification for failed validations</li></ul><p>which I have not used outside of small tests.</p><p>In my opinion, <code>great_expectations</code> appears to be a useful addition in the tool kit of each data scientist/engineer. It has a low barrier of entrance since it can basically be reduced to an additional <code>json</code> file living in the code repository, but it has the potential to significantly simplify validating datasets and, in particular, debugging data pipelines.</p><p>At the moment, I am not a great fan of the initialization via <code>great_expectations init</code> and the resulting folder structure in the project directory. However, I did not use <code>great_expectations</code> under real conditions and maybe there are advantages of this setup that I do not see at the moment.</p><p>Overall, <code>great_expectations</code> appears to integrate nicely in many machine learning pipelines and I cannot wait to extensively test the tool in future projects. If you have any experiences with <code>great_expectations</code>, feel free to share them in the comments.</p>

Great Expectations: Validating datasets in machine learning pipelines

Remote training with GitLab-CI and DVC

<p>While doing AI is sexy and cool, data infrastructure is typically not considered any of this. However, production-grade machine learning applications heavily rely on proper data infrastructure. Hence, in order to generate actual business value, solid data pipelines are required.</p><h2>A truth about data science projects</h2><p>Consider the following story: We start a data science project with a time-boxed proof of concept (PoC) having a skillful and enthusiastic project team that generates insights in fast iterations. After our time box ends, we achieved promising results and get the opportunity to present them in front of “the decision makers”. Luckily, we ace our presentation and it becomes more and more clear: “this idea is a winner!”. Everyone is feeling great.</p><p>However, under the hood, the promising results were achieved on a local machine with data dumps (CSV files) from multiple data sources carefully hand-crafted by an SQL expert with a special series of magical queries. Clearly, it is often very useful to work with data dumps for fast iterations, but clearly it is also a shortcut.</p><p>This shortcut becomes a problem when it is ignored. Even worse, when it is not properly communicated and understood by “the decision makers”. The trade-off for fast insights and results during the PoC was not considering data infrastructure and building proper data pipelines. Now, after everyone is hyped about the successful presentation and expects business value within “a few days”, we have to face the truth – we took a shortcut and before we can generate business value, we have to fix it.</p><h2>A heavy burden for data science projects</h2><p>Because it is possible to have short-term success as sketched in our fictional story, often times, the AI hype drives companies to start data science projects before evaluating and thinking about the current state of their data infrastructure. This can be useful in order to validate ideas. However, it becomes a problem if not all stakeholders are aware that the implications, i.e., building a production-grade machine learning application, are (depending on the data infrastructure), more probably than not, a challenging next step.</p><p>At worst, outdated and missing data infrastructure can lead to the bizarre situation where a data science project team is faced with the task to casually solve company-wide data infrastructure challenges. On the quest for generating business value after a successful PoC, the project team has to deal with organisational issues without much public awareness, and hence without much support – possibly resulting in frustration and failure to generate business value with the once so promising idea.</p><p>Metaphorically speaking, the team is driving a sports car (the shiny new machine learning model) on a forest path (the data infrastructure) and everyone around wonders why they do not run on full speed resulting in the impression that it is simply not possible to generate actual business value with data science projects.</p><h2>The attitude towards data infrastructure</h2><p>Historically, setting up a new data infrastructure is associated with great pain. This is because it is typically related to huge investments of time and money. Furthermore, there are various paradigms, e.g. data lakes (see <a href="https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/" target="_blank">here</a>  and <a href="https://jamesdixon.wordpress.com/2014/09/25/data-lakes-revisited/" target="_blank">here</a> ), <a href="https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html" target="_blank">data lakehousing</a>  and <a href="https://martinfowler.com/articles/data-monolith-to-mesh.html#TheNextEnterpriseDataPlatformArchitecture" target="_blank">data meshes</a>  each with different sets of benefits and trade-offs to consider. However, improving the data infrastructure is expressly not solely a technical issue. In fact, what is even more important is changing the mindset about the significance of data in the company. This change is likely the single most crucial step for generating sustainable and growing business value with data science projects.</p><p>There are (at least) two reasons to rethink data infrastructure:</p><h3>Faster cycle time for validation</h3><p>Clearly, starting with a PoC as described above yields first insights as to whether or not an idea is promising. However, without proper data infrastructure, it is usually hard and costly to validate an idea end-to-end. This usually leads to lengthy discussions about if and when to start without actually starting to learn valuable lessons about the idea. Having proper data infrastructure allowing for fast end-to-end validation and experimentation enables one to dismiss unsuccessful ideas faster and makes it possible to single out the successful ones. The ability to validate ideas with fast end-to-end experiments is particularly crucial for building successful machine learning applications because there are many moving parts and the application typically affects various parts of the company.</p><h3>True value is the ability to utilize machine learning algorithms</h3><p>Typically, there are plenty of ideas on how to use data science to generate business value in a company. More often than not, there are also known machine learning algorithms already used by others to implement the same or similar ideas. Hence, there is legitimate reason to assume that this known algorithm supposedly would work at least well enough for a first version of the application. However, many times it is not the knowledge about the algorithm, but the availability of data and the ability to integrate the algorithm end-to-end into the company infrastructure in a painless way which decide if business value can be created.</p><h2>(Re-)thinking data</h2><p>Starting to (re-)think data is not only a technical issue; first it amounts to asking questions like</p><ul><li>What data is available?</li><li>What quality does the data have?</li><li>Who owns the data?</li><li>Who controls access to the data?</li><li>Who is responsible for the data and its quality?</li><li>What is the current relationship between producers and consumers of data?</li><li>How can we evolve and improve this crucial relationship?</li></ul><p>Here, the main driver for answering these questions is to find ways to reduce the overall end-to-end cycle time for the development of machine learning applications by improving, for example, the availability, the processing speed and the quality of data. In most cases, we do not recommend to actually solve all data infrastructure problems upfront and then start data science projects. In fact, many issues are typically unknown at this point and it is very challenging to find suitable solutions without implementing specific applications.</p><p>Hence, it is perfectly fine to start rethinking data on a large scale and act small on a use case by use case basis. For one thing, this allows validating different technical approaches. For another (this is probably more important), it allows changing the mindset about the significance of data step by step. The focus here is on implementing use cases end-to-end learning, in particular, to build production-grade machine learning applications. At this stage, using cloud infrastructure offers a good way to move quickly without much ramp-up. As soon as several use cases create business value, unifying the data infrastructure might yield additional value.</p><h2>Summary</h2><p>While everyone is talking about AI, in the end it takes much more than data science and machine learning algorithms to build production-grade machine learning applications and generate business value. Moreover, sustainable business value with machine learning and AI requires more than clever algorithms – it requires rethinking data.</p><p>In fact, many state-of-the-art algorithms are publicly available, e.g. the <a href="https://en.wikipedia.org/wiki/PageRank" target="_blank">Google search algorithm</a>  and even the <a href="https://patents.google.com/patent/US7058628B1/en" target="_blank">patent is expired</a> , the state-of-the-art model for natural language processing <a href="https://github.com/google-research/bert" target="_blank">BERT</a>  is open source and the network architecture for state-of-the-art image classification <a href="https://en.wikipedia.org/wiki/Residual_neural_network" target="_blank">ResNet</a>  is available and even implemented in various frameworks like Keras and Pytorch.</p><p>However, the major part of the business value is not the algorithm but the capability to employ the algorithm in a production-grade machine learning application, and hence the true value lies in the underlying data (often not open source) and the data infrastructure.</p><p>Here, a big bang attempt to change the data infrastructure or start by pouring all available data into a single place is more often than not an unnecessarily challenging approach. Instead, starting to rethink data – use case by use case – and building a suitable data infrastructure on the way appears to be much more promising.</p><p>If you are interested in some more ideas and our approach to data science projects, see the <a href="/wissens-hub/blog/wie-man-data-science-projekte-nicht-in-die-poc-sackgasse-manoevriert">blog post</a>  (German) and the free on-demand <a href="https://www.codecentric.de/wissens-hub/webinare/webinar-data-science-projekte">webinar</a>  (German).</p>

Thinking AI means re-thinking data

<p></p><p>This is the second article in our dish-o-tron series (a non-standard Deep Learning tutorial) in which we tackle one of the biggest problems in community kitchens: coming across someone else’s dirty dishes. We are facing this problem by building a state-of-the-art AI-system – the dish-o-tron.</p><p>If this is the first time you hear about the dish-o-tron and you are interested in the whole story, you might want to start with the <a href="/en/knowledge-hub/blog/dish-o-tron-no-more-dirty-dishes-ai">first part.</a> </p><p>In our conception, the dish-o-tron uses a computer vision AI model in order to detect dirty dishes, hence we require training data to produce this kind of AI-model. A brief look around reveals there is no suitable data available. This might come as a shock. However, this realization is a typical issue for many problem solvers tackling real-world problems with AI. Don’t get discouraged!</p><p>In this blogpost we start building the dish-o-tron hands-on by gathering an initial “good enough” data set for the next steps. Although we have already collected a dataset that we will share with you at some point, we need to point out that we will NOT share the link with you until you have collected your own data. In order to have the real dish-o-tron-experience, it is absolutely necessary that you gather training data yourself.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Ptc49Z3cSSWvrFc6feqP"><img width=640 src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Ptc49Z3cSSWvrFc6feqP" alt="dish-o-tron" /></a> <br /> <i>image source: pixabay.com by Dieterich01</i></p><h2>Approach and reasoning</h2><p>The high-level idea is to just start tackling the problem with an end-to-end solution. For the first prototype it is reasonable to take some shortcuts. In many cases this is a very promising approach. We do not want to start by collecting data for a few months, then train “the best” AI-model for a few weeks and finally try to set up a dish-o-tron on a kitchen sink.</p><p>Instead, we’d like to put a first version of the dish-o-tron on a kitchen sink as fast as possible and iteratively improve the solution. In this way, we can (hopefully) decide with more certainty which parts actually need improvement by taking into account real-world feedback.</p><p>So in this first article, we gather and prepare an initial data set for the dish-o-tron in a hands-on way and in three steps:</p><ul><li>Making videos of clean and dirty kitchen sinks</li><li>Splitting the videos into images of clean and dirty kitchen sinks</li><li>Splitting the images into training, validation and test data sets</li></ul><p>As a starting point for your data collection we provide a Google Colab notebook to follow along. A Colab notebook is a service designed by Google that allows you to run code and train models in the cloud. And the best part: it is currently free. Think of a Colab notebook as a Linux Docker container that runs a web server that can execute Python code and even allows you to use a GPU for model training. You have a temporary file system in your container where you can download stuff and install libraries etc.</p><p>You can find the Colab notebook <a href="https://colab.research.google.com/drive/1tgXsHuG3yi-aoOL26y5DRwBovQC_PkhL" target="_blank">here.</a>  (You will need a Google account to be able to run the code. Save a copy of the notebook to your Google drive to persist your changes.)</p><h2>Videos of kitchen sinks</h2><p>As we have already mentioned several times (sorry but not sorry!), gathering data is a key step for many problem solvers to tackle actual real-world problems because these problems typically do not start with a polished Kaggle data set. For this reason, we strongly encourage you to leave the comfort of your desk chair and make videos of the kitchen sink in question.</p><p>Yes, at first glance, this is quite a hassle. However, gathering data on-site is a valuable learning experience because we obtain important information about the problem and its domain. In our case, this involvement with the domain, for instance, leads to questions like:</p><ul><li>What should the videos look like?</li><li>What data is useful and required for solving the problem?</li></ul><p>Thinking about such questions is important in order to tackle the actual problem at hand and not focus too narrowly, for example, on the AI component of the dish-o-tron.</p><p>A few further (possibly) helpful considerations about the videos:</p><ul><li>Take note of the future position of the dish-o-tron for the perspective</li><li>It might be useful to take several videos of clean and dirty sinks with little changes such as:<ul><li>switching the lights on/off</li><li>changing the position of the water tap</li><li>repositioning of unrelated objects around the sink</li></ul></li><li>It might help to move the camera slightly back and forth to add some variance</li><li>Dirty sinks come in many different configurations when making several videos with e.g. different plates/cups/cutlery, and changing their positions might be required.</li></ul><p>This is certainly not a complete list, feel free to point out additional considerations for the videos.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d97f5igJQLujDf59Z0x7"><img loading="lazy" width="640" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/d97f5igJQLujDf59Z0x7" alt="kitchen sink" /></a> </p><p>Are you still sitting in your comfy desk chair? Did our passionate plea for the importance of gathering data not convince you? <p><b>You can do this! Gather data for your dish-o-tron!</b> <b>It’s worth it! Just grab your smartphone and follow these instructions:</b></p><ul><li>use a landscape perspective (please say NO to vertical videos)<br /> If you are not sure why you should say NO to vertical videos, please study this comprehensive explanation on  <a href="https://www.youtube.com/watch?v=f2picMQC-9E" target"_blank">YouTube</a>.</li><li>film from a top-down position (not from the front)</li><li>it’s allowed to have objects located next to the sink</li><li>the difference between clean and not_clean is only determined by whether or not there are dishes <b>IN</b> the sink</li><li>Don’t scroll down to read more. <b>Take your smartphone and go to the sink.</b></li></ul><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mHfedOJHSoeMEO1POg3Y"><img loading="lazy" width="640" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mHfedOJHSoeMEO1POg3Y" alt="kitchen sink" /></a> </p><p><span><b>PRIVACY WARNING: Make sure you do not record any personal things like photos or other people. Since you are recording video, also make sure you don’t record any conversations or other persons. Otherwise you won’t be able to share and talk about your great work later. Then you won’t become famous for building the best dish-o-tron in the world. As a result, you will not get the job as AI Lead at the self-driving car company and so on. So be careful, you have been warned.</b></span></p><p>Record 5 short videos (3-5 sec.) of a clean sink:</p><ul><li><ul><li>slowly move the camera slightly to get some different angles and reflections</li><li>for each video change some conditions e.g.<ul><li>switch light on/off</li><li>open the tap to make the sink wet</li><li>move the tap</li><li>… be creative – what else could happen?</li></ul></li></ul></li></ul><p><br /> (sample video for not_clean sink)</p><p>Record 5-8 short videos of a not_clean sink:</p><ul><li>put dishes/glasses/tools/pans whatever into the sink</li><li>for each video change something<ul><li>move the position of dishes</li><li>put more / remove</li><li>change light</li><li>…</li></ul></li></ul><p>That’s it. You have collected your very own first data to build the dish-o-tron. For the next steps this data will be enough. Will this data suffice to build a reliable AI product that works under every condition? Absolutely not! However, this data lays the foundation for building a running AI system and iteratively improving it.</p><p>Another source for additional data is your friends and colleagues. Just tell them about your journey to turn the community kitchen into a peaceful meeting ground. Ask them to provide additional videos of their dirty dishes for your collection. Believe it or not, this may be a nice door opener and starting point for interesting conversations with people to whom you didn’t talk for a while (and perhaps won’t for a while)!</p><h2>Labeling data</h2><p>Now go back to the <a href="https://colab.research.google.com/drive/1tgXsHuG3yi-aoOL26y5DRwBovQC_PkhL" target="_blank">Colab notebook</a>  and merge your data collection with the data that we provided. You can upload your additional videos into the Colab environment, for example via the UI in the panel on the left-hand side.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/OXJmNsZIT3KGwxs5vtYk"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/OXJmNsZIT3KGwxs5vtYk" alt="colab notebook" /></a> </p><p>Put them into <code>data/video_samples</code> and sort them into the right subfolders (first 5 into <code>clean</code> and the rest into <code>not_clean</code>). With this sorting step you have “labeled” the data. You told the dish-o-tron what a <code>clean</code> and a <code>not_clean</code> sink looks like. From your knowledge, dish-o-tron can learn everything!</p><p>That’s all the magic. You have put pictures into folders. Bravo.</p><p>OK, to be fair, labeling at scale is not that simple. Some datasets have millions of images. Some labels are not as easy to give as <em>clean</em> or <em>not_clean</em>. For example, a label could also be that you need to mark every pixel in an image where you see a road and seperate it from a wall. This might help a self-driving car to stay on track. Labels like this for millions of images can be very expensive – but also very valuable.</p><p><em>A short side note: Typically, AI systems benefit from large databases. Hence, we considered kick-starting a crowdsourcing campaign in order to gather a community DISH-O-TRON dataset. Potentially, this could improve all dish-o-trons around the world and crowdsourcing datasets would also be useful for various other kinds of problems. </em></p><p><em>In other IT communities, there are tools and platforms to collaboratively share and grow code. In some open-source software projects, hundreds or even thousands of collaborators are contributing to one big mission goal (often without getting anything back but good software). Unfortunately things like this do not yet exist to grow and collect datasets. But wouldn’t it be great to have a GitHub for datasets? To have a Kickstarter for data collection initiatives? To have hundreds of people around the world collecting data to feed the dish-o-tron? But maybe the data would just be too valuable to be shared – being the new oil or was it electricity? If you are interested in collaboratively building a large (dish-o-tron) dataset, please drop us a note.</em></p><h2>Splitting images in train, validation and test datasets</h2><p>A fundamental concept in training machine learning models is splitting the dataset into train, validation and test datasets. Because this concept is a comprehensive topic on its own, we only briefly discuss the intricacies of data splitting here. To get a better understanding, we strongly recommend familiarizing yourself with this topic further. A possible starting point is the articles <a href="https://www.fast.ai/2017/11/13/validation-sets/" target="_blank">here </a>  and <a href="https://mlbook.explained.ai/bulldozer-testing.html" target="_blank">here.</a>  (For our German speaking readers: You could also watch our introduction to machine learning video from our AI bootcamp <a href="https://youtu.be/iX9r8wvjKdo?t=1167" target="_blank">here</a> .)</p><p><em>Another side note: <a href="https://www.fast.ai/" target="_blank">fast.ai</a>  is a really great starting point if you want to learn more about machine learning. Big kudos to Jeremy Howard, his team and the fast.ai community. You have been a great inspiration to us as well. We have watched your lessons. We love your practical way of teaching. Implement something and learn by doing! It’s not necessary and also not possible to understand all details of Deep Learning before you build something. Like this you will never build something. That’s how the dish-o-tron was born, by the way. </em></p><p>Choosing a validation dataset and test dataset in order to evaluate the model more or less defines the rules of the game. Hence, it is crucial to understand the implications of the chosen splitting approach. For example, in our case, the images originate from videos, and hence are not completely unrelated in this sense. Two chronologically close frames of a video might not be very different potentially resulting in two very similar images in the train and test dataset.</p><p>In the future it could be useful to have a test set for the dish-o-tron containing only images from kitchen sinks that are not present in the training and validation dataset. Many times it is not clear at the beginning what the test set should look like and creating a reliable test set is an art in itself. In many cases, we have to iterate and improve it over time.</p><p>A rule of thumb is that the test set should represent the actual real-life situation as well as possible. Therefore, there is a good argument in favour of putting data from the same kitchen sink into the train, validation and test set if the model for the dish-o-tron is only used for one particular sink.</p><p><strong>Attention:</strong> the Colab notebook only provides temporary storage and all data will be deleted if the notebook is closed. Hence, to persist the data, you have to download it or store it, e.g. in your Google Drive storage.</p><h2>Conclusion</h2><p>In this article we tackled a sub-problem that appears to be tedious at first glance. However, gathering data, working and preparing data, understanding the data and its origins are fundamental tasks for problem solvers to understand the big picture of the problem at hand.</p><p>We hope that we were able to motivate you to actually get up from your desk and take videos of kitchen sinks in various configurations and work with the data. This is an important step to build the dish-o-tron and get the real problem solver experience.</p><p>In the next article we will use that data to train our first model. We will demonstrate this by using a service like Google AutoML as well as an easy-to-use framework like fast.ai. If you want to get in contact with us and maybe ask for the whole DIRTY-DISHES-DATASET, please answer to this <a href="https://twitter.com/MoserOli/status/1306864868490870784" target="_blank">tweet. </a> </p><p>Continue with the <a href="/en/knowledge-hub/blog/dish-o-tron-train-that-vision-model" target="_blank"> third part</a>  of our series where we train the vision model.</p>

DISH-O-TRON – Gather that DATA you must!

<p></p><p>With this article we continue our endeavor of building dish-o-tron – an AI system designed to prevent the sudden appearance of dirty dishes in the community kitchen sink, and hence turning the community kitchen into a place of peace and harmony.</p><p>This is part 3 of the dish-o-tron series, you may want to start with the <a href="/en/knowledge-hub/blog/dish-o-tron-no-more-dirty-dishes-ai">first part</a>  where we introduce the idea and the concept behind dish-o-tron and the <a href="/en/knowledge-hub/blog/dish-o-tron-gather-that-data-you-must">second part</a>  where we collect the initial data set.</p><p>In this article, we use the data gathered in the previous part to build “the heart” (or – perhaps better – “the brains”) of dish-o-tron empowering it to detect dirty dishes. In concrete terms, we train a machine learning model which is capable of classifying images of sinks into clean (no dirty dishes) and not_clean (dirty dishes) using the fast.ai library and AutoML from Google Cloud.</p><p>If this is the point where you think to yourself “oops, I did not gather any data” – we warned you several times. It is absolutely necessary that you gather training data yourself to have the real dish-o-tron-experience. We strongly encourage you to revisit the previous article and gather your own data and, in particular, don’t download our pre-prepared <a href="#">dataset</a> .</p><p></p><p>If this is the point where you think to yourself “Yay, I did gather my own data”: congratulations, you may now continue your journey and indulge in one of the most favourite occupations of every deep learner: watching an AI-model during training.</p><p>If you are a developer maybe you know watching your program compile or watching your CI/CD pipeline running tests. But watching an AI model train is something special. And if you watch harder (but not too hard) you might even influence the accuracy of the outcoming model! Depending on the architecture it might be necessary to watch deeper instead of harder – you will find out with further practice.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/JNowHiDoSdaBTGA0wtlf"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/JNowHiDoSdaBTGA0wtlf" alt="dish-o-tron: codes compiling, model is training meme" width="250" height="126" /></a> <p>Comics taken from <a href="https://xkcd.com/303/">1</a>  and <a href="https://www.reddit.com/r/ProgrammerHumor/comments/9cu51a/shamelessly_stolen_from_xkcd_credit_where_is_due/">2</a>  kudos to XKCD</p></div><p>We start with a short excursion about the requirements of dish-o-tron.</p><h2>Excursion: Revisit some requirements of dish-o-tron</h2><p>The dish-o-tron needs to be able to set off an alarm in case of a coworker violating the general rules of using the community kitchen. In most kitchens there are rules are like:</p><ul><li>DO NOT PUT DIRTY DISHES IN THE SINK!</li><li>Please, respect rule number 1 !!!1!eleven!</li><li>If the dishwasher is running, take your stuff and leave it at your desk until the dishwasher has finished.</li><li>EVERYBODY can empty the dishwasher.</li><li>NO EXCUSES. DO NOT PUT DIRTY DISHES IN THE SINK. NEVER.</li></ul><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/h2VWosxkSv21T3UaQPK5"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/h2VWosxkSv21T3UaQPK5" alt="dish-o-tron: community kitchen rules" width="247" height="300" /></a> <p>Exemplary community kitchen rules</p></div><p>In many kitchens these rules are manifested on various posters, stickers and even laminated printouts! Some even colorize words (OMG!) to emphasize that really everybody should take care of this. But we all know it. We are rebels. While reading these signs one always thinks: One day, when nobody sees me, I will just put my cup in the sink and run!</p><p>So far, we are not sure if this is only a German thing and thus if you have rules like this in your community kitchen please share a pic by answering to this <a href="https://twitter.com/MoserOli/status/1306864868490870784" target="_blank">tweet. </a> .</p><p>Because there is nothing we can do about this – we have to find another solution. The next reasonable step obviously is: Permanent control and punishment. That’s where dish-o-tron enters the arena. Inspired by the DEFCON levels of the United States Armed Forces we therefore propose the DISHCON levels (see <a href="https://en.wikipedia.org/wiki/DEFCON">this</a>  wikipedia article for reference.)</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/qofjtBnRB2W51gb2QP6z"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/qofjtBnRB2W51gb2QP6z" alt="dish-o-tron: table with dishcon levels" width="250" height="68" /></a> <p>The dishcon levels.</p></div><p>Since we are peace-loving problem solvers the escalations for DISHCON 1 and 2 WILL NEVER be implemented. Also privacy is important to us, so we will not record or save any images. We will not transfer any footage to the cloud. Dish-o-tron sees, maybe beeps, and then it just forgets.</p><h2>Approach and Reasoning</h2><p>Until only recently training a machine learning model for image classification would have required special knowledge in Data Science, however, current progress and development in particular in the environment of public cloud providers significantly simplified this task for problem solvers looking for rapid end-to-end progress.</p><p>This low barrier of entry into AI systems allows us to rely on existing libraries such as fast.ai and services like AutoML from Google Cloud to obtain a reasonable state-of-the-art vision model for our classification task. In this way we can build the first functioning prototype and focus on solving the actual problem at hand. At a later stage it might be useful to revisit the model training, however, the best model is useless as long as it is not integrated.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nCond4pDT4QKjh3Dhmb1"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/nCond4pDT4QKjh3Dhmb1" alt="sidetracked meme" width="700" height="235" /></a> </p><p>For many people dealing with AI and building neural networks from scratch is a lot of fun. However, be honest with yourself! There is close to zero chance that you will create something that will come close to existing solutions. In fact, you will spend lots of time for a worse outcome. It is essential that you focus! Don’t get sidetracked! You are a problem solver. Your goal is to solve an actual real-world problem. The AI model is merely a tool for you to bring peace and harmony to your community kitchen.</p><p>In the following, we pursue two options to obtain a vision model in just a few steps:</p><ul><li>We utilize the fast.ai library</li><li>We use AutoML in the Google Cloud</li></ul><p><em>Short sidenote: Yes, it might be useful to revisit the vision model at some point. At this stage of the project it is helpful to think about this point in time in terms of “as soon as 80% of all community kitchen sinks are equipped with a dish-o-tron”.</em></p><h2>fast.ai</h2><p>fast.ai is per se a great starting point if you want to start with deep learning and machine learning. With the mission of “Making neural nets uncool again” it provides a competitive high-level python library allowing for rapid progress while building an AI system.</p><p>The fast.ai library allows you to train state-of-the-art vision models in a few lines of code. To get started you use the following colab-notebook:<br /> <a href="https://colab.research.google.com/drive/136Ios1VaMjQ-fJDsUi7umq41aX7NVmaT?usp=sharing" target="_blank">Colab notebook</a> </p><p>When finishing this notebook you will end up with a fast.ai model which is basically a pytorch model. This model can also be exported and used outside of the colab-notebook environment. However, so far we struggled a lot to deploy fast.ai models on edge devices and in particular on a Google Coral device. Somehow we did not find a painless way to do so. Feel free to investigate on your own and we are very happy if you reach out to us if you find a nice way.</p><h2>AutoML</h2><p>AutoML is a Machine Learning Service from Google Cloud which allows you to automate the training of your own custom vision models. It comes with a graphical interface and the option to, e.g., export models to edge devices such as the Google Coral device. The only thing you have to provide are labeled images and money. Yes, that’s basically it: you trade money for AI-expertise and speed. For training a model with ~10.000 labeled images we expect costs of ~25 $.</p><p>Does this mean AutoML is always the right solution? Not at all! But it is a nice tool to have if you are looking for rapid end-to-end progress. This is particularly the case if the goal is to validate ideas. Here, learning slowly and struggling to make any real end-to-end progress with an idea in favour of saving a few bucks on your cloud bill is often the worst choice.</p><p>Obtaining an AutoML vision model requires four simple steps:</p><ol><li>A tiny bit more data preparation and uploading the data</li><li>Creating the Dataset in AutoML</li><li>Training a readily available computer vision model in AutoML</li><li>Export the model (in a suitable format for the Coral device)</li></ol><p>In order to follow along you require access to the Google Cloud and a Google Cloud project ideally with <code>project-owner</code> access privileges.</p><p><em><strong>ATTENTION:</strong> Not everything we do is covered by the free-tier and hence, some charges may apply.</em></p><h3>1. Data preparation</h3><p>Before we can use AutoML to train a vision model, we have to upload our data to Google Cloud and also prepare a CSV file containing meta information about the data such as, e.g., labels of the images. This is a necessary evil before we can finally lean back and throw some money at Google to do the rest of the work.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mGbRQvrmS02hhbTGaTft"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mGbRQvrmS02hhbTGaTft" alt="shut up and take my money meme" width="250" height="141" /></a> </p><p><a href="https://colab.research.google.com/drive/1Fow9mUGSICF7gCdoyACJvI3n3TjZlfib?usp=sharing" target="_blank">This Colab notebook</a>  should help you to take the final hurdle. Here, we provide a possible way to:</p><ul><li>Upload our data into a Storage Bucket in Google Cloud</li><li>Generate the necessary metadata CSV-file for AutoML</li></ul><p>Finally, we are in a position to use AutoML.</p><h3>2. Creating the dataset in AutoML</h3><p>The starting point for using AutoML is creating a dataset. Because we already uploaded the data into a GCS bucket and prepared the CSV metadata file, we can create the dataset with a few clicks in the UI. After triggering the upload the import will take some time. This is your chance to ponder about life and do some meditation. You could also watch some cat videos – if this is your thing – or just grab a cup of coffee. While you are in the kitchen there might be an opportunity to collect another dirty dishes video. Don’t get mad – you already made fantastic progress on your journey to build dish-o-tron.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1zsudeBESL6gFqlv3ci6"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1zsudeBESL6gFqlv3ci6" alt="creating a data set in automl step 1" width="250" height="114" /></a> <p>Creating a data set in AutoML.</p></div><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2JNWp6NJTcahGYuotHxZ"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2JNWp6NJTcahGYuotHxZ" alt="creating a dataset in automl part 2" width="250" height="151" /></a> <p>Using the prepared csv file.</p></div><p>As soon as the import is finished, we can inspect the dataset in AutoML. It is useful to make a few sanity checks at this point to ensure that the data is uploaded correctly.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/dURFuIRUGrGwkKmAoAtw"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/dURFuIRUGrGwkKmAoAtw" alt="Inspecting a dataset in AutoML" width="250" height="113" /></a> <p>Inspecting a dataset in AutoML</p></div><h3>3. Training the vision model</h3><p>And now, finally, it is going to happen. We can start training the model with a few clicks in the UI. Because we plan on deploying the model on a Coral device, we choose the option “Edge”. For simplicity we select “optimize for best trade-off between latency and accuracy” and set (depending on the number of images) a suitable amount of node hours.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/S6egV82hRWerd4KoFEcY"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/S6egV82hRWerd4KoFEcY" alt="table with node hours depending on number of images" width="250" height="88" /></a> <p>Suggested node hours depending on number of images in the dataset.</p></div><p>Please be aware that for each unit of time, Google Cloud uses 8 nodes in parallel, where each node is equivalent to a n1-standard-8 machine with an attached NVIDIA® Tesla® V100 GPU. Hence 8 node hours are approximately 1 “wall clock” hour. It is advisable to use the early stopping feature to ensure that training stops when further accuracy improvement is not possible. In the end, you pay only for the compute hours that are actually used.</p><p>Now push the final button.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/tkDuIuA1TNeZlKpH5ZdN"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/tkDuIuA1TNeZlKpH5ZdN" alt="start model training in automl" width="250" height="240" /></a> <p>Start model training in AutoML</p></div><p>You did it! You are now a real Deep Learner! Feel free to relax for a few hours and check at irregular intervals if the training is finished. This is your time to take a break without feeling bad about it. That is what being a Deep Learner is all about.</p><p>Training a model is a magical experience. Don’t forget to check on your model and observe it during the training every once in a while: Rumour has it that observing the training procedure will change the outcome of the experiment. There are even stories that the intensity of the observing influences the accuracy of the model.</p><p>When the training is complete or at the latest, when you are back at your desk and observe that the training is complete, it is time for a few sanity checks of the model. Again this is possible with built-in validations of AutoML. If the accuracy is below 95% there is a strong reason to believe that something went wrong with the data or the data preparation.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jBmDFNdRSrKDoI76UjuJ"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jBmDFNdRSrKDoI76UjuJ" alt="Model evaluation in AutoML" width="250" height="119" /></a> <p>Evaluating a trained model in AutoML</p></div><p>If everything looks fine, we export the model for coral devices.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mj7LYAgQR6Cwk1pFItMA"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mj7LYAgQR6Cwk1pFItMA" alt="exporting a trained model in AutoML" width="250" height="207" /></a> <p>Exporting the trained model in AutoML</p></div><p>That’s it! We have our first vision model for our dish-o-tron. Peace and harmony for your community kitchen were rarely as tangible as at this point in time.</p><h2>Conclusion</h2><p>Finishing this part of the tutorial is an important step for you and your future career as a professional problem solver. Frankly, that’s one (very) small step for Deep Learning, one giant leap for you – but that is okay. Be proud of yourself! This is how successful real-world problem solvers tackle AI tasks for the first iterations.</p><p>Okay, let’s make this more official: you have earned the AI TRAINING WATCHER badge (silver level)</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/G1Aqu5RLivGOERab3gvo"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/G1Aqu5RLivGOERab3gvo" alt="AI-Model watcher badge" width="250" height="135" /></a> </p><p>Don’t be shy, you earned it! Feel free to print it out and proudly wear it however you enjoy!</p><p>In the next article, we will build the first physical version of DISH-O-TRON which can (and should) be put into use at a real community kitchen sink. Stay tuned!</p>

DISH-O-TRON – Train that vision model!

<p><em>Sadly, to tell you the truth, doing dishes is still a thing. However, so far most of our readers still like our non-standard Deep Learning tutorial.</em></p><p>Typically, AI is demonstrated as solving various toy problems. AI plays chess and Go, AI plays video games, AI makes people dance. It is time to stop this madness and finally apply AI in a meaningful way. Therefore, we proudly present the dish-o-tron. The dish-o-tron is an AI system designed to solve an actual real-world problem impacting millions of people around the world every day: facing dirty dishes in the community kitchen sink.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pcyYzx0XQNaMmoRiwcBn"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/pcyYzx0XQNaMmoRiwcBn" alt="dirty dishes in the community kitchen sink" width="250" height="107" /></a> <p>dirty dishes in the community kitchen sink – a real-world problem</p></div><p>Reading this blog series will equip you with the ultimate power to solve this long-lasting problem in your community kitchen once and for all by using state-of-the-art AI technology.</p><h2>The dish-o-tron</h2><p>At first glance, the dish-o-tron is an inconspicuous, well-positioned webcam in the kitchen observing the shared kitchen sink. In its natural state the dish-o-tron is just happy and enjoys life. The dish-o-tron doesn’t care whether you prefer tea or coffee and it likes all kinds of kitchen talk. However, there is one single thing that the dish-o-tron absolutely hates: watching someone put dirty dishes in the community sink.</p><p></p><p>Detecting dirty dishes in the sink enrages the peace-loving dish-o-tron so much that it starts beeping. The only way to return it to its natural peaceful state and thus stopping the noise is to admit one’s mistake and remove all dirty dishes from the community sink, leaving it neat and clean again.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KshoGpISnyD4NikRB1A8"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KshoGpISnyD4NikRB1A8" alt="respect privacy in the kitchen" width="250" height="166" /></a> <p>privacy in the kitchen has to be respected.</p></div><p>Building the dish-o-tron requires three high-level steps:</p><ul><li>Gathering and preparing data</li><li>Training an AI model</li><li>Deployment of the model</li></ul><p>In the following, we will discuss these steps further.</p><h2>Gathering and preparing data</h2><p>Trying to solve real-world problems with AI often starts with the realisation that there is little or even no data available. This issue prevents many problem solvers from actually solving the problem. “If only data collection had started years ago!”, they say, “then we could now actually solve the problem”. While this is a reasonable thought, it simply doesn’t help.</p><p>Consoling users currently facing a problem by saying that it is necessary to gather lots of data for quite some time before we can start building a solution is at least challenging. Typically a more promising approach is to build a system addressing the problem which is able to improve over time.</p><p>In this way, we will not solve the problem completely in the first step; however, we will tackle the problem right away and put ourselves in a position to iteratively adjust the solution to match the requirements which also become more and more clear while working on the problem.</p><p>Since our problem is unique in a sense that there is no Kaggle dataset readily available, we start our journey to building the dish-o-tron by doing our best to collect a suitable dataset for a first working system. Here, we will make videos of various kitchen sinks clean and not clean and split them up into a first labeled dataset.</p><p></p><p>In this way, we started collecting the DIRTY-DISHES-DATASET with thousands of pictures that we will share with you in the next article.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/JuNFMzUpTqRtwMfQmcOS"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/JuNFMzUpTqRtwMfQmcOS" alt="sample images from the dirty-dishes dataset" width="250" height="151" /></a> <p>sample images from the dirty-dishes dataset</p></div><h2>Training an AI model</h2><p>Not so long ago, training an AI model was tedious and required expert knowledge. In many cases this is still true today. Depending on the problem, we have to figure out a suitable model architecture and feature engineering and this requires some experimentation before we can train a suitable AI model. This is another issue which prevents problem solvers from building a solution tackling the whole problem even if data is available.</p><p>Fortunately, image classification is one of the best understood use cases in AI. There are lots of established best practices regarding model architectures and training of models. Among others this led to two things:</p><ul><li>High-level software libraries such as fast.ai which abstract away lots of the nitty-gritty details of image classification, providing a black-box kind of approach where state-of-the-art practises are simply utilised without burdening the user with the details.</li><li>Machine Learning as a service offerings from various public cloud providers such as automl and rekognition allowing training of image classification models on custom data in a few simple steps.</li></ul><p>Both approaches will typically not lead to the absolutely best solution. However, most of the time this is not necessary and ‘good enough’ will be just fine and a nice trade-off between time & money spent vs. result. For our first version of the dish-o-tron, we will employ the <a href="https://cloud.google.com/automl" target="_blank">AutoML Service</a>  from Google Cloud to train a first model.</p><p>We can use various tools to inspect the model and try to explain if the black box learns what we expect.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VpD61VqpQnyJhXGaIBAF"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/VpD61VqpQnyJhXGaIBAF" alt="visualizing what the dish-o-tron model has actually learned" width="250" height="191" /></a> <p>Visualizing what the model has actually learned.</p></div><p>The training of the AI model with AutoML and its technical details will be discussed in a follow-up blog post.</p><h2>Deployment of the model</h2><p>Having an AI model generally will not solve an actual real-life problem. For a viable solution, the AI model has to be integrated into a suitable context. Many times, this is the key step to generating any value at all. Nevertheless, this step is often postponed to the distant future after “collecting high quality data” and “building the best AI model”. This is, more often than not, a mistake because integrating the model into its context poses various challenges on its own. Hence, it should not be ignored and instead tackled early in order to learn and identify the associated challenges.</p><p>While building the dish-o-tron, we tried multiple options to run the model. We deployed it on a Pi Zero which is a really small and cheap device that can be glued anywhere with a small powerbank. But it is rather slow. We ran the model in the browser using our notebook’s webcam with TensorFlow.js. We used the Google AIY Kit, which is much faster than the Pi Zero and also comes with a beeper and blinking lights (but it is quite old and deploying state-of-the-art models is hacky). Finally, we used the Google Coral device, which is made for this kind of workload and well-integrated into Google AutoML but comes with a price tag.</p><p>The community kitchen is a special place. It’s a place where rumors are born, where gossip is produced and where you can openly chat about the most secret secrets of your company! That’s why dish-o-tron is living on the edge. Edge devices enable you to run audio and video analytics AND respect the privacy of your community kitchen. No image is transferred to the cloud. Nothing is saved. Dish-o-tron sees and forgets.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ifYte6hjS9qkGzscSWIv"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ifYte6hjS9qkGzscSWIv" alt="various edge devices" width="250" height="85" /></a> <p>Various edge devices</p></div><p>Moreover, the hardware we consider and buy in order to actually build the dish-o-tron will establish basic conditions for our solution space. In other words, we have to mind that it is possible to painlessly deploy the AI model on our preferred edge device. For the first version of the dish-o-tron, we decided to use a Google AIY kit (see video below). For the next version, we chose a Google Coral edge device, which allows us to run advanced computer vision tasks on a Raspberry-size mini computer. Fortunately, AutoML allows us to export models in a viable format.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/prd2PYdSwOt0zBb9m6Ph"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/prd2PYdSwOt0zBb9m6Ph" alt="Google coral device" width="250" height="131" /></a> <p>Google coral device</p></div><p>The construction of the dish-o-tron including the deployment of the model on the Coral device and its technical details will be discussed in an upcoming blog post.</p><h2>Conclusion</h2><p>AI research has brought us new technology that can solve problems that couldn’t be solved before. Have you read the book <em>AI superpowers</em> by Kai-Fu Lee? He says that you don’t need to be one of the best AI researchers any more to apply AI and find new business opportunities. You need to collect (lots of) data and can “just” use existing algorithms, services and open source frameworks. Well, in our opinion building AI solutions is not easy – but it is indeed getting easier and easier every day.</p><p>See the first prototype running on the google AIY kit here (mind the green/red LED at the box):</p><p></p><p>Follow this blog series if you want to know how to build and run such a model on an edge device yourself. Building the dish-o-tron will fundamentally change the way you experience the community kitchen. Instead of being a place of constant anger and hostility, the community kitchen will become a peaceful meeting ground for sharing ideas and connecting with co-workers.</p><p>In the upcoming blog posts, we will guide you through the process of building your own dish-o-tron for your community kitchen sink. Hence, we will tackle a real-world problem and playfully learn how to build and improve an AI system from scratch. Stay tuned!</p><p>Continue with the <a href="/en/knowledge-hub/blog/dish-o-tron-gather-that-data-you-must">the second part of our series</a>  where we start with gathering data.</p>

DISH-O-TRON – No more dirty dishes thanks to AI

# 5 Reasons We’re Excited About MotherDuck’s Launch in AWS Frankfurt

For some time, a key challenge for European data teams has been balancing innovation with strict regulation. We’ve often seen powerful tools launch first in the US, while our need for GDPR compliance and data sovereignty requires a local presence.

This is why the official launch of [MotherDuck](https://motherduck.com/) in the AWS Frankfurt region on 24 September (eu-central-1) is a noteworthy development for the data community here [^1]. As an official launch partner, we evaluated the platform ahead of its European debut. Our perspective is clear: this is far more than just a new cloud location. It represents a new, more efficient philosophy for small- to medium-sized data analytics. 

Before we dig into the five key reasons for our positive assessment, let’s first address the fundamental question:

## What the Duck Is MotherDuck?

To fully appreciate [MotherDuck's](https://motherduck.com/) value proposition, one must first understand its foundation: [DuckDB](https://duckdb.org/).

In essence, DuckDB is to analytics what SQLite is to transactional databases – a powerful, serverless, and embedded data engine. It operates “in-process,” which eliminates the need for any complex client–server architecture. There is no server to install, no instance to configure. This simplicity, combined with its consistently high rankings in performance benchmarks like [ClickBench](https://benchmark.clickhouse.com/)[^2], has led to widespread adoption (over 30k GitHub stars) and a massive developer following.

While DuckDB excels on a local machine, enterprise environments require additional capabilities for collaboration, security, and scale. This is precisely where MotherDuck comes in. It extends DuckDB with a suite of production-ready, cloud-based features, including:
- Centralized authorization and user management
- Durable, persistent cloud storage
- Intelligent caching and query scaling

As MotherDuck’s founder, Jordan Tigani, often puts it: “While DuckDB turns your laptop into a personal analytics engine, MotherDuck scales your laptop into the cloud with dual execution.” In short, MotherDuck provides the collaborative and enterprise-grade layer that allows teams to harness the full power of DuckDB in a secure and scalable way. More on dual execution below.

The architectural approach of combining a powerful local engine with a lean, collaborative cloud layer is what makes the platform particularly compelling. Based on our evaluation, here are five key reasons why we are excited about this development:

## Your Data Most Likely Isn’t as Big as You Think

The data industry has been obsessed with “Big Data” for over a decade. But as MotherDuck’s founders argue, [Big Data Is Dead](https://motherduck.com/blog/big-data-is-dead/). The reality is often simpler: companies don’t operate at the petabyte scale of Google or Meta. Many analytics workloads run on datasets that are gigabytes or a few terabytes in size. This scale doesn’t always require massive, complex distributed systems.

Today’s laptops and single servers are incredibly powerful—or, as DuckDB creator Hannes Mühleisen puts it, we lived through a “[lost decade of small data](https://duckdb.org/2025/05/19/the-lost-decade-of-small-data.html).” MotherDuck and DuckDB are engineered for this small- to medium-sized data reality. They provide the power of a distributed system without the overhead, cost, and complexity, allowing you to process data efficiently where it makes the most sense.

## A Focus on Simplicity and Performance

One of the biggest barriers in data analytics is often the initial setup. Traditional systems require installing servers, configuring instances, and managing permissions before a single query can be run. DuckDB’s core mission is to eliminate this friction entirely.

There are no servers to manage. You simply install the library and start querying. This radical simplicity, combined with its high-performance query engine, changes the time-to-insight. An analyst can go from a 10 GB Parquet file to meaningful results in seconds, not hours (depending on hardware and data layout). MotherDuck extends this philosophy to team collaboration, providing the necessary infrastructure for production-ready data applications without reintroducing the complexity that DuckDB was designed to remove.

## Simplified and Secure Data Sharing

A common challenge in collaborative analytics is the manual exchange of data files, such as CSV exports. A practice that still kicks off many data science and AI projects. This approach creates data silos, raises security concerns, and leads to version-control issues with inconsistent datasets spread among different team members.

MotherDuck directly addresses this by changing the paradigm from sharing data to sharing access to data. Instead of creating data copies, teams can work from a single, consistent source of truth.

The sharing model, accessible via a web interface and controllable programmatically with standard SQL commands (e.g., GRANT/REVOKE semantics), eliminates the need for “nasty CSV exports” and provides a clean way to collaborate.

## Rich Partner Ecosystem

A data platform’s value is directly tied to its ability to integrate with the tools an organization already uses. MotherDuck embraces a “bring your own tools” philosophy, standing in contrast to more monolithic platforms.

The platform is supported by a rich and growing [ecosystem of partners](https://motherduck.com/ecosystem/), including numerous open-source projects and commercial SaaS solutions. This commitment to interoperability allows organizations to pick and choose a best-of-breed data stack tailored to their specific needs, rather than being forced into a one-size-fits-all solution.

## Dual Execution: Local Speed and Cloud Scale

Perhaps the most technically innovative feature of the platform is its approach to dual execution. MotherDuck’s intelligent query planner can distribute a single query plan between a local DuckDB instance and the MotherDuck cloud service.

This model leverages the best of both environments: the interactive speed and low latency of local processing with the scalability and durable storage of the cloud. By executing parts of a query on the user’s machine, this architecture minimizes data transfer by design, which in turn reduces both latency and cloud compute costs.

This powerful dual execution model even extends to modern web applications, where DuckDB can run directly in the browser (via WebAssembly) while being powered by MotherDuck’s backend for larger, shared datasets.

# Conclusion

SQLite revolutionized the world of transactional databases. By providing a powerful, serverless, file-based database, it became an integral part of nearly every application and device on the planet – for examples, see [here](https://www.sqlite.org/famous.html).

We believe DuckDB is poised to do for analytics what SQLite did for transactions. It brings the same principles of simplicity and high performance to a domain that has long been burdened by complexity. MotherDuck is the catalyst that scales this potential, transforming DuckDB from a personal powerhouse into a viable, collaborative platform for modern data teams.

The official launch in Frankfurt is an exciting milestone for data analytics in Europe. We are proud to be a launch partner on this journey and look forward to seeing the innovative solutions our clients will build with this technology.

What’s Next? If you are exploring ways to modernize your data stack or want to see how this new approach could benefit your team, we are here to help. Contact us for a no-obligation consultation to discuss your specific use case.

[^1]: As with any cloud service, customers should verify whether any control‑plane metadata (e.g., service logs, metrics, authentication/usage telemetry) leaves the region. Separately, each organization must assess the data‑protection compliance of hosting personal data with MotherDuck in AWS Frankfurt (eu-central-1).
[^2]: Please take performance benchmarks with the usual grain of salt, as the complexities are thoroughly explained [here](https://hannes.muehleisen.org/publications/DBTEST2018-performance-testing.pdf) by DuckDB co-creator Hannes Mühleisen: On Performance-Testing in Database Systems.

5 Reasons Why We’re Excited About MotherDuck Launch in AWS Frankfurt

Service Lead Data & ML & AI

Du hast Fragen oder möchtest dich zu deinen Herausforderungen austauschen? Gern – trag einfach deine Kontaktdaten ein.

Kontaktanfrage | Sales (allgemein)

Kontakt

Kontakt aufnehmen

Die Zeit der oberflächlichen KI-Pflaster ist vorbei. Lass uns auf der TDWI gemeinsam darüber sprechen, wie wir deine Strukturbrüche heilen und dich auf dem Weg zur echten KI-Company begleiten. Wir freuen uns auf den persönlichen Austausch.

Warum wir Software neu denken müssen

KI-Pflaster lösen keine Probleme im Fundament. Mit codecentric zum KI-Gewinner werden. Erfahre mehr auf der TDWI 2026 – wir freuen uns auf dich!

Fundament stärken: Vom KI-Pflaster zum echten KI-Gewinner

Unsere Talks auf der TDWI

Dienstag, 23.6.2026

Mittwoch, 24.6.2026

Zur TDWI

Du willst, dass dein Unternehmen nicht nur Symptome kaschiert, sondern ein echtes, datengetriebenes Fundament aufbaut? Dann triff uns auf der TDWI! Wir zeigen dir, wie du den anspruchsvollen Weg gehst, um durch KI echte Wettbewerbsvorteile zu erzielen, anstatt nur auf schnelle „Quick Wins“ für die Galerie zu setzen.

TDWI 2026: Pflaster fixen keine Brüche im Fundament

Pflaster fixen keine Strukturbrüche. codecentric@TDWI 2026

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

Digitale Souveränität

IT-Security

Künstliche Intelligenz

Software-Modernisierung

Leistungen von A bis Z ...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

Karriere

Über uns

Aktuelles

<h4>Datenhaltung mit DuckDB</h4><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/resize=width:100,height:100/UdBLlw5wQsOsoK9HdBw5" alt="Matthias_Solingen_g.png" title="Matthias_Solingen_g.png" width="100" height="100" /><p>Erfahre von Matthias Niehoff praxisnah am Beispiel von DuckDB, wie du den Spagat zwischen standardisiertem Reporting und explorativer Analyse meisterst.</p><p><strong>Wann?</strong> 11.35 Uhr - 12:20 Uhr<br><strong>⁠Wo?</strong> TDWI Tool Track</p>

<h4>Souveräne KI-Infrastruktur auf Kubernetes</h4><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/resize=width:100,height:100/HnL2W0LuT529X1YLmIQ0" alt="Bastian" title="Bastian_Nürnberg_g.png" width="100" height="100" /><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/resize=width:100,height:100/bgk7DwMWSSy5fRzE1yOH" alt="Michael Wagner" title="Michael_Nürnberg_3_g.png" width="100" height="100" /><p>Erfahre von Bastian Scherber und Michael Wagner, wie du den Schritt vom simplen LLM-Download zum stabilen 24/7-Betrieb auf dem eigenen Kubernetes-Cluster meisterst – für echte digitale Souveränität und volle Datenkontrolle.</p><p><strong>Wann?</strong> 9 Uhr - 10 Uhr<br><strong>Wo?</strong> Data Science &amp; AI Track</p><p></p><p></p><h4>Aufbau eines Datensees durch die Raiffeisen Information Service</h4><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/resize=width:100,height:100/TLkN0By9SoSlWNtRbOuN" alt="Stephan" title="Stephan_Solingen_1_g.png" width="100" height="100" /><p>Erfahre von Thomas Forer und Dr. Stephan Kepser am Praxisbeispiel der Südtiroler Raiffeisenkassen, wie der Aufbau eines zentralen Datalakes die Basis für echte KI-Use-Cases schafft – für ein skalierbares Datenfundament statt redundanter Insellösungen.</p><p><strong>Wann?</strong> 10.30 Uhr - 11.15 Uhr<br><strong>Wo?</strong> Branchentrack Finanzindustrie</p>

<h4>Data Quality &amp; Reliable Analytics: A Use Case for dbt Tests</h4><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/resize=width:100,height:100/aJX5gx3SMmWHNwO1Llnv" alt="Francesca" title="Francesca_Berlin_g.png" width="100" height="100" /><p>Erfahre von Dr. Francesca Diana am Beispiel von dbt Core, wie du fehlerhafte Daten frühzeitig abfängst und robuste Pipelines aufbaust – für eine Datenqualität, der du wirklich vertrauen kannst.</p><p><strong>Wann?</strong> 18 Uhr - 18.45 Uhr<br><strong>Wo? </strong>Data Architekcture Track</p>

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Pflaster fixen keine Strukturbrüche. codecentric@TDWI 2026

TDWI 2026: Pflaster fixen keine Brüche im Fundament

Fundament stärken: Vom KI-Pflaster zum echten KI-Gewinner

Unsere Talks auf der TDWI

Warum wir Software neu denken müssen

Jetzt für unseren Newsletter anmelden