Questa guida fornisce le best practice per l'utilizzo del servizio Dialogflow. Queste linee guida sono pensate per una maggiore efficienza e accuratezza e per tempi di risposta ottimali da parte del servizio.
Dovresti anche consultare la guida Progettazione generale degli agenti per tutti i tipi di agenti e la guida Progettazione di agenti vocali specifica per la progettazione di agenti vocali.
Messa in produzione
Prima di eseguire l'agente in produzione, assicurati di implementare le seguenti best practice:
- Utilizzare le versioni degli agenti
- Riutilizzare i client di sessione
- Implementa la gestione degli errori con i tentativi
Abilita audit log
Abilita gli audit log di accesso ai dati per l'API Dialogflow nel tuo progetto. In questo modo, puoi monitorare le modifiche apportate in fase di progettazione negli agenti Dialogflow collegati a questo progetto.
Versioni dell'agente
Devi sempre utilizzare le versioni dell'agente per il traffico di produzione. Per saperne di più, consulta Versioni e ambienti.
Crea il backup dell'agente
Mantieni un backup esportato dell'agente aggiornato. In questo modo potrai recuperare rapidamente l'agente o il progetto se tu o i membri del tuo team li eliminate accidentalmente.
Riutilizzo del client
Puoi migliorare il rendimento della tua applicazione
riutilizzando le istanze della libreria client *Client
per tutta la durata dell'esecuzione dell'applicazione.
Ancora più importante,
puoi migliorare il rendimento delle chiamate API detect intent
riutilizzando un'istanza della libreria client SessionsClient.
Per saperne di più, consulta la guida alle best practice per le librerie client.
Aggiornamenti batch all'agente
Se invii molte richieste API di aggiornamento degli agenti individuali in un breve periodo di tempo, le tue richieste potrebbero essere limitate. Questi metodi API in fase di progettazione non sono implementati per gestire tassi di aggiornamento elevati per un singolo agente.
Alcuni tipi di dati hanno metodi batch per questo scopo:
- Anziché inviare molte richieste
EntityTypes
create,patchodelete, utilizza i metodibatchUpdateobatchDelete. - Invece di inviare molte richieste
Intents
create,patchodelete, utilizza i metodibatchUpdateobatchDelete.
Tentativi di ripetizione degli errori API
Quando chiami i metodi API, potresti ricevere risposte di errore. Alcuni errori devono essere ritentati, perché spesso sono dovuti a problemi temporanei. Ci sono due tipi di errori:
- Errori dell'API Cloud.
- Errori inviati dal tuo servizio webhook.
Inoltre, devi implementare un backoff esponenziale per i nuovi tentativi. In questo modo, il sistema può trovare una tariffa accettabile mentre il servizio API è sottoposto a un carico elevato.
Errori API Cloud
Se utilizzi una libreria client fornita da Google, i tentativi di ripetizione degli errori dell'API Cloud con backoff esponenziale vengono implementati per te.
Se hai implementato la tua libreria client utilizzando REST o gRPC, devi implementare i tentativi per il client. Per informazioni sugli errori per cui è consigliabile o sconsigliabile riprovare, consulta Proposte di miglioramento delle API: configurazione dei 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 ritentati automaticamente.
Il codice deve riprovare a eseguire l'operazione in caso di errori 503 Service Unavailable
ricevuti dal webhook.
Per informazioni sui tipi di errori webhook e su come verificarli, consulta la documentazione del servizio webhook.
Test di carico
È una best practice eseguire il test di carico per il sistema prima di rilasciare il codice in produzione. Considera questi punti prima di implementare i test di carico:
| Riepilogo | Dettagli |
|---|---|
| Aumenta il carico. | Il test di carico deve aumentare gradualmente il carico applicato al servizio Dialogflow. Il servizio non è progettato per gestire picchi improvvisi di carico, che si verificano raramente con il traffico reale. Il servizio impiega del tempo per adattarsi alle richieste di carico, quindi aumenta lentamente il tasso di richieste finché il test non raggiunge il carico desiderato. |
| Le chiamate API vengono addebitate. | Le chiamate API verranno addebitate durante un test e saranno limitate dalla quota del progetto. |
| Utilizza i test doppi. | Potresti non dover chiamare l'API durante il test di carico. Se lo scopo del test di carico è determinare come il tuo sistema gestisce il carico, spesso è meglio utilizzare un test double al posto delle chiamate effettive all'API. Il test double può simulare il comportamento dell'API sotto carico. |
| Utilizza i tentativi. | Il test di carico deve eseguire tentativi con un backoff. |
Chiamare Dialogflow in modo sicuro da un dispositivo utente finale
Non devi mai archiviare le chiavi private utilizzate per accedere all'API Dialogflow su un dispositivo utente finale. Ciò vale per l'archiviazione delle chiavi direttamente sul dispositivo e per la codifica delle chiavi nelle applicazioni. Quando l'applicazione client deve chiamare l'API Dialogflow, deve inviare le 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 chiama direttamente Dialogflow. In questo modo, dovresti memorizzare le chiavi private su un dispositivo dell'utente finale. La tua applicazione mobile deve invece inoltrare le richieste tramite un servizio proxy sicuro.
Prestazioni
Questa sezione descrive le informazioni sul rendimento per varie operazioni all'interno di Dialogflow. Comprendere la latenza è importante per progettare agenti reattivi e impostare aspettative di rendimento realistiche, anche se questi valori non fanno parte dello SLA di Dialogflow.
Quando crei strumenti di monitoraggio e avviso, tieni presente che i modelli linguistici di grandi dimensioni (LLM) e l'elaborazione vocale vengono in genere gestiti utilizzando metodi di streaming. Le risposte vengono inviate al client il prima possibile, spesso molto prima della durata totale della chiamata al metodo. Per saperne di più, consulta le best practice per i modelli linguistici di grandi dimensioni (LLM).
Rendimento per operazione
La tabella seguente fornisce informazioni sulle prestazioni tipiche delle operazioni di Dialogflow:
| Azione | Note |
|---|---|
| Rilevamento dell'intent (testo) | Funzionamento rapido |
| Rilevamento dei parametri (testo) | Funzionamento rapido |
| Riconoscimento vocale (streaming) | I dati vengono elaborati e le risposte vengono restituite il prima possibile. Il tempo totale di esecuzione è determinato principalmente dalla durata dell'audio di input. Non è consigliabile misurare la latenza utilizzando il tempo di esecuzione totale. |
| Sintesi vocale (streaming) | Il tempo totale di esecuzione è determinato principalmente dalla durata dell'audio di output. I dati vengono elaborati e le risposte vengono restituite il più rapidamente possibile. |
| Chiamate webhook | Il rendimento è determinato direttamente dal tempo di esecuzione del codice nell'webhook. |
| Importa / Esporta agente | Il rendimento dipende dalle dimensioni dell'agente. |
| Formazione degli agenti | Il rendimento dipende dal numero di flussi, intent e frasi di addestramento. L'addestramento di agenti di grandi dimensioni può richiedere decine di minuti. |
| Creazione dell'ambiente | La creazione di un ambiente prevede l'addestramento dell'agente, pertanto il tempo totale dipenderà dalle dimensioni e dalla complessità dell'agente. |
Note chiave:
- Streaming:per le chiamate in streaming (riconoscimento e sintesi vocale), i dati vengono elaborati man mano che arrivano e le risposte vengono restituite il prima possibile. Ciò significa che la risposta iniziale è in genere molto più rapida del tempo totale della chiamata.
- Playbook: un prompt LLM viene creato in base alle istruzioni del playbook, al contesto della conversazione e all'input dello strumento. È possibile eseguire più prompt LLM in una singola chiamata del playbook. Per questo motivo, l'esecuzione del playbook è variabile, a seconda del numero di prompt emessi e della complessità delle chiamate.
Considerazioni importanti sulla latenza
- Nessuna garanzia di latenza: gli SLA di Dialogflow non prendono in considerazione la latenza, nemmeno con Throughput riservato.
- Latenza LLM:tieni presente che l'elaborazione LLM può introdurre una latenza significativa. Tieni conto di questo aspetto nella progettazione dell'agente e nelle aspettative degli utenti.
- Monitoraggio e avvisi:quando configuri il monitoraggio e gli avvisi, tieni conto della natura in streaming delle risposte degli LLM e dei servizi vocali. Non dare per scontato che il tempo di risposta totale sia uguale al tempo per la prima risposta.