Oracle Digital Assistant unterstützt zwei Intents: Regelmäßige Intents und Antwort-Intents. Beide Intent-Typen verwenden dasselbe NLP-Modell, das für Pre-Production-Tests und in der Produktion auf Trainer Tm gesetzt werden sollte.

Der Unterschied zwischen den beiden Intent-Typen besteht darin, dass Antwort-Intents mit einer vordefinierten Nachricht verknüpft sind, die angezeigt wird, wenn das Intent aus einer Benutzernachricht aufgelöst wird, während reguläre Intents, wenn sie aufgelöst werden, zu einer im Dialogablauf definierten Benutzer-Bot-Unterhaltung führen.

Sie verwenden Antwort-Intents für den Bot, um auf häufig gestellte Fragen zu antworten, die immer eine einzige Antwort ergeben. Regelmäßige Intents werden verwendet, um eine längere Benutzer-Bot-Interaktion zu starten, die zum Abschluss einer Transaktionsaufgabe, zum Abfragen eines Backend-Systems oder zum Bereitstellen einer Antwort auf eine häufig gestellte Frage führt, die eine externe Abhängigkeit wie Uhrzeit, Datum oder Standort berücksichtigen muss, wenn eine Antwort bereitgestellt wird.

Um die Entwicklung und Verwaltung des Skills effizienter zu gestalten, sollten Sie eine Benennungskonvention für Ihre Intents erstellen, die es Ihnen leicht macht, sofort zu verstehen, wofür ein bestimmtes Intent steht, und die Filteroption bei der Suche nach Intents zu verwenden.

Beispiel: Ein Teil des Namens sollte zwischen Antwort-Intents und regulären Intents (und möglicherweise auch erforderlichen regulären Intents) abgrenzen, damit Sie eine direkte Antwort zurückgeben können, jedoch mit einer komplexeren Verarbeitung, z.B. mit einem Anhang oder basierend auf einer Abfrage an einen Remote-Service. In diesem Sinne können Sie mit einem Schema beginnen, das dem Folgenden ähnelt:

• Reguläre Intents: reg.<name_of_intent>

• Antwort-Intents: ans.<name_of_intent>

• Reguläre Intents, die Antworten sind: reg.ans.<name_of_intent>

Wenn Ihr Skill zugehörige Aufgaben verarbeitet, die kategorisiert werden können, kann dies auch bei der Intent-Benennung verwendet werden. Angenommen, Sie haben die Absicht, Anforderungen zu erstellen und zu stornieren. In diesen beiden Anwendungsfällen könnte die Benennungskonvention wie folgt lauten:

• Reguläre Intents: create.reg.<name_of_intent>, cancel.reg.<name_of_intent>

• Antwort-Intents: create.ans.<name_of_intent>, cancel.ans.<name_of_intent>

• Reguläre Intents, die Antworten sind: create.reg.ans.<name_of_intent>, cancel.reg.ans.<name_of_intent>

Es gibt keine strenge Regel, ob Sie Punktnotation, Unterstriche oder etwas von Ihrem eigenen verwenden. Behalten Sie die Namen jedoch kurz genug bei, damit sie nicht im Bereich des Intent-Editors von Oracle Digital Assistant abgeschnitten werden.

Jedes Intent verfügt auch über ein Feld "Unterhaltungsname". Der Unterhaltungsname wird in Disambiguierungsdialogen verwendet, die automatisch vom digitalen Assistenten oder Skill erstellt werden, wenn eine Benutzernachricht in mehrere Intents aufgelöst wird.

Jedes Intent verfügt über ein Feld "Beschreibung", in dem Sie kurz beschreiben sollten, wofür ein Intent gedacht ist, damit andere, die den Skill verwalten, ihn ohne zu erraten verstehen können.

Ein Beispiel für einen zu engen Geltungsbereich von Intents ist die Definition eines separaten Intents für jedes Produkt, das von einem Skill verarbeitet werden soll. Nehmen wir als Beispiel die Verlängerung einer bestehenden Versicherungspolice. Wenn Sie Absichten pro Police definiert haben, unterscheidet sich die Nachricht "Ich möchte meine Frau zu meiner Krankenversicherung hinzufügen" nicht wesentlich von "Ich möchte meine Frau zu meiner Autoversicherung hinzufügen", da die Unterscheidung zwischen den beiden ein einziges Wort ist. Stellen Sie sich ein weiteres negatives Beispiel vor, wenn wir bei Oracle einen digitalen Assistenten für unsere Kunden erstellt haben, um Produktsupport anzufordern. Für jedes unserer Produkte haben wir einen separaten Skill mit denselben Intents und Schulungsäußerungen erstellt.

Als kleines Kind haben Sie wahrscheinlich keine separaten Fähigkeiten entwickelt, um Flaschen, Papierstücke, Spielzeug, Kissen und Taschen zu halten. Vielmehr hast du einfach gelernt, wie man Dinge hält. Das gleiche Prinzip gilt für das Erstellen von Intents für einen Bot.

Der Geltungsbereich eines Intents ist zu breit, wenn Sie nach dem Lösen des Intents immer noch nicht sehen können, was der Benutzer möchte. Beispiel: Sie haben ein Intent mit dem Namen "handleExpenses" erstellt und es mit den folgenden Äußerungen und einer guten Anzahl von Variationen trainiert.

• "Ich möchte eine neue Spesenabrechnung erstellen"

• "Ich möchte meine letzte Spesenabrechnung prüfen"

• "Meine letzte Spesenabrechnung stornieren"

• "Mein letzter Bericht erfordert Korrekturen"

Damit wäre eine weitere Verarbeitung erforderlich, um zu verstehen, ob eine Spesenabrechnung erstellt, aktualisiert, gelöscht oder gesucht werden soll. Um komplexen Code in Ihrem Dialogablauf zu vermeiden und die Fehleroberfläche zu reduzieren, sollten Sie keine Intents entwerfen, die zu weit gefasst sind.

Denken Sie immer daran, dass maschinelles Lernen Ihr Freund ist und dass Ihr Modelldesign Sie zu einem ebenso guten Freund von dialogorientierter KI in Oracle Digital Assistant machen sollte.

Und es gibt mehr Funktionen von Entitys, die es sich lohnen, Zeit damit zu verbringen, Informationen zu identifizieren, die mit ihnen gesammelt werden können.

Beispiel: Was passiert, wenn ein Benutzer die Meldung "Ich habe diesen Artikel am 12. Juni 2021 und am 2. Juli 2021 gekauft" eingibt, wenn er nach einem Kaufdatum gefragt wird? In diesem Fall generiert die Entity, wenn sie mit der Komponente "Gemeinsame Antwort" oder "Entitys auflösen" verwendet wird, automatisch ein Dialogfeld zur Disambiguation, in dem der Benutzer einen einzelnen Wert als Dateneingabe auswählen kann. Wie in menschlichen Gesprächen, in denen eine Person eine andere Person bittet, eine Aussage oder Ordnung zu disambiguieren, werden Entitäten dasselbe für Sie tun. Selbstverständlich können Entitys auch so konfiguriert werden, dass sie mehrere Werte akzeptieren, wenn der Anwendungsfall dies unterstützt.

Wenn Sie die Komponente "Allgemeine Antwort" oder "Entitys auflösen" mit benutzerdefinierten Entitys verwenden, können die für Benutzer angezeigten Prompts in der Entity so definiert werden, dass Benutzer beim erneuten Prompt für zuvor nicht erfolgreiche Dateneingaben wechselnde Prompts erhalten. Wenn sich die Prompt-Nachricht zwischen den Aufrufen ändert, wird Ihr Bot weniger roboter- und dialogorientierter. Darüber hinaus können Sie alternierende Eingabeaufforderungen verwenden, um schrittweise weitere Informationen anzuzeigen, die Benutzer bei der Bereitstellung einer korrekten Eingabe unterstützen.

Als allgemeine Praxis wird empfohlen, Entitys zu verwenden, um Benutzereingaben zu validieren und Validierungsfehlermeldungen anzuzeigen sowie Eingabeaufforderungen und Dialogfelder zur Klärung anzuzeigen.

Wie bei Intents wird beim Erstellen von Entitynamen eine Benennungskonvention empfohlen. Wenn Sie den Entitytyp in den Namen der Entity aufnehmen, erleichtert dies zunächst das Verständnis auf einen Blick und bietet eine einfache Möglichkeit, eine Liste von Entitys zu filtern. Beispiel: Sie können das folgende Schema verwenden:

• Wertelistenentity: list.<name_of_entity>

• Entity des regulären Ausdrucks: reg.<name_of_entity>

• Abgeleitete Entität: der.<name_of_entity> oder der.DATE.<name_of_entity>

• Mischentity: cbe.<name_of_entity>

• Entität für maschinelles Lernen: ml.<name_of_entity>

Ob Sie Punktnotation wie in den obigen Beispielen, Unterstriche oder etwas von Ihrem eigenen verwenden, liegt an Ihnen. Darüber hinaus würden wir empfehlen, dass Sie versuchen, die Namen ziemlich kurz zu halten.

Jede Entity verfügt über ein Beschreibungsfeld, in dem Sie kurz beschreiben sollten, wofür eine Entity gedacht ist. Das Feld ist begrenzt in der Anzahl der Zeichen, die Sie eingeben können, also achten Sie darauf, kurz zu sein.

Beim Erstellen von Äußerungen für Ihre Intents verwenden Sie die meisten Äußerungen als Trainingsdaten für die Intents. Sie sollten jedoch auch einige Äußerungen zum Testen des von Ihnen erstellten Modells beiseite legen. Eine 80/20-Datenaufteilung ist in der Konversations-KI üblich, da das Verhältnis zwischen Äußerungen, die für das Training erstellt werden sollen, und Äußerungen, die zum Testen erstellt werden sollen.

Ein weiteres Verhältnis, das Sie beim Lesen von maschinellem Lernen finden können, ist eine 70/15/15-Aufteilung. Eine 70/15/15-Aufteilung bedeutet, dass 70% Ihrer Äußerungen zum Trainieren eines Intents verwendet werden, 15% zum Testen des Intents während der Entwicklung und die anderen 15% zum Testen verwendet werden, bevor Sie mit der Produktion beginnen. Eine gute Analogie zum Intent-Training ist eine Schulprüfung. Die 70% sind das, was ein Lehrer über ein Thema lehrt. Die ersten 15% sind dann Tests, die Sie während des Studiums durchführen. Dann, wenn es darum geht, Ihre Prüfung zu schreiben, erhalten Sie weitere 15% Reihe von Tests, die Sie noch nicht gesehen haben.

Obwohl die 70/15/15 überzeugend ist, empfehlen wir weiterhin eine Aufteilung von 80/20 für die Schulung von Oracle Digital Assistant-Intents. Wie Sie später in diesem Handbuch sehen werden, erhalten Sie zusätzliche Daten zum Testen aus Cross-Testing-Äußerungen im Kontext des digitalen Assistenten (Nachbarentests). Wenn Sie also die Empfehlungen in diesem Handbuch befolgen, sammeln Sie genügend Daten zum Testen, um sicherzustellen, dass Ihre Modelle funktionieren (auch wenn es sich nicht um eine 70/15/15-Aufteilung handelt). Und Sie werden in der Lage sein, diese Tests wiederholt durchzuführen, um eine Vorstellung von Verbesserungen oder Regression im Laufe der Zeit zu bekommen.

Es gibt keinen Müll, keine Diamanten, wenn es um dialogorientierte KI geht. Die Qualität der Daten, mit denen Sie Ihr Modell trainieren, hat einen direkten Einfluss auf das Verständnis des Bots und seine Fähigkeit, Informationen zu extrahieren.

Das Ziel der Definition von Äußerungen besteht darin, einen unvoreingenommenen und ausgewogenen Satz von Trainings- und Testdaten zu erstellen, die das Intent-Modell nicht überladen. Hier sind einige Regeln, nach denen Sie nach unserer Erfahrung gute Ergebnisse erzielen können.

• Verwenden Sie keine Generierungswerkzeuge, um Äußerungen zu erstellen. Die Chancen stehen gut, dass Sie viele Äußerungen mit wenig Variation erhalten.

• Betrachten Sie verschiedene Ansätze, um ein Intent auszulösen, wie "Ich möchte mein Kennwort zurücksetzen" oder "Ich kann mich nicht bei meiner E-Mail anmelden".

• Verwenden Sie keine Äußerungen, die aus einzelnen Wörtern bestehen, da ihnen der Kontext fehlt, aus dem das Maschinenmodell lernen kann.

• Vermeiden Sie Wörter wie "bitte", "Danke" usw., die nicht viel zur semantischen Bedeutung der Äußerungen beitragen.

• Verwenden Sie eine repräsentative Gruppe von Entitywerten, aber nicht alle.

• Variieren Sie die Platzierung der Entity. Sie können die Entity am Anfang, in der Mitte und am Ende der Äußerung platzieren.

• Halten Sie die Anzahl der Äußerungen zwischen Intents ausgewogen (z.B. 300 für ein Intent und 15 für ein anderes Intent vermeiden).

• Streben Sie nach semantisch und syntaktisch vollständigen Sätzen.

• Verwenden Sie korrekte Schreibweisen. Nur ausnahmsweise würden Sie einige sehr wahrscheinliche Rechtschreibfehler und Tippfehler in den Äußerungen hinzufügen. Das Modell ist in der Regel in der Lage, mit Rechtschreibfehlern und Tippfehlern allein umzugehen.

• Fügen Sie länderspezifische Variationen hinzu (z. B. Papierkorb vs. Mülltonne, Windel vs. Windel).

• Variieren Sie die Satzstruktur (z.B. "Ich möchte eine Pizza bestellen", "Ich möchte eine Pizza, kann ich bestellen").

• Ändern Sie das Personalpronomen (z. B. ich, wir sind, wir sind, ich würde, ich würde, wir, Sie, Ihr, wir).

• Verwenden Sie verschiedene Begriffe für das Verb (z.B. bestellen, bekommen, fragen, wollen, mögen, wollen).

• Verwenden Sie verschiedene Begriffe für das Substantiv (z. B. Pizza, Calzone, Hawaiianisch).

• Erstellen Sie Äußerungen mit unterschiedlichen Längen (kurze, mittlere und lange Sätze).

• Erwägen Sie die Pluralisierung (z.B. "Ich möchte Pizzen bestellen", "Kann ich einige Pizzen bestellen").

• Überlegen Sie, verschiedene Verbformen und Gerunden zu verwenden ("Fischen ist erlaubt", "Ich möchte fischen, kann ich das tun").

• Verwenden Sie Satzzeichen in einigen Fällen und lassen Sie es in anderen aus.

• Verwenden Sie repräsentative Begriffe (z. B. zu viele technische Begriffe vermeiden, wenn die Software von Verbrauchern verwendet wird).

Äußerungen sollten nicht auf die gleiche Weise definiert werden wie Befehlszeilenargumente oder Listenschlüsselwörter. Stellen Sie sicher, dass alle Äußerungen, die Sie definieren, den Begriff "konversativ" für sie haben. Beim Erstellen von Äußerungen, für die nur Schlüsselwörter aufgelistet sind, fehlt der Kontext oder das Modell für maschinelles Lernen ist zu kurz, um daraus zu lernen.

Idealerweise werden gute Äußerungen aus echten Daten kuratiert. Wenn Sie keine vorhandenen Gesprächsprotokolle haben, sollten Sie Crowdsourcing-Äußerungen in Betracht ziehen, anstatt sie nur zu synthetisieren. Die Synthese sollte Ihr letzter Ausweg sein.

E-Mail-Personen, die Sie kennen, repräsentieren oder wissen, wie Sie die beabsichtigte Zielgruppe Ihres Bots darstellen. Darüber hinaus können Sie mit dem Data Manufacturing-Feature von Oracle Digital Assistant einen automatisierten Prozess zum Erfassen von (Crowdsourcing-)Vorschlägen für Äußerungen einrichten, die Sie dann wahrscheinlich kuratieren möchten, damit sie die von uns beschriebenen Regeln für eine gute Äußerung einhalten.

Beachten Sie, dass Sie feststellen können, dass Personen, die Sie nach Beispieläußerungen fragen, sich herausgefordert fühlen, außergewöhnlich gute Beispiele zu finden, was zu unrealistischen Nischenfällen oder einer übermäßig künstlerischen Verwendung von Sprache führen kann, die Sie zur Kuratierung der Sätze verpflichtet.

Denken Sie auch daran, dass beim Kurieren von Beispieläußerungen auch mehrere Variationen einzelner Proben erstellt werden, die Sie durch Crowdsourcing geerntet haben.

Die Qualität der Äußerungen ist wichtiger als die Quantität. Ein paar gute Äußerungen sind besser als viele schlecht gestaltete utterances.Our-Empfehlungen sind, mit 20-30 guten Äußerungen pro Intent in der Entwicklung zu beginnen und diese Zahl schließlich auf 80-100 zu erhöhen, um Ihre Intents ernsthaft zu testen. Im Laufe der Zeit und wenn der Bot mit echten Benutzern getestet wird, sammeln Sie zusätzliche Äußerungen, die Sie dann kuratieren und zum Trainieren des Intent-Modells verwenden.

Abhängig von der Wichtigkeit und dem Anwendungsfall eines Intents können Sie am Ende unterschiedliche Anzahl von Äußerungen pro Intent definieren, die von hundert bis mehreren hundert (und selten bis zu den Tausenden) reichen. Wie bereits erwähnt, sollte der Unterschied in den Äußerungen pro Intent jedoch nicht extrem sein.

Ein Modell für maschinelles Lernen bewertet eine Benutzernachricht und gibt einen Konfidenzscore für das Label (Intent) der obersten Ebene und den Zweitplatzierten zurück. In der dialogorientierten KI wird das Label der obersten Ebene als Intent zum Starten einer Unterhaltung aufgelöst.

Stellen Sie sich also basierend auf dem Modelltraining und der Benutzernachricht einen Fall vor, in dem das Modell zu 80% sicher ist, dass Intent A eine gute Übereinstimmung ist, 60% Vertrauen in Intent B und 45% für Intent C. In diesem Fall würden Sie wahrscheinlich ziemlich bequem sein, dass der Benutzer Intent A möchte.

Aber was ist, wenn das Label mit der höchsten Punktzahl nur 30% Vertrauen hat, dass dies das ist, was der Benutzer will? Würden Sie riskieren, dass das Modell diesem Intent folgt, oder würden Sie es lieber sicher abspielen und davon ausgehen, dass das Modell nicht vorhersagen kann, was ein Benutzer möchte, und dem Benutzer eine Nachricht anzeigen kann, um eine Anforderung neu zu formulieren?

Um dem Intent-Modell zu helfen, eine Entscheidung darüber zu treffen, welche Intents mit einer Benutzeräußerung abgeglichen werden sollen, verwendet die Konversations-KI eine Einstellung namens Konfidenzschwellenwert. Das Intent-Modell wertet eine Benutzeräußerung anhand aller Intents aus und weist Konfidenzscores für jedes Intent zu. Der Konfidenzschwellenwert ist ein Wert im Bereich möglicher Konfidenzscores, der die Zeile markiert:

• unter denen eine Absicht als überhaupt nicht mit der Äußerung übereinstimmt; und

• über dem ein Intent als Kandidatenabsicht zum Starten einer Unterhaltung gilt.

In Oracle Digital Assistant wird der Konfidenzschwellenwert für einen Skill in den Einstellungen des Skills definiert und hat den Standardwert 0.7.

Eine Einstellung von 0.7 ist ein guter Wert, um mit dem trainierten Intent-Modell zu beginnen und es zu testen. Wenn Tests zeigen, dass das richtige Intent für Benutzernachrichten deutlich über 0,7 aufgelöst wird, haben Sie ein gut trainiertes Modell.

Wenn Sie mit einer Einstellung von 0,7 gute Ergebnisse erzielen, versuchen Sie es mit 0,8. Je höher die Konfidenz, desto wahrscheinlicher ist es, dass Sie das Rauschen aus dem Intent-Modell entfernen. Das bedeutet, dass das Modell nicht auf Wörter in einer Benutzernachricht reagiert, die für die Auflösung des Anwendungsfalls nicht relevant sind.

Je höher jedoch die Konfidenzschwelle ist, desto wahrscheinlicher ist es, dass das Gesamtverständnis sinkt (was bedeutet, dass viele praktikable Äußerungen möglicherweise nicht übereinstimmen), was nicht das ist, was Sie wollen. Mit anderen Worten: 100 Prozent "Verstehen" (oder 1,0 als Vertrauensniveau) sind möglicherweise kein realistisches Ziel.

Denken Sie daran, dass es bei der Konversations-KI darum geht, zu verstehen, was ein Benutzer möchte, obwohl er dies auf viele verschiedene Arten ausdrücken kann. Zum Beispiel sollten die Nutzer in einem Pizzabot-Fall Pizza mit so unterschiedlichen Phrasen wie "Ich möchte eine Pizza bestellen" und "Ich bin hungrig" bestellen können.