Capítulo 1 — A Evolução da Arquitetura RAG

Primeiro post do passeio capítulo a capítulo pelo LLM Primer III: Aprimorando a IA Empresarial com RAG. Em que os dois limites estruturais de um modelo base — conhecimento congelado e ausência de proveniência — acabam tendo uma única resposta arquitetural, e essa resposta ganhou quatro faces em três anos.

Por que este capítulo existe

Um transformer treinado sobre um corpus fixo tem dois limites que nenhum treinamento adicional apaga por completo. Seu conhecimento termina no dia em que o corpus terminou. E ele não consegue dizer de qual documento uma frase veio, porque a frase é uma média estatística sobre muitos, não uma citação de algum. A primeira falha produz respostas confiantemente erradas sobre qualquer coisa recente. A segunda produz citações confiantemente erradas. Juntas elas produzem a patologia empresarial agora familiar: uma resposta que soa como autoridade e linka para uma cláusula que não existe.

RAG é a resposta arquitetural para as duas ao mesmo tempo. Você para de pedir que o modelo saiba tudo de antemão e começa a entregar a ele o material relevante no momento da inferência, recuperado de um corpus que você controla. O corpus atualiza sem retreino. As passagens recuperadas viram citações porque você as buscou de propósito. O trabalho do modelo encolhe de recall para síntese. O resto do capítulo é a história de como esse movimento simples cresceu, em três anos, para quatro arquiteturas progressivamente mais capazes.

1.1 RAG Naive: embed, recupera, empilha

A forma mais simples é a que todo tutorial público ainda descreve. Offline: separe o corpus em chunks, embed cada um, escreva os vetores no índice. Online: embed a query, busque os top-k chunks mais próximos, concatene num prompt, mande pro modelo, devolva a resposta com os chunks listados como citação. Duas chamadas de função e uma busca vetorial.

A demo funciona. O produto raramente. Similaridade por vizinho mais próximo é um proxy de relevância, não uma medição dela, e modelos de embedding treinados em texto web genérico rotineiramente confundem colheita de pomar de maçã com resultados trimestrais da Apple. O chunker não tem sinal de onde frases terminam ou tabelas começam. Uma única passada de recuperação não consegue atender a uma pergunta cuja resposta está espalhada por três documentos. E quando a recuperação falha, o modelo sintetiza a partir do que voltou — as citações são reais, mas não sustentam nada da resposta.

1.2 RAG Avançado: heurísticas em volta do mesmo pipeline

A segunda postura mantém a espinha embed-recupera-gera e adiciona processamento antes e depois da chamada de recuperação. Melhorias pré-recuperação miram a query: rewriting, expansão, decomposição, HyDE (rascunhar uma resposta hipotética e embedar ela como query). Melhorias pós-recuperação miram os candidatos: um reranker cross-encoder que pontua query e passagem juntas em vez de embedá-las apartadas, deduplicação, filtro por metadados, compressão de contexto.

Os ganhos não são pequenos. Um reranker cross-encoder em cima de um retriever vetorial tipicamente move a relevância top-5 da faixa 50–70% para 75–90%. Rewriting de query soma mais cinco a dez pontos onde o fraseado original era ambíguo. A maioria dos sistemas em produção rotulados hoje simplesmente como "RAG" está rodando esta arquitetura, e para uma classe ampla de problemas empresariais — Q&A sobre documentação interna, defletor de suporte, busca em base de conhecimento — é o nível certo de investimento. O que não dá é flexibilidade. Toda query continua passando pelo mesmo pipeline.

1.3 RAG Modular: componentes componíveis, roteamento explícito

Em 2024 pesquisa e tooling convergiram para o RAG Modular. As mesmas técnicas continuam presentes, mas expostas como componentes discretos e trocáveis, e o pipeline é montado por requisição. Um router decide quais retrievers chamar — talvez um índice vetorial denso, um BM25, um SQL, uma API externa — e os resultados são fundidos, frequentemente via reciprocal rank fusion. O reranker é selecionado pelo tipo de query. O gerador é selecionado pelo tier de qualidade necessário. A arquitetura virou um grafo de componentes em vez de uma fila de estágios.

Duas consequências práticas. Primeiro, o sistema é testável de um modo que as posturas anteriores não eram — cada componente pode ser avaliado e substituído independentemente. Segundo, o sistema é ajustável por classe de query: uma lookup factual passa por um retriever rápido e um gerador pequeno, uma síntese multi-documento passa por vários retrievers e um grande, ambos servidos da mesma biblioteca de componentes. O preço é operacional. Quando uma resposta sai errada, a pergunta onde isso deu errado? agora tem muitas respostas possíveis, e o time precisa de instrumentação que consiga localizar a falha num componente específico. Invista na observabilidade antes da arquitetura modular, não depois.

1.4 RAG Agêntico: o LLM toca o pipeline

A quarta postura inverte uma suposição que as três anteriores compartilhavam em silêncio — a de que o LLM é o último passo. Em RAG Agêntico, o LLM toca o pipeline. Dado um catálogo de ferramentas (busca vetorial, SQL, fetch web, reranker, calculadora), o modelo pensa, escolhe uma ferramenta, observa o resultado, pensa de novo, e termina quando tem uma resposta ou bate num limite de passos. A arquitetura deixou de ser pipeline e virou um pequeno programa que o modelo escreve do zero para cada query.

Isso compra planejamento multi-step, seleção dinâmica de ferramenta, e padrões de coordenação multi-agente como planejador/retriever/crítico/escritor. Custa latência, gasto de token e reprodutibilidade — uma única query agora é uma árvore de decisões em vez de uma sequência fixa, e queries patológicas podem queimar muitos turnos se debatendo antes de produzir resposta. Sistemas agênticos em produção precisam de controles de orçamento, limites de passo e políticas de timeout que pipelines fixos nunca precisaram pensar. O caso de uso certo são perguntas cuja profundidade é variável e imprevisível: síntese de pesquisa, lookup jurídico sobre jurisprudência, revisão de literatura. O caso de uso errado é um bot de suporte estático, onde o loop agêntico adiciona variância que o workload não pedia.

1.5 RAG versus fine-tuning

A pergunta que todo time eventualmente faz. O enquadramento honesto é que eles resolvem problemas diferentes. RAG endereça problemas de conhecimento — o modelo não sabe X, e X muda, e o usuário precisa de uma citação. Fine-tuning endereça problemas de comportamento — o modelo sabe a resposta mas a apresenta no formato errado, recusa o template da empresa, ou enrola onde devia ser conciso. RAG é barato de montar e caro por query. Fine-tuning é caro uma vez e barato por query. RAG itera em minutos (mude um documento); fine-tuning itera em dias. Heurística útil: se a falha é o modelo não sabe, vá para RAG. Se a falha é o modelo sabe mas faz errado, vá para fine-tuning. Muitos sistemas maduros eventualmente fazem os dois, mas comece por RAG — a maioria das falhas empresariais são falhas de conhecimento, não de comportamento.

O que o Capítulo 1 prepara

Toda arquitetura RAG — qualquer das quatro que você escolha — é refém de quão bem ela consegue ler seus documentos-fonte. Um pipeline Modular de ponta com orquestrador agêntico ainda está trabalhando sobre chunks que saíram de um passo de parsing em algum lugar a montante. Se aquele passo perdeu a estrutura de tabela, embaralhou a ordem de leitura em múltiplas colunas, ou substituiu legendas de figura por OCR distorcido, todo componente a jusante está raciocinando sobre entrada corrompida. A arquitetura define o teto do sistema. O parser define o chão. Na maioria dos sistemas em produção, o chão importa mais, porque a maioria deles está longe do teto.

Próximo — Capítulo 2: Parsing Inteligente de Documentos. Por que um utilitário ingênuo de PDF-para-texto destrói qualidade de recuperação em silêncio, o que o parsing consciente de layout de fato preserva, e a alternativa multimodal que recupera direto sobre imagens de página.