O problema com bot de IA no WhatsApp não é quando ele não sabe a resposta. É quando ele acha que sabe — e responde com algo que parece verdade, mas não é.
Donos de negócio que ligam IA no atendimento descobrem isso no pior momento: o cliente reclama que o bot prometeu prazo de troca que não existe, citou um serviço que nem está no portfólio, ou afirmou um horário de funcionamento errado. Em 2024, a Air Canada foi obrigada a honrar uma política de reembolso que o próprio chatbot da companhia inventou — a decisão veio do tribunal civil de British Columbia, no Canadá, e virou referência nas discussões sobre responsabilidade de empresas pelo que o bot promete. O sistema falou, o sistema cobra.
Esse comportamento tem nome técnico: alucinação. E não é um bug que vai sumir quando o modelo melhorar. É como o LLM funciona por padrão. A boa notícia é que o atendimento bem montado tem três camadas de defesa que reduzem consideravelmente o problema.
Principais pontos
- Alucinação acontece porque o LLM completa texto plausível, não porque tem opinião própria — sem instrução para consultar a base do seu negócio, ele preenche com o que parece coerente.
- O risco aumenta quando o escopo do bot é amplo demais, do tipo "responda qualquer pergunta do cliente" sem delimitar de onde a resposta deve vir.
- A defesa real é em camadas: RAG com limiar de confiança, prompt restritivo e auditoria do painel. Nenhuma das três sozinha resolve.
- A primeira semana de uso ensina mais do que qualquer planejamento prévio — é lendo conversa real que você descobre o que falta documentar.
- O trade-off é entre cobertura ampla e confiança: bot que responde tudo erra mais; bot que responde "não sei" frustra menos do que parece.
Para quem está colocando IA no atendimento agora, a pergunta não é mais "meu bot vai ter IA generativa?". É "qual a arquitetura que evita que ele invente?". Esse é exatamente o tipo de decisão que produtos como o VertisBot precisam tornar concreta — não como promessa de marketing, mas como configuração técnica auditável.
Alucinação não é bug, é como o modelo completa texto
Para entender por que isso acontece, vale separar o que o LLM realmente faz por dentro. Quando o cliente pergunta "vocês trocam produto em 30 dias?", o modelo não consulta documento nenhum por mágica. Ele recebe a pergunta como sequência de tokens e gera o próximo token mais provável dado o contexto. Repete o processo até formar uma resposta inteira.
Sem nada extra, esse "próximo token mais provável" é puxado do treinamento geral do modelo — que viu milhões de textos sobre políticas de troca, horários comerciais e descrições de serviços. Então o modelo costuma produzir uma resposta plausível, com tom seguro, no português que você esperaria de um atendente. O problema é que essa resposta não tem origem na sua empresa. Tem origem na média estatística de como outras empresas falam sobre o tema.
Isso explica o paradoxo: o bot soa correto e está errado ao mesmo tempo. Ele não está mentindo no sentido humano. Está fazendo exatamente o que foi treinado pra fazer — completar texto.
O que torna um bot vulnerável a inventar resposta
Três configurações disparam alucinação consistentemente:
Prompt aberto demais. Frases como "você é um assistente que ajuda clientes da Loja X" não definem fronteira. O modelo entende "ajude" como "responda qualquer coisa razoável". Quando a pergunta foge da base, ele preenche com palpite.
Base de conhecimento sem cobertura. Se o cliente perguntar sobre algo que não está nos documentos que você subiu — e o bot não tiver regra explícita pra dizer "não tenho essa informação" — o modelo entra em modo improviso. Como já viu textos parecidos no treino, escreve algo que parece correto.
Tom comercial otimista. Modelos treinados pra serem "úteis" tendem a evitar respostas negativas. Eles preferem dar uma resposta qualquer a admitir desconhecimento. Sem instrução contrária, a tendência é completar com confiança.
A combinação dos três é o cenário que mais aparece em conversa real: cliente pergunta algo razoável, o bot não tem na base, o prompt não bloqueia, o modelo improvisa, o cliente acredita.
Três camadas de defesa que blindam o atendimento
A arquitetura defensável tem três camadas trabalhando juntas. Nenhuma sozinha resolve. Juntas, reduzem consideravelmente o risco.
Camada 1: RAG com limiar de confiança
RAG — Retrieval Augmented Generation — é o mecanismo que faz o bot consultar sua base antes de responder. Funciona assim: o cliente pergunta, o sistema busca os trechos mais relevantes nos documentos que você subiu, e só então o modelo gera a resposta usando esses trechos como contexto.
A peça que muita gente esquece é o limiar de confiança. A busca vetorial sempre retorna alguma coisa, mesmo quando a pergunta não tem nada a ver com sua base. Então é preciso definir um corte: se o melhor resultado tiver similaridade abaixo do limite, o sistema trata como "não encontrado" e dispara o caminho de fallback, em vez de empurrar trechos irrelevantes pro modelo (que vai usá-los e produzir resposta ruim).
Como regra prática, a calibração desse limiar é feita depois das primeiras dezenas de conversas reais. Começa conservador (favorece o "não sei") e afrouxa se você ver perguntas legítimas caindo no fallback à toa.
Camada 2: prompt restritivo que ordena "não sei"
O prompt do sistema é onde você impõe a fronteira. Em vez de "você é um assistente útil", a instrução vira algo como: "Responda apenas com base nos trechos fornecidos. Se a informação não estiver nos trechos, diga que não tem essa informação no momento e ofereça registrar a dúvida pro time."
Essa única mudança reduz boa parte das alucinações do tipo "modelo inventa porque foi treinado pra ser prestativo". O modelo passa a tratar "não sei" como resposta válida, em vez de evitar essa frase a todo custo.
A linguagem importa. "Não sei" puro soa frio. "Vou registrar essa pergunta pro time retomar com você o quanto antes" mantém o atendimento profissional sem inventar resposta.
Camada 3: revisão do histórico no painel
A terceira camada não é técnica do bot — é operacional sua. Você precisa ler conversa real. Idealmente nos primeiros sete dias, e depois em revisão semanal por algum tempo.
O que você procura: respostas que parecem corretas mas você sabe que não estão na base, perguntas que caíram em "não sei" mas deveriam ter resposta documentada, e padrões de dúvida que você não tinha mapeado. Cada um desses três pontos é uma instrução pra você: ajustar prompt, completar base, ou revisar limiar.
Sem essa terceira camada, as duas primeiras viram conjectura — você acha que está blindado porque o sistema parece estar respondendo bem, mas só checando o histórico você confirma. Em referência inicial, separar uma hora por semana pra essa revisão costuma bastar nas primeiras semanas.
O trade-off real: cobertura ampla versus cobertura estreita
Toda decisão de arquitetura aqui passa pelo mesmo dilema. Você pode configurar o bot pra responder amplamente — passa do limiar com facilidade, prompt menos restritivo, fallback raro. Isso parece bom porque o cliente quase nunca ouve "não sei". O custo é maior risco de invenção. Quando o bot erra, erra com tom de quem sabe.
Ou você configura conservador — limiar exigente, prompt rigoroso, "não sei" como caminho aceitável. O cliente vê o fallback com mais frequência. Em compensação, o que o bot afirma você pode confiar.
O ponto é que não existe meio-termo gratuito. Você está sempre trocando uma coisa pela outra. A escolha certa depende do tipo de pergunta que aparece e do custo de um erro. Atendimento sobre horário e endereço tolera mais cobertura ampla. Atendimento sobre política de cancelamento, garantia ou prazo legal pede a versão conservadora.
Como auditar seu bot na primeira semana de uso
Auditoria honesta é simples mas exige disciplina. Três passos:
- Liste as últimas conversas completas (pergunta inicial + resposta do bot, em sequência) — algumas dezenas costuma bastar pra capturar padrão.
- Marque cada uma com uma das categorias: resposta correta com origem clara na base, resposta correta mas sem origem clara (sinal de alerta), resposta errada ou inventada, "não sei" apropriado, "não sei" indevido.
- Conte as ocorrências por categoria. Os três primeiros números dizem se você tem problema de alucinação. Os dois últimos dizem se você está sendo restritivo demais.
Em referência inicial, dá pra fazer essa varredura em cerca de uma hora. Repete depois de cada ajuste de prompt ou base. Depois de algumas rodadas, o padrão estabiliza e você passa a fazer revisão por amostragem.
Como o VertisBot ajuda contra alucinação no atendimento
O VertisBot foi pensado pra que essas três camadas estejam disponíveis sem você ter que montar a arquitetura do zero. Na prática:
- Base de conhecimento com upload, parsing, chunking e embeddings, que monta a camada de RAG a partir dos arquivos que você sobe (PDF, texto, conteúdo do site).
- Configuração de comportamento do agente, onde dá pra restringir o tom, definir o que ele deve dizer fora do escopo da base, e ajustar como ele se apresenta ao cliente.
- Painel multi-tenant com conversas e analytics, onde o operador lê o histórico real, marca o que está fora do esperado e usa esse insumo pra refinar a base ou o prompt.
- Modelo configurável conforme a necessidade, incluindo a opção de usar a própria chave de IA (BYO key) — útil pra quem quer controle direto sobre qual LLM está respondendo.
- Atendimento no webchat do site e no WhatsApp, com a mesma base e o mesmo comportamento nos dois canais, evitando comportamentos divergentes entre canais.
Vale lembrar que o VertisBot opera exclusivamente com IA — não tem transferência ao vivo pra atendente humano dentro do painel. O fallback de "não sei" pode incluir registro pra contato posterior, que o operador retoma no canal e no tempo dele.
Perguntas frequentes
Se eu usar RAG, a alucinação é resolvida?
RAG reduz consideravelmente, mas não elimina sozinha. Sem limiar de confiança bem calibrado, o sistema empurra trechos pouco relevantes pro modelo e ele ainda inventa. Sem prompt restritivo, o modelo ignora os trechos e improvisa. As três camadas trabalham juntas.
Posso confiar no "não sei" do bot?
Tende a ser mais confiável do que uma resposta com tom seguro mas sem origem clara. "Não sei" controlado é sinal de bot calibrado. O risco real está em respostas que soam corretas e não têm raiz na sua base.
Por que o bot acerta sobre horário e erra sobre política de troca?
Geralmente porque horário está claramente na base e política de troca está vaga ou ausente. O modelo improvisa onde não tem trecho de apoio e o limiar passou. A revisão do painel identifica esse tipo de lacuna.
Preciso revisar conversa pra sempre?
Mais intensivamente nas primeiras semanas, quando você ainda está calibrando. Depois, em amostragem semanal. Operações com volume alto costumam montar revisão por tema, em vez de conversa por conversa.
O bot pode aprender sozinho com as conversas?
Não na forma como você está pensando. O LLM não atualiza a base automaticamente. Quem atualiza é você (ou seu time) ao revisar o histórico e identificar lacunas. Esse fluxo de "leu conversa → atualizou base → bot melhorou" é manual por design — é parte da segurança do sistema.
Fechamento
Alucinação não vai desaparecer no curto prazo. É uma característica de como modelos de linguagem funcionam, e a forma de conviver com ela é arquitetura, não fé na tecnologia. As três camadas — RAG com limiar, prompt restritivo e auditoria do painel — não eliminam o problema, mas reduzem consideravelmente e te dão visibilidade pra agir.
O que separa o bot que funciona do que vira passivo do cliente é simples: o primeiro foi calibrado lendo conversa real, o segundo foi ligado e esquecido. Não tem como pular essa etapa.
