Diagnostique um problema

Existem várias razões possíveis para a degradação do desempenho da busca. As mais comuns são:

• Pressão de memória: se o conjunto de trabalho exceder a RAM disponível
• Requisições complexas (por exemplo, hnsw_ef alta, filtros complexos sem índice de payload)
• Processos em segundo plano competindo (por exemplo, otimizador ainda em execução após upload em massa)
• Problema com o cluster (por exemplo, problemas de rede, degradação de hardware)

Consulta Única Muito Lenta (Latência)

Use quando: consultas individuais levam muito tempo, independentemente da carga.

Passos de diagnóstico:

• Verifique se a segunda execução da mesma requisição é significativamente mais rápida (indica pressão de memória)
• Tente a mesma consulta com with_payload: false e with_vectors: false para ver se a recuperação de payload é o gargalo
• Se a requisição usa filtros, tente removê-los um por um para identificar se uma condição de filtro específica é o gargalo

Correções comuns:

• Ajuste os parâmetros HNSW: Ajuste fino da busca
• Habilite a quantização em memória: Quantização escalar
• Reduza a Dimensionalidade do Vetor com Modelos Matryoshka: Modelos Matryoshka
• Use oversampling + rescore para vetores de alta dimensão Busca com quantização
• Habilite io_uring para cargas de trabalho intensivas em disco no Linux io_uring

Não Consegue Lidar com QPS Suficiente (Throughput)

Use quando: o sistema não consegue atender a consultas suficientes por segundo sob carga.

• Reduza a contagem de segmentos (default_segment_number para 2) Maximizando o throughput
• Use a API de busca em lote em vez de consultas únicas Busca em lote
• Habilite a quantização para reduzir o custo de CPU Quantização escalar
• Adicione réplicas para distribuir a carga de leitura Replicação

Busca Filtrada é Lenta

Use quando: a busca filtrada é significativamente mais lenta que a não filtrada. A reclamação mais comum do SA após a memória.

• Crie um índice de payload no campo filtrado Índice de payload
• Use is_tenant=true para a condição de filtro primária: Índice de tenant
• Tente o algoritmo ACORN para filtros complexos: ACORN
• Evite usar condições de filtro nested como filtro primário. Isso pode forçar o qdrant a ler valores brutos de payload em vez de usar o índice.
• Se o índice de payload foi adicionado após a construção do HNSW, acione um reindex para criar links de subgrafo filtráveis

Otimize o desempenho da busca com atualizações paralelas

Passos de diagnóstico

• Tente executar a mesma consulta com o parâmetro indexed_only=true, se a consulta for significativamente mais rápida, isso significa que o otimizador ainda está em execução e ainda não indexou todos os segmentos.
• Se o uso de CPU ou IO estiver alto mesmo sem consultas, isso também indica que o otimizador ainda está em execução.

Mudanças de configuração recomendadas

• reduza optimizer_cpu_budget para reservar mais CPU para consultas
• Use prevent_unoptimized=true para evitar a criação de segmentos com uma grande quantidade de dados não indexados para buscas. Em vez disso, uma vez que um segmento atinge o chamado "indexing_threshold", todos os pontos adicionais serão adicionados em "estado adiado".

Saiba mais aqui

O Que NÃO Fazer

• Defina always_ram=false na quantização (disk thrashing em cada busca)
• Coloque HNSW em disco para produção sensível à latência (apenas para armazenamento frio)
• Aumente a contagem de segmentos para throughput (o oposto: menos = melhor)
• Crie índices de payload em todos os campos (desperdiça memória)
• Culpe o Qdrant antes de verificar o status do otimizador