Este guia fornece práticas recomendadas para usar o serviço Dialogflow. Estas diretrizes foram concebidas para uma maior eficiência e precisão, bem como para tempos de resposta ideais do serviço.
Também deve consultar o guia de design de agentes gerais para todos os tipos de agentes e o guia de design de agentes de voz especificamente para conceber agentes de voz.
Produção
Antes de executar o seu agente em produção, certifique-se de que implementa as seguintes práticas recomendadas:
- Use versões de agentes
- Reutilize clientes de sessão
- Implemente o processamento de erros com novas tentativas
Ative os registos de auditoria
Ative os registos de auditoria de acesso a dados para a API Dialogflow no seu projeto. Isto pode ajudar a acompanhar as alterações de tempo de conceção nos agentes do Dialogflow associados a este projeto.
Versões do agente
Deve usar sempre versões de agentes para o seu tráfego de produção. Consulte Versões e ambientes para ver detalhes.
Crie uma cópia de segurança do agente
Mantenha uma cópia de segurança do agente exportada atualizada. Isto permite-lhe recuperar rapidamente o agente ou o projeto se os eliminar acidentalmente.
Reutilização de clientes
Pode melhorar o desempenho da sua aplicação
reutilizando *Clientinstâncias da biblioteca de cliente
durante o tempo de execução da sua aplicação.
Mais importante ainda, pode melhorar o desempenho das chamadas da API Detect Intent reutilizando uma instância da biblioteca cliente SessionsClient.
Para mais informações sobre este assunto, consulte o guia de práticas recomendadas com bibliotecas de cliente.
Atualizações em lote para o agente
Se estiver a enviar muitos pedidos individuais da API de atualização de agentes num curto período de tempo, os seus pedidos podem ser limitados. Estes métodos de API de tempo de conceção não são implementados para processar taxas de atualização elevadas para um único agente.
Alguns tipos de dados têm métodos de processamento em lote para este fim:
- Em vez de enviar muitos pedidos de EntityTypes
create,patchoudelete, use os métodosbatchUpdateoubatchDelete. - Em vez de enviar muitos pedidos de Intents
create,patchoudelete, use os métodosbatchUpdateoubatchDelete.
Voltas a tentar de erros da API
Quando chama métodos da API, pode receber respostas de erro. Existem alguns erros que devem ser repetidos, porque muitas vezes se devem a problemas temporários. Existem dois tipos de erros:
- Erros da API Cloud.
- Erros enviados do seu serviço de webhook.
Além disso, deve implementar uma retirada exponencial para repetições. Isto permite que o seu sistema encontre uma taxa aceitável enquanto o serviço de API está sob carga elevada.
Erros da API Cloud
Se estiver a usar uma biblioteca cliente fornecida pela Google, as novas tentativas de erro da API Cloud com recuo exponencial são implementadas por si.
Se tiver implementado a sua própria biblioteca cliente através de REST ou gRPC, tem de implementar novas tentativas para o seu cliente. Para obter informações sobre os erros que deve ou não repetir, consulte o artigo Propostas de melhoria da API: configuração de repetição automática.
Erros de webhook
Se a sua chamada API acionar uma chamada webhook,
o seu webhook pode devolver um erro.
Mesmo que esteja a usar uma biblioteca de cliente fornecida pela Google, não são feitas novas tentativas automaticamente em caso de erros de webhook.
O seu código deve tentar novamente os erros 503 Service Unavailable
recebidos do webhook.
Consulte a documentação do
serviço de webhook
para ver informações sobre os tipos de erros de webhook
e como verificá-los.
Testes de carga
É uma prática recomendada executar testes de carga para o seu sistema antes de lançar o código para produção. Considere estes pontos antes de implementar os testes de carga:
| Resumo | Detalhes |
|---|---|
| Aumente a carga. | O teste de carga tem de aumentar gradualmente a carga aplicada ao serviço Dialogflow. O serviço não foi concebido para processar picos abruptos de carga, que raramente são experimentados com tráfego real. O serviço demora algum tempo a ajustar-se às exigências de carga, por isso, aumente a taxa de pedidos lentamente até que o teste atinja a carga desejada. |
| As chamadas API são cobradas. | As chamadas API são cobradas durante um teste e são limitadas pela quota do projeto. |
| Use substitutos de teste. | Pode não precisar de chamar a API durante o teste de carga. Se o objetivo do teste de carga for determinar como o seu sistema processa a carga, é frequentemente melhor usar um test double em vez de chamadas reais à API. O seu teste duplo pode simular o comportamento da API sob carga. |
| Use novas tentativas. | O teste de carga tem de realizar novas tentativas com um recuo. |
Chamar o Dialogflow de forma segura a partir de um dispositivo do utilizador final
Nunca deve armazenar as suas chaves privadas usadas para aceder à API Dialogflow num dispositivo do utilizador final. Isto aplica-se ao armazenamento de chaves diretamente no dispositivo e à codificação rígida de chaves em aplicações. Quando a sua aplicação cliente precisa de chamar a API Dialogflow, deve enviar pedidos para um serviço de proxy pertencente ao programador numa plataforma segura. O serviço de proxy pode fazer as chamadas Dialogflow reais e autenticadas.
Por exemplo, não deve criar uma aplicação para dispositivos móveis que chame o Dialogflow diretamente. Se o fizesse, teria de armazenar chaves privadas num dispositivo do utilizador final. Em alternativa, a sua aplicação para dispositivos móveis deve passar os pedidos através de um serviço de proxy seguro.
Desempenho
Esta secção descreve as informações de desempenho de várias operações no Dialogflow. A compreensão da latência é importante para criar agentes com capacidade de resposta e definir expetativas de desempenho realistas, embora estes valores não façam parte do SLA do Dialogflow.
Ao criar ferramentas de monitorização e alerta, tenha em atenção que os modelos de linguagem (conteúdo extenso) (MDIs/CEs) e o processamento de voz são normalmente processados através de métodos de streaming. As respostas são enviadas ao cliente assim que possível, muitas vezes muito antes da duração total da chamada do método. Para mais informações, consulte o artigo Práticas recomendadas com modelos de linguagem (conteúdo extenso) (MDIs/CEs).
Desempenho por operação
A tabela seguinte fornece informações sobre o desempenho típico das operações do Dialogflow:
| Ação | Notas |
|---|---|
| Deteção de intenção (texto) | Funcionamento rápido |
| Deteção de parâmetros (texto) | Funcionamento rápido |
| Reconhecimento de voz (em streaming) | Os dados são processados e as respostas são devolvidas assim que possível. O tempo de execução total é determinado principalmente pela duração do áudio de entrada. Não é recomendável medir a latência através do tempo de execução total. |
| Síntese de voz (streaming) | O tempo de execução total é determinado principalmente pela duração do áudio de saída. Os dados são processados e as respostas são devolvidas o mais rapidamente possível. |
| Chamadas de webhook | O desempenho é determinado diretamente pelo tempo de execução do seu código no webhook. |
| Agente de importação / exportação | O desempenho depende do tamanho do agente. |
| Formação de agentes | O desempenho depende do número de fluxos, intenções e expressões de preparação. A formação de agentes grandes pode demorar dezenas de minutos. |
| Criação de ambientes | A criação de um ambiente envolve a preparação do agente, pelo que o tempo total depende do tamanho e da complexidade do agente. |
Notas importantes:
- Streaming: para chamadas de streaming (reconhecimento e síntese de voz), os dados são processados à medida que chegam, e as respostas são devolvidas assim que possível. Isto significa que a resposta inicial é normalmente muito mais rápida do que o tempo total da chamada.
- Guiões: é criada uma instrução de LLM com base nas instruções do guião, no contexto da conversa e na entrada da ferramenta. É possível executar vários comandos de MDG num único comando de livro de jogadas. É por isso que a execução do manual de soluções é variável, dependendo da quantidade de comandos emitidos e da complexidade das chamadas.
Considerações importantes sobre a latência
- Sem garantias de latência: os SLAs do Dialogflow não consideram a latência, mesmo com débito processado.
- Latência do MDI/CE: tenha em atenção que o processamento do MDI/CE pode introduzir uma latência significativa. Tenha isto em conta no design do agente e nas expetativas dos utilizadores.
- Monitorização e alertas: ao configurar a monitorização e os alertas, tenha em conta a natureza de streaming das respostas dos MDIs e dos serviços de voz. Não assuma que o tempo de resposta total é igual ao tempo até à primeira resposta.