Como funciona
- Geração do embedding. Os dados (texto, imagem, áudio) são convertidos em vetores numéricos densos por um modelo de embedding antes de entrar no banco.
- Indexação por ANN. Os vetores entram no banco e são organizados via algoritmo de busca aproximada (HNSW, IVF, LSH). É o índice que torna possível pesquisar similaridade em milhões de vetores em milissegundos.
- Consulta por similaridade. A pergunta é convertida em vetor pelo mesmo modelo de embedding usado na ingestão e o banco devolve os top-k mais próximos por uma métrica (cosseno, dot product, L2).
- Recuperação dos dados originais. Os IDs dos vetores retornados apontam pros documentos originais, que entram em RAG, recomendação ou outro pipeline downstream.
Por que importa
- Casa por significado, não por igualdade. Banco relacional acha registro por chave exata. Vector database acha por similaridade semântica.
- Escala em milhões com ANN. Comparar vetor de consulta contra cada um dos N vetores da base é inviável em volume. ANN aproxima isso em milissegundos.
- É fundação de RAG. Todo sistema RAG bem feito tem um vector database por baixo. É a memória externa do LLM.
- Habilita recomendação e detecção de anomalia. Sistema que sugere itens parecidos ou identifica outliers passa por busca em vetor.
O que muda para cada perfil
Para o Translator
Leitura transversal: como o conceito muda o papel de quem alinha tech, dados e negócio.
O que muda pra você. Vector database é peça-chave do RAG. Escolher errado custa caro depois. O Translator participa da decisão arquitetural em vez de delegar 100% pra engenharia, porque a escolha tem efeito direto em produto e custo.
Analogia. É infra de RAG, igual o Postgres é infra de aplicação. Quem trata como detalhe de implementação descobre tarde que mudou o stack inteiro depois.
Pergunta-âncora. "pgvector basta" ou "precisamos Pinecone"? Não é decisão de engenharia pura. É decisão de produto com restrição de custo e escala.
Para DPM
Linguagem e exemplos para Data Product Managers e Analytics Leads.
O que muda pra você. Vector database é o backend da camada de "dados não estruturados como produto". Tickets, contratos, e-mails, transcrições deixam de ser arquivo morto e viram base recuperável por significado. Métrica de qualidade da busca (recall@k, precision) é responsabilidade de Analytics.
Analogia. É um warehouse, mas pra significado. SQL casa CPF com CPF; vector database casa "ticket que reclama de cobrança" com "registro de erro de billing" mesmo sem palavra em comum.
Pergunta-âncora. Como medimos qualidade da busca? Sem métrica (recall@k, MRR), o sistema vira caixa-preta e ninguém sabe se piorou.
Para Produto
Linguagem e exemplos para Product Managers.
O que muda pra você. Vector database habilita feature de busca semântica, recomendação por similaridade e Q&A em base de documentos. Mas escolha errada de stack vira dívida técnica que afeta latência, custo unitário e capacidade de filtrar por metadata.
Analogia. É como escolher banco pra produto financeiro. Mudar depois é caro. Decisão de plataforma, não só de infra.
Pergunta-âncora. Esse problema é de busca semântica de verdade ou keyword search resolve? Vector database só compensa quando a busca lexical claramente não entrega.
Para Engenharia
Linguagem e exemplos para Data Engineers, ML Engineers e Arquitetos.
O que muda pra você. Stack típica: pgvector (Postgres extension, mais barato pra começar), Pinecone (managed, mais caro mas operação simples), Weaviate, Qdrant, Milvus, ChromaDB. Trade-offs: latência vs recall, hosted vs self-hosted, hybrid search (dense + BM25), metadata filtering, multi-tenancy.
Analogia. Pense em índice especializado pra similaridade aproximada. HNSW é o B-tree desse mundo. Tem trade-off entre tempo de build, memória e recall.
Pergunta-âncora. Vou começar com pgvector ou já preciso de banco dedicado? Em quase todo POC, pgvector resolve. Migrar depois é trabalho conhecido, e adia decisão de licença/operação.
Para Gestão
Linguagem e exemplos para TPMs, Engineering Managers e líderes de time.
O que muda pra você. Vector database é capability técnica que escala com a empresa. Cada projeto que usa RAG, recomendação ou clustering vai bater nessa mesma infra. Sem ownership central, cada squad escolhe stack diferente, e a operação vira N bancos de vetor desconexos.
Analogia. É infra compartilhada, igual a um data warehouse central. Permitir que cada squad escolha o seu é fragmentar capability.
Pergunta-âncora. Quem é dono do vector database na empresa? Sem dono central, fica óbvio em 6 meses pelo número de stacks duplicadas.
Para Negócio
Linguagem e exemplos para Estratégia, Operações e FP&A.
O que muda pra você. Vector database é o que viabiliza, do lado técnico, qualquer projeto de IA que use conhecimento próprio da empresa. É infra cara de operar em escala, então faz sentido começar pequeno (pgvector) e migrar pra solução dedicada só quando o volume justifica.
Analogia. É como começar com servidor compartilhado e migrar pra dedicado. Pular essa progressão custa licença antes de provar o caso.
Pergunta-âncora. Antes de comprar Pinecone ou Weaviate, alguém testou pgvector em escala real? Pra projeto que ainda não passou de POC, pgvector quase sempre cabe.
Citado nestes artigos
2 artigos do blog referenciam Vector database.
RAG vs fine-tuning: quando cada um cabe
RAG entrega conhecimento atualizável e auditável. Fine-tuning entrega estilo, formato e domínio com vocabulário próprio. Decisão arquitetural com efeito direto em custo.
O que é RAG (Retrieval Augmented Generation)
RAG combina busca semântica em base interna com geração de texto. Forma mais barata e auditável de fazer IA usar conhecimento da empresa.