Indicizza set di dati di grandi dimensioni in Azure AI Search

Note

Azure AI Search è disponibile tramite il portale di Azure, le API REST e Azure SDK. È inoltre alla base di Foundry IQ, il livello di conoscenza gestito che trasforma il contenuto aziendale in knowledge base riutilizzabili e con riconoscimento delle autorizzazioni per gli agenti nel portale di Microsoft Foundry.

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 Azure AI Search.

Queste strategie presuppongono la familiarità con i due approcci di base per l'importazione di 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.

Usa un servizio di ricerca creato dopo il 3 aprile 2024 per maggiore spazio di archiviazione per partizione. È anche possibile aggiornare i servizi meno recenti per trarre vantaggio dall'archiviazione di partizione superiore.

Note

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 tramite le API push

Le API push, come l'API REST dell'Indice documenti o il metodo IndexDocuments (Azure SDK per .NET), sono la forma più diffusa di indicizzazione in Azure AI Search. Per le soluzioni che usano un'API push, la strategia per l'indicizzazione a esecuzione prolungata ha 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 le dimensioni dell'intero payload sono inferiori a 16 MB, una richiesta può gestire fino a 1.000 documenti in un'operazione di caricamento in blocco. 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 impiegato 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.

Gestisci 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 il servizio è stato aggiornato di recente, è passato a un piano tariffario superiore o a partizioni aumentate.

  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 è in sovraccarico e al momento la richiesta non può essere elaborata.

    • 207 - Multi-Status. Questo errore indica che alcuni documenti hanno avuto esito positivo, ma almeno uno ha avuto esito negativo.

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

Azure .NET SDK ripete automaticamente le richieste con codice 503 e le altre richieste non riuscite, ma per ripetere le richieste con codice 207 è necessario implementare una logica personalizzata. È anche possibile usare strumenti open source come Polly per implementare una strategia di ripetizione dei tentativi.

Usa gli indicizzatori e le API pull

Gli indicizzatori offrono 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 dei soli 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 entro la finestra di elaborazione, l'indicizzatore riprende dal punto in cui si era interrotto alla successiva esecuzione, a condizione che si usi un'origine dati che supporti 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 Crea indicizzatore, impostare l'argomento batchSize per personalizzare questa impostazione in modo che corrisponda meglio alle caratteristiche dei dati.

Le dimensioni batch predefinite sono specifiche dell'origine dati. Il database SQL di Azure e Azure Cosmos DB hanno dimensioni batch predefinite pari a 1.000. Al contrario, l'indicizzazione di Azure Blob e SharePoint (anteprima) imposta la dimensione del batch su 10 documenti, in considerazione delle dimensioni medie dei documenti più grandi.

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 il rilevamento delle modifiche abilitato, 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. Questo modello è particolarmente importante durante l'esecuzione iniziale o durante l'indicizzazione di contenitori BLOB di grandi dimensioni, in cui la fase di elenco dei BLOB da sola può richiedere più ore o giorni. Durante questo periodo, l'indicizzatore non mostra alcun BLOB in fase di elaborazione, ma a meno che non venga segnalato un errore, è probabile che continui a scorrere l'elenco di BLOB. L'elaborazione e l'arricchimento dei documenti iniziano solo dopo il completamento di questa fase e questo comportamento è previsto.

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

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

Per altre informazioni sull'impostazione delle pianificazioni, vedere Creare un'API REST dell'indicizzatore o vedere Pianificare gli indicizzatori per Azure AI Search.

Note

La finestra di elaborazione massima dipende dal fatto che l'indicizzatore abbia un set di competenze. Gli indicizzatori con set di competenze vengono eseguiti in un ambiente multi-tenant gestito internamente con una durata massima di 2 ore. Gli indicizzatori configurati per utilizzare collegamenti privati condivisi hanno una durata massima di 24 ore. Gli indicizzatori senza set di competenze vengono eseguiti per una durata massima di 24 ore.

Se l'indicizzatore usa un set di competenze con cache di arricchimento, consulta le informazioni seguenti prima di abilitare la cache per carichi di lavoro su larga scala.

Attenzione

Per i carichi di lavoro con competenze a esecuzione prolungata, interruzioni ripetute o errori frequenti, una cache di arricchimento può aumentare il totale di rielaborazione durante l'inserimento o il ripristino iniziale. Una cache di arricchimento non è un backup e non tiene traccia dei documenti che hanno completato l'elaborazione.

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, in modo da popolare 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 elaborati correttamente dell'indicizzatore non sembra aumentare in quel periodo e potrebbe sembrare che non stia facendo progressi, anche se in realtà li sta facendo. Per 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. Passare al servizio di ricerca nel portale di Azure.

  2. 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 che viene eseguiti in parallelo è approssimativamente uguale al numero di unità di ricerca.

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

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

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

  6. Pianificare gli indicizzatori.

  7. 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 particolare 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 di origine dati è destinato agli stessi documenti e campi, tutti i valori della prima esecuzione vengano 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, usare SynapseML per il caricamento e l'indicizzazione dei dati. L'esercitazione include i passaggi per chiamare gli strumenti Foundry per l'arricchimento tramite intelligenza artificiale, ma è anche possibile usare l'API AzureSearchWriter per l'indicizzazione del testo.