Práticas recomendadas de uso de serviços

Neste guia, apresentamos 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 geral de agentes para todos os tipos de agente e o guia de design de agente de voz especificamente para projetar agentes de voz.

Produção

Antes de executar seu agente na produção, implemente as práticas recomendadas de produção:

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 do agente exportado 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

É possível melhorar o desempenho do seu aplicativo reutilizando instâncias da biblioteca de cliente *Client durante o ciclo de vida da execução.

Mais importante ainda, é possível melhorar o desempenho das chamadas de API de detecção de intent reutilizando uma instância de biblioteca de cliente SessionsClient.

Consulte a referência de Sessões.

Para mais informações, consulte o guia 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, patch ou delete, use os métodos batchUpdate ou batchDelete.
  • Em vez de enviar muitas solicitações de Intents create, patch ou delete, use os métodos batchUpdate ou batchDelete.

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:

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 Detalhes
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.