Capítulo 10 · RAG · 9 min
Ler seus documentos
Como um LLM acessa milhares de páginas sem memorizá-las. Embeddings, busca semântica, contexto injetado.
Buscar antes de responder
Um LLM sabe o que foi comprimido em seus pesos durante o treinamento. Mas sua documentacao interna, suas notas, suas faturas ou uma pagina publicada ontem nao estao necessariamente ali.
O RAG adiciona uma etapa antes da geracao: buscar documentos relevantes, coloca-los no contexto e deixar o modelo responder usando essa informacao.
Escolha uma pergunta: ela é embedded, comparada aos chunks do corpus, e os mais relevantes são injetados no prompt antes da geração. É esse desvio que permite a um LLM responder sobre documentos que nunca viu durante o treinamento.
De documentos a vetores
Primeiro cortamos documentos em chunks. Cada chunk vira um embedding e e salvo em uma base vetorial.
Quando chega uma pergunta, ela tambem vira vetor. Depois buscamos os chunks mais proximos por similaridade semantica. Nao buscamos apenas palavras iguais: buscamos significado proximo.
O prompt aumentado
Os chunks recuperados sao inseridos no prompt:
Pergunta do usuario + contexto recuperado + instrucoes de resposta
O modelo nao "aprende" esses documentos permanentemente. Ele os le naquele momento, dentro da janela de contexto.
Por que e util
RAG resolve tres problemas praticos:
- atualidade — voce pode responder com informacao mais recente que o treinamento
- especializacao — pode usar documentos privados ou tecnicos
- rastreabilidade — pode mostrar de onde veio uma resposta
Mas nao e magia. Se a busca recupera chunks ruins, o modelo raciocina com dados ruins.
Qual modelo de embedding usar?
Nem toda pergunta leva aos chunks certos com o mesmo embedding. Um modelo treinado em portugues generalista vai recuperar mal codigo Python; um modelo treinado em codigo vai recuperar mal trocas medicas.
As escolhas que aparecem na pratica:
text-embedding-3-small/-large(OpenAI) — qualidade solida, generalista, multilingue. O default quando voce comeca.bge-large/bge-m3(BAAI) — open-source, excelente em multilingue, no topo dos benchmarks MTEB em 2024.all-MiniLM-L6-v2(Sentence-Transformers) — pequeno, rapido, possivel de implantar localmente. Boa relacao qualidade/custo para casos simples.- Modelos especializados por dominio (codigo, biomedico, juridico) — sempre melhores no nicho, mais fracos em outros lugares.
Uma regra pratica: testar dois ou tres modelos com seus dados e suas perguntas. O ranking MTEB diz pouco sobre seu caso de uso especifico.
O reranker: uma segunda passagem
A busca vetorial tem um defeito: e rapida mas grosseira. Um embedding de algumas centenas de dimensoes e uma media difusa de um texto. Muitos chunks "mais ou menos relevantes" flutuam no topo, e os realmente bons as vezes ficam afogados.
Por isso uma segunda etapa virou padrao em sistemas RAG serios: o reranker.
A ideia em duas etapas:
- Primeira passagem (busca vetorial) — recupera os 50 ou 100 chunks mais proximos. Rapido.
- Segunda passagem (reranking) — um modelo pequeno (frequentemente um cross-encoder) avalia cada par
(pergunta, chunk)junto, da uma pontuacao precisa, e mantem o top 5–10. Lento por chunk, mas so e executado nos 50 candidatos da primeira passagem.
O reranker ve a pergunta e o chunk ao mesmo tempo, o que o embedding nao faz. Ele capta sutilezas semanticas que a busca vetorial perde. Cohere, Jina AI, BAAI oferecem rerankers prontos para usar.
Sem reranker, seu RAG estagna. Com ele, a qualidade salta um nivel sem mudar o resto do pipeline.
Fragilidades
Um pipeline RAG pode falhar por varios motivos:
- chunks grandes ou pequenos demais
- embeddings pouco adaptados ao dominio
- perguntas que precisam combinar muitas fontes
- contexto recuperado contraditorio
- modelo que ignora parte do contexto
A qualidade depende tanto do retrieval quanto do modelo gerativo.
O proximo passo
Com RAG, o modelo pode consultar documentos. Com ferramentas, ele pode fazer ainda mais: calcular, chamar APIs, navegar, escrever arquivos. Isso nos leva aos agentes.
Atualizado em