Todo mundo já testou um assistente de I.A. e viu a mesma coisa: ele escreve bem, argumenta bem e não sabe nada sobre a sua empresa. Não conhece a política de devolução, o contrato do cliente X, o histórico de chamados nem o manual do produto. RAG, sigla para Retrieval-Augmented Generation, é a técnica que resolve exatamente esse problema: em vez de treinar um modelo do zero, você entrega ao modelo os documentos certos no momento certo, e ele responde com base neles. Este post explica como isso funciona, onde costuma falhar e o que precisa estar pronto antes de começar.
O que é RAG e por que ele venceu o fine-tuning
Existem dois caminhos para uma I.A. "aprender" o conteúdo de uma empresa. O fine-tuning ajusta os pesos do modelo com os seus dados: caro, lento, difícil de atualizar e sem rastreabilidade (o modelo responde, mas não diz de onde tirou). O RAG faz diferente: guarda os documentos em uma base de busca, recupera os trechos mais relevantes para cada pergunta e coloca esses trechos no contexto do modelo antes de ele responder.
Para o negócio, a diferença é enorme. Com RAG, um documento atualizado hoje já vale na resposta de amanhã. Cada resposta pode citar a fonte. E o custo acompanha o uso, não um ciclo de treinamento. É por isso que a quase totalidade das aplicações corporativas de I.A. que chegaram a produção usa RAG, e não modelos customizados.
Como funciona o pipeline, passo a passo
Um pipeline de RAG tem quatro etapas, e cada uma esconde decisões de engenharia.
Ingestão: os documentos (PDFs, páginas de wiki, tickets, planilhas, e-mails) são coletados, limpos e quebrados em pedaços menores, os chunks. O tamanho e a estratégia de quebra afetam diretamente a qualidade: cortar uma tabela no meio ou separar a pergunta da resposta em um FAQ destrói o sentido.
Indexação: cada chunk é convertido em um embedding, um vetor numérico que representa o significado do texto, e armazenado em um banco vetorial. Aqui entram escolhas de modelo de embedding, dimensionalidade e metadados (data, área, nível de acesso) que permitem filtrar depois.
Recuperação: quando o usuário pergunta, a pergunta vira embedding, o sistema busca os chunks mais próximos e, nos pipelines maduros, combina busca semântica com busca por palavra-chave (busca híbrida) e reordena os resultados com um reranker.
Geração: os trechos recuperados vão para o prompt, com instruções claras de responder só com base neles e de citar a origem. O modelo escreve a resposta final.
Na prática, o modelo de linguagem é a parte mais fácil de trocar. O valor, e o risco, estão nas três primeiras etapas.
Onde os projetos de RAG falham
O erro mais comum é tratar RAG como projeto de I.A. quando ele é, antes de tudo, um projeto de engenharia de dados. Se a base tem três versões da mesma política, uma delas vencida, o sistema vai recuperar a errada em algum momento. Se os documentos estão em imagens escaneadas sem OCR, eles simplesmente não existem para o pipeline. Se não há metadados de permissão, um vendedor pode receber na resposta um trecho do contrato que só a diretoria deveria ver.
O segundo erro é não medir. Um RAG sem avaliação é um chute bem redigido. É preciso montar um conjunto de perguntas com respostas esperadas, medir precisão da recuperação e fidelidade da resposta, e rodar isso a cada mudança de chunking, embedding ou prompt. Sem esse ciclo, ninguém sabe se a versão nova ficou melhor ou pior.
O terceiro é começar grande demais. Indexar "todos os documentos da empresa" no primeiro sprint garante uma base suja e um resultado decepcionante.
O que precisa estar pronto antes de começar
Uma pergunta de negócio bem delimitada, com um público claro: "reduzir o tempo de resposta do suporte nível 1 usando a base de conhecimento" é um bom início; "uma I.A. que sabe tudo da empresa" não é.
Um corpus curado e com dono: alguém responsável por dizer qual documento é a verdade e por retirar o que venceu.
Regras de acesso definidas: quem pode ver o quê precisa estar modelado antes da indexação, não depois de um vazamento.
Um conjunto de avaliação: cinquenta perguntas reais, com as respostas certas, já servem para começar.
Essa é a parte em que a Alcance Tech costuma entrar: traduzir a dor ("o suporte demora", "ninguém acha o contrato certo") em um recorte de dados, um pipeline versionado e um conjunto de métricas, para que o RAG entre em produção com evidência, não com demonstração.
RAG como camada permanente da empresa
Quando bem construído, um RAG deixa de ser "o chatbot" e vira infraestrutura: uma camada de acesso ao conhecimento que qualquer sistema pode consultar, do atendimento ao onboarding de funcionários. O modelo de linguagem por trás vai mudar várias vezes nos próximos anos. A base de dados organizada, com dono, permissão e métrica, é o ativo que fica.