Guia de Desempenho da Pesquisa de AI

A Busca de AI é desenvolvida para recuperação rápida e escalável. O desempenho do AI Search 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 o aplicativo lida com picos de tráfego. A maioria das cargas de trabalho tem um bom desempenho logo de início, mas para situações em que seja necessário escalar ou otimizar a latência, este guia apresenta dicas práticas e padrões comuns para ajudar a configurar seu sistema para desempenho ideal.

Fatores que afetam o desempenho

Desempenho não é um número único — é uma faixa que depende das características da carga de trabalho, das escolhas de configuração, e da implementação do cliente. Este guia foi elaborado para ajudar a construir um modelo mental claro de como o desempenho funciona, para que a Pesquisa de AI possa ser usada da forma mais eficaz.

Os seguintes são os principais fatores que influenciam como o sistema se comporta:

• Escolha da SKU: padrão ou otimizada para armazenamento.
• Tamanho do índice: número de vetores armazenados.
• Tamanho de incorporação: geralmente 384–1536.
• Tipo de consulta: vizinho mais próximo aproximado (rede neurais artificiais (ANN)) ou híbrida.
• Número de resultados solicitados: valores mais altos aumentam o tempo de obtenção.
• Tipo de incorporação: gerenciada ou autogerenciada.
• Carga de consulta: quanto tráfego 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 implantações do mundo real.

Escolha o SKU certo

A Pesquisa de IA oferece duas SKUs, cada uma projetada para equilibrar latência, escalabilidade e eficiência de custos dependendo da carga de trabalho. Escolher a SKU certa para a sua aplicação é a primeira alavanca para o ajuste de desempenho.

Em geral:

• Escolha endpoints padrão quando a latência for crítica e seu índice estiver bem abaixo de 320 milhões de vetores.
• Escolha endpoints otimizados para armazenamento ao trabalhar com mais de 10 milhões de vetores, conseguir tolerar alguma latência extra e precisar de melhor custo-benefício por vetor (até 7x mais barato).

A tabela a seguir mostra algumas diretrizes de desempenho esperadas.

sku	Latência	QPS	Capacidade de endpoint	Tamanho da unidade do Vector Search (VSU)
Standard	20–50 ms	30–200+	320 milhões de vetores	2 milhões de vetores
Armazenamento otimizado	300–500 ms	30–50	Vetores de 1 bilhão	64 milhões de vetores

Compreender o tamanho do índice

O desempenho é máximo quando seu índice se encaixa em uma única unidade de pesquisa vetorial, com espaço adicional para lidar com carga de queries adicional. À medida que as cargas de trabalho escalam além de uma única unidade de pesquisa vetorial (ou seja, 2M+ vetores para o padrão ou 64M+ para otimizado para armazenamento), a latência aumenta e o QPS diminui. Por fim, o QPS estabiliza em aproximadamente 30 QPS (rede neurais artificiais (ANN)).

O desempenho depende de muitos fatores exclusivos de cada carga de trabalho, como padrões de consulta, filtros, dimensionalidade do vetor e simultaneidade. Os seguintes números são pontos de referência.

sku	Vetores	Dimensão	Latência	QPS	Consultas mensais
Standard	10.000	768	20 ms	Mais de 200	500 milhões+
	10 milhões	768	40 ms	30	78 milhões
	100 milhões	768	50 ms	30	78 milhões
Armazenamento otimizado	10 milhões	768	300 ms	50	130 milhões
	100 milhões	768	400ms	40	100 milhões
	1B	768	500 ms	30	78 milhões

Minimizar o tamanho das incorporações

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

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

Por exemplo, reduzir a dimensionalidade em um fator de dois (ou seja, de 768 para 384) geralmente 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 se acumulam ainda mais em dimensionalidades muito baixas. Por exemplo, o uso de vetores de 64 dimensões pode oferecer um QPS significativamente maior e uma latência consideravelmente menor em comparação com os benchmarks de 768 dimensões mostrados na tabela. Isso torna 384 dimensões e abaixo especialmente atraentes para casos de uso de alta taxa de transferência e sensíveis à latência, desde que a qualidade de recuperação permaneça aceitável.

Use as redes neurais artificiais (ANN) para eficiência e use o híbrido quando necessário.

Utilize consultas de rede neurais artificiais (ANN) sempre que possível. Eles são os mais eficientes no uso de compute e suportam o maior QPS.

Use a pesquisa híbrida se necessário. A pesquisa híbrida melhora a abrangência em algumas aplicações, especialmente onde palavras-chave específicas de domínio são importantes. A busca híbrida geralmente utiliza cerca do dobro de recursos do que a rede neural artificial (ANN) e pode reduzir significativamente a Taxa de transferência.

Use 10–100 resultados

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

Como prática recomendada, recomenda-se manter num_results no intervalo de 10–100, a menos que seu aplicativo exija especificamente mais. Experimente diferentes valores de num_results usando consultas realistas para entender o impacto na sua carga de trabalho.

Evite a escala para zero para produção

O AI Search é compatível com dois tipos de embeddings com diferentes compensações de desempenho.

Incorporações gerenciadas são as mais convenientes. Com incorporações gerenciadas, o Databricks gera automaticamente incorporações para suas linhas e queries. No momento da consulta, o texto da consulta é passado para um endpoint de servindo modelo para a geração da inserção, o que adiciona latência. Se o modelo de incorporação for externo, também introduz uma sobrecarga de rede adicional.

Incorporações autogerenciadas possibilitam computar vetores de incorporação 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 incorporações autogerenciadas.

Para casos de uso de produção em tempo real, evite endpoints de modelo que dimensionam para zero. Inicializações a frio podem atrasar respostas por vários minutos ou até mesmo causar falhas se o endpoint estiver inativo quando uma consulta chega.

Plano para picos de query

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 (excesso de solicitações).

A latência se mantém baixa quando a carga é moderada, e aumenta gradualmente à medida que se aproxima da capacidade QPS máxima. Quando o sistema atinge 100% da capacidade de QPS, ele começa a retornar erros 429. Caso o recuo adequado não tenha sido configurado, o aplicativo poderá parar de responder.

Os erros 429 funcionam como um mecanismo de segurança para proteger o sistema. Orienta-se o cliente a aguardar e tentar novamente mais tarde, para que o endpoint se mantenha íntegro e responsivo, mesmo diante de picos de tráfego súbitos.

Como uma melhor prática, use o AI Search Python SDK, que inclui tratamento integrado de backoff e repetição.

Se você usar a API REST, implemente o backoff exponencial com jitter.

Usar entidades de serviço com tokens OAuth

Utilize métodos de autenticação eficientes para o melhor desempenho. O Databricks recomenda usar uma entidade de serviço com token OAuth em todos os ambientes de produção. Tokens de acesso OAuth oferecem maior segurança e também aproveitam a infraestrutura otimizada para rede para permitir que o sistema opere com capacidade total.

O uso de tokens de acesso pessoal (PATs) deve ser evitado, pois eles introduzem sobrecarga de rede, adicionam centenas de milissegundos de latência e reduzem significativamente o QPS que seu endpoint pode sustentar.

Use o SDK do Python

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

Reutilize o objeto de índice em diversas consultas. Evite fazer chamadas para client.get_index(...).similarity_search(...) em cada solicitação, já que este 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 usar o Índice de Pesquisa de AI em ambientes MLFlow, onde é possível criar o objeto de índice na inicialização do endpoint e então reutilizá-lo para cada consulta.

Esta orientação é especialmente útil em aplicações em tempo real, 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 credenciais só estão disponíveis 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.

Escalar a taxa de transferência do endpoint com alta QPS

info

Visualização

Esse recurso está em Prévia Pública.

Por default, endpoints padrão suportam 20–200 QPS dependendo do tamanho do índice. Aplicações em tempo real, como barras de pesquisa, sistemas de recomendação e correspondência de entidades, frequentemente exigem 100 a 1.000+ QPS. Somente em endpoints padrão, é possível definir um QPS alvo. O Databricks provisiona a infraestrutura para melhor corresponder a esse nível de taxa de transferência (melhor esforço, não garantido) quando os índices são criados ou sincronizados.

Usar alta QPS quando:

• Seu aplicativo requer mais de 50 QPS de taxa de transferência sustentada.
• Você recebe erros 429 (excesso de solicitações) sob carga normal.
• A latência é comprometida com o aumento do tráfego, mesmo quando a utilização média aparenta ser baixa.

Você pode definir um QPS de destino usando a IU do Databricks, o SDK ou a API REST. Ver Escalar a taxa de transferência do endpoint com alta QPS.

Paralelize entre endpoints

Se QPS alta não estiver disponível em seu workspace, ou se você precisar de taxa de transferência extremamente alta além de um único endpoint, a Databricks recomenda as seguintes estratégias:

• Dividir índices entre endpoints. Se você tiver vários índices, cada um dos quais recebe uma porção significativa de tráfego, hospede-os em endpoints separados para atingir uma largura de banda total mais alta.
• Replique o índice entre endpoints. Se a maior parte do tráfego atingir um único índice, duplique-o em vários endpoints e divida o tráfego uniformemente no nível do cliente para ganhos lineares de QPS.

Use testes de carga para garantir que os endpoints estejam dimensionados corretamente

Um teste de carga mede o desempenho do seu endpoint de Pesquisa de AI sob diferentes níveis de tráfego, simulando o uso no mundo real e ajudando a dimensionar seu endpoint corretamente para atender aos seus requisitos de produção. Consulte Como configurar um teste de carga para endpoints de Pesquisa de IA para obter detalhes sobre como criar e executar um teste de carga.