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:
# 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.
Essa orientação é especialmente útil em aplicativos em tempo real e sensíveis à latência. Em configurações RAG com vários índices ou fluxos de autorizaçã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.