Freigeben über

Verwendung von Conversational Language Understanding oder Orchestrierungsworkflow für Apps

  • Artikel

Wenn Sie große Anwendungen erstellen, sollten Sie überlegen, was für Ihren Anwendungsfall besser geeignet ist: eine einzelne Konversations-App (flache Architektur) oder mehrere orchestrierte Apps.

Übersicht über die Orchestrierung

Der Orchestrierungsworkflow ist ein Feature, mit dem Sie verschiedene Projekte von LUIS Conversational Language Understanding mit benutzerdefinierten Fragen und Antworten in einem Projekt verbinden können. Dieses Projekt können Sie dann für Vorhersagen mit nur einem Endpunkt verwenden. Das Orchestrierungsprojekt trifft eine Vorhersage, welches untergeordnete Projekt aufgerufen werden sollte, leitet die Anforderung automatisch weiter und gibt eine Antwort zurück.

Die Orchestrierung umfasst zwei Schritte:

  1. Vorhersagen, welches untergeordnete Projekt aufgerufen werden soll
  2. Weiterleiten der Äußerung an die untergeordnete Ziel-App und Zurückgeben der Antwort der untergeordneten App

Vorteile der Orchestrierung

  • Klare Aufgliederung und schnellere Entwicklung:

    • Wenn Ihr Gesamtschema über eine beträchtliche Anzahl von Fachgebieten verfügt, kann eine Orchestrierung dazu beitragen, Ihre Anwendung in mehrere untergeordnete Apps aufzugliedern (von denen jede ein bestimmtes Fachgebiet bedient). Eine Konversations-App für Automobile könnte beispielsweise die Fachgebiete Navigation oder Medien abdecken.
    • Die parallele Entwicklung der einzelnen Fachgebiets-Apps ist einfacher. Personen und Teams mit spezifischen Kenntnissen in diesen Fachgebieten können gemeinsam und parallel an einzelnen Apps arbeiten.
    • Da die Apps für die einzelnen Fachgebiete kleiner sind, wird der Entwicklungszyklus schneller. Das Trainieren kleinerer Fachgebiets-Apps nimmt viel weniger Zeit in Anspruch als eine einzelne große App.

  • Flexiblere Schwellenwerte für die Konfidenzbewertung:

    • Da es separate untergeordnete Apps für jedes Fachgebiet gibt, ist es einfach, separate Schwellenwerte für verschiedene untergeordnete Apps festzulegen.

  • Verbesserung der KI-Qualität, sofern erforderlich:

    • Für einige Anwendungen ist es erforderlich, dass bestimmte Entitäten auf das Fachgebiet beschränkt sind. Durch Orchestrierung lässt sich dies leicht erreichen. Nachdem das Orchestrierungsprojekt prognostiziert, welche untergeordnete App aufgerufen werden soll, werden die anderen untergeordneten Apps nicht aufgerufen.

      Ein Beispiel: Wenn Ihre App die vordefinierte Entität Person.Name enthält, betrachten Sie die Äußerung „Wo bekomme ich günstig einen Mercedes?“ im Kontext einer Frage zu Fahrzeugen. In diesem Zusammenhang ist Mercedes eine Automarke und sollte nicht als Name einer Person erkannt werden. Wenn Sie diese Orchestrierung verwenden, kann diese Äußerung an eine untergeordnete App weitergeleitet werden, die für die Beantwortung einer solchen Frage erstellt wurde und die Entität Person.Name nicht enthält.

Nachteile der Orchestrierung

  • Redundante Entitäten in untergeordneten Apps:

    • Wenn eine bestimmte vordefinierte Entität unabhängig vom Fachgebiet in allen Äußerungen zurückgegeben werden muss (z. B. Quantity.Number oder Geography.Location), kann diese Entität nicht in die Orchestrierungs-App eingegeben werden, da es sich um ein rein absichtsbasiertes Modell handelt. Sie müssen sie jeder einzelnen untergeordneten App hinzufügen.

  • Efficiency:

    • Orchestrierungs-Apps verwenden zwei Arten von Modellrückschlüssen. Eine für die Vorhersage, welche untergeordnete App aufgerufen werden soll, und die andere für die Vorhersage in der untergeordneten App. Die Rückschlüsse sind in der Regel langsamer als bei einzelnen Apps mit einer flachen Architektur.

  • Trainieren/Testen der Aufteilung für den Orchestrator:

    • Beim Trainieren einer Orchestrierungs-App können Sie Daten nicht differenziert zwischen den Test- und Trainingsdatensätzen aufteilen. Sie können z. B. keine 90-10-Aufteilung für die untergeordnete App A trainieren und dann eine 80-20-Aufteilung für die untergeordnete App B trainieren. Diese Einschränkung kann geringfügig sein, aber es lohnt sich, dies im Hinterkopf zu behalten.

Übersicht über die flache Architektur

Eine flache Architektur ist die andere Methode zum Entwickeln von Konversations-Apps. Hierbei verwenden Sie keine Orchestrierungs-App zum Senden von Äußerungen an eine von mehreren untergeordneten Apps, sondern entwickeln eine einzelne (flache) App zur Verarbeitung von Äußerungen.

Vorteile der flachen Architektur

  • Einfachheit:

    • Bei kleinen Apps oder Fachgebieten kann der Orchestratoransatz übermäßig komplex sein.
    • Da sich alle Absichten und Entitäten auf derselben App-Ebene befinden, ist es möglicherweise einfacher, Änderungen an allen gemeinsam vorzunehmen.

  • Es ist einfacher, Entitäten hinzuzufügen, die immer zurückgegeben werden sollen:

    • Wenn Sie möchten, dass bestimmte vordefinierte Entitäten oder Listenentitäten für alle Äußerungen zurückgegeben werden, müssen Sie diese nur zusammen mit anderen Entitäten in einer einzigen App hinzufügen. Bei Verwendung der Orchestrierung müssten Sie die Entitäten, wie oben erwähnt, jeder untergeordneten App hinzufügen.

Nachteile der flachen Architektur

  • Unübersichtlich für große Apps:

    • Bei großen Apps (z. B mehr als 50 Absichten oder Entitäten) kann es schwierig werden, sich weiterentwickelnde Schemas und Datasets nachzuverfolgen. Diese Schwierigkeit wird besonders in Fällen deutlich, in denen die App mehrere Fachgebiete bedienen muss. Eine Konversations-App für Automobile könnte beispielsweise die Fachgebiete Navigation oder Medien abdecken.

  • Eingeschränkte Kontrolle über Entitätsüberstimmungen:

    • In einer flachen Architektur gibt es keine Möglichkeit, Entitäten so einzuschränken, dass sie nur in bestimmten Fällen zurückgegeben werden. Wenn Sie die Orchestrierung verwenden, können Sie diese bestimmten Entitäten bestimmten untergeordneten Apps zuweisen.

Zugehöriger Inhalt