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

Dans Recherche Azure AI, un normalizer est un composant qui prétrait le texte du mot clé correspondant aux champs marqués comme « filtrables », « facetable » ou « triable ». Contrairement aux champs de texte intégral « pouvant faire l’objet d’une recherche » associés à des analyseurs de texte, le contenu créé pour les opérations de filtrage, facettage et tri ne subit pas d'analyse ni de tokenisation. L’absence d’analyse de texte peut produire des résultats inattendus lorsque des différences de casse ou de caractères apparaissent ; un normalisateur est donc nécessaire pour homogénéiser les variations de 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, toutes les minuscules ou majuscules)
• Normaliser les accents et les diacritiques comme ö ou ê aux caractères équivalents ASCII « o » et « e »
• 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 nécessitent la correspondance de l’entrée de requête au contenu du document. La correspondance est sur le contenu tokenisé, comme c’est le cas lorsque vous appelez « search », ou sur du contenu non tokenisé si la requête est un filtre, une facette ou une opération orderby .

Étant donné que le contenu non tokenisé n’est pas non plus analysé, de petites différences dans le contenu sont évaluées comme des valeurs distinctes. Prenons les exemples suivants :

• $filter=City eq 'Las Vegas' ne renverra que les documents contenant strictement le texte "Las Vegas" et exclura ceux contenant "LAS VEGAS" et "las vegas", ce qui demeure insuffisant lorsque le cas d’utilisation exige l’ensemble des documents, indépendamment de la casse.

• search=*&facet=City,count:5 retournera "Las Vegas", "LAS VEGAS" et "las vegas" en tant que valeurs distinctes en dépit d’être la même ville.

• search=usa&$orderby=City retournera les villes dans l’ordre lexicographique : "Las Vegas", "Seattle", , "las vegas"même si l’intention est d’ordonner les mêmes villes ensemble indépendamment du cas.

Un normaliseur, qui est 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" seraient traitées en fonction du normaliseur que vous avez sélectionné (par exemple, tout le texte est minusculisé) pour obtenir des résultats plus uniformes.

Comment spécifier un normaliseur

Les normaliseurs sont spécifiés dans une définition d’index, sur une base par champ, sur les champs de texte (Edm.String et Collection(Edm.String)) qui ont au moins l’une des propriétés « filtrables », « triables » ou « facetable » définies sur true. La définition d’un normaliseur est facultative et a la valeur Null par défaut. Nous vous recommandons d’évaluer les normaliseurs prédéfinis avant de configurer un normaliseur personnalisé.

Les normaliseurs ne peuvent être spécifiés que lorsque vous ajoutez un nouveau champ à l’index. Par conséquent, si possible, essayez d’évaluer les besoins de normalisation avant et d’affecter des normaliseurs dans les phases initiales de développement lors de la suppression et de la recréation d’index est routine.

1. Lors de la création d’une définition de champ dans l’index, définissez la propriété « normalizer » sur l’une des valeurs suivantes : un normaliseur prédéfini tel que « minuscules » ou un normaliseur 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"
      ...
    }
   ]
   

2. Les normaliseurs personnalisés sont définis dans la section « normaliseurs » de l’index en premier, puis affecté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"
    },
   

Une bonne solution de contournement pour les index de production, où la reconstruction des index est coûteuse, consiste à créer un champ identique à l’ancien, mais avec le nouveau normaliseur, et à l’utiliser à la place de l’ancien. Utilisez Update Index pour incorporer le nouveau champ et mergeOrUpload pour le remplir. Plus tard, dans le cadre de la maintenance planifiée des index, vous pouvez nettoyer l’index pour supprimer les champs obsolètes.

Normaliseurs prédéfinis et personnalisés

Recherche Azure AI fournit des normaliseurs intégrés pour les cas d’usage courants, ainsi que la possibilité de personnaliser en fonction des besoins.

^{(1) Les} normaliseurs personnalisés ne spécifient pas d'analyseurs de jetons, car les normaliseurs produisent toujours un seul jeton.

Tester un normaliseur

Vous pouvez utiliser l’analyseur de test (REST) pour voir comment un normaliseur traite une entrée.

Demande

  POST https://[search service name].search.windows.net/indexes/[index name]/analyze?api-version=[api-version]
    Content-Type: application/json
    api-key: [admin key]

  {
     "normalizer":"asciifolding",
     "text": "Vis-à-vis means Opposite"
  }

Réponse

HTTP/1.1 200 OK

{
  "tokens": [
    {
      "token": "Vis-a-vis means Opposite",
      "startOffset": 0,
      "endOffset": 24,
      "position": 0
    }
  ]
}

Informations de référence sur les normaliseurs

Normaliseurs prédéfinis

Filtres char 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és :

• Cartographie
• pattern_replace

Filtres de tokens 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 jeton globaux utilisés dans les analyseurs personnalisés.

• normalisation_arabe
• asciifolding
• cjk_width
• Elision
• normalisation_allemande
• hindi_normalization
• indic_normalization
• persian_normalization
• scandinavian_normalization
• scandinavian_folding
• sorani_normalization
• Minuscules
• Majuscules

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, un ou plusieurs filtres de caractères et des filtres de jetons. Les filtres de caractères et les filtres de jeton sont les blocs de construction d’un normaliseur personnalisé et responsables du traitement du texte. Ces filtres sont appliqués de gauche à droite.

Le token_filter_name_1 est le nom du filtre de jeton, et char_filter_name_1 et char_filter_name_2 sont les noms des filtres de caractère (consultez les tables des filtres de jeton pris en charge et des 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",
      ...
   }
]

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

Exemple de normaliseur personnalisé

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

• Un normaliseur personnalisé nommé « my_custom_normalizer » est défini dans la section « normalizers » de la définition d’index.

• Le normaliseur se compose de deux filtres de caractères et de trois filtres de tokens : élision, minuscules et filtre asciifolding personnalisé « my_asciifolding ».

• Le premier filtre de caractères « map_dash » remplace tous les tirets par des traits de soulignement tandis que le deuxième « remove_whitespace » supprime tous 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
        }
     ]
  }

Voir aussi

• Interrogation des concepts dans Recherche Azure AI

• Analyseurs pour le traitement linguistique et texte

• API REST De recherche de documents