O Que Fazer Quando a Indexação do Qdrant Está Muito Lenta

O Qdrant NÃO constrói índices HNSW imediatamente. Segmentos pequenos usam força bruta até excederem indexing_threshold_kb (padrão: 20 MB). A busca durante esta janela é mais lenta por design, não um bug.

• Entenda o otimizador de indexação Otimizador de Indexação

Uploads/Ingestão Muito Lentos

Use quando: chamadas de API de upload ou upsert estão lentas. Identifique o gargalo: lado do cliente (rede, loteamento) vs. lado do servidor (CPU, E/S de disco)

Para o lado do cliente, otimize o loteamento e o paralelismo:

• Use upserts em lote (64-256 pontos por solicitação) API de Pontos
• Use 2-4 fluxos de upload paralelos

Para o lado do servidor, otimize a configuração do Qdrant e a estratégia de indexação:

• Crie mais shards (3-12), cada shard tem um worker de atualização independente Sharding
• Crie índices de payload antes que os HNSW sejam construídos (necessário para índice vetorial filtrável) Índice de Payload

Adequado para carga inicial em massa de grandes conjuntos de dados:

• Desabilite o HNSW durante a carga em massa (defina indexing_threshold_kb como muito alto, restaure depois) Parâmetros da Coleção
• Definir m=0 para desabilitar HNSW é legado, use um indexing_threshold_kb alto em vez disso

Cuidado, uploads rápidos sem indexação podem usar temporariamente mais RAM e degradar o desempenho da busca até que o otimizador alcance.

Veja https://search.qdrant.tech/md/documentation/tutorials-develop/bulk-upload/

Otimizador Travado ou Demorando Muito

Use quando: o otimizador está rodando por horas, sem terminar.

• Verifique o progresso real através do endpoint de otimizações (v1.17+) Monitoramento de Otimização
• Grandes mesclagens e reconstruções de HNSW levam legitimamente horas em grandes conjuntos de dados
• Verifique a CPU e a E/S de disco (HNSW é limitado por CPU, mesclagem é limitada por E/S, HDD não é viável)
• Se optimizer_status mostrar um erro, verifique os logs por disco cheio ou segmentos corrompidos

Tempo de Construção do HNSW Muito Alto

Use quando: a construção do índice HNSW domina o tempo total de indexação.

• Reduza m (padrão 16, bom para a maioria dos casos, 32+ raramente necessário) Parâmetros HNSW
• Reduza ef_construct (100-200 é suficiente) Configuração HNSW
• Mantenha max_indexing_threads proporcional aos núcleos da CPU Configuração
• Use GPU para indexação Indexação com GPU

Índice HNSW para Coleções Multi-Tenant

Se você tem um caso de uso multi-tenant onde todos os dados são divididos por algum campo de payload (por exemplo, tenant_id), você pode evitar a construção de um índice HNSW global e, em vez disso, confiar em payload_m para construir o índice HNSW apenas para subconjuntos de dados. Pular o índice HNSW global pode reduzir significativamente o tempo de indexação.

Veja Coleções Multi-Tenant para detalhes.

Índices de Payload Adicionais Estão Muito Lentos

O Qdrant constrói links HNSW extras para todos os índices de payload para garantir que a qualidade da busca vetorial filtrada não se degrade. Alguns índices de payload (por exemplo, campos text com textos longos) podem ter um número muito alto de valores únicos por ponto, o que pode levar a um longo tempo de construção do HNSW.

Você pode desabilitar a construção de links HNSW extras para um índice de payload específico e, em vez disso, confiar em estratégias ligeiramente mais lentas no tempo de consulta, como ACORN.

Leia mais sobre como desabilitar links HNSW extras na documentação

Leia mais sobre ACORN na documentação

O Que NÃO Fazer

• Não crie índices de payload DEPOIS que o HNSW foi construído (quebra o índice vetorial filtrável)
• Não use m=0 para uploads em massa em uma coleção existente, isso pode descartar o HNSW existente e causar longas reindexações
• Não faça upload de um ponto por vez (o overhead por solicitação domina)