Normalisation du texte pour le filtrage, les facettes et le tri sans prise en compte de la casse

Article
12/10/2024

Important

Cette fonctionnalité est en préversion publique sous les conditions d’utilisation supplémentaires. L’API REST en préversion prend en charge cette fonctionnalité.

Dans la recherche cognitive Azure, un normalisateur est un composant qui pré-traite le texte pour la correspondance de mots clés sur les champs marqués comme « filtrable », « à choix multiples » ou « triable ». Contrairement aux champs « pouvant faire l’objet d’une recherche » en texte intégral associés à des analyseurs de texte, le contenu créé pour les opérations de filtre, facettes et tri ne subit pas d’analyse ou de segmentation du texte en unités lexicales. L’omission de l’analyse de texte peut produire des résultats inattendus lorsque des différences de casse et de caractères apparaissent. C’est pourquoi vous avez besoin d’un normaliseur pour homogénéiser les variations dans votre contenu.

En appliquant un normaliseur, vous pouvez obtenir des transformations de texte légères qui améliorent les résultats :

Casse cohérente (par exemple, tout en minuscules ou en majuscules)
Normalisent les accents et les signes diacritiques tels que ö ou ê en caractères ASCII équivalents, « o » et « e » dans notre exemple
Mappent des caractères tels que - et les espaces blancs en un caractère spécifié par l’utilisateur

Avantages des normaliseurs

La recherche et la récupération de documents à partir d’un index de recherche requiert la mise en correspondance de l’entrée de requête avec le contenu du document. La correspondance est soit sur le contenu segmenté, comme c’est le cas lorsque vous appelez la « recherche », ou sur du contenu non segmenté si la requête est une opération filter, facet ou orderby.

Étant donné que le contenu non segmenté n’est pas non plus analysé, les petites différences dans le contenu sont évaluées comme des valeurs distinctes. Penchez-vous sur les exemples suivants :

$filter=City eq 'Las Vegas' retourne uniquement les documents qui contiennent le texte exact "Las Vegas" et exclut les documents avec "LAS VEGAS" et "las vegas", ce qui n’est pas approprié lorsque le cas d’usage nécessite tous les documents, indépendamment de la casse.
search=*&facet=City,count:5 retournera "Las Vegas", "LAS VEGAS" et "las vegas" comme valeurs distinctes en dépit d’être la même ville.
search=usa&$orderby=City renverra les villes dans l’ordre lexicographique : "Las Vegas", "Seattle", "las vegas", même si l’intention est de classer les mêmes villes ensemble, indépendamment de la casse.

Un normaliseur, appelé pendant l’indexation et l’exécution des requêtes, ajoute des transformations légères qui lissent les différences mineures dans le texte pour les scénarios de filtre, de facette et de tri. Dans les exemples précédents, les variantes de "Las Vegas" seront traitées selon le normaliseur que vous sélectionnez (par exemple, tout le texte est en minuscules) pour obtenir des résultats plus uniformes.

Comment spécifier un normaliseur

Les normaliseurs sont spécifiés dans une définition d’index, par champ, sur des champs de texte (Edm.String et Collection(Edm.String)) dont au moins une des propriétés « filterable », « sortablee » ou « facetable » est définie sur true. La définition d’un normaliseur est facultative. Elle est null par défaut. Nous recommandons d’évaluer les normaliseurs prédéfinis avant d’en configurer un personnalisé.

Les normaliseurs ne peuvent être spécifiés que lorsque vous ajoutez un nouveau champ à l’index, aussi, si possible, essayez d’évaluer les besoins de normalisation à l’avance et d’affecter des normaliseurs au cours des phases initiales de développement lorsque les index sont encore régulièrement supprimés et recréés.

Lors de la création d’une définition de champ dans l’index, définissez la propriété « normalizer » sur l’un des valeurs suivantes : un normaliseur prédéfini tel que « lowercase », ou un analyseur personnalisé (défini dans le même schéma d’index).
```
"fields": [
 {
   "name": "Description",
   "type": "Edm.String",
   "retrievable": true,
   "searchable": true,
   "filterable": true,
   "analyzer": "en.microsoft",
   "normalizer": "lowercase"
   ...
 }
]
```
Les normaliseurs personnalisés sont définis en premier dans la section « normalizers » de l’index, puis attribués à la définition de champ, comme indiqué à l’étape précédente. Pour plus d’informations, consultez Créer un index et Ajouter des normaliseurs personnalisés.
```
"fields": [
 {
   "name": "Description",
   "type": "Edm.String",
   "retrievable": true,
   "searchable": true,
   "analyzer": null,
   "normalizer": "my_custom_normalizer"
 },
```

Remarque

Pour modifier le normaliseur d’un champ existant, recréez entièrement l’index (vous ne pouvez pas recréer des champs individuels).

Une bonne solution pour les index de production, où la reconstruction d’index est coûteuse, consiste à créer un nouveau champ identique à l’ancien, mais avec la nouvelle normalisation, et de l’utiliser à la place de l’ancien. Utilisez Mettre à jour l’index pour incorporer le nouveau champ et mergeOrUpload pour le remplir. Par la suite, pendant l’opération de maintenance planifiée de l’index, vous pouvez le nettoyer de façon à supprimer les champs obsolètes.

Normaliseurs prédéfinis et personnalisés

La recherche cognitive Azure fournit des normalisateurs intégrés pour les cas d’utilisation courants, avec la possibilité de les personnaliser en fonction des besoins.

Category	Description
Normaliseurs prédéfinis	Fournis prêts à l’emploi et utilisables sans aucune configuration.
Normaliseurs personnalisés ¹	Pour les scénarios avancés. Requiert une configuration définie par l’utilisateur d’une combinaison d’éléments existants, comprenant de filtres de caractères et de jetons.

⁽¹⁾ Les normaliseurs personnalisés ne spécifient pas de générateurs de jetons, car les normaliseurs produisent toujours un jeton unique.

Référence sur les normaliseurs

Normaliseurs prédéfinis

Nom	Description et options
standard	Met le texte en minuscules, puis applique l’asciifolding.
minuscules	Convertit des caractères en minuscules.
majuscules	Convertit des caractères en majuscules.
asciifolding	Transforme les caractères qui ne sont pas dans le bloc Unicode latin de base en leur équivalent ASCII, s’il en existe un. Par exemple, changez `à` en `a`.
elision	Supprime l’élision au début des jetons.

Filtres de caractères pris en charge

Les normaliseurs prennent en charge deux filtres de caractères identiques à leurs équivalents dans les filtres de caractères d’analyseur personnalisé :

Filtres de jetons pris en charge

La liste ci-dessous montre les filtres de jetons pris en charge pour les normaliseurs, et est un sous-ensemble des filtres de jetons globaux utilisés dans des analyseurs personnalisés.

Ajouter des normaliseurs personnalisés

Les normaliseurs personnalisés sont définis dans le schéma d’index. La définition inclut un nom, un type, et un ou plusieurs filtres de caractères et de jetons. Les filtres de caractères et de jetons sont les blocs de construction d’un normaliseur personnalisé, et sont responsables du traitement du texte. Ces filtres sont appliqués de gauche à droite.

Le token_filter_name_1 est le nom d’un filtre de jetons, tandis que char_filter_name_1 et char_filter_name_2 sont les noms des filtres de caractères (voir les tableaux Filtres de jetons pris en charge et Filtres de caractères pris en charge ci-dessous pour les valeurs valides).

"normalizers":(optional)[
   {
      "name":"name of normalizer",
      "@odata.type":"#Microsoft.Azure.Search.CustomNormalizer",
      "charFilters":[
         "char_filter_name_1",
         "char_filter_name_2"
      ],
      "tokenFilters":[
         "token_filter_name_1"
      ]
   }
],
"charFilters":(optional)[
   {
      "name":"char_filter_name_1",
      "@odata.type":"#char_filter_type",
      "option1": "value1",
      "option2": "value2",
      ...
   }
],
"tokenFilters":(optional)[
   {
      "name":"token_filter_name_1",
      "@odata.type":"#token_filter_type",
      "option1": "value1",
      "option2": "value2",
      ...
   }
]

Des normaliseurs personnalisés peuvent être ajoutés lors de la création de l’index ou ultérieurement en en mettant un à jour. L’ajout d’un normaliseur personnalisé à un index existant nécessite que l’indicateur « allowIndexDowntime » soit spécifié dans Index de mise à jour et entraîne l’indisponibilité de l’index pendant quelques secondes.

Exemple de normaliseur personnalisé

L’exemple ci-dessous illustre une définition de normalisation personnalisée avec les filtres de caractères et de jetons correspondants. Les options personnalisées pour les filtres de caractères et de jetons sont spécifiées séparément comme des constructions nommées, puis référencées dans la définition du normaliseur, comme illustré ci-dessous.

Une normalisation personnalisée nommée « my_custom_normalizer » est définie dans la section « normalizers » de la définition d’index.
Le normaliseur est composé de deux filtres de caractères et de trois filtres de jetons : élision, minuscules et filtre d’asciifolding personnalisé « my_asciifolding ».
Le premier filtre de caractères, « map_dash », remplace tous les tirets par des traits de soulignement tandis que le second, « remove_whitespace », supprime toutes les espaces.

  {
     "name":"myindex",
     "fields":[
        {
           "name":"id",
           "type":"Edm.String",
           "key":true,
           "searchable":false,
        },
        {
           "name":"city",
           "type":"Edm.String",
           "filterable": true,
           "facetable": true,
           "normalizer": "my_custom_normalizer"
        }
     ],
     "normalizers":[
        {
           "name":"my_custom_normalizer",
           "@odata.type":"#Microsoft.Azure.Search.CustomNormalizer",
           "charFilters":[
              "map_dash",
              "remove_whitespace"
           ],
           "tokenFilters":[              
              "my_asciifolding",
              "elision",
              "lowercase",
           ]
        }
     ],
     "charFilters":[
        {
           "name":"map_dash",
           "@odata.type":"#Microsoft.Azure.Search.MappingCharFilter",
           "mappings":["-=>_"]
        },
        {
           "name":"remove_whitespace",
           "@odata.type":"#Microsoft.Azure.Search.MappingCharFilter",
           "mappings":["\\u0020=>"]
        }
     ],
     "tokenFilters":[
        {
           "name":"my_asciifolding",
           "@odata.type":"#Microsoft.Azure.Search.AsciiFoldingTokenFilter",
           "preserveOriginal":true
        }
     ]
  }

Partager via