Infraestrutura de Recuperação e Bancos de Dados Vetoriais

Uma prova de conceito de busca vetorial e um sistema em produção que se sustenta sob volume real de consultas são dois problemas de engenharia distintos. Nós construímos e operamos a camada de infraestrutura de recuperação que fica por baixo do seu pipeline de RAG, dos seus fluxos de trabalho agênticos ou do seu produto de busca semântica — o motor vetorial, o pipeline de embeddings que o alimenta, o gerenciamento do ciclo de vida do índice que o mantém saudável e a stack de observabilidade que detecta a degradação de qualidade antes que os usuários percebam.

Somos neutros em relação ao fornecedor do motor. Nossa prática é agnóstica quanto ao motor entre Qdrant, Milvus, Weaviate, pgvector e Elasticsearch kNN, e qual deles recomendamos depende da sua contagem de vetores, dos padrões de consulta, dos requisitos de multi-tenancy e da capacidade operacional.

De um Demo de 50 mil Vetores à Produção de 200 milhões de Vetores

A lacuna entre um demo e um sistema em produção é quase inteiramente um problema de infraestrutura. O demo carrega 50 mil vetores no Pinecone, executa uma consulta de similaridade por cosseno e retorna resultados em 40 ms. A produção não se parece em nada com isso.

• 200 milhões de vetores e 500 consultas por segundo sustentadas
• 15 dimensões de filtro de metadados e documentos atualizando a cada hora
• Três equipes compartilhando um único cluster sob isolamento estrito de tenants

Nessa escala, os picos de compactação do HNSW estouram seu P99 para 800 ms, o recall se degrada silenciosamente após uma semana de atualizações incrementais, e o pipeline de embeddings não consegue acompanhar a taxa de mudança dos seus documentos. É aqui que trabalhamos.

A Seleção do Motor É um Exercício de Benchmarking, Não uma Decisão de Marca

Todo fornecedor afirma ter desempenho de ponta; os benchmarks contam uma história mais complexa. Não escolhemos um banco de dados a partir de uma matriz de recursos — carregamos seus vetores reais, executamos suas consultas reais com seus filtros de metadados reais e medimos o recall em valores de k operacionalmente relevantes junto à latência P50/P95/P99 sob carga concorrente.

Os resultados contradizem regularmente o marketing dos fornecedores. O nível serverless do Pinecone parece econômico até que cargas de trabalho sustentadas de alto QPS empurrem os custos de unidades de leitura além do ponto de equilíbrio do self-hosting, e o pgvector parece limitante até que as varreduras iterativas fechem a lacuna da busca filtrada.

O Pipeline de Embeddings É Onde a Recuperação em Produção Realmente Falha

As equipes gastam 60% do seu esforço de engenharia de busca vetorial no pipeline, não no armazenamento. O pipeline cuida da ingestão de documentos, do chunking, da inferência do modelo de embedding, da reindexação incremental em atualizações de documentos e da propagação de metadados — e cada etapa tem modos de falha que degradam silenciosamente a qualidade da recuperação.

• Conhecimento desatualizado — a segunda falha mais comum de RAG em produção. Um documento é atualizado no Confluence, mas o índice ainda serve o embedding antigo. A correção são gatilhos de change-data-capture que reembutem incrementalmente, não uma reindexação em lote noturna.
• Documentos fantasma — um documento de origem é excluído, mas seu vetor permanece, retornando resultados para conteúdo que não existe mais. Como transações atômicas entre um sistema de fonte da verdade e um armazenamento vetorial são quase impossíveis em arquiteturas divididas, construímos camadas de reconciliação que detectam e expurgam vetores órfãos.

A seleção do modelo de embedding importa mais do que a maioria das equipes percebe, e trocar depois é caro: reembutir 8 milhões de documentos quando você faz upgrade de text-embedding-ada-002 para text-embedding-3-large custa dias de computação e exige infraestrutura de dual-write para evitar tempo de inatividade. Avaliamos os modelos em relação ao seu conjunto de consultas específico do domínio antes de você se comprometer.

• Cohere embed-v4 — lidera a recuperação multilíngue a US$ 0,01 por milhão de tokens em mais de 100 idiomas.
• Nomic Embed v2 — 137 milhões de parâmetros, roda em CPU, com a melhor relação qualidade-tamanho do mercado.
• OpenAI text-embedding-3-large — um forte polivalente.

A escolha certa depende da sua mistura de idiomas, dos requisitos de latência e de você poder aceitar dependência de API ou precisar de inferência local (on-premises).

Ciclo de Vida do Índice: O Problema Operacional Sobre o Qual Ninguém Te Avisa

Os índices HNSW se degradam — não é um bug, é uma realidade arquitetural. Com 160 milhões de vetores, uma reconstrução completa de HNSW leva 3 a 6 horas. As atualizações incrementais tornam a estrutura do grafo subótima e corroem o recall ao longo do tempo; os eventos de compactação disparam a latência de consulta; e cada upsert, exclusão e mesclagem de segmento aciona reconstruções de subíndices que consomem CPU em manutenção em vez de servir consultas. O trade-off é inevitável: elevar de 0,8 para 0,95 de recall aumenta a latência do HNSW em aproximadamente 31%.

Projetamos um gerenciamento de ciclo de vida que absorve a ingestão contínua sem perda de qualidade:

• Rotação de índice blue-green — reconstruir em infraestrutura separada e trocar atomicamente com zero tempo de inatividade.
• Portões automatizados de validação de recall — comparar um conjunto de consultas de referência (golden) com o índice atual após cada operação importante; se o recall cair abaixo do limite, a troca não acontece.
• A construção de HNSW acelerada por GPU no Qdrant e no Elasticsearch reduz os tempos de reconstrução em uma ordem de magnitude, embora a orquestração de quando reconstruir, como validar e como trocar seja engenharia customizada.

A quantização amplia isso ainda mais. O Qdrant agora oferece quantização de 1,5 bit, 2 bits e assimétrica , e o BBQ do Elasticsearch reduz o heap em mais de 95% em comparação com float32. Isso economiza memória e melhora a taxa de transferência, mas cada esquema tem um perfil de recall diferente frente a distribuições de dados diferentes — por isso caracterizamos o impacto no recall dos seus vetores específicos antes de implantar a quantização em produção.

Multi-Tenancy e Isolamento em Escala Real

Equipes de plataforma atendendo mais de 200 equipes internas de ML, ou produtos SaaS com milhares de tenants clientes, precisam de infraestrutura que garanta isolamento: as consultas do tenant A nunca podem retornar os dados do tenant B, os logs de auditoria devem rastrear cada consulta até uma identidade de tenant, e tenants inativos (cold) não devem consumir recursos de que os tenants ativos (hot) precisam.

• Weaviate — o modelo de um-shard-por-tenant com estados de tenant (ACTIVE, INACTIVE, OFFLOADED para o S3) é a implementação mais madura para implantações com alta contagem de tenants.
• Milvus — suporta isolamento em nível de banco de dados, coleção, partição ou chave de partição, ajustando a granularidade aos seus requisitos de conformidade.

Ambos exigem orquestração customizada em escala — provisionamento de tenants, transições de estado, gerenciamento de cotas e detecção de vazamento entre tenants não são tratados pelo próprio banco de dados. Construímos a camada operacional que torna a multi-tenancy gerenciável para implantações reguladas que exigem conformidade com SOC 2 ou ISO 27001 .

Fluxos de Trabalho Agênticos Estão Remodelando os Requisitos de Infraestrutura

A onda da IA agêntica muda o que os armazenamentos vetoriais precisam fazer. O RAG estático recupera documentos de um corpus fixo. Os fluxos de trabalho agênticos exigem memória episódica (histórico de conversa e raciocínio intermediário), busca semântica sobre um grande corpus de documentos, e camadas de perfil de usuário — muitas vezes acessando os três em um único passo do agente. O requisito de latência abaixo de 400 ms é mais rígido que o do RAG em lote, e o suporte a transações ACID está se tornando essencial para agentes multietapa que atualizam o estado sem escritas parciais.

Nenhum banco de dados vetorial isolado lida bem com as três camadas de memória, então as equipes montam arquiteturas multi-armazenamento: Redis para estado de sessão, Qdrant ou Milvus para busca semântica, e um banco de dados de grafo para rastreamento de relacionamentos. O Unified Memory Core da Oracle (março de 2026) tenta convergir consultas vetoriais, JSON, de grafo, relacionais e espaciais em um único motor. Projetamos a camada de recuperação para sistemas agênticos — quais armazenamentos lidam com quais tipos de memória, como as consultas são roteadas entre armazenamentos e como a consistência se mantém quando um agente atualiza o estado em vários backends em um único passo de raciocínio.

O Que Entregamos

Todo engajamento começa com uma fase de benchmarking: carregamos seus vetores, executamos suas consultas e produzimos recomendações de motor quantificadas. A partir daí, construímos a infraestrutura de produção:

• O cluster de armazenamento vetorial, com planejamento de capacidade e runbooks de escalonamento.
• O pipeline de embeddings, com reindexação incremental acionada por CDC e gerenciamento de versões de modelo.
• A automação do ciclo de vida do índice, com rotação blue-green e portões de validação de recall.
• A camada de orquestração de multi-tenancy, quando você precisar de isolamento de tenants.
• A stack de observabilidade, com detecção de drift, alertas de regressão de recall e monitoramento de latência P95/P99.
• Ferramentas de migração para equipes migrando entre motores, usando formatos Parquet intermediários para preservar os embeddings onde a dimensionalidade coincide, em vez de forçar um reembute completo.

Definimos o escopo de cada engajamento com projeções mensais explícitas de custo de infraestrutura, para que você saiba quanto a produção vai custar antes de se comprometer.