Index de recherche dans la Recherche Azure AI

Article
10/21/2024

Dans la Recherche Azure AI, un index de recherche est un contenu pouvant faire l’objet d’une recherche, accessible au moteur de recherche pour l’indexation, la recherche en texte intégral, la recherche vectorielle, la recherche hybride et les requêtes filtrées. Un index est défini par un schéma et enregistré dans le service de recherche, l’importation des données se faisant dans un deuxième temps. Ce contenu existe dans votre service de recherche, en dehors de vos magasins de données principaux, ce qui est nécessaire pour les temps de réponse en millisecondes attendus dans les applications de recherche modernes. À l’exception des scénarios d’indexation pilotés par l’indexeur, le service de recherche ne se connecte jamais à vos données sources et ne les interroge jamais..

Si vous voulez créer et gérer un index de recherche, cet article vous aidera à comprendre les points suivants :

Contenu (documents et schéma)
Structure de données physiques
Opérations de base

Vous préférez être pratique immédiatement ? Consultez Créer un index de recherche à la place.

Schéma d’un index de recherche

Dans la recherche Azure AI, les index contiennent des documents de recherche. Conceptuellement, un document correspond à une unité de données pouvant faire l’objet d’une recherche dans un index. Par exemple, un détaillant peut avoir un document pour chaque produit, une université peut avoir un document pour chaque classe, un site de voyage peut avoir un document pour chaque hôtel et destination, etc. Pour comparer avec des éléments de base de données plus familiers, un index de recherche correspond à une table, et les documents équivalent plus ou moins aux lignes d’une table.

Comme l’illustre l’exemple suivant, la structure d’un document est déterminée par le schéma d’index. La collection « fields » correspond généralement à la majeure partie de l’index, dans laquelle chaque champ est nommé, se voit attribuer un type de données et est pourvu de comportements autorisés qui déterminent son utilisation.

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

D’autres éléments sont réduits par souci de concision, mais les liens suivants peuvent fournir davantage d’informations :

les suggesteurs prennent en charge les requêtes d’autocomplétion comme la saisie semi-automatique ;
les scoringProfiles, ou profils de score, sont utilisés pour le paramétrage de la pertinence ;
les analyseurs sont utilisés pour traiter les chaînes en jetons en fonction des règles linguistiques ou d’autres caractéristiques prises en charge par l’analyseur ;
les corsOptions, ou scripts à distance Cross-Origin (CORS), sont utilisés pour les applications qui délivrent des demandes de différents domaines ;
encryptionKey configurer le double chiffrement du contenu sensible dans l’index.
semantic configure le reclassement sémantique dans le texte intégral et la recherche hybride.
vectorSearch configure les champs et requêtes vectoriels.

Définitions des champs

Un document de recherche est défini par la collection « fields » dans le corps de la demande de création d’index. Vous avez besoin de champs pour l’identification du document (clés), le stockage de texte pouvant faire l’objet d’une recherche et la prise en charge des filtres, facettes et tris. Il se peut également que vous ayez besoin de champs pour les données qu’un utilisateur ne voit jamais. Par exemple, il peut être utile de disposer de champs pour des marges bénéficiaires ou des promotions commerciales que vous pouvez utiliser dans un profil de score pour booster un score de recherche.

Si les données entrantes sont hiérarchiques par nature, vous pouvez les représenter dans un index en tant que type complexe, utilisé pour des structures imbriquées. L’exemple de jeu de données intégré, Hotels, illustre des types complexes utilisant une adresse (contenant plusieurs sous-champs) qui entretient une relation un-à-un avec chaque hôtel, et une collection complexe Rooms, où plusieurs chambres sont associées à chaque hôtel.

Attributs de champ

Les attributs d’un champ déterminent son utilisation, par exemple s’il est utilisé dans la recherche en texte intégral, la navigation par facettes, les opérations de tri et ainsi de suite.

Les champs de type chaîne sont souvent marqués avec les attributs « Possibilité de recherche » et « Récupérable ». Vous pouvez utiliser les champs « Triable », « Filtrable » et « À choix multiple » pour affiner les résultats de la recherche.

Attribut	Description
« Possibilité de recherche »	Pouvant faire l’objet d’une recherche vectorielle ou en texte intégral. Les champs de texte sont sujets à une analyse lexicale (p. ex. césure de mots) lors de l’indexation. Si vous définissez un champ avec possibilité de recherche sur une valeur comme « journée ensoleillée », cette valeur est fractionnée au niveau interne en jetons individuels « journée » et « ensoleillée ». Pour en savoir plus, consultez la rubrique Fonctionnement de la recherche en texte intégral.
« Filtrable »	Référencé dans les requêtes $filter. Les champs filtrables de type `Edm.String` ou `Collection(Edm.String)` ne font pas l’objet d’une analyse lexicale, les comparaisons ne concernent donc que les correspondances exactes. Par exemple, si vous définissez un champ avec la valeur « journée ensoleillée », la requête `$filter=f eq 'sunny'` ne renverra aucune correspondance, contrairement à `$filter=f eq 'sunny day'`.
« Triable »	Le système trie les résultats par score par défaut, mais vous pouvez configurer le tri en fonction des champs des documents. Les champs de type `Collection(Edm.String)` ne sont pas « triables ».
« À choix multiple »	Généralement utilisé dans une présentation des résultats de recherche qui inclut un nombre de correspondances par catégorie (par exemple, les hôtels dans une ville spécifique). Cette option ne peut pas être utilisée avec des champs de type `Edm.GeographyPoint`. Les champs de type `Edm.String` qui sont « filtrables », « triables » ou « à choix multiple » ne peuvent pas dépasser 32 Ko de longueur. Pour plus d’informations, consultez l’article Créer un index (API REST).
« Clé »	Identificateur unique des documents dans l’index. Un seul champ doit être choisi comme champ clé et il doit être de type `Edm.String`.
« Récupérable »	Définit si le champ peut être retourné dans un résultat de recherche. Cet attribut est utile quand vous voulez utiliser un champ (comme profit margin) comme mécanisme de filtre, de tri ou de score, mais que vous ne voulez pas qu’il soit visible par l’utilisateur final. Il doit être `true` for `key` .

Même si vous pouvez ajouter de nouveaux champs à tout moment, les définitions de champ existantes sont verrouillées pour toute la durée de vie de l’index. C’est pourquoi les développeurs utilisent généralement le portail pour créer des index simples, tester des idées ou rechercher une définition de paramètre. Il est plus efficace d’effectuer des itérations fréquentes sur la conception d’un index si vous suivez une approche basée sur du code pour reconstruire l’index facilement.

Remarque

Les API que vous utilisez pour créer un index ont différents comportements par défaut. Pour les API REST, la plupart des attributs sont activés par défaut (par exemple, « Possibilité de recherche » et « Récupérable » sont actifs pour les champs de type chaîne) et vous n’avez généralement besoin de les définir que si vous voulez les désactiver. Pour le Kit de développement logiciel (SDK) .NET, l’inverse est vrai. Pour les propriétés que vous ne définissez pas explicitement, l’option par défaut désactive le comportement de recherche correspondante, sauf si vous l’activez de façon spécifique.

Structure et taille physiques

Dans la recherche Azure AI, la structure physique d’un index est en grande partie une implémentation interne. Vous pouvez accéder à son schéma, interroger son contenu, surveiller sa taille et gérer sa capacité, mais les clusters eux-mêmes (index inversés, index vectoriels, partitions, et d’autres fichiers et dossiers) sont gérés en interne par Microsoft.

Vous pouvez surveiller la taille de l’index dans la page gestion de recherche > index dans le portail Azure ou en émettant une requête GET INDEX sur votre service de recherche. Vous pouvez également émettre une demande de statistiques de service et vérifier la valeur de la taille de stockage.

La taille d’un index est déterminée par les éléments suivants :

Quantité et composition de vos documents
Attributs sur des champs individuels
Configuration de l’index (en particulier si vous incluez des suggesteurs)

La composition et la quantité des documents sont déterminées par ce que vous choisissez d’importer. N’oubliez pas qu’un index de recherche ne doit contenir que du contenu pouvant faire l’objet d’une recherche. Si les données sources incluent des champs binaires, omettez-les à moins d’utiliser l’enrichissement par IA pour craquer et analyser le contenu afin de créer des informations de recherche de texte.

Les attributs de champ déterminent les comportements. Pour prendre en charge ces comportements, le processus d’indexation crée les structures de données nécessaires. Par exemple, pour un champ de type Edm.String, « pouvant faire l’objet d’une recherche » appelle la recherche en texte intégral, qui analyse les index inversés pour le terme tokenisé. En revanche, un attribut « filtrable » ou « triable » prend en charge l’itération sur des chaînes non modifiées. L’exemple de la section suivante montre des variations de taille d’index en fonction des attributs sélectionnés.

Les générateurs de suggestions sont des constructions qui prennent en charge les requêtes de type anticipé ou de saisie semi-automatique. Ainsi, lorsque vous incluez un générateur de suggestions, le processus d’indexation crée les structures de données nécessaires pour les correspondances de caractères textuels. Les générateurs de suggestions sont implémentés au niveau du champ. Par conséquent, choisissez uniquement les champs qui sont raisonnables pour le type.

Exemple illustrant les implications de stockage des attributs et des générateurs de suggestions

La capture d’écran suivante illustre les caractéristiques du stockage d’index résultant des différentes combinaisons d’attributs. L’index est basé sur l’exemple d’index de biens immobiliers, que vous pouvez créer facilement à l’aide de l’Assistant Importer des données et les exemples de données intégrés. Bien que les schémas de l’index ne soient pas montrés, vous pouvez en déduire les attributs d’après le nom de l’index. Par exemple, pour l’index realestate-searchable, seul l’attribut « Possibilité de recherche » est sélectionné ; pour l’index realestate-retrievable, seul l’index « Récupérable » est sélectionné, et ainsi de suite.

Bien que ces variantes d’index soient plutôt artificielles, nous pouvons nous y reporter pour nous faire une idée de la façon dont les attributs affectent le stockage :

« retrievable » n’a aucun effet sur la taille de l’index.
« filterable », « sortable » et « facetable » consomment davantage de stockage.
suggester risque fort d’augmenter la taille de l’index, mais pas autant que la capture d’écran ne l’indique (tous les champs susceptibles d’être pris en charge par le suggesteur ont été sélectionnés, ce qui n’est pas un scénario courant avec la plupart des index).

L’effet des analyseurs n’est pas non plus pris en compte dans le tableau précédent. Si vous utilisez le générateur de jetons edgeNgram pour stocker des séquences détaillées de caractères (a, ab, abc, abcd), l’index est plus grand que si vous utilisez l’analyseur standard.

Opérations de base et interaction

Maintenant que vous avez une meilleure idée de ce qu’est un index, cette section présente les opérations d’exécution d’index, notamment la connexion à et la sécurisation d’un index unique.

Remarque

Lors de la gestion d’un index, sachez qu’il n’existe pas de prise en charge de portail ou d’API pour le déplacement ou la copie d’un index. Au lieu de cela, les clients pointent généralement leur solution de déploiement d’applications sur un service de recherche différent (si vous utilisez le même nom d’index), ou modifient le nom pour créer une copie sur le service de recherche actuel, puis le générer.

Isolation d’index

Dans la Recherche Azure AI, vous travaillerez avec un index à la fois, où toutes les opérations liées à l’index ciblent un index unique. Il n’existe aucun concept d’index associé ou de jointure d’index indépendants pour l’indexation et l’interrogation.

Disponible en continu

Un index est immédiatement disponible pour les requêtes dès que le premier document est indexé, mais ne sera pas entièrement opérationnel tant que tous les documents ne seront pas indexés. En interne, un index de recherche est distribué entre les partitions et s’exécute sur des réplicas. L’index physique est géré en interne. L’index logique est géré par vous.

Un index est disponible en continu, sans possibilité de suspension ou de mise hors connexion. Étant donné qu’il est conçu pour une opération continue, les mises à jour de son contenu, ou les ajouts à l’index lui-même, se produisent en temps réel. Par conséquent, les requêtes peuvent retourner temporairement des résultats incomplets si une demande coïncide avec une mise à jour de document.

Notez que la continuité des requêtes existe pour les opérations de document (actualisation ou suppression) et pour les modifications qui n’ont pas d’impact sur la structure et l’intégrité existantes de l’index actuel (comme l’ajout de nouveaux champs). Si vous devez effectuer des mises à jour structurelles (en modifiant des champs existants), elles sont généralement gérées à l’aide d’un flux de travail de suppression et de recréation dans un environnement de développement, ou en créant une nouvelle version de l’index sur le service de production.

Pour éviter une regénération d’index, certains clients qui effectuent de petites modifications choisissent de « créer une version » d’un champ en en créant un qui coexiste avec une version précédente. Au fil du temps, cela se traduit par un contenu orphelin sous la forme de champs obsolètes ou de définitions d’analyseur personnalisé obsolètes, en particulier dans un index de production qui est coûteux à répliquer. Vous pouvez résoudre ces problèmes sur les mises à jour planifiées de l’index dans le cadre de la gestion du cycle de vie des index.

Connexion de point de terminaison et sécurité

Toutes les demandes d’indexation et de requête ciblent un index. Les points de terminaison sont généralement l’un des suivants :

Point de terminaison	Connexion et contrôle d’accès
`<your-service>.search.windows.net/indexes`	Cible la collection d’index. Utilisé lors de la création, de la liste ou de la suppression d’un index. Des droits d’administrateur sont nécessaires pour ces opérations, disponibles par le biais de clés d’API d’administration ou d’un rôle de contributeur de recherche.
`<your-service>.search.windows.net/indexes/<your-index>/docs`	Cible la collection documents d’un index unique. Utilisé lors de l’interrogation d’un index ou de l’actualisation des données. Pour les requêtes, les droits de lecture sont suffisants et disponibles par le biais de clés d’API de requête ou d’un rôle de lecteur de données. Pour l’actualisation des données, des droits d’administrateur sont nécessaires.

Comment se connecter à Recherche Azure AI

Démarrez avec le portail Azure. Les abonnés Azure ou la personne ayant créé le service de recherche, peuvent gérer le service de recherche dans le portail Azure. Un abonnement Azure nécessite des autorisations de Contributeur ou supérieures pour créer ou supprimer des services. Ce niveau d’autorisation suffit pour gérer entièrement un service de recherche dans le portail Azure.
Essayez d’autres clients pour l’accès par programme. Nous vous recommandons les démarrages rapides pour les premières étapes :

Étapes suivantes

Vous pouvez acquérir de l’expérience en créant un index en utilisant presque n’importe quel exemple ou procédure pas à pas pour la recherche Azure AI. Pour commencer, vous pouvez choisir l’un des démarrages rapides à partir de la table des matières.

Mais vous souhaiterez également vous familiariser avec les méthodologies de chargement d’un index avec des données. Les stratégies de définition d’index et d’importation de données sont définies en tandem. Les articles suivants fournissent plus d’informations sur la création et le chargement d’un index.

Partager via