Este guia apresenta as práticas recomendadas para usar o serviço do Dialogflow. Estas diretrizes foram criadas para aumentar a eficiência e a precisão, bem como otimizar os tempos de resposta do serviço.
Consulte também o guia de design de agentes gerais para todos os tipos de agentes e o guia de design de agentes de voz especificamente para criar agentes de voz.
Produção
Antes de executar seu agente na produção, implemente as práticas recomendadas de produção:
- Usar versões de agente
- Reutilizar clientes da sessão
- Implementar o tratamento de erros com novas tentativas
Ativar registros de auditoria
Ative os registros de auditoria de acesso a dados da API Dialogflow no seu projeto. Assim como o recurso Histórico de mudanças, os registros de auditoria ajudam a rastrear as mudanças no tempo de design nos agentes do Dialogflow CX associados ao projeto.
Versões de agente
Use sempre versões de agente no tráfego de produção. Veja os detalhes em Versões e ambientes.
Criar backup do agente
Mantenha um backup exportado do agente atualizado. Isso permite uma recuperação rápida se você ou os membros da sua equipe excluírem acidentalmente o agente ou o projeto.
Reutilização do cliente
Para melhorar o desempenho do seu aplicativo, reutilize instâncias da biblioteca de cliente *Client durante todo o ciclo de vida de execução do aplicativo.
O mais importante é que você pode melhorar o desempenho das chamadas de API de detecção de intent
reutilizando uma instância da biblioteca de cliente SessionsClient.
Selecione um protocolo e uma versão para a referência de sessão:
| Protocolo | V3 | V3beta1 |
|---|---|---|
| REST | Recurso da sessão | Recurso da sessão |
| RPC (remote procedure call) | Interface da sessão | Interface da sessão |
| C++ | SessionsClient | Indisponível |
| C# | SessionsClient | Indisponível |
| Go | SessionsClient | Indisponível |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | Indisponível | Indisponível |
| Python | SessionsClient | SessionsClient |
| Ruby | Indisponível | Indisponível |
Saiba mais no guia de Práticas recomendadas com bibliotecas de cliente.
Novas tentativas após um erro na API
Ao chamar métodos de API, você pode receber respostas de erro. Há algumas solicitações que devem ser repetidas porque os erros costumam ocorrer devido a problemas temporários. Existem dois tipos de erro:
- Erros da API Cloud.
- Erros enviados do seu serviço de webhook.
Além disso, implemente uma espera exponencial para novas tentativas. Isso permite que o sistema encontre uma taxa aceitável enquanto o serviço da API está com carga intensa.
Erros da API Cloud
Se você estiver usando uma biblioteca de cliente fornecida pelo Google, novas tentativas de erro da API do Cloud com espera exponencial serão implementadas para você.
Se você implementou sua própria biblioteca de cliente usando REST ou gRPC, deverá implementar as novas tentativas para seu cliente. Para saber mais sobre os erros que podem ser repetidos ou não, consulte Propostas de melhoria da API: configuração de nova tentativa automática.
Erros de webhook
Se a chamada de API acionar uma chamada de webhook,
ele poderá retornar um erro.
Mesmo que você esteja usando uma biblioteca de cliente fornecida pelo Google,
os erros de webhook não serão repetidos automaticamente.
Seu código precisa repetir 503 Service Unavailable
erros recebidos do webhook.
Consulte a documentação do
serviço de webhook
para informações sobre os tipos de erros de
webhook e como verificá-los.
Teste de carga
É uma prática recomendada executar testes de carga no seu sistema antes de liberar o código para produção. Considere estes pontos antes de implementar seus testes de carga:
| Resumo | Details |
|---|---|
| Aumente a carga. | Seu teste de carga precisa aumentar a carga aplicada ao serviço do Dialogflow. O serviço não foi projetado para processar explosões bruscas de carga, que raramente ocorrem com o tráfego real. Ele demora para se ajustar às demandas de carga. Por isso, aumente a taxa de solicitação lentamente, até que o teste atinja a carga desejada. |
| As chamadas de API são cobradas. | Você será cobrado por chamadas de API durante um teste, e as chamadas serão limitadas pela cota do projeto. |
| Use duplas de teste. | Talvez não seja necessário chamar a API durante o teste de carga. Se a finalidade do teste for determinar como seu sistema processa a carga, é melhor usar uma dupla de teste no lugar das chamadas reais para a API. A dupla de teste pode simular o comportamento da API com a carga. |
| Use as novas tentativas. | Seu teste de carga precisa executar novas tentativas com uma espera. |
Como chamar o Dialogflow com segurança de um dispositivo de usuário final
Nunca armazene as chaves privadas usadas para acessar a API Dialogflow em um dispositivo do usuário final. Isso se aplica ao armazenamento de chaves diretamente no dispositivo e à codificação de chaves em aplicativos. Quando o aplicativo cliente precisa chamar a API Dialogflow, ele precisa enviar solicitações para um serviço de proxy do desenvolvedor em uma plataforma segura. O serviço de proxy pode fazer chamadas reais do Dialogflow.
Por exemplo, não crie um aplicativo para dispositivos móveis que chame o Dialogflow diretamente. Para fazer isso, você precisa armazenar chaves privadas em um dispositivo de usuário final. Seu aplicativo para dispositivos móveis precisa transmitir solicitações por meio de um serviço de proxy seguro.
Desempenho
Esta seção descreve informações de desempenho para várias operações no Dialogflow. É importante entender a latência para projetar agentes responsivos e definir expectativas de desempenho realistas, embora esses valores não façam parte do SLA do Dialogflow.
Ao criar ferramentas de monitoramento e alertas, observe que os modelos de linguagem grandes (LLMs) e o processamento de voz geralmente são processados usando métodos de streaming. As respostas são enviadas ao cliente assim que possível, muitas vezes bem antes da duração total da chamada de método. Para mais informações, consulte as Práticas recomendadas com modelos de linguagem grandes (LLMs).
Performance por operação
A tabela a seguir contém informações sobre o desempenho típico das operações do Dialogflow:
| Ação | Observações |
|---|---|
| Ações de fluxo: manipuladores de estado | Operação mais rápida |
| Fluxos: detecção de intent (texto) | Operação mais rápida |
| Fluxos: detecção de parâmetros (texto) | Operação rápida |
| Reconhecimento de fala (streaming) | Os dados são processados e as respostas são retornadas assim que possível. O tempo total de execução é determinado principalmente pela duração do áudio de entrada. Não é recomendável medir a latência usando o tempo total de execução. |
| Síntese de fala (streaming) | O tempo total de execução é determinado principalmente pela duração do áudio de saída. Os dados são tratados e as respostas são retornadas o mais rápido possível. |
| Repositórios de dados: IA generativa desativada | O tempo real depende do tamanho do repositório de dados. |
| Repositórios de dados: IA generativa ativada | O desempenho depende do tamanho do repositório de dados, do modelo de linguagem em uso e do comprimento da saída e da entrada do comando, nessa ordem. |
| Resposta generativa de substituição | O desempenho depende do idioma em uso e do comprimento da entrada e da saída do comando, nessa ordem. |
| Geradores | O desempenho depende do modelo de linguagem em uso, da complexidade da entrada e do comprimento da saída do comando, além do número de geradores no turno. Vários geradores em um único turno resultam em várias chamadas para um modelo de linguagem. |
| Execução de playbooks | A performance depende da complexidade do playbook, do número de comandos e do tempo de execução das ferramentas chamadas. O tamanho da saída e da entrada do comando afeta essa performance. Vários comandos de modelo de linguagem podem ser executados em série, aumentando o tempo total da chamada. |
| Playbooks: ferramentas | O desempenho depende da execução da ferramenta. |
| Chamadas de webhook | O desempenho é determinado diretamente pelo tempo de execução do código no webhook. |
| Agente de importação / exportação | A performance depende do tamanho do agente. |
| Treinamento de agentes | O desempenho depende do número de fluxos, intents e frases de treinamento. O treinamento de agentes grandes pode levar dezenas de minutos. |
| Criação do ambiente | Criar um ambiente envolve treinar o agente. Portanto, o tempo total depende do tamanho e da complexidade dele. |
Observações importantes:
- Streaming:para chamadas de streaming (reconhecimento e síntese de fala), os dados são processados conforme chegam, e as respostas são retornadas assim que possível. Isso significa que a resposta inicial geralmente é muito mais rápida do que o tempo total da chamada.
- Playbooks:um comando de LLM é criado com base nas instruções do playbook, no contexto da conversa e na entrada da ferramenta. Vários comandos de LLM podem ser executados em uma única chamada de playbook. Por isso, a execução do playbook varia de acordo com a quantidade de comandos emitidos e a complexidade das chamadas.
Considerações importantes sobre latência
- Sem garantias de latência:os SLAs do Dialogflow não consideram a latência, mesmo com Capacidade de processamento provisionada.
- Latência do LLM:o processamento do LLM pode introduzir latência significativa. Considere isso no design do seu agente e nas expectativas dos usuários.
- Monitoramento e alertas:ao configurar o monitoramento e os alertas, considere a natureza transmitida das respostas dos LLMs e dos serviços de voz. Não suponha que o tempo total de resposta é igual ao tempo até a primeira resposta.