„Wir müssen über Ihre Daten sprechen“: Datenqualität im Zeitalter von KI

IN Machine Learning — 21 June, 2017

Kürzlich nahm ich an einer Industrietagung über Industriemaschinen und Maschinenbau teil. Diese Branche hinkt dem Handel ungefähr fünf Jahre hinterher, wenn es darum geht, zu verstehen, welchen Unterschied die Integration von künstlicher Intelligenz (KI) und Machine Learning in ihre Prozesse machen kann.

data_quality-4.png

Ein Professor, der eine Session über Informationsmanagement im Maschinenbau leitete, hielt einen Keynote-Vortrag. Darin konzentrierte er sich auf Machine Learning und KI in der Industrie 4.0. Einer der industriellen Anwendungsfälle, die der Professor präsentierte, erregte meine Aufmerksamkeit. Er beschrieb dabei folgende Situation: „Die Daten wurden von Experten in die Datenbank übertragen. Deshalb waren wir sicher, dass die Daten korrekt sind, schließlich kamen sie ja von Spezialisten. Dennoch waren die Produkte, die auf Basis dieser Daten gefertigt wurden, fehlerhaft.“ Das ist kein wörtliches Zitat, aber der Gedanke, dass Daten schon deshalb korrekt sein müssen, weil sie von Experten eingepflegt werden, zog sich wie ein Leitmotiv durch die gesamte Präsentation des Projekts. Diese Vorstellung faszinierte mich, denn in all den Jahren, in denen ich es mit Daten zu tun habe, ist mir noch nie ein System untergekommen, bei dem alle Daten korrekt und absolut vertrauenswürdig waren, noch nicht einmal – oder gerade dann nicht – wenn viele Experten täglich mit diesen Daten arbeiten.

Daten sind die Grundlage, auf der alle datengetriebenen Entscheidungen, Machine Learning und KI-Modelle basieren. Die Datenqualität spielt dabei eine ganz entscheidende Rolle: KI-Systeme lernen von Daten und gehen implizit davon aus, dass diese die Fälle, welche die Maschine lernen soll, angemessen repräsentieren. Während eine gewisse Anzahl von Ungenauigkeiten in den Daten unvermeidlich ist, beeinträchtigt eine zu große Fehlermenge Machine Learning negativ und es wird für die Maschine immer schwieriger, zwischen echten, aber kleinen Effekten und statistischen Schwankungen zu unterscheiden. Systematische Verschiebungen und Entwicklungen sind sogar noch gefährlicher, da der KI-Algorithmus nicht wissen kann, welcher Teil der Daten systematisch falsch ist.

Trotz bester Absichten, gibt es einfach zu viele Möglichkeiten, die Daten zu verfälschen. So können sie zum Beispiel bei der Übertragung von einem System zum anderen falsch eingegeben oder konvertiert werden. Diese Art von Fehler kann jedoch durch verbesserte Instrumente und Prozesse sowie den möglichst häufigen Einsatz automatisierter Prüfmechanismen deutlich reduziert werden. In einem Projekt haben wir viele Datenpunkte gefunden, die im Kommentarfeld mit „Test“, „Test2“, „Nicht verwenden“ oder „Veraltet“ beschrieben waren, was darauf hindeutet, dass es sich um Daten handelt, die ursprünglich zum Testen des Systems verwendet und danach nie entfernt wurden.

Andere Beispiele sind subtiler:

  • Datenfelder (z. B. Spalten in einer Datenbank) ändern mit der Zeit ihre Bedeutung, ohne dass die dazugehörige Feldbeschreibung (z. B. Änderung oder Weiterentwicklung des Schemas) angepasst wird. Das führt dazu, dass das Feld anhand irgendeines Übereinkommens für unterschiedliche Zwecke verwendet wird. Sobald dieses gemeinsame Übereinkommen vergessen wird, verlieren bedauerlicherweise die Daten ihre Bedeutung. So etwas passiert schnell, wenn Mitarbeiter in Schlüsselpositionen ausgewechselt werden oder externe Partner beteiligt sind.
  • Die Daten, die in einer Datenbank gespeichert werden, bilden nicht die „wirkliche Welt“ ab, die sie beschreiben sollen. In einem Projekt wurde ich gefragt, ob es möglich sei, für ein großes internationales Unternehmen ein finanzielles Ziel (wie das EBIT) zu prognostizieren. Von der grundsätzlichen Schwierigkeit einmal ganz abgesehen, sind in der Regel viel zu wenige Daten verfügbar (z. B. die Quartals-Finanzziele der letzten fünf Jahre, was nur 20 Datenpunkte bedeutet). Es stellte sich außerdem heraus, dass die vorhandenen Daten nicht verwendet werden konnten, um vergangene Ereignisse zu analysieren. Obwohl die korrekten Informationen mit großer Sorgfalt in die Datenbank eingegeben wurden, erlaubte deren Struktur nicht, Fusionen, Übernahmen, Umsätze oder die Verschiebung von Prioritäten, Produktionslinien oder Verantwortlichkeiten zwischen den Unternehmensbereichen und Tochtergesellschaften nachzuverfolgen. Auch wenn alle Daten korrekt eingegeben worden wären, hätten sie nur für den Augenblick Gültigkeit und Veränderungen der Organisationsstruktur würden sich nicht in den gespeicherten Daten widerspiegeln.
  • Die Daten und/oder die Speichersysteme werden von verschiedenen Gruppen für unterschiedliche Zwecke verwendet, ohne dass sie sich dessen bewusst sind. In einer großen Organisation mit zentraler Datenspeicherung kann das durchaus vorkommen. So hatte ich ein Projekt mit einem großen internationalen Handelskonzern, bei dem die gesamten Daten in einer zentralen Datenbank gespeichert wurden. Bei unserem Projekt ging es um den Warenabverkauf und alles in den Daten – von der Bezeichnung der Variablen bis hin zur Beschreibung und sogar zum Datenbankschema – rechtfertigte die Annahme, dass die Datenbank ausschließlich den Verkaufsdaten der individuellen Produkte in den verschiedenen Filialen des Händlers vorbehalten sei. Doch weit gefehlt: Es stellte sich heraus, dass die operativen Geschäftsbereiche das System gleichzeitig zur Bestellung aller nötigen Materialien für die Filialen nutzten, die nicht für den Kunden bestimmt waren, wie Reinigungsmittel, Tüten etc. Da die Datenbank nicht zwischen „interner“ und „externer“ Verwendung differenzierte, gab es keine Möglichkeit, diese Produkte von den Kundenprodukten zu unterscheiden – es sei denn man kannte die Konvention, nach der die Produkte ausgezeichnet waren.
  • Daten sind nur für einen bestimmten Zeitraum gültig. Ein eindeutiges Beispiel dafür ist die Lebensdauer eines Produkts: Ein neues Produkt wird eingeführt und verkauft oder im weiteren Fertigungsprozess verwendet. Irgendwann wird es eingestellt und kann nicht mehr bestellt werden. In diesem Fall kann ein Gültigkeitszeitraum definiert werden, der festlegt, wann das Produkt „aktiv“ ist. Noch Jahre nach der Einstellung des Produkts können Verkaufsdaten oder Nutzungsverhalten mit der Beschreibung der eigentlichen Artikel abgeglichen werden. Häufig ist die Änderung jedoch subtiler: Oft liefern die Hersteller von Originalteilen (OEMs) Produkte oder Komponenten, die anhand von gemeinsam vereinbarten Spezifikationen hergestellt werden. Die OEMs können allerdings ihre Produkte innerhalb dieser Vorgaben ändern. Obwohl die Beschreibung, die Identifikationsnummer und alle anderen Details des Produktes gleich bleiben, ist das Produkt selbst ein anderes. Da es dennoch die ursprünglichen Vorgaben erfüllt, wird die Änderung von den OEMs meist gar nicht kommuniziert. So kann es kommen, dass, wenn viele Teile zu einem finalen Produkt zusammengesetzt werden, das Endprodukt fehlerhaft ist, obwohl doch scheinbar nichts geändert wurde. Änderungen zu verzeichnen, seien sie auch noch so klein, gibt zumindest Aufschluss darüber, wann und wo Ungereimtheiten auftauchen können. In der Softwareentwicklung wird diese Problematik durch „Unit-Tests“ (d. h. jede Software wird einzeln getestet, um sicherzugehen, dass sie genau das tut, was sie soll) und „Integrationstests“ gelöst. Bei letzteren wird das Zusammenspiel aller Komponenten in einer Umgebung getestet, die der geplanten Verwendung möglichst genau entspricht. Es ist wichtig, beide Arten von Tests häufig, wenn nicht gar kontinuierlich durchzuführen.

All diese Beispiele und Anekdoten zeigen, dass die Datenqualität für jedes KI-Projekt von höchster Wichtigkeit ist – gleichzeitig bleibt es schwierig, sie sicherzustellen und aufrechtzuerhalten. Thomas Redman zeigt in seinem Artikel „Data Doesn’t Speak for Itself“ im Harvard Business Review ein Beispiel, wie die Datenqualität sich mit der Zeit entwickelt. Zunächst ist die Datenqualität nicht bekannt und muss anhand einer Metrik gemessen werden, die im spezifischen Kontext eines Projekts definiert wird. Sobald die Ausgangbasis geschaffen und die Zielebene festgelegt ist, konzentrieren sich erste Projekte auf die Verbesserung der Datenqualität. Sind diese Projekte abgeschlossen, sollte die Qualität aller Daten, die im System gespeichert sind, deutlich besser sein. Allerdings wird die Qualität von da an wieder abnehmen, wenn es kein kontinuierliches Monitoring und keine permanente Verbesserung der Datenqualität gibt. Neue Daten kommen hinzu und bei jedem neue Datenpunkt besteht die Gefahr, dass er auf eine neue Weise fehlerhaft ist, die bisher noch nicht erfasst wurde. Automatisierte Qualitätskontrollen können nur prüfen, was zum aktuellen Zeitpunkt bekannt ist, und müssen kontinuierlich erweitert werden. In einem weiteren Artikel fordert Redman, dass die Datenqualität jedermanns Aufgabe in einer Organisation oder einem Unternehmen sein muss – und nicht nur die Priorität eines kleinen Teams, das die Datenbank hin und wieder pflegt.

image in blog.png

Quelle: HBR

Um noch einmal die Geschichte des Professors am Anfang aufzugreifen: Die Schlussfolgerung aus dem Projekt ist, dass die Daten nur eine bestimmte Zeit hatten, in der sie als „korrekt“ gelten konnten – das ist der sogenannte Gültigkeitszeitraum, den ich oben erwähnt habe. In dem speziellen Fall kam „das Verfallsdatum“ zustande, weil Drittanbieter die benötigten Komponenten für den Fertigungsprozess mit der Zeit leicht verändert hatten. Jede Veränderung fand klar innerhalb der Spezifikationen statt – aber alle Veränderungen zusammen bedeuteten, dass das Endprodukt einfach nicht funktionierte.

Dr. Ulrich Kerzel Dr. Ulrich Kerzel

earned his PhD under Professor Dr Feindt at the US Fermi National Laboratory and at that time made a considerable contribution to core technology of NeuroBayes. After his PhD, he went to the University of Cambridge, where he was a Senior Research Fellow at Magdelene College. His research work focused on complex statistical analyses to understand the origin of matter and antimatter using data from the LHCb experiment at the Large Hadron Collider at CERN, the world’s biggest research institute for particle physics. He continued this work as a Research Fellow at CERN before he came to Blue Yonder as a Principal Data Scientist.