Como fazer RAG: divisão de textos, embeddings e reranking

Como fazer RAG: divisão de textos, embeddings e reranking

Para fazer RAG, você prepara os documentos, divide em trechos, transforma cada trecho em embedding, busca os mais próximos da pergunta, reordena os candidatos com reranking e só então entrega o contexto ao modelo para responder. A qualidade quase nunca se perde na geração da resposta, e sim antes: texto mal extraído, trechos mal cortados e busca que ninguém testou. Por isso o caminho mais seguro é testar cada etapa separadamente, com perguntas reais e respostas já conhecidas.

Principais pontos

• RAG é uma cadeia de etapas. Se o trecho certo não chega ao modelo, nenhum prompt conserta a resposta.
• Monte primeiro um conjunto de referência: perguntas reais da operação, com o documento e o trecho que respondem cada uma.
• A divisão dos textos pesa mais do que a escolha do modelo de embedding. Cortar a exceção longe da regra gera respostas erradas com aparência de certas.
• Reranking é uma segunda triagem. Vale adicioná-lo quando o trecho certo aparece entre os candidatos, mas não no topo.
• Peça ao sistema que admita quando não encontrou nada. Testar a resposta «não sei» é tão importante quanto testar as respostas certas.

O que acontece em um pipeline de RAG, do documento à resposta?

RAG (geração aumentada por recuperação) significa que o modelo responde com base em trechos dos seus documentos, buscados no momento da pergunta, em vez de depender só do que aprendeu no treinamento. A AWS descreve a ideia e a Google Cloud mostra uma arquitetura de referência com as mesmas peças. Na prática, são seis etapas:

• Ingestão: extrair o texto dos arquivos e anexar metadados (fonte, versão, área, permissão).
• Divisão: cortar o texto em trechos que façam sentido sozinhos.
• Embeddings: transformar cada trecho em um vetor que representa seu significado.
• Busca: encontrar os trechos mais próximos da pergunta.
• Reranking: reordenar os candidatos com um critério mais fino.
• Geração: o modelo responde usando os trechos escolhidos e cita a fonte.

A ordem importa porque o erro se propaga. Um PDF extraído com a tabela embaralhada gera trechos ruins, que geram vetores ruins, que geram busca ruim, e no fim o modelo responde com confiança sobre algo errado. Quem só avalia a resposta final não sabe qual etapa falhou e acaba mexendo no prompt sem resultado.

O primeiro artefato, antes de qualquer código, é o conjunto de referência. Peça a quem atende clientes ou opera o processo que liste perguntas reais, escritas do jeito que as pessoas perguntam (inclusive com abreviação e erro de digitação, como no WhatsApp). Para cada pergunta, registre qual documento e qual trecho respondem. Esse conjunto será a régua de todas as etapas abaixo.

Etapa 1: seus documentos chegam limpos ao pipeline?

A perda de qualidade mais barata de evitar acontece na ingestão. Os problemas mais comuns:

• PDFs escaneados sem texto reconhecido, que viram páginas vazias.
• Tabelas que, na extração, viram uma sequência de células sem relação entre si.
• Cabeçalhos e rodapés repetidos em toda página, poluindo cada trecho.
• Várias versões do mesmo documento, onde a política antiga continua respondendo.
• Documentos que determinadas pessoas não deveriam ver, indexados para todo mundo.

O teste é simples: pegue alguns documentos representativos, abra o texto extraído (não o arquivo original) e leia como se fosse o modelo. Se você não consegue entender uma tabela ou uma lista nesse texto, o sistema também não vai entender.

Trate os metadados como parte do conteúdo. Guarde pelo menos a origem, a versão ou data de vigência e a permissão de acesso. Isso permite filtrar a busca (só documentos vigentes, só os que o usuário pode ver) e citar a fonte na resposta. Se os documentos contêm dados pessoais, defina antes o que entra no índice e quem responde por ele. O artigo sobre RIPD em projetos de IA ajuda a decidir quando essa análise é necessária.

Como dividir textos em trechos sem quebrar o sentido?

A divisão (chunking) é a etapa em que mais se perde qualidade sem ninguém perceber. Trechos grandes demais misturam assuntos e diluem o sinal na busca. Trechos pequenos demais perdem o contexto: uma frase como «nesse caso, o prazo é maior» não significa nada sem o que veio antes.

As abordagens mais usadas, da mais simples à mais cuidadosa:

• Tamanho fixo com sobreposição: corta por quantidade de texto e repete um pedaço entre trechos vizinhos. É rápida, mas ignora a estrutura.
• Por estrutura: respeita títulos, seções, itens numerados e cláusulas. Costuma ser o melhor ponto de partida para manuais, contratos e políticas.
• Por unidade de sentido: uma pergunta e sua resposta de FAQ, um produto e sua ficha, uma cláusula e suas exceções ficam juntos.

Duas práticas melhoram muito o resultado. A primeira é prefixar cada trecho com o título do documento e da seção, para que ele carregue seu contexto. A segunda é manter a regra e a exceção no mesmo trecho, ou em trechos vizinhos que a busca consiga recuperar juntos.

O teste desta etapa não envolve modelo nenhum. Para cada pergunta do conjunto de referência, localize manualmente o trecho que a responde e verifique três coisas: a resposta cabe inteira ali? O trecho se entende sozinho? A exceção importante está junto? Cada «não» é um problema de divisão a corrigir antes de gastar tempo com busca.

Embeddings: como escolher o modelo e testar a busca?

O embedding transforma texto em números de modo que trechos de significado parecido fiquem próximos. Para a maioria das empresas brasileiras, o critério principal é o desempenho em português com o seu vocabulário, não a fama do modelo. Dois cuidados práticos: use o mesmo modelo para indexar os documentos e para transformar as perguntas, e reindexe tudo se trocar de modelo.

Busca por significado tem um ponto fraco conhecido: códigos, siglas, números de pedido e nomes próprios. Uma pergunta sobre um código de produto específico pode trazer trechos parecidos em tema, mas do produto errado. Nesses casos, combine a busca vetorial com busca por palavras-chave (busca híbrida) e use filtros por metadados.

O teste desta etapa é de recuperação. Para cada pergunta do conjunto de referência, rode a busca e veja se o trecho correto aparece entre os primeiros resultados. Anote acerto ou erro, pergunta por pergunta. Depois:

• Reescreva cada pergunta de dois ou três jeitos (formal, informal, com erro de digitação) e repita.
• Inclua perguntas com códigos e siglas para ver se a busca híbrida é necessária.
• Olhe os erros um por um. Muitas vezes o problema está na divisão ou nos documentos duplicados, não no modelo de embedding.

Só troque de modelo depois de descartar essas causas. Trocar o modelo é a mudança mais cara e a que menos costuma resolver.

Reranking: quando vale adicionar essa etapa?

A busca vetorial é rápida e traz uma lista ampla de candidatos, mas ordena de forma aproximada. O reranking é uma segunda passada: um modelo lê a pergunta e cada candidato juntos e reordena por relevância. É mais preciso e mais lento, por isso se aplica só a um grupo pequeno de candidatos.

Um guia de decisão simples:

• Se o trecho certo quase sempre aparece nos primeiros resultados, o reranking traz pouco. Não adicione.
• Se o trecho certo aparece entre os candidatos, mas fica em posições baixas, o reranking tende a ajudar.
• Se o trecho certo nem aparece entre os candidatos, o problema está antes: divisão, embeddings ou documentos. Reranking não cria o que a busca não trouxe.
• Se o atendimento exige resposta rápida, meça a latência extra antes de decidir.

Para testar, use o mesmo conjunto de referência e compare a posição do trecho correto antes e depois do reranking. Se a posição melhora na maioria dos casos e a latência continua aceitável, a etapa se paga. Se não, remova e simplifique.

Defina também um limite de relevância. Quando nenhum candidato é bom o bastante, o sistema deve dizer que não encontrou, em vez de entregar o menos ruim ao modelo.

Como a resposta final deve usar o contexto recuperado?

Depois da busca, o desafio é entregar ao modelo pouco contexto e bom contexto. Mais trechos não significam resposta melhor; trechos irrelevantes competem pela atenção do modelo. A Anthropic discute isso em engenharia de contexto para agentes. Na prática, envie poucos trechos, com a fonte identificada, e instrua o modelo a responder só com base neles e a citar de onde veio cada afirmação.

Três testes para esta etapa:

• Pergunta sem resposta nos documentos: o sistema deve admitir que não sabe e, se for o caso, encaminhar para uma pessoa.
• Documentos em conflito, como duas versões de uma política: o sistema deve preferir a vigente ou sinalizar a dúvida.
• Documento com instrução embutida, como um texto que diga para ignorar as regras: o sistema não deve obedecer. Esse risco está descrito no OWASP Top 10 para aplicações com LLM e se trata com validação de saída e limites de ação, como no artigo sobre guardrails em agentes de IA.

Guarde os logs de cada resposta: pergunta, trechos recuperados, versão do documento e resposta dada. Sem isso, quando alguém reclamar de uma resposta errada, ninguém saberá em qual etapa ela falhou.

Plano passo a passo e como aplicamos o método

Um roteiro enxuto para o primeiro RAG:

• Escolha um único conjunto de documentos com dono definido e alguma estabilidade (um manual de políticas, por exemplo).
• Monte o conjunto de referência com perguntas reais e o trecho que responde cada uma.
• Revise o texto extraído e corrija os documentos problemáticos.
• Defina a divisão por estrutura, com título e seção em cada trecho, e valide manualmente.
• Escolha o modelo de embedding, indexe e meça a recuperação. Adicione busca híbrida se códigos e siglas falharem.
• Adicione reranking apenas se o diagnóstico mostrar trecho certo em posição baixa.
• Teste respostas, incluindo perguntas sem resposta e documentos conflitantes.
• Repita o conjunto de referência a cada mudança, como em um teste de regressão.

Cenário ilustrativo: uma distribuidora quer que o atendimento consulte a política de trocas e devoluções. No primeiro teste, a busca traz o trecho da regra geral, mas não a exceção para produtos em promoção, que estava em outra página do PDF. O erro não está no modelo nem no reranking: a divisão separou regra e exceção. Depois de reorganizar os trechos por seção e manter a exceção junto da regra, a mesma pergunta passa a ser respondida corretamente, e o conjunto de referência confirma que as outras perguntas não pioraram.

O método que usamos segue o mesmo raciocínio. Mapear: entender o processo atual, quais perguntas aparecem e onde a resposta hoje está. Limitar: escolher poucos documentos, definir o que o sistema pode responder e quando deve passar para uma pessoa. Pilotar: rodar um fluxo real com logs e uma métrica de sucesso combinada, como descrito em como medir um piloto de automação com IA. Transferir: entregar a operação documentada, com o conjunto de referência, e decidir com a equipe se amplia, ajusta ou para.

Perguntas frequentes

Preciso de um banco vetorial para começar um RAG? Não necessariamente. Para um conjunto pequeno de documentos, muitas vezes basta uma extensão vetorial do banco que você já usa ou um índice simples em memória. O que não pode faltar é o conjunto de referência para medir a busca, porque ele serve em qualquer tecnologia que você escolher depois.

RAG ou fine-tuning: qual escolher para responder com base nos meus documentos? Para conteúdo que muda e precisa de fonte citável, como políticas, manuais e catálogos, RAG costuma ser o caminho mais direto, porque basta atualizar o documento. Fine-tuning serve mais para ajustar estilo ou comportamento do que para memorizar fatos. Os dois podem coexistir, mas comece pelo RAG e meça.

Como saber se o RAG está bom o suficiente para usar com clientes? Defina antes do piloto o que significa suficiente: por exemplo, o trecho correto aparecer entre os primeiros resultados para as perguntas do conjunto de referência e o sistema recusar corretamente as perguntas sem resposta. Rode o piloto com revisão humana e logs e só amplie quando os erros restantes forem conhecidos e tratáveis.

Posso indexar documentos com dados pessoais? Depende da finalidade, da base legal e de quem pode acessar o quê. Evite indexar dados pessoais que o caso de uso não exige, aplique permissões na busca e registre quem consultou. Em caso de dúvida, consulte o jurídico e acompanhe as orientações da ANPD.

Fontes

• AWS: What is retrieval-augmented generation
• Google Cloud: retrieval-augmented generation architecture
• Anthropic: Effective context engineering for AI agents
• OWASP Top 10 for LLM Applications