RAG, embeddings e vector database: o que cada um faz e quando usar.

RAG, embeddings e vector database são três peças do mesmo problema: fazer um LLM responder com base no conhecimento do seu negócio, não apenas no que ele aprendeu na internet até o corte de treinamento. RAG (Retrieval-Augmented Generation) é a arquitetura. Embeddings são o jeito de transformar texto em algo que computador compara. Vector database é onde esses embeddings ficam guardados para busca rápida. Sem essa combinação, qualquer LLM é um assistente brilhante que nunca leu o manual da sua empresa.

Este texto trata cada peça com profundidade prática, mostra como funciona RAG passo a passo, quando é a escolha certa e o que rodamos em produção quando o projeto precisa de IA com base de dados própria.

O problema que o RAG resolve

Um LLM puro tem três limitações para uso corporativo. Primeiro, conhecimento congelado no corte de treinamento — não sabe do seu produto, do seu cliente, do seu processo. Segundo, contexto finito — mesmo modelos com janela de 200k ou 1M de tokens não cabem o conjunto inteiro de documentos da empresa, e enviar tudo a cada chamada é caro e lento. Terceiro, privacidade — você não quer que dado interno seja enviado em prompt sem controle.

Os três caminhos tradicionais para resolver isso:

• Mandar tudo no prompt. Funciona se a base é pequena e estável. Inviável para milhares de documentos.
• Fine-tuning do modelo. Funciona para ensinar estilo ou tarefa, mas é caro pra fato atualizável e perde flexibilidade.
• RAG. Buscar dinamicamente os trechos relevantes da base e injetar no prompt no momento da consulta. Atualizar a base é trivial — basta reindexar.

RAG ganha quando o conhecimento muda com frequência, é volumoso ou precisa ser auditável (rastrear de onde veio cada resposta). É o desenho mais usado em IA com base de dados própria hoje.

O que são embeddings, em uma frase

Embedding é um vetor numérico — uma lista de números, geralmente de 1.024 a 3.072 valores — que representa o significado semântico de um texto.

Analogia direta: imagine um mapa com 1.024 dimensões. Cada documento, cada parágrafo, cada pergunta vira um ponto nesse mapa. Textos com significado parecido ficam próximos no mapa, mesmo sem palavras em comum. "Como cancelo meu pedido?" e "Quero estornar a compra que fiz" têm coordenadas próximas porque significam a mesma intenção. "Como cancelo meu pedido?" e "Política de privacidade do site" ficam longe.

Quem gera o vetor é um modelo de embedding. Em produção, modelos comuns são voyage-3 da Voyage AI, text-embedding-3-large da OpenAI e Cohere Embed v3. O custo de embedding ficou barato: gira em torno de US$ 0,02 a US$ 0,12 por milhão de tokens processados, dependendo do modelo.

O que é um vector database e por que ele existe

Banco relacional comum não foi feito pra buscar por proximidade entre vetores. Vector database é o sistema otimizado pra isso: dado um vetor de consulta, devolve os N vetores mais próximos em milissegundos, mesmo entre milhões de documentos. Indexação típica usa HNSW (Hierarchical Navigable Small World) ou IVFFlat.

Opções de mercado:

• Postgres com pgvector. Extensão que adiciona tipo vector ao Postgres tradicional. Vantagem: coexiste com o banco operacional, transações ACID, fácil auditar. É a base do Supabase.
• Pinecone. Vector store gerenciado, foco em escala. Caro, mas conveniente.
• Weaviate, Qdrant, Chroma. Vector stores especializados, open source ou gerenciados.
• Elasticsearch / OpenSearch. Busca híbrida (vetorial + textual) madura.

Para a maioria dos projetos, Postgres com pgvector resolve até centenas de milhões de vetores. Trocar por solução especializada só compensa quando latência ou volume cobram preço.

Como RAG, embeddings e vector store trabalham juntos

O fluxo tem duas fases. Primeiro, a preparação offline. Depois, a execução em runtime quando o usuário pergunta.

Refinamentos comuns: hybrid search combina busca vetorial com busca textual tradicional (BM25) — captura tanto sinônimos quanto match exato de termos técnicos. Reranking melhora precisão sem aumentar muito o custo. Filtros por metadados garantem que o usuário só veja chunks aos quais tem acesso.

Quando RAG é a escolha certa (e quando não é)

RAG é a escolha certa quando:

• A base de conhecimento muda com frequência — política, manual, catálogo, ticket de suporte.
• O volume não cabe no contexto do modelo, mesmo com janelas grandes.
• Privacidade exige controle de dados — o que entra no prompt é decidido pelo seu sistema, não enviado integralmente.
• Auditoria importa — resposta precisa citar fonte para conformidade.
• Diferentes usuários têm permissões distintas — filtros por metadados resolvem.

RAG não é a escolha quando:

• Conhecimento é estável e pequeno — usa prompt caching, mais barato e mais simples.
• Resposta exige raciocínio multi-step e não lookup de fato — usa agente com ferramentas.
• Tarefa é geração criativa sem fonte — não tem o que recuperar.
• Modelo precisa adotar estilo, formato ou jargão específico — fine-tune resolve melhor.

Em sistemas profissionais, RAG geralmente coexiste com prompt caching, tool use e (raramente) fine-tuning. Não é escolha única.

O que a Skala usa em produção

Stack típica de RAG nos projetos da Skala, com o porquê de cada escolha:

Para entender como RAG entra em soluções operacionais com workflow completo, veja como agentes de IA são aplicados em operações reais — RAG costuma ser uma das camadas dentro de um agente que orquestra múltiplos passos.

Perguntas frequentes