Best practice per l'utilizzo del servizio

Questa guida fornisce le best practice per l'utilizzo del servizio Dialogflow. Queste linee guida sono pensate per una maggiore efficienza e precisione, nonché per tempi di risposta ottimali da parte del servizio.

Dovresti anche consultare la guida generale alla progettazione degli agenti per tutti i tipi di agente 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:

Abilita gli audit log

Abilitare gli audit log di accesso ai dati per l'API Dialogflow nel tuo progetto. In questo modo puoi tenere traccia delle modifiche in fase di progettazione negli agenti Dialogflow collegati a questo progetto.

Versioni agente

Devi sempre utilizzare le versioni dell'agente per il traffico di produzione. Per maggiori dettagli, consulta Versioni e ambienti.

Crea backup dell'agente

Mantieni aggiornato un backup degli agenti esportati aggiornati. In questo modo potrai eseguire rapidamente il ripristino 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 della durata di esecuzione dell'applicazione.

Inoltre, puoi migliorare le prestazioni del rilevamento delle chiamate API di intent riutilizzando un'istanza della libreria client SessionsClient.

Consulta la sezione di riferimento Sessioni.

Per ulteriori informazioni sull'argomento, consulta la guida Best practice con le librerie client.

Aggiornamenti batch all'agente

Se invii molte richieste API di aggiornamento dell'agente individuali in un breve periodo di tempo, le tue richieste potrebbero essere limitate. Questi metodi dell'API design-time non vengono implementati per gestire frequenze di aggiornamento elevate per un singolo agente.

A questo scopo, alcuni tipi di dati dispongono di metodi batch:

  • Anziché inviare molte richieste di EntityTypes create, patch o delete, utilizza i metodi batchUpdate o batchDelete.
  • Anziché inviare molte richieste di intent create, patch o delete, utilizza i metodi batchUpdate o batchDelete.

Nuovi tentativi errori API

Quando chiami metodi API, potresti ricevere risposte di errore. Ci sono alcuni errori che devono essere riprovati, poiché spesso sono dovuti a problemi temporanei. Ci sono due tipi di errori:

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 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 dell'API: configurazione dei nuovi tentativi automatici.

Errori 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 riprovati automaticamente. Il codice deve riprovare a 503 Service Unavailable errori ricevuti dal webhook. Consulta la documentazione del servizio webhook per informazioni sui tipi di errori relativi al webhook e su come verificarli.

Test di carico

Una best practice consiste nell'eseguire un test di carico del sistema prima di rilasciare il codice in produzione. Prima di implementare i test di carico, considera 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 burst bruschi di carico, che si verificano raramente con il traffico reale. Affinché il servizio si adatti alle esigenze del carico, aumenta lentamente la tasso di richieste fino a quando il test non raggiunge il carico desiderato.
Le chiamate API sono addebitate. Ti verrà addebitato un costo per le chiamate API durante un test e le chiamate saranno limitate dalla quota di progetto.
Usa i 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 è meglio utilizzare un doppio di test invece delle chiamate effettive all'API. Il test doppio 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 dell'utente finale

Non devi mai archiviare le chiavi private utilizzate per accedere all'API Dialogflow su un dispositivo dell'utente finale. Questo vale per l'archiviazione delle chiavi direttamente sul dispositivo e per le chiavi hardcoded nelle applicazioni. Quando l'applicazione client deve chiamare l'API Dialogflow, deve inviare richieste a un servizio proxy di proprietà dello sviluppatore su una piattaforma sicura. Il servizio proxy può effettuare le chiamate Dialogflow autenticate.

Ad esempio, non creare un'applicazione mobile che chiami direttamente Dialogflow. Ciò richiederebbe di archiviare le chiavi private su un dispositivo dell'utente finale. L'applicazione mobile deve invece passare le richieste attraverso un servizio proxy sicuro.