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 design para agentes gerais para todos os tipos de agentes e o guia design de agentes de voz específico para 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. Isso ajuda a rastrear as alterações no tempo de design nos agentes do Dialogflow vinculados a este 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 que você recupere rapidamente se você ou os membros da sua equipe excluírem o agente ou o projeto acidentalmente.
Reutilização do cliente
Para melhorar o desempenho do aplicativo,
reutilize instâncias da biblioteca de cliente *Client
durante a execução do aplicativo.
Mais importante,
é possível melhorar o desempenho das chamadas de API de detecção de intent
reutilizando uma instância da biblioteca de cliente SessionsClient.
Saiba mais no guia de práticas recomendadas com bibliotecas de cliente.
Atualizações em lote para o agente
Se você estiver enviando muitas solicitações de API individuais para atualização de agente em um curto período, suas solicitações poderão ser limitadas. Esses métodos de API do projeto não são implementados para processar altas taxas de atualização de um único agente.
Alguns tipos de dados têm métodos em lote para essa finalidade:
- Em vez de enviar muitas solicitações de EntityTypes
create,patchoudelete, use os métodosbatchUpdateoubatchDelete. - Em vez de enviar muitas solicitações de Intents
create,patchoudelete, use os métodosbatchUpdateoubatchDelete.
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.