Fallbacks em Chatbots de IA: Como Identificar Lacunas de Conhecimento e Redirecionar com Segurança

Um chatbot para websites não precisa de responder a todas as perguntas. O essencial é que consiga reconhecer quando a base de conhecimento não oferece fundamentação suficiente e que continue a ser útil para os visitantes. Preencher uma lacuna com um palpite verosímil cria um problema de confiança: um prazo de entrega errado, uma regra de produto inventada ou uma indicação de suporte desadequada podem causar mais trabalho do que uma limitação clara e direta.

Por que a Ausência de Resultados É um Problema de Produto

Num chatbot de IA com base de conhecimento, existem pelo menos três causas para a ausência de resposta. Em primeiro lugar, a informação pode realmente não existir. Em segundo lugar, pode estar presente, mas não ser encontrada devido ao idioma, formulação, metadados ou ordenação. Em terceiro lugar, embora localizável, pode não ser suficiente para garantir uma resposta segura. Estes casos parecem semelhantes no chat, mas exigem ações diferentes na gestão do sistema.

Os sistemas de recuperação (retrieval) não avaliam automaticamente se uma resposta é empresarialmente aceitável. A documentação oficial sobre Retrieval-Augmented Generation no Azure AI Search descreve como a pesquisa de texto e vetorial podem ser combinadas para fornecer fontes para uma resposta. Esta combinação melhora a pesquisa, mas não substitui uma regra que defina quando um resultado é considerado suficiente. Por isso, antes da geração do texto, o chatbot necessita de uma decisão bem definida: responder, pedir esclarecimentos ou redirecionar com segurança.

Um "No-Answer" Não É um Beco Sem Saída

Uma resposta de fallback adequada não diz simplesmente "Não tenho informações sobre isso". É composta por quatro elementos: estabelece o limite sem desculpas técnicas, evita suposições, oferece um esclarecimento preciso ou uma alternativa segura e, quando necessário, indica o caminho para o contacto humano. O tom pode ser cordial, mas não deve esconder a incerteza.

• Limite: "Não encontrei uma informação conclusiva nos dados autorizados."
• Contexto: "Trata-se de uma encomenda, de um contrato ou de uma configuração técnica?"
• Próximo passo: "Se indicar o nome do produto, posso verificar novamente os documentos disponíveis."
• Transferência: "Para uma verificação definitiva, encaminhamos a sua questão para a equipa responsável."

Desta forma, o chat permanece útil sem inventar preços, prazos, implicações jurídicas ou compromissos. O critério de encaminhamento para suporte humano deve atuar mais cedo, especialmente em questões sobre dados pessoais, pagamentos, propostas individuais ou temas críticos de segurança. O guia sobre Human Handoff no Suporte do Website ajuda a estruturar estas transições como um processo claro e não como uma saída de emergência.

Operacionalizar a Decisão Antes da Resposta

As equipas não devem adotar um limite arbitrário vindo de uma demonstração. A pontuação obtida na pesquisa é apenas um sinal e pode variar conforme o índice, o modelo, o idioma e a combinação de consultas. A documentação do Semantic Ranking assinala que as distribuições de pontuação do reranker podem variar. Portanto, um limite deve estar sempre associado a um conjunto de dados testado e a uma classe de erro concreta.

Uma decisão prática pode combinar várias verificações. Existe pelo menos uma fonte de uma área de conteúdo autorizada? Corresponde ao idioma e à versão atual do produto ou contrato? Apresenta uma fundamentação direta para a resposta pretendida? Os principais resultados são contraditórios? Apenas quando estes critérios forem devidamente preenchidos é que o gerador deve formular uma resposta. Caso contrário, o chatbot pede esclarecimentos específicos ou aciona o fallback.

Exemplo: Informação Definitiva sobre Entregas

Se um utilizador perguntar pelo prazo de entrega de um produto específico, um artigo genérico sobre envios não é suficiente. O chatbot pode explicar que não encontra uma informação vinculativa, solicitar o número da encomenda ou a variante do produto e encaminhar para o suporte. Uma resposta como "A sua encomenda chega amanhã" não estaria sustentada pela base de conhecimento. O mesmo princípio aplica-se a garantias, cancelamentos, questões de saúde ou acesso a contas: quanto maior o risco potencial, mais rigorosa deve ser a verificação.

Avaliar a Recuperação Antes de Reescrever Conteúdos

A ausência de resposta é frequentemente um indicador útil. Antes de criar um novo prompt, a equipa deve analisar toda a cadeia: pergunta original, idioma identificado, consulta de pesquisa normalizada, filtros aplicados, principais resultados, versões das fontes utilizadas e o resultado escolhido. Isto permite identificar se falta um documento ou se a pesquisa falhou na sua recuperação.

1. Classificar a pergunta e a intenção de forma anonimizada, como produto, suporte, conta ou questões legais.
2. Comparar as fontes esperadas com os resultados efetivamente recuperados.
3. Registar os filtros de idioma, validade, acesso e versão do produto.
4. Verificar se os principais resultados sustentam realmente a pergunta ou se contêm apenas termos semelhantes.
5. Classificar o caso como lacuna de documentação, falha de recuperação, regra de segurança ou transferência justificável.

Para estas comparações, é recomendável utilizar um pequeno Golden Set composto por perguntas reais previamente validadas. O artigo sobre Medição da Qualidade de Resposta em Chatbots de IA explica por que razão perguntas críticas e pouco frequentes não devem diluir-se numa média geral. Inclua deliberadamente perguntas sem resposta correspondente no sistema. Só assim é possível testar se o chatbot reage de forma controlada quando não possui a informação.

Integrar as Lacunas num Fluxo Editorial

Um único diálogo não justifica a criação imediata de uma nova FAQ. Contudo, múltiplos fallbacks semelhantes podem indicar que uma informação importante falta ou é difícil de localizar. Para isto, basta manter um registo simplificado com a intenção, a classe de erro, o idioma afetado, os IDs das fontes existentes e o estado. Históricos completos de conversas, nomes ou dados de conta não devem figurar num painel de análise geral.

O responsável pela gestão do conteúdo decide então se adiciona uma FAQ, detalha uma página de produto, melhora os metadados ou ajusta a mensagem de encaminhamento. Cada atualização deve ter um responsável, uma fonte e uma data. Para informações sujeitas a prazos, como disponibilidade ou promoções, é aconselhável definir uma data de expiração. Desta forma, evita-se que um artigo criado com a melhor intenção se transforme na próxima fonte desatualizada.

Não Utilizar a Taxa de Alucinação como Métrica Única de Qualidade

Uma taxa reduzida de erros visíveis pode ser enganadora se o chatbot recorrer excessivamente ao fallback. Em contrapartida, uma taxa de resposta elevada não representa sucesso se as respostas não forem sustentadas pelas fontes. O ideal é acompanhar um conjunto equilibrado de indicadores: percentagem de questões respondidas com segurança, taxa de fallbacks fundamentados, taxa de encaminhamento por intenção, tempo até à resolução pela equipa, lacunas recorrentes e auditorias manuais por amostragem. A análise deve permitir a segmentação por idioma, área de produto e classe de risco.

O NIST AI Risk Management Framework recomenda gerir os riscos no respetivo contexto e implementar processos formais de medição e controlo. Para as equipas de gestão do website, isto não significa armazenar todas as interações, mas sim estabelecer responsabilidades claras e critérios verificáveis para garantir respostas seguras.

Além disso, os testes devem refletir cenários reais de utilização. Uma pergunta curta feita num smartphone contém habitualmente menos contexto do que uma consulta detalhada no computador. Erros ortográficos, abreviaturas de produtos e a mistura de idiomas são situações esperadas e não exceções. Por isso, não teste apenas perguntas perfeitamente estruturadas, mas inclua variações sem número de encomenda, com múltiplos nomes de produtos ou com referências temporais ambíguas. Cada variação deve acionar uma resposta fundamentada, um pedido de esclarecimento útil ou um encaminhamento seguro. Um fallback que apenas funciona com perguntas de teste ideais não garante proteção na utilização diária.

O feedback da equipa de suporte é igualmente valioso. Quando os operadores respondem a um pedido encaminhado, podem categorizar brevemente o motivo: falta de informação, informação desatualizada, necessidade de permissões especiais ou consulta que exigia uma decisão individual. Estas categorias conetam o website, a redação de conteúdos e o suporte ao cliente, sem transformar o utilizador num objeto de estudo. Uma análise mensal das categorias mais frequentes é, em regra, suficiente para planear melhorias prioritárias.

Lista de Verificação para um Fallback Seguro

• As respostas surgem exclusivamente com fontes adequadas, autorizadas e atualizadas.
• Os limites e combinações de sinais foram validados com um Golden Set.
• As categorias de elevado risco dispõem de regras específicas para pedidos de esclarecimento e transferência humana.
• Os textos de fallback esclarecem o limite sem simular detalhes técnicos internos ou uma falsa certeza.
• Os registos contêm apenas os dados de diagnóstico estritamente necessários.
• Casos recorrentes têm um responsável definido e um estado de resolução acompanhado.
• Novas fontes são reavaliadas antes da publicação, após alterações e ao atingir a data de expiração.

Conclusão: Limites Claros Melhoram a Qualidade das Respostas

Um chatbot de IA profissional não procura responder ao maior número possível de perguntas, mas sim limitar-se ao que a sua base de conhecimento validada suporta. A melhor resposta de fallback é concreta, útil e transfere os casos complexos sem barreiras. Quando as equipas tratam a ausência de resposta como dados de teste e sinalizações editoriais, tanto a recuperação como os conteúdos apresentam melhorias mensuráveis. Comece com dez perguntas essenciais, dez perguntas intencionalmente sem resposta e um fluxo de encaminhamento claro para cada nível de risco. Isto estabelece uma base sólida antes de atribuir maior autonomia ao chatbot.

Fontes

• Microsoft Learn: RAG and Generative AI in Azure AI Search
• Microsoft Learn: Semantic Ranking Overview
• Microsoft Learn: Create a Full-Text Query
• NIST: AI Risk Management Framework