Recherche approximative pour corriger les fautes d’orthographe et de frappe

  • Article

Azure AI Search prend en charge la recherche approximative, type de requête qui pallie les fautes d’orthographe et les termes mal orthographiés dans la chaîne d’entrée. Recherche approximative recherche les termes ayant une composition similaire. L’extension de la recherche pour couvrir les correspondances proches a l’effet de la correction automatique d’une faute de frappe lorsque l’écart n’est que quelques caractères mal placés.

Il s’agit d’un exercice d’expansion de requête qui produit une correspondance avec les termes ayant une composition similaire. Quand une recherche approximative est spécifiée, le moteur de recherche génère un graphe (basé sur la théorie de l’automate fini déterministe) des termes composés de la même façon, pour l’ensemble des termes de la requête. Par exemple, si votre requête comprend trois termes "university of washington", un graphique est créé pour chaque terme de la requête search=university~ of~ washington~ (la recherche floue ne supprime pas les mots vides, donc "of" obtient un graphique).

Le graphe se compose d’un maximum de 50 expansions, ou permutations, de chaque terme, capturant à la fois les variantes correctes et incorrectes dans le processus. Le moteur retourne ensuite les correspondances les plus pertinentes dans la réponse.

Pour un terme comme « université », le graphique peut comporter "unversty, universty, university, universe, inverse". Tous les documents qui correspondent à ces termes du graphe sont inclus dans les résultats. Contrairement à d’autres requêtes qui analysent le texte pour gérer les différentes formes du même mot (« mice » et « mouse »), les comparaisons dans une requête approximative sont effectuées telles quelles sans aucune analyse linguistique du texte. Les termes « universe » et « inverse », qui sont sémantiquement différents, constituent des correspondances, car les différences syntaxiques sont minimes.

Une correspondance est établie si les différences sont limitées à, au plus, deux modifications, une modification étant un caractère inséré, supprimé, substitué ou transposé. L’algorithme de correction de chaîne qui spécifie la valeur différentielle est la métrique Distance de Damerau-Levenshtein. Elle est décrite comme étant le nombre minimum d’opérations (insertions, suppressions, substitutions ou transpositions de deux caractères adjacents) nécessaires pour transformer une chaîne de caractères en une autre.

Dans Azure AI Search :

  • La requête approximative s’applique à des termes entiers. Les phrases ne sont pas prises en charge directement, mais vous pouvez spécifier une correspondance floue pour chaque terme d'une phrase en plusieurs parties à l'aide de constructions AND. Par exemple : search=dr~ AND cleanin~. Cette expression de requête recherche des correspondances sur le « nettoyage à sec ».

  • La distance par défaut d’une modification est 2. La valeur ~0 signifie qu’il n’y a pas d’expansion (seul le terme exact est considéré comme une correspondance), mais vous pouvez spécifier ~1 pour un degré de différence ou une modification.

  • Une requête approximative peut étendre un terme jusqu’à 50 permutations. Cette limite n’est pas configurable, mais vous pouvez réduire efficacement le nombre d’expansions en diminuant la distance de modification à 1.

  • Les réponses se composent de documents contenant une correspondance pertinente (jusqu’à 50).

Pendant leur traitement, les requêtes approximatives ne sont pas soumises à une analyse lexicale. L’entrée de la requête est ajoutée directement à l’arborescence de requête et développée pour créer un graphe de termes. La seule transformation effectuée est la mise en minuscules.

Collectivement, les graphes sont soumis en tant que critères de correspondance par rapport aux jetons de l’index. Comme vous pouvez l’imaginer, la recherche approximative est fondamentalement plus lente que les autres formes de requête. La taille et la complexité de votre index peuvent déterminer si les avantages sont suffisants pour compenser la latence de la réponse.

Remarque

La recherche approximative ayant tendance à être lente, il peut être utile d’examiner d’autres approches, telles que l’indexation N-gramme, avec sa progression de séquences de caractères courtes (séquences de deux et trois caractères pour les jetons bigrammes et trigrammes). En fonction de votre langue et de la surface d’exposition de la requête, l’approche N-gramme peut offrir de meilleures performances. Sachez toutefois que l’indexation N-gramme est très gourmande en stockage et génère des index beaucoup plus volumineux.

Une autre solution, que vous pouvez envisager si vous souhaitez gérer uniquement les cas les plus flagrants, est une carte de synonymes. Par exemple, vous pouvez établir une correspondance entre « search » et « serach, serch, sarch » ou entre « retrieve » et « retreive ».

Les champs de chaîne attribués comme « pouvant faire l’objet d’une recherche » sont des candidats à la recherche partielle.

Les analyseurs ne sont pas utilisés pour créer un graphe d’expansions, mais cela ne signifie pas qu’ils doivent être ignorés dans les scénarios de recherche approximative. Les analyseurs sont importants pour la tokenisation pendant l’indexation, où les jetons dans les index inversés sont utilisés pour la correspondance avec le graphique.

Comme toujours, si les requêtes de test ne produisent pas les correspondances attendues, effectuez des expériences avec différents analyseurs d’indexation. Par exemple, essayez un analyseur de langage pour voir si vous obtenez de meilleurs résultats. Certaines langues, en particulier celles qui ont des mutations de voyelle, peuvent tirer parti des formes fléchies et irrégulières générées par les processeurs de langage naturel Microsoft. Dans certains cas, l’utilisation de l’analyseur linguistique approprié peut s’avérer déterminante pour qu’un terme soit représenté sous forme de jetons d’une manière compatible avec la valeur fournie par l’utilisateur.

Les requêtes partielles sont construites à l’aide de la syntaxe de requête Lucene complète, appelant l’analyseur de requête Lucene complet et ajoutant un caractère tilde ~ après chaque terme entier entré par l’utilisateur.

Voici un exemple de requête qui appelle une recherche partielle. Elle comprend quatre termes, dont deux sont mal orthographiés :

POST https://[service name].search.windows.net/indexes/hotels-sample-index/docs/search?api-version=2023-11-01
{
    "search": "seatle~ waterfront~ view~ hotle~",
    "queryType": "full",
    "searchMode": "any",
    "searchFields": "HotelName, Description",
    "select": "HotelName, Description, Address/City,",
    "count": "true"
}

  1. Définissez le type de requête sur la syntaxe Lucene complète (queryType=full).

  2. Indiquez la chaîne de requête où chaque terme est suivi d’un opérateur tilde (~) à la fin de chaque terme (search=<string>~). Un graphique d’expansion est créé pour chaque terme dans l’entrée de requête.

    Incluez un paramètre facultatif, un nombre compris entre 0 et 2 (valeur par défaut), si vous souhaitez spécifier la distance de modification (~1). Par exemple, « blue~ » ou « blue~1 » retournent « blue », « blues » et « glue ».

Si vous le souhaitez, vous pouvez améliorer les performances des requêtes en définissant la requête sur des champs spécifiques. Utilisez le paramètre searchFields pour spécifier les champs à rechercher. Vous pouvez également utiliser la propriété select pour spécifier les champs retournés dans la réponse de requête.

Pour les tests simples, nous vous recommandons d’utiliser le Navigateur de recherche ou un client REST afin d’effectuer une itération au sein d’une expression de requête. Les deux outils sont interactifs, ce qui signifie que vous pouvez rapidement parcourir plusieurs variantes d’un terme et évaluer les réponses retournées.

Quand les résultats sont ambigus, la mise en surbrillance des correspondances peut vous aider à identifier la correspondance dans la réponse.

Remarque

L’utilisation de la mise en surbrillance des correspondances pour identifier les correspondances approximatives a des limites et fonctionne uniquement pour la recherche approximative de base. Si votre index a des profils de scoring, ou si vous enrichissez la requête avec une syntaxe supplémentaire, la mise en surbrillance des correspondances risque d’échouer pour identifier la correspondance.

Exemple 1 : Recherche approximative avec le terme exact

Supposons qu’un champ "Description" d’un document de recherche contient la chaîne suivante : "Test queries with special characters, plus strings for MSFT, SQL and Java."

Commencez par une recherche approximative sur « special » et ajoutez la mise en surbrillance des correspondances au champ Description :

search=special~&highlight=Description

Dans la réponse, étant donné que vous avez ajouté la mise en surbrillance des correspondances, la mise en forme est appliquée à « special » en tant que terme correspondant.

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]
}

Réessayez la demande en orthographiant mal « spécial » en enlevant plusieurs lettres ("pe") :

search=scial~&highlight=Description

Jusqu’à présent, aucune modification n’est apportée à la réponse. Étant donné la distance par défaut de 2 degrés, la suppression de deux caractères "pe" de « spécial » permet toujours d’obtenir une correspondance pour ce terme.

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]
}

Essayez une autre requête, modifiez davantage le terme de recherche en supprimant un dernier caractère pour un total de trois suppressions (de « spécial » à "scal") :

search=scal~&highlight=Description

Notez que la même réponse est retournée, mais à présent la correspondance approximative ne porte pas sur « special », mais sur « SQL ».

"@search.score": 0.4232868,
"@search.highlights": {
    "Description": [
        "Mix of special characters, plus strings for MSFT, <em>SQL</em>, 2019, Linux, Java."
    ]
}

L’intérêt de cet exemple développé est d’illustrer la clarté que la mise en surbrillance des correspondances peut apporter à des résultats ambigus. Dans tous les cas, le même document est retourné. Si vous aviez utilisé des ID de document pour vérifier une correspondance, vous auriez peut-être manqué le passage de « special » à « SQL ».

Voir aussi