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.
Desempenho
Esta seção descreve informações de desempenho para várias operações no Dialogflow. Entender a latência é importante 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 alerta, observe que os modelos de linguagem grandes (LLMs) e o processamento de fala geralmente são processados usando métodos de streaming. As respostas são enviadas ao cliente assim que possível, geralmente muito 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).
Desempenho por operação
A tabela a seguir fornece informações sobre o desempenho típico das operações do Dialogflow:
| Ação | Observações |
|---|---|
| Detecção de intent (texto) | Operação rápida |
| Detecção de parâmetro (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 pelo comprimento 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 pelo comprimento do áudio de saída. Os dados são processados e as respostas são retornadas o mais rápido possível. |
| Chamadas de webhook | A performance é determinada 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 | A criação de um ambiente envolve o treinamento do agente, portanto, o tempo total depende do tamanho e da complexidade dele. |
Observações importantes:
- Streaming:nas chamadas de streaming (reconhecimento e síntese de fala), os dados são processados conforme chegam, e as respostas são retornadas o mais rápido possível. Isso significa que a resposta inicial normalmente é muito mais rápida do que o tempo total da ligação.
- Livros de jogo:um comando de LLM é criado com base nas instruções do livro de jogo, 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 que a execução do playbook é variável, dependendo da quantidade de comandos emitidos e da complexidade das chamadas.
Considerações importantes sobre a latência
- Nenhuma garantia de latência:os SLAs do Dialogflow não consideram a latência, mesmo com a capacidade provisionada.
- Latência do LLM:o processamento do LLM pode introduzir latência significativa. Considere isso no design do agente e nas expectativas do usuário.
- Monitoramento e alertas:ao configurar o monitoramento e os alertas, considere a natureza transmitida das respostas de LLMs e serviços de fala. Não presuma que o tempo total de resposta é igual ao tempo até a primeira resposta.