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 geral de design de agentes 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
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ê se recupere rapidamente se você ou seus colegas de equipe excluírem acidentalmente o agente ou o projeto.
Reutilização do cliente
Você pode melhorar a performance do aplicativo reutilizando instâncias da biblioteca de cliente *Client durante o tempo de execução do aplicativo.
O mais importante é que você pode melhorar a performance 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 |
Para mais informações, consulte o guia 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 as informações de performance para várias operações no Dialogflow. Entender a latência é importante para criar agentes responsivos e definir expectativas de performance 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 são normalmente processados usando métodos de streaming. As respostas são enviadas ao cliente o mais rápido possível, geralmente muito antes de a 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 fornece informações sobre a performance típica 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 o mais rápido 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 processados 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 | A performance depende do tamanho do repositório de dados, do modelo de linguagem em uso e da duração da saída e da entrada do comando, nessa ordem. |
| Resposta generativa de substituição | A performance depende do idioma em uso e da duração da saída e da entrada do comando, nessa ordem. |
| Geradores | A performance depende do modelo de linguagem em uso, da complexidade da entrada e da duração da saída do comando e do número de geradores na rodada. Vários geradores em uma única rodada 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 de todas as ferramentas chamadas. A duração da saída e da entrada do comando afeta essa performance. Vários comandos de modelo de linguagem podem ser executados em série, somando o tempo total da chamada. |
| Playbooks: ferramentas | A performance depende da execução da ferramenta. |
| Chamadas de webhook | A performance é determinada diretamente pelo tempo de execução do código no webhook. |
| Importar / exportar agente | A performance depende do tamanho do agente. |
| Treinamento dos agentes | A performance 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 vai depender do tamanho e da complexidade do agente. |
Observações importantes :
- Streaming:para chamadas de streaming (reconhecimento e síntese de fala), os dados são processados à medida que 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 chamada.
- Playbooks:um comando LLM é criado com base nas instruções do playbook, no contexto da conversa e na entrada da ferramenta. Vários comandos 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 latência
- Sem garantias de latência:os SLAs do Dialogflow não consideram a latência, mesmo em Capacidade de processamento provisionada.
- Latência do LLM:o processamento do LLM pode introduzir uma 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 suponha que o tempo total de resposta seja igual ao tempo até a primeira resposta.