Indexer des jeux de données volumineux dans Azure AI Recherche

Si vous avez besoin d’indexer des jeux de données volumineux ou complexes dans votre solution de recherche, cet article explore les stratégies pour prendre en charge les processus de longue durée sur Recherche IA Azure.

Ces stratégies supposent une certaine familiarité avec les deux méthodes de base pour importer des données, à savoir l’envoi (push) de données dans un index ou le tirage (pull) de données à partir d’une source de données prise en charge à l’aide d’un indexeur de recherche. Si votre scénario implique un enrichissement par IA à forte intensité de calcul, des indexeurs sont alors nécessaires, en raison de la dépendance de l’ensemble des compétences vis-à-vis des indexeurs.

Cet article vient compléter l’article Conseils pour de meilleures performances qui décrit les bonnes pratiques pour concevoir des index et des requêtes. Un index bien conçu qui inclut uniquement les champs et les attributs dont vous avez besoin est un prérequis important pour une indexation à grande échelle.

Utilisez un service de recherche créé après le 3 avril 2024 pour un stockage supérieur par partition. Vous pouvez également mettre à niveau des services plus anciens pour bénéficier d’un stockage de partition plus élevé.

Indexer les données à l’aide des API Push

Les API Push, telles que l’API REST Documents Index ou la méthode IndexDocuments (Kit SDK Azure pour .NET), constituent la forme d’indexation la plus répandue dans Recherche Azure AI. Pour les solutions qui utilisent une API push, la stratégie d’indexation de longue durée comprend l’un des composants suivants ou les deux :

• Traitement par lot des documents
• Gestion des threads

Traitement par lots de plusieurs documents par demande

Un mécanisme simple pour indexer une grande quantité de données consiste à envoyer plusieurs documents ou enregistrements dans une même demande. Tant que la charge utile entière est inférieure à 16 Mo, une demande peut gérer jusqu’à 1 000 documents dans une opération de chargement en bloc. Ces limites s’appliquent que vous utilisiez l’API REST Documents Index ou la méthode IndexDocuments du Kit de développement logiciel (SDK) .NET. Avec l’utilisation de l’une des API, vous pouvez empaqueter 1 000 documents dans le corps de chaque requête.

Le traitement par lot des documents permet de réduire considérablement le temps nécessaire pour traiter un volume de données important. La détermination de la taille de lot optimale pour vos données est un composant clé de l’optimisation des vitesses d’indexation. Les deux principaux facteurs qui influencent la taille de lot optimale sont les suivants :

• Le schéma de votre index
• La taille de vos données

Étant donné que la taille de lot optimale dépend de votre index et de vos données, la meilleure approche consiste à tester différentes tailles de lot pour déterminer ce qui produit les vitesses d’indexation les plus rapides pour votre scénario. Pour obtenir un exemple de code pour tester les tailles de lot à l’aide du Kit de développement logiciel (SDK) .NET, consultez Tutoriel : optimiser l’indexation avec l’API Push.

Gérer des threads et une stratégie de nouvelle tentative

Les indexeurs ont une gestion de thread intégrée, mais lorsque vous utilisez les API push, votre code d’application doit gérer les threads. Assurez-vous qu’il existe suffisamment de threads pour tirer pleinement profit de la capacité disponible, en particulier si vous avez récemment mis à niveau votre service, basculé vers un niveau tarifaire plus élevé ou augmenté les partitions.

1. Augmentez le nombre de threads simultanés dans votre code client.

2. Au fur et à mesure que les requêtes atteignent le service de recherche, vous risquez de rencontrer des codes d’état HTTP indiquant que la requête n’a pas abouti. Pendant l’indexation, deux codes d’état HTTP courants sont :

   • 503 Service indisponible : cette erreur signifie que le système est surchargé et que votre requête ne peut pas être traitée pour le moment.

   • 207 Multi-état : Cette erreur signifie que certains documents ont réussi, mais qu’au moins un a échoué.

3. Pour gérer les échecs, les requêtes doivent être retentées en utilisant une stratégie de nouvelle tentative avec backoff exponentiel.

Le SDK .NET Azure retente automatiquement les requêtes qui échouent ou qui génèrent une erreur 503, mais vous devez implémenter votre propre logique de nouvelle tentative en cas d’erreurs 207. Des outils open source tels que Polly peuvent également être utilisés pour mettre en œuvre une stratégie de nouvelle tentative.

Utiliser des indexeurs et les API d’extraction

Les indexeurs offrent plusieurs fonctionnalités utiles pour les processus de longue durée :

• Traitement par lot des documents
• Indexation parallèle sur des données partitionnées
• Planification et détection des modifications pour indexer uniquement les nouveaux documents et ceux modifiés au fil du temps

Les planifications d’un indexeur peuvent reprendre le traitement au dernier point d’arrêt connu. Si les données ne sont pas entièrement indexées dans la fenêtre de traitement, l’indexeur récupère partout où il s’est arrêté lors de l’exécution suivante, en supposant que vous utilisez une source de données qui fournit la détection des modifications.

Le partitionnement des données en sources de données individuelles plus petites permet le traitement parallèle. Vous pouvez diviser les données sources, par exemple en plusieurs conteneurs dans Stockage Blob Azure, créer une source de données pour chaque partition, puis exécuter les indexeurs en parallèle en fonction du nombre d’unités de recherche de votre service de recherche.

Vérifier la taille de lot de l’indexeur

Comme avec l’API Push, les indexeurs vous permettent de configurer le nombre d’éléments par lot. Pour les indexeurs basés sur l’API REST Create Indexer, définissez l’argument batchSize pour personnaliser ce paramètre afin de mieux correspondre aux caractéristiques de vos données.

Les tailles de lot par défaut sont spécifiques à la source de données. Azure SQL Database et Azure Cosmos DB ont une taille de lot par défaut de 1 000. En revanche, l’indexation d’Azure Blob et de SharePoint (version préliminaire) définit la taille du lot à 10 documents afin de tenir compte de la taille moyenne des documents plus importante.

Indexeurs planifiés pour les processus de longue durée

La planification des indexeurs est un mécanisme important pour le traitement des grands jeux de données et l’organisation des processus à exécution longue, comme l’analyse d’images dans un pipeline d’enrichissement.

En général, le traitement de l’indexeur s’exécute dans une fenêtre de deux heures. Si la charge de travail d’indexation se mesure en jours plutôt qu’en heures, vous pouvez configurer une planification consécutive et périodique pour démarrer l’indexeur toutes les deux heures. En supposant que le suivi des modifications est activé dans la source de données, l’indexeur reprend le traitement là où il s’est arrêté la dernière fois. À cette cadence, un indexeur peut s’exécuter sur un backlog de documents pendant plusieurs jours jusqu’à ce que tous les documents non traités soient traités. Ce modèle est particulièrement important lors de l'exécution initiale ou lors de l'indexation de conteneurs d'objets blob volumineux, où la phase de liste des objets blob à elle seule peut prendre plusieurs heures ou des jours. Pendant ce temps, l’indexeur n’affiche aucun objet blob en cours de traitement, mais sauf si une erreur est signalée, il est probable qu’il effectue toujours une itération dans la liste des objets blob. Le traitement et l’enrichissement des documents commencent uniquement une fois cette phase terminée, et ce comportement est attendu.

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

Quand il n’y a plus de documents nouveaux ou mis à jour dans la source de données, l’historique d’exécution de l’indexeur signale des documents 0/0 traités et aucun traitement n’est effectué.

Pour plus d’informations sur la définition de planifications, consultez API REST de création d’indexeur ou Planifier des indexeurs pour Azure AI Recherche.

Si votre indexeur utilise un jeu de compétences avec un cache d’enrichissement, consultez les informations suivantes avant d’activer le cache pour des charges de travail à grande échelle.

Exécuter des indexeurs en parallèle

Si vous avez partitionné vos données, vous pouvez créer plusieurs combinaisons indexeur-données-source qui extraient de chaque source de données et écrivent dans le même index de recherche. Étant donné que chaque indexeur est distinct, vous pouvez les exécuter en même temps, de sorte que vous remplissez un index de recherche plus rapidement que si vous les avez exécutés séquentiellement.

Assurez-vous d’avoir une capacité suffisante. Une unité de recherche dans votre service peut exécuter un indexeur à tout moment donné. La création de plusieurs indexeurs est utile uniquement s’ils peuvent s’exécuter en parallèle.

Le nombre de travaux d’indexation qui peuvent s’exécuter simultanément varie selon l’indexation basée sur le texte et les compétences. Pour plus d’informations, consultez Exécution de l’indexeur.

Si votre source de données est un conteneur Stockage Blob Azure ou Azure Data Lake Storage Gen 2, l’énumération d’un grand nombre d’objets blob peut prendre beaucoup de temps (parfois des heures) jusqu’à ce que cette opération soit terminée. Par conséquent, le nombre de documents réussis de votre indexeur ne semble pas augmenter pendant cette période et peut donner l’impression de ne pas progresser, alors qu’en réalité, c’est le cas. Si vous souhaitez que le traitement des documents soit plus rapide pour un grand nombre d’objets blob, envisagez de partitionner vos données dans plusieurs conteneurs et de créer des indexeurs parallèles pointant vers un index unique.

1. Accédez à votre service Search dans le Portail Microsoft Azure.

2. Vérifiez le nombre d’unités de recherche utilisées par votre service de recherche. Sélectionnez Paramètres>Mettre à l’échelle pour afficher le nombre en haut de la page. Le nombre d’indexeurs qui s’exécutent en parallèle est approximativement égal au nombre d’unités de recherche.

3. Partitionnez vos données sources entre plusieurs conteneurs ou dossiers virtuels au sein du même conteneur.

4. Créez plusieurs sources de données, une pour chaque partition, associées à leur propre indexeur.

5. Spécifiez le même index de recherche cible dans chaque indexeur.

6. Planifiez les indexeurs.

7. Vérifiez l’état de l’indexeur et l’historique d’exécution pour confirmer.

Il existe certains risques associés à l’indexation parallèle. Tout d’abord, rappelez-vous que l’indexation ne s’exécute pas en arrière-plan, ce qui augmente la probabilité que les requêtes soient limitées ou supprimées.

Deuxièmement, Azure AI Recherche ne verrouille pas l’index pour les mises à jour. Les écritures simultanées sont gérées en appelant une nouvelle tentative si une écriture particulière ne réussit pas lors de la première tentative, mais vous remarquerez peut-être une augmentation des échecs d’indexation.

Même si plusieurs jeux indexeur-données-source peuvent cibler le même index, gardez à l’esprit qu’une exécution d’indexeur est susceptible de remplacer les valeurs existantes dans l’index. Si un deuxième jeu indexeur-données-source cible les mêmes documents et champs, toutes les valeurs de la première exécution sont remplacées. Les valeurs de champ sont remplacées dans leur entier ; un indexeur ne peut pas fusionner les valeurs de plusieurs exécutions dans le même champ.

Indexer le Big Data sur Spark

Si vous disposez d’une architecture Big Data et que vos données se situent sur un cluster Spark, utilisez SynapseML pour charger et indexer des données. Ce didacticiel comprend des étapes pour appeler Foundry Tools pour l’enrichissement par IA, mais vous pouvez également utiliser l’API AzureSearchWriter pour l’indexation de texte.

Contenu connexe

• Tutoriel : Optimiser l’indexation à l’aide de l’API Push
• Tutoriel : indexer des données volumineuses provenant d'Apache Spark en utilisant SynapseML et la Recherche Azure AI
• Conseils pour améliorer les performances dans Recherche Azure AI
• Analyser les performances dans Recherche Azure AI
• Indexeurs dans Recherche Azure AI
• Superviser l’état et les résultats des indexeurs dans Azure AI Recherche