Bitcoinkursvorhersage mit AWS – Teil 2

Annahme für den Use Case

Für den fachlichen Use Case unterstellen wir, dass man auf Basis der Twitter-Daten der letzten Stunde – mit dem Hashtag #Bitcoin – eine Vorhersage auf den Bitcoinkurs der nächsten 24h machen kann. Aus Zeit- und Kostengründen haben wir diese Annahme nicht weitergehend validiert, d.h. wir haben keine Studien durchgeführt, die belegen, ob dies auch tatsächlich so ist bzw. welche Begriffe, Tweets, etc. in der Vergangenheit am ehesten einen Einfluss auf die Kursentwicklung hatten1 .

Zusammenhang zwischen Bitcoin Kurs und Tweets
Abbildung 1. Zusammenhang zwischen Bitcoin Kurs und Tweets – Annahme für die Vorhersage – eigene Darstellung

Wir nehmen also an, dass wiederkehrende Muster an Wörtern in den Tweets zu einer ähnlichen Kursveränderung des Bitcoins führen. Wenn beispielsweise die Begriffe Trump, Geld und bezahlen in einer bestimmten Verteilung – d.h. Anzahl, in der Vergangenheit zu steigenden Kursen geführt haben – dann nehmen wir an, dass das zukünftig bei einer ähnlichen Verteilung wieder so passieren wird.

Datenvorverarbeitung und Modelltraining

Zum Verständnis dieses Abschnitts ist es zunächst wichtig im Hinterkopf zu haben, dass wir bei der Datenvorverarbeitung und dem Modelltraining immer mit historischen Daten arbeiten.

Für die Modellbildung ist es zunächst wichtig, die jeweils wichtigsten Wörter in den gesammelten Tweets zu identifizieren. Hierzu haben wir einfache Datenvorverarbeitungsmethoden aus dem NLP (Natural Language Processing) Bereich genutzt, wie z.B. Part-of-speech tagging (POS), Entfernung von Stoppwörtern oder Tokenization. Im Wesentlichen werden jeweils die drei häufigsten Substantive, Verben und Named Entities (Eigennamen wie Unternehmen, Personen oder Städte) gezählt.

Beispiel für Filterung und Zählen wichtiger Begriffe in den Tweets – eigene Darstellung
Abbildung 2. Beispiel für Filterung und Zählen wichtiger Begriffe in den Tweets – eigene Darstellung

Im nächsten Schritt müssen nun die identifizierten Wörter mit den Bitcoin-Daten bzw. der Entwicklung des Bitcoin-Kurses in Verbindung gebracht werden.

Hierzu wird zunächst zu jeder vollen Stunde die relative Kursentwicklung für den nächsten Tag berechnet. In einem zweiten Schritt werden diese Werte gruppiert, z.B. in steigende Kurse (alles >+1% Kursentwicklung), fallende Kurse (alles <-1% Kursentwicklung) und gleichbleibende Kurse (alles zwischen >=-1% und <=+1% Kursentwicklung)2 . Dieses Vorgehen soll in Abbildung 3 etwas besser veranschaulicht werden.

Vereinfachtes Beispiel für die Gruppierung von Kursentwicklungen – eigene Darstellung
Abbildung 3. Vereinfachtes Beispiel für die Gruppierung von Kursentwicklungen – eigene Darstellung

Dann werden diese Kategorien (steigende Kurse, sinkende Kurse, etc.) mit den gezählten Wörtern assoziiert. Abbildung 4 zeigt dies etwas anschaulicher. Am 12.02., um 12:00 Uhr wurde innerhalb von 24h ein fallender Kurs gemessen. Gleichzeitig kamen die Begriffe Trump, Geld und bezahlen am 12.02. in dem Zeitraum von 11-12 Uhr besonders häufig vor. Entsprechend unserer Annahme (siehe hierzu auch im Abschnitt Annahme für den Use Case) gehen wir nun davon aus, dass bei einer ähnlichen Verteilung dieser Begriffe zukünftig auch eine ähnliche (stark fallende) Kursentwicklung zu erwarten ist.

Gezählte Wörter und Kategorien – eigene Darstellung
Abbildung 4. Gezählte Wörter und Kategorien – eigene Darstellung

In diesem Verfahren bilden wir nun viele gleichmäßige Zeitscheiben, jeweils im Stundentakt. Jede dieser Zeitscheiben besteht nun aus 9 Features (3 Substantive, 3 Verben, 3 Named Entities) und einem Label (der Kategorie welche die Kursentwicklung beschreibt).

Dieses Datenkonstrukt wird nun mit einer Supervised Learning Methode (Multinomiale Logistische Regression) trainiert.

 

Vorhersage und Fazit

Auf Basis des trainierten Modells (siehe vorheriger Abschnitt) sind wir nun in der Lage einmal pro Stunde eine Vorhersage, jeweils für den nächsten Tag zu berechnen. Die Vorhersage gibt immer jeweils eine Range an, z.B. der Kursveränderung wird zwischen +3% und +5% liegen. Abbildung 5 zeigt einen Auszug aus der Datenvisualisierung, die mit Tableau umgesetzt wurde (basierend auf echten Daten/Prognosen).

Visualisierung der Ergebnisse – eigene Darstellung
Abbildung 5. Visualisierung der Ergebnisse – eigene Darstellung

Wie man recht schnell erkennen kann, sind wir unserem Ziel, steinreich zu werden, leider nicht sehr viel nähergekommen. Die berechnete Prognose ist nur selten in der Lage, die Kursentwicklung richtig vorherzusagen.

Dafür war das Projekt in Bezug auf die technische Implementierung ein voller Erfolg. Es ist uns gelungen, die komplette fachliche Logik des Projekts auf AWS zu migrieren. Darüber hinaus konnten wir auch relativ große Datenmengen effizient verarbeiten. So werden beispielsweise beim täglichen Training des Modells mehr als 2.500.000 Tweets auf einer relativ bescheidenen EC2-Instanz verarbeitet.

 

Lessons Learned und Ausblick

Für die Implementierung des Projekts mussten zahlreiche AWS-Komponenten aufgesetzt werden, die miteinander interagieren und die in Summe eine gewisse Komplexität mit sich bringen. Trotzdem war unsere Erfahrung, dass die Umsetzung im Vergleich zu der selbstgebauten On-Premise Lösung deutlich schneller, effizienter und in Summe auch einfacher umzusetzen war.

Wesentliche Lessons Learned, die wir aus diesem und auch aus anderen Cloud-Projekten mitgenommen haben:

  • Implementation to Costs
    In der Softwareentwicklung kümmert man sich üblicherweise um die Effizienz seines Programms, um eine möglichst geringe Zeit- und Speicherkomplexität zu erhalten. Auch auf Cloud-Computing Plattformen bleibt dies relevant, allerdings kommt aufgrund der Kostenpflicht zusätzlich noch die Optimierung im Hinblick auf Kosten. Bei der Nutzung der Services können häufig zahlreiche Kosten für Features anfallen, die eventuell gar nicht verwendet werden. Des Weiteren kann die Verwendung der einzelnen Services so optimiert werden, dass diese so wenig wie möglich aufgerufen werden, da auch hier der Kostenfaktor hoch sein kann.
  • Geringere Komplexität und effizientere Teams
    In Summe war – im Vergleich zur On-Premise Lösung – der Gesamtpersonalaufwand für das Projekt erheblich niedriger. Bei der Implementierung der ersten Leistungsstufe waren in Spitzenzeiten bis zu sechs Experten mit ganz unterschiedlichen Skills notwendig (z.B. Spark-, Hive-, Docker-Experten usw.). Die Cloud-Lösung hingegen konnte im Wesentlichen von nur einer einzelnen Person umgesetzt werden. Wir sehen den Hauptgrund hierfür in einer geringeren Gesamtkomplexität: das Management zahlreicher kleiner Teilprobleme kann quasi an die Cloud ausgelagert werden. Damit hat sich auch der Kommunikations- und Abstimmungsaufwand innerhalb des Teams erheblich reduziert.
  • Stabiler Betrieb bei guter Erweiterbarkeit und Skalierbarkeit
    Seitdem die fachliche Logik auf AWS migriert wurde, hatten wir keinen einzigen Ausfall einer AWS Komponente zu verzeichnen. Das System läuft seit der Aufsetzung auf AWS, ohne dass wir uns größere Gedanken über Stabilitäts- oder Backupthemen machen mussten. Gleichzeitig ist das implementierte System deutlich leichter skalier- und erweiterbar. Möchte man beispielsweise eine weitere Datenquelle anbinden, so müsste man hierzu lediglich eine neue Elastic Beanstalk-Instanz erstellen, die die Daten von der gewünschten API abruft.
  • Ein gutes Explorationskonzept lohnt sich
    Ein wesentlicher Grund dafür, dass die Implementierung schnell verlief, war die Entwicklung eines detaillierten Explorationskonzepts, in dem die wichtigsten Anforderungen an das System exploriert wurden. Durch das Explorationskonzept wurden bereits von Anfang an für das Projekt geeigneten Services identifiziert, sodass nicht erst während der Implementierung auffällt, dass eine Technologie für das Projekt eher ungeeignet ist. Ebenso wurden die einzelnen Datenverarbeitungsschritte definiert, wodurch die Umsetzung dieser Verarbeitungen in einem Skript wesentlich einfacher wurde.

Trotz der Fertigstellung des Projekts gibt es noch zahlreiche weitere Aspekte, mit denen das Projekt weitergeführt werden kann:

  • Anbindung weiterer Datenquellen
    Es ist durchaus denkbar, weitere Datenquellen anzubinden. So könnte man z.B. unterschiedliche Nachrichtendienste anbinden und den Inhalt der Artikel detailliert analysieren.
  • Ausbau der Algorithmen
    Der implementierte Algorithmus stellt ein sehr einfaches Verfahren dar, da im Wesentlichen nur die häufigsten Begriffe betrachtet werden. Hier gibt es noch sehr viel besser geeignete, komplexere Ansätze. So könnte man die Beziehungsnetzwerke der Twitter-Nutzer mitberücksichtigen und z.B. die Anzahl der Follower oder die Anzahl der Retweets analysieren. Man könnte auch Sentimentanalysen durchführen und deutlich ausgereiftere NLP Methoden (z.B. Long-Short-Term-Memory Networks) oder Frameworks wie BERT einsetzen.
  • Evaluierung weiterer Services
    Das Hauptziel des Projekt war vor allem das Gewinnen von Know-how in AWS. Daher wäre die Evaluation von weiteren Services ebenfalls ein weiterer Punkt, an dem am Projekt weitergearbeitet könnte. Geeignet wären zum Beispiel der Natural Language Processing Service Amazon Comprehend oder der Service zur Visualisierung von Daten, Amazon QuickSight.
  • Weitere Automatisierung
    Nicht nur das Training und die Vorhersage können automatisiert werden, sondern auch die Erstellung der gesamten Projektinfrastruktur auf AWS. Dafür eignet sich die Infrastructure-as-Code Software Terraform, die das automatische Erstellen der benötigten Ressourcen ermöglicht. Auch hier könnte es interessant sein, weitere Teile des Projekts zu automatisieren.

Zusammenfassend birgt das Projekt ein sehr weites Feld an Möglichkeiten, das System weiterzuentwickeln. Vom Ausbau der Algorithmen, über die Anzahl der Datenquellen, bis hin zu weiterer Automatisierung besteht umfangreiches Potential zum Ausbau und der Verbesserung des Systems.

Co-Autor: Danny Claus

Zu Teil 1 der Bitcoinkursvorhersage mit AWS

 

Advanced Analytics Projekte mit Machine Learning erfolgreich umsetzen

 


1 In einem echten Kundenprojekt hätte man hier vorab eine entsprechende Validierung vornehmen müssen. Da für uns aber die technischen Aspekte im Vordergrund standen, haben wir davon im Rahmen dieses internen Projekts abgesehen.

2 Dies ist lediglich ein vereinfachtes Beispiel. In unserem echten Modell verwenden wir in Summe 11 Kategorien.

Unser Kracher-Beitrag im April: Extraktion strukturierter Daten aus Tankbelegen

Top Beitrag des Monats

Trotz 12 Millionen Geschäftsreisen in 2018 setzen nur 13% der befragten Unternehmen eine vollständige digitale Reisekostenabrechnung ein. Auch bei uns ist die Reisekostenabrechnung noch nicht komplett digitalisiert. Wir haben Verfahren zur Informationsextraktion untersucht, um dies zu ändern.

Hier geht’s zum Beitrag

 

Bitcoinkursvorhersage mit AWS – Teil 1

Social mediA Price PREdiction – SAPPhiRE
Abbildung 1. Social mediA Price PREdiction – SAPPhiRE – eigene Darstellung

Ein zweites Ziel im Rahmen dieses Projekts war die Entwicklung eines technischen Prototyps, der die komplexen Aspekte eines typischen Big Data Projekts (Datenintegration, Datenanalyse und Datenvisualisierung) umsetzt. Hierzu wurde in einer ersten Leistungsstufe eine entsprechende Umgebung komplett selbst aufgebaut und On-Premise betrieben.

Architektur der ersten Leistungsstufe
Abbildung 2. Architektur der ersten Leistungsstufe – eigene Darstellung

Beim Aufbau und Betrieb dieser Plattform mussten wir eine Vielzahl an Herausforderungen meistern, angefangen vom Monitoring der Anwendung, über Backupstrategien bis hin zur Sicherstellung einer Skalierbarkeit. Hierzu wurde eine Vielzahl an Technologien eingesetzt: Spark, Hive, PostgreSQL, Docker, HDFS, REST, Java und Tableau – um nur ein paar zu nennen. Und wie man sich denken kann, ist das Zusammenspiel dieser verschiedenen Technologien durchaus komplex und auch aufwendig, unter anderem weil man eine Vielzahl von Experten benötigt, die sich regelmäßig miteinander abstimmen und synchronisieren.

Für uns war das der Anlass, unseren fachlichen Use Case mit einem neuen Technologiestack und auf Basis von Cloud Computing Technologien zu erproben.

Die Ergebnisse dieses Projekts wollen wir im Rahmen einer zweiteiligen Blogserie kurz vorstellen. Im Rahmen dieses ersten Beitrags stellen wir die technische Umsetzung vor. In einem zweiten Teil beschreiben wir die implementierte Business Logik und gehen auf die wesentlichen Lessons Learned ein, die wir im Rahmen des Projekts für uns mitgenommen haben.

Technische Umsetzung

Für die technische Umsetzung wurde ein Platform-as-a-Service (PaaS) Ansatz auf Basis von AWS Technologien genutzt, d.h. sämtliche Hardware wurde von der Cloud zur Verfügung gestellt. Lediglich die Software, d.h. die fachliche Logik, musste selbst implementiert werden.

Die Architektur lässt sich dabei in folgende Abschnitte aufteilen:

 

Datensammlung

Auf Abbildung 3 ist dargestellt, wie die Komponenten für die Datensammlung miteinander arbeiten. Für die Sammlung der Twitter- und Bitcoin Daten wurde die Twitter API bzw. Coindesk API verwendet. Die Twitter API stellt Tweets mithilfe von Streaming in Echtzeit bereit, während die Coindesk API eine REST API darstellt und somit durch das Stellen von HTTP Requests den aktuellen Kurswert zurückgibt. Beide APIs werden jeweils durch ein Python-Skript angesprochen, welche dauerhaft im Hintergrund laufen und die dabei abgerufenen Daten speichern. Für die Ausführung dieser Skripte auf AWS wurde Elastic Beanstalk verwendet – ein Service, der sich automatisch um die Bereitstellung von Code auf EC2-Instanzen kümmert.

Architektur für die Datensammlung
Abbildung 3. Architektur für die Datensammlung – eigene Darstellung

Um die Twitter- und Bitcoin-Daten von Elastic Beanstalk auf einem AWS Storage Service zu übertragen, wird der Service Kinesis Firehose verwendet, welcher Daten entgegennimmt und diese im gewählten Storage Service abspeichert. Kinesis Firehose ermöglicht es zudem, eingehende Daten zu komprimieren oder zu verarbeiten, bevor diese gespeichert werden.

Als zentraler Storage Service für alle im Projekt verwendeten Daten wird S3 benutzt, womit Objekte gespeichert und abgerufen werden können.

Datenverarbeitung, Modelltraining und -vorhersage

Wie zuvor bei der Datensammlung stellt Abbildung 4 sämtliche Komponenten dar, die für die Datenverarbeitung, das Modelltraining und die -vorhersage verantwortlich sind. Da das Training täglich und die Vorhersage stündlich laufen sollen, müssen die dazugehörigen Services in AWS selbst angesteuert werden. Für diesen Zweck wird CloudWatch benutzt – ein Service, der hauptsächlich für das Logging der AWS Services zuständig ist, aber zusätzlich weitere Funktionen anbietet, wie z.B. das Auslösen von Services in einem festlegbaren Intervall.

Architektur für das Modelltraining und die Vorhersage
Abbildung 4. Architektur für das Modelltraining und die Vorhersage – eigene Darstellung

Durch CloudWatch soll ein Training / eine Vorhersage gestartet werden. Allerdings kann der dafür verantwortliche Service (SageMaker => siehe hierzu auch den nächsten Absatz) nicht direkt durch einen CloudWatch Auslöser angesteuert werden. Daher wird der Service Lambda verwendet, welcher das Ausführen von Skripten auf der Cloud ermöglicht. Die Ausführung einer Lambda Funktionen kann durch Events ausgelöst werden, wie z.B. die vorher genannte CloudWatch Auslöser, wodurch ein regelmäßiges Training / Vorhersage gewährleistet werden kann. In der Lambda Funktion wird die AWS SDK Boto3 verwendet, um SageMaker aufrufen zu können.

Bei SageMaker handelt es sich um einen Machine Learning Service, auf dem jegliche Operationen zum Erstellen, Trainieren und Bereitstellen von Machine Learning Modellen möglich sind. Auf SageMaker werden sowohl das Training als auch die Vorhersage ausgeführt. Um auf die Daten in S3 zugreifen zu können, wird der Service Athena verwendet, mit welchem SQL-ähnliche Abfragen in S3 ausgeführt werden können. Das aus dem Training entstehende Modell wird sodann auf S3 gespeichert.

Gesamte Architektur
Abbildung 5. Gesamte Architektur – eigene Darstellung

Mit dem Zusammenfügen der Architekturen für die Datensammlung bzw. Modelltraining und Vorhersage ergibt sich nun die Gesamtarchitektur wie in Abbildung 5 dargestellt.

Jetzt haben wir euch die technische Implementierung im Wesentlichen vorgestellt, im zweiten Teil unserer Sapphire-Reihe geht es dann ums Eingemachte: Wie sieht die implementierte Business Logik genau aus und welche Lessons Learned ziehen wir aus dem Projekt?

Co-Autor: Danny Claus

Zu Teil 2 der Bitcoinkursvorhersage mit AWS

 

Advanced Analytics Projekte mit Machine Learning erfolgreich umsetzen

 

 

Cloud Bursting – Wie man mit Kubernetes die Hybrid Cloud zum Platzen bringt

In den vergangenen sechs Monaten haben wir uns im Rahmen einer Masterarbeit mit dem Thema Hybrid Cloud auseinandergesetzt. Ziel war es, eine Hybrid Cloud mit Kubernetes und Cloud Bursting für eine Beispielanwendung umzusetzen.
Doch was genau bedeutet denn nun Cloud Bursting? Der Begriff stammt aus dem Englischen „to burst“ – zu Deutsch „platzen“. Es geht darum, Anwendungen im privaten Teil einer Hybrid Cloud bei steigender Last durch Public-Cloud-Ressourcen zu erweitern. Die Private Cloud platzt also auf und wird – wenn man so will – von der Public Cloud aufgefangen.

Die Hybrid Cloud ist eine Lösung, die eine Private Cloud mit einem oder mehreren Public Cloud Services kombiniert und mittels proprietärer Software eine Kommunikation zwischen unterschiedlichen Services ermöglicht. Hybrid Cloud Services sind leistungsfähig, weil sie Unternehmen eine bessere Kontrolle ihrer privaten Daten ermöglichen. Eine Organisation kann vertrauliche Daten in einer Private Cloud oder in einem lokalen Rechenzentrum speichern und gleichzeitig von den robusten Rechenressourcen einer verwalteten Public Cloud profitieren. https://www.citrix.com/de-de/glossary/what-is-hybrid-cloud.html

Für welche Anwendungen ist das interessant? Es ist hauptsächlich dann spannend, wenn die Last stark schwankt. Eine gewisse Grundlast wird durch die private Cloud abgedeckt und die Spitzen skalieren automatisch in die Public Cloud. So fallen dort auch nur Kosten an, wenn die Ressourcen benötigt werden.

Lastzeiten
Abbildung 1: Lastzeiten – eigene Darstellung

Use Case Machine Learning

Machine Learning (kurz ML) kann ziemlich viel Ressourcen und Zeit in Anspruch nehmen. Neuronale Netze zur Bilderkennung, welche für das ImageNet Projekt trainiert wurden, benötigen mittlerweile nur noch wenige Minuten Trainingszeit. Dafür müssen jedoch mehrere Knoten mit jeweils mehreren GPUs zur Beschleunigung eingesetzt werden1 . Gleichzeitig unterscheidet sich die Auslastung beispielsweise von der eines Web-Servers. Während dieser potenziell unendlich lange läuft, ist das Training eines neuronalen Netzes irgendwann abgeschlossen. Beim maschinellen Lernen können deshalb erhebliche Schwankungen entstehen.

In der Beispielanwendung sollen Trainingsdaten auf eine hybride Cloud-Plattform hochgeladen werden. Das Training erfolgt mit der Python-Bibliothek Keras, welche über eine einfache API verfügt und verschiedene Beispiele bereitstellt. Es können jedoch auch andere Frameworks oder Bibliotheken genutzt werden. Zu Beginn des Trainings werden die Trainingsdaten von der Plattform heruntergeladen. Daraufhin wird das eigentliche Learning ausgeführt. Zum Schluss wird das fertige Modell auf die Plattform hochgeladen. Ob das Training nun im privaten oder im öffentlichen Teil stattfindet, muss automatisch von der Hybrid Cloud entschieden werden.

Technische Hürden: Kommunikation einzelner Services

Innerhalb eines Kubernetes Clusters können einzelne Services miteinander kommunizieren. Jeder Service bekommt dazu seinen eigenen clusterinternen DNS-Eintrag. In der Regel besteht ein Cluster aus mehreren Knoten. Auf welchem ein Container ausgeführt wird, wird von Kubernetes entschieden. In einer Hybrid Cloud existieren mindestens zwei Cluster. Idealerweise verhalten sich diese wie ein großer Cluster. Daraus entstehen folgende Herausforderungen:

  1. Cross-Cluster-Kommunikation: Services können über Clustergrenzen hinweg untereinander kommunizieren, als wären sie alle im selben Cluster.
  2. Multicluster-Scheduling: Kubernetes Pods werden automatisch in einem freien Cluster platziert.

 

Technische Umsetzung durch Cross-Cluster Kommunikation und Multicluster-Scheduling

Zum Glück gibt es für beide Probleme Lösungen aus der Kubernetes-Community. Für die Cross-Cluster-Kommunikation kann das Service Mesh Istio als Mulitcluster-Installation eingesetzt werden. Dies hat den schönen Nebeneffekt, dass automatisch sämtlicher Netzwerkverkehr über mutual TLS (mTLS) verschlüsselt wird. Andere Lösungen wie Cilium oder Linkerd verfügen über ähnliche Funktionen.

Das Multicluster-Scheduling kann über den gleichnamigen Multicluster Scheduler von Admiralty erreicht werden. Dessen Einsatz ist außerdem im Blogbeitrage Running Argo Workflows Across Multiple Kubernetes Clusters auf deren Website erläutert.

 Istio Multicluster Service Mesh
Abbildung 2: Istio Multicluster Service Mesh – eigene Darstellung

Was bedeutet dies nun für unseren Use Case? Durch den Einsatz von Istio können die Trainingsdaten aus jedem Cluster der Hybrid Cloud heruntergeladen werden, ohne dass dafür extra Freischaltungen nötig sind. Über den Ausführungsort des Machine Learnings entscheidet der Multicluster Scheduler.

Damit das Bursting auch funktioniert, muss in der Public Cloud das Autoscaling für den Kubernetes Cluster aktiviert werden. So werden bei steigender Last automatisch neu Konten zum Cluster hinzugefügt.

Test der Beispielumgebung

Natürlich haben wir die Beispielanwendung einem Test unterzogen. Dabei wurden in kurzer Zeit eine große Menge an ML-Jobs erstellt und ausgewertet in welchem Cluster sie ausgeführt wurden. Die Erwartung war, dass zunächst der private Cluster genutzt wird und im Anschluss der öffentliche. Im Test hat dies größtenteils auch funktioniert, allerdings wurden einzelne Jobs schon in die Public Cloud „geburstet“, als in der Private Cloud noch ausreichend Kapazität verfügbar war. Hier offenbart sich eine aktuelle Schwäche des Schedulers. Seine Entscheidungen lassen sich nur schwer nachvollziehen oder beeinflussen. Die Möglichkeit Cluster zu gewichten könnte Abhilfe schaffen. Dann könnte dem privaten Cluster eine höhere Priorität zugewiesen werden. Da sich das Projekt aber noch in der Beta-Phase befindet, ist eine Umsetzung in Zukunft in Betracht zu ziehen.

Fazit: Wie lässt sich Cloud Bursting implementieren 

Cloud Bursting lässt sich basierend auf Kubernetes, Istio und dem Multicluster Scheduler implementieren. Es kann helfen, die Cloud bei Lastschwankungen besser zu nutzen. Der Funktionsumfang des Schedulers lässt aktuell noch ein Feature zur Priorisierung von Clustern vermissen. Es sind einige weitere Projekte zur Mulitcluster-Verwaltung in der Entstehung. Dazu zählen z. B. Kubernetes Federation, Submariner oder Google Anthos. Es bleibt also weiterhin spannend.

Simon Mennig hat diesen Blogbeitrag im Rahmen seiner Thesis „Herausforderungen bei einer Hybrid Cloud“ verfasst.


1 https://www.fast.ai/2018/08/10/fastai-diu-imagenet/

Extraktion strukturierter Daten aus Tankbelegen: So wird die Reisekostenabrechnung endlich effizient

12 Millionen Geschäftsreisende gab es 2018 nach Angaben der Geschäftsreisenanalyse 2019 des VDR (Verband Deutsches Reisemanagement e.V.)1 und damit einen ganzen Berg an Reisekostenabrechnungen, die es zu bearbeiten gilt – für Arbeitnehmer und in den Unternehmen. In Zeiten von KI und Digitalisierung setzen allerdings nur 13 % der befragten Unternehmen (10-500 Mitarbeitern) eine vollständige digitale Reisekostenabrechnung um1. Auch bei uns – einem Softwareunternehmen – ist die Reisekostenabrechnung noch nicht vollständig automatisiert. Daher haben wir uns in Form einer Thesis mit möglichen Verfahren der Informationsextraktion beschäftigt, um diesen Prozess digitalisieren zu können.

Fehlende Normierung behindert Automatisierungsprozess

Ein Teilproblem der vollständigen Automatisierung ist das Fehlen einer Normierung für Rechnungen über Kleinstbeträge – auch bekannt als Belege. Dies erschwerte ein automatisiertes Extrahieren der gesuchten Daten enorm. Zeit für die Digitalisierung des Prozesses durch Umsetzung eines Systems zur automatischen Extraktion von Daten aus Tankbelegen. Das System gliedert sich dabei in drei Teilprobleme, die es zu lösen gilt:

 

Vorverarbeitung des Eingabebildes

Der erste Schritt zur Digitalisierung eines Dokumentes ist das Umwandeln des bedruckten Papiers in eine Datei. Dazu kann entweder ein Scanner oder eine Fotokamera verwendet werden. Das Resultat aus beiden Vorgängen ist eine Bilddatei. Hier ein Beispiel, das mithilfe einer Handykamera aufgenommen wurde:

Quelle: Bild von Tankbeleg – eigene Darstellung
Quelle: Bild von Tankbeleg – eigene Darstellung

Um dieses Bild für eine Textextraktion zu optimieren, muss dieses in seine binäre Darstellung umgewandelt werden – dies erreichen wir durch eine sogenannte Binarisierung. Das Ziel einer Binarisierung ist, dass alle Pixel nur noch die Werte „eins“ (Vordergrund / Schrift) oder „null“ (Hintergrund) erhalten. Dadurch lässt sich der Text vom Hintergrund separieren. Voraussetzung hierfür ist ein Bild in Graustufen, denn bei der Binarisierung wird versucht eine Schwelle für Grauwerte zu berechnen, damit ein Pixel eindeutig als „eins“ oder „null“ identifiziert werden kann. Binarisierungsverfahren lassen sich in zwei Ansätze einteilen: Ein globaler Ansatz versucht eine Schwelle für das gesamte Bild zu finden. Ein lokaler Ansatz hingegen versucht eine Schwelle für kleine Ausschnitte des Bildes zu finden. Aber wann nun welches Verfahren nutzen? Globale Ansätze sind gut, falls das Bild in einer einheitlichen Helligkeit vorliegt. Dies ist aufgrund der per Kamera aufgenommenen Fotos allerdings nicht der Fall. Daher haben wir festgestellt, dass in das System ein lokaler Binarisierungsansatz implementiert werden muss. Nach dem Anwenden einer Binarisierung mithilfe der Methode von Sauvola – ein adaptives Binarisierungsverfahren, welches Dokumente anhand lokal adaptiver Schwellenwerte binarisiert – liegt das Bild in seiner binären Darstellung vor:

Quelle: Binäre Darstellung Tankbeleg – eigene Darstellung
Quelle: Binäre Darstellung Tankbeleg – eigene Darstellung

Ein weiteres wichtiges Verfahren der Vorverarbeitung ist die Korrektur des Neigungswinkels, falls das Bild schief eingescannt oder fotografiert wurde. Durch diese Korrektur kann ein Finden von Textzeilen stark vereinfacht werden. Zu diesem Zweck haben wir in das System eine Linienfindung implementiert. Diese sucht zusammenhängende Textzeilen und stellt diese als Linie dar. Anhand der Mittelung aller Winkel dieser Linien relativ zur x-Achse kann so der Neigungswinkel berechnet werden. Das Dokument muss anschließend noch im inversen Winkel rotiert werden. Durch eine Korrektur des Neigungswinkels verbessert sich die Qualität der Textextraktion erheblich. Seht selbst:

Originale Darstellung Tankbelegbeispiel
Originale Darstellung
Korrigierte Darstellung Tankbelegbeispiel
Korrigierte Darstellung

Quelle: https://www.kress.eu/de/news/309-deutliche-kraftstoffersparnis-erneut-nachgewiesen.html

Auslesen des Textes

Das Überführen von gescannten oder fotografierten Bildern in maschinenlesebaren Text nennt sich Optical Character Recognition (OCR). Durch diese Technologie ist es möglich, Bilder mit textuellem Inhalt durch Computersysteme erkennen zu lassen. Eine populäre Lösung hierfür ist die OpenSource OCR Engine Tesseract. Die Engine wurde ursprünglich von HP entwickelt und wird seit 2006 von Google gepflegt und erweitert2.
Um Tesseract zu verwenden, kann auf das Apache Tika Toolkit zurückgegriffen werden. Dieses Toolkit bietet unterschiedliche Parser zum Extrahieren von Daten an, unter anderem den TesseractOCRParser. Durch ihn ist eine problemlose Kopplung der Tesseract OCR Engine an eine Java Applikation möglich.

Extraktion der relevanten Informationen

Da der Text nun in maschinenlesbarer Form vorliegt, muss das System die eigentliche Informationsextraktion durchführen. Eine Bibliothek zum Finden strukturierter Informationen in unstrukturiertem Text ist Apache UIMA (Unstructered Information Management Architecture). Die Bibliothek bietet Schnittstellen zu den Programmiersprachen C++ und Java. Mit UIMA können Annotatoren entwickelt werden, die zum Beispiel auf Basis von regulären Ausdrücken Informationen aus unstrukturiertem Text extrahieren.

Alle Komponenten innerhalb von UIMA kommunizieren mithilfe der Common Analysis Structure (CAS). Die CAS ist ein Subsystem in UIMA, das den Datenaustausch zwischen UIMA Komponenten ermöglicht3. Innerhalb der CAS wird ein TypeSystem definiert, das alle Datentypen beinhaltet, die extrahiert werden sollen. In unserem Fall der Tankbelege wären das die Datentypen Sum, Date, Time, Quantity (Literzahl), Type (Kraftstoffart) und Address. Für diese Datentypen werden in dem vorher erwähnten Annotator die entsprechenden regulären Ausdrücke hinterlegt.
Im nächsten Schritt wird in das CAS der im vorhergehenden Schritt ermittelte Dokumententext eingegeben. Der Annotator durchsucht nun den im CAS hinterlegten Dokumententext und speichert die Start- und Endposition im Text, wo der jeweilige Datentyp zu finden ist. Das CAS kann anschließend nach diesen Datentypen, also den strukturierten Informationen, durchsucht werden. Eine Beispielhafte Informationsextraktion mit Apache UIMA aus dem Belegfoto (s. oben) ist im Folgenden dargestellt:

Beispielhafte Informationsextraktion mit Apache UIMA – eigene Darstellung
Beispielhafte Informationsextraktion mit Apache UIMA – eigene Darstellung

Es ist zu erkennen, dass alle Daten bis auf die Gesamtsumme korrekt extrahiert werden können. Dies hängt mit der Schwierigkeit zusammen einen regulären Ausdruck zu entwickeln, der nicht alle Eurobeträge extrahiert, sondern nur den gewünschten. Bei nicht-normierten Daten wie dem Gesamtbetrag schneidet ein KI-System besser ab, da dort der vorliegende textuelle Kontext (z.B. die Position im Gesamttext) in die Klassifizierung mit einbezogen werden kann.

Fazit

Das System zur Extraktion strukturierter Daten aus Tankbelegen ist damit fertiggestellt und erleichtert die Reisekostenabrechnung in Zukunft erheblich.
Die wichtigsten Schritte der Vorverarbeitung bei der Digitalisierung analoger Dokumente sind die Binarisierung und eine anschließende Korrektur des Neigungswinkels, da ansonsten eine Texterkennung unter Umständen deutlich schlechtere Ergebnisse liefert. Falls Dokumente vorliegen, die unterschiedliche Helligkeitsgrade aufweisen muss statt eines globalen Binarisierungsverfahren ein lokales verwendet werden.
Die Qualität der Informationsextraktion hängt stark von den entwickelten regulären Ausdrücken für den jeweiligen Datentyp ab. Es kann festgehalten werden, dass auch in Zeiten der Künstlichen Intelligenz eine regelbasierte Informationsextraktion durchaus noch eine Daseinsberechtigung besitzt, da viele Daten (wie z. B. Datum und Uhrzeit) normiert sind und dadurch eindeutige reguläre Ausdrücke zur Informationsextraktion angewendet werden können. Durch die Anbindung des Systems an die Cloudlösung „Business Filemanager“ können Tankbelege sogar von unterwegs aus direkt hochgeladen, ausgelesen und damit der Reisekostenabteilung zur Verfügung gestellt werden.

P.S: Wir haben eine Lösung gefunden, die wir zwar nicht selbst programmiert haben, aber rege nutzen: die App Lunchit®. Hierbei handelt es sich um denselben Ansatz nur für Essensbelege. Seit wir Lunchit® nutzen sparen wir erheblich Zeit in der Verwaltung. Wir müssen nun keine Essensmarken mehr ausgeben und mit den Restaurants verrechnen. Ein weiterer Pluspunkt: Arbeitnehmer sparen außerdem Zeit durch die Nutzung der App, da keine Belege oder Marken mehr abgeholt, mitgenommen und abgezählt werden müssen.
Und wie sieht es bei Dir aus – tippst Du noch Reisekostenabrechnungen manuell oder digitalisierst Du schon? Teile Deine Erfahrungen mit uns durch einen Kommentar.

Hier mehr über Machine Learning Verfahren in der Praxis erfahren

 

1. Quelle: https://www.vdr-service.de/fileadmin/services-leistungen/fachmedien/geschaeftsreiseanalyse/VDR-Geschaeftsreiseanalyse-2019.pdf

2. Quelle: Ray Smith. An overview of the tesseract ocr engine. In Ninth International Conference on Document Analysis and Recognition (ICDAR 2007), volume 2, pages 629 – 633. IEEE, 2007.

3. Quelle: Thilo Gotz and Oliver Suhre. Design and implementation of the uima common analysis system. IBM Systems Journal, 43(3):476{489, 2004.

KI kann alles? Die aktuellen Grenzen von KI und Deep Learning

Künstliche Intelligenz war schon immer ein wesentlicher Bestandteil futuristischer Visionen. Diesen Zukunftsbildern sind wir in den letzten Jahren durch die rasante Entwicklung im Bereich der künstlichen Intelligenz deutlich nähergekommen. Wer hätte schon um die Jahrtausendwende mit selbstfahrenden Autos gerechnet? Gleichzeitig werden die (scheinbar unendlichen) Möglichkeiten von KI, z.B. in den Medien, häufig zu optimistisch oder auch z.T. übertrieben dargestellt. Das sogenannte Deep Learning, eine spezielle mathematische Methode basierend auf neuronalen Netzen, ist ganz maßgeblich für den aktuellen Hype um KI mit verantwortlich. Gleichzeitig hat auch diese Methode seine Grenzen, auf die Gary Marcus in seinem Paper „Deep Learning: A Critical Appraisal“ strukturiert eingeht. Inspiriert von dieser Arbeit soll im Folgenden auf diese Grenzen näher eingegangen werden.

Die Größe der realen Welt und wie begrenzt KI sie sieht

Die Realität ist unglaublich komplex und unglaublich vielfältig. Wir Menschen bewegen uns tagtäglich in dieser Komplexität, die häufig daher rührt, dass wir nicht in fest definierten, abgeschlossenen Systemen leben. Viele Teilaufgaben kann künstliche Intelligenz schon heute besser lösen als wir, aber gleichzeitig sind Menschen immer noch recht gut darin, Information im jeweiligen Kontext zu verarbeiten. Sehen wir nachts eine rot leuchtende Verkehrsampel im Garten eines Freundes, erkennen wir sie als Partybeleuchtung und warten nicht darauf, dass auf grün umschaltet.

Wie sieht künstliche Intelligenz aber die Welt? KI-Algorithmen lernen die Welt durch Datensätze kennen. Betrachten wir zum Beispiel das autonome Fahren. Eine Teilaufgabe besteht für KI hier darin, Schilder korrekt zu erkennen. Hierzu können wir einem KI-Algorithmus Beispielbilder vorlegen. Gleichzeitig würden wir die Schilder auf den Beispielbildern markieren und die korrekte Kategorie benennen („Stoppschild“). Der KI-Algorithmus vergleicht nun ein Bild mit der erwarteten Ausgabe („Stoppschild“) – dies macht er mit allen Beispielbildern und versucht, einen mathematischen Zusammenhang zwischen dem Bild und der Verkehrsschildkategorie zu finden.

Die Welt besteht für einen KI-Algorithmus also hauptsächlich aus den Daten, die ihm vorgelegt werden. Damit unterscheidet sich der KI-Algorithmus natürlich nicht grundlegend von uns Menschen, aber es gibt doch einige Herausforderungen und Grenzen, die ihn doch unterscheidet.

Schierer Datenhunger

Ein kleines Kind, das zum ersten Mal in seinem Leben einen Elefanten sieht, versteht sehr schnell was ein Elefant ist und erkennt danach ein solches Tier auch in anderen Zusammenhängen sehr zuverlässig, z.B. in einem Kinderbuch oder im Fernsehen. Bei Deep-Learning-Algorithmen ist dies nicht der Fall. Dies liegt daran, dass sie solche Zusammenhänge nicht explizit lernen können, sondern diese implizit auf Basis einer großen Anzahl von Beispielen tun. Daher sind sie extrem datenhungrig. Liegen diese großen Datenmengen nicht vor, dann tun sich diese Algorithmen sehr schwer, die Qualität der Modelle bzw. der Vorhersageergebnisse sinkt.

Auch müssen die verarbeiteten Beispieldaten möglichst alle Facetten eines Problems beinhalten. Ein Deep-Learning-Verfahren, dass immer nur mit weißen Schwänen trainiert wurde, ist – im Gegensatz zum Menschen – nicht in der Lage, einen plötzlich auftretenden schwarzen Schwan zu erkennen, wenn dieser vorher nicht in den Trainingsdatensätzen hinterlegt war.

Standing on the shoulder of giants
Abbildung 1: Standing on the shoulder of giants – eigene Darstellung

Auch heute können wir die Welt um uns (noch?) nicht abschließend erklären. Doch eine der Stärken der Wissenschaft ist es, auf dem vorhandenen Wissen aufzubauen und in einem iterativen Prozess immer bessere Modelle unserer Welt zu entwerfen. Das Englische Sprichwort „Standing on the shoulders of giants“ beschreibt dies anschaulich: Jede Generation baut auf den Vordenkern vergangener Epochen auf.

Das bedeutet aber auch, dass wir in all unserem Handeln immer auf dieses Vorwissen zugreifen können. Ein Apfel in unserer Hand, den wir loslassen, fällt auf den Boden und steigt nicht an die Decke. Fassen wir eine kalte Wand an, so wird die Wand wärmer und unsere Hand kälter – Energie geht also auf den kälteren Körper über. Das Gegenteil passiert nicht spontan. All das sind Beispiele für allgemeines Vorwissen, das wir stets als Transferwissen verfügbar haben, unabhängig davon, welche speziellen Probleme wir gerade lösen.
Doch Deep Learning-Algorithmen können dieses Transfer- oder Allgemeinwissen nicht nutzen. Sie können nicht auf einem allgemeinen Vorwissen aufbauen, sondern müssen jedes Problem, das sie lösen sollen, von Grund auf neu lernen. Deep-Learning-Algorithmen sind also immer sehr problemspezifisch.

Ein Beispiel in diesem Zusammenhang ist die Bilderkennung. Es gibt schon sehr gute Deep-Learning-Modelle zur Objekterkennung. Diese erkennen sehr zuverlässig, ob auf einem Bild ein Teller Nudeln oder ein Hund dargestellt wird. Eine leichte Abwandlung dieser Problemstellung – z.B. der Algorithmus soll auf Satellitenfotos automatisch Fahrbahnmarkierungen (Zebrastreifen, Pfeile, etc.) erkennen – führt dazu, dass diese Modelle für diese Problemstellung völlig unbrauchbar werden und ein ganzer Forschungszweig gegründet wird, der sich nur mit der Lösung dieses Themas beschäftigt.

Korrelation bedeutet nicht kausaler Zusammenhang

Die Nutzung von Vorwissen ist auch notwendig, um logisch sinnvolle Zusammenhänge von zufälligen Zusammenhängen zu unterscheiden. Ein Beispiel: Die Geburtenrate in westeuropäischen Ländern geht stetig zurück. Gleichzeitig ist die Anzahl brütender Storchenpaare rückläufig. Wollten wir die Geburtenrate erhöhen, müssten wir also einfach Störche besser schützen?

Historischer Verlauf zur Entwicklung der Storch- und Babyzahlen und dadurch abgeleitete Correlation.
Abbildung 2. Historischer Verlauf zur Entwicklung der Storch- und Babyzahlen und dadurch abgeleitete Correlation.

Das ist natürlich ein offensichtlicher Fehlschluss. Nur weil ein mathematischer Zusammenhang historisch existiert, heißt es noch lange nicht, dass die Geburtenrate in einem logischen Zusammenhang mit der Anzahl der Störche steht.

Grafik zum zukünftigen Verlauf zur Entwicklung der Storch- und Babyzahlen
Abbildung 3. Real eingetretener, zukünftiger Verlauf zur Entwicklung der Storch- und Babyzahlen.

Ein Mensch kann diesen offensichtlichen Fehlschluss erkennen, da er gerade auf seine gesamte Lebenserfahrung und Allgemeinbildung zurückgreifen kann – KI kann das im Allgemeinen nicht. Bei komplizierteren Problemstellungen können auch Menschen nicht mehr zweifelsfrei sagen, ob einem mathematischen Zusammenhang eine reale Abhängigkeit zu Grunde liegt. Hier müssen Wissenschaftler Hypothesen aufstellen, die sie dann immer wieder mit neuen Experimenten versuchen zu widerlegen.

Bedeutet Auswendiglernen wirklich Konzeptverständnis?

Im Begriff „Künstliche Intelligenz“ ist schon der Vergleich mit menschlichen Fähigkeiten angelegt. Diese Vergleiche ziehen sich durch alle Begrifflichkeiten: so „lernt“ zum Beispiel ein Machine-Learning-Modell Zusammenhänge und Ähnlichkeiten aus einem vorgegebenen Datensatz. Nur was genau bedeutet hier „lernen“? Ein Mensch ist in der Lage, mit recht wenigen Daten Konzepte zu lernen.
Zur Illustration dient Abbildung 4: in einem einfachen Computerspiel bewegt sich auf dem Bildschirm ein Ball. Ziel ist es mit dem Ball alle auf dem Bildschirm platzierten Blöcke zu berühren, die bei Berührung verschwinden. Trifft der Ball auf ein Hindernis, so wird er von dort abgestoßen. Es sei denn, er berührt den unteren Bildschirmrand, dann ist das Spiel verloren. Mit Hilfe eines horizontal beweglichen Schlägers lässt sich der Ball indirekt steuern.

Computerspiel nach dem Prinzip von Breakout - ein Ball muss mit einem Schläger gespielt werden, der beim Berühren die Blöcke zerstört
Abbildung 4. Computerspiel nach dem Prinzip von Breakout – ein Ball muss mit einem Schläger gespielt werden, der beim Berühren die Blöcke zerstört (Quelle: Flickr.com).

Ein Mensch versteht das Spielprinzip nach wenigen Sekunden, auch ohne eine explizite Regeldefinition und hat auch keine Probleme mit einer leichten Abwandlung: zum Beispiel, in dem die vertikale Position des Schlägers leicht verändert wird. Ein Deep-Learning-Modell hat mit solchen Verallgemeinerungen häufig große Probleme und scheitert durch die leichte Veränderung der äußeren Umstände. Das Modell hat nicht wirklich verallgemeinerte Konzepte gelernt („Schläger“, „Ball“, „Wand“) sondern durch endloses Ausprobieren eine erfolgreiche Lösungsstrategie gefunden – die jedoch nicht robust ist gegen kleine Abwandlungen der Systemparameter.

Die vielgefürchtete „black box“

Deep-Learning-Modellen wird häufig nachgesagt, dass sie schwer „erklärbar“ sind und wie eine „black box“ wirken. Man füttert das Modell mit Daten, erhält eine Antwort, aber weiß nicht wirklich, warum das Modell diese Antwort gegeben hat. Das Regelwerk, das zur Entscheidung führt, ist nicht sofort ersichtlich – es ist regelrecht undurchsichtig. Um diese Undurchsichtigkeit von KI zu durchbrechen, ist die „Erklärbarkeit“ von KI-Modellen ein Gegenstand aktueller Forschung. Aber warum ist das überhaupt wichtig? Ganz konkret schränken undurchsichtige KI-Modelle die Anwendbarkeit von KI in den folgenden zwei Beispielen ein:

Vertrauenswürdigkeit: Besonders in regulierten Bereichen, wie zum Beispiel der Medizintechnik oder dem Verkehrswesen, unterliegt jegliche Software besonders hohen gesetzlichen Auflagen. Es soll sichergestellt werden, dass die Software unter allen möglichen Umständen sicher agiert. Das stellt Deep-Learning-Modelle vor große Herausforderungen: Sie lernen hauptsächlich aus den zur Verfügung stehenden Daten. Nehmen wir wieder das Beispiel einer Verkehrsschilderkennung. Es ist undurchsichtig, warum genau das Modell ein Stoppschild als solches erkennt. Die Forschergruppe um Eykholt et al1. zeigte zum Beispiel, wie leicht KI-Modelle sich hier austricksen lassen können. Durch eine leichte Modifikation der Verkehrsschilder, die für Menschen klar als solche erkennbar war, wurden die Schilder nicht mehr als Stoppschild erkannt. Solche Effekte stellen natürlich das Vertrauen in Deep-Learning-Algorithmen für diese Anwendungszwecke in Frage. Die Undurchsichtigkeit von Deep-Learning-Modellen erschwert es, solche unerwünschten Effekte zu bemerken, da sie nicht direkt erkennbar sind.
Sicherheits- und Qualitätsgarantien für modulare Systeme: Im Ingenieursbereich werden komplexe technische Systeme häufig aus vielen kleinen Einzelteilen zusammengesetzt. Ein Auto benötigt einen Motor, Räder, eine Kupplung – für jede dieser Komponenten können in der Entwicklung Sicherheitsgarantien gegeben werden, die es erlauben das Teil in ein größeres Gesamtsystem einzusetzen. Deep-Learning-Modelle können das nicht ohne weiteres. Sie sind extrem abhängig von ihrem ursprünglichen Datensatz. Durch die Undurchsichtigkeit der Modelle ist es sehr schwierig, die Auswirkung veränderter Voraussetzungen auf das Modell abzuschätzen. Dementsprechend ist es nur schwer möglich ein Gesamtsystem modular aus vielen Modellen aufzubauen und verbindliche Qualitäts- und Performancegarantien für das Gesamtsystem abzuleiten.

Wie sieht die Zukunft von KI und Deep Learning aus?

Gary Marcus gibt ein paar Anregungen bezüglich der künftigen Entwicklung von künstlicher Intelligenz und insbesondere von Deep Learning:

  • Wiederaufleben anderer KI-Disziplinen: Deep Learning ist ein Teil des Machine Learning, welches wiederum einer ganz gewissen Disziplin der künstlichen Intelligenz angehört. Eine klassische Disziplin der KI ist symbolische Künstliche Intelligenz. Hierdurch können vielleicht Fortschritte im logischen Schließen erzielt werden.
  • Zurück zum Studienobjekt Mensch: So kann man besser verstehen und lernen, wie wir lernen und die Welt wahrnehmen. Disziplinen wie die kognitive Psychologie und Entwicklungspsychologie, die versuchen die Funktionsweise des Menschen besser zu verstehen, könnten hier neue Impulse liefern.
  • Anspruchsvollere Ziele: Häufig wird versucht, mit Deep Learning eng abgesteckte Probleme zu lösen. Stattdessen steht der Vorschlag im Raum, darüber hinausgehende Herausforderungen aufzustellen – z.B. einen Algorithmus ein beliebiges Video oder einen Text analysieren zu lassen und ihn offene Fragen beantworten lassen: Wer ist die Hauptfigur? Was will sie erreichen? Welche Folgen hätte ihr Erfolg oder Misserfolg?

 

Fazit: Herausforderungen und Grenzen kennen – Deep Learning richtig nutzen

Manchmal scheint es, als stünde Künstliche Intelligenz kurz davor, die Menschheit in jeglicher Hinsicht zu überflügeln. Es gibt in der Tat einzelne Problemstellungen, in denen dies der KI bereits gelungen ist. Dennoch sind wir von einer Dominanz der KI in allen Lebensbereichen noch ein gutes Stück entfernt. Deep-Learning-Methoden arbeiten besonders gut, wenn sehr viele Daten vorhanden sind und die Problemstellung ganz klar abgegrenzt ist. Aber es gibt auch noch viele Herausforderungen – unter anderem: ein echtes Verständnis abstrakter Konzepte, Transfer von Wissen auf neuartige Anwendungsprobleme, Transparenz und Sicherheitsgarantien, die Unterscheidung zwischen zufälligen und logisch sinnvollen Zusammenhängen. Daher ist ein Bewusstsein über diese Rahmenbedingungen, beim Einsatz von KI Verfahren wie z.B. Deep Learning, sehr wichtig. Die Anregungen von Gary Marcus für die künftige Entwicklung können da wertvolle Impulse liefern.

Co-Autor: Danny Claus


1 Robust Physical-World Attacks on Deep Learning Visual Classification

Vorbereitung ist alles: Wie die erfolgreiche Einführung eines Remote Service gelingt

 

„Mein PC zeigt eine komische Meldung an. Was muss ich jetzt drücken?“

„Ich bin schon bei der Arbeit – kannst du bitte schauen, ob ich das Bügeleisen ausgeschaltet habe?“

 

Im Alltag gibt es häufig Probleme, die wir remote lösen möchten. Oft funktioniert dies auch – manchmal ist die Problemlösung aber nicht so einfach umsetzbar, da die technischen Voraussetzungen nicht vorhanden sind.

Ähnliche Schwierigkeiten finden wir auch in der Industrie. Taucht beispielsweise an einer Maschine beim Kunden ein Fehler auf und die Maschine läuft nicht mehr, heißt es so schnell wie möglich handeln und das Problem remote identifizieren. Denn der plötzliche Stillstand einer Maschine bedeutet nicht nur wirtschaftliche Verluste, sondern mindert auch die Kundenzufriedenheit. Ehe eine nicht durchdachte Problembeseitigung angesteuert wird, ist eine Vorabanalyse in jedem Fall nötig: Vorbereitung ist alles, um Störungsfälle aus der Ferne effizient zu beheben. Der Lösungsansatz: die Einführung von Remote Services – doch wie vorgehen und was sollte beachtet werden?

Die gängigsten Remote Services

Unzählige UseCases werden im Bereich von Remote Services geboten. Die Favoriten darunter sind Sensorwerte, Remote Desktop, Log-/Konfigurationsdateien und Softwareupdates. Dabei lassen sich Sensorwerte anzeigen, so dass mögliche Fehlerquellen direkt identifiziert bzw. ausgeschlossen werden können. Auf diese Weise können defekte Teile schnell gefunden und so eine Reparatur effizient geplant werden. Um direkt die Oberfläche eines Produktes einsehen zu können und mit dieser zu agieren, ist die Nutzung von Remote Desktop weit verbreitet. Log-/Konfigurationsdateien werden wiederum übertragen, um Fehler zu analysieren und Einstellungen zu ändern. Eine weitere Anwendung ist die Bereitstellung und Auslieferung von Softwareupdates für neuste Sicherheitsupdates oder Features.

Die Bedienung: einfach aber effektiv

Eine Oberfläche zur Einsicht und Nutzung aller Funktionen muss erstellt werden. Die verfügbaren Daten müssen für den Nutzer übersichtlich aufbereitet und dargestellt werden, so dass ein Problem schnell gefunden werden kann. Für eine gute UserExperience ist hier auch ein Augenmerk auf die Endgeräte zu legen mit denen die Oberfläche bedient werden soll (Smartphone, PC, …). Des Weiteren müssen Benachrichtigungen versandt werden, um bei Problemen automatisch Verantwortliche zu informieren bzw. im Idealfall einen bevorstehenden Ausfall vorherzusehen (siehe auch Best Practices bei der Umsetzung von Predictive Maintenance).

Herausforderungen

Nachdem die Rahmenbedingungen festgelegt sind, gilt es zur erfolgreichen Realisierung von Remote Service verschiedene, komplexe Phasen zu durchlaufen:

  1. Connectivity: Das Vernetzen der Geräte ist Grundlage des Remote Service. Die Daten müssen remote abgreifbar sein. Hier gibt es oft auch bereits vorhandene Schnittstellen, da das Produkt bereits mit anderen Produkten kommunizieren muss. An diese kann man anknüpfen.
  2. Condition Monitoring: Automatisches Überwachen des Zustandes der Geräte. Hierbei gilt es die relevanten Datenwerte zu finden, die für einen Ausfall sorgen können.
  3. Alerting: Bei kritischen Zuständen müssen Verantwortliche angemessen alarmiert werden. Hierzu müssen zunächst kritische Zustände definiert und Verantwortliche gefunden werden.
  4. Predictive Maintenance, Prescriptive Maintenance: In diesem Fall wird vorab erkannt, dass ein Produkt ausfallen wird. So kann es proaktiv gewartet und Ausfallzeiten verhindert werden.

 

Des Weiteren müssen Abläufe definiert werden, die in enger Abstimmung mit den Service-Technikern wie auch mit den Kunden erstellt werden. Für ein Softwareupdate muss beispielsweise geklärt sein, wann und von wem dieses eingespielt werden darf. Wird das Produkt gerade eingesetzt, so wäre ein automatisiertes Update nicht gewünscht – evtl. sogar kritisch.

Eine weitere Herausforderung ist die Berücksichtigung des Datenschutzes: Wo werden die Daten z.B. gespeichert (On Premise, Cloud)? Wer kann welche Daten einsehen (Rechte und Rollen)? Müssen Daten zensiert werden (DSGVO)?

Remote Service mit ThingWorx

Mit unserem IoT Partner PTC und der ThingWorx-Plattform, haben wir bereits einige Remote Service Lösungen umgesetzt. Hierbei stellt sich ThingWorx als sehr flexibel heraus und bietet bereits Of-the-box-Lösungen an:

Connectivity: Neben einer Kepware-Integration zur direkten Anbindung von Produkten, die bereits Industriestandard Protokolle wie OPC nutzen, werden unter anderem auch SDKs für verschiedene Programmiersprachen angeboten. Vorhandene Systeme wie Mail, ERP oder Datenbanken können über Standard-Module wie auch einer REST-API angebunden werden. Kundenspezifische Protokolle über Protocol Adapter.

Dashboards: Durch den Mashup Builder können eigene Oberflächen erstellt werden. Auch bietet PTC mit Zusatzmodulen wie die ThingWorx Apps1 eine vorkonfigurierte Oberfläche für IoT Anwendungen. Diese kann nach Bedarf erweitert werden.

Remote Desktop: Neben einer integrierten Tunneling Lösung, die ohne aufwändiges VPN (VirtualPrivateNetwork) eine sichere Verbindung zu Applikationen wie Remote Desktop aufbauen kann, bietet ThingWorx auch eine TeamViewer Integration wie auch weitere Remote Assistance-Lösungen wie Augmented Reality2.

Predictive Maintenance: Mit ThingWorx Analytics3 können Machine Learning Projekte umgesetzt werden, die Ausfälle von Maschinen vorhersagen können sollen.

Fazit

Remote Service kann die Wartung von Geräten stark vereinfachen und dem Kunden sowie der Produktion einen hohen Mehrwert bieten. Damit dies reibungslos funktioniert muss eine Lösung sorgfältig geplant werden. Eine flexible Plattform ist hier von Vorteil, die sich auch für kommende UseCases einsetzen lässt. Hier legt ThingWorx mit den Out-of-the-Box Lösungen eine gute Grundlage bereit, ein Remote Service Projekt zu starten.

Der Bonus: Sind die Produkte erstmal connected, so bieten sich neben Remote Service auch weitere Einsatzzwecke der Daten an: Dashboards für den Kunden, Machine Learning, Auslastung der Produkte um Verbesserungspotentiale zu entdecken und noch viele weitere, auch ungeahnte Möglichkeiten, die man zuvor gar nicht in Betracht gezogen hatte.

Template Business Case herunterladen

 

Das könnte Dich auch interessieren: Praktische Predictive Services Anwendungen aus der Industrie


Links:

1 ThingWorx Apps

2 Industrial Augmented Reality für den Service

3 Predictive Analytics unterstützt durch Machine Learning

Die Zukunft von Predictive Maintenance: On the way to intelligent-prescriptive-predictive maintenance

Einen Überblick zu den Strategien und Best Practices im Kontext von Predicitive Maintenance finden Sie im ersten Teil unserer Blogreihe „Best Practices bei der Umsetzung von Predictive Maintenance – Ein Erfahrungsbericht “. Im nächsten Schritt sollte man sich jetzt auch darüber Gedanken machen, wo genau Künstliche Intelligenz eingesetzt werden kann und welche Machine Learning Methoden hier sinnvoll unterstützen können. Mehr

Den Nutzen von Big Data auch ohne Big Data Technologien erreichen

Vor allem in mittelständischen Unternehmen gilt Big Data mitunter als eine Art „eierlegende Wollmilchsau“. Die Einschätzung „Heute macht man das halt mit BigData, Spark, SMACK-Stack, Hortonworks, in der Cloud mit AWS“ führt häufig zu sehr komplexen Lösungen mit hohen Anforderungen an die Hardware. Ein Aufwand, der in vielen Fällen aber gar nicht erforderlich wäre oder gar ungeeignete Lösungen bringt. Zumal die Kosten oft den Nutzen deutlich übersteigen. Vor diesem Hintergrund gerieten klassische Technologien wie relationale Datenbanken durch neue Technologien, Produkte und Paradigmen im Big Data Umfeld in den Hintergrund.

Davon ausgehend beleuchten wir nachfolgend klassische Technologien, die in der Literatur im Big Data Umfeld als nicht leistungsfähig eingestuft werden, hinsichtlich Skalierungsmöglichkeiten. Ziel ist es zu validieren, wie zum Beispiel auch mit relationalen Datenbanken der Nutzen von Big Data Instrumenten erreicht werden kann und ob es eindeutige Indikatoren dafür gibt, ab wann man tatsächlich sinnvollerweise auf Big Data Technologien setzen sollte.

Es muss nicht immer Big Data sein

Grundsätzlich gilt: Mit der Einführung von Big Data Technologien muss auch die IT-Infrastruktur angepasst werden, um die Anwendungen auch optimal betreiben zu können.

Eine solche Anpassung an Big Data Technologie ist vor allem dann notwendig, wenn es darum geht, semistrukturierte oder unstrukturierte Daten zu analysieren. Klassische Technologien wie relationale Datenbanken sind hier durch ihre technischen Restriktionen weniger geeignet, denn mit diesen kann nur auf strukturierten Daten direkt gearbeitet werden.

Liegen allerdings bereits strukturierte Daten vor, muss es nicht zwingend eine Big Data Technologie sein. Hier sollte man zunächst anhand des Anwendungsfalls bewerten, ob eine Optimierung der bestehenden Technologie oder eine Anpassung der Fragestellung ausreichend ist. Möglicherweise genügt eine Ja/Nein Entscheidung anstatt der exakten Berechnung mit feingranularer Wahrscheinlichkeitsrechnung.

3-V Model als Indikator für Big Data

Eine eindeutige Einstufung, ab wann Big Data Technologien eingesetzt werden sollten, existiert nicht. Allerdings ist es anhand des sogenannten 3-V-Modells möglich zu erkennen, ob der Einsatz von Big Data Technologien hilfreich wäre.

Die Metriken Datenvolumen, -geschwindigkeit und -vielfalt

(Quelle: https://gi.de/informatiklexikon/big-data/)

Die Metriken Datenvolumen, -geschwindigkeit und -vielfalt charakterisieren die Anforderungen für einen Anwendungsfall. Je nach Ausprägung der drei Eigenschaften lässt sich abschätzen, ob moderne Technologien eingesetzt werden sollten.

Liegen in mehreren Datenbereichen die höchsten beziehungsweise zweithöchsten Anforderungen vor (äußerster und zweiter Ring von außen), ist der Einsatz moderner Technologien bzw. Big Data sinnvoll. Stellen hingegen nur einzelne Anforderungen in einem Bereich hohe Anforderungen (zum Beispiel „besonders schnell, aber kein hohes Datenvolumen“, oder „sehr hohes Datenvolumen per Batchjobs“), muss jeder Anwendungsfall individuell beurteilt werden, ob sich Big Data Technologien anbieten oder ob es bessert ist, klassische Technologien zu optimieren.

Optimierungsmöglichkeiten von klassischen Technologien

Best Practices um Skalierungspotenziale relationaler Datenbanken auszuschöpfen:

  • Grundsätzlich sind die Daten in relationalen Systemen unsortiert, aufgrund dessen kann das Anlegen von Indizes zu schnelleren Zugriffszeiten führen.
  • Das Verlagern von Teilrelationen in den Arbeitsspeicher kann zur schnelleren Verarbeitung der Daten führen, da die Daten nicht mehr zwischen Arbeitsspeicher und Festplattenspeicher übertragen werden.
  • Das Erstellen von Partitionen und Replikationen führt zu parallelen oder einzelnen Zugriffen auf verschiedene Teilrelationen einer Datenbank. Dadurch ist eine parallele Verarbeitung gewährleistet, oder es werden nur relevante Daten einer Relation zur Analyse verwendet.
  • Das Einrichten einer Master-Slave-Architektur orientiert sich am verteilten Datenmanagement, das auch Hadoop verwendet. Dadurch können Datensätze auf unterschiedlichen Servern verteilt und parallele Analysen durchgeführt werden, indem die Last einer Anfrage aufgeteilt wird.
  • Für die „Vorverarbeitung“ der Daten und zur späteren Präsentation der Ergebnisse lassen sich materialisierte Sichten verwenden, um Zeit zu sparen.

 

Fazit:

Big Data Technologien können in vielen Situationen eine Lösung bieten, die ohne diese nicht möglich gewesen wäre. Die Entscheidung zum Einsatz solcher Technologien muss aber gut überlegt sein, denn der Einsatz ist kostspielig und aufwändig. Das 3-V-Modell kann helfen zu entscheiden, ob nicht auch schlankere und damit günstigere Ansätze ebenso zum Ziel führen können.

Co-Autor Bartu Uysal

 

Mehr zu Datenintegration gibt’s hier

Buzzword Dschungel Künstliche Intelligenz (KI) – die wichtigsten Begriffe auf einen Blick

In unseren Gesprächen mit Kunden und Partnern werden häufig Begriffe wie Künstliche Intelligenz (KI), Data Science oder Machine Learning in einem Atemzug genannt. Dabei schwirren zahlreiche Schlagworte durch die Gegend, die häufig gar nicht so klar voneinander abgrenzbar sind oder als Synonyme verwendet werden. Hier möchten wir Licht ins Dunkel bringen und einen kurzen und klaren Überblick über die wichtigsten Begriffe geben, diese kurz erläutern und zueinander abgrenzen.

Künstliche Intelligenz, Machine Learning, Neuronale Netze

KI bezeichnet die Automatisierung von menschlichem Verhalten. Man unterscheidet hierbei zwischen der starken und schwachen KI.

Vergleich Starke-Schwache KI
Vergleich Starke-Schwache KI

Von einer starken KI mit eigenem Bewusstsein und Empathie ist die Wissenschaft noch meilenweit entfernt. Wenn heutzutage von Künstlicher Intelligenz gesprochen wird, dann bezieht sich dies auf Anwendungsfälle im Bereich der schwachen KI. Diese Systeme sind in der Lage einzelne, klar abgegrenzte Aufgaben, wie z.B. Bilderkennung, gut zu lösen. Sie erlangen dabei aber kein tiefergehendes Verständnis des dahinterliegenden Problems und erscheinen dadurch nur nach außen intelligent.

Teilmengen Künstliche Intelligenz
Teilmengen Künstliche Intelligenz

Die schwache KI basiert dabei auf Methoden der Mathematik und Informatik. Ein wichtiges Subset von Methoden in diesem Bereich wird unter dem Begriff Machine Learning zusammengefasst. Neuronale Netze wiederum sind innerhalb des „Werkzeugkastens“ Machine Learning eine Methode bzw. ein Tool das eingesetzt werden kann. Innerhalb dieser Methode stellt das Deep Learning eine ganz spezielle Ausprägung eines neuronalen Netzes dar.

Das könnte Dich auch interessieren: DFKI-Projekt soll Deep-Learning-Verfahren verlässlicher machen (elektroniknet.de)

Data Analytics, Data Science, Data Mining

Unter Data Analytics versteht man zunächst alles was mit einer zielgerichteten Analyse von Daten zu tun hat. Auf Basis des Ergebnisses dieser Analyse sollen neue Schlussfolgerungen und Handlungsempfehlungen ermöglicht werden. Unter dem Begriff Data Analytics haben sich über die Zeit weitere Disziplinen, wie beispielsweise Data Science entwickelt.

Data Science ist der Überbegriff für eine Reihe an Methoden und Algorithmen mit denen man aus Daten Wissen generieren kann. Hierzu kommen ausgereifte Verfahren aus dem Bereich Mathematik, Statistik und Informatik zum Einsatz. Um die Ergebnisse dieser Verfahren auch korrekt interpretieren zu können, ist es notwendig, dass ein Data Scientist auch ein entsprechendes fachliches Wissen (z.B. über die Funktionsweise einer Windkraftanlage) mitbringt bzw. im Verlauf eines Projekts aufbaut. Mit Data Science ist man in der Lage, sowohl strukturierte Daten (z.B. eine Tabelle mit fest definierten Attributen wie Alter, Name, etc.), unstrukturierte Daten (z.B. ein komplexer Text in natürlicher Sprache) und semistrukturierte Daten (ein Mix aus strukturierten und unstrukturierten Daten) zu analysieren.

Data Science

Data Mining ist als ein Teilbereich innerhalb von Data Science zu verstehen. Ziel ist es, bisher unbekannter Querverbindungen, Trends oder Muster in großen Datenmengen zu finden. Dabei werden auch Methoden eingesetzt, die im Bereich Machine Learning Anwendung finden (z.B. Clustering). Da diese Methoden aber quasi „von Hand“ durch einen Menschen auf Daten angewendet werden, bringen Data Mining Techniken (im Gegensatz zu Machine Learning) keine selbstlernenden Mechanismen mit. Bildlich gesprochen lernt der Mensch und nicht die Maschine.

Rollen in einem Data Science Projekt

Innerhalb von Data Analytics Projekten benötigt man ganz unterschiedliche Skills und Experten. Die zugehörigen Rollen sind dabei sehr breit gefächert und oft nicht ganz klar voneinander abzugrenzen. Ein Data Scientist kann beispielsweise auch Aufgaben übernehmen, die man eher einem Data Engineer zuordnen würde und umgekehrt. So muss ein Data Scientist auch häufig Daten aufbereiten, da dies ein elementarer Bestandteil von vielen Datenanalyse-Projekten ist.

Data Science Projekt Rollen
Data Science Projekt Rollen

 

Im Data Analytics gibt es vier verschiedene Stufen, um große Datenmengen zu analysieren.

Datenanalyseverfahren

Analyseansätze im Data Analytics

 

Jede Stufe ist mit einer bestimmten Fragestellung verknüpft – die es gilt zu beantworten. Dabei steigt die Komplexität, um zu einer zielgerichteten Antwort auf die jeweilige Frage zu kommen. Gleichzeitig steigt aber auch der entsprechende Mehrwert der damit verbunden ist.

Machine Learning- Business Value und Komplexität

 

Business Intelligence, Advanced Analytics

Sowohl Business Intelligence als auch Advanced Analytics sind häufig verwendete Begriffe, die Verfahren und Prozesse zur Analyse von Daten des eigenen Unternehmens bezeichnen.

Business Intelligence ist der Vorreiter von Advanced Analytics, wo man durch Datenanalysen vergangene Ereignisse untersucht. Man kann Business Intelligence in den Analyseverfahren Descriptive und Diagnostic Analytics einordnen, da Fragen wie „Wie viele Produkte habe ich zu welchem Preis in welcher Region verkauft?“ beantwortet werden können.

Im Gegensatz zu Business Intelligence wird mit Advanced Analytics Methoden der Blick gezielt in die Zukunft gerichtet¹. Dadurch können Prognosen über zukünftige Ereignisse aufgestellt werden. Fragen wie „Wie viele Produkte sollen wir produzieren?“ oder „Wann soll eine Wartung durchgeführt werden?“ können beantwortet werden. So ist Advanced Analytics unter den Predictive und Prescriptive Analytics Verfahren einzuordnen.

ETL, Big Data, Data Lake, Data Discovery, Data Exploration

ETL bedeutet Extract, Transform und Load und ist die Grundlage für die Befüllung von Data Warehouse und eine Basistechnologie zur Datenintegration. Zuerst werden die Daten extrahiert aus ein oder mehreren Quellen, dann transformiert in ein gewünschtes Zielformat und zuletzt an einen Zielort abgelegt.

Volume, Variety und Velocity sind die drei Dimensionen von Big Data. Was bedeutet, dass dieses Phänomen sich aus rasant (Velocity) steigender (Volume) Daten unterschiedlicher Art (Variety) ergibt. Daraus ergeben sich sowohl Herausforderungen wie das Speichern, Verwalten, als auch Chancen wie Möglichkeiten diese Daten auszuwerten.

In einem Data Lakewerden strukturierte und unstrukturierte Daten aus verschiedenen Datenquellen zusammengeführt mit dem Ziel, die verschiedenen, isolierten Datensilos eines Unternehmens aufzubrechen und die Daten an einen zentralen Ort zusammenzuführen. Auf diesen, dort gespeicherten Rohdaten können dann weitergehende, komplexe Datenanalysen durchgeführt werden.

Der Discovery Prozess im Bereich Data Discovery deckt die Erforschung und die Vorbereitung der Daten ab. Der Prozess kann mit einem initialen Qualitätscheck starten. Um eine erste Einschätzung zum Potential der Daten zu erhalten, kann ein simples Machine Learning Model angewandt werden. Der Discovery Prozess dient dazu erste Hypothese, Ideen oder Datenpotential ausfindig zu machen.

Als Weiterführung von Data Discovery wird in Data Exploration nach „tieferen“ Entdeckungen gesucht, welche zu einem ersten Prototyp führen können. Ziel ist es die gewünschte Lösung festzulegen, damit sie nicht vom Ziel abweicht.

 

FAZIT: Buzzword Dschungel KI – viele Wege führen zum Mehrwert aus Daten

Im Laufe der Zeit ist eine Vielzahl an Begrifflichkeiten rundum KI entstanden, die sich häufig in Teilen überlappen und auch nicht immer ganz 100% klar voneinander abgegrenzt werden können. Bei genauerer Betrachtung stellt man fest, dass sich hinter jedem Buzzword eine eigene, häufig sehr spezialisierte Wissensdomäne versteckt, die mit einem entsprechenden technologischen und methodischen Know-How verbunden ist. Sie alle haben aber gemein, dass sie versuchen, neue Informationen und damit einen Mehrwert aus Daten zu generieren. Mit diesem Beitrag haben wir versucht, die Abgrenzungen und auch die Überschneidungen deutlich zu machen.

Co-Autorin Christina Reiter


¹https://www.alexanderthamm.com/de/artikel/advanced-analytics-theorie-und-praxis/

 

Wollen Sie mehr Durchblick im KI Dschungel? Hier entlang …