Pular para o conteúdo principal

Guia de desempenho da pesquisa vetorial

Mosaic AI Vector Search foi desenvolvido para uma recuperação rápida e escalável. O desempenho da pesquisa vetorial depende de diversos fatores, incluindo a escolha do SKU, o tamanho do índice, o tipo de consulta, a dimensionalidade do vetor, os métodos de autenticação e a forma como a sua aplicação lida com picos de tráfego. A maioria das cargas de trabalho apresenta um bom desempenho imediatamente, mas para situações em que é necessário escalar ou otimizar a latência, este guia apresenta dicas práticas e padrões comuns para ajudá-lo a configurar seu sistema para obter o desempenho ideal da pesquisa vetorial.

Fatores que afetam o desempenho

O desempenho não é um número único — é um intervalo que depende das características da carga de trabalho, das opções de configuração e da implementação do cliente. Este guia foi elaborado para auxiliá-lo a construir um modelo mental claro de como funciona o desempenho, para que possa utilizar o Mosaic AI Vector Search de forma mais eficaz.

A seguir estão os fatores do key que influenciam o comportamento do sistema:

  • Opção de SKU: padrão ou otimizado para armazenamento.
  • Tamanho do índice: número de vetores armazenados.
  • Tamanho de incorporação: normalmente 384—1536.
  • Tipo de consulta: vizinho mais próximo aproximado (redes neurais artificiais (ANN)) ou híbrido.
  • Número de resultados solicitados: valores mais altos aumentam o tempo de recuperação.
  • Tipo de incorporação: gerenciar ou auto-gerenciar.
  • Carga de consultas: a quantidade de tráfego que atinge o endpoint ao longo do tempo.
  • Método de autenticação: como seu aplicativo se conecta ao Databricks.

O restante deste artigo fornece dicas práticas para ajustar cada uma dessas variáveis e explica como elas afetam a latência da pesquisa e a taxa de transferência em implementações reais.

Selecione o SKU correto

Mosaic AI Vector Search Oferece duas SKUs, cada uma projetada para equilibrar latência, escalabilidade e eficiência de custos, dependendo da carga de trabalho. Escolher o SKU adequado para sua aplicação é o primeiro passo para otimizar o desempenho.

Em geral:

  • Selecione o ponto final padrão quando a latência for crítica e seu índice estiver bem abaixo de 320 milhões de vetores.
  • Selecione o endpoint otimizado para armazenamento quando estiver trabalhando com mais de 10 milhões de vetores, puder tolerar alguma latência extra e precisar de melhor custo-benefício por vetor (até 7 vezes mais barato).

A tabela a seguir apresenta algumas diretrizes de desempenho esperadas.

sku

Latência

QPS

Capacidade do índice

Tamanho da unidade de pesquisa vetorial (VSU)

Standard

20—50 ms

30—200+

Vetores 320M

Vetores 2M

Otimizado para armazenamento

300—500 ms

30—50

Vetores 1B

64M vetores

Entenda o tamanho do índice

O desempenho é mais elevado quando o seu índice se encaixa em uma única unidade de pesquisa vetorial, com espaço extra para lidar com cargas adicionais de consultas. À medida que as cargas de trabalho ultrapassam uma única unidade de pesquisa vetorial (ou seja, mais de 2 milhões de vetores para padrão ou mais de 64 milhões para otimizado para armazenamento), a latência aumenta e o QPS diminui. Eventualmente, o QPS estabiliza em aproximadamente 30 QPS (redes neurais artificiais (ANN)).

O desempenho depende de diversos fatores exclusivos de cada carga de trabalho, como padrões de consulta, filtros, dimensionalidade vetorial e simultaneidade. Os números a seguir são pontos de referência.

sku

Vetores

Dimensão

Latência

QPS

Consultas mensais

Standard

10K

768

20ms

Mais de 200

MAIS DE 500 M

10 milhões

768

40ms

30

78M

100M

768

50ms

30

78M

Otimizado para armazenamento

10 milhões

768

300 ms

50

130M

100M

768

400ms

40

100M

1B

768

500ms

30

78M

Minimize o tamanho da incorporação

A dimensionalidade vetorial refere-se ao número de recursos em cada vetor. Os valores típicos são 384, 768, 1024 ou 1536. Dimensões mais elevadas proporcionam representações mais expressivas que podem melhorar a qualidade, mas têm um custo de e compute. Vetores de menor dimensão exigem menos computação durante a recuperação, o que se traduz em tempos de consulta mais rápidos e maior QPS. Por outro lado, vetores de dimensões mais elevadas aumentam a carga e compute e e reduzem a taxa de transferência.

Como regra geral, escolha a menor dimensionalidade que preserve a qualidade da recuperação para seu caso de uso.

Por exemplo, reduzir a dimensionalidade em um fator de dois (digamos, de 768 para 384) normalmente melhora o QPS em cerca de 1,5x e reduz a latência em cerca de 20%, dependendo do tamanho do índice e do padrão de consulta. Esses ganhos aumentam ainda mais em dimensionalidades muito baixas. Por exemplo, o uso de vetores de 64 dimensões pode oferecer um QPS dramaticamente maior e uma latência significativamente menor em comparação com os benchmarks de 768 dimensões mostrados na tabela. Isso resulta em 384 dimensões e torna o abaixo especialmente atraente para casos de uso com alta taxa de transferência e sensíveis à latência, desde que a qualidade da recuperação permaneça aceitável.

Utilize redes neurais artificiais (ANN) para obter eficiência e utilize híbridas quando necessário.

Utilize consultas de redes neurais artificiais (ANN) sempre que possível. São os mais eficientes em termos de computee suportam o mais alto QPS.

Use a pesquisa híbrida quando necessário. A pesquisa híbrida melhora a recuperação em alguns aplicativos, especialmente quando as palavras-chave específicas do domínio são importantes. A pesquisa híbrida normalmente utiliza aproximadamente o dobro de recursos em comparação com as redes neurais artificiais (ANN) e pode reduzir significativamente a taxa de transferência.

Use 10—100 resultados

Cada consulta inclui um parâmetro num_results, que é o número de resultados da pesquisa a serem retornados. Este valor tem impacto direto no desempenho. A recuperação de mais resultados exige uma análise mais profunda do índice, o que aumenta a latência e reduz o QPS. O efeito se torna mais significativo em valores mais altos. Por exemplo, aumentar num_results em 10x pode dobrar a latência da consulta e reduzir a capacidade do QPS em 3x, dependendo do tamanho e da configuração do índice.

Como melhor prática, mantenha num_results na faixa de 10 a 100, a menos que seu aplicativo exija especificamente mais. Experimente diferentes valores de num_results usando consultas realistas para entender o impacto em sua carga de trabalho.

Evite a escala para zero na produção

A Pesquisa vetorial suporta dois tipos de incorporações com diferentes compromissos de desempenho.

Os embeddings gerenciados são os mais convenientes. Com gerenciar embeddings, o Databricks gera embeddings para suas linhas e consultas automaticamente. No momento da consulta, o texto da consulta é passado para um modelo de servidor endpoint para gerar a incorporação, o que adiciona latência. Se o modelo de incorporação for externo, ele também introduzirá uma sobrecarga de rede adicional.

compute As incorporações auto-gerenciadas permitem que você incorpore incorporações antecipadamente e passe os vetores diretamente no momento da consulta. Isso evita a geração de tempo de execução e permite a recuperação mais rápida. Todos os números de desempenho incluídos neste artigo são baseados em embeddings auto-gerenciados.

Para casos de uso de produção em tempo real, evite pontos finais de modelo que escalem para zero. O início a frio pode atrasar as respostas em vários minutos ou até mesmo causar falhas se o endpoint estiver inativo quando uma consulta chegar.

Planeje picos de consultas

Esta seção descreve o que esperar à medida que o tráfego aumenta e como permanecer abaixo dos limites críticos que acionam picos de latência ou erros 429 (Too Many Requests, ou Muitas solicitações).

A latência permanece baixa quando a carga é moderada e aumenta gradualmente à medida que você se aproxima da capacidade máxima de QPS. Quando o sistema atinge a capacidade de 100 QPS (% ), ele começa a retornar erros 429. Se você não configurou o backoff adequado, o aplicativo pode parar de responder.

Os erros 429 servem como um mecanismo de segurança para proteger o sistema. Eles orientam o cliente a recuar e tentar novamente mais tarde, para que o endpoint permaneça íntegro e responsivo, mesmo sob picos repentinos de tráfego.

Como prática recomendada, utilize a pesquisa vetorial Python SDK, que inclui backoff integrado e tratamento de tentativas.

Se utilizar a API REST, implemente o backoff exponencial com jitter.

Utilize a entidade de serviço com OAuth tokens

Utilize métodos de autenticação eficientes para obter o melhor desempenho. Databricks Recomenda-se utilizar uma entidade de serviço com tokens de autenticação de domínio ( OAuth ) em todos os ambientes de produção. Os tokens de acesso OAuth oferecem maior segurança e também aproveitam a infraestrutura otimizada para a rede, permitindo que o sistema opere em plena capacidade.

Evite utilizar tokens de acesso pessoal (PATs), pois eles introduzem sobrecarga na rede, adicionam centenas de milissegundos de latência e reduzem significativamente o QPS que seu endpoint pode sustentar.

Utilize o SDK Python

Utilize a versão mais recente do Python SDK para beneficiar de otimizações integradas de desempenho e confiabilidade.

Reutilize o objeto de índice nas consultas. Evite chamar client.get_index(...).similarity_search(...) em cada solicitação, pois esse padrão adiciona latência desnecessária.

Em vez disso, inicialize o índice uma vez e reutilize-o:

Python
# Initialize once
index = client.get_index(...)

# Then use it for every query
index.similarity_search(...)

Isso é importante ao utilizar o índice de pesquisa vetorial em ambientes MLFlow, onde é possível criar o objeto de índice em uma inicialização d endpoint e, em seguida, reutilizá-lo para todas as consultas.

Essas orientações são especialmente úteis em aplicações em tempo real e sensíveis à latência. Em configurações RAG com vários índices ou fluxos de autenticação em nome do usuário, em que a seleção de índice ou as credenciais só estão disponíveis no momento da consulta, inicializar o objeto de índice uma vez pode não ser viável. Essa otimização não é necessária nesses cenários.

Paralelizar entre pontos finais

A Databricks recomenda explorar as seguintes estratégias para aumentar o QPS total no sistema:

  • Divida os índices entre os terminais. Se você possui vários índices, cada um recebendo uma parte significativa do tráfego, hospede-os em pontos de extremidade separados para alcançar uma largura de banda total mais elevada.
  • Replicar o índice em todos os terminais. Se a maior parte do tráfego atingir um único índice, duplique-o em vários pontos finais. Divida o tráfego uniformemente no nível do cliente para obter ganhos lineares de QPS.