Todo mundo que colocou um chatbot ou um agente para atender cliente já viu acontecer: a resposta sai bonita, segura e errada. O reembolso citado não existe mais, o prazo é o do ano passado, a regra é de outro produto. O modelo não mentiu de propósito. Ele simplesmente não sabia, e preencheu o buraco com algo que parecia plausível.
A técnica que resolve isso tem nome: RAG, a geração aumentada por recuperação. Um guia para desenvolvedores publicado pela Confluent explica o padrão passo a passo, com o exemplo de um chatbot de companhia aérea. Abaixo está a nossa leitura, em linguagem de operação, e o que a gente tira disso para quem quer agentes trabalhando com os dados da própria empresa.
De onde vem este texto
O guia é material de um fornecedor, então fala das ferramentas dele. A lógica, porém, vale para qualquer pilha de tecnologia, e é ela que interessa aqui.
O que é RAG, sem jargão
Um modelo de linguagem foi treinado com um volume enorme de texto público, até uma certa data. Ele não conhece a sua política de trocas, a tabela de preços deste mês nem o histórico do cliente que está do outro lado.
RAG é o jeito de entregar esse conhecimento na hora da pergunta. Funciona assim:
- Os documentos da empresa são quebrados em pedaços com sentido próprio: um parágrafo da política, uma cláusula, um registro de atendimento.
- Cada pedaço vira um vetor, uma representação matemática do seu sentido, e vai para um banco vetorial.
- A pergunta do cliente também vira vetor, e o banco devolve os pedaços com sentido mais parecido. Não é busca por palavra-chave: “minha mala sumiu” acha o trecho sobre “bagagem extraviada”.
- Esses trechos entram no pedido ao modelo como contexto, e ele responde com base neles.
A alternativa seria ajustar o próprio modelo com os dados da empresa (o chamado fine-tuning). O guia lembra que isso custa caro, exige gente especializada e pode fazer o modelo esquecer o que já sabia. Com RAG, o modelo fica como está e o conhecimento muda quando a empresa muda.
O problema que quase ninguém vê: o dado envelhece
A maioria das implantações de RAG carrega os documentos uma vez e esquece. Três semanas depois, a política mudou, o estoque é outro e o agente continua respondendo com a foto antiga.
O ponto central do guia é que a base de conhecimento precisa ser alimentada continuamente, com cada mudança entrando assim que acontece, e não em cargas de fim de semana. Sem isso, o RAG só troca uma alucinação por uma informação desatualizada, que é quase tão ruim quanto.
Um agente com RAG é tão bom quanto o dado que chega até ele, e quando chega. Dado certo de ontem ainda pode ser resposta errada hoje.
Nem tudo deve virar vetor
Um erro comum é jogar tudo no banco vetorial. O guia é claro sobre o que faz sentido:
- Vale vetorizar texto livre e documentos: políticas, contratos, manuais, e-mails, avaliações de clientes, relatórios com tabelas e texto misturados.
- Não vale vetorizar o que não tem sentido sozinho, como números de CPF, de cartão ou listas de códigos de produto, nem métricas agregadas (“quantos clientes clicaram no banner”). Isso continua sendo consulta ao banco de dados de sempre.
Uma dica prática do guia: quando um dado estruturado importa, vale traduzir para algo mais perto da linguagem. Um campo “faixa de preço” com “barato” ou “caro” ajuda o modelo a entender o que um número sozinho não diz. E dado pessoal precisa ser filtrado ou mascarado antes de entrar no fluxo, por LGPD e por bom senso.
Os quatro passos de um RAG que funciona
- Abastecer a base. Conectar as fontes (sistemas, documentos, atendimento), limpar, quebrar em pedaços, gerar os vetores e manter tudo atualizado conforme o negócio muda.
- Montar o contexto da pergunta. Na hora do pedido, juntar os trechos certos do banco vetorial com os dados do cliente que estão nos outros sistemas, como a reserva, o plano ou o saldo.
- Quebrar a pergunta em passos. “Posso usar minhas milhas para fazer upgrade e levar uma segunda mala?” são três perguntas: assentos e preço, regra de bagagem, saldo de milhas. Um agente faz cada consulta no sistema certo e só no fim pede ao modelo a resposta. Antes de tudo, confere se a mesma pergunta já foi respondida, para não pagar duas vezes.
- Conferir antes de responder. A resposta do modelo passa por uma checagem separada, com as regras do negócio: o valor do reembolso bate com a política? O número do bilhete existe? Se não bate, não sai.
O quarto passo é o que mais falta nas implantações apressadas. O guia sugere que ele fique com um time diferente, mais perto de conformidade, e separado do resto do sistema, para que as regras possam mudar sem mexer no agente.
Rápido ou certo: uma escolha de negócio
Toda consulta a mais custa tempo. O guia dá um exemplo honesto: uma resposta em um segundo com 90% de acerto ou em dez segundos com 100%. Não existe resposta certa para todos os casos.
- Cliente VIP pedindo reembolso: vale esperar e acertar.
- Time interno consultando um procedimento: rápido e quase sempre certo resolve.
- A maioria das pessoas aceita esperar alguns segundos por uma resposta confiável num atendimento.
O importante é que essa escolha seja feita de propósito, por caso, e medida depois. Não é decisão técnica; é decisão de quem conhece o cliente.
Três exemplos do guia
- Recomendação de produtos no varejo. Estoque, vendas, avaliações e programa de fidelidade alimentam a base, e o assistente recomenda com base no perfil de cada cliente.
- Leitura do mercado em tempo real. Notícias e dados financeiros entram continuamente, e a pergunta “como o mercado reagiu ao balanço?” é respondida com o que saiu há minutos.
- Portal de vagas. O currículo é lido e resumido, o perfil é completado e o sistema cruza candidatos e vagas, para os dois lados.
São só exemplos. A mesma lógica serve para atendimento, jurídico, compras, RH ou financeiro: se a resposta depende de um documento ou de um dado da empresa que muda, é caso para RAG.
O que isso muda na prática
A lição para quem está colocando IA na operação é que o modelo é a parte mais fácil. O trabalho está em ligar as fontes certas, manter o dado vivo, decidir o que vira vetor, quebrar as perguntas difíceis e conferir a resposta antes que ela chegue a alguém. E tudo isso com peças trocáveis: o próprio guia lembra que dá para trocar o modelo, o banco vetorial e o gerador de vetores sem ficar preso a fornecedor.
- O Analista de IA mapeia de onde vem cada resposta que o agente precisa dar e quais regras ele não pode quebrar.
- O Forward Deployed Engineer monta o fluxo dentro da operação: conectores, atualização contínua, filtro de dados pessoais, checagem antes de responder e aprovação humana onde o erro custa caro.
- O treinamento ensina o time a manter a base de conhecimento em dia, que é onde o agente aprende o que mudou.
Atendimento, contratos, políticas internas e catálogos são só exemplos. Se é tarefa que se repete e depende de consultar informação da empresa, dá para automatizar, e com RAG bem feito o agente responde com o dado de agora.
O modelo não sabe nada da sua empresa. RAG é como ele passa a saber, e o streaming é como ele continua sabendo.
Gostou deste artigo?
Receba o próximo antes de ele chegar ao blog.
Um e-mail curto por edição com o que vale a pena sobre agentes de IA na operação. Sem spam.