Indexation de blobs et de fichiers pour produire plusieurs documents de recherche
S’applique à : Indexeurs de blobs, Indexeurs de fichiers
Par défaut, un indexeur traite le contenu d’un 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 les valeurs de parsingMode pour créer plusieurs documents de recherche à partir d’un seul blob ou fichier. Les valeurs de parsingMode qui donnent lieu à de nombreux documents de recherche comprennent delimitedText (pour CSV) et jsonArray ou jsonLines (pour JSON).
Lorsque vous utilisez l’un de ces modes d’analyse, les nouveaux documents de recherche qui apparaissent doivent avoir des clés de document uniques, et un problème se pose pour déterminer l’origine de cette valeur. Le blob parent a au moins une valeur unique sous la forme de la propriété metadata_storage_path property, mais s’il contribue à cette valeur pour plus d’un document 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
Chaque document dans un index est identifié de manière unique par une clé de document. 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 blob apparaît sous la forme d’un document de recherche distinct et vous évite d’avoir à créer vous-même ce mappage de champs (normalement, seuls les champs ayant des noms et des types identiques sont automatiquement mappés).
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, la Recherche Azure AI peut générer une clé de document pour chaque entité individuelle extraite d’un blob. La clé générée est nommée AzureSearch_DocumentKey et elle est ajoutée à chaque document de recherche. L’indexeur effectue le suivi des « nombreux documents » créés à partir de chaque blob et peut cibler les mises à jour de l’index de recherche lorsque les données sources changent.
Par défaut, en l’absence de mappage explicite pour le champ d’index de clé, le champ AzureSearch_DocumentKey est mappé à celui-ci, à l’aide de la fonction de mappage de champs base64Encode.
Exemple
Imaginons une définition d’index avec les champs suivants :
idtemperaturepressuretimestamp
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 parsingMode sur jsonLines (sans spécifier de mappage explicite pour le champ de clé), le mappage suivant est implicitement appliqué.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Cette configuration se traduit par des clés de document désambiguïsées, comme dans l’illustration suivante (ID encodé en base64 raccourci par souci de concision).
| id | température | pressure | timestamp |
|---|---|---|---|
| aHR0 ... YjEuanNvbjsx | 100 | 100 | 2024-02-13T00:00:00Z |
| aHR0 ... YjEuanNvbjsy | 33 | 30 | 2024-02-14T00:00:00Z |
| aHR0 ... YjIuanNvbjsx | 1 | 1 | 2023-01-12T00:00:00Z |
| aHR0 ... YjIuanNvbjsy | 120 | 3 | 2022-05-11T00:00:00Z |
Mappage de champ personnalisé pour le champ de clé d’index
En prenant la même définition d’index que l’exemple précédent, supposons que votre conteneur de blobs comporte des blobs ayant 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"
Quand vous créez un indexeur avec delimitedText parsingMode, il peut sembler naturel de configurer une fonction de mappage pour le champ de clé comme suit :
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Toutefois, ce mappage ne permet pas d’afficher quatre documents dans l’index, car le champ recordid n’est pas unique dans l’ensemble des blobs. Par conséquent, nous vous recommandons d’utiliser le mappage de champs implicite appliqué à partir de la propriété AzureSearch_DocumentKey pour le champ d’index de clé avec les modes d’analyse « un-à-plusieurs ».
Si vous ne souhaitez pas configurer un mappage de champs explicite, assurez-vous que la valeur sourceField est distincte pour chaque entité parmi tous les objets blob.
Remarque
L’approche utilisée par AzureSearch_DocumentKey, visant à assurer l’unicité des entités extraites, est susceptible de changer. Par conséquent, ne vous fiez pas à sa valeur pour les besoins de votre application.
Spécifier le champ de clé d’index dans vos données
En supposant la même définition d’index que l’exemple précédent et que parsingMode est défini sur jsonLines sans spécifier de mappages de champs explicites de sorte que les mappages ressemblent au premier exemple, supposons que votre conteneur d’objets blob possède des objets blob 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"
Notez que chaque document contient le champ id, qui est défini comme le champ key dans l’index. Dans ce cas, même si un document unique AzureSearch_DocumentKey est généré, il ne sera pas utilisé comme « clé » pour le document. Au lieu de cela, la valeur du champ id est mappée au champ key
Comme dans l’exemple précédent, ce mappage ne permet pas d’afficher quatre documents dans l’index, car le champ id n’est pas unique dans l’ensemble des blobs. Dans ce cas, toute entrée json qui spécifie un élément id entraîne une fusion sur le document existant au lieu d’un chargement d’un nouveau document, et l’état de l’index reflète la dernière entrée de lecture avec l’élément spécifié id.
Étapes suivantes
Si vous n’êtes pas déjà familiarisé avec la structure et le workflow de base de l’indexation de blobs, vous devez commencer par consulter Indexation du Stockage Blob Azure avec la Recherche Azure AI. Pour plus d’informations sur les modes d’analyse pour les différents types de contenu blob, consultez les articles suivants.