RAG: como fazer um LLM responder com os seus dados, sem inventar

• O que é RAG e qual problema ele resolve?
• Como funciona o pipeline de RAG na prática?
• Por que chunking e embeddings decidem a qualidade?
• O que dá errado em RAG e como corrigir?
• Como avaliar um sistema de RAG?
• RAG, fine-tuning ou contexto longo: quando usar cada um?

Um modelo de linguagem não conhece os documentos da sua empresa e não tem como citar fonte para o que afirma. RAG resolve os dois problemas com uma ideia simples: buscar os trechos certos antes de perguntar, e pedir que a resposta se apoie neles.

O que é RAG e qual problema ele resolve?

RAG significa Retrieval-Augmented Generation — geração aumentada por recuperação. O nome descreve o mecanismo: antes de o modelo responder, um sistema de busca recupera da sua base os trechos mais relevantes para a pergunta e os injeta no prompt. O modelo passa a responder olhando para esse material.

A arquitetura foi formalizada em um artigo da Meta AI em 2020 e virou o padrão corporativo por resolver três limitações simultâneas dos modelos de linguagem:

1. Desconhecimento do que é seu. Nenhum modelo foi treinado com o manual interno, o contrato do cliente ou a base de chamados da sua empresa.
2. Corte de conhecimento. O treinamento tem uma data final. Tudo que aconteceu depois é invisível para o modelo.
3. Ausência de fonte. Um LLM puro afirma sem poder mostrar de onde tirou. Em contextos jurídicos, médicos ou financeiros, isso inviabiliza o uso.

A alternativa óbvia — colocar todos os documentos no prompt — esbarra em custo e em qualidade. Mesmo com janelas de contexto grandes, enviar milhares de páginas a cada pergunta é caro em tokens e degrada a precisão, porque a informação relevante se dilui no ruído.

Exemplo prático: perguntar a um modelo genérico "qual o prazo de garantia do contrato 4471?" produz uma resposta plausível e inventada. Com RAG, o sistema recupera a cláusula exata daquele contrato e a resposta vem com a citação — verificável em segundos.

Como funciona o pipeline de RAG na prática?

O sistema tem duas metades que rodam em momentos diferentes.

Indexação (uma vez, e a cada atualização):

1. Extração. Converter PDFs, planilhas, páginas e bancos em texto limpo. Etapa entediante e decisiva: tabela mal extraída vira resposta errada.
2. Chunking. Dividir o texto em pedaços. É a decisão mais impactante de todo o pipeline.
3. Embeddings. Transformar cada pedaço em um vetor por meio de um modelo de embedding.
4. Armazenamento. Guardar vetores e metadados — origem, data, permissão, seção — num índice pesquisável.

Consulta (a cada pergunta):

1. Busca. Gerar o embedding da pergunta e recuperar os trechos mais próximos.
2. Reordenação. Reavaliar os candidatos com um modelo mais preciso e ficar com os melhores.
3. Montagem do prompt. Inserir os trechos escolhidos junto com a instrução e a pergunta.
4. Geração. O modelo responde citando as fontes.

def responder(pergunta: str) -> dict:
    consulta = embed(pergunta)
    candidatos = indice.buscar(consulta, k=20, filtro={"permissao": usuario.grupos})
    trechos = reordenar(pergunta, candidatos)[:5]

    contexto = "\n\n".join(
        f"[{t.id}] (fonte: {t.origem}, {t.data})\n{t.texto}" for t in trechos
    )
    instrucao = (
        "Responda usando SOMENTE o contexto abaixo. Cite as fontes entre colchetes. "
        "Se o contexto não contiver a resposta, diga que não encontrou.\n\n"
        f"{contexto}\n\nPergunta: {pergunta}"
    )
    return {"resposta": llm(instrucao), "fontes": [t.origem for t in trechos]}

Repare no filtro por permissão dentro da busca. Ele é o detalhe que separa um protótipo de um sistema corporativo: o controle de acesso precisa acontecer na recuperação, não na geração. Confiar no modelo para "não contar" o que ele já recebeu no contexto é uma decisão de segurança ruim.

Exemplo prático: um assistente de RH indexou documentos de todos os departamentos e aplicava a regra de acesso apenas na instrução do prompt. Bastou uma pergunta indireta para que dados de outra área vazassem na resposta. A correção foi filtrar por grupo no índice, antes da busca.

Por que chunking e embeddings decidem a qualidade?

Quando um RAG responde mal, a causa quase nunca é o modelo de linguagem — é a busca ter trazido o trecho errado. E a busca depende de duas escolhas.

Chunking é como o texto é cortado. Pedaços grandes demais trazem ruído junto com o sinal; pequenos demais perdem contexto e devolvem frases soltas sem sentido. Três estratégias cobrem a maioria dos casos:

A regra prática: respeite a estrutura que o documento já tem. Um contrato tem cláusulas, uma norma tem artigos, um manual tem seções. Cortar a cada 500 tokens ignorando isso parte a informação no meio e obriga a busca a adivinhar.

Embeddings definem o que "parecido" significa. O conceito é o mesmo de qualquer medida de similaridade entre vetores — a intuição por trás da distância euclidiana aplicada a centenas de dimensões, com a diferença de que aqui se usa normalmente similaridade de cosseno. Três cuidados importam: escolher um modelo com bom desempenho em português, verificar o limite de tokens do modelo de embedding e — regra inegociável — usar o mesmo modelo para indexar e para consultar.

Uma quarta decisão evita o erro mais frustrante: adotar busca híbrida, combinando similaridade vetorial com busca por palavra-chave. Vetores captam sentido, mas erram em códigos, siglas e números — exatamente o que as pessoas mais procuram numa base corporativa.

Exemplo prático: uma base de chamados devolvia resultados ruins para consultas como "erro 4711". A busca vetorial entendia "erro" e ignorava o número. Com busca híbrida, o código passou a ter peso e a taxa de acerto subiu de imediato.

O que dá errado em RAG e como corrigir?

Cinco falhas concentram os problemas de sistemas em produção:

1. O trecho certo nem foi recuperado. Nada que você faça no prompt resolve. Investigue chunking, considere busca híbrida e recupere mais candidatos antes de reordenar.
2. O trecho certo foi recuperado e o modelo ignorou. Costuma acontecer quando o contexto está longo demais e a informação relevante ficou no meio. Reduza o número de trechos e ordene por relevância decrescente.
3. A resposta extrapola a fonte. Instrua explicitamente a responder só com o contexto, exija citação e permita "não encontrei". Modelos preferem responder a admitir ausência — é preciso autorizar o contrário.
4. A base envelhece em silêncio. Documento atualizado e índice desatualizado produzem respostas confiantes e erradas. Reindexação precisa ser parte do pipeline de dados, com data de atualização visível na resposta.
5. Perguntas que a arquitetura não atende. RAG recupera trechos; ele não soma, não conta e não compara toda a base. "Quantos contratos vencem este mês?" é consulta de banco, não de similaridade. A saída é dar ao agente uma ferramenta de consulta estruturada ao lado do RAG.

Exemplo prático: um assistente jurídico acertava perguntas conceituais e errava sistematicamente as de contagem. A correção não foi melhorar o RAG — foi adicionar uma ferramenta de consulta SQL e deixar o modelo escolher qual usar conforme a pergunta.

Como avaliar um sistema de RAG?

Sem medição, você tem uma demonstração convincente e um produto imprevisível. A avaliação precisa separar as duas metades:

Recuperação — monte um conjunto de 50 a 100 perguntas reais com o trecho correto anotado à mão. Meça em que proporção o trecho certo aparece entre os recuperados e em que posição ele costuma cair. Esse conjunto é o ativo mais valioso do projeto: ele permite trocar embedding, mudar chunking ou ativar reordenação e saber, com números, se melhorou.

Geração — sobre os trechos recuperados, avalie três dimensões: fidelidade (a resposta está contida no contexto?), relevância (responde ao que foi perguntado?) e cobertura (usou o que era necessário?). Ferramentas como Ragas automatizam parte disso usando um modelo como avaliador, o que é útil para acompanhar tendência — mas revisão humana periódica continua necessária.

Duas métricas operacionais completam o quadro: latência por etapa, para saber onde o tempo se perde, e custo por resposta, que costuma surpreender quando a reordenação usa um modelo caro.

Exemplo prático: um time trocou o modelo de embedding acreditando que melhoraria tudo e a satisfação caiu. O conjunto de avaliação mostrou o motivo: o modelo novo era melhor em inglês e pior em português, e a recuperação piorou em oito pontos. Sem o conjunto, a conclusão teria sido "o modelo de linguagem piorou".

RAG, fine-tuning ou contexto longo: quando usar cada um?

As três abordagens resolvem problemas diferentes e são frequentemente confundidas:

A escolha fica simples com uma pergunta: o que você quer ensinar ao modelo é um fato ou um comportamento? Fato — política de reembolso, cláusula, especificação — é RAG. Comportamento — sempre responder no formato de laudo, usar a terminologia da casa — é fine-tuning. E se o material cabe inteiro no contexto e muda a cada conversa, mandar tudo direto é mais simples que construir pipeline.

Vale notar que as três se combinam. Um sistema maduro pode ter um modelo ajustado para o formato da empresa, RAG para os fatos e uma janela de contexto grande para o documento que o usuário acabou de anexar. E, quando essa recuperação precisa ser oferecida a várias aplicações de IA diferentes, o Model Context Protocol virou a forma padrão de expor a base como ferramenta reutilizável.

Exemplo prático: uma seguradora tentou fine-tuning para ensinar as regras de cobertura ao modelo. Cada mudança de política exigia retreinar, e o modelo continuava sem citar a fonte. Migrar para RAG resolveu ambos os problemas — e o fine-tuning permaneceu, mas só para o formato padronizado dos pareceres.

Conclusão

RAG é a forma mais direta de fazer um modelo de linguagem trabalhar com o conhecimento que é seu, sem retreinar nada e com a resposta ancorada em uma fonte que dá para conferir. A arquitetura é simples de descrever e exigente de executar: quase todo o resultado depende de decisões pouco glamourosas — como o documento é extraído, como o texto é cortado, qual modelo de embedding entende português, se a busca combina semântica e palavra-chave, e se o controle de acesso acontece na recuperação. Quando um sistema desses decepciona, comece investigando a busca antes de trocar o modelo: na esmagadora maioria dos casos, o trecho certo nunca chegou ao prompt. E antes de qualquer otimização, monte o conjunto de perguntas de avaliação — é ele que transforma opinião sobre qualidade em número comparável, e é o que permite melhorar de verdade em vez de trocar peças no escuro.