Condividi tramite

Indicizzare set di dati di grandi dimensioni in Azure AI Search

  • Articolo

Se è necessario indicizzare set di dati complessi o di grandi dimensioni nella soluzione di ricerca, questo articolo illustra le strategie per supportare processi a esecuzione prolungata in Ricerca di intelligenza artificiale di Azure.

Queste strategie presuppongono la familiarità con i due approcci di base per l'importazione dei dati: il push dei dati in un indice o il pull di dati da un'origine dati supportata usando un indicizzatore di ricerca. Se lo scenario prevede un uso intensivo del calcolo l'arricchimento tramite intelligenza artificiale, gli indicizzatori sono necessari, data la dipendenza del set di competenze dagli indicizzatori.

Questo articolo integra Suggerimenti per migliorare le prestazioni, che offre procedure consigliate per la progettazione di indici e query. Un indice ben progettato che include solo i campi e gli attributi necessari è un prerequisito importante per l'indicizzazione su larga scala.

È consigliabile usare un servizio di ricerca più recente, creato dopo il 3 aprile 2024, per uno spazio di archiviazione superiore per ogni partizione.

Nota

Le strategie descritte in questo articolo presuppongono una singola origine dati di grandi dimensioni. Se la soluzione richiede l'indicizzazione da più origini dati, vedere Indicizzare più origini dati in Azure AI Search per un approccio consigliato.

Indicizzare i dati usando le API push

Le API push, ad esempio l'API REST Documents Index o il metodo IndexDocuments (Azure SDK per .NET) sono la forma più diffusa di indicizzazione in Ricerca di intelligenza artificiale di Azure. Per le soluzioni che usano un'API push, la strategia per l'indicizzazione a esecuzione prolungata include uno o entrambi i componenti seguenti:

  • Invio in batch di documenti
  • Gestione dei thread

Eseguire il batch di più documenti per richiesta

Un semplice meccanismo per l'indicizzazione di una grande quantità di dati consiste nell'inviare più documenti o record in un'unica richiesta. Se l'intero payload è inferiore a 16 MB, una richiesta può gestire fino a 1.000 documenti in un'operazione di caricamento bulk. Questi limiti si applicano se si usa l'API REST dell'indice documenti o il metodo IndexDocuments in .NET SDK. Usando entrambe le API, è possibile creare un pacchetto di 1.000 documenti nel corpo di ogni richiesta.

L'invio in batch dei documenti riduce significativamente la quantità di tempo necessario per lavorare tramite un volume di dati di grandi dimensioni. Determinare le dimensioni ottimali dei batch per i dati è fondamentale per ottimizzare la velocità di indicizzazione. I due fattori principali che influiscono sulle dimensioni ottimali dei batch sono i seguenti:

  • Schema dell'indice
  • Dimensioni dei dati

Dato che le dimensioni ottimali dei batch dipendono dall'indice e dai dati, l'approccio migliore consiste nel testare dimensioni di batch diverse per determinare quali garantiscono la velocità di indicizzazione più elevata per lo scenario specifico. Per il codice di esempio per testare le dimensioni dei batch con .NET SDK, vedere Esercitazione: Ottimizzare l'indicizzazione con l'API push.

Gestire i thread e una strategia di ripetizione dei tentativi

Gli indicizzatori hanno una gestione dei thread predefinita, ma quando si usano le API push, il codice dell'applicazione deve gestire i thread. Assicurarsi che siano presenti thread sufficienti per sfruttare appieno la capacità disponibile, soprattutto se sono state aumentate di recente le partizioni o sono state aggiornate a un servizio di ricerca di livello superiore.

  1. Aumentare il numero di thread simultanei nel codice client.

  2. Quando si aumentano le richieste che raggiungono il servizio di ricerca, potrebbero essere visualizzati codici di stato HTTP che indicano che la richiesta non è stata interamente completata. Durante l'indicizzazione, i due codici di stato HTTP comuni sono i seguenti:

    • 503 Servizio non disponibile: questo errore indica che il sistema è sottoposto a un carico elevato e che la richiesta non può essere elaborata in questo momento.

    • 207 Multi-Status: questo errore indica che alcuni documenti hanno avuto esito positivo, ma almeno un errore.

  3. Per gestire gli errori, le richieste dovranno essere ripetute usando una strategia di ripetizione dei tentativi con backoff esponenziale.

Azure .NET SDK ritenta automaticamente 503 e altre richieste non riuscite, ma è necessario implementare la propria logica per riprovare 207. È anche possibile usare strumenti open source come Polly per implementare una strategia di ripetizione dei tentativi.

Usare gli indicizzatori e le API pull

Gli Indicizzatori hanno diverse funzionalità utili per i processi a esecuzione prolungata:

  • Invio in batch di documenti
  • Indicizzazione parallela su dati partizionati
  • Pianificazione e rilevamento delle modifiche per l'indicizzazione solo di documenti nuovi e modificati nel tempo

Le pianificazioni dell'indicizzatore possono riprendere l'elaborazione nell'ultimo punto di arresto noto. Se i dati non vengono indicizzati completamente all'interno della finestra di elaborazione, l'indicizzatore riprende dal punto in cui è stato interrotto durante l'esecuzione successiva, a condizione che si utilizzi un'origine dati che fornisce il rilevamento delle modifiche.

Il partizionamento dei dati in singole origini dati di dimensioni inferiori consente l'elaborazione parallela. È possibile suddividere i dati di origine, ad esempio in più contenitori in Archiviazione BLOB di Azure, creare un'origine dati per ogni partizione e quindi eseguire gli indicizzatori in parallelo, soggetto al numero di unità di ricerca del servizio di ricerca.

Controllare le dimensioni del batch dell'indicizzatore

Come per l'API push, gli indicizzatori consentono di configurare il numero di elementi per batch. Per gli indicizzatori basati sull'API REST di creazione indicizzatore, è possibile impostare l'argomento batchSize per personalizzare questa impostazione in base alle caratteristiche dei dati.

Le dimensioni batch predefinite sono specifiche dell'origine dati. database SQL di Azure e Azure Cosmos DB hanno dimensioni batch predefinite pari a 1.000. Al contrario, l'indicizzazione BLOB di Azure limita le dimensioni dei batch a 10 documenti in considerazione delle dimensioni medie superiori dei documenti.

Pianificare gli indicizzatori per i processi a esecuzione prolungata

La pianificazione dell'indicizzatore è un meccanismo importante per l'elaborazione di set di dati di grandi dimensioni e per gestire processi a esecuzione lenta come l'analisi delle immagini in una pipeline di arricchimento.

In genere, l'elaborazione dell'indicizzatore viene eseguita in un intervallo di due ore. Se il carico di lavoro di indicizzazione richiede giorni anziché ore per il completamento, è possibile inserire l'indicizzatore in una pianificazione ricorrente consecutiva che inizia ogni due ore. Supponendo che l'origine dati abbia abilitato il rilevamento delle modifiche, l'indicizzatore riprende l'elaborazione in cui è stata interrotta l'ultima volta. A questo punto, un indicizzatore può continuare a funzionare tramite un backlog del documento per più giorni fino a quando non vengono elaborati tutti i documenti non elaborati.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Quando nell'origine dati non sono più presenti documenti nuovi o aggiornati, la cronologia di esecuzione dell'indicizzatore segnala i 0/0 documenti elaborati e non viene eseguita alcuna elaborazione.

Per altre informazioni sull'impostazione delle pianificazioni, vedere Creare l'API REST dell'indicizzatore o vedere Pianificare gli indicizzatori per Ricerca di intelligenza artificiale di Azure.

Nota

Alcuni indicizzatori eseguiti in un'architettura di runtime precedente hanno una finestra di elaborazione massima di 24 ore anziché 2 ore. Il limite di due ore è destinato ai processori di contenuto più recenti eseguiti in un ambiente multi-tenant gestito internamente. Quando possibile, Azure AI Search tenta di eseguire l'offload dell'elaborazione dell'indicizzatore e del set di competenze nell'ambiente multi-tenant. Se non è possibile eseguire la migrazione dell'indicizzatore, viene eseguito nell'ambiente privato e può essere eseguito fino a 24 ore. Se si pianifica un indicizzatore che presenta queste caratteristiche, si supponga una finestra di elaborazione di 24 ore.

Eseguire indicizzatori in parallelo

Se si esegue la partizione dei dati, è possibile creare più combinazioni di indicizzatore origine dati che estraggono da ogni origine dati e scrivono nello stesso indice di ricerca. Poiché ogni indicizzatore è distinto, è possibile eseguirli contemporaneamente, popolando un indice di ricerca più rapidamente rispetto a quelli eseguiti in sequenza.

Assicurarsi di avere una capacità sufficiente. Un'unità di ricerca del servizio permette di eseguire un indicizzatore in qualsiasi momento. La creazione di più indicizzatori è utile solo se possono essere eseguiti in parallelo.

Il numero di processi di indicizzazione che possono essere eseguiti simultaneamente varia per l'indicizzazione basata su testo e basata sulle competenze. Per altre informazioni, vedere l’Esecuzione dell'indicizzatore.

Se l'origine dati è un contenitore di Archiviazione BLOB di Azure o Azure Data Lake Storage Gen 2, l'enumerazione di un numero elevato di BLOB può richiedere molto tempo (anche ore) fino al completamento di questa operazione. Di conseguenza, il conteggio dei documenti dell'indicizzatore non sembra aumentare durante tale periodo e potrebbe sembrare che non stia facendo progressi, quando è. Se si desidera velocizzare l'elaborazione dei documenti per un numero elevato di BLOB, è consigliabile partizionare i dati in più contenitori e creare indicizzatori paralleli che puntano a un singolo indice.

  1. Accedere al portale di Azure e controllare il numero di unità di ricerca usate dal servizio di ricerca. Selezionare Impostazioni>Scala per visualizzare il numero nella parte superiore della pagina. Il numero di indicizzatori eseguiti in parallelo è approssimativamente uguale al numero di unità di ricerca.

  2. Partizionare i dati di origine in più contenitori o in più cartelle virtuali all'interno dello stesso contenitore.

  3. Creare più origini dati, una per ogni partizione, abbinata al proprio indicizzatore.

  4. Specificare lo stesso indice di ricerca di destinazione in ogni indicizzatore.

  5. Pianificare gli indicizzatori.

  6. Esaminare lo stato dell'indicizzatore e la cronologia di esecuzione per la conferma.

Esistono alcuni rischi associati all'indicizzazione parallela. Prima di tutto, tenere presente che l'indicizzazione non viene eseguita in background, aumentando la probabilità che le query vengano limitate o eliminate.

In secondo luogo, Azure AI Search non blocca l'indice per gli aggiornamenti. Le scritture simultanee vengono gestite, richiamando un nuovo tentativo se una determinata scrittura non riesce al primo tentativo, ma si potrebbe notare un aumento degli errori di indicizzazione.

Anche se più set di origini dati dell'indicizzatore possono essere destinati allo stesso indice, prestare attenzione alle esecuzioni dell'indicizzatore che possono sovrascrivere i valori esistenti nell'indice. Se un secondo indicizzatore-origine dati è destinato agli stessi documenti e campi, tutti i valori della prima esecuzione vengono sovrascritti. I valori dei campi vengono sostituiti per intero; un indicizzatore non può unire valori da più esecuzioni nello stesso campo.

Indicizzare Big Data in Spark

Se si dispone di un'architettura di Big Data e i dati si trova in un cluster Spark, è consigliabile l’uso di SynapseML per il caricamento e l'indicizzazione dei dati. L'esercitazione include i passaggi per chiamare i servizi di intelligenza artificiale di Azure per l'arricchimento tramite intelligenza artificiale, ma è anche possibile usare l'API AzureSearchWriter per l'indicizzazione del testo.

Contenuto correlato