RAG na prática: o que decide se o assistente acerta ou inventa

Construímos um assistente sobre 374 documentos do nosso próprio site e medimos com 638 perguntas escritas pelo time de conteúdo. Em quase metade delas, o material recuperado não continha a resposta. O modelo não tinha culpa nenhuma.

Quase toda empresa que tentou colocar um assistente de IA sobre a própria documentação passou pela mesma sequência: a demonstração impressiona, o piloto anima, e o uso real decepciona. O assistente responde com uma política que foi revogada, cita um preço de três anos atrás, ou inventa uma resposta educada para algo que ninguém nunca escreveu.

Quando isso acontece, a reação normal é trocar de modelo. É a peça mais visível e a mais fácil de trocar. E é quase sempre a peça errada.

Este artigo mostra o que realmente decide a qualidade de um assistente ligado à base de conhecimento da empresa, com os números de um sistema que construímos e medimos.

RAG é buscar antes de responder

RAG, sigla de Retrieval-Augmented Generation, é uma arquitetura com uma regra simples: o sistema procura na sua base antes de deixar o modelo escrever qualquer coisa. Os trechos encontrados entram no pedido, e o modelo redige a resposta a partir deles, citando de onde veio cada afirmação.

A diferença prática está no que acontece quando a informação muda. Sem RAG, o conhecimento está embutido no modelo e mudar uma política significa refazer um processo caro. Com RAG, o conhecimento fica fora do modelo: você corrige o documento e a próxima resposta já sai certa.

É por isso que RAG é a escolha padrão para conhecimento corporativo. Política, preço, procedimento e catálogo mudam o tempo todo, e o custo de manter isso atualizado precisa ser o custo de editar um documento, não o de reprocessar um modelo.

A contrapartida é que a qualidade da resposta passa a depender inteiramente da qualidade do que está escrito. O sistema não conserta um manual mal escrito. Ele expõe.

Não é a mesma coisa que anexar um PDF no chat

Anexar um documento a uma conversa e perguntar sobre ele resolve um problema para uma pessoa, naquele momento. Muita gente já faz isso, e faz bem. Isso não é RAG, e confundir os dois é o que faz projetos nascerem com a expectativa errada.

A diferença é a mesma que existe entre uma planilha e um sistema. Anexar funciona enquanto o volume cabe na conversa, enquanto quem pergunta sabe qual arquivo abrir e enquanto ninguém precisa auditar de onde veio a resposta. Nenhuma dessas três condições sobrevive à escala de uma empresa.

O resumo é que anexar é uma ferramenta pessoal e RAG é uma peça de infraestrutura. Empresas que tratam a segunda como a primeira acabam com dezenas de cópias desatualizadas do mesmo manual circulando por conversas privadas.

Onde isso se aplica de verdade na empresa

O padrão que faz um caso valer a pena é sempre o mesmo: existe conhecimento escrito, ele muda, e gente qualificada gasta tempo procurando por ele. Onde essas três condições aparecem juntas, RAG paga.

• AtendimentoResponder com a política que vale hoje, não com a que estava no manual antigo.
• Pré-vendaResponder questionário de segurança e edital do cliente sem parar a equipe por dias.
• OnboardingDar ao funcionário novo as perguntas que ele teria vergonha de fazer ao gestor.
• Help desk internoFechar sozinho o chamado que era só "onde está o procedimento".
• JurídicoAchar a cláusula equivalente numa base de contratos que ninguém lê inteira.
• ComplianceResponder à auditoria onde está escrito que a empresa faz aquilo.
• BackofficeConsultar a regra de alçada e aprovação que ninguém memoriza.
• CampoConsultar o manual de centenas de páginas pelo celular, dentro do cliente.

Os três primeiros concentram o volume, porque envolvem muita gente perguntando a mesma coisa. Os últimos concentram valor por consulta, porque cada resposta economiza horas de um profissional caro.

Construímos um e medimos: os números

Para escrever este artigo com base em alguma coisa que não fosse teoria, montamos um RAG sobre o conteúdo público da X-Apps: artigos do blog, páginas de serviço, cases e perguntas frequentes. É um corpus institucional em português, do tipo que qualquer empresa tem.

O teste simula a situação real: a pergunta existe e foi escrita por uma pessoa, mas o texto dela não está no índice. É a pergunta inédita, que é o único caso que importa medir. Perguntar aquilo que já está escrito com as mesmas palavras não prova nada.

A leitura importante dessa curva não é o número de cima, é o formato dela. Entre 10 e 20 resultados a curva achata: entregar o dobro de material ao modelo comprou 3,6 pontos percentuais. Isso significa que o que falta não está mais fundo na lista. Está fora da base.

O gargalo é o conteúdo, não o algoritmo

Existe uma segunda métrica, e é ela que muda a conversa. Além de perguntar se o documento certo apareceu, medimos quanto da resposta correta estava de fato presente no material recuperado. O resultado foi 54,1% em média, e apenas 63% das perguntas tiveram pelo menos metade da resposta coberta.

Traduzindo para linguagem de projeto: em quase metade das perguntas, nenhum modelo do mundo produziria uma boa resposta, porque a informação necessária não estava escrita em lugar nenhum do material. O sistema estava funcionando. A base é que estava incompleta.

Isso tem uma consequência prática boa. Medir cobertura de conteúdo é barato, roda sem contratar nada e aponta exatamente quais perguntas do seu negócio não têm resposta documentada. Essa lista costuma valer mais para a operação do que o assistente em si.

Conteúdo velho vence conteúdo novo

Este é o risco que mais aparece em produção e o menos antecipado. Perguntamos ao sistema quanto custa desenvolver um aplicativo, que é uma das perguntas comerciais mais frequentes que existem.

Consulta ao índice do protótipo em 31/08/2026. Pontuação da busca lexical, sem filtro de data.

Quatro dos cinco primeiros resultados são de 2019 a 2022. O único documento atual ficou em terceiro. Um assistente ingênuo montaria uma resposta convincente sobre preço de aplicativo usando material da época em que o iPhone 11 era lançamento.

A correção não é sofisticada, e é justamente por isso que ela precisa ser decidida no projeto e não descoberta depois. Cada documento entra no índice com uma etiqueta de frescor, derivada da data. Conteúdo abaixo de um limite fica de fora das respostas, e conteúdo sensível a tempo, como preço e prazo, fica de fora sempre.

O sistema precisa saber dizer que não sabe

Um assistente que responde tudo é pior que um assistente que responde pouco, porque destrói a confiança na primeira resposta errada e ninguém volta. A capacidade de se abster é o comportamento de segurança mais importante do sistema, e o mais negligenciado nos protótipos.

A ideia intuitiva para implementar isso é olhar a pontuação da busca: se o melhor trecho pontuou baixo, a pergunta está fora do escopo e o sistema se cala. Testamos, e o resultado foi o contrário do esperado.

A pergunta sobre bolo de cenoura pontuou mais alto que a pergunta sobre o nosso próprio serviço, nas duas métricas. O motivo fica visível ao abrir os resultados: em português, "não existe receita de bolo" é uma expressão comum em texto corporativo, e "receita" também significa faturamento. Com algumas centenas de textos em português, quase toda palavra frequente aparece em algum lugar.

A conclusão de projeto é direta: a decisão de responder ou se calar precisa acontecer antes da busca, e precisa entender a pergunta, não contar palavras. Na prática isso vira um classificador barato, com entrada de poucas dezenas de tokens, que decide se aquilo é assunto da empresa antes de qualquer custo relevante.

É uma peça pequena e é ela que separa um assistente confiável de um gerador de respostas plausíveis.

As três peças de um RAG que funciona

O desenho que sobreviveu à medição tem três estágios, e cada um usa a ferramenta mais barata que resolve aquele problema.

O detalhe que economiza dinheiro é usar modelos diferentes em papéis diferentes. O porteiro processa poucas dezenas de tokens e roda a cada pergunta, inclusive nas que serão recusadas. O redator é caro e só entra quando já existe material bom na mesa. Inverter essa ordem, que é o que um protótipo ingênuo faz, significa pagar preço de redação para responder sobre bolo de cenoura.

O limite de trechos por documento é o outro detalhe que parece burocrático e não é. Sem ele, uma única página longa ocupa o contexto inteiro e todo o resto da base fica invisível para o modelo.

Quanto disso é software e quanto é curadoria

A parte de software de um RAG é menor do que a indústria sugere. O índice do nosso corpus inteiro, com 2.563 trechos, é montado em 0,4 segundo e cabe num arquivo de poucos megabytes. Não houve banco de dados, servidor de busca nem serviço pago envolvido para chegar aos números deste artigo.

A parte de curadoria é a que não tem atalho. Ela é composta de decisões que só quem conhece o negócio pode tomar: qual documento é a versão oficial de cada assunto, o que está obsoleto e deve sair, qual pergunta frequente ainda não tem resposta escrita, e quem é o dono de manter isso.

É a diferença entre um sistema que se entrega uma vez e um sistema que alguém cuida.

Na prática, isso vira uma rotina curta e verificável, que cabe em cinco pontos.

• Existe uma pessoa responsável por revisar as perguntas que o assistente não soube responder
• Cada assunto relevante tem um documento declarado como a fonte oficial
• Conteúdo obsoleto é retirado do índice, e não apenas deixado para trás no site
• Preço, prazo e SLA têm tratamento próprio, separado do resto do conhecimento
• Existe um conjunto de perguntas reais que roda a cada mudança, para detectar regressão

Quando a lista acima não tem dono, o assistente degrada sozinho: a base envelhece, as respostas pioram devagar e ninguém percebe até um cliente reclamar.

Quando RAG não é a resposta

Nem todo problema de IA é um problema de recuperação, e insistir em RAG onde ele não cabe produz sistemas complicados que resolvem mal.

Os dois últimos itens da coluna direita são a fronteira mais comum na prática. Quando a resposta depende do saldo de um contrato ou do status de um pedido, o dado está no ERP e não em documento nenhum, e o desenho passa a exigir consulta a sistema. Quando o usuário quer que algo aconteça, e não apenas ser informado, o assunto vira sistema agêntico.

Por onde começar sem gastar

O primeiro passo custa pouco e responde a pergunta mais cara: a sua base sustenta as perguntas que o seu negócio recebe?

Junte as perguntas reais que a operação já responde por escrito, hoje, em atendimento, comercial e help desk. Monte um índice simples sobre os documentos que existem. Rode as perguntas e leia os trechos recuperados, sem pedir resposta a nenhum modelo. Se os trechos respondem, o projeto é viável e a escolha de tecnologia vira detalhe. Se não respondem, você acabou de descobrir, de graça, que o projeto era de conteúdo e não de software.

É esse teste que separa os assistentes que entram em produção dos que ficaram bonitos na demonstração.

Fontes e método

Os números deste artigo vêm de um protótipo de recuperação construído sobre o conteúdo público da X-Apps, executado em 31 de agosto de 2026. O corpus tem 374 documentos e 2.563 trechos, com alvo de 350 palavras por trecho e sobreposição entre trechos vizinhos.

A avaliação usou 730 perguntas escritas pelo time de conteúdo, cada uma com documento de origem conhecido. Foram descartadas 5 sem corpo de documento e 87 que não carregavam nenhum termo distintivo do documento esperado, restando 638 perguntas. O regime de teste remove do índice o texto das próprias perguntas, para simular pergunta inédita.

Duas ressalvas honestas sobre o alcance desses números. A primeira é que eles medem recuperação, ou seja, se o material certo chega ao modelo, e não a qualidade final da resposta escrita. A segunda é que o corpus é de conteúdo institucional em português: bases de outra natureza, como código, jurisprudência ou documentos multilíngues, podem se comportar de outro jeito.

Perguntas frequentes