RAG 101 (1): Naive RAG, ou a arquitetura do PDF picado, top-k e fé

No post anterior, vimos que o fine-tuning ajuda o modelo a aprender comportamentos, formatos e tarefas, enquanto o RAG permite consultar informações externas no momento da resposta. vamos abrir a caixa-preta.

Quando alguém diz que “conectou uma LLM aos documentos da empresa”, muitas vezes está falando disso:

documentos → chunks → embeddings → busca vetorial → top-k → prompt → resposta

Esse é o Naive RAG.

Ele foi o ponto de partida de boa parte das aplicações de IA generativa que usam bases documentais.

E funciona, só não tão magicamente quanto alguns diagramas fazem parecer.

Primeiro, o documento é cortado Imagine um contrato com cinquenta páginas,como ele inteiro pode ser grande para uma consulta, o sistema divide o em blocos menores, chamados de chunks.

Esses blocos podem ter 300, 500 ou 1.000 tokens, com alguma sobreposição entre eles.

É como pegar um livro e separá-lo em cartões.

O problema aparece quando o corte respeita a quantidade de tokens, mas ignora a estrutura do conteúdo.

Uma regra pode ficar em um cartão, a exceção pode cair no cartão seguinte.

Uma tabela se separa do título, a conclusão se distancia das evidências que a sustentavam.

O documento continua armazenado, mas a relação lógica entre suas partes talvez não continue.

Depois, os chunks viram vetores Cada fragmento é processado por um modelo de embeddings.

Esse modelo transforma o texto em uma sequência de números que representa características semânticas do conteúdo.

Textos com significados semelhantes tendem a ocupar regiões próximas nesse espaço vetorial, quando uma pessoa faz uma pergunta, ela também é convertida em vetor.

O sistema compara o vetor da pergunta com os vetores dos documentos e procura os fragmentos mais próximos.

Em geral, essa comparação usa alguma métrica, como similaridade de cosseno.Só que proximidade semântica não garante completude factual. exemplo: Posso cancelar o serviço sem pagar multa?

O sistema encontra um fragmento dizendo "O cliente poderá cancelar o serviço sem cobrança adicional." Só que o parágrafo seguinte, armazenado em outro chunk, diz: "A condição anterior aplica-se exclusivamente aos cancelamentos realizados nos primeiros sete dias após a contratação."

Se apenas o primeiro fragmento chegar à LLM, a resposta pode parecer clara, segura e fundamentada, só que também estará incompleta. entendem como o modelo não inventou necessariamente a informação?

Ele respondeu com o pedaço que recebeu.

Ai entra o top-k O sistema normalmente não recupera apenas um fragmento, Ele seleciona os k resultados mais próximos, Top-3 significa os três fragmentos mais semelhantes, Top-5, os cinco e por ai vai Só que recuperar mais documentos pode trazer mais ruído.

Entre os cinco resultados podem aparecer:

1. a política atual
2. uma versão antiga da política
3. uma notícia interna sobre o tema
4. um documento de outro país
5. um texto semanticamente parecido, mas relacionado a outro produto

Agora a LLM precisa descobrir, sozinha, quais fontes são atuais, relevantes e compatíveis entre si. é tipo receber os cacos e tenta reconstruir o vaso.

Então o Naive RAG é ruim? não, de forma alguma, Ele continua sendo útil.

Para bases pequenas, perguntas simples e documentos relativamente homogêneos, pode entregar resultados bastante bons.

Também é excelente para prototipar uma ideia, testar o corpus e entender os primeiros padrões de consulta.

A dificuldade aparece quando um protótipo simples é tratado como arquitetura pronta para qualquer cenário corporativo. isto é, documentos reais possuem versões, hierarquias e exceções. e por ai vai.

A busca vetorial encontra semelhança, mas todo o restante ainda precisa ser projetado com cuidado.

Onde costumam surgir os erros?

Quando uma resposta apresenta problemas, é comum trocar o prompt ou culpar a LLM, mas a falha pode estar em vários pontos anteriores: - O documento foi mal extraído?

• O chunking destruiu uma seção importante?

• O modelo de embeddings representa bem aquele domínio?

• O top-k trouxe muito ruído? e por ai vai.

A resposta final só consegue trabalhar com o contexto que atravessou todo esse caminho e por isso, avaliar somente o texto gerado é olhar para a última etapa de um problema que pode ter começado na ingestão.

E o que aprendemos com o (Naive) RAG?

Ele apresentou uma ideia poderosa: permitir que uma LLM consulte conhecimento externo sem precisar incorporar todos os fatos aos seus pesos, mas também revelou que recuperar informação envolve muito mais do que calcular quais vetores estão próximos.

A qualidade depende da forma como os documentos são preparados, divididos, indexados, recuperados e entregues ao modelo, isto é engenharia de dados! sempre falo isso.

Conectar uma LLM a um banco vetorial cabe numa tarde.

Entender por que ela recebeu exatamente aqueles cinco pedaços já exige engenharia.

No próximo post da série: vamos falar de Advanced RAG, quando começamos a reescrever consultas, combinar buscas, filtrar ruído e usar rerankers antes de confiar no primeiro top-k que apareceu.

vou começar a postar também recomendações do dia de livros técnicos: segue minha primeira recomendação: link.amazon/B00If…

---