Best Practices für die Nutzung von Diensten

In diesem Leitfaden finden Sie Best Practices für die Verwendung des Dialogflow-Dienstes. Diese Richtlinien sind auf mehr Effizienz und Genauigkeit sowie optimale Antwortzeiten des Service ausgelegt.

Sehen Sie sich auch den Leitfaden zum allgemeinen Agent-Design für alle Agenttypen und den Leitfaden zum Design von Sprach-Agenten speziell für das Design von Sprach-Agenten an.

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. So können Sie Änderungen bei der Entwicklung in den Dialogflow-Agents verfolgen, die mit diesem 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.

Sicherung für Kundenservicemitarbeiter erstellen

Behalten Sie ein aktuelles exportiertes Back-up des Agents. So können Sie schnell wiederherstellen, wenn Sie oder Ihre Teammitglieder den Kundenservicemitarbeiter oder das Projekt versehentlich löschen.

Wiederverwendung des Clients

Sie können die Leistung Ihrer Anwendung verbessern, indem Sie *Client-Clientbibliotheksinstanzen während der gesamten Ausführungsdauer Ihrer Anwendung wiederverwenden.

Vor allem können Sie die Leistung der Intent-Erkennung bei API-Aufrufen verbessern, indem Sie eine SessionsClient-Clientbibliotheks-Instanz wiederverwenden.

Weitere Informationen finden Sie in der Referenz zu Sitzungen.

Weitere Informationen hierzu finden Sie im Leitfaden Best Practices für Clientbibliotheken.

Batch-Updates für den Agent

Wenn Sie viele einzelne API-Anfragen zur Aktualisierung des Agents über einen kurzen Zeitraum senden, kann es bei Ihren Anfragen zu einer Drosselung kommen. Diese API-Methoden für die Entwicklung wurden nicht implementiert, um hohe Aktualisierungsraten für einen einzelnen Agent zu verarbeiten.

Einige Datentypen verfügen über Batchmethoden für diesen Zweck:

• Statt viele Anfragen für die EntityTypes create, patch oder delete zu senden, verwenden Sie die Methoden batchUpdate oder batchDelete.
• Statt viele Anfragen für die Intents create, patch oder delete zu senden, verwenden Sie die Methoden batchUpdate oder batchDelete.

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.

Hinweis: Einige Dialogflow-Integrationen wie Dialogflow Messenger bieten sowohl Clientcode als auch einen Proxydienst, ähnlich der obigen Beschreibung. Der Proxydienst antwortet nur dann auf Anfragen, wenn die Integration aktiviert ist. Zur Verbesserung dieser Integrationen erfordert der Proxydienst möglicherweise keine Authentifizierung. Die Proxydienst-API ist auf eine kleine Teilmenge von Dialogflow API-Methoden beschränkt, die für die Integration erforderlich sind. Darüber hinaus bietet der Proxydienst nie Zugriff auf administrative Google Cloud- oder Dialogflow-APIs, ohne dass eine Authentifizierung erforderlich ist. Diese eingeschränkte Proxy-API verringert die Sicherheitslücke.

Leistung

In diesem Abschnitt finden Sie Leistungsinformationen zu verschiedenen Vorgängen in Dialogflow. Die Latenz ist wichtig, um responsive Kundenservicemitarbeiter zu entwickeln und realistische Leistungserwartungen festzulegen. Diese Werte sind jedoch nicht Teil der Dialogflow-SLA.

Beachten Sie beim Erstellen von Monitoring- und Benachrichtigungstools, dass Large Language Models (LLMs) und die Sprachverarbeitung in der Regel mit Streamingmethoden 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 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
Intent-Erkennung (Text)	Schnelle Bedienung
Parametererkennung (Text)	Schnelle Bedienung
Spracherkennung (Streaming)	Die Daten werden so schnell wie möglich verarbeitet und die Antworten zurückgegeben. Die Gesamtausführungszeit wird hauptsächlich durch die Länge der Audioeingaben bestimmt. Die Messung der Latenz anhand der Gesamtausführungszeit wird nicht empfohlen.
Sprachsynthese (Streaming)	Die Gesamtausführungszeit wird hauptsächlich durch die Länge der Audioausgabe bestimmt. Die Daten werden so schnell wie möglich verarbeitet und die Antworten zurückgegeben.
Webhook-Aufrufe	Die Leistung wird direkt durch die Ausführungszeit Ihres Codes im Webhook bestimmt.
Import-/Export-Agent	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 Trainingssätze ab. Das Training großer Agenten kann mehrere Minuten dauern.
Umgebungserstellung	Beim Erstellen einer Umgebung wird der Agent trainiert. Die Gesamtzeit hängt daher von der Größe und Komplexität des Agents ab.

Wichtige Hinweise:

• Streaming:Bei Streamingaufrufen (Spracherkennung und ‑synthese) werden die Daten bei Eingang verarbeitet und die Antworten so schnell wie möglich zurückgegeben. Das bedeutet, dass die anfängliche Antwort in der Regel viel schneller erfolgt als die Gesamtdauer des Anrufs.
• Playbooks:Ein LLM-Prompt wird anhand der Playbook-Anweisungen, des Konversationskontexts und der Tool-Eingabe erstellt. Mehrere LLM-Prompts können in einem einzigen Playbook-Aufruf ausgeführt werden. Daher ist die Ausführung des Playbooks variabel und hängt von der Anzahl der 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 bei der Gestaltung des Bots und den Erwartungen der Nutzer.
• Überwachung und Benachrichtigungen: Berücksichtigen Sie bei der Einrichtung von Monitoring und Benachrichtigungen die gestreamte Natur der Antworten von LLMs und Sprachdiensten. Angenommen, die gesamte Antwortzeit entspricht der Zeit bis zur ersten Antwort.