Archive August 2017

Dies ist der zweite Beitrag einer Beitragsreihe auf diesem Blog, in der ich meinen Versuch beschreibe, eine eigene neuronale Engine für Maschinenübersetzung einzurichten. Im ersten Beitrag stellte ich mich und das Projekt vor.

Für die Einrichtung von neuronalen Netzen ist die richtige Wahl der Hardware ebenso wichtig wie die Wahl der Software und der Algorithmen, da das Training neuronaler Netze im Grunde aus einer Unzahl an Matrixmultiplikationen besteht, die am besten parallel erfolgen. Das ist auch der Grund für die raschen Fortschritte bei künstlichen neuronalen Netzen in den letzten Jahren, da aufgrund der Erfindung von LCD-Monitoren und der wachsenden Beliebtheit von Spielen mit virtueller Realität mehr und bessere dedizierte Grafikprozessoren (GPUs) auf den Markt gekommen sind. Das Konzept eines neuronalen Netzes ist nicht neu. Künstliche neuronale Netze wurden bereits in den 40er Jahren konzipiert. Bis vor Kurzem konnte man damit jedoch keine praktischen Aufgaben lösen, da normale CPUs mit seriellen Rechenvorgängen für die damit verbundenen Berechnungen nicht ausreichen. Erst die Markteinführung von ausreichend rechenstarken GPUs brachte den Durchbruch, da GPUs eigens für intensive parallele Rechenaufgaben und Matrixmultiplikationen konstruiert sind.

Aber ich schweife vom Thema ab. Dieser Beitrag befasst sich mit der Einrichtung der richtigen Hardware für ein neuronales Netz für maschinelle Übersetzung (NMÜ). Die Entwickler der verschiedenen Open-Source-NMÜ-Toolkits empfehlen eine leistungsstarke GPU mit mindestens 6 GB an dediziertem, internem GPU-Arbeitsspeicher. Deshalb habe ich sofort zugeschlagen, als mein lokaler Händler in Sachen Gadgets für Nerds, Fry’s, einen sogenannten Gaming-PC von Asus mit einer Nvidia GeForce GTX-1070-Grafikkarte mit 8 GB Grafikspeicher stark reduziert im Angebot hatte. Die 1070 ist eine Leistungsstufe niedriger als das derzeitige Top-Produkt von Nvidia, die GTX 1080 Ti, kostet jedoch nur ungefähr die Hälfte der 1080 Ti. AMD stellt mit seiner Radeon-Serie ebenfalls gute GPUs her, aber da dieser Asus-PC als Ausstellungsstück extrem günstig war, war die Wahl getroffen. Leider ist das BIOS von Asus mit seinen eigenen Problemen verbunden, die ich nun beschreiben werden. Wenn Sie also an den (allzu) technischen Details der Einrichtung des PCs interessiert sind, lesen Sie bitte weiter.

Auf dem PC war Windows 10 vorinstalliert, was aber für rechenintensive Anwendungen wie neuronale Netze eher ungeeignet ist. Alle oben erwähnten Open-Source-Toolkits laufen standardmäßig auf Linux. Ich entschloss mich, Windows 10 auf der Maschine zu belassen, da der PC ohne Installationsmedium geliefert wurde, obwohl ich nicht die Absicht habe, je auf dem Gaming-PC Computerspiele zu spielen. Deshalb partitionierte ich die Festplatte neu, was mit Windows 10 erstaunlich einfach war. Dann installierte ich mithilfe eines USB-Flashspeichers Ubuntu in einer Dual-Boot-Konfiguration. Anleitungen hierzu gibt es im Web zuhauf. Alles schien glatt zu laufen, bis ich bemerkte, dass Ubuntu nicht den Treiber von Nvidia verwendete, sondern einen anderen Treiber. Das verfehlt jedoch den ganzen Sinn der 1070-Karte, da dieser andere Treiber nicht alle Funktionen der Karte nutzen kann. Und damit begannen die Probleme.

Ich installierte also den neuesten Nvidia-Treiber für Ubuntu mit den folgenden Befehlen (lassen Sie „sudo“ weg, wenn Sie als root eingeloggt sind):

 
sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt-get update
sudo apt-get install nvidia-384

384 ist die neueste Treiberversion zum Zeitpunkt der Abfassung dieses Beitrags. Nach dem Neustart, um den Treiber zu aktivieren, begann die Sache jedoch schief zu laufen. Ich konnte mich nicht einloggen und wurde immer wieder zum Login-Bildschirm zurückgeworfen, egal, was ich versuchte.

Die Ursache des Problems schien die sogenannte Secure-Boot-Einstellung im Asus UEFI BIOS zu sein, die so viel Sinn macht wie ein Sandkasten in der Sahara. Diese Einstellung soll verhindern, dass Nicht-Windows-Betriebssysteme bestimmte Firmware verwenden, die vom Systemhersteller nicht geprüft wurde, auch wenn diese Firmware von einem Hersteller einer der Systemkomponenten stammt — in meinem Fall vertraut also Asus Nvidia nicht. Nach einem weiteren Neustart gelangte ich mithilfe von F2 ins UEFI BIOS zu den Secure-Boot-Einstellungen. Ich konnte die Funktion nicht deaktivieren, da „Enabled“ grau unterlegt und fixiert war. Also wählte ich stattdessen die Option „Other OS“ statt „Windows OS“, siehe die Screenshots unten. Dadurch löste ich zumindest eines der Probleme.

Boot-Einstellungen im Asus UEFI BIOS

Detailansicht der Boot-Einstellungen im Asus UEFI BIOS

Nach einem weiteren Neustart wurde ich von einem Bildschirm voller Fehlermeldungen über einen PCIe-Busfehler, pcieport usw. begrüßt, der ununterbrochen scrollte. Dazu wurden die Dateien syslog und kern.log mit ebendiesen Fehlermeldungen so vollgeschrieben, dass sie meine gesamte TB-Festplatte füllten und das System einfror. Hier schaffte die Einfügung einer weiteren Option in das Grub-Boot-Menü Abhilfe:

• Ich gelangte mit Strg + Alt + F1 zur Befehlszeile.
• Dort leerte ich die Dateien syslog und kern.log, die meine gesamte Festplatte füllten, mit den folgenden Befehlen:
  

   
  sudo truncate -s0 syslog
  sudo truncate -s0 kern.log

• Danach erstellte ich eine Sicherungskopie der grub-Datei und öffnete die Originaldatei folgendermaßen:
  

   
  sudo cp /etc/default/grub /etc/default/grub.bak
  sudo -H gedit /etc/default/grub

  In gedit ersetzte ich die Zeile

   
  GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”

  durch

   
  GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash pci=nomsi”

  MSI bedeutet Message Signaled Interrupts, die das System vor Einfrierungen bei Interrupts schützen sollen. Es ist jedoch bekannt, dass bestimmte Hardwarekombinationen MSI nicht unterstützen und das System dabei einfriert, was MSI eigentlich verhindern sollen. Scheinbar ist mein PC mit Asus-Motherboard mit Intel-Chipset und einer Nvidia GeForce-GPU auf Ubuntu 16.04 ein Beispiel dafür.

• Ich speicherte die bearbeitete grub-Konfiguration und verließ gedit. Danach aktualisierte ich grub und startete das System neu:

   
  sudo update-grub
  sudo reboot

Seither habe ich einige GPU-intensive Berechnungen (ohne künstliche neuronale Netze) durchgeführt und das System scheint stabil zu laufen. Keine überlaufenden Log-Dateien, keine PCIe-Fehler und keine Probleme beim Neustarten oder Einloggen. Die Windows-Seite scheint ebenfalls stabil zu sein.

Im nächsten Beitrag befasse ich mich mit der schwierigen Wahl des Toolkits — OpenNMT oder Tensorflow von Google?

Vor kurzem habe ich mit dem ambitionierten Projekt begonnen, meine eigene neuronale Maschinenübersetzungsengine einzurichten. Dieser Beitrag dient als Übersicht über die mit der Zeit veröffentlichten Blog-Beiträge.

• 28. August 2017: Vorwort – erläutert die Fragen nach dem „Wer“ und dem „Warum“
• 30. August 2017: Auswahl und Einrichtung der richtigen Hardware
• 12. September 2017: Überblick über Open-Source-Toolkits
• 3. Januar 2018: Neuronale Netze — eine Einführung

In letzter Zeit, wenn ich mich als Übersetzerin, genauer Patentübersetzerin vorstelle, werde ich immer häufiger gefragt, ob ich aufgrund der neuronalen Maschinenübersetzung (MÜ) nicht unter Existenzängsten leide. Normalerweise würde ich einfach auf den neuesten MÜ-Witz verweisen, der in sozialen Netzwerken die Runde macht, und die Sache wäre gegessen. Hier im Silicon Valley, wo selbstfahrende Autos, Drohnen und Roboter-Wachmänner zum Alltag gehören, ist das jedoch nicht ganz so einfach. Darüber hinaus hat das Europäische Patentamt das neue EU-Patent bekannt gegeben, dessen Einführung für Anfang 2018 geplant ist und Übersetzungskosten mithilfe von MÜ sparen soll. Derzeit sieht es jedoch so aus, als ob sich die Einführung verzögern wird.

Nichtsdestotrotz füllt sich auch mein Posteingang immer mehr mit Anfragen zur Nachbearbeitung von maschinell übersetzten Texten. Da ich auch beim Redigieren von von Menschen übersetzten Texten nicht besonders effizient bin, auch wenn die Übersetzung ausgezeichnet ist, bin ich wohl für die Nachbearbeitung von maschinell übersetzten Texten ungeeignet. Da habe ich einfach nicht den Nerv dafür. Deswegen hat sich vor einiger Zeit die folgende Idee in meinem Kopf festgesetzt: Ich will meine eigene neuronale Maschinenübersetzungs-Engine einrichten.

Das hört sich äußerst ambitioniert an, ist jedoch nicht unmöglich. Ich verfüge über jahrelange/jahrzehntelange Erfahrung mit höherer Mathematik (theoretischer Physik) und Computerprogrammierung. Außerdem gibt es mittlerweile mehrere Open-Source-Toolkits für neuronale MÜ, die man zusammen mit verschiedenen Libraries herunterladen kann, unterstützt von Diskussionsforen. Ich könnte also einfach eines dieser Toolkits herunterladen, das neuronale Netz mithilfe verschiedener Open-Source-Korpora trainieren und voila. Aber das wäre viel zu einfach! Und nicht sehr produktiv. Ich will das Netz an einen Punkt bringen, an dem ich es bei der täglichen Arbeit einsetzen kann. Außerdem will ich verstehen, wie die neuronale MÜ wirklich funktioniert, um vielleicht später, nach der maschinellen Apokalypse (die sicher noch weiter entfernt ist, als manche das behaupten) als Beraterin für neuronale MÜ anstatt als MÜ-nachbearbeitende Sklavin zu fungieren. Hierzu werde ich meine Erfahrungen auf diesem Blog dokumentieren. Da ich dieses ambitionierte Projekt nur neben der täglichen Arbeit mache, kann ich jedoch keine allzu regelmäßigen Beiträge versprechen, da der Fortschritt eben von der täglichen Arbeitslast abhängt. Auf keinen Fall wird es ein ‚Live-Blog‘, da ich den Leserinnen und Lesern beim Programmieren unerlässlichen österreichischen Kraftausdrücke ersparen will …

Ich begann mit diesem Projekt vor mehr als einem Jahr mit einem einführenden Kurs von Andrew Ng über maschinelles Lernen auf Coursera. Andrew Ng ist nicht nur einer der Mitbegründer von Coursera und Professor an der Stanford-Universität, er ist außerdem ein ausgezeichneter Vortragender. Er führte alle notwendigen Konzepte im Kurs ein, auf dem (für mich als Physikerin) gerade richtigen mathematischen Niveau mit nicht allzu viel Programmierarbeit (in der symbolischen Sprache MATLAB). Ich kann diesen Kurs als Einführung in das Thema ‚Künstliche Intelligenz‘ nur empfehlen. Allerdings behandelt Andrew Ng in seinem ausgezeichneten Kurs die maschinelle Übersetzung nicht. Nach diesem Kurs belegte ich mehrere Kurse über Robotik (auf Coursera) und künstliche Intelligenz (auf EdX) auf beginnendem Master-Niveau. Ich habe sogar einen autonom navigierenden Rover namens Boticelli konstruiert. Natürlich bin ich noch keine Expertin, aber ich weiß jetzt viel mehr über neuronale Netze und künstliche Intelligenz als der durchschnittliche Amateur. Im Herbst werde ich meine Erkenntnisse in einem Vortrag auf der 58. Jahreskonferenz der American Translators Association zusammenfassen.

Als Nächstes werde ich die notwendige Computer-Hardware kaufen und eines der Open-Source-Toolkits für neuronale MÜ auswählen. Für neuronale Netze braucht man dedizierte Hardware, genauer, hochwertige Grafikprozessoren (GPUs), da die Trainingsphase eines neuronalen Netzwerks praktisch aus sehr vielen Matrixmultiplikationen besteht. Dedizierte GPUs können eine große Anzahl an parallelen Rechenvorgängen ausführen, im Gegensatz zu CPUs, die für serielle Berechnungen am besten geeignet sind. Deshalb wird für eine NMÜ-Engine ein „Gaming-PC“ mit einer VR-fähigen Highend-Grafikkarte benötigt, da ironischerweise die Berechnungen für Computerspiele mit virtueller Realität und die für neuronale Netze für „seriöse“ Anwendungen wie maschinelle Übersetzung ziemlich ähnlich sind.

Mehr zu diesen nächsten Schritten im nächsten Beitrag. Bis zum nächsten Mal!