Guia de desempenho da Busca Vetorial
Mosaic AI Vector Search foi desenvolvida para recuperação rápida e escalável. O desempenho da busca vetorial depende de muitos fatores, incluindo a escolha da SKU, o tamanho do índice, o tipo de consulta, a dimensionalidade do vetor, os métodos de autenticação e como seu aplicativo lida com picos de tráfego. A maioria das cargas de trabalho funciona bem sem nenhuma configuração adicional, mas para situações em que você precisa aumentar ou otimizar a latência, este guia apresenta dicas práticas e padrões comuns para ajudá-lo a configurar seu sistema para um desempenho ideal na busca vetorial.
Fatores que afetam o desempenho
O desempenho não é um número único — é uma faixa que depende das características da carga de trabalho, das opções de configuração e da implementação do cliente. Este guia foi desenvolvido para ajudá-lo a construir um modelo mental claro de como o desempenho funciona, para que você possa usar Mosaic AI Vector Search da maneira mais eficaz.
Os key fatores que influenciam o comportamento do sistema são os seguintes:
- Escolha do SKU: padrão ou otimizado para armazenamento.
- Tamanho do índice: número de vetores armazenados.
- Tamanho de inserção: tipicamente 384–1536.
- Tipo de consulta: vizinho mais próximo aproximado (rede neurais artificiais (RNA)) ou híbrido.
- Número de resultados solicitados: valores mais altos aumentam o tempo de recuperação.
- Tipo de incorporação: gerenciamento ou autogerenciamento.
- Carga de consultas: 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 de pesquisa e a taxa de transferência de consultas em implementações reais.
Selecione o SKU correto
Mosaic AI Vector Search oferece duas SKUs, cada uma projetada para equilibrar latência, escalabilidade e custo-benefício, dependendo da carga de trabalho. Escolher o SKU correto para sua aplicação é o primeiro passo para otimizar o desempenho.
Em geral:
- Escolha o endpoint padrão quando a latência for crítica e seu índice tiver bem menos de 320 milhões de vetores.
- Escolha um 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 busca vetorial (VSU) |
|---|---|---|---|---|
Standard | 20–50 ms | 30–200+ | 320 milhões de vetores | 2M vetores |
Otimizado para armazenamento | 300–500 ms | 30–50 | Vetores 1B | 64 milhões de vetores |
Compreender o tamanho do índice
O desempenho é máximo quando o índice cabe em uma única unidade de busca vetorial, com espaço extra para lidar com cargas adicionais de consultas. À medida que as cargas de trabalho aumentam além de uma única unidade de busca vetorial (ou seja, mais de 2 milhões de vetores para a versão padrão ou mais de 64 milhões para a versão otimizada para armazenamento), a latência aumenta e o número de consultas por segundo (QPS) diminui. Eventualmente, o QPS estabiliza em aproximadamente 30 QPS (rede neurais artificiais (ANN)).
O desempenho depende de muitos fatores específicos de cada carga de trabalho, como padrões de consulta, filtros, dimensionalidade do vetor e concorrência. Os números a seguir são pontos de referência.
sku | Vetores | Dimensão | Latência | QPS | Consultas mensais |
|---|---|---|---|---|---|
Standard | 10 mil | 768 | 20ms | Mais de 200 | 500 milhões+ |
10 milhões | 768 | 40ms | 30 | 78M | |
100M | 768 | 50ms | 30 | 78M | |
Otimizado para armazenamento | 10 milhões | 768 | 300ms | 50 | 130M |
100M | 768 | 400ms | 40 | 100M | |
1B | 768 | 500ms | 30 | 78M |
Minimizar o tamanho de 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 altas proporcionam representações mais expressivas que podem melhorar a qualidade, mas têm um custo 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 (consultas por segundo). Por outro lado, vetores de dimensões superiores aumentam a carga compute e reduzem a taxa de transferência.
Como regra geral, escolha a menor dimensionalidade que preserve a qualidade da recuperação de dados para o seu caso de uso.
Por exemplo, reduzir a dimensionalidade pela metade (digamos, de 768 para 384) normalmente melhora o QPS em cerca de 1,5 vezes e reduz a latência em cerca de 20%, dependendo do tamanho do índice e do padrão de consulta. Esses ganhos se multiplicam ainda mais em dimensionalidades muito baixas. Por exemplo, o uso de vetores de 64 dimensões pode proporcionar um QPS dramaticamente maior e uma latência significativamente menor em comparação com os benchmarks de 768 dimensões mostrados na tabela. Isso torna as dimensões 384 e inferiores especialmente atraentes 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.
Use redes neurais artificiais (RNA) para eficiência e use híbrida quando necessário
Utilize consultas de rede neurais artificiais (RNA) sempre que possível. São os mais eficientes computee suportam o maior número de QPS (questões por segundo).
Utilize a busca híbrida quando necessário. A busca híbrida melhora a recuperação de informações em algumas aplicações, especialmente onde palavras-chave específicas do domínio são importantes. A pesquisa híbrida normalmente usa cerca de duas vezes mais recursos que a rede neural artificial (RNA) e pode reduzir significativamente a Taxa de transferência.
Use 10 a 100 resultados
Cada consulta inclui um parâmetro num_results , que é o número de resultados de pesquisa a serem retornados. Esse valor impacta diretamente o desempenho. Recuperar mais resultados exige uma varredura mais profunda do índice, o que aumenta a latência e reduz as consultas por segundo (QPS). O efeito torna-se mais significativo em valores mais altos. Por exemplo, aumentar num_results em 10 vezes pode dobrar a latência da consulta e reduzir a capacidade de QPS em 3 vezes, dependendo do tamanho e da configuração do índice.
Como boa prática, mantenha num_results no intervalo de 10 a 100, a menos que sua aplicação exija especificamente um valor maior. Experimente diferentes valores num_results usando consultas realistas para entender o impacto na sua carga de trabalho.
Evite a redução da escala para zero na produção.
A Busca Vetorial suporta dois tipos de incorporações com diferentes vantagens e desvantagens em termos de desempenho.
Os embeddings gerenciais são os mais convenientes. Com o gerenciamento de embeddings, Databricks gera embeddings automaticamente tanto para suas linhas quanto para suas consultas. No momento da consulta, o texto da consulta é passado para um endpoint do modelo de serviço para gerar o embedding, o que adiciona latência. Se o modelo de incorporação for externo, ele também introduz uma sobrecarga de rede adicional.
Os embeddings autogerenciados permitem compute embeddings antecipadamente e passar os vetores diretamente no momento da consulta. Isso evita a geração em 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 autogerenciados.
Para casos de uso em produção real, evite pontos finais do modelo que escalam para zero. A inicialização 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 para 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 desencadeiam picos de latência ou erros 429 (Muitas Requisiçõ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 100% da capacidade de QPS, ele começa a retornar erros 429. Se você não configurou o backoff corretamente, o aplicativo pode parar de responder.
Os erros 429 servem como um mecanismo de segurança para proteger o sistema. Eles instruem 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 o SDK Python do Vector Search, que inclui recursos integrados de backoff e repetição de tentativas.
Se você usar a API REST, implemente o backoff exponencial com jitter. Veja esta postagem no blog da AWS.
Usar entidade de serviço com tokens OAuth
Utilize métodos de autenticação eficientes para obter o melhor desempenho. Databricks recomenda o uso de uma entidade de serviço com tokens OAuth em todos os ambientes de produção. access tokens OAuth proporcionam maior segurança e também aproveitam a infraestrutura otimizada para rede, permitindo que o sistema opere em plena capacidade.
Evite usar access tokens pessoal (PATs), pois eles introduzem sobrecarga na rede, adicionam centenas de milissegundos de latência e reduzem significativamente o QPS que seu endpoint pode suportar.
Use o SDK do Python
Utilize a versão mais recente do SDK Python para aproveitar as otimizações integradas de desempenho e confiabilidade.
Reutilize o objeto de índice em todas as consultas. Evite chamar client.get_index(...).similarity_search(...) em todas as solicitações, pois esse padrão adiciona latência desnecessária.
Em vez disso, inicialize o índice uma única vez e reutilize-o:
# Initialize once
index = client.get_index(...)
# Then use it for every query
index.similarity_search(...)
Isso é importante ao usar o índice de pesquisa vetorial em ambientes MLFlow, onde você pode criar o objeto de índice na inicialização do endpoint e reutilizá-lo para cada consulta.
Esta orientação é especialmente útil em aplicações em tempo real e sensíveis à latência. Em configurações RAG com múltiplos índices ou fluxos de autorização em nome do usuário , onde a seleção de índice ou as credenciais estão disponíveis apenas no momento da consulta, inicializar o objeto de índice uma única vez pode não ser viável. Essa otimização não é necessária nesses cenários.
Paralelizar entre os endpoints
A Databricks recomenda explorar as seguintes estratégias para aumentar o número total de QPS (consultas por segundo) no sistema:
- Dividir índices entre os pontos de extremidade. Se você tiver vários índices, cada um recebendo uma parcela significativa do tráfego, hospede-os em endpoints separados para alcançar uma largura de banda total maior.
- Replicar o índice em todos os endpoints. Se a maior parte do tráfego atingir um único índice, duplique-o em vários pontos de extremidade. Divida o tráfego igualmente no nível do cliente para obter ganhos lineares de QPS.