Dieser Leitfaden 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.
Weitere Informationen finden Sie in der Anleitung zum allgemeinen Design von Agents für alle Agent-Typen und im Leitfaden zum Design von Voice-Agents speziell für das Entwerfen 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
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
Sorgen Sie für eine aktuelle exportierte Agent-Sicherung. So können Sie schnell eine Wiederherstellung durchführen, wenn Sie oder Ihre Teammitglieder den Agent oder das Projekt versehentlich löschen.
Wiederverwendung durch Client
Sie können die Leistung Ihrer Anwendung verbessern, wenn Sie *Client-Clientbibliotheksinstanzen für die Dauer der Ausführungsdauer Ihrer Anwendung wiederverwenden.
Sie können vor allem die Leistung von API-Aufrufen zur Intent-Erkennung verbessern, wenn 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 |
| Einfach loslegen (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 dazu finden Sie im Leitfaden zu 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.