Rapidez x precisão: medindo o recall da busca vetorial quantizada

Todo mundo quer que a busca vetorial seja imediata. Mas os vetores de alta dimensão são pesados. Um único vetor float-32 de 1.024 dimensões ocupa bastante memória, e compará-lo com milhões de outros é computacionalmente caro.

Para resolver isso, mecanismos de busca como o Elasticsearch utilizam duas estratégias principais de otimização:

1. Busca aproximada (mundo pequeno hierárquico navegável [HNSW]): em vez de analisar cada documento, construímos um grafo de navegação para acessar rapidamente a vizinhança provável da resposta.
2. Quantização: Compactamos os vetores (por exemplo, de floats de 32 bits para inteiros de 8 bits ou até mesmo valores binários de 1 bit) para reduzir o uso de memória e acelerar os cálculos.

Mas a otimização geralmente vem acompanhada de uma taxa: a precisão.

O medo é válido: "Se eu compactar meus dados e usar atalhos durante a busca, perderei os melhores resultados?" "Essa otimização degrada a relevância do meu mecanismo de busca?"

Para provar que a quantização do Elastic não degrada os resultados, criamos um ambiente de testes repetíveis usando o DBPedia-14 como conjunto de dados para calcular exatamente quanta precisão (especificamente, recall) sacrificamos em prol da velocidade ao usar as otimizações padrão do Elasticsearch.

Resumindo: é provavelmente muito menos do que você pensa. Confira o caderno aqui e teste você mesmo

As definições (para os não especialistas)

Antes de analisarmos o código, vamos definir alguns termos.

• Relevância versus recuperação: A relevância é subjetiva (encontrei informações úteis?). A recuperação é matemática. Se houver 10 documentos no banco de dados que correspondam perfeitamente à sua consulta, e o mecanismo de busca encontrar nove deles, sua recuperação será de 90% (ou 0,9).
• Busca exata (plana): às vezes chamada de método "força bruta". O mecanismo de busca analisa cada documento em um índice e calcula a distância.
  • Prós: recall perfeito de 100%.
  • Contras: computacionalmente caro e lento em larga escala.
• Busca aproximada (HNSW): O método do "atalho". O mecanismo de busca cria um HNSW gráfico e percorre o gráfico para encontrar os vizinhos mais próximos.
  • Prós: extremamente rápido e escalável.
  • Contras: Você pode perder um vizinho se a travessia do gráfico parar muito cedo.

O experimento: exato x aproximado

Para testar a recuperação, usamos o conjunto de dados DBPedia-14, um grande conjunto de dados de títulos e resumos em 14 classes de ontologia, muito usado para treinar e avaliar modelos de categorização de texto. Especificamente, vamos focar a categoria "Filme". Decidimos comparar as configurações otimizadas de produção com uma verdade matematicamente perfeita.

Neste experimento, estamos usando o modelo jina-embeddings-v5-text-small, um modelo multilíngue de última geração que lidera os benchmarks do setor de representação de textos. Escolhemos esse modelo porque ele define o padrão atual para embeddings de alto desempenho. Ao combinar a precisão de elite do Jina v5 com a quantização nativa do Elasticsearch, podemos demonstrar uma arquitetura de busca que é computacionalmente eficiente e sem prejudicar a qualidade da recuperação.

Configuramos um índice com mapeamento duplo. Ingerimos o mesmo texto em dois campos diferentes simultaneamente:

1. content.raw com tipo: flat. Isso força o Elasticsearch a realizar uma varredura de força bruta dos vetores Float32 completos. Isso retorna resultados de correspondência exatos e será usado na nossa linha de base.
2. content com o tipo semantic_text. Com padrões usando HNSW + melhor quantização binária (BBQ). Esse é o padrão otimizado de produção para correspondência aproximada.

O teste Recall@10

Para nossa métrica, usamos o Recall@10.

Escolhemos 50 filmes aleatórios e executamos a mesma consulta nos dois campos.

• Se a busca exata (plana) indicar que os 10 principais vizinhos são IDs [1, 2, 3... 10], você pode usar a busca exata.
• E a busca aproximada (HNSW) retorna IDs [1, 2, 3... 9, 99].
• Encontramos corretamente nove dos 10 principais. A pontuação é 0,9.

Aqui está o mapeamento que usamos:

Os resultados: a "estagnação" do sucesso

Realizamos um teste de escala, recarregando todo o conjunto de dados e testando com tamanhos de índice de 1.000 a 40.000 documentos.

Veja o que aconteceu com a pontuação de recall:

Os resultados foram incrivelmente estáveis. Mesmo com o aumento da escala, a busca aproximada coincidiu com a busca exata por força bruta em mais de 99% dos casos.

Por que funcionou tão bem?

Você poderia esperar que comprimir vetores em valores binários prejudicasse mais a precisão do que isso. A razão para isso não ocorrer está em como o Elasticsearch lida com a recuperação.

A maioria dos modelos de embedding hoje gera vetores Float32, que são volumosos. Para deixar a busca eficiente, o Elasticsearch usa quantização para vetores de alta dimensionalidade. Especificamente, desde a versão 9.2, ele usa BBQ como padrão.

O BBQ usa um mecanismo de reclassificação:

1. Percurso: o mecanismo de busca utiliza os vetores comprimidos (quantizados) para percorrer rapidamente o gráfico HNSW. Como os vetores são pequenos, ele pode superamostrar com eficiência, reunindo uma lista maior de candidatos (p. ex., os 100 principais documentos aproximadamente semelhantes) sem penalidade no desempenho.
2. Reclassificação: com esses candidatos, ele recupera os valores de precisão total apenas para esses poucos documentos para calcular a classificação final e precisa.

Ele oferece o melhor dos dois mundos: rapidez na quantização para o trabalho pesado e precisão dos números de ponto flutuante para a classificação final.

Podemos fazer melhor?

É importante notar que os resultados aqui usam configurações padrão e uma amostra aleatória de dados. Pense nisso como um ponto de partida de alto desempenho. Embora o Jina v5 seja excelente, essas pontuações de recall não são garantia de que funcione em todos os conjuntos de dados. Cada coleta de dados tem as próprias peculiaridades e, embora você possa definitivamente ajustar ainda mais as coisas para ter ainda mais desempenho, deve sempre comparar seus dados específicos para saber seu limite.

Conclusão

Este é um teste em pequena escala. Mas o objetivo do exercício não é medir especificamente o modelo de embeddings nem o BBQ, e sim mostrar como medir facilmente o recall do seu conjunto de dados com o mínimo de configuração.

Se você quiser executar esse teste com seus próprios dados, pode conferir o notebook aqui e tentar você mesmo.