Busca vetorial no Manticore Search: como tratar como sistema de produção

O Manticore Search não trata busca vetorial como um mero complemento a embeddings, mas como um sistema de retrieval completo, com suas próprias métricas, tradeoffs de arquitetura e ciclos de operação. Isso significa que o índice vetorial precisa ser modelado como um componente crítico de infraestrutura: sua atualização exige batching controlado para evitar picos de CPU e memória, sua fragmentação exige otimização de chunks (não só por tamanho, mas por densidade semântica dos vetores), e sua persistência depende de backups físicos, não apenas lógicos, porque índices HNSW não são reconstruídos rapidamente a partir de dados brutos. A versão 6, lançada em 2024, já suporta até 10 milhões de vetores indexados por segundo em hardware moderno, mas essa taxa cai drasticamente se o HNSW não for afinado com parâmetros como ef_construction e max_links, que afetam diretamente recall vs latência.

Essa visão opera no mesmo plano de desafios que o CockroachDB enfrentou ao desenvolver o C-SPANN: HNSW padrão não escala bem em arquiteturas distribuídas ou com atualizações contínuas. Também dialoga com o que o Postgres revela em cenários reais, quando tabelas ultrapassam 5 milhões de vetores e filtros de metadados entram na query, o custo de manter alta precisão de recall sob pressão de latência começa a exigir decisões de engenharia, não só de modelagem. O Manticore resolve isso com uma camada de cache de resultados de ANN pré-filtrados, algo ausente em soluções genéricas de embedding.

Em 1º de junho, o CEVIU destacou os tradeoffs do HNSW no Postgres, mas como um problema de *escolha de índice*. Agora, com a orientação do Manticore, o foco migrou para *operação contínua*: tuning de HNSW deixou de ser uma configuração estática e virou um processo dinâmico ligado a SLAs de recall (ex.: ≥92% em 99% das queries) e orçamento de memória (ex.: ≤12 GB por nó). Também é nova a ênfase em backups físicos, antes, a cobertura tratava recuperação de índices vetoriais como questão secundária; agora, é condição para produção.

Para times de dados que usam RAG ou sistemas agênticos, ignorar a natureza sistêmica da busca vetorial gera vazamentos silenciosos: um LLM pode gerar respostas plausíveis, mas baseadas em chunks recuperados com baixo recall ou alto skew semântico. O Manticore mostra que, nesse contexto, a qualidade do retrieval não depende só do modelo de embedding, mas da estabilidade do índice, da granularidade do chunking e da integridade física do backup, fatores que impactam diretamente a confiabilidade de pipelines analíticos e de recomendação, como o SilverTorch da Meta, onde 'index as model' só funciona se o índice for tão robusto quanto o modelo.