Scegliere l'indice vettoriale corretto per il carico di lavoro in Azure HorizonDB (anteprima)

Azure HorizonDB supporta quattro modalità per eseguire la ricerca di similarità vettoriale: una scansione esatta (flat) e tre indici approssimati per la ricerca del vicino più prossimo (ANN): IVFFlat, HNSW e DiskANN. La scelta giusta dipende dal numero di vettori disponibili, dalla frequenza con cui cambiano, dal richiamo necessario, dalla quantità di memoria che è possibile spendere e dalla frequenza con cui si filtra in base ai metadati.

Per la maggior parte dei carichi di lavoro di intelligenza artificiale di produzione in HorizonDB, DiskANN è l'impostazione predefinita consigliata. È l'indice vettore ad alte prestazioni di Microsoft, ridimensiona da migliaia a miliardi di vettori, supporta fino a 16.000 dimensioni, accetta inserimenti e aggiornamenti sul posto ed è l'unica opzione in HorizonDB che supporta il filtro advanc0, combinando la somiglianza del vettore con i predicati di metadati senza perdere richiamo o latenza. Gli altri tipi di indice rimangono utili per casi specifici (set di dati piccoli o statici, carichi di lavoro solo in memoria), illustrati in questa guida.

Questo articolo offre un singolo punto decisionale in modo da non dover leggere quattro documenti di estensione per rispondere a "quale indice devo usare?". Per l'utilizzo dettagliato, seguire i collegamenti alla fine di ogni sezione.

Differenze tra le quattro opzioni

Tutte e quattro le opzioni restituiscono i vicini più vicini di un vettore di query. Differiscono nel modo in cui effettuano la ricerca:

• Flat (senza indice) - Confronta il vettore di query con ogni riga. Sempre 100% richiamo. I costi aumentano in modo lineare con il numero di righe.
• IVFFlat - Suddivide lo spazio vettoriale in liste durante un'unica fase di addestramento, quindi al momento della query cerca solo nelle liste più vicine. Rapido da creare, indice più piccolo, recall inferiore rispetto agli indici a grafo a parità di velocità.
• HNSW : crea un grafico a più livelli di vettori. Richiamo elevato e bassa latenza nei set di dati in memoria, ma l'indice deve adattarsi alla RAM per ottenere prestazioni ottimali e il limite pgvector è di 2.000 dimensioni.
• DiskANN - indice vettoriale a grafo di Microsoft, progettato per mantenere prestazioni elevate quando la maggior parte dei dati si trova su SSD anziché in RAM. Ridimensiona fino a miliardi di vettori, supporta fino a 16.000 dimensioni, accetta aggiornamenti sul posto ed è l'unica opzione in HorizonDB che supporta filtri avanzati. Impostazione predefinita consigliata per i carichi di lavoro di intelligenza artificiale di produzione in HorizonDB.

Tutti e quattro vengono esposti tramite l'estensione vector (pgvector); DiskANN richiede inoltre l'estensione pg_diskann .

Confronto rapido

Albero delle decisioni

Iniziare in alto e fermarsi alla prima corrispondenza.

1. Hai meno di 100.000 vettori e la latenza non è critica? Utilizzare una scansione completa (senza indice). Si ottengono risultati esatti senza ottimizzazione.
2. Più di 16.000 dimensioni, o è necessario combinare la similarità vettoriale con filtri di metadati mantenendo un recall elevato? Usare DiskANN. È l'unica opzione che supporta entrambi, tramite filtri avanzati in HorizonDB.
3. Il set di dati supererà la RAM, oppure le righe vengono aggiunte continuamente, oppure si prevede che superi ~10M? Usare DiskANN. È progettato per rimanere veloce quando la maggior parte dei vettori vive su SSD.
4. Il set di dati è per lo più statico, entra comodamente in RAM e il recall deve essere elevato? Utilizzare HNSW.
5. Il set di dati è principalmente statico, si adatta alla RAM ed è possibile tollerare un richiamo inferiore in cambio di build molto veloci? Usare IVFFlat.
6. Qualsiasi altra cosa? Il valore predefinito è DiskANN. Si tratta dell'indice consigliato per i nuovi carichi di lavoro HorizonDB su larga scala.

Esempi di dimensioni

Questi esempi illustrano i compromessi. Esegui sempre il benchmark con i tuoi dati, le tue query e il tuo obiettivo di richiamo.

1 milione di vettori, 1.536 dimensioni, per lo più di sola lettura

HNSW o DiskANN funziona. Selezionare HNSW se l'indice si adatta comodamente alla RAM e il set di dati è stabile. Selezionare DiskANN se si prevede che il set di dati continui a crescere o si prevede di eseguire query filtrate.

10 milioni di vettori, 1.536 dimensioni, inserimenti giornalieri

Usare DiskANN con max_neighbors = 64. Non sono necessarie ricompilazioni complete periodiche perché gli aggiornamenti vengono applicati direttamente. Vedere Configurazione consigliata dei parametri.

100 milioni di vettori+, incorporamenti ad alta dimensione (3.072+)

Usare DiskANN. HNSW e IVFFlat non sono validi in questa dimensionalità. Per i parametri esatti, vedere Indicizzazione vettoriale scalabile con DiskANN (anteprima ).

Fino a 100.000 vettori usati come baseline di correttezza

Usa una scansione piana. È il modo più rapido per verificare che un indice ANN restituisca i vicini corretti prima di decidere di adottarne uno.

Filtro avanzato e DiskANN

La maggior parte delle query di recupero in produzione combinano la similarità vettoriale con clausole strutturate WHERE: in base a tenant, categoria, intervallo di date, prezzo, stato o qualsiasi altra colonna di metadati. L'indice selezionato determina se le query filtrate rimangono veloci e accurate.

• IVFFlat e HNSW applicano i predicati dopo che la ricerca ANN ha restituito i candidati. Con un filtro selettivo, la maggior parte dei candidati viene scartata e il recall crolla, costringendo spesso a recuperare più risultati del necessario e a riordinarli nell'applicazione.
• DiskANN supporta il filtro avanzato per Azure HorizonDB (anteprima), che inserisce i predicati dei metadati nell'indice stesso. L'indice continua a percorrere il grafo finché LIMIT non è soddisfatto delle righe che superano il filtro, così da ottenere risultati a bassa latenza e richiamo elevato in una singola query SQL, anche con predicati selettivi su milioni di vettori.

Il filtro avanzato è ciò che rende DiskANN l'indice corretto per applicazioni agentiche, motori di raccomandazione, ricerca di intelligenza artificiale multi-tenant e qualsiasi carico di lavoro di recupero in cui il filtro fa parte della query. Viene eseguito in modo nativo all'interno di HorizonDB accanto ai dati relazionali, in modo da mantenere coerenza transazionale, familiarità con PostgreSQL SQL e un singolo archivio, senza database vettoriali separato o servizio di ricerca esterno. Funziona con pgvector, le integrazioni di Azure AI, la ricerca testuale completa BM25 e il resto dello stack di recupero AI di HorizonDB.

Se le query filtrate fanno parte del carico di lavoro, scegliere DiskANN. Vedere Filtrare la ricerca con filtri avanzati per esempi di query e i parametri di indice che controllano questo comportamento.

Costo di aggiornamento e ricompilazione

• IVFFlat : sottoposto a training su un campione di dati. Il richiamo diminuisce man mano che vengono inserite nuove righe perché le partizioni diventano sbilanciate. Ricostruire periodicamente.
• HNSW - Gli inserimenti vengono applicati al grafo in loco. Non è necessaria alcuna ricostruzione, ma gli inserimenti hanno un costo maggiore rispetto a IVFFlat.
• DiskANN - Gli inserimenti vengono applicati in loco. L'indice supporta anche build parallele e REINDEX CONCURRENTLY per ricostruzioni complete in un'unica operazione.

Per carichi iniziali di grandi dimensioni, compilare l'indice dopo l'inserimento bulk e usare maintenance_work_mem più lavoratori paralleli per velocizzare il tempo di compilazione. Per i set di dati con più di 3 milioni di righe, eseguire anche la build con la clausola TABLESPACE temptablespace. Vedere Velocizzare la compilazione dell'indice.

Eseguire la migrazione tra tipi di indice

È possibile modificare i tipi di indice senza modificare l'applicazione. La query SQL rimane invariata, ma solo l'istruzione CREATE INDEX cambia.

-- Drop the old index
DROP INDEX IF EXISTS demo_embedding_idx;

-- Build the new one (DiskANN shown)
CREATE INDEX demo_embedding_idx
ON demo USING diskann (embedding vector_cosine_ops);

Per evitare una finestra del servizio, usare CREATE INDEX CONCURRENTLY per compilare il nuovo indice, quindi eliminare quello precedente.

Operatori di distanza

Tutte e quattro le opzioni supportano gli stessi operatori di distanza di pgvector. Scegliere l'operatore corrispondente al modello di incorporamento:

• <-> - Distanza euclidea (L2) - vector_l2_ops
• <=> - Distanza coseno - vector_cosine_ops
• <#> - Prodotto interno negativo - vector_ip_ops

L'operatore deve corrispondere alla classe di operatore del metodo di accesso dell'indice. La distanza cosena è l'impostazione predefinita per la maggior parte dei modelli di incorporamento, inclusa la famiglia text-embedding-3-* di Azure OpenAI.

Contenuti correlati

• Implementare la ricerca vettoriale in Azure HorizonDB tramite l'estensione pgvector (Anteprima)
• Indicizzazione vettoriale scalabile con DiskANN (anteprima)
• Optimizzare le prestazioni quando si usa pgvector in Azure HorizonDB (anteprima)