Melhore a precisão do seu bot com o Assisted NLU do Amazon Lex

O desafio de entender como as pessoas realmente falam

Quem já trabalhou com bots conversacionais sabe bem o problema: o usuário não fala do jeito que o sistema espera. A mesma solicitação pode vir de dezenas de formas diferentes, misturada com outras informações na mesma frase, ou de maneira ambígua o suficiente para confundir qualquer sistema tradicional de Compreensão de Linguagem Natural (NLU).

Sistemas baseados em regras exigem que desenvolvedores configurem manualmente cada variação possível de uma frase — um trabalho enorme que ainda assim deixa lacunas. Um bot de reservas treinado com “reserve um hotel” vai falhar quando o usuário disser “preciso de um lugar para ficar”. Pedidos complexos como “quero uma suíte no centro de São Paulo do dia 15 ao 18 de dezembro” frequentemente perdem detalhes críticos. E frases ambíguas como “preciso de ajuda com minha reserva” deixam o bot sem saber se o usuário quer criar, visualizar, alterar ou cancelar.

Para resolver esse problema, a AWS anunciou o Assisted NLU no Amazon Lex — um recurso que combina o aprendizado de máquina (ML) tradicional com grandes modelos de linguagem (LLM) para lidar com as variações naturais da comunicação humana. E o melhor: está incluído sem custo adicional no preço padrão do Amazon Lex.

O que é o Assisted NLU e como ele funciona

O Assisted NLU usa LLMs para aprimorar a classificação de intenções e a resolução de slots. Em vez de depender apenas de exemplos de frases configurados manualmente, o recurso utiliza os nomes e descrições das suas intenções e slots para entender o que o usuário está tentando fazer — lidando com erros de digitação, frases complexas e extração de múltiplos slots sem configuração manual adicional.

Os resultados reportados pela AWS são expressivos: 92% de precisão na classificação de intenções e 84% de precisão na resolução de slots, em média. Clientes que já adotaram o recurso relataram aumentos de 11 a 15% na classificação de intenções, 23,5% menos respostas de fallback e 30% mais eficiência no tratamento de entradas com ruído.

O recurso opera em dois modos:

• Modo Primário (Primary): o LLM processa todas as entradas do usuário como principal mecanismo de classificação.
• Modo Fallback: o NLU tradicional é usado primeiro; o LLM só é acionado quando a confiança está baixa ou quando a entrada seria roteada para a FallbackIntent.

A ativação é feita diretamente no console do Amazon Lex, nas configurações de localidade do bot. Para configuração via código, a AWS disponibiliza a referência da API NluImprovementSpecification. Quem ainda não conhece o Amazon Lex pode começar pelo Guia de Introdução.

Boas práticas de implementação

Escolhendo o modo certo

A escolha entre Modo Primário e Modo Fallback depende do contexto do seu bot:

• Use o Modo Primário para bots novos ou quando você tem poucos exemplos de frases (menos de 20 por intenção). É o modo ideal para começar do zero com boas descrições.
• Use o Modo Fallback quando o bot já tem boa performance e você quer que o LLM atue apenas nos casos limítrofes. Se mais de 30% das requisições estiverem acionando o LLM no Modo Fallback, vale considerar migrar para o Modo Primário.
• Não troque para o Modo Primário sem testes A/B em bots que já performam bem — você pode introduzir latência sem ganho real de precisão.

Escrevendo boas descrições de intenções

As descrições de intenções funcionam como prompts para o LLM — não são documentação interna. A qualidade delas determina diretamente a precisão do sistema. A AWS recomenda um padrão consistente:

“Intenção de [verbo de ação] [objeto/entidade] [contexto/restrições]”

Exemplos práticos:

• Bom: “Intenção de reservar ou garantir um quarto de hotel ou suíte para uma estadia”
• Ruim: “TBD” ou “Intenção 1” — não fornece nenhum sinal para o LLM
• Ruim: “Intenção de reservar e gerenciar reservas de hotel” — combinar múltiplas ações em uma intenção confunde a classificação

Outros pontos importantes: evite linguagem que se sobreponha entre intenções diferentes, não inclua valores de slots ou exemplos específicos na descrição, e baseie as descrições no vocabulário real dos seus usuários.

Escrevendo boas descrições de slots

As descrições de slots fornecem contexto para que o LLM saiba exatamente qual informação extrair e como interpretá-la. O padrão recomendado é:

[O que o slot captura] [restrições contextuais] [orientação sobre valores válidos]

Alguns exemplos do que isso resolve na prática:

• Se você tem dois slots do tipo AMAZON.Number (número de noites e número de hóspedes), a descrição é essencial para o LLM diferenciar qual “3” pertence a qual slot.
• Para capturar códigos de aeroporto, use AMAZON.AlphaNumeric com a descrição “Código IATA válido de aeroporto (por exemplo, GRU, CGH, BSB)”. O LLM consegue mapear “voo saindo de Guarulhos” para GRU sem precisar de um catálogo completo de valores.
• Para um slot de tipo de quarto com valores como Standard, Deluxe e Suíte, uma descrição detalhando as características de cada categoria permite que o LLM resolva entradas como “o quarto maior” ou “quarto com cozinha” para o valor correto.

Nunca deixe descrições de slots em branco — especialmente em slots customizados. E lembre-se de atualizar as descrições sempre que a lógica de negócio mudar.

Desambiguação de intenções

Quando múltiplas intenções podem corresponder à entrada do usuário, o Assisted NLU apresenta opções de desambiguação. Para que isso funcione bem:

• Use nomes e descrições de intenções claros e sem sobreposição.
• Forneça nomes de exibição amigáveis para nomes técnicos de intenções.
• Limite as opções de desambiguação a no máximo 3 ou 4 — se “reservar hotel” corresponde a 6 intenções, o design do bot precisa ser revisado.
• Monitore quais pares de intenções frequentemente disparam desambiguação e refine-os continuamente.
• Tenha uma estratégia de fallback clara quando o usuário não seleciona nenhuma opção.

Testando sua implementação com o Test Workbench

Após configurar as descrições, o próximo passo é validar tudo sistematicamente. A AWS recomenda usar o Test Workbench do Amazon Lex para medir como o Assisted NLU lida com variações reais de frases. A documentação do Test Workbench e um vídeo demonstrativo estão disponíveis para consulta.

Atenção: ao configurar a execução do conjunto de testes, certifique-se de selecionar o bot e o alias onde o Assisted NLU está habilitado — o teste só exercita o recurso se o alias apontar para uma versão com o Modo Fallback ou Primário configurado.

O que testar

• Casos extremos: entradas com erros de digitação (“quero resrvar um quarto”), expressões coloquiais, pedidos ambíguos e frases incompletas.
• Variações de slots built-in: formatos de data (“próxima terça”, “dia 15”), aliases de localização, variações de nome e formatos de e-mail.
• Slots customizados: verifique se o vocabulário do usuário é mapeado corretamente para os valores definidos, especialmente no modo de expansão.

Vale destacar um ponto de segurança importante: diferente de aplicações de IA generativa abertas, o Assisted NLU usa o LLM estritamente como um motor de classificação e extração, limitado pela definição do bot. O LLM não pode inventar novas intenções, acionar ações fora do escopo do bot ou retornar texto gerado livremente ao usuário. Mesmo assim, a AWS recomenda validar que entradas adversariais sejam roteadas de forma previsível para a FallbackIntent.

Interpretando os resultados

Após a execução dos testes, use as taxas de aprovação para priorizar esforços:

• 0 a 30%: alta prioridade — reescreva a descrição da intenção e verifique sobreposições.
• 30 a 70%: média prioridade — analise padrões nas falhas e refine as descrições.
• 70 a 100%: baixa prioridade — ajustes menores ou nenhuma ação necessária.

Iteração e versionamento seguro

Para iterar com segurança sem impactar o tráfego em produção, a AWS recomenda usar o sistema de versionamento e aliases do Amazon Lex: refine as descrições na versão Draft, teste no alias de teste, crie uma versão numerada quando os resultados forem satisfatórios e promova para produção. Em caso de problemas, basta redirecionar o alias de produção para a versão anterior. Consulte o Guia de Versionamento e Aliases para detalhes.

Do ponto de vista de controle de acesso, a AWS recomenda usar políticas do Gerenciamento de Identidade e Acesso (IAM) para restringir quem pode modificar definições do bot. As permissões lex:UpdateBotLocale, lex:UpdateIntent e lex:UpdateSlot devem ser limitadas a desenvolvedores autorizados. Mais detalhes em Gerenciamento de Identidade e Acesso para o Amazon Lex.

Monitoramento em produção

Com o bot em produção, a AWS recomenda habilitar logs de conversa no alias de produção para acompanhar a performance do Assisted NLU com tráfego real. Veja como configurar em Configurando Logs de Conversa.

Os principais campos a monitorar são:

• fulfilledByAssistedNlu: flag booleana que indica quando o LLM tratou a classificação ou resolução de slot.
• nluConfidence: pontuação de confiança para a intenção selecionada.
• missedUtterance: booleano que indica quando a FallbackIntent foi classificada.

Para comparar os modos Primário e Fallback, crie versões separadas do bot para cada modo, aponte aliases diferentes para elas e compare as métricas no CloudWatch.

Estratégia de implantação recomendada

Para bots novos, a AWS recomenda começar com o Modo Primário, usando de 10 a 15 exemplos de frases por intenção e investindo na qualidade das descrições.

Para bots existentes com boa performance, o ponto de partida é o Modo Fallback, com testes A/B antes de qualquer migração para o Modo Primário. Sempre mantenha uma versão anterior do bot disponível para rollback.

O checklist de implantação sugerido inclui: métricas de baseline documentadas, testes com casos extremos em ambiente de desenvolvimento, logs de conversa habilitados, dashboard no CloudWatch configurado e procedimento de rollback definido.

Conclusão

O Assisted NLU representa uma evolução significativa para quem trabalha com bots no Amazon Lex. Ao combinar o NLU tradicional com LLMs, a AWS entrega um recurso que lida com a imprevisibilidade real da comunicação humana — sem exigir configuração manual exaustiva e sem custo adicional.

A chave para extrair o máximo do recurso está na qualidade das descrições de intenções e slots: elas funcionam como prompts para o LLM e determinam diretamente a precisão do sistema. Com boas descrições, testes sistemáticos e uma estratégia de implantação gradual, é possível melhorar expressivamente a experiência conversacional dos usuários.

Para habilitar o recurso no seu bot, acesse a documentação de habilitação do Assisted NLU no Amazon Lex Developer Guide.

Fonte

Improve bot accuracy with Amazon Lex Assisted NLU (https://aws.amazon.com/blogs/machine-learning/improve-bot-accuracy-with-amazon-lex-assisted-nlu/)