Best practice per l'utilizzo del servizio

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

Consulta anche la guida alla progettazione di agenti generici per tutti i tipi di agenti e la guida alla progettazione di 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 audit log

Abilita i log di controllo di accesso ai dati per l'API Dialogflow nel tuo progetto. In questo modo puoi monitorare le modifiche apportate in fase di progettazione gli agenti Dialogflow collegati a questo progetto.

Versioni dell'agente

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

Crea il backup dell'agente

Mantieni aggiornato un backup dell'agente esportato. In questo modo potrai recuperare rapidamente se tu o i membri del tuo team eliminate accidentalmente l'agente o il progetto.

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.

Soprattutto, puoi migliorare il rendimento delle chiamate API di rilevamento dell'intenzione riutilizzando un'istanza della libreria client SessionsClient.

Consulta il riferimento alle sessioni.

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

Aggiornamenti batch all'agente

Se invii molte richieste API di aggiornamento degli agenti individualmente in un breve periodo di tempo, le tue richieste potrebbero essere limitate. Questi metodi API di design 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, patch o delete, utilizza i metodi batchUpdate o batchDelete.
  • Invece di inviare molte richieste di intent create, patch o delete, utilizza i metodi batchUpdate o batchDelete.

Nuovi tentativi in caso di errore dell'API

Quando chiami i metodi dell'API, potresti ricevere risposte di errore. Per alcuni errori è necessario riprovare, poiché spesso sono dovuti a problemi temporanei. Ci sono due tipi di errori:

Inoltre, devi implementare un backoff esponenziale per i tentativi. In questo modo, il sistema può trovare una frequenza accettabile mentre il servizio API è sotto un carico elevato.

Errori dell'API Cloud

Se utilizzi una libreria client fornita da Google, le ripetizioni degli errori dell'API Cloud con backoff esponenziale sono implementate per te.

Se hai implementato la tua libreria client utilizzando REST o gRPC, devi implementare i tentativi di nuovo per il client. Per informazioni sugli errori per i quali devi o non devi riprovare, consulta Proposte di miglioramento dell'API: configurazione del nuovo tentativo automatico.

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, non verrà eseguito automaticamente un nuovo tentativo per gli errori relativi ai webhook. Il codice dovrebbe riprovare per gli errori 503 Service Unavailable ricevuti dal webhook. Consulta la documentazione del servizio webhook per informazioni sui tipi di errori webhook e su come verificarli.

Test di carico

È buona prassi eseguire test di carico per il sistema prima di rilasciare il codice in produzione. Prendi in considerazione questi punti prima di implementare i test di carico:

Riepilogo Dettagli
Aumenta il carico. Il test di carico deve aumentare 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 ha bisogno di tempo per adeguarsi alle richieste di carico, quindi aumenta lentamente la frequenza delle richieste finché il test non raggiunge il carico desiderato.
Le chiamate API sono a pagamento. Ti verranno addebitate le chiamate API durante un test e le chiamate saranno limitate dalla quota del progetto.
Utilizza doppioni di test. Potresti non dover chiamare l'API durante il test di carico. Se lo scopo del test di carico è determinare in che modo il sistema gestisce il carico, spesso è meglio utilizzare un doppio di test anziché le chiamate effettive all'API. Il doppio di test può simulare il comportamento dell'API sotto carico.
Utilizza i tentativi di nuovo. Il test di carico deve eseguire riprova con un backoff.

Chiamare Dialogflow in sicurezza da un dispositivo dell'utente finale

Non devi mai memorizzare le tue chiavi private utilizzate per accedere all'API Dialogflow su un dispositivo dell'utente finale. Questo vale per la memorizzazione delle chiavi direttamente sul dispositivo e per la codifica delle chiavi 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 effettive e autenticate.

Ad esempio, non dovresti creare un'applicazione mobile che chiama direttamente Dialogflow. Per farlo, devi memorizzare le chiavi private su un dispositivo dell'utente finale. L'applicazione mobile deve invece far passare le richieste tramite un servizio proxy sicuro.

Prestazioni

Questa sezione illustra le informazioni sul rendimento di 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).

Prestazioni per operazione

La tabella seguente fornisce informazioni sulle prestazioni tipiche delle operazioni di Dialogflow:

Azione Note
Rilevamento di 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. La misurazione della latenza utilizzando il tempo di esecuzione totale non è consigliata.
Sintesi vocale (streaming) Il tempo di esecuzione totale è determinato principalmente dalla durata dell'audio in uscita. 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.
Agente importazione / esportazione Il rendimento dipende dalle dimensioni dell'agente.
Formazione degli agenti Le prestazioni dipendono 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 principali:

  • Streaming: per le chiamate in streaming (riconoscimento vocale e sintesi), i dati vengono elaborati man mano che arrivano e le risposte vengono restituite il più rapidamente 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. Ecco perché l'esecuzione del playbook è variabile, a seconda della quantità di prompt emessi e della complessità delle chiamate.

Considerazioni importanti sulla latenza

  • Nessuna garanzia sulla latenza:gli SLA di Dialogflow non tengono conto della latenza, anche in caso di throughput pianificato.
  • 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 completo sia uguale al tempo per la prima risposta.