Wie Anleitungen sprechen lernen

Bereits seit Jahren helfen uns Chatbots auf Webseiten weiter. Spätestens 2011 mit Einführung von Apples Siri übernehmen zusätzlich Sprachassistenten häufig kleinere Aufgaben. Chatbots oder Sprachassistenten wie Alexa, Google Assistant oder Siri helfen uns inzwischen bei kleineren Alltagsaufgaben: Der nächste Termin beim Zahnarzt wird in den Kalender diktiert, die Wettervorhersage oder das Geburtsdatum von Louis de Funès abgefragt, die Lieblingsplaylist gespielt oder in einer fremden Stadt der Weg zum nächsten Hotel oder zur nächsten Tankstelle abgefragt. Dieser niederschwellige Zugang und die inzwischen erstaunliche Zuverlässigkeit, gesprochene Sprache zu verstehen, bringt Sprachassistenten in den Kreis der Technologien, die eine Schlüsselrolle für das Internet der Dinge (Internet of Things, IoT) und Industrie 4.0 einnehmen. Dadurch wird es Schnittstellen zur Technischen Kommunikation geben.

Sicherlich kann sich nicht jeder damit anfreunden, dass diese Technologie Sicherheitslücken hat und eine Verbindung vom Wohnzimmer oder aus der Werkhalle zu den Servern der Silicon-Valley-Konzerne aufbaut. Alternativen zu den Produkten von Apple, Google oder Amazon und deren Anbindung an externe Server sind allerdings dünn gesät. Denn die Rechenleistung, die komplexe Sprachverarbeitung und Künstliche Intelligenz erst ermöglicht, können Offline-Endgeräte meist nicht erzielen.

Wer hätte zudem vergleichbare Datenmengen zur Verfügung, um eine Spracherkennung kontinuierlich zu trainieren? Eine beeindruckende Präsentation über den aktuellen Stand der Dinge lieferte Sundar Pichai, CEO von Google LLC. Bei der diesjährigen Entwicklerkonferenz I/O zeigte Pichai, wie Google Assistant beispielsweise bei einem Friseur anruft und mit einem Menschen einen Termin aushandelt [1].

Wer spricht denn da?

Eine umfassende Übersicht über die Anbieter von Sprachassistenten oder der Softwaresysteme, um solche Assistenten zu bauen, fällt ohne Anforderungskatalog schwer. Schaut man sich die Plattformanbieter der Sprachassistenten an, die theoretisch für jeden zugänglich sind, so stößt man auf altbekannte Größen der IT-Welt: Apple stellt auf Geräten mit seinem Betriebssystem iOS seit 2011 Siri bereit. Google Assistant ist seit 2016 für Geräte verfügbar, auf denen das Google-Betriebssystem Android läuft oder sich die Google-Assistant-App installieren lässt. Ebenfalls auf nahezu allen Plattformen und den eigens entwickelten smarten Lautsprechern lässt sich Alexa von Amazon nutzen. Windows stellt dem Benutzer Cortana zur Seite und auf verschiedenen Wegen lassen sich auch Sprachassistenten mit Watson von IBM aufbauen.

Alle Anbieter haben zwei Dinge gemeinsam: Erstens bieten sie ihren Kunden Plattform und Infrastruktur, um die einzelnen Dienste zu nutzen. Zweitens ermöglichen sie anderen Unternehmen, deren Dienste auf ihrer Plattform bereitzustellen. Dazu bieten die Anbieter Schnittstellen oder eigene Softwaresysteme, um Sprachassistenten erstellen und publizieren zu können.

Wie funktioniert ein Sprachassistent?

Wenn auch der Erstellungsprozess eines Sprachassistenten je nach Plattform und Einsatzszenario natürlich immer etwas anders aussieht, lässt sich eine allgemeine Funktionsweise skizzieren (Abb. 01).

Der Nutzer startet den Sprachassistenten und sagt zum Beispiel „Hallo“ oder stellt eine Frage. Die Spracherkennung versucht nun, die Aussage oder Frage zu transkribieren, was je nach Umgebungsgeräuschen oder auch Dialekt schwierig sein kann. Hier liegt der erste Unterschied zu einem Chatbot, der lediglich geschriebene Sprache versteht. Das können zwar die meisten Sprachassistenten auch. Allerdings versuchen sie vielmehr mit der transkribierten Aussage herauszufinden, was der Nutzer möchte. Man spricht hier auch von Natural Language Processing (NLP) oder Natural Language Understanding.

Ist die Absicht des Nutzers nun bekannt, der „Intent“ („Intention“, „Absicht“ oder „Vorhaben“), wird nach einer passenden Reaktion gesucht. In unserem Beispiel könnten wir dem Sprachassistenten beigebracht haben, dass „Hallo“ eine Begrüßung sei. Nun haben wir dem Sprachassistenten vielleicht mitgegeben, dass er bei einer Begrüßung zunächst den Namen des Nutzers herausfinden soll. Da der Nutzer seinen Namen noch nicht genannt hat, fragt der Sprachassistent: „Hallo, wie ist dein Name?“.

Antwortet der Nutzer mit „Christopher“, kennt der Sprachassistent nun den Namen und begrüßt ihn mit „Hallo Christopher, schön dich kennenzulernen!“ (Abb. 01). Antwortet der Sprachassistent, zeigt sich die zweite Abgrenzung zu einem Chatbot: Der Text wird dank Text-to-Speech-Algorithmus gesprochen und nicht nur auf einem Bildschirm ausgegeben.

Der Sprachassistent wird also mit möglichst vielen Anliegen und gewünschten Reaktionen trainiert. Ob die Antwort direkt gegeben, nur ein Link präsentiert oder eine andere Datenquelle angefragt wird, ist für das Funktionsprinzip zunächst unerheblich und eher eine Frage des gewünschten Anwendungsfalls.

Abb. 01 Beispielhafter Aufbau eines Intent – auch Intention bzw. Absicht. Quelle Christopher Rechtien

Welche Verbindung ist vorhanden?

Die Technologie scheint also auch für den Kontext von Service- und Nutzerinformationen geeignet. Das Thema Sprachassistent ist in der Technischen Redaktion also richtig aufgehoben, denn hier liegt oft die Schaltzentrale der benötigten relevanten Informationen. Zielgruppen analysieren und Informationen nutzergerecht aufbereiten, zählt zudem von Haus aus zu den Kernkompetenzen Technischer Redakteure.

Aber wie genau kann ein Sprachassistent Benutzern helfen? Spielt man es gedanklich durch, wird schnell deutlich, dass vorgelesene Handlungsanweisungen kaum hilfreich sind: Ohne Grafiken im Dokument oder eine Smart Glass mit Augmented Reality fehlt der Bezug vom Handlungsschritt zum realen Objekt. Zudem dürften die wenigsten Handlungsanweisungen derzeit so formuliert sein, dass sie sich direkt dazu eignen, vorgelesen zu werden. Gezielt nach Anschlusswerten oder möglichen Produktionsparametern zu fragen, könnte schon hilfreicher sein. Auch eine verständliche „Übersetzung“ für den numerischen Fehlercode zu bekommen, kann Zeit sparen. In einem Frage-Antwort-Szenario einen technischen Defekt schnell einzugrenzen und zu identifizieren, könnte sogar ein Anwendungsfall sein, der den Aufwand für einen Sprachassistenten möglicherweise allein rechtfertigt.

Womit soll man anfangen?

Oftmals gibt es nicht den einen universellen und richtigen Weg, um eine Technologie einzuführen. Das ist natürlich auch bei Sprachassistenten so. Im Folgenden sollen daher drei mögliche Phasen vorgestellt werden, mit denen ein Sprachassistent für Service- und Nutzerinformationen eingeführt werden kann. Im ersten Schritt werden dabei die Anwendungsfälle ermittelt und der Sprachassistent konzipiert – Design the Bot. Während der zweiten Phase wird der Sprachassistent mit Leben erfüllt – Build the Bot. Die dritte und letzte Phase soll dazu dienen, den Sprachassistenten einsatzfähig zu machen. Hier wird gezielt getestet und nachjustiert, bevor und nachdem der Sprachassistent veröffentlicht wurde – Beat the Bot.

Phase 1 „Design the Bot“

Die Basis aller Technologieeinführungen sollten ein Konzept und ein realistischer Projektplan sein – getreu dem Projektmanagement-Slogan: „Wenn ich wenig Zeit habe, nehme ich mir viel davon am Anfang“. Im Falle eines Sprachassistenten dominieren zwei Fragen, die im Konzept übergeordnet geklärt werden sollten:

• Wie sehen unsere Anwendungsfälle oder die unserer Kunden für einen Sprachassistenten aus?
• Was fragt die Zielgruppe?

Erst wenn durch die Antworten auf diese beiden Fragen die Menge an Lösungen eingegrenzt ist, lassen sich konkrete Aussagen zu Technologie und Umsetzung treffen. Werden einfache Frequently Asked Questions (FAQ) beantwortet oder bekommt der Nutzer am Ende Links zurück, die die Lösungen in einem passwortgeschützten Content-Delivery-Portal zeigen, dann dürfte nichts gegen Google oder Alexa sprechen. Gebe ich hingegen sensible Daten über den Sprachassistenten preis, kann es sinnvoll sein, den Assistenten doch mit einer Software umzusetzen, die auf eigener Infrastruktur läuft.

Entscheidende Anwendungsfälle finden

Technologien sind nur Mittel zum Zweck, selten alleinige Lösung; oft sind sie aber Bestandteil davon. Das so genannte Technology Dropping, also das Brainstorming über potenzielle Technologien als Heilsbringer, ist nicht hilfreich. Genauso wenig bringt es, Details der Technologien zu diskutieren, bevor der anzustrebende Nutzen klar ist.

Bevor Lösungen genau definiert werden, sollten zunächst die Herausforderungen der Kunden und der Nutzer – falls die Nutzer nicht die Kunden sind – identifiziert werden. Diese Herausforderungen bilden die Basis für die Anwendungsfälle unseres Sprachassistenten.

Ein Anwendungsfall für einen Servicetechniker in einer Windenergieanlage könnte beispielsweise so aussehen: Der Techniker muss sich für jeden Anlagentypen die Anzugsmomente bestimmter Bolzen aus der Technischen Dokumentation heraussuchen und merken. Dann kriecht er zum schwer zugänglichen Bauteil, wartet es und muss die Bolzen mit dem entsprechenden Anzugsmoment anziehen, falls er das Anzugsmoment in der Zwischenzeit nicht vergessen hat. Könnte er stattdessen mit einem Headset nach den Anzugsmomenten oder anderen Parametern für die spezifische Anlage fragen, würde der Serviceeinsatz vielleicht 15 Minuten kürzer ausfallen. Eine geringe Ersparnis, die sich natürlich für ein ganzes Serviceteam und einen Windpark entsprechend auszahlt. Schon haben wir einen möglichen Anwendungsfall identifiziert.

Der Effizienzgewinn bringt einen Mehrwert für den Kunden, da sich aus der regulären Technischen Dokumentation zusätzlich eine digitale Dienstleistung entwickeln lässt. Für diesen Prozess, angefangen beim Identifizieren der Herausforderungen bis letztlich zum Entwickeln und Bereitstellen von Dienstleistungen, stehen verschiedenste Herangehensweisen bereit: Design Thinking for Industrial Services (DETHIS) oder die DIN SPEC 33453 „Entwicklung digitaler Dienstleistungssysteme“, die dieses Jahr erscheinen wird [2, 3].

Zielgruppenanalyse neu denken

In der Aus- und Weiterbildung Technischer Redakteure ein wichtiges Thema, in der Praxis aber leider zu wenig angewandt, avanciert die Zielgruppenanalyse bei Sprachassistenten zur elementaren Herausforderung und Weiche zwischen Erfolg und Misserfolg. Die Gründe hierfür liegen auf der Hand: Ein Sprachassistent kann nur das wirklich gut verstehen, was wir ihm beibringen. Haben wir kein realistisches Bild davon, was die Benutzer später wirklich fragen und welche Begriffe sie verwenden, dann kann ein Sprachassistent keine Antworten geben. Der notwendige Vertrauensvorschuss ist so schnell verspielt und eine zweite Chance zu bekommen, ist nicht gerade leicht.

Es gibt viele Mittel und Wege, um Zielgruppenanalysen durchzuführen, inklusive passender Fachliteratur und Vorgehensmodelle. Deshalb soll an dieser Stelle nicht allzu tief auf die Zielgruppenanalyse eingegangen werden. Die Rahmenbedingungen für eine Zielgruppenanalyse hängen immer auch von den Gegebenheiten des Kunden ab: Kann ich einen Vertreter der Zielgruppe bei seiner Aufgabe begleiten, kann ich ihn interviewen oder zumindest an einer Umfrage teilnehmen lassen oder bekomme ich Informationen nur aus zweiter oder dritter Hand? So können beispielsweise auch Service- oder Hotline-Anfragen ausgewertet oder in interdisziplinären Workshops Themen gesammelt und aufbereitet werden.

Für die Zielgruppenanalyse eines Sprachassistenten ist es besonders relevant, potenzielle Fragen der Nutzer möglichst im O-Ton zu erhalten. Nur so bekommt man eben genau die Fragestellungen und die Terminologie der Zielgruppe heraus. Eine Möglichkeit hierzu ist die Wizard-of-Oz-Methode. Dabei wird einem Benutzer ein Chatbot vorgegaukelt. Tatsächlich beantwortet ein versierter Techniker die Fragen im Chat. Mit dem Chatverlauf bekommt man eine gute Vorstellung davon, wie die Dialoge für den eigenen Sprachassistenten gestaltet sein sollten, um realistisch zu wirken.

Phase 2 „Build the Bot“

Der initiale Aufbau des Sprachassistenten ist sicherlich die arbeitsaufwendigste Phase. Wie die vorherigen Abschnitte hoffentlich zeigen, ist die Ausgestaltung dieser Phase stark von den ermittelten Use Cases und der ausgewählten Software abhängig. So ist es alleine eine Frage, wie facettenreich die Dialogmöglichkeiten ausgeschöpft werden sollen oder ob der Sprachassistent das Anliegen des Nutzers direkt an ein weiteres System übergibt, außerordentlich wichtig. Unabhängig von der ausgewählten Software müssen allerdings immer Dialoge in irgendeiner Form entworfen und die Sprache der Nutzer berücksichtigt werden; beide Aspekte beleuchten die folgenden zwei Abschnitte.

Vom Redakteur zum Dialogdesigner

Die Vorarbeiten sind gemacht: Die entscheidenden Anwendungsfälle und Zielgruppen stehen fest. Auch ist definiert, wie weit der Sprachassistent direkt Antworten geben und wann er besser verlinken soll. Vielleicht soll der Sprachassistent auch bestimmte Parameter vom Benutzer erfragen und damit eine andere Datenquelle ansprechen, die Antworten liefert. Das Konzept hält all das bereits fest (Abb.02).

Die Zielgruppenanalyse bildet die wichtigste Grundlage, um sinnvolle Dialoge für den Sprachassistenten zu entwerfen. Die Anliegen der Nutzer liegen möglichst umfassend gesammelt vor und können Funktions- oder Themenkomplexen zugeordnet werden (Abb. 02).

Wie „menschlich“ sich der Sprachassistent letztlich anfühlen soll oder muss, bietet sicherlich Potenzial für eine eigene Studienarbeit. Am Ende stehen wieder die Fragen nach der Zielgruppe und der Ausrichtung der Anwendung. Ein Mindestansatz für soziale Konversation sollte aber immer mit eingebaut werden. Unabhängig von seinem Zweck ist es beispielsweise sehr wahrscheinlich, dass der Sprachassistent nach seinem Namen oder seinen Fähigkeiten gefragt wird.

Abb. 02  Quelle Christopher Rechtien

Warum flache Dialogtiefe anstreben?

Von einigen Sonderfällen abgesehen, dürften die Gespräche mit Sprachassistenten eher kurz ausfallen. Besonders bei technischen Informationen, die der Benutzer im Normalfall möglichst schnell benötigt, ist eine flache Dialogtiefe eine Prämisse. Aus Sicht des Benutzers ist die geringste mögliche Dialogtiefe nach dem Muster <Frage Nutzer → Antwort VA> wahrscheinlich das Ideal (VA steht für Voice Assistant).

Doch selbst wenn man obligatorische Dialogebenen, wie beispielsweise <Anwendung aufrufen → Begrüßung> nicht berücksichtigt, reicht <Frage Nutzer → Antwort VA> meist nicht aus. Ein Beispiel: Fragt ein Kfz-Mechatroniker „Welches Anzugsmoment hat die Ölablassschraube?“, dann fehlt dem Sprachassistenten wahrscheinlich die Kontextinformation, für welchen Fahrzeugtypen die Information benötigt wird, und eine Rückfrage wird fällig. Wurde diese Kontextinformation nicht durch den vorhergehenden Dialog gegeben, lautet das Dialogmuster <Anwendung aufrufen → Begrüßung → Frage Nutzer → Rückfrage VA → Antwort Nutzer → Antwort VA>. Die Dialogtiefe sollte für die meisten Fälle ausreichen und im Sinne des Benutzers und des Pflegeaufwandes nicht unnötig überschritten werden.

Eine Ausnahme in Sachen flache Dialogtiefe bilden die so genannten Entscheidungsbäume, die an sich einen denkbaren Anwendungsfall erst möglich machen: die geführte Fehlersuche. Hierbei könnte der Fehlercode, den eine Maschine meldet, der Einstiegspunkt für einen Nutzer sein. Sukzessiv kann der Sprachassistent durch Rückfragen die Fehlerursache gemeinsam mit dem Nutzer eingrenzen und die passende Lösung finden. Dank anonymisierter Nutzerstatistiken können diese geführten Fehlersuchen später genau ausgewertet werden. So lässt sich das Produkt optimieren oder die Fehlersuche konsequent verbessern. Sind zum Beispiel die häufigsten Fehlerursachen identifiziert, aber technisch nur schwer vermeidbar, können sie zumindest bei der geführten Fehlersuche zuerst geprüft werden.

In einigen Programmen, mit denen sich Sprachassistenten erstellen lassen, müssen exemplarisch mögliche Nutzerfragen im Wortlaut angegeben werden. Künstliche Intelligenz lernt dann auf Basis dieser Beispielfragen und kann ähnliche Nutzerfragen in gewissem Umfang selbstständig zuordnen. Diese Trainingsfragen sind eine große Chance, den Sprachassistenten so zu bauen, dass er am Ende möglichst oft dem Nutzer eine passende Antwort geben kann. Diese Chance kann freilich nur mit einer möglichst konkreten vorhergehenden Zielgruppenanalyse umfassend genutzt werden.

Synonyme pflegen

Technische Redakteure wissen, wie wichtig eine einheitliche Terminologie ist: „Nenne gleiche Dinge immer gleich“, heißt es. Das ist bereits bei einer Technischen Dokumentation in einer Sprache irreführend, wenn die Funktionen eines Produkts über Seiten unterschiedlich benannt werden. Werden die Dokumente dann mit derselben Kreativität übersetzt, sind Unsicherheit und Frust der Benutzer vorprogrammiert. Terminologie spielt auch bei Sprachassistenten eine Rolle. Speziell sind hier die Synonyme interessant, die bisher bestenfalls als Suchhilfen im Dokumentindex oder als verbotener Begriff in der Terminologieliste stehen.

Die Benutzer sprechen ihre eigene Sprache und verwenden eigene Terminologie. Je nach Einsatzgebiet und Diversität der Zielgruppen können diese persönlichen oder milieuspezifischen Terminologien teils erheblich von der Terminologie in der Technischen Dokumentation abweichen. Dennoch muss der Sprachassistent die Synonyme kennen und verstehen. Bei Sprachassistenten werden die Terme als Entitäten (engl. Entities) verwaltet. Oft mit der eigentlichen Benennung und den möglichen Synonymen.

Je nach Anwendungsfall sollen genau diese Entities herausgefunden werden: Von welcher Baugruppe spricht der Nutzer und was will er damit tun? Mit den Antworten auf diese Fragen: „Welche Baugruppe?“ und „Was soll gemacht werden?“ kann der Sprachassistent dann bei einer anderen Datenquelle eine Anfrage stellen.

Phase 3 „Beat the Bot“

Sind die inhaltlichen Arbeiten vorerst abgeschlossen, sollte der Sprachassistent ausgiebig getestet werden, bevor er für seine Benutzer freigegeben wird. Die Erwartungen der Zielgruppen werden sicherlich hoch sein, so dass ein Vertrauensvorschuss die Folge ist. Er bietet die Chance, die Benutzer zu Fans und Multiplikatoren des Projekts zu machen.

Diese Chance lässt sich aber auch leicht verspielen. Das kann an technischen Kinderkrankheiten liegen oder weil der Sprachassistent Nutzerfragen nicht verarbeiten kann. Später hat der Sprachassistent im Vergleich zu anderer Software den Nachteil: Man sieht ihm nicht an, dass er möglicherweise hunderte Stunden nachgebessert wurde. Ist die Chance einmal verspielt, wird es schwer, sich das Vertrauen der Benutzer wieder zu erarbeiten.

Usability Test muss sein

Um praktische Probleme herauszufinden, bietet sich ein zweistufiger Usability Test an. Es sollte auf jeden Fall versucht werden, die Grenzen des Sprachassistenten auszutesten und so Schwachstellen zu identifizieren. Die Methodik kann je nach beteiligten Personen und verfügbaren Ressourcen vom Rahmen abweichen, der hier grob beschrieben ist:

Im Alpha-Test (Stufe 1) sollten zunächst die Intents zu den angedachten Themen ausgetestet werden: Funktionieren sie wie geplant? Muss die Künstliche Intelligenz mit weiteren Fragebeispielen trainiert werden? Solche Tests können im Zweifel die Ersteller selbst durchführen oder Kollegen, die in das Projekt eingeweiht sind.

Der Beta-Test (Stufe 2) sollte dann mit einer möglichst repräsentativen Anzahl von Vertretern der Zielgruppen stattfinden. Dabei sollten zumindest deren Nutzerstatistiken dezidiert ausgewertet und die Beteiligten interviewt werden. Bestenfalls decken sich die Erkenntnisse mit denen aus der vorangegangenen Zielgruppenanalyse. Schlimmstenfalls kann man rechtzeitig nachbessern, bevor jeder Zugriff bekommt.

Fähigkeiten klar kommunizieren

Zusammen mit der Veröffentlichung müssen die künftigen Benutzer auch über die Möglichkeiten informiert werden. Egal, wie gut der Sprachassistent gelungen ist – er wird auf absehbare Zeit nur einen Teil des Aufgabenbereichs abdecken können. Die Nutzer müssen wissen, was sie den Sprachassistenten fragen können und zu welchen Bereichen er Auskünfte gibt. Auch eine Kontaktmöglichkeit, an wen sie sich wenden können, wenn der Sprachassistent nicht macht, was er soll, oder Verbesserungsvorschläge aufkommen.

Im Training bleiben

Abhängig von der Systemlandschaft, die verwendet wird, stehen eine Reihe von Nutzerstatistiken zur Verfügung: Welche Fragen werden gestellt? Auf welche Fragen werden keine Antworten gefunden? Wie oft werden welche Funktions- oder Themenkomplexe genutzt? An welcher Stelle in geführten Fehlersuchen haben die Benutzer den Fehler identifiziert? Alle diese Fragen geben erheblich Aufschluss darüber, wie die eigenen Produkte genutzt werden und welchen Informationsbedarf die Zielgruppen haben.

Diesen Schatz an Erkenntnissen sollte man sich regelmäßig ansehen, um den Sprachassistenten weiter auszubauen und zu verfeinern. Solche Revisionen können in der ersten Zeit sogar wöchentlich stattfinden. Der fortlaufende Revisionsrhythmus sollte sich an den Nutzungszahlen orientieren, um entsprechend schnell auf die Rückmeldungen der Nutzer reagieren zu können.

Links zum Weiterlesen

[1] https://www.youtube.com/watch?v=D5VN56jQMWM

[2] www.dethis.de

[3] https://www.din.de/de/forschung-und-innovation/din-spec/alle-geschaeftsplaene/wdc-beuth:din21:285703329