| Dimensão |
RAG Semântico |
RAG Quantitativo |
|---|---|---|
| Foco Principal | Significado, conceito e contexto discursivo | Dados numéricos, métricas e valores exatos |
| Método de Busca | Embeddings / Vetores (Similaridade) |
SQL / Filtros Agregados (Match exato) |
| Fonte de Dados | Texto não estruturado (PDFs, FAQs, manuais, docs) | Dados estruturados (Tabelas SQL, CSV, DW, Data Lakes) |
| Exemplo de Pergunta | "Por que os clientes costumam cancelar o serviço?" | "Qual foi o faturamento total do mês de maio?" |
| Tipo de Resposta | Explicativa, sintetizada e rica em contexto | Objetiva, exata, tabulada ou estatística |
RAG virou uma espécie de guarda-chuva. Hoje qualquer sistema que consulta alguma fonte antes de responder acaba recebendo esse nome, mesmo quando a forma de recuperar a informação é completamente diferente.
Isso acaba escondendo uma distinção importante. Nem toda informação é armazenada da mesma forma, então não existe um único mecanismo de recuperação que funcione bem para tudo.
Se a base é composta por documentos, manuais, contratos, artigos, documentação técnica ou qualquer outro conteúdo escrito em linguagem natural, o objetivo passa a ser localizar trechos que tenham relação com a pergunta feita pelo usuário. As palavras podem ser diferentes. O significado não.
Imagine alguém perguntando:
"Por que os clientes cancelam o serviço?"Em algum documento pode existir apenas a frase:
"Grande parte dos usuários desiste durante o processo de cadastro."As duas frases não compartilham praticamente nenhuma palavra importante. Mesmo assim, estão falando sobre o mesmo assunto. Esse tipo de associação dificilmente seria encontrado usando uma busca tradicional por palavras-chave.
É justamente aí que entra o RAG semântico.
Nesse modelo, os documentos são convertidos em embeddings, representações numéricas capazes de preservar relações de significado. Quando uma pergunta chega, ela também é transformada em um vetor. O sistema procura os documentos semanticamente mais próximos e envia esse contexto para o modelo de linguagem produzir a resposta.
Esse tipo de abordagem funciona muito bem quando existe muito texto não estruturado:
- Documentação interna.
- Políticas da empresa.
- Artigos técnicos.
- Contratos.
- FAQs.
- Bases de conhecimento.
Tudo isso costuma produzir resultados excelentes com recuperação semântica.
O cenário oposto: dados exatos e numéricos
Agora imagine outra situação.
"Qual foi o faturamento de maio?"Ou então:
"Quantos pedidos foram entregues ontem?"Não existe contexto para interpretar.
Também não existe significado escondido entre documentos.
Existe um número armazenado em algum lugar.
Nesses casos, usar embeddings seria acrescentar complexidade onde ela não traz benefício algum. A resposta já está organizada em tabelas, índices e relacionamentos. Basta consultá-la.
Esse cenário costuma ser chamado de RAG quantitativo.
A recuperação acontece sobre dados estruturados. Em vez de calcular similaridade entre vetores, o sistema executa consultas, aplica filtros, faz agregações e retorna exatamente os registros necessários. O modelo de linguagem entra depois, organizando ou explicando o resultado, mas quem encontrou a informação foi o banco de dados.
Duas ferramentas para problemas diferentes
Essa diferença parece pequena quando vista em um diagrama. Na prática, muda completamente a arquitetura.
- Um banco vetorial não substitui um banco relacional.
- Um banco relacional também não substitui uma busca semântica.
Cada um resolve um problema diferente.
O erro mais comum é assumir que embeddings representam uma evolução natural de qualquer mecanismo de busca. Não representam.
Se alguém perguntar o saldo de uma conta bancária, o sistema precisa devolver um valor exato. Não existe margem para "documentos parecidos".
Da mesma forma, procurar uma política interna sobre trabalho remoto usando apenas SQL dificilmente produziria um bom resultado. O banco consegue localizar registros. Entender assuntos é outra história.
A força dos sistemas híbridos
Boa parte das aplicações modernas acaba combinando os dois modelos.
Uma pergunta como:
"Por que as vendas caíram em maio?"pode exigir primeiro uma consulta ao banco para verificar se realmente houve queda. Depois disso, entram atas de reunião, chamados de suporte, pesquisas de satisfação, e-mails ou feedbacks de clientes para explicar o motivo.
Os números vêm do banco relacional.
O contexto vem da recuperação semântica.
Quando essas duas abordagens trabalham juntas, o modelo deixa de responder apenas com precisão ou apenas com contexto. Ele consegue entregar os dois ao mesmo tempo.
No fim, a escolha quase nunca depende do framework, do banco vetorial ou do modelo de linguagem utilizado.
Ela depende da natureza da informação que será recuperada.