6 desafios críticos da produção da pesquisa vetorial

Você decidiu usar a pesquisa vetorial em seu aplicativo, produto ou negócio. Você pesquisou como e por que os embeddings e a pesquisa vetorial tornam um problema solucionável ou podem ativar novos recursos. Você mergulhou na área quente e emergente de algoritmos aproximados de vizinhos mais próximos e bancos de dados de vetores.

Quase imediatamente após a produção de aplicativos de pesquisa vetorial, você começará a enfrentar dificuldades muito difíceis e potencialmente imprevistas. Este blog tenta fornecer a você algum conhecimento sobre o seu futuro, os problemas que você enfrentará e as perguntas que você talvez ainda não saiba e que precisa fazer.

1. Pesquisa vetorial ≠ banco de dados vetorial

A pesquisa vetorial e todos os algoritmos inteligentes associados são a inteligência central de qualquer sistema que tente aproveitar vetores. No entanto, toda a infra-estrutura associada para torná-lo útil ao máximo e pronto para produção é enorme e muito, muito fácil de subestimar.

Para colocar isso da maneira mais forte que posso: um banco de dados vetorial pronto para produção resolverá muitos, muitos mais problemas de “banco de dados” do que problemas “vetoriais” . De forma alguma a pesquisa vetorial em si é um problema “fácil” (e abordaremos muitos dos subproblemas difíceis abaixo), mas a montanha de problemas de banco de dados tradicionais que um banco de dados vetorial precisa resolver certamente continua sendo a “parte difícil”. ”

Os bancos de dados resolvem uma série de problemas muito reais e bem estudados, desde atomicidade e transações, consistência, desempenho e otimização de consultas, durabilidade, backups, controle de acesso, multilocação, escalonamento e fragmentação e muito mais. Os bancos de dados vetoriais exigirão respostas em todas essas dimensões para qualquer produto, negócio ou empreendimento.

Tenha muito cuidado com a “infraestrutura de pesquisa vetorial” desenvolvida em casa. Não é tão difícil baixar uma biblioteca de pesquisa vetorial de última geração e começar a aproximar-se do vizinho mais próximo em direção a um protótipo interessante. Continuar nesse caminho, entretanto, é um caminho para reinventar acidentalmente seu próprio banco de dados. Essa é provavelmente uma escolha que você deseja fazer conscientemente.

2. Indexação incremental de vetores

Devido à natureza dos mais modernos algoritmos de busca vetorial de RNA, a atualização incremental de um índice vetorial é um enorme desafio. Este é um conhecido “problema difícil”. A questão aqui é que esses índices são cuidadosamente organizados para pesquisas rápidas e qualquer tentativa de atualizá-los gradativamente com novos vetores deteriorará rapidamente as propriedades da pesquisa rápida. Assim, para manter pesquisas rápidas à medida que os vetores são adicionados, esses índices precisam ser reconstruídos periodicamente do zero.

Qualquer aplicação que pretenda transmitir novos vetores continuamente, com requisitos de que ambos os vetores apareçam rapidamente no índice e as consultas permaneçam rápidas, precisará de suporte sério para o problema de “indexação incremental”. Esta é uma área muito importante para você entender seu banco de dados e um bom lugar para fazer uma série de perguntas difíceis.

Existem muitas abordagens possíveis que um banco de dados pode adotar para ajudar a resolver esse problema para você. Uma pesquisa adequada dessas abordagens preencheria muitos posts desse tamanho. É importante compreender alguns detalhes técnicos da abordagem do seu banco de dados, pois isso pode ter compensações ou consequências inesperadas no seu aplicativo. Por exemplo, se um banco de dados optar por fazer uma reindexação completa com alguma frequência, isso poderá causar alta carga de CPU e, portanto, afetar periodicamente as latências de consulta.

Você deve compreender a necessidade de indexação incremental de seus aplicativos e os recursos do sistema no qual você confia para atendê-lo.

3. Latência de dados para vetores e metadados

Cada aplicativo deve compreender sua necessidade e tolerância à latência de dados. Os índices baseados em vetores têm, pelo menos segundo outros padrões de banco de dados, custos de indexação relativamente altos. Há uma compensação significativa entre custo e latência de dados.

Quanto tempo depois de 'criar' um vetor você precisa que ele seja pesquisável em seu índice? Se for em breve, a latência vetorial será um ponto importante no design desses sistemas.

O mesmo se aplica aos metadados do seu sistema. Como regra geral, a mutação de metadados é bastante comum (por exemplo, alterar se um usuário está online ou não) e, portanto, normalmente é muito importante que as consultas filtradas de metadados reajam rapidamente às atualizações de metadados. Tomando o exemplo acima, não será útil se sua pesquisa vetorial retornar uma consulta para alguém que ficou offline recentemente!

Se você precisar transmitir vetores continuamente para o sistema ou atualizar os metadados desses vetores continuamente, será necessária uma arquitetura de banco de dados subjacente diferente daquela que seria aceitável para o seu caso de uso, por exemplo, reconstruir o índice completo todas as noites para ser usado no dia seguinte .

4. Filtragem de metadados

Afirmarei fortemente este ponto: penso que em quase todas as circunstâncias, a experiência do produto será melhor se a infraestrutura de pesquisa vetorial subjacente puder ser aumentada pela filtragem de metadados (ou pesquisa híbrida).

Mostre-me todos os restaurantes que eu possa gostar (uma pesquisa vetorial) que estejam localizados em um raio de 16 quilômetros e tenham preços baixos a médios (filtro de metadados).

A segunda parte desta consulta é uma cláusula WHERE tradicional do tipo sql intersectada com, na primeira parte, um resultado de pesquisa vetorial. Devido à natureza desses índices vetoriais grandes, relativamente estáticos e relativamente monolíticos, é muito difícil fazer pesquisas conjuntas de vetores + metadados com eficiência. Este é outro dos conhecidos “problemas difíceis” que os bancos de dados vetoriais precisam resolver em seu nome.

Existem muitas abordagens técnicas que os bancos de dados podem adotar para resolver esse problema para você. Você pode “pré-filtrar”, o que significa aplicar o filtro primeiro e depois fazer uma pesquisa vetorial. Esta abordagem sofre por não ser capaz de aproveitar efetivamente o índice vetorial pré-construído. Você pode “pós-filtrar” os resultados depois de fazer uma pesquisa vetorial completa. Isso funciona muito bem, a menos que seu filtro seja muito seletivo; nesse caso, você gasta muito tempo procurando vetores que mais tarde descarta porque não atendem aos critérios especificados. Às vezes, como é o caso do Rockset, você pode fazer uma filtragem de “estágio único”, que consiste em tentar mesclar o estágio de filtragem de metadados com o estágio de pesquisa de vetor de uma forma que preserve o melhor dos dois mundos.

Se você acredita que a filtragem de metadados será crítica para seu aplicativo (e afirmo acima que quase sempre será), as compensações e a funcionalidade da filtragem de metadados se tornarão algo que você desejará examinar com muito cuidado.

5. Linguagem de consulta de metadados

Se eu estiver certo e a filtragem de metadados for crucial para o aplicativo que você está construindo, parabéns, você tem outro problema. Você precisa de uma maneira de especificar filtros sobre esses metadados. Esta é uma linguagem de consulta.

Vindo do ponto de vista do banco de dados, e como este é um blog do Rockset, você provavelmente pode esperar onde estou indo com isso. SQL é a forma padrão da indústria para expressar esses tipos de instruções. “Filtros de metadados” em linguagem vetorial são simplesmente “a cláusula WHERE ” para um banco de dados tradicional. Tem a vantagem de também ser relativamente fácil de portar entre diferentes sistemas.

Além disso, esses filtros são consultas e as consultas podem ser otimizadas. A sofisticação do otimizador de consultas pode ter um enorme impacto no desempenho de suas consultas. Por exemplo, otimizadores sofisticados tentarão aplicar primeiro os filtros de metadados mais seletivos, pois isso minimizará o trabalho exigido pelos estágios posteriores da filtragem, resultando em um grande ganho de desempenho.

Se você planeja escrever aplicativos não triviais usando pesquisa vetorial e filtros de metadados, é importante entender e estar confortável com a linguagem de consulta, tanto em ergonomia quanto em implementação, que você está se inscrevendo para usar, escrever e manter.

6. Gerenciamento do ciclo de vida do vetor

Tudo bem, você chegou até aqui. Você tem um banco de dados vetorial que possui todos os fundamentos corretos de banco de dados necessários, possui a estratégia de indexação incremental correta para seu caso de uso, possui uma boa história sobre suas necessidades de filtragem de metadados e manterá seu índice atualizado com latências você pode tolerar. Incrível.

Sua equipe de ML (ou talvez OpenAI) lança uma nova versão de seu modelo de incorporação. Você tem um banco de dados gigantesco cheio de vetores antigos que agora precisam ser atualizados. O que agora? Onde você executará esse grande trabalho de ML em lote? Como você vai armazenar os resultados intermediários? Como você fará a mudança para a nova versão? Como você planeja fazer isso de uma forma que não afete sua carga de trabalho de produção?

Faça as perguntas difíceis

A pesquisa vetorial é uma área emergente rapidamente e estamos vendo muitos usuários começando a trazer aplicativos para produção. Meu objetivo para esta postagem foi fornecer a você algumas das perguntas cruciais e difíceis que você talvez ainda não saiba fazer. E você se beneficiará muito se eles forem respondidos mais cedo ou mais tarde.

Neste post o que não abordei foi como a Rockset tem e está trabalhando para resolver todos esses problemas e por que algumas de nossas soluções para eles são inovadoras e melhores do que a maioria das outras tentativas de última geração. Cobrir isso exigiria muitas postagens desse tamanho, que é, creio eu, exatamente o que faremos. Fique atento para mais.