Escolher e alimentar um banco de dados vetorial

Uma equipe implanta um serviço vetorial especializado para 12.000 fragmentos. Seis semanas depois, é preciso restringir a busca aos documentos visíveis para o usuário conectado, e as permissões vivem no PostgreSQL. Não existe nenhum join entre os dois sistemas. A equipe acaba recuperando 200 resultados do serviço vetorial, consultando o PostgreSQL para saber quais são autorizados e mantendo apenas três. A latência triplica, o recall desaba assim que um usuário tem poucas permissões, e 12.000 vetores caberiam em 50 megabytes de memória.

A escolha de um banco vetorial costuma ser apresentada como uma questão de desempenho de busca. Para a grande maioria dos projetos, esse não é o critério decisivo: abaixo de alguns milhões de vetores, todas as opções são rápidas o suficiente. O que decide é sua capacidade de filtrar por metadados, de manter a consistência entre seus vetores e sua fonte da verdade, e de remover um documento de forma limpa. Escolha com base nesses três eixos, não em um teste de velocidade.