Por que o chatbot inventa preços e prazos que não existem?

Porque o modelo foi treinado para produzir texto plausível e, sem acesso à sua tabela real, ele completa a lacuna com algo que soa razoável. A correção é conectar o bot à fonte de dados real e instruí-lo a recusar a resposta quando não encontrar o valor.

Trocar de modelo por um mais novo resolve o problema?

Raramente. Modelos mais novos erram menos em raciocínio, mas nenhum modelo adivinha um dado que nunca recebeu. Se a causa é falta de acesso à informação da empresa, trocar de modelo só muda o texto do erro.

Dá para o chatbot admitir que não sabe?

Sim, e isso deve ser projetado explicitamente. Configure um limiar de relevância na busca, uma instrução clara de recusa e um caminho de transferência para humano. Um bot que diz não sei e transfere gera menos dano que um que responde errado com confiança.

Por que o chatbot da sua empresa erra e como resolver

Um chatbot corporativo erra por três causas, e quase sempre é possível identificar qual delas está agindo: ele não tem acesso à informação correta, ele tem a informação mas foi instruído de forma frouxa, ou ele foi autorizado a opinar sobre assuntos que deveriam estar fora do escopo. Trocar de modelo não resolve nenhuma das três.

O erro mais comum é o bot não ter a informação

Modelos de linguagem preveem a continuação mais provável de um texto. Quando perguntam o prazo de entrega para o interior de Minas e o modelo não tem essa tabela, ele não trava, ele completa com algo plausível. "Cinco a sete dias úteis" soa perfeitamente razoável e pode estar completamente errado.

Isso não é defeito do modelo, é o comportamento esperado dele. O defeito está na arquitetura de quem ligou um modelo genérico ao atendimento de uma empresa sem conectar as fontes de verdade.

A correção é dupla:

Conectar às fontes. Informação em texto (políticas, manuais, condições comerciais) entra por RAG: os documentos viram trechos indexados e o sistema recupera os relevantes antes de responder. Informação transacional (status do pedido, saldo, disponibilidade) entra por tool-use: o modelo chama uma função que consulta o sistema ao vivo. Nunca indexe dado transacional em documento, ele nasce velho.

Fechar a saída. A instrução do sistema precisa ser explícita: responda apenas com base no material recuperado, cite a origem, e diga que não encontrou quando não encontrar. Um prompt genérico de "seja prestativo" produz um bot que prefere inventar a decepcionar.

Por que RAG corrige a maior parte disso

RAG muda a natureza da tarefa que o modelo executa. Sem RAG, a pergunta é "responda isto"; o modelo puxa da memória difusa do treinamento. Com RAG, a pergunta vira "responda isto usando apenas o texto abaixo"; a tarefa passa a ser de leitura e síntese, algo em que modelos são muito mais confiáveis do que em recuperação de memória.

Além disso, RAG traz duas propriedades que importam em empresa:

Rastreabilidade. A resposta aponta o documento e a seção. Quando alguém contesta, existe onde verificar.
Atualização barata. Mudou a política, você reindexa o arquivo. A resposta muda no mesmo dia, sem retreino de nada.

Mas RAG não é mágica, e o próximo tópico é justamente onde ele falha.

Quando o bot tem RAG e ainda assim erra

Sintoma	Causa provável	Correção
Responde sobre o tema certo, mas com detalhe errado	Chunk cortado no meio, perdeu contexto	Cortar por seção e guardar o título junto com o trecho
Erra em códigos, SKUs, números de norma	Busca vetorial pura não lida bem com identificadores	Busca híbrida (vetorial + BM25) e reranker
Traz a resposta de um documento antigo	Versões antigas indexadas junto com as novas	Metadado de vigência e filtro por data na busca
Dá informação de outro cliente ou setor	Falta de filtro de permissão na recuperação	Filtrar por permissão na consulta, antes do modelo ver
Mistura dois documentos que se contradizem	A base tem contradição real	Definir a fonte de verdade e arquivar o resto
Responde bem em teste e mal em produção	Perguntas reais são mais bagunçadas que as de teste	Montar o conjunto de avaliação com perguntas reais do histórico

Note que quase todas as causas estão na etapa de busca, não na de geração. Se o trecho certo não é recuperado, nenhum modelo acerta. É por isso que a maior parte do trabalho de quem constrói esses sistemas, o padrão nos projetos da Retti Tech também, está em ingestão, corte e recuperação, não em prompt.

O bot erra porque foi autorizado a falar demais

Muito chatbot corporativo é solto sem escopo. Perguntam sobre concorrente, sobre política, sobre um caso jurídico específico, e ele responde, porque ninguém disse que não devia.

Delimite por escrito e no código:

Assuntos permitidos. Fora deles, o bot recusa e oferece transferência.
Ações que exigem humano. Cancelamento, reembolso, negociação de desconto, qualquer coisa com efeito financeiro ou jurídico.
Frases proibidas. Compromisso de prazo sem consulta ao sistema, garantia de resultado, aconselhamento médico, contábil ou jurídico.
Limiar de confiança. Se a busca não retornar nada acima de um certo grau de similaridade, o bot não tenta, ele encaminha.

O último item é o mais negligenciado e o mais eficaz. Um bot que transfere 20% das conversas com honestidade é infinitamente melhor que um que responde 100% com 15% de erro silencioso.

Como descobrir qual é a sua causa

Não adivinhe. Pegue de 30 a 50 conversas reais em que o bot errou e classifique cada uma:

A informação existia na base? Se não, o problema é de conteúdo, não de IA.
A informação existia e não foi recuperada? Problema de busca, chunking, embedding, ausência de híbrido ou de reranker.
Foi recuperada e o modelo respondeu diferente do trecho? Problema de instrução ou de contexto excessivo diluindo o que importa.
O bot não deveria nem ter tentado responder? Problema de escopo e de guardrail.

Essa classificação leva algumas horas e vale mais do que qualquer troca de ferramenta. Na maioria das auditorias, a maior fatia cai nas duas primeiras categorias: a base estava incompleta, desatualizada ou contraditória.

Medir antes e depois

Sem medição, correção vira opinião. Monte um conjunto de avaliação com 50 a 100 perguntas reais, cada uma com a resposta esperada e a fonte correta. A cada mudança, novo chunking, novo modelo, novo prompt, rode o conjunto e compare três números: quantas respostas corretas, quantas com a fonte certa, e quantas recusas indevidas.

Sem esse termômetro, toda alteração parece melhorar alguma coisa e piorar outra sem que ninguém perceba. Com ele, o chatbot para de ser aposta e vira sistema.