Diese Anleitung enthält Best Practices für die Verwendung des Dialogflow-Dienstes. Diese Richtlinien sind auf mehr Effizienz und Genauigkeit sowie optimale Antwortzeiten des Service ausgelegt.
Im Leitfaden zum allgemeinen Agent-Design finden Sie Best Practices für alle Agent-Typen und im Leitfaden zum Design von Sprach-Agents speziell für das Design von Sprach-Agents.
Produktion
Bevor Sie den Agent in der Produktion ausführen, sollten Sie die folgenden Best Practices implementieren:
- Agent-Versionen verwenden
- Sitzungsclients wiederverwenden
- Fehlerbehandlung mit Wiederholungsversuchen implementieren
Audit-Logs aktivieren
Aktivieren Sie in Ihrem Projekt Audit-Logs zum Datenzugriff für die Dialogflow API. Ähnlich wie bei der Funktion „Änderungsverlauf“ können Sie mit Audit-Logs Änderungen bei der Entwicklung in den Dialogflow CX-Agents verfolgen, die mit dem Projekt verknüpft sind.
Agent-Versionen
Sie sollten daher immer Agent-Versionen für Ihren Produktions-Traffic verwenden. Weitere Informationen finden Sie unter Versionen und Umgebungen.
Agent-Sicherung erstellen
Halten Sie eine aktuelle exportierte Agent-Sicherung bereit. So können Sie schnell eine Wiederherstellung durchführen, wenn Sie oder Ihre Teammitglieder den Agent oder das Projekt versehentlich löschen.
Client wiederverwenden
Sie können die Leistung Ihrer Anwendung verbessern, indem Sie *Client-Clientbibliotheksinstanzen für die gesamte Lebensdauer der Ausführung Ihrer Anwendung wiederverwenden.
Vor allem können Sie die Leistung von API-Aufrufen zur Intent-Erkennung verbessern, indem Sie eine SessionsClient-Clientbibliotheksinstanz wiederverwenden.
Wählen Sie ein Protokoll und eine Version für die Sitzungsreferenz aus:
| Protokoll | V3 | V3beta1 |
|---|---|---|
| REST | Sitzungsressource | Sitzungsressource |
| RPC | Sitzungsoberfläche | Sitzungsoberfläche |
| C++ | SessionsClient | Nicht verfügbar |
| C# | SessionsClient | Nicht verfügbar |
| Go | SessionsClient | Nicht verfügbar |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | Nicht verfügbar | Nicht verfügbar |
| Python | SessionsClient | SessionsClient |
| Ruby | Nicht verfügbar | Nicht verfügbar |
Weitere Informationen hierzu finden Sie im Leitfaden Best Practices für Clientbibliotheken.
Wiederholungen nach API-Fehlern
Beim Aufrufen von API-Methoden können Fehlerantworten zurückgegeben werden. Es gibt einige Fehler, bei denen Sie Wiederholungsversuche vornehmen sollten, da diese Fehler häufig auf vorübergehende Probleme zurückzuführen sind. Es gibt zwei Arten von Fehlern:
- Cloud API-Fehler.
- Fehler, die von Ihrem Webhook-Dienst gesendet wurden.
Darüber hinaus sollten Sie einen exponentiellen Backoff für Wiederholungsversuche implementieren. So kann Ihr System eine akzeptable Rate finden, während der API-Dienst stark ausgelastet ist.
Cloud API-Fehler
Wenn Sie eine von Google bereitgestellte Clientbibliothek verwenden, werden Wiederholungen nach Cloud API-Fehlern mit exponentiellem Backoff für Sie implementiert.
Wenn Sie Ihre eigene Clientbibliothek mit REST oder gRPC implementiert haben, müssen Sie Wiederholungsversuche für Ihren Client implementieren. Informationen zu den Fehlern, nach denen Sie eine Wiederholung durchführen sollten oder nicht, finden Sie unter API-Verbesserungsvorschläge: Automatische Wiederholungskonfiguration.
Webhook-Fehler
Wenn Ihr API-Aufruf einen Webhook-Aufruf auslöst, gibt Ihr Webhook möglicherweise einen Fehler zurück.
Selbst wenn Sie eine von Google bereitgestellte Clientbibliothek verwenden, erfolgt bei Webhook-Fehlern keine automatische Wiederholung.
Ihr Code sollte bei 503 Service Unavailable-Fehlern, die Ihr Webhook erhalten hat, noch einmal eine Anforderung schicken.
In der Dokumentation zum Webhook-Dienst finden Sie Informationen zu den verschiedenen Webhook-Fehlern und dazu, wie Sie nach ihnen suchen können.
Lasttests
Es empfiehlt sich, Lasttests für Ihr System auszuführen, bevor Sie den Code für die Produktion freigeben. Berücksichtigen Sie die folgenden Punkte, bevor Sie Ihre Lasttests implementieren:
| Fazit | Details |
|---|---|
| Erhöhen Sie die Last. | Der Lasttest muss die Last erhöhen, die auf den Dialogflow-Dienst angewendet wird. Der Dienst ist nicht für die Verarbeitung von Last-Bursts ausgelegt, die bei echtem Traffic selten auftreten. Es dauert eine Weile, bis sich der Dienst an die Lastanforderungen angepasst hat. Erhöhen Sie daher die Anfragerate langsam, bis der Test die gewünschte Last erreicht. |
| Für API-Aufrufe werden Gebühren fällig. | Während eines Tests werden Ihnen API-Aufrufe in Rechnung gestellt und die Aufrufe werden durch das Projektkontingent begrenzt. |
| Verwenden Sie Test-Doubles. | Während des Lasttests müssen Sie die API möglicherweise nicht aufrufen. Wenn Sie mit dem Lasttest ermitteln möchten, wie Ihr System mit der Last umgeht, ist es oft besser, ein Test-Double anstelle von tatsächlichen API-Aufrufen zu verwenden. Ihr Test-Double kann das Verhalten der API unter Last simulieren. |
| Führen Sie Wiederholungsversuche durch. | Ihr Lasttest muss Wiederholungsversuche mit einem Backoff ausführen. |
Dialogflow sicher von einem Endnutzergerät aus aufrufen
Speichern Sie Ihre privaten Schlüssel nie für den Zugriff auf die Dialogflow API auf einem Endnutzergerät. Dies gilt für die direkte Speicherung von Schlüsseln auf dem Gerät und für die harte Codierung von Schlüsseln in Anwendungen. Wenn Ihre Clientanwendung die Dialogflow API aufrufen muss, sollte sie Anfragen an einen entwicklereigenen Proxydienst auf einer sicheren Plattform senden. Der Proxydienst kann die tatsächlichen, authentifizierten Dialogflow-Aufrufe ausführen.
Beispielsweise sollten Sie keine mobile Anwendung erstellen, die Dialogflow direkt aufruft. Dazu müssten Sie private Schlüssel auf einem Endnutzergerät speichern. Ihre mobile Anwendung sollte stattdessen Anfragen über einen sicheren Proxydienst weiterleiten.
Leistung
In diesem Abschnitt finden Sie Informationen zur Leistung verschiedener Vorgänge in Dialogflow. Die Latenz ist wichtig, um reaktionsschnelle Agents zu entwickeln und realistische Leistungserwartungen zu setzen. Diese Werte sind jedoch nicht Teil des Dialogflow-SLA.
Wenn Sie Tools für Monitoring und Benachrichtigungen entwickeln, beachten Sie, dass Large Language Models (LLMs) und die Sprachverarbeitung in der Regel mit Streaming-Methoden verarbeitet werden. Antworten werden so schnell wie möglich an den Client gesendet, oft viel früher als die Gesamtdauer des Methodenaufrufs. Weitere Informationen finden Sie unter den Best Practices mit Large Language Models (LLMs).
Leistung pro Vorgang
Die folgende Tabelle enthält Informationen zur typischen Leistung von Dialogflow-Vorgängen:
| Aktion | Hinweise |
|---|---|
| Workflow-Aktionen: Zustands-Handler | Schnellster Vorgang |
| Abläufe: Intent-Erkennung (Text) | Schnellster Vorgang |
| Abläufe: Parametererkennung (Text) | Schneller Vorgang |
| Spracherkennung (Streaming) | Daten werden verarbeitet und Antworten so schnell wie möglich zurückgegeben. Die Gesamtausführungszeit wird hauptsächlich durch die Länge der Audioeingabe bestimmt. Es wird nicht empfohlen, die Latenz anhand der Gesamtausführungszeit zu messen. |
| Sprachsynthese (Streaming) | Die Gesamtausführungszeit wird hauptsächlich durch die Länge der Audioausgabe bestimmt. Daten werden verarbeitet und Antworten so schnell wie möglich zurückgegeben. |
| Datenspeicher: generative KI deaktiviert | Die tatsächliche Zeit hängt von der Größe des Datenspeichers ab. |
| Datenspeicher: generative KI aktiviert | Die Leistung hängt von der Größe des Datenspeichers, dem verwendeten Language Model und der Länge der Prompt-Ausgabe und -Eingabe ab. |
| Generativer Fallback | Die Leistung hängt von der verwendeten Sprache und der Länge der Prompt-Ausgabe und -Eingabe ab. |
| Generatoren | Die Leistung hängt vom verwendeten Language Model, der Komplexität der Prompt-Eingabe und -Ausgabe und der Anzahl der Generatoren in der Runde ab. Mehrere Generatoren in einer einzelnen Runde führen zu mehreren Aufrufen eines Language Models. |
| Ausführung von Playbooks | Die Leistung hängt von der Komplexität des Playbooks, der Anzahl der Prompts und der Ausführungszeit aller aufgerufenen Tools ab. Die Länge der Prompt-Ausgabe und -Eingabe wirkt sich auf diese Leistung aus. Mehrere Language Model-Prompts können seriell ausgeführt werden, was sich auf die Gesamtaufrufdauer auswirkt. |
| Playbooks: Tools | Die Leistung hängt von der zugrunde liegenden Ausführung des Tools ab. |
| Webhook-Aufrufe | Die Leistung wird direkt durch die Ausführungszeit Ihres Codes im Webhook bestimmt. |
| Agent importieren / exportieren | Die Leistung hängt von der Größe des Agents ab. |
| Schulung für Kundenservicemitarbeiter | Die Leistung hängt von der Anzahl der Abläufe, Intents und Trainingsbeispiele ab. Das Training großer Agents kann mehrere Minuten dauern. |
| Umgebungserstellung | Beim Erstellen einer Umgebung wird der Agent trainiert. Die Gesamtzeit hängt also von der Größe und Komplexität des Agents ab. |
Das Wichtigste im Überblick :
- Streaming:Bei Streaming-Aufrufen (Spracherkennung und -synthese) werden Daten verarbeitet, sobald sie eingehen, und Antworten werden so schnell wie möglich zurückgegeben. Die erste Antwort erfolgt in der Regel viel schneller als die Gesamtdauer des Aufrufs.
- Playbooks:Ein LLM-Prompt wird anhand der Playbook- Anweisungen, des Unterhaltungskontexts und der Tool-Eingabe erstellt. Mehrere LLM-Prompts können in einem einzelnen Playbook-Aufruf ausgeführt werden. Daher ist die Ausführung des Playbooks variabel und hängt von der Anzahl der ausgegebenen Prompts und der Komplexität der Aufrufe ab.
Wichtige Hinweise zur Latenz
- Keine Latenzgarantien:Die Dialogflow-SLAs berücksichtigen die Latenz nicht, auch nicht bei bereitgestelltem Durchsatz.
- LLM-Latenz:Die LLM-Verarbeitung kann zu einer erheblichen Latenz führen. Berücksichtigen Sie dies beim Design Ihres Agents und bei den Erwartungen der Nutzer.
- Monitoring und Benachrichtigungen:Wenn Sie Monitoring und Benachrichtigungen einrichten, berücksichtigen Sie die Streaming-Natur der Antworten von LLMs und Sprachdiensten. Gehen Sie nicht davon aus, dass die vollständige Antwortzeit der Zeit bis zur ersten Antwort entspricht.