Implémentation d’un disjoncteur Word et d’un générateur de formes dérivées
Microsoft fournit des analyseurs lexicaux et des générateurs de formes dérivées pour un certain nombre de langues. Cette rubrique explique comment implémenter et utiliser des analyseurs lexicaux et des générateurs de formes dérivées personnalisés pour les langues et les paramètres régionaux au-delà de ceux fournis par Microsoft.
Notes
Les analyseurs lexicaux personnalisés n’ont pas été temporairement pris en charge. En juillet 2018, une modification a été apportée à Windows Server 2019 qui a empêché le chargement des DLL sans signature Microsoft par SearchIndexer.exe. Cette limitation a été levée en janvier 2021.
Cette rubrique est organisée comme suit :
- Inscription d’une DLL de ressource de langage
- Inscription d’une langue
- Implémentation d’un Word Beaker
- Implémentation d’un générateur de formes dérivées
- Rubriques connexes
Inscription d’une DLL de ressource de langage
Chaque DLL de ressource de langage doit implémenter et exporter les points d’entrée suivants. La DLL peut être inscrite pour être dans n’importe quel dossier.
- DllMain est le point d’entrée standard de DLL.
- DllRegisterServer inscrit la DLL dans le Registre, par exemple
regsvr32.exe %SystemRoot%\MyFolder\wordbreaker.dll - DllCanUnloadNow permet aux clients d’appeler ce point d’entrée par le biais du modèle COM (Component Object Model) pour déterminer s’il est possible de décharger la DLL de ressource de langage.
- DllUnRegisterServer supprime la DLL du Registre.
Inscription d’une langue
Le Registre contient des entrées spécifiques à la langue pour la langue indexée, et ces entrées contrôlent les parties des processus d’indexation et de requête qui sont propres à la langue. Ces entrées de Registre se trouvent sous la clé de Registre suivante.
HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
ContentIndex
Control
Language
Implémentation d’un Word Beaker
Word analyseurs implémentent IWordBreaker. La méthode IWordBreaker::BreakText effectue tout le traitement et l’analyse du texte. Pour implémenter un composant analyseur lexicaux, vous devez disposer d’une heuristique de langue pour votre langue. Cela inclut des informations sur la syntaxe et la morphologie. Vous pouvez également avoir besoin d’une liste de mots à exclure ou à inclure. Vous générez le fichier de mots parasites pour vos paramètres régionaux de langue à partir de la liste des mots exclus. Pour plus d’informations sur les considérations linguistiques et sur la façon dont ces considérations affectent les implémentations d’analyseur lexicaux, consultez Considérations linguistiques et Unicode.
L’objectif main de IWordBreaker::BreakText est de traiter du texte en continu à partir du TEXT_SOURCE jusqu’à ce que tout le texte soit traité, ou jusqu’à ce que l’analyseur lexical rencontre une erreur. Dans cette boucle de traitement des données, IWordBreaker::BreakText appelle des méthodes d’analyse et d’utilitaire qui effectuent des tâches spécifiques pour ce processus. Par exemple, l’analyseur lexicaux allemand peut gérer des mots composés, tandis que l’analyseur lexical Français peut traiter des signes diacritiques ou clitiques. Les fonctions spécifiques que l’analyseur lexical effectue et la stratégie qu’il utilise pour effectuer ces tâches dépendent entièrement des exigences de cette langue.
Lors de la rupture de texte, les analyseurs lexicaux identifient les formes « alternatives » pour les mots qui peuvent avoir plusieurs représentations. Aucune relation sémantique n’est implicite entre les mots générés. En fait, le mot d’origine ne peut pas être inclus dans la liste des alternatives. Les autres formulaires sont enregistrés dans la même position dans l’index que le mot d’origine pour indiquer qu’ils sont identiques.
Lorsqu’un document est inclus dans l’index, chaque mot se voit attribuer une valeur entière qui représente le décalage ou la distance du mot par rapport au début d’un document. La distance relative entre les mots d’une requête est comparée aux décalages stockés dans l’index de recherche en texte intégral. La requête « Where is Kyle’s document » (Where is Kyle’s document) correspond à un document avec « Where » au décalage n, « is » à n+1, « Kyle’s » à n+2 et « document » à n+3. « Où le document de Kyle est-il déposé dans la base de données ? » est représenté comme suit :
| Where | is | Kyle Kyle's |
document | Classé | in | le | base de données de base de données |
Dans cet exemple, l’analyseur lexical stocke d’autres formes pour « Kyle » (« kyle ») et « base de données » (« base de données ») dans l’index. L’analyseur lexical génère et stocke d’autres mots pendant le processus de création d’index dans les conditions suivantes :
- Si un autre mot est susceptible d’apparaître sous la forme d’un mot unique dans une requête
- Si un générateur de formes dérivées n’est pas susceptible de dériver le mot d’origine de l’alternative
La génération de formes de mots alternatives augmente le nombre de façons dont les requêtes représentent et correspondent à une phrase, comme illustré dans les variantes suivantes :
- Où le document Kyle est-il déposé dans la base de données ?
- Où se trouve le document de Kyle déposé dans la base de données
- Où le document Kyle est-il déposé dans la base de données ?
- Où se trouve le document de Kyle dans la base de données
WordSink et PhraseSink
Word analyseurs utilisent les objets IWordSink et IPhraseSink pour collecter et stocker tous les mots et expressions qu’ils extraient du texte. Un analyseur lexical stocke les mots dans un formulaire aussi proche que possible du formulaire word d’origine dans le document. IPhraseSink stocke les expressions au moment de la requête. Les expressions améliorent la pertinence des résultats des requêtes, car les séquences de mots plus longues sont plus rares et offrent une plus grande distinction que les expressions plus petites. Lorsque l’indexeur place une expression dans le IPhraseSink au moment de la requête, il crée une instance de l’analyseur lexical pour diviser l’expression en mots. L’indexeur évalue ensuite l’expression en vérifiant si les mots de l’expression sont adjacents les uns aux autres dans l’index. Par exemple, si « ABCD » se produit dans l’index aux positions x, x+1, x+2 et x+3, la correspondance d’expression se produit si une sous-chaîne adjacente de « ABCD » est envoyée dans une requête. Cette stratégie est efficace pour les analyseurs de mots basés sur des caractères qui fractionnent des expressions et des mots longs lors de la création de l’index et qui génèrent des expressions au moment de la requête.
Sauts
Les pauses sont les espaces entre les mots. Les espaces blancs, la ponctuation, la mise en forme ou simplement la nature du langage lui-même peuvent provoquer des interruptions. L’indexeur utilise quatre types de sauts différents : fin de mot (EOW), fin de phrase (EOS), fin de paragraphe (EOP) et fin de chapitre (EOC). L’arrêt EOW est l’arrêt par défaut. Après chaque jeton, chaque saut indique une distance sémantique différente entre les mots de chaque côté. Les mots séparés par EOW ont le lien sémantique le plus étroit, suivis par EOS, EOP et EOC. Plusieurs appels à IWordSink::P utBreak sont cumulatifs et sont analogues à l’insertion de mots ou de phrases null.
Scalabilité, performance et sécurité
La façon dont l’analyseur lexical répond aux appels simultanés est largement déterminée par votre choix de modèle de thread. L’indexeur est une application à thread unique. Pour que les analyseurs lexicaux fonctionnent dans un environnement à thread unique, les analyseurs lexicaux doivent être écrits à l’aide d’un modèle de thread « libre » ou « les deux ». Word les disjoncteurs ne doivent pas s’inscrire auprès de COM à l’aide du modèle de thread « appartement ».
Nous recommandons que les analyseurs lexicaux évitent les états globaux et stockent des données dans le instance pour l’analyseur lexical. Le seul contenu qui doit être stocké dans l’implémentation de l’analyseur lexicaux concerne les paramètres fQuery et ulMaxTokenSize. Word analyseurs ne doivent pas être plus de deux fois plus lents que le point de référence établi par l’analyseur lexical anglais. Word performances du disjoncteur doivent également s’améliorer avec une capacité matérielle accrue.
Word les disjoncteurs pour l’indexeur s’exécutent dans le contexte de sécurité du système local. Ils doivent être écrits pour gérer les mémoires tampons et s’empiler correctement. Toutes les copies de chaînes doivent avoir des vérifications explicites pour se protéger contre les dépassements de mémoire tampon. Vous devez toujours vérifier la taille allouée de la mémoire tampon et tester la taille des données par rapport à la taille de la mémoire tampon. Word analyseurs ne peuvent pas supposer que le texte passé à la méthode IWordBreaker::BreakText est bien formé. Pour plus d’informations sur la résolution des problèmes liés aux analyseurs lexicaux, consultez Résolution des problèmes liés aux ressources linguistiques et bonnes pratiques.
Implémentation d’un générateur de formes dérivées
Les stemmers implémentent l’interface IStemmer . La méthode IStemmer::GenerateWordForms génère une liste de formulaires de mots infléchis pour un mot d’entrée particulier. Pour implémenter un composant stemmer, vous devez disposer d’une heuristique de langue pour votre langue. Cela inclut des informations sur la morphologie. Vous pouvez également avoir besoin d’une liste de mots à exclure ou à inclure. Pour plus d’informations sur les considérations linguistiques et sur la façon dont ces considérations affectent les implémentations stemmer, consultez Considérations linguistiques et Unicode.
Nous recommandons que les stemmers ne génèrent pas la casse génitive, ou possessive, pour les mots. Par exemple, « David » n’est pas généré comme une autre forme pour « David ». Le disjoncteur génère à la fois « David » et « David » lorsqu’il analyse « David’s ».
Le stemmer utilise l’objet IWordFormSink pour rassembler la liste des mots alternatifs. IWordFormSink::P utWord génère le mot final à partir du stemmer. Dans tous les cas, ce dernier mot est identique au mot d’entrée de IStemmer::GenerateWordForms. Par exemple, étant donné le mot « swim », le stemmer génère les formes de mots suivantes : « natation », « nageur », « nageur », « nageur », « swam » et « swum », par le biais d’appels à IWordFormSink::P utAltWord. Le stemmer génère « swim » via IWordFormSink::P utWord.
Scalabilité, performance et sécurité
Les stemmers, comme les disjoncteurs, doivent utiliser un modèle de threading « libre » et s’inscrire auprès de COM avec leur modèle de thread défini sur « free » ou « both ». Recherche Windows appelle des instances distinctes du stemmer à partir de différents threads en même temps. Les stemmers doivent donc avoir un minimum de instance données.
La précision du stemmer a un impact significatif sur la pertinence des requêtes. Si l’élément stemmer n’a pas correctement contenu le texte, les requêtes peuvent renvoyer des résultats imprévisibles et incorrects. Les stemmers doivent gérer des centaines de requêtes par seconde sans affecter négativement les performances des requêtes. Les performances de Stemmer doivent s’améliorer avec une capacité matérielle accrue. Pour plus d’informations sur la résolution des problèmes liés aux souches, consultez Résolution des problèmes liés aux ressources linguistiques et aux meilleures pratiques.
Les stemmers pour Windows Search s’exécutent dans le contexte de sécurité locale. Ils doivent être écrits pour gérer les mémoires tampons et s’empiler correctement. Toutes les copies de chaîne doivent avoir des vérifications explicites pour se prémunir contre les dépassements de mémoire tampon. Vous devez toujours vérifier la taille allouée de la mémoire tampon et tester la taille des données par rapport à la taille de la mémoire tampon.
Rubriques connexes