A maioria dos chatbots de suporte que eu vejo em produção erra da mesma forma: responde com o que o modelo sabe de forma geral, não com o que a empresa de fato faz. O resultado é uma resposta bonita, coerente e completamente errada para o contexto do negócio.
Não estou falando de chatbot ruim com fluxo de pergunta e resposta fixo. Estou falando de chatbot com modelo de linguagem por baixo, configurado de forma genérica, sem nenhum conhecimento real sobre os produtos, políticas e processos de quem está usando. O modelo inventa. E inventa bem. Esse é o problema.
A diferença entre um chatbot que confunde e um que realmente funciona está em dar ao modelo acesso ao conhecimento correto no momento certo. A técnica para isso tem um nome pomposo, RAG, Retrieval Augmented Generation, mas o conceito é simples. Antes de responder, o sistema busca os trechos de documentação, políticas ou FAQs que são relevantes para a pergunta do usuário. Passa esses trechos para o modelo junto com a pergunta. O modelo responde com base no que você forneceu, não no que acha que provavelmente é verdade.
Por que isso muda o resultado
Um modelo de linguagem como o Claude é muito capaz de raciocinar sobre informação que você coloca no contexto. O que ele não consegue fazer é adivinhar qual é a sua política de devolução, quantos dias o frete demora para o Nordeste, se o plano básico inclui suporte prioritário ou não. Isso é conhecimento específico da sua empresa.
Sem isso no contexto, ele vai dar uma resposta plausível. Plausível, não correta.
Já acompanhei implantações em que o pior feedback não era “o chatbot não sabia responder”. Era “o chatbot respondeu errado e o cliente foi embora convencido de uma coisa que não era verdade”. Erro silencioso é pior do que ausência de resposta. Com a base de conhecimento bem construída e o processo de busca funcionando, o chatbot passa a responder com as informações reais: cita o prazo correto, explica a política exata, redireciona para o canal certo quando a situação está fora do escopo dele.
Como a base de conhecimento precisa estar organizada
Essa parte é subestimada na maioria dos projetos.
A qualidade da busca depende diretamente de como o conhecimento está estruturado. Documentos muito longos fragmentam mal. Documentos muito curtos perdem contexto quando recuperados. A granularidade ideal varia por tipo de conteúdo: uma FAQ com perguntas e respostas curtas funciona de forma completamente diferente de um manual de produto com seções longas de procedimento.
O que aprendi na prática é que revisar os documentos antes de indexar poupa muito tempo de ajuste depois. Quando alguém escreve a política de frete como prosa corrida misturada com exceções e tabelas de prazo, o sistema de busca vai ter dificuldade de isolar o trecho certo. Quando a mesma informação está em formato mais estruturado, com cada regra em bloco próprio, a recuperação melhora visivelmente.
Aliás, isso gera um efeito colateral interessante. O processo de construir a base de conhecimento para o chatbot força a empresa a organizar informação que estava espalhada por e-mails, planilhas, documentos avulsos. Já vi empresa que não sabia qual era a política de reembolso vigente porque havia quatro versões em circulação. O chatbot não pode ter ambiguidade, então o projeto acaba resolvendo algo que deveria ter sido resolvido antes.
O que o Claude faz bem nesse cenário
Instrução de comportamento funciona muito bem. Você define que o chatbot deve responder apenas com base nos documentos fornecidos, que quando não souber deve dizer que não sabe, que em determinados casos deve encaminhar para um humano. Ele segue essas instruções com consistência razoável.
A parte de raciocínio sobre documentos também é boa. Se um usuário faz uma pergunta que exige combinar informação de dois trechos diferentes, o modelo consegue fazer essa síntese. Isso vai além de recuperação simples, e é onde os modelos mais capazes começam a mostrar diferença em relação aos intermediários.
O que exige atenção é a tendência de responder mesmo quando não deveria. Sem instrução explícita para recusar, o modelo vai tentar ser útil e vai preencher lacunas com estimativas. Você precisa ser deliberado na instrução de comportamento para conter isso.
A integração com suporte humano
Chatbot que resolve tudo é ficção.
Mesmo bem implementado, haverá casos que fogem do escopo, situações que precisam de julgamento humano, clientes que não vão se satisfazer com nenhuma resposta automatizada. O sistema precisa saber quando escalar.
Na prática, o que funciona é definir critérios claros de transferência: tipo de problema, nível de insatisfação percebida, presença de palavras que indicam urgência ou reclamação formal. Quando qualquer um desses critérios é detectado, o chatbot transfere com contexto, não do zero. O atendente humano recebe o resumo da conversa, o problema identificado e o que foi tentado.
Isso é onde muita empresa erra: fazem o handoff sem contexto, o atendente precisa pedir ao cliente que explique de novo o que já explicou, e o nível de frustração aumenta. Parece detalhe de implementação. Não é.
Manutenção que ninguém planeja
A base de conhecimento precisa ser atualizada. Preço muda, política muda, produto muda.
Se o processo de atualização for manual e trabalhoso, ele não vai acontecer com regularidade, e o chatbot vai começar a responder com informação desatualizada. Isso precisa estar no design desde o início: como as atualizações entram na base, quem é responsável, com que frequência o conteúdo é revisado. Um processo simples de atualização que funciona na prática vale mais do que uma arquitetura sofisticada que ninguém consegue manter.
Pois é. O chatbot em si é menos da metade do projeto. A outra metade, que aparece depois do deploy, é governança do conhecimento.
Quando compensa
Para empresa com volume alto de atendimento e perguntas repetitivas, o retorno é claro. Se sessenta por cento das interações de suporte são variações das mesmas vinte perguntas, automatizar esse volume com qualidade resolve um problema real.
Para empresa com poucos atendimentos por dia, sinceramente, o custo de construção e manutenção provavelmente não se paga tão rápido. Não porque a tecnologia não funcione, mas porque o problema não tem escala suficiente para justificar a solução.
A pergunta que sempre faço antes de recomendar: quantas conversas de suporte você tem por mês, e qual porcentagem delas o cliente poderia ter resolvido sozinho se a resposta correta estivesse acessível? Se esse número for alto, a conversa sobre chatbot vale a pena. Se for baixo, provavelmente tem outra prioridade melhor.
Gabriel Schunck está disponível para consultorias e projetos de IA para atendimento. Entra em contato pelo gabriels.dev.br.