Index de recherche dans Recherche Azure AI

2025-06-22

Dans Recherche Ia Azure, un index de recherche est votre contenu pouvant faire l’objet d’une recherche, disponible 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.

Cet article décrit les concepts clés de création et de gestion d’un index de recherche, notamment :

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

Conseil / Astuce

Vous voulez commencer immédiatement ? Consultez Créer un index de recherche.

Schéma d’un index de recherche

Dans 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 est susceptible d’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 ces concepts 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",
  "description" : "Health plan coverage for standard and premium plans for Northwind and Contoso employees."
  "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 embedding 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 telles que la saisie semi-automatique.
Les scoringProfiles sont utilisés pour le réglage 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 émettent des requêtes à partir de différents domaines.
La encryptionKey configure le double chiffrement du contenu sensible dans l’index.
La semantic configure le reclassement sémantique dans le texte intégral et la recherche hybride.
La vectorSearch configure les champs et requêtes vectoriels.

Définitions de 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. Vous voudrez peut-être également des champs pour les données qu’un utilisateur ne voit jamais. Par exemple, il est possible que vous souhaitiez avoir des champs pour des marges bénéficiaires ou des promotions commerciales que vous pouvez utiliser dans un profil de score afin de 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 champs

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

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	Descriptif
« 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 coupure de mots, 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 découvrir 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 »	Permet de définir si le champ peut être retourné dans un résultat de recherche. Cet attribut est utile quand vous voulez utiliser un champ (tel que 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` pour les champs `key`.

Même si vous pouvez ajouter de nouveaux champs à tout moment, les définitions de champ existantes sont verrouillées pendant toute la durée de vie de l’index. C’est pourquoi les développeurs utilisent généralement le Portail Azure pour créer des index simples, tester des idées ou rechercher un paramètre dans les pages du portail. 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 Recherche Azure AI, la structure physique d’un index est en grande partie une implémentation interne. Vous pouvez accéder à son schéma, charger et interroger son contenu, surveiller sa taille et gérer sa capacité. Toutefois, Microsoft gère les structures d’infrastructure et de données physiques stockées avec votre service de recherche.

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

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

Quantité et composition de vos documents.
Les attributs sur des champs individuels.
La configuration de l’index. Plus précisément, 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 ces champs, sauf si vous utilisez l’enrichissement par IA pour fissurer et analyser le contenu pour créer des informations pouvant faire l’objet d’une 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 d’autocomplétion ou de saisie semi-automatique. Lorsque vous incluez un suggesteur, le processus d’indexation crée les structures de données nécessaires pour les correspondances de caractères textuels. Les suggesteurs sont implémentés au niveau du champ. Par conséquent, choisissez uniquement les champs qui sont raisonnables pour l’autocomplétion.

Exemple illustrant les implications de stockage des attributs et des suggesteurs

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 des 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.
Un 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

Il n'existe aucune prise en charge via le portail ou l'API pour déplacer ou copier un index. En règle générale, vous pointez le déploiement de votre application vers un autre service de recherche (en utilisant le même nom d'index) ou vous modifiez le nom pour créer une copie sur votre service de recherche actuel, puis le construisez.

Isolation d’index

Dans Recherche IA Azure, vous utilisez un index à la fois. Toutes les opérations liées à l’index ciblent un seul index. 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 il n’est pas entièrement opérationnel tant que tous les documents ne sont pas indexés. En interne, un index est distribué entre les partitions et s’exécute sur des réplicas. L’index physique est géré en interne. Vous gérez l’index logique.

Un index est disponible en continu et ne peut pas être suspendu ou mis hors connexion. Comme il est conçu pour une opération continue, des mises à jour de son contenu et des ajouts à l’index lui-même se produisent en temps réel. Si une demande coïncide avec une mise à jour de document, les requêtes peuvent retourner temporairement des résultats incomplets.

La continuité des requêtes existe pour les opérations de document, telles que l’actualisation ou la suppression, et pour les modifications qui n’affectent pas la structure ou l’intégrité existantes d’un index, telles que l’ajout de nouveaux champs. Les mises à jour structurelles, telles que la modification de champs existants, sont généralement gérées à l’aide d’un flux de travail de suppression et de reconstruction dans un environnement de développement ou en créant une nouvelle version de l’index sur le service de production.

Pour éviter une reconstruction d’index, certains clients qui effectuent de petites modifications versionnent un champ en créant un nouveau champ qui coexiste avec une version précédente. Au fil du temps, cela conduit à du contenu orphelin par le biais de champs obsolètes et de définitions d’analyseur personnalisées obsolètes, en particulier dans un index de production coûteux à répliquer. Vous pouvez résoudre ces problèmes pendant 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. Les droits d’administrateur sont requis pour ces opérations et disponibles via des clés API d’administration ou un rôle Contributeur de recherche.
`<your-service>.search.windows.net/indexes/<your-index>/docs`	Permet de cibler la collection de 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 via des clés API de requête ou 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 via la création d’un index en utilisant presque n’importe quel exemple ou procédure pas à pas pour 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.