Application Programming Interfaces (APIs) spielen dank der Entwicklung von Technologien wie serviceorientierter Architektur, Cloud Computing und Internet of Things (IoT) sowohl in der virtuellen als auch in der physischen Welt eine immer wichtigere Rolle. Heute haben unsere Kollegen aus der Microsoft Research-Abteilung ihre Best Practices im Bereich Natural Language Interfaces (Natural Language Interfaces) ausgetauscht. Jetzt mitmachen!
Cloud-, Web-, Wetter-, Sport- und Finanz-Webdienste stellen Endbenutzern Daten und Dienste über die Web-API zur Verfügung, während IoT-Geräte anderen Geräten im Netzwerk ermöglichen, ihre Funktionen zu nutzen.
In der Regel werden APIs in verschiedenen Softwareprogrammen verwendet: Desktop-Anwendungen, Websites und mobile Anwendungen. Sie dienen Benutzern auch über eine grafische Benutzeroberfläche (GUI). Grafische Schnittstellen haben einen großen Beitrag zur Popularisierung von Computern geleistet, aber mit der Entwicklung der Computertechnologie werden ihre vielen Einschränkungen immer deutlicher. Wenn Geräte kleiner, mobiler und intelligenter werden, werden immer mehr Anforderungen an die grafische Anzeige auf dem Bildschirm gestellt, beispielsweise bei tragbaren Geräten oder Geräten, die an das IoT angeschlossen sind.
Benutzer sind auch gezwungen, sich an eine Vielzahl von grafischen Oberflächen zu gewöhnen, wenn sie verschiedene Dienste und Geräte verwenden. Mit zunehmender Anzahl verfügbarer Dienste und Geräte steigen auch die Kosten für die Schulung und Anpassung der Benutzer. Natural Language Interfaces (NLI) bieten ein erhebliches Potenzial als einziges intelligentes Tool für eine Vielzahl von serverseitigen Diensten und Geräten. NLIs verfügen über unglaubliche Funktionen zum Ermitteln der Benutzerabsicht und zum Erkennen von Kontextinformationen, wodurch Anwendungen wie virtuelle Assistenten für Benutzer wesentlich komfortabler werden.
Wir haben Schnittstellen in natürlicher Sprache für APIs (NL2API) untersucht. Im Gegensatz zu allgemeinen NLIs wie virtuellen Assistenten haben wir versucht zu verstehen, wie NLIs für einzelne Web-APIs wie die Kalenderdienst-API erstellt werden. In Zukunft können diese NL2APIs die API demokratisieren und den Benutzern helfen, mit Softwaresystemen zu interagieren. Sie können auch das Skalierbarkeitsproblem allgemeiner virtueller Assistenten lösen, indem sie eine verteilte Entwicklung ermöglichen. Der Nutzen eines virtuellen Assistenten hängt weitgehend von der Breite seiner Funktionen ab, dh von der Anzahl der unterstützten Dienste.
Die Integration von Webdiensten in einen virtuellen Assistenten ist jedoch unglaublich mühsam. Wenn einzelne Webdienstanbieter eine einfache Möglichkeit hätten, NLIs für ihre APIs zu erstellen, könnten die Integrationskosten erheblich gesenkt werden. Ein virtueller Assistent müsste nicht unterschiedliche Schnittstellen für unterschiedliche Webdienste verwalten. Es würde für ihn ausreichen, einfach einzelne NL2APIs zu integrieren, die dank der natürlichen Sprache Einheitlichkeit erreichen. NL2API kann auch die Entwicklung von Webdiensten, die Programmierung von Empfehlungssystemen und die Hilfe für die API erleichtern. Sie müssen sich also nicht die große Anzahl verfügbarer Web-APIs und deren Syntax merken.
Abbildung 1. Möglichkeiten zum Erstellen einer Schnittstelle in natürlicher Sprache für die API. Links: Traditionelle Methoden lehren Sprachwahrnehmungsmodelle, Absichten in einer natürlichen Sprache zu erkennen, andere Modelle lernen, mit jeder Absicht verknüpfte Zellen zu extrahieren und sie dann manuell mit API-Anforderungen abzugleichen. Richtig: Unsere Methode kann natürliche Sprache direkt in API-Anfragen übersetzen.Die Hauptaufgabe von NL2API besteht darin, Ausdrücke in der natürlichen Sprache des Benutzers zu erkennen und in eine API-Anforderung zu übersetzen. Genauer gesagt haben wir uns auf Web-APIs konzentriert, die in Anlehnung an die REST-Architektur, dh die RESTful-API, erstellt wurden. RESTful-APIs werden häufig in Webdiensten, Geräten für das Internet der Dinge sowie in Anwendungen für Smartphones verwendet. Ein Beispiel aus der Microsoft Graph-API ist in Abbildung 1 dargestellt.
Die linke Seite der Abbildung zeigt die traditionelle Methode zum Erstellen einer natürlichen Sprache, bei der wir Sprachwahrnehmungsmodelle lehren, um Absichten zu erkennen, und andere Modelle, um Zellen zu extrahieren, die jeder der Absichten zugeordnet sind, und sie dann manuell mit API-Anforderungen abgleichen, indem sie Code schreiben. Stattdessen können wir (wie auf der rechten Seite der Abbildung gezeigt) lernen, wie Ausdrücke aus einer natürlichen Sprache direkt in API-Anforderungen übersetzt werden. Im Rahmen der Studie verwenden wir unser System für APIs aus dem
Microsoft Graph API- Paket. Mithilfe von Microsoft Graph-Web-APIs können Entwickler auf produktivitätssteigernde Daten zugreifen: E-Mail, Kalender, Kontakte, Dokumente, Verzeichnisse, Geräte und mehr.
Abbildung 2. Mithilfe von Microsoft Graph-Web-APIs können Entwickler auf Daten zugreifen, die die Produktivität steigern: E-Mail, Kalender, Kontakte, Dokumente, Verzeichnisse, Geräte und mehr.Eine der Anforderungen für das Modell, das wir entwickeln, ist die Möglichkeit, eine detaillierte Benutzeroberfläche zu erstellen. Die meisten vorhandenen NLIs helfen den Benutzern nur wenig, wenn das Team nicht richtig erkannt wurde. Wir empfehlen, dass eine detailliertere Benutzererfahrung NLI erheblich komfortabler macht.
Wir haben ein modulares Modell entwickelt, das von Sequenz zu Sequenz arbeitet (siehe Abbildung 3), um eine detaillierte Interaktion mit NLI zu ermöglichen. Zu diesem Zweck verwenden wir eine Architektur, die nach dem Prinzip „von Sequenz zu Sequenz“ arbeitet. Gleichzeitig zerlegen wir das Ergebnis der Entschlüsselung in mehrere interpretierte Einheiten, die als Module bezeichnet werden.
Jedes Modul versucht, ein vorbestimmtes Ergebnis vorherzusagen, indem es beispielsweise einen bestimmten Parameter verwendet, der auf einer in NL2API empfangenen Anweisung basiert. Nach einem einfachen Vergleich können Benutzer das Prognoseergebnis eines Moduls leicht verstehen und auf modularer Ebene mit dem System interagieren. Jedes Modul in unserem Modell generiert konsistente Ergebnisse, keinen kontinuierlichen Zustand.
Abbildung 3. Ein modulares Modell, das von Sequenz zu Sequenz arbeitet. Die Steuerung aktiviert mehrere Module, von denen jedes einen Parameter erstellt.Module: Zuerst definieren wir, was ein Modul ist. Ein Modul ist ein spezialisiertes neuronales Netzwerk, das eine bestimmte Aufgabe zur Vorhersage einer Sequenz ausführen soll. In NL2API entsprechen verschiedene Module unterschiedlichen Parametern. In der GET-Messages-API sind die Module beispielsweise FILTER (Absender), FILTER (isRead), SELECT (Anhänge), ORDERBY (receiveDateTime), SEARCH usw. Die Aufgabe des Moduls besteht darin, die eingehende Anweisung zu erkennen und bei Aktivierung einen vollständigen Parameter zu erstellen. Dazu muss das Modul die Werte seines Parameters anhand der eingehenden Anweisung ermitteln.
Wenn eine eingehende Aussage beispielsweise wie "ungelesene Briefe über eine Doktorarbeit" klingt, sollte das SEARCH-Modul vorhersagen, dass der Wert des SEARCH-Parameters "Doktorarbeit" ist, und den vollständigen Parameter "SEARCH-Doktorarbeit" als Ausgabesequenz generieren. Analog sollte sich das Modul FILTER (isRead) daran erinnern, dass Ausdrücke wie "ungelesene E-Mails", "nicht gelesene E-Mails" und "noch ungelesene E-Mails" angeben, dass sein Parameterwert "False" sein sollte. .
Es ist nur natürlich, dass der nächste Schritt die Erstellung von Decodermodulen war, die bestimmen, worauf man sich konzentrieren soll, wie im üblichen Modell „von Sequenz zu Sequenz“. Anstelle eines Decoders, der für alles verwendet wird, haben wir jetzt mehrere Decoder, von denen jeder auf die Vorhersage bestimmter Parameter spezialisiert ist. Da jedes Modul eine klar definierte Terminologie hat, ist es außerdem viel einfacher, die Benutzerinteraktion auf Modulebene zu konfigurieren.
Moderator: Für jede einleitende Phrase werden nur wenige Module verwendet. Die Aufgabe des Reglers besteht darin, zu bestimmen, welche Module ausgeführt werden sollen. Somit ist der Regler auch ein Decoder, der bestimmt, worauf es sich zu konzentrieren lohnt. Indem eine Anweisung codiert und in eine Eingabe umgewandelt wird, wird eine Folge von Modulen erstellt, die als Schaltung bezeichnet werden. Anschließend erstellen die Module die entsprechenden Parameter, und schließlich werden die Parameter kombiniert, um die endgültige Anforderung an die API zu bilden.
Durch die Aufteilung des komplexen Prognoseprozesses im Standardmodell „Sequenz zu Sequenz“ in kleine, hochspezialisierte Prognoseeinheiten, die als Module bezeichnet werden, lässt sich das Prognosemodell den Benutzern leicht erklären. Mithilfe des Feedbacks der Benutzer können dann mögliche Prognosefehler auf der untersten Ebene korrigiert werden. In unserer Studie testen wir unsere Hypothese, indem wir den interaktiven NLI mit seiner nicht interaktiven Version vergleichen, sowohl durch Simulation als auch durch Experimente mit Personen, die wirklich funktionierende APIs verwenden. Wir können zeigen, dass Benutzer mit interaktiven NLIs häufiger und schneller Erfolg haben, was zu einer höheren Benutzerzufriedenheit führt.
In Kürze werden wir
einen Artikel veröffentlichen , in dem die Erstellung von Schnittstellen in natürlicher Sprache für die Web-API beschrieben wird. Bleib dran!