© DrHitch/Shutterstock.com
Einstieg ins Machine Learning

2 Text-Preprocessing für ML


Die meisten Verfahren im Bereich des Machine Learnings (ML) arbeiten mit rein numerischem Input. Bei den meisten Arten von Daten, z. B. Tabellen von Messwerten oder Bildern, ist die Umwandlung in die richtige Form offensichtlich. Aber wie können wir Machine Learning mit Buchstaben und Wörtern betreiben? Der Erfolg hängt vom richtigen Preprocessing ab.

Erfolgreiches Machine Learning ist meist zu 75 Prozent von richtigem Preprocessing abhängig. Da die richtige Repräsentation der Daten bei Text nicht eindeutig ist, sondern immer von der Zielsetzung und dem verwendeten Verfahren abhängt, hat das Preprocessing bei der Arbeit mit Text einen noch höheren Stellenwert als ohnehin schon. In diesem Kapitel wollen wir uns der Frage widmen, wie wir dieses wichtige Preprocessing richtig umsetzen, und welche Textdarstellungen es gibt, um den größtmöglichen Erfolg mit unseren ML-Algorithmen zu erzielen.

Die meisten ML-Algorithmen, insbesondere bei Deep Learning (Schichten von neuronalen Netzen), benötigen Input in Form von Tensoren. Praktisch kann man bei der Entwicklung Tensoren mit mehrdimensionalen Arrays von Fließkommawerten gleichsetzen. Die Abbildungen 2.1, 2.2 und 2.3 zeigen Beispiele für Tensoren.

image

Abbildung 2.1: Ein 1-D-Tensor (Vektor), z. B. eine Zeile in einem Spreadsheet

image

Abbildung 2.2: Ein 2-D-Tensor (Matrix), z. B. ein Schwarz-Weiß-Bild

image

Abbildung 2.3: Ein 3-D-Tensor, z. B. ein RGB-Bild

Bei numerischen tabellarischen Daten oder Bildern liegt die Umwandlung auf der Hand. Schließlich haben die Daten prinzipiell schon die richtige Form. Die meisten ML-Verfahren erwarten aber nicht nur Tensoren, sondern auch, dass sie immer dieselbe Größe haben. Tabellarische Daten sind meist gleichförmig, die Datenpunkte haben dieselbe Anzahl Spalten (= dieselbe Dimension). Bilder lassen sich trivial vergrößern oder verkleinern und so in Matrizen fester Größe umwandeln. Die meisten Textdaten aber variieren in der Länge von Datum zu Datum, ähnlich wie Audio und Video, was eine zusätzliche Hürde in der Nutzung darstellt.

Das Hauptproblem von Text ist also, dass die richtige numerische Darstellung nicht auf der Hand liegt. Der Grund dafür ist, dass es auch nach über sechzig Jahren KI-Forschung noch nicht gelungen ist, eine allgemeingültige Repräsentation von Wissen zu finden, mit der Algorithmen arbeiten können. Aber genau das ist ja Text: ein künstliches Mittel, mit dem Menschen Wissen außerhalb von Köpfen aufbewahren können. Das macht Text zugleich auch unglaublich reizvoll und nützlich für KI-Verfahren:

  • Es gibt viel davon (Internet, Bücher, firmeninterne Dokumentensammlungen …)
  • Er ist oft leicht verfügbar (Scraper, Datenbanken, einfacher File-Import)
  • Wissen ist enorm kompakt repräsentiert (Der String Katze lässt sich in 5 Byte oder weniger packen, ein Katzenbild hat schnell einige Dutzend oder Hunderte Kilobyte)

Trotz der Hürden lohnt es sich also herauszufinden, wie man Text geschickt in eine passende Form bringen kann, um die Vorteile von ML zu nutzen (Kasten: „Klassisches NLP vs. Machine Learning“).

Klassisches NLP vs. Machine Learning

Dieses Kapitel legt einen Fokus auf Machine-Learning-Verfahren und damit Verfahren, die generisch auf (fast) beliebigen Inputs arbeiten können, solange sie als Tensoren vorliegen. Es gibt aber auch eine Reihe von nützlichen Algorithmen, die mit rein regelbasierten Verfahren arbeiten. Die sind nicht auf die Darstellung von Text als Tensoren angewiesen und arbeiten oft auf Strings, z. B. Part-of-Speech-(POS-)Tagging, Lemmatisierung, Stemming, Ermittlung von Satzanfang und -ende etc. Diese sind allerdings oft händisch durch langjährige, mühsame Arbeit ermittelt und verfeinert worden. Der Vorteil dieser Verfahren ist, dass sie erprobt und als fertige Bibliotheken verfügbar sind und so als Ergänzung zu ML-Verfahren oder zum Preprocessing eingesetzt werden können. Der Nachteil ist, dass sie in der Regel für jede neue Sprache mühsam händisch neu angepasst werden müssen. Nichtsdestotrotz ist es nützlich, sich einen Überblick über die Möglichkeiten zu verschaffen, die auch ohne ML zur Verfügung stehen.

First Things First: die richtige Nutzung von Unicode

Um mit Text arbeiten zu können, muss er zerschnitten werden, die Schnipsel müssen verglichen, Sonderzeichen und Umlaute einheitlich dargestellt und die Länge von Textelementen muss verglichen werden. Das ist natürlich trivial – wir nehmen einfach für alle Texte Unicode, dann geht alles wie von Zauberhand!

Leider ist es in der Praxis nicht so leicht. Das Problem ist, dass die Codierung eines Texts in Unicode nicht eindeutig ist, auch wenn es bei der Darstellung des Texts auf dem Bildschirm so aussieht. Insbesondere bei der Arbeit mit OCR-Software und wenn der Input aus Dokumenten stark unterschiedlicher Herkunft besteht, ergeben sich häufig Probleme wie die folgenden (und das ist nur eine Auswahl):

  • Umlaute und Akzente können als ein Code-Point (z. B. U+00FC LATIN SMALL LETTER U WITH DIAERESIS) oder als zwei Code-Points (z. B. U+0075 LATIN SMALL LETTER U und U+0308 COMBINING DIARESIS) repräsentiert werden.
  • Auch scheinbar eindeutige Zeichen wie der Buchstabe A können durch verschiedene Code-Points dargestellt werden, es gibt mehr als zehn Unicodecodierungen für das lateinische Alphabet (a–z, A–Z) und die arabischen Ziffern (0–9).
  • Es gibt mehr als zwanzig Arten von Leerzeichen. Zieht man das nicht in Betracht und zerlegt Text einfach anhand von Standardleerzeichen (U+0020), kann es sein, dass Wörter aneinander kleben bleiben.
  • Manchmal können mehrere Buchstaben zusammen durch einen einzelnen Code-Point, eine Ligatur, repräsentiert werden. Das führt dann dazu, dass der String „Affe“ die Länge drei hat (weil das Doppel-F durch ein Zeichen dargestellt wird) und der String „Af f e“ die Länge vier.
  • Je nach Alter des Inputs kann es auch sein, dass Code-Points „deprecated“ sind, das heißt, sie wurden durch neue Code-Points an anderer Stelle ersetzt.

Grund hierfür ist, dass Unicode über Jahre gewachsen ist und Sprache, Text und Druck komplizierte Materien sind. Für die meisten dieser Besonderheiten gibt es gute und logische Begründungen. Nichtsdestotrotz ist derartiger Input Gift für erfolgreiches ML. Zum Glück gibt es hierfür eine Lösung: Normalisierung.

char vs. Buchstabe vs. Code-Point vs. Glyphe

1 char = 1 Buchstabe. Einfach, oder? Sobald man sich umfassend mit Text-Preprocessing beschäftigt, lohnt es sich, einmal einen Blick auf die Details von Schriftsystemen zu werfen.

Ein Zeichen auf dem Bildschirm nennt man eine Glyphe. Das genaue Aussehen einer Glyphe wird durch den verwendeten Schriftsatz (Font) bestimmt. Bei europäischen Schriftsystemen ist eine Glyphe meist identisch mit einem Buchstaben, aber im Fall einer Ligatur wie „ff“ statt „f f” ist es auch möglich, dass eine Glyphe mehrere Buchstaben umfasst. Im Chinesischen repräsentiert eine Glyphe meist ein ganzes Wort. Ein Emoji wäre z. B. auch eine Glyphe.

Glyphen setzen sich aus einem oder mehreren Graphemen zusammen. Ein Graphem ist das kleinste bedeutungsunterscheidende Element einer Schriftsprache. Bei einfachen Buchstaben wie „A“ ist ein Buchstabe ein Graphem, das eine Glyphe ist. Akzente und andere Betonungszeichen oder Teile asiatischer Schriftzeichen kann man auch als Graphem auffassen. Je nach akademischer Sichtweise ist z. B. ein „ü“ ein einzelnes Graphem oder besteht aus den Graphemen „u“ und „¨“ (weshalb es beide Möglichkeiten gibt, einen Umlaut in Unicode zu repräsentieren).

Die Mission von Unicode war, alle Grapheme aller Schriftsprachen repräsentieren zu können. Oft ist es gelungen, allerdings nicht immer, sodass es besser ist, bei Unicodezeichen weder von Buchstaben noch von Glyphen oder Graphemen zu sprechen, sondern von Code-Points.

Zu Zeiten der ersten Version von Unicode dachte man noch, dass 16 Bit reichen würden, um alle notwendigen Code-Points zu codieren, daher haben populäre Sprachen aus den 90er-Jahren wie Java und C# chars der Größe 16 Bit. Für die meisten Texte aus lateinischen Schriftsystemen stimmt das, sodass man als Entwickler*in aus Westeuropa oft fälschlicherweise annimmt, dass ein char einem Code-Point bzw. einem Buchstaben oder einer Glyphe entspricht.

Bei späteren Versionen von Unicode wurde schnell klar, dass man mehr als 16 Bit braucht, um die ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang