Ce billet se concentre sur une technique particulière appelée recherche par similarité de texte. Dans ce type de recherche, l'utilisateur saisit une courte requête en texte libre et les documents sont classés en fonction de leur similarité avec la requête. La similarité des textes peut être utile dans divers cas d'utilisation :

• Réponse aux questions : À partir d'une collection de questions fréquemment posées, trouver des questions similaires à celle que l'utilisateur a saisie.

• Recherche d'articles : Dans une collection d'articles de recherche, renvoyer les articles dont le titre est étroitement lié à la requête de l'utilisateur.

• Recherche d'images : Dans un ensemble de données d'images légendées, trouver les images dont la légende est similaire à la description de l'utilisateur.

Une approche simple de la recherche par similarité consisterait à classer les documents en fonction du nombre de mots qu'ils partagent avec la requête. Mais un document peut être similaire à la requête même s'ils n'ont que très peu de mots en commun - une notion plus robuste de similarité prendrait également en compte son contenu syntaxique et sémantique.

La communauté du traitement du langage naturel (NLP) a mis au point une technique appelée "text embedding" qui code les mots et les phrases sous forme de vecteurs numériques. Ces représentations vectorielles sont conçues pour capturer le contenu linguistique du texte et peuvent être utilisées pour évaluer la similarité entre une requête et un document.

Ce billet explore comment les text embeddings et le type dense_vector d'Elasticsearch pourraient être utilisés pour soutenir la recherche de similarité. Nous donnerons d'abord un aperçu des techniques d'intégration, puis nous présenterons un prototype simple de recherche par similarité à l'aide d'Elasticsearch.

Qu'est-ce qu'un encartage de texte ?

Examinons de plus près les différents types d'enchâssement de texte et leur comparaison avec les méthodes de recherche traditionnelles.

Les enchâssements de mots

Un modèle d'intégration de mots représente un mot sous la forme d'un vecteur numérique dense. Ces vecteurs visent à capturer les propriétés sémantiques du mot - les mots dont les vecteurs sont proches les uns des autres devraient être similaires en termes de signification sémantique. Dans une bonne intégration, les directions dans l'espace vectoriel sont liées à différents aspects de la signification du mot. Par exemple, le vecteur pour "Canada" peut être proche de "France" dans une direction, et proche de "Toronto" dans une autre.

Les communautés de recherche et de traitement de texte s'intéressent depuis longtemps aux représentations vectorielles des mots. L'intégration de mots a connu un regain d'intérêt au cours des dernières années, lorsque de nombreuses tâches traditionnelles ont été revues à l'aide de réseaux neuronaux. Certains algorithmes d'intégration de mots ont été développés avec succès, notamment word2vec et GloVe. Ces approches utilisent de grandes collections de textes et examinent le contexte dans lequel chaque mot apparaît pour déterminer sa représentation vectorielle :

• Le modèle word2vec Skip-gram entraîne un réseau neuronal à prédire les mots du contexte autour d'un mot dans une phrase. Les poids internes du réseau donnent l'enchâssement des mots.

• Dans GloVe, la similarité des mots dépend de leur fréquence d'apparition avec d'autres mots du contexte. L'algorithme entraîne un modèle linéaire simple sur les comptes de cooccurrence des mots.

De nombreux groupes de recherche distribuent des modèles qui ont été pré-entraînés sur de grands corpus de textes tels que Wikipedia ou Common Crawl, ce qui permet de les télécharger et de les intégrer dans des tâches en aval. Bien que des versions pré-entraînées soient parfois utilisées directement, il peut être utile d'adapter le modèle à l'ensemble de données et à la tâche spécifiques. Cela se fait souvent en exécutant une étape de "réglage fin" sur le modèle pré-entraîné.

Les mots intégrés se sont révélés très robustes et efficaces, et il est désormais courant d'utiliser les mots intégrés à la place des mots individuels dans les tâches de TAL telles que la traduction automatique et la classification des sentiments.

Enchâssement de phrases

Plus récemment, les chercheurs ont commencé à s'intéresser aux techniques d'intégration qui représentent non seulement des mots, mais aussi des sections de texte plus longues. La plupart des approches actuelles sont basées sur des architectures de réseaux neuronaux complexes et intègrent parfois des données étiquetées lors de la formation afin de faciliter la capture des informations sémantiques.

Une fois entraînés, les modèles sont capables de prendre une phrase et de produire un vecteur pour chaque mot dans son contexte, ainsi qu'un vecteur pour la phrase entière. Comme pour l'intégration de mots, des versions pré-entraînées de nombreux modèles sont disponibles, ce qui permet aux utilisateurs d'éviter le processus d'entraînement coûteux. Alors que le processus d'apprentissage peut être très gourmand en ressources, l'utilisation du modèle est beaucoup plus légère - les modèles d'intégration de phrases sont généralement assez rapides pour être utilisés dans le cadre d'applications en temps réel.

Parmi les techniques courantes d'intégration de phrases, on peut citer InferSent, Universal Sentence Encoder, ELMo et BERT. L'amélioration de l'intégration des mots et des phrases est un domaine de recherche actif, et il est probable que d'autres modèles forts seront introduits.

Comparaison avec les méthodes de recherche traditionnelles

Dans la recherche d'informations traditionnelle, une façon courante de représenter un texte sous forme de vecteur numérique consiste à attribuer une dimension à chaque mot du vocabulaire. Le vecteur d'un texte est alors basé sur le nombre d'occurrences de chaque terme du vocabulaire. Cette façon de représenter un texte est souvent appelée "bag of words," parce que nous comptons simplement les occurrences de mots sans tenir compte de la structure de la phrase.

Les text embeddings diffèrent des représentations vectorielles traditionnelles sur certains points importants :

• Les vecteurs encodés sont denses et relativement peu dimensionnés, avec souvent entre 100 et 1 000 dimensions. En revanche, les vecteurs de sacs de mots sont peu nombreux et peuvent comporter plus de 50 000 dimensions. Les algorithmes d'intégration codent le texte dans un espace de dimension inférieure dans le cadre de la modélisation de sa signification sémantique. Idéalement, les mots et expressions synonymes se retrouvent avec une représentation similaire dans le nouvel espace vectoriel.

• Les encastrements de phrases peuvent prendre en compte l'ordre des mots lors de la détermination de la représentation vectorielle. Par exemple, la phrase "tune in" peut être représentée par un vecteur très différent de "in tune".

• Dans la pratique, les enchâssements de phrases ne s'appliquent pas toujours bien à de grandes parties de texte. Ils ne sont pas couramment utilisés pour représenter un texte plus long qu'un court paragraphe.

Utilisation des embeddings pour la recherche de similitudes

Supposons que nous disposions d'une vaste collection de questions et de réponses. Un utilisateur peut poser une question et nous voulons retrouver la question la plus similaire dans notre collection pour l'aider à trouver une réponse.

Nous pourrions utiliser des enchâssements de texte pour permettre de retrouver des questions similaires :

• Lors de l'indexation, chaque question est traitée par un modèle d'intégration de phrases afin de produire un vecteur numérique.

• Lorsqu'un utilisateur saisit une requête, celle-ci est traitée par le même modèle d'intégration de phrases pour produire un vecteur. Pour classer les réponses, nous calculons la similarité vectorielle entre chaque question et le vecteur de la requête. Pour comparer les vecteurs d'intégration, il est courant d'utiliser la similitude cosinus.

Ce dépôt donne un exemple simple de la façon dont cela pourrait être réalisé dans Elasticsearch. Le script principal indexe environ 20 000 questions de l'ensemble de données StackOverflow, puis permet à l'utilisateur de saisir des requêtes en texte libre dans l'ensemble de données.

Nous verrons bientôt chaque partie du script en détail, mais voyons d'abord quelques exemples de résultats. Dans de nombreux cas, la méthode est capable de capturer la similarité même lorsqu'il n'y a pas de fort chevauchement de mots entre la requête et la question indexée :

• "zippage des fichiers" retours "Compression / décompression des dossiers & Fichiers"

• "déterminer si quelque chose est une IP" renvoie "Comment déterminer si une chaîne de caractères est une IP ou un nom d'hôte ?"

• "traduire des octets en doubles" returns "Convertir des octets en nombres à virgule flottante en Python"

Détails de la mise en œuvre

Le script commence par télécharger et créer le modèle d'intégration dans TensorFlow. Nous avons choisi l'encodeur universel de phrases de Google, mais il est possible d'utiliser de nombreuses autres méthodes d'intégration. Le script utilise le modèle d'intégration tel quel, sans aucune formation ou mise au point supplémentaire.

Ensuite, nous créons l'index Elasticsearch, qui comprend des correspondances pour le titre de la question, les balises et le titre de la question encodé sous forme de vecteur :

Dans le mapping pour dense_vector, nous devons spécifier le nombre de dimensions que les vecteurs contiendront. Lors de l'indexation d'un champ title_vector, Elasticsearch vérifiera qu'il possède le même nombre de dimensions que celui spécifié dans le mapping.

Pour indexer les documents, nous faisons passer le titre de la question par le modèle d'intégration afin d'obtenir un tableau numérique. Ce tableau est ajouté au document dans le champ title_vector.

Lorsqu'un utilisateur saisit une requête, le texte passe d'abord par le même modèle d'intégration et est stocké dans le paramètre query_vector. Depuis la version 7.3, Elasticsearch propose une fonction cosineSimilarity dans son langage de script natif. Pour classer les questions en fonction de leur similitude avec la requête de l'utilisateur, nous utilisons donc une requête script_score :

Nous veillons à transmettre le vecteur de requête en tant que paramètre de script afin d'éviter de recompiler le script() à chaque nouvelle requête. Elasticsearch n'autorisant pas les scores négatifs, il est nécessaire d'en ajouter un à la similarité cosinus.

| Note : ce billet de blog utilisait à l'origine une syntaxe différente pour les fonctions vectorielles qui était disponible dans Elasticsearch 7.3, mais qui a été supprimée dans la version 7.6. |

Limites importantes

La requête script_score est conçue pour envelopper une requête restrictive et modifier les scores des documents qu'elle renvoie. Cependant, nous avons fourni une requête match_all, ce qui signifie que le script sera exécuté sur tous les documents de l'index. Il s'agit d'une limitation actuelle de la similarité vectorielle dans Elasticsearch - les vecteurs peuvent être utilisés pour évaluer les documents, mais pas dans l'étape de recherche initiale. L'aide à la recherche basée sur la similarité des vecteurs est un domaine important des travaux en cours.

Pour éviter de parcourir tous les documents et maintenir des performances élevées, la requête match_all peut être remplacée par une requête plus sélective. La bonne requête à utiliser pour la recherche dépend probablement du cas d'utilisation spécifique.

Bien que nous ayons vu quelques exemples encourageants ci-dessus, il est important de noter que les résultats peuvent également être bruyants et non intuitifs. Par exemple, "zippant les fichiers" attribue également des scores élevés à "Partiel .csproj Fichiers" et "Comment éviter .pyc fichiers ?". Et lorsque la méthode renvoie des résultats surprenants, il n'est pas toujours évident de déboguer le problème - la signification de chaque composante du vecteur est souvent opaque et ne correspond pas à un concept interprétable. Avec les techniques de notation traditionnelles basées sur le chevauchement des mots, il est souvent plus facile de répondre à la question suivante : "pourquoi ce document est-il bien classé ?"

Comme indiqué précédemment, ce prototype est conçu comme un exemple de la manière dont les modèles d'intégration peuvent être utilisés avec les champs vectoriels, et non comme une solution prête à l'emploi. Lors de l'élaboration d'une nouvelle stratégie de recherche, il est essentiel de tester les performances de l'approche sur vos propres données, en veillant à les comparer à une base de référence solide telle qu'une requête de correspondance. Il peut s'avérer nécessaire d'apporter des modifications majeures à la stratégie avant qu'elle n'obtienne des résultats solides, notamment en affinant le modèle d'intégration pour l'ensemble de données cible ou en essayant différentes manières d'intégrer les intégrations, telles que l'expansion des requêtes au niveau des mots.

Conclusions

Les techniques d'intégration constituent un moyen puissant de capturer le contenu linguistique d'un texte. En indexant les enchâssements et en attribuant des notes basées sur la distance vectorielle, nous pouvons comparer les documents en utilisant une notion de similarité qui va au-delà de leur chevauchement au niveau des mots.

Nous sommes impatients d'introduire davantage de fonctionnalités basées sur le type de champ vectoriel. L'utilisation des vecteurs pour la recherche est un domaine nuancé et en développement - comme toujours, nous serions ravis de connaître vos cas d'utilisation et vos expériences sur Github et les forums de discussion!

Arrière-plan

Lors du développement d'Elasticsearch, nous rencontrons parfois un problème important pour lequel il n'existe pas d'approche simple ou établie. Il est naturel de se demander s'il existe un document universitaire traitant de cette question. D'autres fois, le travail universitaire est une source d'inspiration. Nous tombons sur un article proposant un nouvel algorithme ou une nouvelle structure de données et nous nous disons "ce serait tellement utile !". Voici quelques exemples de la façon dont Elasticsearch et Apache Lucene intègrent des travaux universitaires :

• HyperLogLog++ pour les agrégations de cardinalité

• Algorithme C3 pour la sélection adaptative des répliques

• Graphes hiérarchiques navigables du petit monde (HNSW) pour la recherche du vecteur le plus proche dans Lucene

• Statistique MIC pour améliorer la classification par apprentissage automatique

• Block-max WAND pour une recherche plus rapide des meilleurs résultats dans Lucene

• ... et bien d' autres encore

Les articles universitaires constituent une ressource inestimable pour les ingénieurs qui développent des systèmes à forte intensité de données. Mais leur mise en œuvre peut être intimidante et sujette à des erreurs - les descriptions d'algorithmes sont souvent complexes et des détails pratiques importants sont omis. Les tests constituent un véritable défi : par exemple, comment tester de manière approfondie un algorithme d'apprentissage automatique dont le résultat dépend étroitement de l'ensemble de données ?

Évaluez le document comme vous le feriez pour une dépendance logicielle.

L'ajout d'une nouvelle dépendance logicielle nécessite une évaluation minutieuse : si l'autre paquet est incorrect, lent ou peu sûr, notre projet pourrait l'être aussi. Avant d'intégrer une dépendance, les développeurs veillent à en évaluer la qualité.

Il en va de même pour les travaux universitaires que vous envisagez de mettre en œuvre. On peut penser que parce qu'un algorithme a été publié dans un article, il doit être correct et performant. Mais même s'il a été soumis à un processus d'examen, un document universitaire peut présenter des problèmes. Peut-être que la preuve d'exactitude repose sur des hypothèses qui ne sont pas réalistes. Il se peut aussi que la section "expériences" montre des performances nettement supérieures à celles de la ligne de base, mais que cela ne soit valable que pour un ensemble de données spécifique. Même si le document est de grande qualité, son approche peut ne pas convenir à votre projet.

Lorsque l'on se demande si l'on doit accepter une "dépendance" à l'égard d'un document universitaire, il est utile de se poser les mêmes questions que celles que l'on se poserait à l'égard d'un logiciel :

• La bibliothèque est-elle largement utilisée et "testée au combat" ? → D'autres paquets ont-ils mis en œuvre ce document, et cela a-t-il bien fonctionné pour eux ?

• Existe-t-il des critères de performance ? Ces données vous semblent-elles exactes et équitables ? → L'article comporte-t-il des expériences réalistes ? Sont-ils bien conçus ?

• L'amélioration des performances est-elle suffisamment importante pour justifier la complexité ? → Le document est-il comparable à une approche de référence solide ? Dans quelle mesure la performance est-elle supérieure à celle de la base de référence ?

• L'approche s'intégrera-t-elle bien à notre système ? → Les hypothèses et les compromis de l'algorithme sont-ils adaptés à notre cas d'utilisation ?

D'une manière ou d'une autre, lorsqu'un logiciel publie une comparaison de ses performances avec celles de ses concurrents, c'est toujours le logiciel qui est le plus rapide ! Si une tierce partie a conçu les critères de référence, ils peuvent être plus équilibrés. Le même phénomène s'applique aux travaux universitaires. Si un algorithme donne de bons résultats non seulement dans l'article original, mais apparaît également dans d'autres articles comme une référence solide, il est très probable qu'il soit solide.

Soyez créatifs avec les tests

Les algorithmes tirés d'articles universitaires ont souvent un comportement plus sophistiqué que les types d'algorithmes que nous rencontrons couramment. Il s'agit peut-être d'un algorithme d'approximation qui troque la précision contre une plus grande rapidité. Il peut aussi s'agir d'une méthode d'apprentissage automatique qui prend en compte un vaste ensemble de données et produit des résultats (parfois inattendus). Comment pouvons-nous écrire des tests pour ces algorithmes si nous ne pouvons pas caractériser leur comportement de manière simple ?

Focus sur les invariants

Lors de la conception des tests unitaires, il est courant de penser en termes d'exemples : si nous donnons à l'algorithme cet exemple d'entrée, il devrait produire cette sortie. Malheureusement, pour la plupart des algorithmes mathématiques, les tests basés sur des exemples ne couvrent pas suffisamment leur comportement.

Considérons l'algorithme C3, qu'Elasticsearch utilise pour déterminer quel nœud doit traiter une requête de recherche. Il classe chaque nœud à l'aide d'une formule nuancée qui incorpore le service précédent et les temps de réponse du nœud, ainsi que la taille de sa file d'attente. Tester quelques exemples ne permet pas vraiment de vérifier que nous avons compris la formule correctement. Il est utile de prendre du recul et de réfléchir au test des invariants : si le temps de service augmente, le rang du nœud diminue-t-il ? Si la taille de la file d'attente est de 0, le rang est-il déterminé par le temps de réponse, comme le prétend le document ?

Se concentrer sur les invariants peut s'avérer utile dans un certain nombre de cas courants :

• La méthode est-elle censée ne pas tenir compte de l'ordre ? Si c'est le cas, le fait de passer les données d'entrée dans un ordre différent devrait produire le même résultat.

• Certaines étapes de l'algorithme produisent-elles des probabilités de classe ? Si c'est le cas, la somme de ces probabilités doit être égale à 1.

• La fonction est-elle symétrique par rapport à l'origine ? Si c'est le cas, l'inversion du signe de l'entrée devrait simplement inverser le signe de la sortie.

Lorsque nous avons mis en œuvre C3 pour la première fois, nous avons eu un problème dans la formule où nous avons accidentellement utilisé l'inverse du temps de réponse à la place du temps de réponse. Cela signifie que les nœuds les plus lents peuvent être mieux classés ! Lors de la correction du problème, nous avons veillé à ajouter des vérifications invariantes afin d'éviter de nouvelles erreurs.

Comparer avec une implémentation de référence

Parallèlement à l'article, les auteurs ont publié une mise en œuvre de l'algorithme. (Cela est particulièrement probable si l'article contient des expériences, car de nombreuses revues exigent que les auteurs publient le code permettant de reproduire les résultats). Vous pouvez tester votre approche par rapport à cette implémentation de référence pour vous assurer que vous n'avez pas oublié des détails importants de l'algorithme.

Lors du développement de l'implémentation HNSW de Lucene pour la recherche du plus proche voisin, nous avons testé une bibliothèque de référence créée par les auteurs de l'article. Nous avons testé Lucene et la bibliothèque sur le même ensemble de données, en comparant la précision de leurs résultats et le nombre de calculs qu'ils ont effectués. Lorsque ces nombres correspondent étroitement, nous savons que Lucene met fidèlement en œuvre l'algorithme.

Lors de l'intégration d'un algorithme dans un système, il est souvent nécessaire de procéder à des modifications ou à des extensions, comme l'adaptation à plusieurs cœurs ou l'ajout d'heuristiques pour améliorer les performances. Il est préférable de commencer par mettre en œuvre une version "vanilla", de la tester par rapport à la référence, puis d'y apporter des modifications incrémentielles. Vous pouvez ainsi être sûr d'avoir capturé tous les éléments clés avant de procéder à des personnalisations.

Duel contre un algorithme existant

La dernière section propose une autre idée d'invariant de test : comparer le résultat de l'algorithme à celui d'un algorithme plus simple et mieux compris. Prenons l'exemple de l'algorithme WAND block-max de Lucene, qui accélère la recherche de documents en ignorant ceux qui ne peuvent pas figurer dans les premiers résultats. Il est difficile de décrire exactement le comportement de l'outil WAND block-max dans tous les cas, mais nous savons que son application ne devrait pas modifier les premiers résultats ! Nos tests peuvent donc générer plusieurs requêtes de recherche aléatoires, puis les exécuter avec et sans l'optimisation WAND et vérifier que les résultats correspondent toujours.

Un aspect important de ces tests est qu'ils génèrent des entrées aléatoires sur lesquelles la comparaison est effectuée. Cela peut permettre de mettre en œuvre des cas auxquels vous n'auriez pas pensé et de mettre en évidence des problèmes inattendus. Par exemple, le test de comparaison aléatoire de Lucene pour la notation BM25F a permis de détecter des bogues dans des cas subtils. L'idée d'alimenter un algorithme avec des entrées aléatoires est étroitement liée au concept de fuzzing, une technique de test courante dans le domaine de la sécurité informatique.

Elasticsearch et Lucene utilisent fréquemment cette approche de test. Si vous voyez un test qui mentionne un duel "" entre deux algorithmes (TestDuelingAnalyzers, testDuelTermsQuery...), vous savez que cette stratégie est en action.

Utiliser la terminologie du document

Lorsqu'un autre développeur travaillera avec votre code, il devra consulter le document pour en suivre les détails. Le commentaire sur l'implémentation HyperLogLog++ d'Elasticsearch le dit bien : "Essayer de comprendre ce que fait cette classe sans avoir lu le document est considéré comme aventureux." Ce commentaire de méthode constitue également un bon exemple. Elle comprend un lien vers l'article universitaire et met en évidence les modifications apportées à l'algorithme tel qu'il a été décrit à l'origine.

Étant donné que les développeurs fonderont leur compréhension du code sur le document, il est utile d'utiliser exactement la même terminologie. La notation mathématique étant laconique, il peut en résulter des noms qui ne seraient pas habituellement considérés comme "de bon style", mais qui sont très clairs dans le contexte de l'article. Les formules tirées d'articles universitaires sont l'une des rares occasions où vous rencontrerez des noms de variables cryptiques dans Elasticsearch, comme rS et muBarSInverse.

La façon recommandée par l'auteur pour lire un article : avec un grand café.

Vous pouvez envoyer un courriel à l'auteur

Lorsque vous travaillez sur un document difficile, vous pouvez passer des heures à réfléchir à une formule, sans savoir si vous avez mal compris ou s'il s'agit simplement d'une erreur de frappe. S'il s'agissait d'un projet open source, vous pourriez poser une question sur GitHub ou StackOverflow. Mais à qui s'adresser pour obtenir un travail universitaire ? Les auteurs semblent occupés et pourraient être ennuyés par vos courriels.

Au contraire, de nombreux universitaires aiment entendre que leurs idées sont mises en pratique et sont heureux de répondre à des questions par courrier électronique. Si vous travaillez sur un produit qu'ils connaissent bien, il se peut même qu'ils listent l'application sur leur site web !

Les universitaires ont également de plus en plus tendance à discuter de leurs articles en public, en utilisant les mêmes outils que ceux utilisés pour le développement de logiciels. Si un article est accompagné d'un logiciel, vous pouvez trouver des réponses aux questions les plus courantes sur Github. Les communautés Stack Exchange telles que "Theoretical Computer Science" et "Cross Validated" contiennent également des discussions détaillées sur les articles les plus populaires. Certaines conférences ont commencé à publier en ligne tous les comptes rendus d'articles. Ces revues contiennent des discussions avec les auteurs qui peuvent apporter des informations utiles sur l'approche.

A suivre

Cet article se concentre sur les bases du choix d'un document académique et sur la manière de le choisir.

L'algorithme doit être mis en œuvre correctement, mais il ne couvre pas tous les aspects du déploiement réel de l'algorithme. Par exemple, si l'algorithme n'est qu'un élément d'un système complexe, comment s'assurer que les modifications apportées à cet élément conduisent à des améliorations de bout en bout ? Et que se passe-t-il si l'intégration de l'algorithme nécessite des modifications ou des extensions substantielles que l'article original ne couvre pas ? Il s'agit là de sujets importants sur lesquels nous espérons revenir dans de prochains articles.