Série: O Mito da Eficiência — Artigo 03

Bancos Vetoriais: A Nova Geometria do Dado

Entenda o "JPA da Inteligência Artificial" e por que ele vai devorar sua memória RAM.

Bancos Vetoriais: tabela SQL transformando-se em espaço de embeddings
Capa do artigo 3: transição visual de linhas e colunas SQL para pontos numéricos em espaço de alta dimensão — "cadeira" e "poltrona" próximas semanticamente, distantes no índice literal.

O segundo artigo deixou claro que a IA se perde na floresta do código legado. Agora precisamos entender onde essa "nova inteligência" guarda o que aprende — e como recuperamos isso sem SQL tradicional.

Não é quarta dimensão mística. É geometria de coordenadas. E cobra caro em RAM.

Adeus tabelas, olá coordenadas

No SQL do seu legado, a informação vive em gavetas: coluna A, linha B. Você busca "Cadeira" e encontra a string exata. Digite "Assento de madeira" e o banco tradicional não acha nada — a menos que alguém tenha previsto o sinônimo.

O banco vetorial (Pinecone, Milvus, Weaviate, Qdrant, Chroma) não guarda palavras; guarda distâncias. Via embedding, a IA transforma frase, parágrafo ou trecho de procedure em lista de números — um vetor. Exemplo simplificado: [0.12, -0.59, 0.88, ...].

Num mapa matemático de milhares de dimensões, "Cadeira" e "Poltrona" ficam geometricamente próximas. A busca não é por igualdade; é por proximidade. Isso se chama busca vetorial ou semantic search — mudança de paradigma do significado para além da palavra-chave.

Como "conversar" com o banco

Você não usa SELECT e JOIN da mesma forma. O fluxo é:

  1. Embedding da consulta: sua pergunta vira vetor — representação matemática da intenção.
  2. Busca por similaridade: o banco encontra pontos "próximos" no espaço, não strings iguais.
  3. Integração via framework: LangChain4j ou Spring AI encapsulam APIs específicas de cada vendor.

Para o desenvolvedor Java, isso soa familiar se pensarmos na fase pré-Hibernate: cada banco vetorial tinha API própria. Agora frameworks criam abstração — o tal "JPA vetorial".

O JPA dos vetores: abstração necessária

Spring AI expõe VectorStore — interface que permite trocar backend (Postgres com pgvector, Pinecone, Milvus) sem reescrever código de negócio, similar ao Hibernate/JPA. LangChain4j oferece camada equivalente para agentes e RAG.

Objetivo: salvar objeto Java no banco vetorial sem se preocupar se vai para servidor local ou nuvem da Big Tech. Sobrevivência do desenvolvedor em meio à proliferação de vendors.

Isso não elimina complexidade — desloca. Você ainda precisa escolher dimensão do embedding, modelo de embedding, estratégia de chunking de documentos e política de atualização quando o legado muda.

O custo invisível: RAM

Bancos relacionais são eficientes em disco. Banco vetorial, para ser rápido, mantém índices HNSW carregados na RAM.

Cálculo da dor: 1 milhão de documentos, vetor de 1536 dimensões (comum em modelos OpenAI-compatíveis) — você guarda gigabytes de decimais que precisam ser comparados em milissegundos. Seu legado roda feliz com 8 GB; um vetorial robusto "brinca" a partir de 32 GB ou 64 GB só para índices.

Para pequena empresa (10 mil documentos), um servidor comum de 16 GB pode bastar. Escala para bilhões de registros cai no monopólio das Big Techs — confirmação do artigo 1.

Quem está na vanguarda

Databricks e Snowflake integram vetores em data warehouses para evitar dois bancos separados. PostgreSQL com pgvector é aposta mais realista para o chão de fábrica: adiciona coluna vetorial na tabela de sempre — tentativa de salvar legado unindo SQL e semântica.

Pinecone: gerenciado, escala fácil, custo alto. Weaviate: open source, busca híbrida (vetorial + keyword). Qdrant: custo-benefício em 2026. Chroma: protótipos locais. Escolha depende de escala, orçamento e necessidade de soberania.

Imprecisão por design

Fato real: busca vetorial é imprecisa por natureza — proximidade, não exatidão. Você nunca usaria vetorial para fechar caixa do PDV (1+1 = 2). Usa para o gestor perguntar: "Quais produtos vendem mais quando chove?" — relação semântica entre clima e estoque que SQL antigo levaria meses de query manual.

RAG (Retrieval-Augmented Generation) alimenta LLM com trechos recuperados do vetorial antes de responder. Qualidade depende de limpeza e enriquecimento dos dados legados — não basta "jogar" PDFs no bucket.

Tipos de memória no sistema agêntico

TipoPara quêFormato real
Longo prazoManuais, regras, documentaçãoBanco vetorial (embeddings)
Curto prazoHistórico da conversa atualRedis, NoSQL (JSON rápido)
AuditoriaO que a IA decidiu e por quêSQL tradicional (imutável)

Não será enciclopédia de TXT ou MD. Será ecossistema híbrido — exatamente o oposto da narrativa "substitua tudo por IA".

Conclusão

O banco vetorial é cérebro de longo prazo da IA, mas cobra caro pelo aluguel da memória. Não substitui seu banco de dados; vive ao lado dele — bibliotecário dos conceitos, enquanto SQL continua contador dos centavos.

Próximo artigo: se otimizarmos software para economizar RAM, vamos mesmo economizar — ou o mercado engole a eficiência e pede mais?


Nota: Terceiro artigo da série O Mito da Eficiência; continuidade com o artigo 4 em 12/01/2027.