IA
Banco vetorial: por que a IA precisa dele pra ‘entender’ seus dados
O que é um banco vetorial, por que SQL clássico não resolve busca semântica, e como embeddings + similaridade entram no fluxo de RAG — o jeito mais comum de modelos de IA analisarem documentos, tickets e bases internas.
Você pede pro modelo: “qual o SLA do contrato da empresa X?”
O GPT (ou Claude, ou o modelo que for) não abre seu Postgres e faz SELECT * FROM contratos WHERE cliente = 'X'. Ele também não “lê a pasta inteira” a cada pergunta. O que a maioria das aplicações sérias faz é outra coisa: buscar trechos parecidos com a pergunta e colar esses trechos no contexto do modelo.
É aí que entra o banco vetorial.
O problema que o SQL não resolve bem
Bancos relacionais são ótimos pra:
- igualdade (
id = 42) - filtros (
status = 'ativo') - joins, agregações, transações
Eles são ruins pra pergunta do tipo:
“achados sobre atraso de pagamento em clientes do interior”
Porque “atraso”, “inadimplência”, “pagamento em aberto” e “boleto vencido” não são a mesma string — mas são a mesma ideia. LIKE '%atraso%' não cobre isso. Full-text ajuda um pouco, mas ainda é mundo de palavras, não de significado.
Modelos de IA trabalham melhor com significado. Pra isso, texto vira número.
Embedding: texto virando lista de números
Um embedding é um vetor — uma lista de floats — que representa o “lugar” daquele texto num espaço semântico. Frases parecidas ficam perto umas das outras; frases de assuntos diferentes ficam longe.
Exemplo mental (2D de mentira):
- “como resetar a senha” → perto de “esqueci meu login”
- “política de reembolso” → longe dos dois
Na prática o vetor tem centenas ou milhares de dimensões. Você não precisa visualizar. Precisa só saber: distância ≈ similaridade de significado.
Quem gera o embedding é um modelo de embedding (OpenAI, Cohere, sentence-transformers, etc.). O banco vetorial guarda esses vetores e responde: “quais dos meus documentos estão mais perto deste vetor de consulta?”
O que o banco vetorial faz de verdade
Não é mágica. É índice + busca por similaridade em escala.
Fluxo típico de ingestão:
- Quebrar documento em chunks (pedaços)
- Gerar embedding de cada chunk
- Salvar:
{ id, texto, embedding, metadata }
Fluxo típico de pergunta (RAG — Retrieval Augmented Generation):
- Gerar embedding da pergunta
- Buscar os K chunks mais similares
- Montar um prompt: pergunta + trechos encontrados
- O LLM responde com base nisso (e, se bem feito, cita a fonte)
O modelo “analisa” seus dados porque você recuperou o que importa e colocou na janela de contexto. Sem recuperação boa, ele inventa ou fala genérico — o famoso hallucination com cara de confiança.
Por que não guardar o vetor numa tabela qualquer?
Dá. Muita gente começa com pgvector no Postgres e vive bem até certo volume.
A diferença do “banco vetorial” (Pinecone, Qdrant, Weaviate, Milvus, Chroma, etc.) — ou de um índice vetorial dedicado — é otimizar:
| Necessidade | Por que importa |
|---|---|
| Busca aproximada (ANN) | Comparar com milhões de vetores um a um é inviável |
| Filtros + similaridade | “parecido e tenant_id = X e ano >= 2024” |
| Latência baixa | Chat não aguenta 3s só pra retrieval |
| Escala / sharding | Base de conhecimento cresce rápido |
| Metadados | Filtrar por produto, idioma, versão do doc |
Em resumo: o vetor sem índice bom vira O(n) caro. O banco (ou extensão) existe pra tornar “ache os 8 mais parecidos” barato o bastante pra produção.
Onde isso aparece no produto real
- Chat com base de conhecimento interna (docs, Notion, Confluence)
- Atendimento: tickets + FAQ + manuais
- Busca semântica em catálogo / contratos / jurisprudência
- Recomendação (“conteúdos parecidos com este”)
- Deduplicação / detecção de near-duplicate
- Agentes que precisam “lembrar” de arquivos grandes sem meter tudo no prompt
O LLM sozinho tem janela de contexto finita e não conhece seus dados privados. O banco vetorial é a memória de longo prazo consultável por significado.
Objeções que eu escuto (e o que responde)
“Não posso só mandar o PDF inteiro no prompt?”
Até certo tamanho, sim. Depois disso: custo, latência, limite de tokens e qualidade caindo. Retrieval escala melhor.
“Full-text não basta?”
Basta pra palavra-chave. Falha quando o usuário pergunta de outro jeito. Híbrido (keyword + vetorial) costuma ser o melhor dos dois mundos.
“Preciso de Pinecone já no dia 1?”
Não. Protótipo: pgvector ou Qdrant local. Migra quando volume, latência ou filtros complexos doerem.
“O embedding ‘entende’ o documento?”
Ele posiciona o texto. Quem “raciocina” no texto recuperado é o LLM. Embedding ruim = retrieval ruim = resposta ruim, mesmo com GPT caro.
Checklist mental antes de meter vetor no stack
- O caso é busca por significado (não só filtro exato)?
- Chunking faz sentido pro domínio (tamanho, overlap, títulos)?
- Metadata de filtro definida (tenant, tipo, data)?
- Métrica de similaridade alinhada ao modelo (cosine / dot / L2)
- Avaliação de retrieval: a pergunta traz o trecho certo nos top-K?
- Plano B híbrido se o termo for código, ID, nome próprio
Conclusão
Usamos banco vetorial com IA porque modelos não consultam SQL por significado — eles consomem contexto. Embedding transforma texto em geometria; o banco encontra vizinhos; o LLM responde com o que foi recuperado.
Se a sua feature é “pergunte qualquer coisa sobre nossos documentos”, o gargalo raramente é “qual LLM”. É recuperar o pedaço certo, rápido, no tenant certo. Aí o vetor deixa de ser hype e vira infraestrutura.