Echtzeit-Automatisierung

In diesem praktischen Tutorial erstellen wir eine einfache automatisierte Triage-Anwendung, die Communications Mining verwendet, um eingehende E-Mails in Echtzeit zu kategorisieren. Wir erstellen einen End-to-End-Workflow, der als Ausgangspunkt für Ihre eigene Communications Mining-Automatisierung verwendet werden kann, und werfen einen detaillierten Blick auf die Verwendung der Echtzeit-Stream-API.

Voraussetzungen

Grundlagen von Communications Mining

Bevor Sie mit diesem Tutorial beginnen, stellen Sie sicher, dass Sie mit den Konzepten und der Terminologie von Communications Mining sowie den Grundlagen der Communications Mining API vertraut sind.

Communications Mining-Zugriff

Sie benötigen die folgenden Berechtigungen, um dem Tutorial zu folgen. Sie können Ihre aktuellen Berechtigungen auf der Seite Konto verwalten überprüfen.

Projekt	BESCHREIBUNG	PERMISSIONS
reinfer-sandbox	Enthält das vorab mit Anmerkungen versehene Dataset reinfer-sandbox/integration-tutorial , das in diesem Tutorial verwendet wird.	„Quellen anzeigen“, „Beschriftungen anzeigen“
Ihr Entwicklungsprojekt	Während des Onboardings sollten Sie Zugriff auf ein Projekt erhalten haben, das Sie als Entwicklungsumgebung verwenden können.	„Stream admin“, „Streams verbrauchen“, „Quellen anzeigen“, „Labels anzeigen“

Wenden Sie sich an den Support, wenn Sie nicht sicher sind, welches Projekt Sie für die Entwicklung verwenden kann, oder wenn Sie in reinfer-sandbox die Berechtigungen „Quellen anzeigen“ und „Beschriftungen anzeigen“ benötigen.

Tutorial-Daten

In diesem Tutorial verwenden wir vorab mit Anmerkungen versehene Daten. Um eine Kopie des vorab kommentierten Datasets reinfer-sandbox/integration-tutorial zu erstellen, erstellen Sie ein neues Dataset in Ihrem Entwicklungsprojekt mit der Option „Vorhandene Taxonomie kopieren“. Eine Anleitung dazu finden Sie hier.

Da Ihr neues Dataset mit Anmerkungen versehene Daten enthält, beginnt das Modell sofort mit dem Training. Sie können den Modelltrainingsstatus in der Dataset-Statusleiste nachverfolgen. Danach werden Leistungsmetriken für jede Bezeichnung auf der Seite Validierung angezeigt und eine neue Modellversion wird auf der Seite Modelle angezeigt.

Abbildung 1. Validierungsseite mit der Bezeichnungsleistung

Abbildung 2. Modellseite mit der neuen Modellversion

Entwerfen Sie Ihre Anwendung

Da Sie nun mit den Voraussetzungen vertraut sind, können Sie mit dem Erstellen unseres End-to-End-Workflows beginnen. In diesem Abschnitt werden wir das Design einer einfachen automatisierten Triage-Anwendung und ihre Integration mit Communications Mining besprechen. In den nächsten Abschnitten erfahren Sie mehr über die Stream-API , die unsere Automatisierung vorantreiben wird. Schließlich erstellen wir unsere Anwendung basierend auf diesem Design und testen sie mit vorab kommentierten Daten.

Anwendungsfallübersicht

Wir zielen auf einen typischen E-Mail-Support-Anwendungsfall als Ausgangspunkt für unser Design ab:

• Ein Outlook-Support-Postfach erhält täglich eine große Anzahl von Kunden-E-Mails.
• Ein Triage-Team wandelt jede E-Mail in ein Support-Ticket um. Dazu müssen Sie die Ticketfelder mit Informationen aus der E-Mail ausfüllen (z. B. eine Kunden-ID). Jedes Ticket wird dann der entsprechenden Workflow-Warteschlange hinzugefügt.
• Die Tickets in den Workflow-Warteschlangen werden kontinuierlich von einem Kundensupport-Team bearbeitet.
  Abbildung 3. Ein einfacher Anwendungsfall für E-Mail-Support
  

  

  
  

Hier gibt es zwei Automatisierungsmöglichkeiten: den Triage-Schritt und den Verarbeitungsschritt. In diesem Tutorial wird gezeigt, wie Sie den Triage-Schritt automatisieren, indem Sie Communications Mining verwenden, um Pflichtfelder aus der E-Mail zu extrahieren und die E-Mail einer Workflow-Warteschlange zuzuweisen.

Hinweis: Obwohl der Verarbeitungsschritt in diesem Tutorial nicht erläutert wird, basiert er auf den Daten, die während des Triage-Schritts gesammelt wurden. Sie haben also die Möglichkeit, ihn nach dem Erstellen der Beispiel-Triage-Anwendung hinzuzufügen.

End-to-End-Design

Sehen wir uns das nachstehende Diagramm an, das das End-to-End-Design veranschaulicht, das wir erstellen werden:

Abbildung 4. End-to-End-Automatisierungsdesign

Aufgrund der Live-Verbindung zwischen dem Exchange-Server und Communications Mining kann Communications Mining als Datenquelle für Ihre Anwendung dienen. Auf diese Weise ist keine separate Verbindung zwischen Ihrer Anwendung und dem Exchange-Server erforderlich. Ihre Anwendung fragt Communications Mining kontinuierlich nach neuen E-Mails ab und erhält sie zusammen mit ihren vorhergesagten Bezeichnungen und allgemeinen Feldern. (Wir gehen davon aus, dass keine Benutzer direkt im Posteingang des Postfachs arbeiten, während Ihre Anwendung ausgeführt wird; andernfalls müssten Sie Konflikte zwischen Ihrer Anwendung und den Postfachbenutzern berücksichtigen).

Ihre Anwendung fragt Communications Mining ab und prüft für jede E-Mail, ob die erforderlichen Beschriftungen und allgemeinen Felder in der API-Antwort vorhanden sind. Wenn ja, wird ein Ticket in der entsprechenden Workflow-Warteschlange erstellt. Andernfalls wird eine zweite API-Anforderung an Communications Mining gestellt, um die E-Mail als Ausnahme „Keine Vorhersage“ zu markieren. Ebenso sollte es für Benutzer, die die Tickets bearbeiten, eine Möglichkeit geben, falsch kategorisierte Tickets zu melden, sodass die entsprechenden E-Mails in Communications Mining als Ausnahme „false Vorhersage“ markiert werden können. (Beide Ausnahmetypen werden dann vom Modellbetreuer überprüft und mit Anmerkungen versehen, um die Modellleistung zu verbessern).

Teile des Designs (im Diagramm mit einer gepunkteten Kontur dargestellt) liegen außerhalb des Scopes dieses Tutorials. In einem realen Szenario sollten diese Schritte natürlich nicht übersprungen werden:

• Wir verwenden vorhandene Daten in der Plattform, anstatt eine Live-EWS-Verbindung einzurichten.
• Die Daten sind vorab mit Anmerkungen versehen, sodass wir kein Modell trainieren müssen.
• Wir werden keine Feedback-Schleife für Ausnahmen mit „false Vorhersage“ entwerfen, da das Design von den Funktionen des Systems abhängt, in dem Tickets verarbeitet werden.

Datenerfassung

Die empfohlene Option zum Abrufen von E-Mail-Daten in Communications Mining ist die Verwendung des Communications Mining-EWS-Connectors, aber es sind auch andere Optionen verfügbar. Da wir Daten verwenden, die sich bereits in der Plattform befinden, ist die Einrichtung der Datenerfassung nicht Teil dieses Tutorials. Weitere Informationen zu allen verfügbaren Datenerfassungsoptionen finden Sie hier.

Geschäftslogik

Wir möchten diesen Prozess automatisieren:

Ein Triage-Team wandelt jede E-Mail in ein Support-Ticket um. Dazu müssen Sie die Ticketfelder mit Informationen aus der E-Mail ausfüllen (z. B. eine Kunden-ID). Jedes Ticket wird dann der entsprechenden Workflow-Warteschlange hinzugefügt.

Nehmen wir für dieses Tutorial an, dass unsere Workflow-Warteschlangen „Verlängerung“, „Abbruch“, „Administrator“ und „Dringend“ sind. E-Mails zu Verlängerung, Kündigung und Administratoraufgaben (z. B. Adressänderungen) in die jeweiligen Warteschlangen aufgenommen werden sollen, während alle dringenden E-Mails unabhängig vom Thema in die Warteschlange „Dringend‟ aufgenommen werden sollten.

Nehmen wir auch an, dass jede E-Mail eine Kunden-ID enthalten kann (entweder im Betreff oder im Textkörper der E-Mail). Die Kunden-ID muss extrahiert werden, damit sie beim Erstellen eines Tickets in der E-Mail verwendet werden kann. Da Kunden manchmal vergessen, die Kunden-ID anzugeben, möchten wir dieses Feld optional machen, sodass ein Ticket auch dann erstellt werden kann, wenn keine Kunden-ID vorhanden ist.

Abbildung 5. Überprüfter Kommentar mit zugewiesener Beschriftung „Abbruch“ und extrahiertem allgemeinen Feld „Kunden-ID“.

Um E-Mails in die vier Workflow-Warteschlangen kategorisieren zu können, wurde das Modell trainiert, um die Bezeichnungen „Verlängerung“, „Abbruch“, „Administrator“ und „Dringend“ vorherzusagen. Um die Kunden-ID zu extrahieren, wurde das allgemeine Feld „Kunden-ID“ konfiguriert. (Communications Mining verfügt über viele vorgefertigte allgemeine Feldarten; weitere allgemeine Feldarten können basierend auf den Anforderungen Ihrer spezifischen Integration hinzugefügt werden). Eine Liste der aktuell verfügbaren allgemeinen Feldfelder finden Sie hier. Informationen zum Anfordern neuer allgemeiner Feldtypen finden Sie hier.

Wir können nun eine Zuordnung zwischen den vorhergesagten Bezeichnungen, die von Communications Mining erhalten wurden, und der Workflow-Warteschlange finden, in die die E-Mail aufgenommen werden soll:

IF number of labels == 0 THEN put email into "Uncategorised" queue
IF one of labels is "Urgent" THEN put email into "Urgent" queue
ELSE
    IF number of labels == 1 THEN put email into the respective queue
    ELSE put email into "Uncategorised" queue

Wir haben einige Auswahlen für das Tutorial getroffen:

• Zusätzlich zu den vorhandenen vier Workflow-Warteschlangen gibt es eine spezielle Warteschlange „Nicht kategorisiert“. Wenn das Modell keine Vorhersage geben kann, legen wir die E-Mail dort ab, wo sie manuell verarbeitet werden kann. Alternativ hätten wir eine vorhandene Warteschlange auswählen können, die alle nicht kategorisierten E-Mails verarbeiten sollte, z. B. „Administrator“.
• Wenn eine E-Mail mehr als eine Beschriftung aus dem Satz ["Renewal", "Cancellation", "Admin"] hat, bedeutet dies, dass sie mehrere Anforderungen enthält. Wir entscheiden uns dafür, solche E-Mails in die Warteschlange „Nicht kategorisiert“ zu stellen, möglicherweise weil wir nicht damit rechnen, dass wir viele davon erhalten. Alternativ hätten wir eine Warteschlange „Complex Requests“ erstellen können.

In einem realen Szenario sollten Sie solche Entscheidungen auf den spezifischen Anforderungen Ihres Anwendungsfalls basieren.

Modelltraining

Um ein Modell für Vorhersagen abzufragen, benötigen Sie natürlich ein trainiertes Modell. Ein Modell wird trainiert, indem einige der erfassten Daten mit Anmerkungen versehen werden. Da mehrere Stunden der Anmerkung erforderlich sind, um ein gutes Modell zu erstellen, verwenden wir in diesem Tutorial vorkommentierte Daten, sodass Sie nicht Ihr eigenes Modell trainieren müssen.

In einem realen Szenario sollte ein Modelltrainer über gute Domänenkenntnisse der Daten verfügen. Beispielsweise wäre der Benutzer eines Support-Postfachs ein guter Modelltrainer, um die von diesem Postfach stammenden Daten zu beschriften. Das Training muss sorgfältig durchgeführt werden, um ein Modell zu erzeugen, das gut funktioniert und nicht verzerrt ist. Zu diesem Zweck stellt Communications Mining Trainingsressourcen bereit und bietet praxisorientierte Trainingsworkflows an.

Ausnahmebehandlung

Selbst ein gut funktionierendes Modell liefert gelegentlich falsche Ergebnisse, entweder indem eine Bezeichnung nicht vorhergesagt wird oder indem die falsche Bezeichnung vorhergesagt wird. Eine der besten Möglichkeiten, das Modell zu verbessern, besteht darin, die E-Mails zu kommentieren, bei denen das Modell nicht gut funktioniert. Aus diesem Grund möchten wir eine Feedback-Schleife für solche E-Mails haben:

Ihre Anwendung überprüft für jede E-Mail, ob erforderliche Beschriftungen und allgemeine Felder vorhanden sind. Wenn ja, wird ein Ticket in der entsprechenden Workflow-Warteschlange erstellt. Wenn nicht, wird eine zweite API-Anforderung an Communications Mining gestellt, um die E-Mail als Ausnahme „keine Vorhersage“ zu markieren. Ebenso sollte es für Benutzer, die die Tickets bearbeiten, eine Möglichkeit geben, falsch kategorisierte Tickets zu melden, sodass die entsprechenden E-Mails in Communications Mining als Ausnahme „false Vorhersage“ markiert werden können.

Unser Design zeigt Feedback-Schleifen für beide Ausnahmetypen an.

Downstream-Systeme

Unser Design zeigt Workflow-Warteschlangen auf abstrakte Weise an. In der Realität können Sie die E-Mails direkt in eine CRM-Plattform schieben, einen Nachrichtenbroker wie Kafka verwenden oder die E-Mails einfach aus dem Posteingangsordner in einen Unterordner verschieben. Für die Zwecke dieses Tutorials werden die Warteschlangen nachgebildet, aber Sie werden aufgefordert, Ihre Testintegration durchgängig zu entwickeln.

Grundlegendes zum Verständnis der Stream-API

Um eingehende E-Mails zusammen mit vorhergesagten Beschriftungen und extrahierten allgemeinen Feldern abzurufen, verwenden wir die Stream-API, mit der Sie einen Stream von Kommentaren basierend auf einem Dataset, einer angehefteten Modellversion und optionalen Kommentarfiltern definieren und diese durchlaufen können auf zustandsbehaftete Weise.

Jedes Ergebnis in der Stream-Antwort enthält einen Kommentar, eine Liste der vorhergesagten Labels und eine Liste allgemeiner Felder. Dies wird als JSON-Struktur übergeben, wie unten dargestellt:

{
"comment": {...},
"entities": [...],
"labels": [...],
    ...
}

Im folgenden Abschnitt wird erläutert, wie die vorhergesagten Bezeichnungen in jeder Stream-Antwort korrekt interpretiert werden.

Konfidenz-Schwellenwertbewertungen

Konfidenzbewertungen

Der Stream-Endpunkt gibt vorhergesagte Beschriftungen zusammen mit einem Konfidenzwert (eine Zahl zwischen 0 und 1) zurück. Der folgende Snippet wäre beispielsweise für Vorhersagen von „Abbruch“ und „Administrator“ mit Konfidenzen von etwa 0,84 bzw. 0,02:

"labels": [
{
"name": ["Cancellation"],
"probability": 0.8374786376953125
},
{
"name": ["Admin"],
"probability": 0.0164003014564514
}
]

Um ein solches Ergebnis korrekt zu interpretieren, müssen Sie den Mindestkonfidenzwert bestimmen, bei dem Sie die Vorhersage als „Ja, die Bezeichnung trifft zu“ behandeln. Wir nennen diese Zahl den Schwellenwert für die Konfidenzbewertung.

Präzision und Rückruf

Zum Verständnis von Konfidenzschwellenwerten sollten Sie mit den Begriffen Präzision und Rückruf vertraut sein. Eine Erklärung dieser Begriffe finden Sie auf unseren Supportseiten. Kurz gesagt bezieht sich eine hohe Genauigkeit auf eine geringe Rate an falsch positiven Ergebnissen (d. h Ihre Ergebnisse sind mit höherer Wahrscheinlichkeit genau). Eine hohe Rückrufaktion führt zu einer niedrigen falsch-negativen Rate (d. h ist es weniger wahrscheinlich, dass Sie relevante Ergebnisse übersehen).

Konfidenz-Schwellenwert

Der Konfidenzschwellenwert für eine Bezeichnung entspricht einem bestimmten Zielkonflikt zwischen Genauigkeit und Rückruf. Wenn Ihr Modell nicht perfekt funktioniert, verliert eine hohe Genauigkeit die Wiedererkennung und umgekehrt geht eine hohe Wiedererkennung an der Genauigkeit verloren. Diese Zielkonflikte werden als Präzisions-Rückruf-Kurve für jede Bezeichnung auf der Seite Validierung visualisiert.

Abbildung 6. Präzisions-Rückruf-Kurve einer Bezeichnung

Mit dem interaktiven Schieberegler können Sie schnell den gewünschten Schwellenwert finden: Bewegen Sie den Schieberegler nach rechts, um die Genauigkeit zu optimieren, oder nach links, um die Rückruffunktion zu optimieren, bis Sie die Genauigkeit und die Rückruffunktion gefunden haben, die Ihren Anwendungsanforderungen entspricht. Der angezeigte Schwellenwert ist Ihr gewünschter Schwellenwert. Wenn Sie mehr über die Funktionalität der Validierungsseite erfahren möchten, lesen Sie bitte die Supportseiten.

Hinweis:

Wenn Sie sich die Seite Validierung ansehen, stellen Sie möglicherweise fest, dass die Formen der Präzisions-Rückruf-Kurve für jede Bezeichnung unterschiedlich sind. Dadurch erhalten Sie einen Hinweis darauf, wie wir Schwellenwerte auswählen werden: Wir wählen für jede Bezeichnung einen einzelnen Schwellenwert aus. Dies ist besonders wichtig bei Automatisierungsanwendungen, bei denen die beste Leistung gewährleistet werden muss.

Beispielschwellenwerte

Für unsere Beispielanwendung wählen wir einen ausgewogenen Genauigkeits- vs. Rückruf-Kompromiss für unsere Beschriftungen „Verlängerung“, „Abbruch“ und „Administrator“ und optimieren den Rückruf für die Beschriftung „Dringend“ (damit die Wahrscheinlichkeit geringer ist, dass dies der Fall ist). dringende E-Mails verpassen). (Beachten Sie, dass sich die Präzisions- und Rückrufwerte am gewählten Schwellenwert aufgrund kontinuierlicher Verbesserungen der zugrundeliegenden ML-Leistung zum Zeitpunkt der Durchführung dieses Tutorials möglicherweise geringfügig von den hier angezeigten Werten unterscheiden.)

Abbildung 7. Präzision und Rückruf der Administratorbezeichnung

Abbildung 8. Genauigkeit und Rückruf des Abbruch-Labels

Abbildung 9. Genauigkeit und Rückruf des Verlängerungslabels

Abbildung 10. Genauigkeit und Rückruf der dringenden Bezeichnung

Wir verwenden die folgenden Schwellenwerte für den Rest des Tutorials.

Admin: 0.898 (corresponds to 100% precision at 100% recall)
Cancellation: 0.619 (corresponds to 100% precision at 100% recall)
Renewal: 0.702 (corresponds to 100% precision at 100% recall)
Urgent: 0.179 (corresponds to 83% precision at 100% recall)

Wir können nun die Schwellenwerte auf unser Beispiel anwenden. Die Beschriftung „Abbruch“ gilt seit 0.8374786376953125 > 0.619. Die Bezeichnung „Admin“ gilt nicht seit 0.0164003014564514 < 0.898.

"labels": [
{
"name": ["Cancellation"],
"probability": 0.8374786376953125
},
{
"name": ["Admin"],
"probability": 0.0164003014564514
}
]

Um diesen Prozess zu vereinfachen, können Sie mit der Streams-API Ihre Bezeichnungsschwellenwerte in der Stream-Konfiguration angeben. Wenn angegeben, werden nur Bezeichnungen mit Werten über dem Schwellenwert zurückgegeben.

In einem realen Szenario wird die Zielleistung des Präzisionsrückrufs durch die Kombination von Geschäftsanforderungen und historischer Modellleistung bestimmt. Wenn eine Bezeichnung beispielsweise in der Vergangenheit eine Genauigkeit von 85 % bei einer Wiedererkennung von 55 % erreicht hat, können Sie sich entscheiden, zusätzliche Zeit in das Training zu investieren, bis eine Genauigkeit von bis zu 90 % bei einer Wiedererkennung von 55 % erreicht ist. Anschließend können Sie die neue Modellversion anheften, neue Schwellenwerte auswählen und die Konfiguration Ihrer Anwendung aktualisieren.

Erstellen Sie Ihre Anwendung

Nachdem wir unser Design finalisiert haben, sind wir bereit, mit dem Aufbau unserer Anwendung zu beginnen.

Anheften Ihres Modells

Wechseln Sie zur Seite „Modelle“ und heften Sie das Modell an, indem Sie auf den Umschalter „Speichern“ klicken. Sobald das Modell angeheftet wurde, können Sie über die API darauf zugreifen.

Hinweis:

Wenn Sie diesem Teil des Tutorials mit einem anderen Dataset mit Anmerkungen folgen möchten, müssen Sie sicherstellen, dass es ausreichend mit Anmerkungen versehen ist. Insbesondere erzeugt ein Dataset mit nur wenigen beschrifteten Beispielen ein Modell, das für die meisten Kommentare keine Vorhersagen zurückgibt.

Abbildung 11. Heften Sie die Modellversion an, indem Sie auf den Umschalter „Speichern“ klicken

Streamkonfiguration

In den meisten Fällen reicht es aus, den Streamnamen, den Datasetnamen und die Modellversion sowie die gewünschten Beschriftungen anzugeben. Eine vollständige Liste der Optionen finden Sie in der Referenz.

Für jede Bezeichnung sollten Sie einen Schwellenwert angeben. Informationen zum Auswählen von Bezeichnungsschwellenwerten finden Sie im Abschnitt weiter oben in diesem Tutorial.

curl -X PUT 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "stream": {
        "name": "<my-stream-name>",
        "model": {
          "version": <my-model-version>,
          "label_thresholds": [
            {
              "name": [
                "Parent Label",
                "Child Label"
              ],
              "threshold": <my-label-threshold>
            },
            {
              "name": [
                "Label Without Parent"
              ],
              "threshold": <my-label-threshold>
            }
          ]
        }
      }
    }'

Abruf- und Vorrück-Schleife

Sie können jetzt Ihren Stream verwenden, um Kommentare aus Communications Mining abzurufen. Beachten Sie, dass sich sehr geringe Batchgrößen (z. B. das Abrufen in Batches von je einem Kommentar) auf die Geschwindigkeit auswirken, mit der die Kommentare abgerufen werden.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/fetch' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "size": <my-stream-batch-size>
    }'

Die Anfangsposition des Streams wird auf seine Erstellungszeit festgelegt. Für Entwicklungszwecke ist es oft nützlich, Kommentare abzurufen, die vor dem Stream erstellt wurden. Dazu können Sie den Stream auf einen bestimmten Zeitstempel setzen.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/reset' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "to_comment_created_at": "<YYYY-MM-DDTHH:MM:SS>"
    }'

Wenn Sie die fetch -Anforderung jetzt erneut ausführen, wird sie ab der gleichen Position abgerufen. Um den nächsten Batch von Kommentaren abzurufen, müssen Sie den vorherigen Batch mit einer advance -Anforderung bestätigen. In der advance -Anforderung müssen Sie ein sequence_id , das Sie in Ihrer fetch -Antwort finden.

Die Abruf- und Vorwärts-Schleife stellt sicher, dass Sie nicht versehentlich Kommentare überspringen, wenn Ihre Anwendung während der Verarbeitung fehlschlägt. Beachten Sie, dass Ihre Anwendung in der Lage sein muss, einen Kommentar mehrmals zu sehen, wenn ein Kommentar erfolgreich verarbeitet wird, aber im erweiterten Schritt fehlschlägt.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/advance' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "sequence_id": "<my-sequence-id>"
    }'

Beachten Sie, dass Sie den Dataset-Namen in allen API-Anforderungen angeben müssen, die den Stream verwenden – dies liegt daran, dass Streams unter Datasets eingeschränkt sind.

Prozessergebnisse

Die Antwort enthält Kommentare und vorhergesagte Beschriftungen sowie allgemeine Felder, wie auf den Seiten Kommentare und Beschriftungen und allgemeine Felder beschrieben. Auf diesen Seiten erfahren Sie, wie die Antwort analysiert wird.

Ausnahmebehandlung

Wenn Ihre Anwendung es Benutzern ermöglicht, Elemente zu markieren, die falsch vorhergesagt wurden, können Sie den Ausnahmeendpunkt verwenden, um den entsprechenden Kommentar als Ausnahme in der Plattform zu markieren. Der Ausnahmename ist als Filter im Dataset verfügbar, sodass ein Modelltrainer Ausnahmen überprüfen und kommentieren kann, um das Modell zu verbessern.

curl -X PUT 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/exceptions' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "exceptions": [
        {
          "metadata": {
            "type": "Wrong Prediction"
          },
          "uid": "<comment-uid>"
        },
        {
          "metadata": {
            "type": "Wrong Prediction"
          },
          "uid": "<comment-uid>"
        }
      ]
    }'

Fertig!

Herzlichen Glückwunsch, Sie haben das Communications Mining-Automatisierungs-Tutorial abgeschlossen. Natürlich kann sich Ihre eigene Automatisierungsanwendung von der hier abgedeckten unterscheiden. Wenden Sie sich an den Support, wenn Sie Fragen haben.