Encodez des propriétés de texte multilingues dans Amazon Neptune pour former des modèles prédictifs

Amazon Neptune ML est une capacité d'apprentissage automatique (ML) de Amazone Neptune qui vous aide à faire des prédictions précises et rapides sur vos données graphiques. Sous le capot, Neptune ML utilise des réseaux de neurones graphiques (GNN) pour tirer simultanément parti de la structure du graphe et des propriétés des nœuds/arêtes pour résoudre la tâche à accomplir. Les méthodes traditionnelles utilisent uniquement des propriétés et aucune structure de graphe (par exemple, XGBoost, Neural Networks), ou uniquement une structure de graphe et aucune propriété (par exemple, node2vec, Label Propagation). Pour mieux manipuler les propriétés nœud/bord, les algorithmes ML exigent que les données soient des données numériques bien comportées, mais les données brutes d'une base de données peuvent avoir d'autres types, comme du texte brut. Pour utiliser ces autres types de données, nous avons besoin d'étapes de traitement spécialisées qui les convertissent de leur type natif en données numériques, et la qualité des résultats ML dépend fortement de la qualité de ces transformations de données. Le texte brut, comme les phrases, fait partie des types les plus difficiles à transformer, mais les progrès récents dans le domaine du traitement du langage naturel (TAL) ont conduit à des méthodes puissantes capables de gérer du texte provenant de plusieurs langues et d'une grande variété de longueurs.

Depuis la version 1.1.0.0, Neptune ML prend en charge plusieurs encodeurs de texte (text_fasttext, text_sbert, text_word2vecet text_tfidf), qui apportent les avantages des avancées récentes du NLP et permettent la prise en charge des propriétés de texte multilingues ainsi que des exigences d'inférence supplémentaires concernant les langues et la longueur du texte. Par exemple, dans un cas d'utilisation de recommandation d'emploi, les offres d'emploi dans différents pays peuvent être décrites dans différentes langues et la longueur des descriptions d'emploi varie considérablement. De plus, Neptune ML prend en charge un auto option qui choisit automatiquement la meilleure méthode d'encodage en fonction des caractéristiques de l'élément de texte dans les données.

Dans cet article, nous illustrons l'utilisation de chaque encodeur de texte, comparons leurs avantages et leurs inconvénients et montrons un exemple de la façon de choisir les bons encodeurs de texte pour une tâche de recommandation de travail.

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

L'objectif de l'encodage de texte est de convertir les propriétés de bord/nœud basées sur le texte dans Neptune en vecteurs de taille fixe à utiliser dans des modèles d'apprentissage automatique en aval pour des tâches de classification de nœuds ou de prédiction de liens. La longueur de la fonction de texte peut varier considérablement. Il peut s'agir d'un mot, d'une expression, d'une phrase, d'un paragraphe ou même d'un document contenant plusieurs phrases (la taille maximale d'une seule propriété est de 55 Mo dans Neptune). De plus, les fonctionnalités de texte peuvent être dans différentes langues. Il peut aussi y avoir des phrases qui contiennent des mots dans plusieurs langues différentes, que nous définissons comme commutation de code.

À partir de la version 1.1.0.0, Neptune ML vous permet de choisir parmi plusieurs encodeurs de texte différents. Chaque encodeur fonctionne légèrement différemment, mais a le même objectif de convertir un champ de valeur de texte de Neptune en un vecteur de taille fixe que nous utilisons pour construire notre modèle GNN à l'aide de Neptune ML. Les nouveaux encodeurs sont les suivants :

• text_fasttext (nouveau) – Usages texte rapide codage. FastText est une bibliothèque pour un apprentissage efficace de la représentation de texte. text_fasttext est recommandé pour les fonctionnalités qui utilisent une et une seule des cinq langues prises en charge par fastText (anglais, chinois, hindi, espagnol et français). La text_fasttext méthode peut éventuellement prendre la max_length , qui spécifie le nombre maximal de jetons dans une valeur de propriété de texte qui sera codée, après quoi la chaîne est tronquée. Vous pouvez considérer un jeton comme un mot. Cela peut améliorer les performances lorsque les valeurs de propriété de texte contiennent de longues chaînes, car si max_length n'est pas spécifié, fastText encode tous les jetons quelle que soit la longueur de la chaîne.
• text_sbert (nouveau) - Utilise la phrase BERT (Sbert) méthode de codage. SBERT est une sorte de méthode d'incorporation de phrases utilisant les modèles d'apprentissage de représentation contextuelle, BERT-Networks. text_sbert est recommandé lorsque la langue n'est pas prise en charge par text_fasttext. Neptune prend en charge deux méthodes SBERT : text_sbert128, qui est la valeur par défaut si vous spécifiez simplement text_sbertet text_sbert512. La différence entre eux est le nombre maximum de jetons dans une propriété de texte qui sont encodés. La text_sbert128 encoding n'encode que les 128 premiers jetons, alors que text_sbert512 encode jusqu'à 512 jetons. En conséquence, en utilisant text_sbert512 peut nécessiter plus de temps de traitement que text_sbert128. Les deux méthodes sont plus lentes que text_fasttext.
• text_word2vec - Les usages Mot2Vec algorithmes initialement publiés par Google pour encoder du texte. Word2Vec ne prend en charge que l'anglais.
• text_tfidf – Utilise un terme fréquence-fréquence de document inverse (TF-IDF) vectoriseur pour encoder du texte. Le codage TF-IDF prend en charge des fonctionnalités statistiques que les autres codages ne prennent pas en charge. Il quantifie l'importance ou la pertinence des mots dans une propriété de nœud parmi tous les autres nœuds.

Notez que text_word2vec ainsi que text_tfidf étaient auparavant pris en charge et les nouvelles méthodes text_fasttext ainsi que text_sbert sont recommandés par rapport aux anciennes méthodes.

Comparaison de différents encodeurs de texte

Le tableau suivant montre la comparaison détaillée de toutes les options de codage de texte prises en charge (text_fasttext, text_sbertet text_word2vec). text_tfidf n'est pas une méthode d'encodage basée sur un modèle, mais plutôt une mesure basée sur le nombre qui évalue la pertinence d'un jeton (par exemple, un mot) par rapport aux caractéristiques du texte dans d'autres nœuds ou bords, nous n'incluons donc pas text_tfidf en comparaison. Nous recommandons d'utiliser text_tfidf lorsque vous souhaitez quantifier l'importance ou la pertinence de certains mots dans une propriété de nœud ou de bord parmi toutes les autres propriétés de nœud ou de bord.)

Notez les conseils d'utilisation suivants :

• Pour les valeurs de propriété de texte en anglais, chinois, hindi, espagnol et français, text_fasttext est l'encodage recommandé. Cependant, il ne peut pas gérer les cas où la même phrase contient des mots dans plusieurs langues. Pour d'autres langues que les cinq qui fastText prend en charge, utilisez text_sbert codage.
• Si vous avez de nombreuses chaînes de texte de valeur de propriété plus longues que, par exemple, 120 jetons, utilisez le max_length champ pour limiter le nombre de jetons dans chaque chaîne qui text_fasttext encode.

Pour résumer, selon votre cas d'utilisation, nous vous recommandons la méthode d'encodage suivante :

• Si vos propriétés de texte sont dans l'une des cinq langues prises en charge, nous vous recommandons d'utiliser text_fasttext en raison de sa rapidité d'inférence. text_fasttext est le choix recommandé et vous pouvez également utiliser text_sbert dans les deux exceptions suivantes.
• Si vos propriétés de texte sont dans différentes langues, nous vous recommandons d'utiliser text_sbert car c'est la seule méthode prise en charge qui peut encoder des propriétés de texte contenant des mots dans plusieurs langues différentes.
• Si vos propriétés de texte sont dans une langue qui n'est pas l'une des cinq langues prises en charge, nous vous recommandons d'utiliser text_sbert car il prend en charge plus de 50 langues.
• Si la longueur moyenne de vos propriétés de texte est supérieure à 128, envisagez d'utiliser text_sbert512 or text_fasttext. Les deux méthodes peuvent utiliser l'encodage de séquences de texte plus longues.
• Si vos propriétés de texte sont en anglais uniquement, vous pouvez utiliser text_word2vec, mais nous vous recommandons d'utiliser text_fasttext pour son inférence rapide.

Démonstration de cas d'utilisation : tâche de recommandation d'emploi

L'objectif de la tâche de recommandation d'emploi est de prédire les emplois auxquels les utilisateurs postuleront en fonction de leurs candidatures précédentes, de leurs informations démographiques et de leurs antécédents professionnels. Ce poste utilise un jeu de données Kaggle ouvert. Nous construisons l'ensemble de données sous la forme d'un graphe de type à trois nœuds : JOB, utilisateuret ville.

Un emploi est caractérisé par son titre, sa description, ses exigences, sa ville et son état. Un utilisateur est décrit avec les propriétés de la majeure, du type de diplôme, du nombre d'antécédents professionnels, du nombre total d'années d'expérience professionnelle, etc. Pour ce cas d'utilisation, le titre du poste, la description du poste, les exigences du poste et les majeures sont tous sous forme de texte.

Dans l'ensemble de données, les utilisateurs disposent des propriétés suivantes :

• Région – Par exemple, CA ou 广东省 (chinois)
• Majeurs – Par exemple, Gestion des ressources humaines ou Lic Cytura Fisica (espagnol)
• Type de degré – Par exemple, Baccalauréat, Maîtrise, Doctorat ou Aucun
• Nombre d'historique de travail – Par exemple, 0, 1, 16, etc.
• Nombre total d'années d'expérience – Par exemple, 0.0, 10.0 ou NAN

Les tâches ont les propriétés suivantes :

• Titre – Par exemple, Assistant administratif ou Lic Cultura Física (espagnol).
• Description – Par exemple, « Ce poste d'adjoint administratif est chargé d'exécuter diverses fonctions de bureau et de soutien administratif dans les domaines des communications,… ». Le nombre moyen de mots dans une description est d'environ 192.2.
• Exigences – Par exemple, « EXIGENCES DE L'EMPLOI : 1. Souci du détail ; 2. Capacité à travailler dans un environnement au rythme rapide ; 3. Facturation…"
• Région: – Par exemple, CA, NY, etc.

Le type de nœud ville comme Washington DC et Orlando FL n'a que l'identifiant pour chaque nœud. Dans la section suivante, nous analysons les caractéristiques des différentes fonctionnalités de texte et illustrons comment sélectionner les encodeurs de texte appropriés pour différentes propriétés de texte.

Comment sélectionner différents encodeurs de texte

Pour notre exemple, le Majeurs ainsi que Titre les propriétés sont en plusieurs langues et ont de courtes séquences de texte, donc text_sbert est recommandé. L'exemple de code pour le paramètres d'exportation est comme suit. Pour le text_sbert type, il n'y a pas d'autres champs de paramètres. Ici on choisit text_sbert128 autre que text_sbert512, car la longueur du texte est relativement plus courte que 128.

"additionalParams": {
    "neptune_ml": {
        "version": "v2.0",
        "targets": [ ... ],
        "features": [
            {
                "node": "user",
                "property": "Major",
                "type": "text_sbert128"
            },
            {
                "node": "job",
                "property": "Title",
                "type": "text_sbert128",
            }, ...
        ], ...
    }
}

La Description ainsi que Exigences les propriétés sont généralement dans de longues séquences de texte. La longueur moyenne d'une description est d'environ 192 mots, ce qui est plus long que la longueur d'entrée maximale de text_sbert (128). On peut utiliser text_sbert512, mais cela peut entraîner une inférence plus lente. De plus, le texte est en une seule langue (anglais). Par conséquent, nous recommandons text_fasttext les en valeur du langage en raison de son inférence rapide et de sa longueur d'entrée non limitée. L'exemple de code pour le paramètres d'exportation est comme suit. La text_fasttext l'encodage peut être personnalisé à l'aide de langue ainsi que longueur maximaleL’ language valeur est requise, mais max_length Est facultatif.

"additionalParams": {
    "neptune_ml": {
        "version": "v2.0",
        "targets": [ ... ],
        "features": [
            {
                "node": "job",
                "property": "Description",
                "type": "text_fasttext",
                "language": "en",
                "max_length": 256
            },
            {
                "node": "job",
                "property": "Requirements",
                "type": "text_fasttext",
                "language": "en"
            }, ...
        ], ...
    }
}

Plus de détails sur les cas d'utilisation de recommandation de travail peuvent être trouvés dans le Tutoriel sur le carnet Neptune.

À des fins de démonstration, nous sélectionnons un utilisateur, à savoir l'utilisateur 443931, titulaire d'un Master en « Management et ressources humaines ». L'utilisateur a postulé à cinq emplois différents, intitulés "responsable des ressources humaines (RH)", "généraliste RH", "responsable des ressources humaines", "administrateur des ressources humaines" et "spécialiste principal de la paie". Afin d'évaluer les performances de la tâche de recommandation, nous supprimons 50 % des emplois d'application (les bords) de l'utilisateur (ici, nous supprimons "Human Resources Administrator" et "Human Resources (HR) Manager) et essayons de prédire le top 10 emplois pour lesquels cet utilisateur est le plus susceptible de postuler.

Après avoir encodé les caractéristiques de l'emploi et les caractéristiques de l'utilisateur, nous effectuons une tâche de prédiction de lien en formant un modèle de réseau convolutionnel de graphe relationnel (RGCN). La formation d'un modèle Neptune ML nécessite trois étapes : le traitement des données, la formation du modèle et la création du point de terminaison. Une fois le point de terminaison d'inférence créé, nous pouvons faire des recommandations pour l'utilisateur 443931. Parmi les 10 meilleurs emplois prévus pour l'utilisateur 443931 (c. Resources Administrator », « HR Analyst », et al.), on observe que les deux emplois supprimés font partie des 10 prédictions.

Conclusion

Dans cet article, nous avons montré l'utilisation des encodeurs de texte nouvellement pris en charge dans Neptune ML. Ces encodeurs de texte sont simples à utiliser et peuvent prendre en charge plusieurs exigences. En résumé,

• text_fasttext est recommandé pour les fonctionnalités qui utilisent une et une seule des cinq langues prises en charge par text_fasttext.
• text_sbert est recommandé pour le texte que text_fasttext ne prend pas en charge.
• text_word2vec ne prend en charge que l'anglais et peut être remplacé par text_fasttext dans n'importe quel scénario.

Pour plus de détails sur la solution, consultez le GitHub repo. Nous vous recommandons d'utiliser les encodeurs de texte sur vos données graphiques pour répondre à vos besoins. Vous pouvez simplement choisir un nom d'encodeur et définir certains attributs d'encodeur, tout en gardant le modèle GNN inchangé.

À propos des auteurs

Jiani Zhang est un scientifique appliqué d'AWS AI Research and Education (AIRE). Elle travaille sur la résolution d'applications du monde réel à l'aide d'algorithmes d'apprentissage automatique, en particulier les problèmes liés au langage naturel et aux graphes.