Indicizzare set di dati di grandi dimensioni in Ricerca di intelligenza artificiale di Azure
Se i requisiti della soluzione di ricerca includono l'indicizzazione di Big Data o dati complessi, questo articolo descrive le strategie per soddisfare i processi a esecuzione prolungata in Ricerca di intelligenza artificiale di Azure.
Questo articolo presuppone 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 tramite un indicizzatore di ricerca. Se lo scenario prevede un arricchimento intensivo dell'intelligenza artificiale a livello di calcolo, gli indicizzatori sono necessari, data la dipendenza del set di competenze dagli indicizzatori.
Questo articolo integra Suggerimenti per ottenere prestazioni migliori, 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 una risorsa di archiviazione superiore per 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 Ricerca di intelligenza artificiale di Azure per un approccio consigliato.
Indicizzare dati di grandi dimensioni usando le API push
Le API "push", ad esempio l'API REST Dell'indice documenti 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 avrà 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 una singola richiesta. Se le dimensioni dell'intero payload sono inferiori a 16 MB, una richiesta può gestire fino a 1000 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. Per entrambe le API è necessario creare un pacchetto di 1000 documenti nel corpo di ogni richiesta.
L'invio in batch dei documenti ridurrà 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
Poiché le dimensioni ottimali del batch dipendono dall'indice e dai dati, l'approccio migliore consiste nel testare dimensioni di batch diverse per determinare quali risultati sono le velocità di indicizzazione più veloci per lo scenario. Esercitazione: Ottimizzare l'indicizzazione con l'API push fornisce codice di esempio per testare le dimensioni dei batch usando .NET SDK.
Aggiungere 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 dovrà 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.
Aumentare il numero di thread simultanei nel codice client.
Man mano che si aumentano le richieste che raggiunge il servizio di ricerca, è possibile che vengano visualizzati codici di stato HTTP che indicano che la richiesta non ha avuto esito positivo. 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.
Per gestire gli errori, è necessario ritentare le richieste usando una strategia di ripetizione dei tentativi di backoff esponenziale.
Azure .NET SDK ritenta automaticamente 503 e altre richieste non riuscite, ma è necessario implementare la propria logica per riprovare a 207. È anche possibile usare strumenti open source come Polly per implementare una strategia di ripetizione dei tentativi.
Indicizzare con indicizzatori e 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 di documenti appena nuovi e modificati nel tempo
Le pianificazioni dell'indicizzatore possono riprendere l'elaborazione nell'ultimo punto di arresto noto. Se i dati non sono completamente indicizzati all'interno della finestra di elaborazione, l'indicizzatore viene prelevato ovunque sia stato interrotto durante l'esecuzione successiva, presupponendo che si stia usando 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, in base 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 1000. Al contrario, l'indicizzazione BLOB di Azure imposta le dimensioni batch a 10 documenti in riconoscimento delle dimensioni medie del documento maggiori.
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 2 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 riprenderà l'elaborazione in cui è stata interrotta l'ultima volta. A questo punto, un indicizzatore può eseguire il backlog di un documento in una serie di 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 non sono più presenti documenti nuovi o aggiornati nell'origine dati, la cronologia di esecuzione dell'indicizzatore segnala 0/0 i documenti elaborati e non viene eseguita alcuna elaborazione.
Per altre informazioni sull'impostazione delle pianificazioni, vedere Creare l'API REST dell'indicizzatore o vedere Come 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 2 ore è destinato ai processori di contenuto più recenti eseguiti in un ambiente multi-tenant gestito internamente. Quando possibile, Ricerca intelligenza artificiale di Azure 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, verrà eseguito nell'ambiente privato e può essere eseguito per un periodo di 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 partiziona i 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 Esecuzione dell'indicizzatore.
Se l'origine dati è un contenitore Archiviazione BLOB di Azure o Azure Data Lake Archiviazione Gen 2, l'enumerazione di un numero elevato di BLOB può richiedere molto tempo (anche ore) fino al completamento di questa operazione. Ciò causerà che il conteggio dei documenti dell'indicizzatore non viene aumentato durante tale periodo e potrebbe sembrare che non stia facendo progressi, quando è. Se si vuole 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.
Accedere al portale di Azure e controllare il numero di unità di ricerca usate dal servizio di ricerca. Selezionare Impostazioni> Scale per visualizzare il numero nella parte superiore della pagina. Il numero di indicizzatori che verranno eseguiti in parallelo è approssimativamente uguale al numero di unità di ricerca.
Partizionare i dati dell'origine tra più contenitori o più cartelle virtuali all'interno dello stesso contenitore.
Creare più origini dati, una per ogni partizione, abbinata al proprio indicizzatore.
Specificare lo stesso indice di ricerca di destinazione in ogni indicizzatore.
Pianificare gli indicizzatori.
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, Ricerca intelligenza artificiale di Azure 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-origine dati è destinato agli stessi documenti e campi, tutti i valori della prima esecuzione verranno sovrascritti. I valori dei campi vengono sostituiti in pieno; 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 usare 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.