Como os Chatbots Funcionam de Verdade: Regras, Recuperação, LLMs, Ferramentas e Transferência para Humanos

Uma conversa com chatbot pode parecer fácil até o momento em que falha. Você pergunta onde está uma encomenda. O bot repete uma política genérica de entrega. Você fornece o número do pedido. Ele pede o número do pedido novamente. Após três voltas, a pequena bolha de chat que prometia conveniência se torna uma porta trancada entre você e a resposta.

A experiência oposta é quase invisível. O chatbot reconhece que você quer rastrear um pedido, captura o número correto, verifica um registro atual, explica o resultado em uma frase e oferece uma pessoa se o caso for incomum. A diferença não é simplesmente que um bot tem mais inteligência artificial. É que um sistema conversacional tem uma tarefa mais clara, melhor estado, ferramentas confiáveis, limites mais seguros e uma forma planejada de se recuperar.

Este guia olha por trás da bolha de chat. Explica os principais tipos de chatbot, segue uma mensagem por uma arquitetura real e mostra por que a linguagem fluente é apenas uma parte de uma conversa confiável.

O que é um chatbot?

Um chatbot é um software que troca mensagens com uma pessoa por texto, voz ou outro canal conversacional. Ele interpreta uma entrada, decide o que deve acontecer em seguida e retorna uma resposta ou ação. Essa definição ampla inclui um menu fixo em um widget de suporte, um fluxo de voz que coleta um número de conta, um assistente de conhecimento que pesquisa documentos e um sistema de modelo de linguagem que pode redigir respostas abertas.

A conversa é a interface, não a tecnologia subjacente. Dois chatbots podem parecer idênticos enquanto funcionam de maneiras completamente diferentes. Um segue uma árvore de decisão. Outro corresponde a uma intenção e chama um webhook. Um terceiro recupera documentos e pede a um grande modelo de linguagem para escrever uma resposta. Os sistemas mais úteis frequentemente combinam várias abordagens.

Uma lição da ELIZA, sessenta anos depois

Em 1966, Joseph Weizenbaum publicou ELIZA, um programa para conversação em linguagem natural. Seu conhecido script DOCTOR usava padrões e transformações para transformar partes da declaração de um usuário em uma resposta. Uma frase como “Estou infeliz” poderia ser correspondida, reorganizada e refletida como uma pergunta. A troca poderia parecer atenta, mesmo que o programa tivesse pouca informação sobre a vida da pessoa e nenhum modelo de linguagem moderno.

ELIZA continua relevante porque as pessoas respondem à linguagem socialmente. Uma pergunta oportuna, uma frase simpática ou uma resposta confiante podem criar uma impressão de compreensão que excede a maquinaria por baixo. Modelos modernos são muito mais capazes, mas a interface ainda convida ao mesmo erro: julgar o que um sistema sabe pela naturalidade com que soa.

Um chatbot profissional deve, portanto, ganhar confiança por meio da conclusão correta de tarefas, limites visíveis e erros recuperáveis. Personalidade pode melhorar uma interação. Não pode substituir o acesso à informação certa ou um processo seguro.

Três principais arquiteturas de chatbot

Chatbots são mais fáceis de entender quando separamos três famílias arquiteturais. Estas não são gerações estritas onde cada nova torna as outras obsoletas. São ferramentas com diferentes pontos fortes.

1. Regras e fluxos de conversa

Um chatbot baseado em regras segue caminhos projetados antecipadamente. Pode mostrar botões, corresponder palavras-chave, preencher um formulário ou mover entre estados quando condições são satisfeitas. A lógica pode ser explícita: se o usuário quer alterar uma data de entrega, colete o número do pedido, verifique se a encomenda é elegível, mostre datas disponíveis e peça confirmação.

Regras são valiosas quando o processo é estreito e as ações aceitáveis são conhecidas. Elas tornam etapas de conformidade e ações destrutivas mais fáceis de controlar. Sua fraqueza aparece quando as pessoas formulam pedidos de maneiras inesperadas ou saem do caminho projetado. Um bom sistema de regras precisa de fallbacks, correções e rotas de fuga, não apenas um caminho feliz perfeito.

2. Correspondência de intenção e recuperação

Um sistema baseado em intenção estima o que o usuário está tentando fazer e extrai detalhes úteis chamados entidades ou parâmetros. “Rastrear pedido 4821” pode mapear para uma intenção de rastrear pedido e um parâmetro de número de pedido. A documentação de intenção do Dialogflow do Google Cloud descreve esse padrão como comparar uma entrada com frases de treinamento para encontrar uma correspondência.

A recuperação adiciona uma camada de pesquisa. Em vez de responder apenas com uma resposta fixa, o sistema encontra passagens relevantes, entradas de política, artigos de ajuda ou registros. Um chatbot de recuperação pode citar uma resposta conhecida diretamente ou passar material selecionado para um gerador. Sua qualidade depende do que foi indexado, de como a consulta foi formada, se a fonte está atualizada e se o sistema encontrou a passagem certa.

3. Modelos de linguagem, ferramentas e sistemas híbridos

Um grande modelo de linguagem pode interpretar frases variadas e produzir respostas naturais em uma gama muito mais ampla de entradas. Pode resumir, explicar, traduzir, fazer uma pergunta de esclarecimento ou transformar saída estruturada de ferramenta em linguagem legível. Para uma explicação mais profunda da geração de tokens e limites do modelo, veja O que é IA, realmente?.

O modelo ainda precisa de ajuda com fatos e ações ao vivo. Não pode saber a localização atual do pedido 4821, a menos que o aplicativo forneça essa informação por contexto, recuperação ou ferramenta. Não pode emitir um reembolso com segurança apenas porque pode escrever a frase “Seu reembolso está completo”. O aplicativo deve conectar o modelo a serviços autorizados e verificar o resultado.

É por isso que muitos chatbots modernos são híbridos. Regras protegem transições críticas. Recuperação fornece conhecimento atual. Um modelo de linguagem lida com linguagem flexível. Ferramentas leem ou alteram estado externo. Código convencional valida permissões e saídas. Um humano assume casos que exigem julgamento ou autoridade.

O que acontece durante uma rodada de chatbot

Siga uma mensagem simples: “Onde está o pedido 4821?” Uma implementação real pode combinar ou renomear as etapas, mas as responsabilidades subjacentes permanecem reconhecíveis.

1. Receber e normalizar a entrada. O canal pode fornecer texto digitado, fala transcrita, seleções de botão, idioma ou metadados de sessão.
2. Identificar o objetivo. O sistema determina se o pedido diz respeito a rastreamento, cancelamento, pagamento, outro tópico ou algo não suportado.
3. Extrair detalhes necessários. Neste caso, o número do pedido é 4821. Se estiver ausente ou ambíguo, o bot deve perguntar em vez de inventar.
4. Verificar o estado da conversa. O sistema determina o que já sabe, o que tem permissão para reter e qual etapa está ativa.
5. Recuperar conhecimento ou chamar uma ferramenta. Um serviço de rastreamento retorna o status atual. O chatbot não deve criar esse status a partir de padrões de linguagem.
6. Compor e validar a resposta. O aplicativo transforma o resultado em linguagem clara, verifica campos obrigatórios e evita expor dados internos ou pessoais.
7. Responder, recuperar ou transferir. Um resultado normal retorna ao usuário. Um erro, caso não suportado ou pedido por uma pessoa segue uma rota diferente.

O Google Cloud usa o termo fulfillment para a parte de uma rodada conversacional que retorna uma resposta estática, chama um webhook para informações dinâmicas, define parâmetros ou realiza uma ação. Sua documentação de fulfillment do Dialogflow faz uma distinção importante: entender o pedido e cumpri-lo são responsabilidades separadas.

Estado de conversa não é memória humana

Um chatbot precisa de estado suficiente para evitar recomeçar a cada rodada. O estado da sessão pode registrar que a tarefa atual é rastreamento de encomenda, o número do pedido é 4821 e o usuário já confirmou um código postal. Sem estado, “E o segundo pacote?” não tem referência utilizável.

Esse estado é dado projetado, não uma lembrança humana. Alguns sistemas mantêm apenas a sessão atual. Outros armazenam histórico de conversa, resumos, preferências ou informações de conta. Um modelo também pode receber apenas parte de uma conversa longa porque seu contexto tem capacidade finita ou porque o aplicativo deliberadamente limita o que é enviado.

Os usuários não devem presumir que um chatbot esquece quando uma janela fecha ou lembra porque fala como se lembrasse. Retenção, vinculação de conta, uso em treinamento e exclusão dependem do serviço específico. Antes de compartilhar informações sensíveis, inspecione a explicação de privacidade do serviço e use o mínimo de informações necessário para a tarefa.

Como funciona a geração aumentada por recuperação

Os parâmetros de um modelo de linguagem são um lugar ruim para manter uma política de devoluções que muda com frequência. A geração aumentada por recuperação, geralmente abreviada como RAG, aborda isso pesquisando uma coleção externa por material relevante e colocando passagens selecionadas no contexto do modelo antes de ele escrever a resposta.

O artigo original sobre geração aumentada por recuperação combinou um gerador pré-treinado com memória não paramétrica explícita recuperada de um índice. O padrão amplo agora aparece em muitos assistentes de conhecimento: pesquise primeiro, gere depois.

Um pipeline RAG útil tem pelo menos quatro oportunidades de falhar. A coleção de fontes pode estar incompleta. O documento pode estar desatualizado. A recuperação pode selecionar uma passagem irrelevante. O gerador pode ler mal ou embelezar o que recebeu. Citações ajudam apenas se apontarem para a fonte exata de apoio e o usuário puder inspecioná-la.

RAG, portanto, melhora o acesso a conhecimento atual e inspecionável, mas não garante verdade. Deve ser avaliado de ponta a ponta: a fonte correta entrou no índice, a pesquisa a encontrou, a resposta permaneceu dentro das evidências e a citação apoiou a afirmação?

Respostas e ações exigem diferentes níveis de controle

Um chatbot que explica uma política de reembolso não é o mesmo que um chatbot que emite um reembolso. O segundo sistema pode alterar estado externo. Pode chamar um serviço de conta, calendário, sistema de pagamento, ferramenta de mensagens ou controle de dispositivo. Essa capacidade às vezes é descrita como agência, mas a questão prática é mais simples: o que este aplicativo pode fazer além de produzir texto?

Um caminho de ação seguro deve manter verificações importantes fora da prosa do modelo:

• Autenticar o usuário e confirmar que a conta ou recurso pertence a ele.
• Autorizar a ação específica em vez de dar ao chatbot acesso amplo.
• Validar argumentos de ferramenta, valores, destinos e faixas permitidas com código convencional.
• Exigir confirmação explícita antes de ações irreversíveis ou custosas.
• Retornar um resultado de ferramenta verificado em vez de assumir que a ação foi bem-sucedida.
• Registrar informações suficientes para investigar falhas sem expor dados sensíveis desnecessários.

A ilustração mostra uma arquitetura alvo, não uma promessa sobre qualquer chatbot específico. Um modelo de linguagem pode sugerir qual ferramenta chamar, mas o aplicativo ao redor deve decidir se a chamada é permitida. Mais autonomia aumenta o valor de limites de permissão, limites de taxa, confirmação, monitoramento e revisão humana.

Injeção de prompt: quando o conteúdo tenta se tornar uma instrução

Um chatbot que usa ferramentas ou recuperação pode ler texto fornecido por usuários, sites, e-mails ou documentos. Parte desse texto pode conter instruções direcionadas ao modelo, como dizer para ignorar regras anteriores, revelar informações ocultas ou chamar uma ferramenta de forma não intencional. Isso é injeção de prompt.

O Projeto de Segurança GenAI da OWASP lista injeção de prompt como um risco líder para aplicações de modelo de linguagem. O problema central é que modelos processam instruções e conteúdo comum pelo mesmo canal de linguagem. Um documento não confiável pode parecer gramaticalmente semelhante a uma instrução do aplicativo.

Nenhum prompt pode substituir controles de nível de sistema. Aplicações devem tratar conteúdo recuperado e fornecido pelo usuário como não confiável, restringir ferramentas disponíveis, aplicar privilégio mínimo, validar chamadas de ferramenta, isolar operações sensíveis e pedir confirmação onde as consequências importam. O modelo não deve receber uma chave mestra apenas porque a interface é conversacional.

Por que chatbots dão respostas erradas ou frustrantes

Eles entendem mal o pedido

A linguagem é ambígua. “Fechar minha conta” pode significar sair, excluir um perfil, cancelar uma assinatura ou fechar uma conta financeira. Um chatbot confiável reconhece quando o custo de adivinhar é maior que o custo de uma pergunta de esclarecimento.

Eles não têm a informação necessária

Um modelo pode conhecer vocabulário geral de envio, mas não ter o registro do pedido do usuário. A recuperação pode perder a política relevante. Uma ferramenta pode estar indisponível. A resposta correta é declarar a limitação ou usar um fallback, não preencher a lacuna com uma história plausível.

Eles geram uma falsidade confiante

NIST chama conteúdo generativo falso ou errôneo apresentado com confiança de confabulação. Seu Perfil de IA Generativa observa que esse comportamento pode incluir lógica ou citações fabricadas. Fluência torna essas falhas mais difíceis de notar, não menos prováveis de importar.

Eles perdem estado ou carregam o estado errado adiante

Uma sessão pode esquecer um detalhe, confundir dois pedidos, preservar uma suposição incorreta ou aplicar informações de uma tarefa a outra. O estado deve ser visível o suficiente para corrigir e limitado o suficiente para evitar mistura não intencional.

Eles não têm saída elegante

O ciclo mais doloroso costuma ser uma falha de design. O bot atingiu o limite de sua capacidade, mas continua reformulando a mesma resposta. Um fallback deve mudar o caminho: pedir um detalhe ausente, mostrar uma opção suportada, criar um caso ou transferir a conversa.

A transferência para um humano faz parte do sistema, não é uma admissão de derrota

Algumas solicitações são ambíguas, emocionais, excepcionais ou consequentes. Outras exigem autoridade que o chatbot não deveria ter. Um especialista humano pode interpretar o contexto, negociar uma exceção, assumir responsabilidade ou reconhecer que o processo documentado não se aplica ao caso.

Uma transferência só funciona se o contexto viajar junto. A pessoa deve receber o objetivo do usuário, os detalhes confirmados, os resultados relevantes das ferramentas e o motivo do encaminhamento. Forçar o usuário a repetir toda a conversa transforma uma transferência tecnicamente bem-sucedida em uma experiência ruim.

A documentação de transferência para agente humano do Dialogflow trata a transferência como uma transição explícita. Esse princípio de design é mais amplo que uma única plataforma: a escalada deve ser uma rota testada com responsabilidade definida, não uma frase que o bot improvisa quando está travado.

Como avaliar se um chatbot é bom

Uma demonstração convincente é fácil de encenar. Um chatbot confiável deve lidar com variações comuns e falhas visíveis. A avaliação deve começar pela tarefa que o usuário veio concluir.

• Conclusão da tarefa: o usuário obteve a resposta ou concluiu a ação corretamente?
• Fundamentação: as afirmações factuais seguiram a fonte fornecida ou o resultado verificado da ferramenta?
• Recuperação: informações ausentes, eventos sem correspondência e falhas de ferramentas levaram a um próximo passo útil?
• Segurança: autorização, confirmação, tratamento de dados e limites das ferramentas se mantiveram sob entradas adversárias?
• Qualidade da transferência: a conversa chegou à pessoa certa com contexto suficiente?
• Idioma e acessibilidade: o fluxo funcionou nos idiomas suportados, estilos de digitação, condições de fala, navegação por teclado e tecnologia assistiva?
• Esforço do usuário: quantas interações, repetições e correções foram necessárias para concluir a tarefa?

As conversas de teste devem incluir mais do que o caminho feliz. Use números de pedido ausentes, dois números em uma mensagem, erros de ortografia, solicitações não suportadas, documentos desatualizados, tempos limite de ferramentas, solicitações para mudar de assunto, pedidos diretos por uma pessoa e instruções maliciosas escondidas no conteúdo recuperado. A orientação de design de agentes do Google Cloud recomenda igualmente design iterativo e casos de teste, em vez de tentar projetar todos os caminhos de uma vez.

Como usar um chatbot sem abrir mão do julgamento

1. Declare o objetivo e o contexto mínimo relevante. Uma solicitação precisa reduz interações desnecessárias.
2. Não cole senhas, códigos de autenticação, credenciais de pagamento, chaves privadas ou registros sensíveis, a menos que o serviço confiável específico exija e proteja explicitamente essa entrada.
3. Distinga uma explicação de um resultado ao vivo. Pergunte se a resposta veio de um registro atual, de uma fonte citada ou do conhecimento geral do modelo.
4. Abra as citações e verifique afirmações consequentes. Um link de fonte pode ser irrelevante, desatualizado ou inconsistente com a resposta.
5. Revise cada ação antes de confirmá-la. Verifique a conta, o valor, o destino, a data e se a alteração pode ser revertida.
6. Peça por uma pessoa quando o bot se repetir, não tiver autoridade, entender mal um assunto sensível ou não puder mostrar de onde veio a resposta.

O modelo mental que vale a pena manter

Um chatbot não é uma personalidade vivendo dentro de uma bolha. É uma interface conversacional conectada a alguma combinação de fluxos, classificadores, busca, modelos de linguagem, registros, ferramentas, políticas, verificações de segurança e pessoas. A resposta que você vê é a última etapa desse sistema maior.

A melhor pergunta não é “Este bot parece humano?”. Pergunte se ele entendeu a tarefa, usou as evidências certas, respeitou suas permissões, se recuperou honestamente e deixou você no controle. A linguagem natural torna o sistema mais fácil de abordar. A boa engenharia o torna digno de uso.

Referências principais e técnicas

• Joseph Weizenbaum, ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
• Google Cloud, Dialogflow CX documentation for intents, fulfillment, agent design, and human handoff.
• OWASP GenAI Security Project, LLM01:2025 Prompt Injection.