Questa guida fornisce le best practice per l'utilizzo del servizio Dialogflow. Queste linee guida sono state concepite per aumentare l'efficienza e la precisione, nonché per garantire tempi di risposta ottimali da parte del servizio.
Consulta anche la guida generale alla progettazione degli agenti per tutti i tipi di agenti e la guida alla progettazione degli agenti vocali specifica per la progettazione di agenti vocali.
Produzione
Prima di eseguire l'agente in produzione, assicurati di implementare le seguenti best practice:
- Utilizzare le versioni dell'agente
- Riutilizzare i client di sessione
- Implementare la gestione degli errori con nuovi tentativi
Versioni dell'agente
Devi sempre utilizzare le versioni dell'agente per il traffico di produzione. Per i dettagli, consulta Versioni e ambienti.
Crea backup dell'agente
Mantieni un backup degli agenti esportato aggiornato. In questo modo potrai recuperare rapidamente se tu o i membri del tuo team elimini accidentalmente l'agente o il progetto.
Riutilizzo client
Puoi migliorare le prestazioni della tua applicazione riutilizzando *Client istanze della libreria client per la durata dell'esecuzione dell'applicazione.
Soprattutto, puoi migliorare le prestazioni del rilevamento delle chiamate API Intent riutilizzando un'istanza della libreria client SessionsClient.
Seleziona un protocollo e la versione come riferimento per la sessione:
| Protocollo | V3 | Versione 3 beta 1 |
|---|---|---|
| REST | Risorsa sessione | Risorsa sessione |
| RPC | Interfaccia della sessione | Interfaccia della sessione |
| C++ | SessionsClient | Non disponibile |
| C# | SessionsClient | Non disponibile |
| Go | SessionsClient | Non disponibile |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | Non disponibile | Non disponibile |
| Python | SessionsClient | SessionsClient |
| Ruby | Non disponibile | Non disponibile |
Per ulteriori informazioni, consulta la Guida alle best practice per le librerie client.
Nuovi tentativi per errori dell'API
Quando chiami i metodi API, potresti ricevere risposte di errore. Ci sono alcuni errori che dovrebbero essere ritentati, perché spesso sono dovuti a problemi temporanei. Ci sono due tipi di errori:
- Errori relativi all'API Cloud.
- Errori inviati dal servizio webhook.
Inoltre, devi implementare un backoff esponenziale per i nuovi tentativi. Ciò consente al sistema di trovare una tariffa accettabile quando il servizio API è sottoposto a un carico elevato.
Errori relativi all'API Cloud
Se utilizzi una libreria client fornita da Google, vengono implementati automaticamente i nuovi tentativi di errore dell'API Cloud con backoff esponenziale.
Se hai implementato la tua libreria client utilizzando REST o gRPC, devi implementare i nuovi tentativi per il client. Per informazioni sugli errori che dovresti o non devi riprovare, consulta Proposte di miglioramento delle API: configurazione automatica dei nuovi tentativi.
Errori relativi al webhook
Se la chiamata API attiva una chiamata webhook,
il webhook potrebbe restituire un errore.
Anche se utilizzi una libreria client fornita da Google, gli errori webhook non verranno ritentati automaticamente.
Il codice dovrebbe riprovare 503 Service Unavailable
errori ricevuti dal webhook.
Consulta la documentazione del servizio webhook per informazioni sui tipi di errori del webhook e su come verificarli.
Test di carico
Come best practice, conviene eseguire un test di carico del sistema prima di rilasciare il codice in produzione. Prima di implementare i test di carico, tieni presente questi punti:
| Riepilogo | Dettagli |
|---|---|
| Incrementa il carico. | Il test di carico deve aumentare il carico applicato al servizio Dialogflow. Il servizio non è progettato per gestire bruschi cicli di carico, che si verificano raramente con il traffico reale. L'adattamento del servizio alla domanda di carico richiede tempo, quindi aumenta lentamente la tasso di richieste finché il test non raggiunge il carico desiderato. |
| Le chiamate API sono a pagamento. | Ti verrà addebitato un costo per le chiamate API durante un test e le chiamate saranno limitate dalla quota del progetto. |
| Usate test doppi. | Potrebbe non essere necessario chiamare l'API durante il test di carico. Se lo scopo del test di carico è determinare in che modo il tuo sistema gestisce il carico, spesso è preferibile utilizzare un doppio di test invece delle chiamate effettive all'API. Il test duplicato può simulare il comportamento dell'API sotto carico. |
| Usa nuovi tentativi. | Il test di carico deve eseguire nuovi tentativi con un backoff. |
Chiamare Dialogflow in modo sicuro da un dispositivo di utente finale
Non dovresti mai archiviare le chiavi private utilizzate per accedere all'API Dialogflow su un dispositivo di un utente finale. Ciò vale per la memorizzazione diretta delle chiavi sul dispositivo e per l'hard coding delle chiavi nelle applicazioni. Quando l'applicazione client deve chiamare l'API Dialogflow, dovrebbe inviare richieste a un servizio proxy di proprietà dello sviluppatore su una piattaforma sicura. Il servizio proxy può effettuare le chiamate Dialogflow effettive e autenticate.
Ad esempio, non devi creare un'applicazione mobile che chiami direttamente Dialogflow. In questo modo dovrai archiviare le chiavi private sul dispositivo di un utente finale. L'applicazione per dispositivi mobili deve invece passare le richieste attraverso un servizio proxy sicuro.