©melpomen, 123RF

Forscher der University of Michigan haben nach proprietären Vorbildern einen intelligenten persönlichen Assistenten aus freien Komponenten gebaut. Obwohl das Sirius-Projekt den Fokus auf die von der Software erzeugte Serverlast legt, hat sich das Linux-Magazin für den praktischen Nutzwert interessiert.

Was macht der Chefingenieur eines Raumschiffs im 23. Jahrhundert, wenn er einen Computer aus dem 20. Jahrhundert bedienen soll? Er nimmt die Maus in die Hand und spricht “Hallo, Computer” hinein – wie in “Star Trek IV: Zurück in die Gegenwart” (USA 1986). Während seiner Zeitreise musste Montgomery “Scotty” Scott dann schließlich trotzdem noch in die Tasten hauen.

Besitzer moderner Smartphones dagegen kommen mit »OK, Google« , »Hey, Siri« oder »Hey, Cortana« inzwischen recht weit – die Sprachassistenten verstehen viele in Alltagssprache formulierte Fragen oder Anweisungen. Man kann nur raten, welche Algorithmen hinter den proprietären Wunderwerken stecken.

Ganz anders bei dem intelligenten persönlichen und quelloffenen Assistenten Sirius [1], den die Forschergruppe Clarity Lab 2015 an der University of Michigan entwickelt hat. Die unter der BSD-Lizenz veröffentlichte Software bündelt die freien Spracherkennungssysteme CMU Sphinx [2] (Pocketsphinx und Sphinx4), Kaldi [3], eine Bilderkennung auf Basis von Open CV [4] und das Frage-und-Antwort-System Open Ephyra [5]. Die Datenbasis für Letzteres bildet ein Wikipedia-Dump. Mit Hilfe all dieser Komponenten ist Sirius in der Lage, eingetippte oder gesprochene Fragen zu beantworten sowie Gegenstände auf Bildern zu erkennen (Abbildung 1).

Abbildung 1: Sirius und die beteiligten Komponenten verarbeiten Bilder und gesprochene Anfragen.

Das Ziel der Software formulieren die Entwickler vom Clarity Lab in einem Abstract [6] zum Sirius-Tutorial, das während der “20. International Conference on Architectural Support for Programming Languages and Operating Systems” (ASPLOS-20) stattfand. Sie gehen davon aus, dass der Bedarf nach intelligenten persönlichen Assistenten (IPAs) künftig steigt und fragen sich, wie Serverarchitekturen aussehen müssen, um den Workload dieser Programme zu bewältigen. Da Open-Source-IPAs zum Ermitteln der Last fehlten, entwickelten sie Sirius, um die Ressourcen-Anforderungen realitätsnah darzustellen.

Wie schlagen sich Sirius & Co. im praktischen Einsatz? Taugen die Programme als Helfer auf dem Linux-Desktop? Diesen Fragen gingen die Tester nach und nahmen Sirius und seinen Nachfolger Lucida [7] unter die Lupe. Sie installierten die Software dazu unter Ubuntu 14.04 und Ubuntu 16.04, redeten mit der Sirius-Spracherkennung, befragten dessen QA-System und sichteten die Bilderkennung. Lucida ist noch nicht so weit – bisher funktioniert in der Demoversion lediglich ein einfaches Frage-und-Antwort-Spiel, an dem die Tester kurz teilnahmen.

Fertigbausatz

Die Clarity-Lab-Website [1] bietet im Downloadbereich Sirius, die Sirius-Suite und Sirius-Web als ein Archiv (»sirius-1.0.1.tar.gz« ) sowie den englischen Wikipedia-Dump für das Frage-Antwort-System (»wiki_indri_index.tar.gz« ) an (Abschnitt “Antworte mir”).

Nach dem Auspacken des Sirius-Archivs wechseln Anwender ins Verzeichnis »sirius-1.0.1/sirius-application« . Hier liegen dann einige Skripte, die die von Sirius vorausgesetzte Software einspielen, Komponenten aus dem Internet nachladen und diese kompilieren und installieren. Die Skripte sind für Ubuntu 14.04 geschrieben; wer auf die etwas ältere (aber noch bis 2019 unterstützte) LTS-Version setzt, gelangt mit den folgenden vier Befehlen ans Ziel:

sudo ./get-dependencies.sh
sudo ./get-opencv.sh
./get-kaldi.sh
./compile-sirius-servers.sh

Anwender, die das aktuelle Ubuntu 16.04 nutzen, passen zuvor das Skript »get-dependencies.sh« im Texteditor an und kommentieren den Eintrag zum Hinzufügen des externen Ffmpeg-Repository (»ppa:kirillshkrogalev/ffmpeg-next« ) aus. Die externe Paketquelle ist nicht länger erforderlich, denn Ffmpeg steht in den offiziellen Xenial-Repositories.

Danach führen Nutzer die ersten drei Befehle des letzten Listings aus. Bevor sie »./compile-sirius-servers.sh« aufrufen, setzen sie einen symbolischen Link von »/usr/bin/libtoolize« auf »/usr/bin/libtool« , weil das Kaldi-Makefile nach diesem Binary sucht.

Eine schnelle Internetanbindung ist von Vorteil, denn die Skripte laden jede Menge Software aus dem Internet nach. Beim Open-CV-Download wandern rund 3  GByte auf die Platte, Kaldi belegt 2  GByte. Das Sirius-Archiv selbst ist 470  MByte groß und der bereits angesprochene Wikipedia-Dump sogar 11  GByte. Fertig eingerichtet belegen Sirius & Co. etwa 25  GByte Plattenplatz.

In dem Verzeichnis »sirius-application/run-scripts« liegen die Skripte, welche die Spracherkennung, die Bilderkennung und das Frage-Antwort-System auf den Plan rufen. Alle drei Komponenten sind als Serverdienste implementiert. In diesem Ordner befinden sich ebenfalls die Skripte, mit denen Anwender ihre Wünsche an die Server richten; diese tragen den Zusatz »test« im Namen.

Hör gut zu

Im ersten Versuch fütterten die Tester die Sirius-Spracherkennung (Automatic Speech Recognition, ASR) mit ein paar der in »sirius-1.0.1/sirius-application/inputs/questions« hinterlegten Wave-Dateien. Sie starteten dazu in einem Terminal den ASR-Server nacheinander mit einem der drei verfügbaren Backends (Kaldi, Pocketsphinx und Sphinx4):

./start-asr-server.sh kaldi
./start-asr-server.sh pocketsphinx
./start-asr-server.sh sphinx4

In einem zweiten Terminal riefen sie dann das Skript »sirius-asr-test.sh« zusammen mit einer Frage auf und sahen dort, was bei Sirius ankam (Abbildung 2). Das klappte manchmal gut, manchmal erst nach einiger Wartezeit und manchmal gar nicht – so schlug die Kommunikation mit Sphinx4 unter Ubuntu 16.04 komplett fehl. Zum Vergleich nahmen die Tester die Sätze selbst per Mikrofon auf und schickten sie an alle drei Backends. Tabelle 1 zeigt anhand von fünf Beispielsätzen, was Kaldi, Pocketsphinx und Sphinx4 verstanden haben.

Abbildung 2: Anwender senden Wave-Dateien an die Sirius-Spracherkennung und sehen dann in der Ausgabe, was das Backend verstanden hat.

Die Qualität der Texterkennung ist sehr durchwachsen: Bei den mitgelieferten Wave-Dateien arbeitete nur das Sphinx4-Backend fast fehlerlos. Im Test mit eigenen Aufnahmen bleiben richtig erkannte Sätze dagegen eine seltene Ausnahme. Möglicherweise haben die Entwickler ihre Spracherkennungs-Libraries vor allem mit den beigelegten Dateien trainiert, die durchweg in amerikanischer Aussprache vorliegen. Mit den eigenen Aufnahmen (British English mit deutschem Akzent) kam vor allem Sphinx4 gar nicht klar – die anderen Engines erkannten wenigstens einzelne Wörter.

An der Audioqualität sollte das mangelnde Verständnis nicht gelegen haben, denn es kam ein gutes Gesangsmikrofon zum Einsatz. Stichprobenartig nahmen die Tester ihre Sätze mit einem Headset und einem anderen Frequenzgang auf. Diese lieferten aber noch schlechtere Ergebnisse. Die Google- und Apple-Spracherkennungen auf den Smartphones der Tester erkannten jedenfalls fast alle Fragen (siehe nächster Abschnitt).

Antworte mir

Hat der Assistent die Frage richtig verstanden, wäre es schön, wenn er sie auch beantworten könnte. Die Sirius-Entwickler setzen dazu das Frage-Antwort-System Open Ephyra [5] ein.

Als Datenbasis dient ein Wikipedia-Dump ohne semantische Auszeichnungen. Die Entwickler haben ihn mit Indri [8] erzeugt, also einer auf große Textkorpora spezialisierten Suchmaschine. Anwender laden das Wikipedia-Tar.gz-Archiv von der Sirius-Downloadseite herunter und entpacken es ins Verzeichnis »sirius-application/question-answer« .

Danach starten sie den QA-Server über das Skript »start-qa-server.sh« aus dem Verzeichnis »sirius-application/run-scripts« . Auf dem Ubuntu-16.04-Testrechner klappte das nicht ohne Weiteres. Hier war der Aufruf von »ant« im Verzeichnis »sirius-application/question-answer« nötig, bevor der Server seine Arbeit aufnahm. Wer nach dem Aufruf von »./start-qa-server.sh« eine Warnung über »insufficient threads configured« erhält, kann diese mit einem einfachen Hack beheben und in der Datei »sirius-application/question-answer/src/info/ephyra/OpenEphyraServer.java« diese Zeile auskommentieren:

con1.setThreadPool(new QueuedThreadPool(NTHREADS));

Danach ist es erforderlich, das Skript »compile-sirius-servers.sh« noch einmal aufzurufen und auch den QA-Server neu zu starten.

In einem zweiten Terminal stellen Benutzer ihre Fragen, beispielsweise so:

./sirius-qa-test.sh "what is the speed of light"

Nach einer Bestätigung, dass die Frage angekommen ist, erscheint eine Meldung, dass die Frage zum Server wandert. Nach kurzer Wartezeit taucht im Terminal die Antwort auf (Abbildung 3).

Abbildung 3: In einem Terminalfenster läuft der Open-Ephyra-Server, im anderen geben Benutzer ihre Frage ein. Nach kurzer Zeit erscheint hier auch die Antwort.

Gesprochene und getippte Fragen sind möglich – eigentlich wäre es schön, wenn man diese auch noch kombinieren könnte. Mit Sirius ist das kein Problem. Anwender starten dazu einfach neben dem QA-Server zusätzlich den ASR-Dienst und nutzen zur Kommunikation das Skript »sirius-asr-qa-test.sh« :

./sirius-asr-qa-test.sh ../inputs/real/who.is.the.current.president.of.the.united.states.wav

Je nach ASR-Backend dauert die Analyse dann an. Nachdem dieser Teil erfolgreich die Frage transkribiert hat, benötigt der QA-Dienst allerdings noch einige Zeit, um die Antwort zu finden – hier ist also Geduld gefragt.

Vage Auskunft

Open Ephyra geht über eine reine Schlagwortsuche hinaus. Das System findet Antworten, die nicht wörtlich im Wikipedia-Text stehen. Vereinfacht gesagt analysiert und klassifiziert Open Ephyra sowohl die Fragen als auch die in Textform vorliegende Datenbasis. So hat es zu der Frage “Who wrote Hitchhikers Guide?” die passende Antwort “Adams” parat. Wer sich für den genauen Aufbau interessiert, findet unter [9] eine schematische Darstellung der zugrunde liegenden Architektur.

Die Tester ließen insgesamt zwölf Fragen aus verschiedenen Wissensgebieten auf Sirius los. Zum Vergleich befragten sie die beiden proprietären Konkurrenten Google Now und Apples Siri. Die Ergebnisse, die Tabelle 2 zusammenfasst, deklassieren das Frage-und-Antwort-System in Sirius leider als nette Spielerei ohne großen praktischen Nutzen. Der Open-Source-Assistent landet zwar einige Achtungstreffer, die vor dem Hintergrund einer nicht semantisch oder ontologisch erschlossenen Datenbasis Respekt abnötigen. Für einen verlässlichen Helfer im Alltag reicht die Tefferquote aber beileibe nicht aus.

Bei der Gegenüberstellung mit Google Now unter Android und Siri auf dem iPhone ist zu bedenken, dass dort offensichtlich viele Antworten in bezahlter redaktioneller Arbeit vorbereitet sind. Wer wüsste besser als Google, welche Fragen Anwender häufig stellen? Auch die oft betonte “Persönlichkeit” von Apples Assistent entspringt kaum maschineller Intelligenz, sondern sorgfältiger menschlicher Planung. Da Open Ephyra bei einigen Fragen sehr weit danebenliegt und die Software auf modernen Linux-Distributionen offenbar schwer zu kompilieren ist, denken die Entwickler für Lucida bereits über Alternativen nach [10].

Schau genau hin

Die Bilderkennung braucht eine Datenbank mit Merkmalen bekannter Bilder, bevor sie ihren Dienst aufnehmen kann. Anwender wechseln dazu in den Ordner »sirius-application/image-matching« und rufen das Skript »make-db.py« auf. Es akzeptiert den Namen der Datenbank (»landmarks« ) und das Verzeichnis der Bilder (»matching/landmarks/db« ) als Parameter:

./make-db.py landmarks matching/landmarks/db

Der Name der Datenbank steht hartkodiert im Startskript »start-imm-server.py« . Wer also einen anderen Bezeichner als »landmarks« wählt, muss das Skript entsprechend anpassen.

Der Befehl »./start-imm-server.sh« , aus dem Verzeichnis »run-scripts« aufgerufen, fährt den Bilderkennungs-Server hoch. Danach akzeptiert »sirius-imm-test.sh« eine Bilddatei als Parameter. Der Name des erkannten Objekts erscheint in der Terminalausgabe.

Die Tester fügten zum Vergleichen ein paar eigene Bilder zur Datenbank hinzu. Sie nutzten dazu Fotos vom Dienst Freeimages [11] und wählten Abbildungen von Gebäuden aus, die den Testbildern von Sirius ähnelten. Bei einigen Aufnahmen war die Perspektive leicht verändert – und es wurde schnell klar: Das Image Matching funktioniert nur, solange der Aufnahmestandort fast gleich ist. Gegen Sirius und das zugrunde liegende Open CV traten Google Goggles [12] unter Android und die App Camfind [13] auf einem iPhone an. Abbildung 4 zeigt das Ergebnis.

Abbildung 4: Wer der Sirius-Bilderkennung Bilder aus unterschiedlichen Blickwinkeln vorlegt, hat wenig Freude damit. Lediglich Google Goggles war fast fehlerfrei.

Bisher waren nur die einzelnen Sirius-Komponenten in Aktion zu sehen. Von einem persönlichen Assistenten à la Google Now, Siri oder Cortana ist die Software damit noch weit entfernt. Wer nach einem handlichen Gesamtprodukt sucht, kann die Dienste natürlich per Shellskript miteinander kombinieren.

Bildet ein Team

Eine andere Möglichkeit ist der von den Entwicklern im Ordner »sirius-web« beigelegte Python-basierte Webserver. Die zugehörige Readme-Datei enthält leider noch eine veraltete Information zu den Abhängigkeiten – die benötigte Software wandert bereits per »pip install« aus dem erwähnten Skript »get-dependencies.sh« auf die Platte.

Während der Start unter Ubuntu 14.04 gelang, sah es auf dem aktuellen System mau aus, die Tester konnten Sirius-Web nicht in Betrieb nehmen. Allerdings bereitete der Dienst auch unter Trusty Tahr wenig Freude. Während die Anzeige im Browser noch klappte (Abbildung 5), war eine Interaktion über die Schaltflächen nicht möglich.

Abbildung 5: Das bei Sirius mitgelieferte Webfrontend im Verzeichnis »sirius-web« hat im Test leider nicht funktioniert.

Out of the Box

Dass Sirius nicht weiterentwickelt wird, war Anlass genug, einen Blick auf den Nachfolger Lucida [7] zu werfen. Da das Kompilieren aus den Quellen [14] im Test nicht gelang, entschieden sich die Tester für die Docker-Container, die eine abgespeckte Demoversion enthalten. Nach dem Installieren von »docker« und »docker-compose« rufen Benutzer nacheinander folgende zwei Befehle auf:

sudo docker pull claritylab/lucida:latest
sudo docker pull claritylab/lucida-asr

Dabei wandern zirka 17  GByte auf die Platte. Danach betreten Benutzer den Hauptcontainer mit diesem Kommando:

sudo docker run -i -t  claritylab/lucida /bin/bash

Im Stammverzeichnis liegt die Datei »docker-compose.yml« , sie ist zum Starten der Demoversion auf dem Hostsystem erforderlich. Anwender kopieren ihren Inhalt am besten in die Zwischenablage und fügen ihn nach dem Verlassen des Lucida-Containers mit »exit« in eine neue Datei »docker-compose.yml« ein. Aus demselben Verzeichnis heraus starten sie dann alle Lucida-Dienste:

sudo docker-compose up

Die Entwickler empfehlen, das Lucida-Webinterface (»http://localhost:8081« ) mit dem Browser Chrome oder der freien Variante Chromium zu nutzen. Ein Wikipedia-Daten-Dump ist beim Nachfolger nicht dabei. Vielmehr fragt das Webfrontend nach einem Text, der die Faktenbasis für das Frage-Antwort-System bildet. Den geben Anwender selbst ein und klicken dann auf »Submit« .

Lucida fragt anschließend nach den Zugriffsrechten für das Mikrofon, denn die Demoversion kommuniziert ausschließlich per Sprache. Anwender klicken dazu auf das Mikrofon-Symbol und sprechen ihre Frage. Im Hintergrund arbeitet Kaldi und versucht den Text zu verstehen. Das Ergebnis erscheint in der linken Sprechblase, die Antwort rechts daneben (Abbildung 6).

Abbildung 6: Das neue Lucida-Webfrontend funktioniert in Chrome und Chromium. Es nimmt Fragen der Benutzer per Mikrofon auf, doch die Qualität der Antworten bleibt durch die Spracherkennung Kaldi begrenzt.

Wie schon bei den Sirius-Experimenten mit Kaldi (Tabelle 1), gelang es im Test auch in diesem Fall nur mit großen Schwierigkeiten, einen halbwegs richtig erkannten Satz zu diktieren. In der Docker-Ausgabe ist es nicht möglich, Fragen per Tastatur ans System zu schicken, eine Bilderkennung fehlt ebenfalls.

Das Spracherkennungs-Backend Kaldi auszutauschen ist nicht vorgesehen, sodass die Tester auch nicht mit Pocketsphinx oder Sphinx4 experimentieren konnten. Im Github-Repository geben die Entwickler an, gegen Ende des Sommers 2016 die nächste [15] Lucida-Generation zu veröffentlichen. Neben einer neuen Kommandozentrale sollen dann vor allem ein verbessertes Frage-Antwort-System und eine Anleitung, wie Anwender einzelne Komponenten austauschen, beiliegen.

Künftige Helfer

Als ernsthafte Unterstützung im Alltagsleben taugen Sirius, Lucida & Co. noch nicht, Linux-Anwender müssen wohl noch eine Weile warten, bis sie sinnvolle Antworten oder echte Hilfe von einem digitalen Assistenten erhalten. Dass die Leistung der freien Programme noch weit hinter kommerziellen Alternativen zurückbleibt, liegt aber vermutlich nicht an einer schlechteren Qualität der Software. Firmen wie Google oder Apple haben ohne Frage viel Geld in den Trainingsaufwand investiert, der etwa bei der Spracherkennung in stupiden Arbeiten wie stundenlagen Aufnahmen und phonetischer Transskription besteht.

Prinzipiell können Anwender auch die freien Komponenten schulen und an die eigene Stimme gewöhnen. Dafür sind allerdings linguistische Kenntnisse und vor allem Sitzfleisch gefragt.