Indexation d’objets blob et de fichiers pour produire plusieurs documents de recherche

S’applique à : indexeurs de blobs, indexeurs de fichiers (aperçu)

Par défaut, un indexeur traite le contenu d’un objet blob ou d’un fichier comme un document de recherche unique. Si vous souhaitez une représentation plus granulaire dans un index de recherche, vous pouvez définir des valeurs parsingMode pour créer plusieurs documents de recherche à partir d’un objet blob ou d’un fichier. Les valeurs parsingMode qui entraînent de nombreux documents de recherche incluent delimitedText (pour CSV), jsonArray ou jsonLines (pour JSON), ou markdown avec le sous-mode oneToMany pour markdown.

Lorsque vous utilisez l’un de ces modes d’analyse, les nouveaux documents de recherche qui émergent doivent avoir des clés de document uniques et un problème survient lors de la détermination de l’origine de cette valeur. L’objet blob parent a au moins une valeur unique sous la forme de metadata_storage_path property, mais s’il contribue cette valeur à plusieurs documents de recherche, la clé n’est plus unique dans l’index.

Pour résoudre ce problème, l’indexeur de blob génère un AzureSearch_DocumentKey qui identifie de façon unique chaque document de recherche enfant créé à partir du blob parent unique. Cet article explique le fonctionnement de cette fonctionnalité.

Clé de document de type un-à-plusieurs

Une clé de document identifie de façon unique chaque document dans un index. Quand aucun mode d’analyse n’est spécifié, et s’il n’y a pas de mappage de champs explicite dans la définition de l’indexeur pour la clé du document de recherche, l’indexeur de blobs mappe automatiquement metadata_storage_path property comme clé de document. Ce mappage par défaut garantit que chaque objet blob apparaît sous la forme d’un document de recherche distinct. Il élimine également la nécessité de créer manuellement ce mappage de champs. Normalement, les champs avec des noms et des types identiques sont les seuls mappés automatiquement.

Dans un scénario de document de recherche un-à-plusieurs, une clé de document implicite basée sur metadata_storage_path property n’est pas possible. Pour contourner ce problème, Recherche IA Azure peut générer une clé de document pour chaque entité individuelle extraite d’un objet blob. Le système génère une clé appelée AzureSearch_DocumentKey et l’ajoute à chaque document de recherche. L’indexeur effectue le suivi des « nombreux documents » créés à partir de chaque objet blob et peut cibler les mises à jour de l’index de recherche lorsque les données sources changent au fil du temps.

Par défaut, lorsqu'aucun mappage de champ explicite pour le champ d'index de clé n'est spécifié, le AzureSearch_DocumentKey est mappé à ce dernier à l'aide de la fonction de mappage de champ base64Encode.

Example

Imaginez une définition de l'index avec les champs suivants :

• id
• temperature
• pressure
• timestamp

Et que votre conteneur d’objets blob a des objets blob avec la structure suivante :

Blob1.json

{ "temperature": 100, "pressure": 100, "timestamp": "2024-02-13T00:00:00Z" }
{ "temperature" : 33, "pressure" : 30, "timestamp": "2024-02-14T00:00:00Z" }

Blob2.json

{ "temperature": 1, "pressure": 1, "timestamp": "2023-01-12T00:00:00Z" }
{ "temperature" : 120, "pressure" : 3, "timestamp": "2022-05-11T00:00:00Z" }

Lorsque vous créez un indexeur et définissez le mode d'analysejsonLines sans spécifier de mappages de champs explicites pour le champ clé, le mappage suivant est appliqué implicitement.

{
    "sourceFieldName" : "AzureSearch_DocumentKey",
    "targetFieldName": "id",
    "mappingFunction": { "name" : "base64Encode" }
}

Cette configuration résulte en des clés de document désambiguïsées, comme illustré ci-après (ID codé en base64 raccourci pour la concision).

Mappage de champ personnalisé pour le champ de clé d’index

En supposant la même définition d’index que l’exemple précédent, supposons que votre conteneur d’objets blob possède des objets blob avec la structure suivante :

Blob1.json

recordid, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z" 
2, 33, 30,"2024-02-14T00:00:00Z" 

Blob2.json

recordid, temperature, pressure, timestamp
1, 1, 1,"20123-01-12T00:00:00Z" 
2, 120, 3,"2022-05-11T00:00:00Z" 

Lorsque vous créez un indexeur avec delimitedTextanalyseMode, il peut sembler naturel de configurer une fonction de mappage de champs sur le champ clé comme suit :

{
    "sourceFieldName" : "recordid",
    "targetFieldName": "id"
}

Toutefois, ce mappage n’entraîne pas l’affichage de quatre documents dans l’index, car le recordid champ n’est pas unique entre les objets blob. Par conséquent, nous vous recommandons d’utiliser le mappage de champs implicite appliqué de la AzureSearch_DocumentKey propriété au champ d’index clé pour les modes d’analyse « un-à-plusieurs ».

Si vous souhaitez configurer un mappage de champ explicite, assurez-vous que le champ source est distinct pour chaque entité individuelle sur tous les objets blob.

Spécifier le champ de clé d’index dans vos données

En supposant que la même définition d’index s'applique comme dans l’exemple précédent et que le mode d’analyse soit défini sur défaut sans spécifier de mappages de champs explicites afin que les mappages ressemblent à ceux dans le premier exemple, supposons que votre conteneur d’objets blob contient des blobs avec la structure suivante :

Blob1.json

id, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z" 
2, 33, 30,"2024-02-14T00:00:00Z"

Blob2.json

id, temperature, pressure, timestamp
1, 1, 1,"2023-01-12T00:00:00Z" 
2, 120, 3,"2022-05-11T00:00:00Z" 

Chaque document contient le id champ, qui est défini comme key champ dans l’index. Dans ce cas, le système génère un champ AzureSearch_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theidfield is mapped to thekey unique.

Comme dans l’exemple précédent, ce mappage n’entraîne pas l’affichage de quatre documents dans l’index, car le id champ n’est pas unique entre les objets blob. Lorsque cette situation se produit, toute entrée JSON qui spécifie une id entraîne une fusion avec le document existant au lieu de charger un nouveau document. L'index reflète l'état le plus récent de l'entrée spécifiée par id.

Limites

Lorsqu’une entrée de document dans l’index est créée à partir d’une ligne d’un fichier, comme expliqué dans cet article, la suppression de cette ligne du fichier ne supprime pas automatiquement l’entrée correspondante de l’index. Pour supprimer l’entrée de document, vous devez envoyer manuellement une demande de suppression à l’index à l’aide de l’opération de suppression de l’API REST.

Étapes suivantes

Si vous ne connaissez pas encore la structure de base et le flux de travail de l’indexation d’objets blob, il est conseillé de consulter d'abord Indexing Stockage Blob Azure with Recherche Azure AI. Pour plus d’informations sur les modes de parsing pour différents types de contenu blob, consultez les articles suivants.