Résoudre les problèmes liés au stockage et aux différences de métriques dans Recherche AZURE AI

Cet article répond aux questions courantes sur les métriques de stockage qui apparaissent incohérentes dans le portail Azure, les API REST et les kits SDK Azure.

Les valeurs de stockage dans Recherche IA Azure sont collectées régulièrement et peuvent ne pas refléter l’état en temps réel. Par conséquent, les différences à court terme sont attendues dans la plupart des scénarios.

Pour plus d’informations sur la façon dont les métriques sont collectées et signalées, consultez Recherche Azure AI Monitor.

Pourquoi le stockage ne change-t-il pas immédiatement quand je supprime ou mets à jour des documents ?

Lorsque vous supprimez des documents, Recherche Azure AI reconnaît immédiatement la suppression, mais la récupération du stockage physique se produit par le biais d’opérations de fusion en arrière-plan. Le document sous-jacent est marqué comme supprimé et ignoré pendant les requêtes suivantes. À mesure que de nouveaux documents sont indexés et que l’index interne augmente, le système nettoie les documents supprimés et récupère les ressources. Cela signifie que vous êtes susceptible d’observer un décalage entre la suppression de documents et les ressources sous-jacentes libérées.

Les mises à jour de documents ont un effet similaire sur le stockage. Étant donné que les documents sont immuables, une mise à jour est en interne une opération de suppression et d’insertion : l’ancienne version est marquée comme supprimée et une nouvelle version est insérée. Jusqu’à ce que les opérations de fusion en arrière-plan nettoient l’ancienne version, vous pouvez observer que le stockage augmente temporairement plutôt que de rester le même.

Ces opérations de fusion se terminent généralement dans les 24 à 72 heures, selon la quantité de charge sur le service. Si vous êtes proche de la limite de stockage de votre niveau tarifaire, tenez compte de cette augmentation temporaire lorsque vous planifiez des mises à jour à grande échelle ou des remplacements de documents.

Pour plus d’informations, consultez Supprimer des documents dans un index de recherche et surcharge de la suppression ou de la mise à jour de documents dans l’index.

Pourquoi les valeurs du portail et de l’API diffèrent-elles au même moment ?

Le portail Azure et les API REST peuvent signaler des valeurs différentes, car elles ont des cadences d’actualisation différentes. Plus précisément :

• L’onglet Utilisation de la page Vue d’ensemble du portail s’actualise régulièrement, généralement toutes les quelques minutes.
• GET Service Statistics renvoie les compteurs au niveau du service, y compris storageSize, vectorIndexSize, etdocumentCount.
• GET Index Statistics retourne des compteurs spécifiques à chaque index.

Les statistiques au niveau du service et des index sont collectées indépendamment et à différents intervalles. Un instantané d’une surface peut ne pas s’aligner sur un instantané de l’autre s’il n’a pas été capturé en même temps. Ce comportement est normal et n’indique pas de défaut.

Pour plus d’informations sur la surveillance des surfaces, consultez Monitor Recherche Azure AI.

Pourquoi un index reconstruit est-il plus grand qu’un index plus ancien avec du contenu similaire ?

Un index reconstruit peut afficher temporairement un autre profil de stockage, car les opérations de fusion en arrière-plan n’ont pas fini de nettoyer les anciennes versions du document. Selon la charge du service, ces fusions prennent généralement 24 à 72 heures. Pendant cette période, le stockage peut apparaître plus grand que prévu, ce qui est particulièrement important à prendre en compte si vous êtes près de la limite de stockage de votre niveau tarifaire. Planifiez les opérations de reconstruction ou de migration volumineuses pendant les périodes d’activité d’indexation inférieure et surveillez les métriques de stockage jusqu’à ce que les fusions soient terminées.

Même après la fin des opérations de fusion, la taille finale d’un index reconstruit peut différer légèrement de celle de l’original. La taille du stockage d’index n’est pas déterministe et plusieurs facteurs affectent le résultat :

• Modifications de schéma, telles que l’ajout de champs, d’analyseurs ou de configurations vectorielles.
• Ingestion et mise à jour des modèles qui affectent le ratio de documents supprimés.
• Paramètres d’optimisation des vecteurs, tels que la quantisation ou les options de réduction du stockage.

Pour plus d’informations sur les facteurs qui affectent la taille, consultez la taille et les limites de l’index vectoriel et les limites de service dans Recherche Azure AI.

Pourquoi le stockage total ne correspond-il pas à la taille d’index vectoriel ?

storageSize et vectorIndexSize mesurent différentes choses :

• storageSize est l’empreinte disque totale d’un index, y compris le contenu de tous les types de données, tels que le texte, les métadonnées et les vecteurs.
• vectorIndexSize est une limite de la taille d’un index vectoriel chargé en mémoire. Les champs vectoriels qui utilisent l’algorithme KNN exhaustif ne consomment pas le quota d’index vectoriel et signalent zéro pour vectorIndexSize. Pour plus d’informations, consultez La taille et les limites de l’index vector.

Sur le disque, le stockage total consommé par les vecteurs peut être supérieur à la taille d’index vectoriel en mémoire, car Recherche Azure AI stocke plusieurs copies de champs vectoriels à des fins différentes. Pour plus d’informations sur ce que sont ces copies et sur la réduction de la consommation de disque, consultez Éliminer les instances vectorielles facultatives du stockage.

Comment dois-je comparer correctement les métriques ?

Pour déterminer si une différence est réelle ou un artefact de minutage, capturez des valeurs à partir de la même surface dans une fenêtre de temps UTC cohérente :

1. Appelez GET Service Statistics et GET Index Statistics dans la même fenêtre de cinq minutes.
2. Répétez l’échantillonnage sur une cadence fixe, par exemple toutes les 20 à 30 minutes.
3. Comparez au moins trois fenêtres consécutives avant de conclure que les valeurs ne convergent pas.
4. Évaluez storageSize séparément de vectorIndexSize car ils suivent des structures physiques différentes.

Quand une différence est-elle attendue par rapport à un défaut réel ?

La plupart des écarts sont attendus et résolus sans intervention. Si les critères de défaut sont remplis, ouvrez une demande de support avec la preuve décrite dans la section suivante.

Divergence attendue

• Vous avez récemment effectué une indexation intensive, des mises à jour ou des suppressions, et les valeurs sont toujours convergentes.
• Les valeurs du portail et de l’API diffèrent, mais l’écart est réduit entre les exemples répétés.
• storageSize et vectorIndexSize ne correspondent pas, ce qui est par conception parce qu’ils mesurent des choses différentes.

Défaut possible

• L’écart persiste entre au moins trois fenêtres d’échantillonnage alignées pendant une période d’activité d’écriture ou de suppression faible.
• Aucune tendance de convergence n’est visible malgré l’échantillonnage répété.
• Les valeurs signalées entraînent des décisions opérationnelles incorrectes, telles que le déclenchement différé de la mise à l’échelle automatique ou les échecs d’application des quotas.

Que dois-je inclure dans une demande de support ?

Incluez les informations suivantes dans votre demande de support :

• Horodatages UTC pour chaque portail et exemple d’API.
• Réponses JSON brutes de GET Service Statistics et GET Index Statistics.
• Volume approximatif d'ingestion, de mise à jour et de suppression pendant la période d'observation.
• Description de l’impact opérationnel, tel qu’un délai de mise à l’échelle, un bloc de quota ou un rapport de capacité incorrect.

Contenu connexe

• Surveiller Recherche Azure AI
• Taille et limites de l’index vectoriel
• Limites de service de la Recherche Azure AI
• Supprimer des documents dans un index de recherche