Alexa, der Voice-Control-Service von Amazon, dürfte inzwischen zumindest aus Anwendersicht bekannt sein. Dass es sehr unterschiedliche Arten von Skills gibt, ist dagegen vielleicht nicht so bekannt. Dieser Artikel beschreibt die Learnings eines Entwicklers, der bisher noch nicht mit Alexa in Berührung gekommen war, und geht dabei auf die Entwicklung von Custom-Skills und Smart-Home-Skills ein, die Unterschiede zwischen den beiden Varianten und die Frage, wann man welchen Typus verwendet.
Bei einem Custom-Skill geben Entwickler*innen das Sprachmodell (Voice Interaction Model) genau vor, d. h. jeder einzelne Satz mit den entsprechenden Platzhaltern für Variablen muss definiert werden.
Bei einem Smart-Home-Skill entwickelt man nicht selbst das Sprachmodell (Voice Interaction Model) des Skills, sondern gibt die Fähigkeiten eines Geräts über klar definierte Schnittstellen an Alexa weiter. Alexa bestimmt, welche Sprachkonstrukte zum Steuern des Gerätes funktionieren.
Geht es bei dem Skill um die Steuerung eines Gerätes, sollten Entwickler*innen in der Regel zum Smart-Home-Skill greifen. Durch die klaren Vorgaben und Interfaces kann Letzterer allerdings auch nur für die Steuerung von Geräten verwendet werden. In anderen Anwendungsfällen, in denen Alexa nicht direkt mit Geräten interagiert, bleibt weiterhin der Custom-Skill das Mittel der Wahl. Dadurch, dass es Smart-Home-Skills noch nicht so lange gibt, gibt es auch aktuell noch viele Custom-Skill-Implementierungen für die Gerätesteuerung.
Interesse an den Details? Im Folgenden gehe ich auf die Eigenarten dieser beiden Skill-Typen genauer ein.
Der Alexa-Custom-Skill
Ein Custom-Skill besteht aus verschiedenen Intents. Dies sind die Befehle, die der Skill ermöglicht. Für jeden Intent definieren die Entwickler*innen die Sätze, durch die der Intent getroffen wird. Alexa erkennt die Sätze der User (Utterances), und ermittelt darüber den entsprechenden Intent.
Im folgenden Beispiel geht es um einen Skill namens „Supersaugrobots“, mit dem man Saugroboter steuern kann. Ein Satz, den der Nutzer sagen kann, ist:
Alexa, sage Supersaugrobots, starte Robbie in starkem Modus
Was sehen wir hier?
Dieser Satz wurde für einen bestimmten Intent definiert, in diesem Fall ein eigens definierter StartCleaningIntent, der dafür sorgen soll, dass ein Saugroboter mit dem Saugen startet. In diesem Satz befinden sich außerdem einige Variablen:
Alexa, sage {Skill-Name}, starte {Gerätname} in {Modus}
Den Satzteil „sage {Skill-Name}“ benötigt Alexa, um zu ermitteln, welcher Skill genau angesprochen werden soll. Inzwischen gibt es schon Bestrebungen bei Amazon, auch ohne Nennung des Skill-Namens auszukommen, aber diese sind zum Zeitpunkt der Veröffentlichung dieses Beitrags in Beta und nur in englischer Sprache verfügbar (Name Free Interaction ).
Danach startet der Satzteil, mit dem Alexa den Intent ermittelt. Die Platzhalter {Gerätname} und {Modus} sind Slots, deren Werte von Alexa als Slot Values zusammen mit dem ermittelten Intent ans Backend geschickt werden. Slots haben einen Datentyp (Slot Type). Für {Gerätname} ist ein Freitext sinnvoll, den man mit dem vorgefertigten Slot Type AMAZON.SearchQuery erhält. Für {Modus} empfiehlt es sich, einen eigenen Slot Type als Aufzählung zu definieren, in dem die möglichen Modi angegeben werden.
Learning: Der Slot Type
AMAZON.SearchQueryschreibt Zahlen im Suchbegriff aus. Wenn man ein Gerät R2D2 nennt, füllt Alexa den Slot{Gerätname}mit „r. zwei d. zwei“. Diesen wiederum im Backend auf das richtige Gerät zu mappen, ist eine nicht-triviale Aufgabe.
In der Regel definiert der/die Entwickler*in für einen Intent mehrere Sätze:
- Alexa, sage
{Skill-Name}, sauge mit{Gerätname} - Alexa, sage
{Skill-Name}, sauge in{Modus} - Alexa, sage
{Skill-Name}, Start - etc.
Dabei fällt hier auf, dass nicht jeder Satz alle Slots füllt. So fehlt in den Beispielsätzen zwei und drei der Gerätename, während in den Beispielsätzen eins und drei der Modus fehlt. Es gibt mehrere Strategien, diese nicht gefüllten Slots aufzufüllen. Diese müssen Entwickler*innen im Backend implementieren:
- Default: Falls beispielsweise kein
{Modus}übergeben wurde, könnte von einem „normalen Modus“ als Default ausgegangen werden. - Eindeutigkeit: Wenn kein
{Gerätename}übergeben wurde und der Benutzer nur ein Gerät hat, wird das eine Gerät gestartet. - Nachfrage: Wenn kein
{Gerätename}übergeben wurde und der/die Benutzer*in mehr als ein Gerät hat, kann Alexa nachfragen, welches Gerät gemeint ist.
Im Backend müssen die Requests angenommen und verarbeitet werden. Das Alexa Skills Kit SDK (in Java, JavaScript und Python ) unterstützt die Implementierung durch Interfaces und Hilfsmethoden erheblich. Eine zentrale Rolle spielt dabei das RequestHandler Interface, das jeweils eine canHandle und eine handle Methode vorgibt. Bei der Verarbeitung eines Requests wird die Kette der implementierten RequestHandler durchlaufen. Der erste Handler, der bei der Methode canHandle den Wert true zurückgibt, ist für die Verarbeitung verantwortlich. So ist es einfach möglich, unterschiedliche RequestHandler für unterschiedliche Intents zu implementieren (mehr zum Request-Handling hier ).
Der Alexa Smart-Home-Skill
Ein Smart-Home-Skill ist explizit dafür da, ein smartes Gerät über Alexa zu steuern. Das ermöglicht für das Sprachmodell eine andere Vorgehensweise.
Zunächst einmal sucht die Alexa App Geräte über eine Device Discovery, die vom Skill implementiert werden muss. So erhält Alexa Namen, Typen und Referenzen der Geräte. Die Discovery gibt auch die Fähigkeiten (capabilities) des Gerätes in Form von Interfaces an, die Entwickler*innen dann im Backend implementieren müssen .
Das Interface Alexa.PowerController sagt beispielsweise aus, dass das Gerät ein- und ausgeschaltet werden kann. Verbunden mit diesem Interface sind Direktiven (directives), in diesem Fall die Direktive TurnOn und die Direktive TurnOff. Für das Sprachmodell (Voice Interaction Model) sorgt nun Alexa selbst, indem sie diverse Varianten von Einschalten und Ausschalten unterstützt:
- Alexa, schalte
{Gerätname}ein - Alexa,
{Gerätname}aus - Alexa, starte
{Gerätname} - etc.
Wie man sieht, müssen hier Anwender*innen den Skill-Namen bei der Kommunikation mit Alexa nicht mehr angeben, was die Ansprache erheblich erleichtert. Allerdings können wir nicht das Verb „sauge“ für das Starten unseres Saugroboters verwenden, weil das Sprachmodell von Alexa vorgegeben ist und „sauge“ nicht im Sprachmodell des PowerControllers enthalten ist. Inzwischen bietet Amazon schon einige auf bestimmte Geräte spezialisierte, gerätenähere Sprachmodelle. Der Saugroboter wird allerdings zum Zeitpunkt des Schreibens dieses Artikels noch nicht unterstützt.
Direktive, Gerätname und Interface werden in einem Request an das Backend gegeben, in dem Entwickler*innen die Reaktion auf die Direktive implementieren .
Auch die Response auf die Discovery wird im Backend implementiert, so dass der/die Entwickler*in den Vorteil hat, im Skill selbst nur das Account Linking und den Typ Smart-Home-Skill konfigurieren zu müssen. Jegliche Erweiterungen, Unterstützung neuer Geräte, Unterstützung neuer Fähigkeiten, etc. werden nur im Backend implementiert, so dass der Skill selbst dafür nicht neu released werden muss.
Alexa unterstützt allerdings als Backend aktuell für Smart-Home-Skills nur AWS Lambdas, so dass man bei der Wahl der Infrastruktur stark eingeschränkt ist.
Die Informationen über die Capabilities der Geräte nutzt Alexa auch, um die Fähigkeiten in der Alexa-App darzustellen. In der Liste der Geräte bekommt unser Saugroboter mit dem PowerController Interface einen großen Einschaltknopf, über den Anwender*innen den Roboter ein- und ausschalten können. Außerdem kann man die Geräte nun Räumen zuordnen und in Routinen einbinden. All das ist mit einem Custom-Skill natürlich nicht möglich.
Learning: Der Gerätename wird von Alexa verwaltet.
Der/die Anwender*in kann in der Alexa App den Namen des Geräts ändern. Diese Änderung ist allerdings nur für Alexa gültig und wird nicht in das Ursprungssystem zurückgespielt.
Learning: Nicht beide Skill-Arten vereinen.
Wenn aus historischen Gründen schon ein Custom-Skill für die Gerätesteuerung existiert, klingt es erst einmal naheliegend, den Smart-Home-Skill im gleichen Skill unterzubringen. Das ist technisch möglich, für Anwender*innen allerdings sehr verwirrend, da die Bedienung sehr unterschiedlich ist.
Fazit / Empfehlung
Gerätesteuerung sollte mit einem Smart-Home-Skill implementiert werden. Gegenüber einem Custom-Skill ergeben sich die folgenden Vorteile:
- Anwender*innen müssen nicht bei jeder Ansprache den Skill-Namen nennen.
- Entwickler*innen müssen das Sprachmodell nicht selbst pflegen.
- Sie müssen den Skill selten releasen, da die vollständige Funktionalität vom Backend gesteuert wird.
- Man kann Geräte über die Alexa App steuern (ohne Voice).
- Man kann Geräte in Räume einordnen.
- Man kann Geräte in Routinen einbinden.
Nachteil eines Smart-Home-Skills ist das eingeschränkte Sprachmodell, das es aktuell zum Beispiel nicht erlaubt, den Saugroboter mit dem Verb „sauge“ zu starten. Durch die spezifischen Interfaces, die es inzwischen für immer mehr Gerätetypen gibt, und durch die Einführung von Semantics fällt dieser Nachteil immer weniger ins Gewicht.
Übrigens: Das Account-Linking, also das Verbinden eines Benutzer-Accounts mit dem Skill, ist in beiden Varianten identisch.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Flohre
4.10.2017 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Flohre
Senior Software Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.