Des graphes plus statistiques que sémantiques
A la suite de Wikidata, dans la série « utiliser les knowledge Graph à bon escient », cet article traite du cas LinkedIn Skills Graph. Ce n’est pas non plus un usage de Knowledge Graph au sens de la définition donnée dans mon article chapeau. C’est un cas sans ontologie formelle et sans raisonneur, avec de l’apprentissage automatique.
Il s’agit là d’une trajectoire similaire à celles des graphes d’Uber et d’Amazon, d’après la documentation publique disponible. Le modèle de leurs graphes repose apparemment sur un socle de taxonomies et de relations typées, construit et maintenu majoritairement par apprentissage automatique et gouvernance organisationnelle, plutôt que par une ontologie en logique de description axiomatisée.
La rigueur sémantique se déplace ainsi du niveau « schéma logique vérifiable » vers le niveau « pipeline de qualité statistique ». Cela rejoint l’argument souvent avancé par les praticiens de ces graphes (Uber en particulier) : le coût d’acquisition de compétences en ontologie et de maintenance d’un raisonneur DL est jugé disproportionné par rapport au bénéfice, à l’échelle et au rythme de changement de ces données.
Les graphes LinkedIn Skills Graph ainsi que Economic Graph qui l’étend, ne sont clairement pas des biens publics interopérables. Ce sont des actifs propriétaires destinés à supporter des services différenciés d’expériences « produit ». Le partage de la connaissance n’est pas le sujet.
Un exemple hors standards quand l’enjeu n’est pas l‘interopérabilité
La lecture du cas LinkedIn à travers le prisme du modèle d’affaires, rationnalise les choix d’architecture pour le graphe en éclairant l’intention sous-jacente. L’interopérabilité n’est pas la cible et la valeur n’est pas tant dans le métamodèle des compétences, finalement réplicable, que dans le volume de données et leur mise à jour dynamique. LinkedIn a créé une infrastructure interne de captation de valeur, davantage qu’un Knowledge Graph en tant que support de ressources de connaissance à partager. Le Skills Graph est un actif propriétaire qui alimente des produits payants.
Une interopérabilité poussée avec un référentiel ouvert (par exemple ESCO) réduirait la différenciation et faciliterait la portabilité des données vers des concurrents ou d’autres plateformes. Ce qui serait potentiellement contraire à l’intérêt économique d’un acteur qui monétise justement cette couche sémantique. Le Skills Graph alimente les produits de son offre Talent solutions (LinkedIn Recruiter, Talent Insights…) et la recherche Economic Graph. L’interopérabilité normative n’apparaît nulle part dans cette chaîne de valeur documentée.
ESCO et O*Net : des standards, pas des ontologies
Deux référentiels majeurs émergent à l’international : O*Net aux Etats-Unis, présenté par le département du travail comme la base d’outils fédéraux, et ESCO, le cadre normatif de classification des compétences de la commission européenne.
En pratique, ESCO et O*Net ont une utilisation plutôt limitée à un écosystème institutionnel (chercheurs et responsables publics). Néanmoins il est avisé de les utiliser, en tant que standards favorisant l’interopérabilité, comme bases d’une taxonomie fondatrice d’entreprise. Il faudrait toutefois ajouter des sources de données temps réel comme LinkedIn pour capter les compétences émergentes que les référentiels formels n’ont pas encore cataloguées.
Car la mise à jour de nouvelles versions de référentiels standards, fondée sur un consensus, est souvent en décalage avec le rythme d’évolution des compétences. Pour pallier cette lenteur, une approche semi-automatisée de text mining a été proposée en 2021 pour accélérer l’alignement d’ESCO avec les changements technologiques rapides de l’industrie 4.0 et plus récemment encore, le cadre open source ESCOPlus a été spécialement conçu pour améliorer la taxonomie en intégrant des compétences numériques émergentes (via Stack Overflow).
Cependant, si on soulève le « capot » des métamodèles, pas plus ESCO que O*Net ne sont des ontologies formelles en langage de description. Ni l’un ni l’autre ne peuvent servir au raisonnement ni à la désambiguation. Au mieux, ils peuvent servir à la classification (étiqueter des documents). Il est d’ailleurs frappant que le crosswalk développé par la commission européenne pour faire le pont entre ESCO et O*Net se base sur un algorithme d’IA de similarité textuelle. Il n’y a pas de logique formelle dans la déclaration des concepts. Aussi bien ESCO que O*Net peuvent servir à l’interopérabilité, mais pas à l’interopérabilité sémantique.
Pourquoi la valeur n’est pas dans le métamodèle
Si on compare le métamodèle du Skills Graph avec ESCO, on trouvera que ce dernier répertorie 13939 aptitudes pour les compétences et/ou connaissances contre 41K pour LinkedIn. Mais cette comparaison ignore deux choses : l’ampleur de l’Economic Graph, qui couvre l’ensemble des données LinkedIn (1 milliard de membres, 67 millions d’entreprises, 133 000 écoles), et sa mise à jour continue.
La richesse du graphe LinkedIn vient précisément du fait que chaque nœud a un voisinage contextuel riche connecté à d’autres types de nœuds. Ainsi un membre est connecté à ses compétences, à l’entreprise où il travaille, à son titre, à son école, etc. ; chaque compétence, à son tour, est connectée à tous les membres qui la partagent et à tous les emplois qui la requièrent. La densité des connexions croisées inter-types dans l’Economic Graph complet constitue dès lors le véritable avantage structurel.
Certes, en observant les profils et les offres d’emploi publics, un acteur pourrait en principe construire une liste de ~40 000 libellés de compétences comparable au modèle conceptuel utilisé par LinkedIn (taxonomie polyhiérarchique + lignées de connaissance parent/enfant).
Mais il n’aurait pas la mise à jour en continu de ce modèle et la capacité à appliquer du machine learning pour faire passer à l’échelle la construction de la taxonomie. Pas plus qu’il n’aurait de boucles de rétroaction produit à travers les retours des recruteurs, ou des candidats et les badges de compétence validés. Ces dernières constituent un mécanisme de validation continue impossible à répliquer hors de l’écosystème LinkedIn, car il dépend de l’usage massif de la plateforme elle-même.
La valeur est dès lors obtenue par l’entraînement permanent d’un modèle ML (KGBert) par un flux propriétaire continu d’énormes volumes d’information sous forme de profils, requêtes de recruteurs, clics candidats, éditions de suggestions IA par les recruteurs, résultats de Skill Assessments, etc. Un tiers qui obtiendrait la liste des labels de compétences n’obtiendrait ni les poids du modèle, ni les scores de confiance, ni la capacité de mise à jour continue au même rythme.
Ainsi, même une réplication parfaite du vocabulaire ESCO-compatible ne donnerait aucun avantage concurrentiel à LinkedIn, puisque la valeur n’est pas dans la nomenclature mais dans le graphe relationnel complet et propriétaire qui l’entoure. D’où l’absence d’incitation visible à investir dans l’interopérabilité.
L’architecture du Graphe LinkedIn
Pour mieux comprendre, penchons-nous sur l’architecture du graphe LinkedIn. Ce dernier est basé sur un moteur de graphe propriétaire LIquid, avec en amont de la construction du graphe, des pipelines de standardisation de données (« Data Standardization ») où le Machine Learning produit les taxonomies et relations, ensuite chargées dans LIquid pour le service en temps réel.
La suite de l’article détaille les trois aspects suivants
- Pipeline de transformation texte brut vers compétences taggées
- Construction de la taxonomie
- Construction du graphe et exploitation produit
Pipeline de transformation texte brut vers compétences taggées
Ce pipeline permet, à partir de texte libre (profils, requêtes de recherche d’emploi, descriptions de poste), d’extraire des termes candidats à être des compétences.
Le pipeline ingère plusieurs types de documents non structurés : profils membres, offres d’emploi publiées par les recruteurs, CV téléversés, descriptions de cours (LinkedIn Learning), et posts du feed. Chaque type a son propre format et son propre bruit, ce qui justifie un traitement en amont différencié plutôt qu’un unique flux de texte homogène.
Découpage en zones fonctionnelles
Avant même de chercher des mentions de compétences, LinkedIn découpe le document source en zones fonctionnelles distinctes, parce que la position d’une mention dans le document est elle-même un signal de pertinence. Pour une offre d’emploi, on identifie par exemple les blocs « description de l’entreprise », « responsabilités », « avantages » et « qualifications ». Une compétence citée dans « qualifications » pèse davantage qu’une compétence citée dans « description de l’entreprise » (qui parle souvent de la culture de l’entreprise, pas du poste). Pour un CV ou un profil, la logique est identique : distinguer la section « compétences » déclarée explicitement par le membre des sections « expériences » ou « résumé », où des compétences peuvent être mentionnées de façon incidente dans une phrase narrative plutôt qu’en liste.
C’est une étape purement structurelle (analyse de mise en forme, repérage d’en-têtes, de puces, de blocs de texte typés), qui ne cherche pas encore à identifier de compétences précises mais prépare le terrain pour que les étapes suivantes sachent pondérer différemment selon la zone d’où vient chaque mention.
Tagging hybride
Deux mécanismes tournent en parallèle sur chaque zone segmentée. Le premier est un algorithme de dictionnaire classique, sans apprentissage, qui parcourt le texte token par token pour retrouver des correspondances exactes ou quasi-exactes avec les libellés déjà connus de la taxonomie. L’algorithme est très rapide, mais aveugle à tout ce qui n’est pas formulé comme dans le dictionnaire. Le second mécanisme est un modèle two-tower basé sur BERT multilingue (donc un modèle de langue, mais pas un LLM génératif au sens actuel). Il encode séparément (deux tours découplées) une phrase et un nom de compétence en deux vecteurs, puis compare leur similarité. Ce qui permet de repérer des compétences qui ne sont jamais nommées littéralement. Par exemple, une phrase parlant de « conception d’applications iOS » peut faire remonter la compétence « Développement mobile » sans que ces mots y figurent.
Expansion structurelle
Une fois quelques compétences taguées avec certitude, le système interroge le graphe déjà construit pour élargir automatiquement l’ensemble aux compétences voisines dans la hiérarchie (parents, enfants, compétences sœurs du même groupe). C’est une étape purement symbolique (traversée de graphe), sans nouveau modèle de langage : elle exploite la structure de la taxonomie plutôt que le contenu textuel lui-même.
Scoring multitâche
Pour décider du statut d’une compétence candidate, i.e, « compétence requise », « compétence centrale », « compétence simplement mentionnée », un Transformer partagé, complété par des têtes de prédiction spécifiques combine les embeddings déjà calculés avec des features manuelles comme le taux de cooccurrence entre entités. C’est le résultat de cette étape (une compétence, un score de confiance, un statut) qui devient l’arête candidate transmise au pipeline de construction de taxonomie.
Pipeline de construction de la taxonomie
Filtre de cooccurrence
Cette étape ne part pas de zéro : elle exploite les données d’usage réel accumulées par LinkedIn pour repérer quelles paires de compétences sont susceptibles d’être liées hiérarchiquement. Le critère retenu est la cooccurrence : deux termes qui apparaissent ensemble dans une même fenêtre contextuelle (un profil, une offre) suffisamment souvent (le seuil documenté est cinq occurrences minimum) sont de bons candidats à une relation parent/enfant. C’est un filtre purement statistique, sans aucun jugement sémantique à ce stade. Il sert uniquement à réduire l’espace de paires à examiner.Classification supervisée pour l’hypothèse de structuration
Chaque paire candidate retenue est ensuite soumise à un modèle supervisé inspiré de KG-BERT. Les deux compétences sont converties en une phrase contextuelle synthétique générée automatiquement, pas extraite brute d’un corpus, pour éviter le bruit et les biais de fréquence. Cette phrase est encodée par une couche BERT affinée, puis une tête de classification tranche entre trois issues possibles : « A est parent de B », « A est enfant de B », ou « aucune relation ». C’est cette étape qui fait le gros du travail de structuration : elle transforme une simple association statistique (la cooccurrence de l’étape précédente) en une hypothèse de relation hiérarchique typée.Revue taxonomistes
Les prédictions de KGBert ne sont jamais injectées automatiquement dans la taxonomie finale: elles passent par une équipe humaine dédiée, qui assainit la liste (suppression des termes obsolètes ou mal formés), désambiguïse les cas ambigus par examen des métadonnées d’usage réel, puis valide ou rejette les relations proposées. C’est le point de contrôle qualité central du pipeline : le score de confiance maximal (1) n’est attribué qu’aux données ayant reçu cette validation humaine explicite. Le résultat final de ce processus est ce que LinkedIn appelle une lignée de connaissance (knowledge lineage) : une chaîne de relations parent/enfant propre, cohérente et assignée manuellement en dernier ressort par les taxonomistes, qui vient enrichir le framework « Structured Skills ». C’est cet état final qui est écrit comme arêtes assertées dans le graphe de stockage LIquid (décrit dans le paragraphe suivant). Tout ce qui précède (cooccurrence, prédiction KGBert) reste une hypothèse de travail interne au pipeline de construction, invisible du graphe servi en production tant qu’elle n’a pas franchi cette étape de validation.Construction du graphe et exploitation produit
Les lignées validées à l’étape précédente sont écrites comme arêtes (triplets sujet-prédicat-objet) dans LIquid. Ce moteur de graphe propriétaire a été développé en interne par LinkedIn pour servir l’Economic Graph en temps réel humain (interactions utilisateur). Il est en production chez LinkedIn depuis plusieurs années. Le créateur, Scott Meyer, vient de Metaweb/Freebase, le graphe world-writable qui est devenu la base du Knowledge Graph de Google (et de Microsoft).
Son modèle de données est l’implémentation complète du modèle relationnel, où les arêtes sont des triplets de chaînes (sujet, prédicat, objet). Si la structure est proche du triple RDF dans sa forme, elle est sans conformité aux standards W3C (pas d’IRI, pas de types de données XSD, pas de sémantique RDFS/OWL). Si le modèle relationnel reste simple, il est capable de représenter des relations n-aires complexes façon property graph, avec une couche de requête déclarative basée sur Datalog, permettant des traversées de graphe à temps constant.
Datalog ne fait que composer des traversées et jointures logiques sur des faits déjà assertés en amont par les pipelines ML des deux diagrammes précédents. C’est un moteur de très haute performance (des ordres de grandeur de plusieurs millions de requêtes par seconde sur des centaines de milliards d’arêtes, avec des latences inférieures à 50 ms), optimisé pour la génération rapide de candidats plutôt que pour le classement fin.
Venice
LIquid seul répond à la question « quelles entités sont reliées à quoi », mais pas à « dans quel ordre les présenter à l’utilisateur ». C’est le rôle de Venice, un magasin de features (feature store) qui conserve des valeurs précalculées par des modèles de machine learning. Il s’agit de scores d’affinité, d’embeddings, de signaux comportementaux agrégés, prêts à être consultés à faible latence au moment de classer les candidats renvoyés par LIquid. Venice ne génère pas ces features en temps réel. Il les sert, après qu’elles ont été calculées en amont par des pipelines d’apprentissage séparés.
Pinot
En parallèle de Venice, Apache Pinot apporte une capacité d’analytique en temps réel, c’est-à-dire, des agrégations et statistiques fraîches. Par exemple, la popularité récente d’une compétence dans une région donnée, ou le volume de recherches associées. Ce qui complète les features plus stables de Venice avec des signaux de contexte immédiat. La combinaison des deux permet au système de ranking de mélanger mémoire longue (Venice) et signal instantané (Pinot).
Produits
C’est la sortie finale visible par l’utilisateur : les candidats générés par une requête LIquid sur l’Economic Graph, classés à l’aide des features Venice et des insights Pinot, alimentent directement des fonctionnalités commerciales concrètes. La recherche de candidats pour les recruteurs (Recruiter), les recommandations LinkedIn Learning, le matching d’offres d’emploi, et les rapports Talent Insights.
La gouvernance des métadonnées et la découverte des jeux de données dérivés du graphe transitent par DataHub, qui documente le schéma et les champs de chaque jeu de données, mais qui est un catalogue de métadonnées et non un moteur de validation de contraintes de type SHACL.
La qualité est aussi validée a posteriori par des boucles de rétroaction produit. Par exemple, recruteurs éditant des suggestions de compétences générées par IA, candidats signalant des compétences non pertinentes, et Skill Assessments où un score au 70e percentile ou plus délivre un badge vérifié. C’est donc une forme de validation distribuée par les utilisateurs eux-mêmes, en complément (pas en remplacement) de la validation taxonomiste.
Conclusion
Le graphe de compétences (Skills Graph) de LinkedIn est un artefact produit, optimisé pour le matching, la recherche, les recommandations. Chaque brique du pipeline de sa construction existe pour alimenter ce produit monétisé, jamais pour produire un artefact de connaissance interopérable de façon autonome.
Nulle part dans ce pipeline il n’y a de moteur de règles logiques ou de raisonneur d’ontologie formelle. Les standards du Web sémantique (RDF, RDFS, OWL, SHACL, SWRL) ne sont pas utilisés et aucun raisonnement de type DL n’intervient.
Le modèle est un schéma de taxonomies hiérarchiques (nœuds/arêtes typées « parent »/ »enfant »/ »lié à ») et de relations typées construit et maintenu très majoritairement par apprentissage automatique (classification d’entités, désambiguïsation, clustering). Le système de requête (LIquid) introduit toutefois un modèle relationnel strict avec un schéma explicite et un langage déclaratif inspiré de Datalog.
C’est une séparation nette entre couche d’inférence sémantique probabiliste (les modèles ML, qui produisent les arêtes avec un score de confiance) et couche de requête déductive (LIquid/Datalog, qui exploite ces arêtes une fois assertées). Les deux ne se confondent jamais dans un même moteur de raisonnement unifié.
LinkedIn mobilise cette infrastructure pour fournir des insights dérivés du graphe complet à des tiers (gouvernements, chercheurs), sans jamais céder l’accès à la structure et aux poids du graphe lui-même.
Nous avons ici un « knowledge » graph nommé tel, cohérent avec son but : supporter des intérêts privés en gardant un écosystème fermé. La question toutefois demeure : est-ce que le marché du travail ne mériterait pas plus d’initiatives en vue d’une vraie interopérabilité sémantique ? La réponse à cette question se heurte malheureusement à l’évolution rapide des compétences et la bascule de l’acquisition et la structuration des connaissances vers l’exploitation analytique de gros volumes de données.
Le prochain cas d’usage de Knowledge Graph abordera un cas particulièrement pertinent pour le partage des connaissances : la NASA, avec Stardog.
Sources
https://www.linkedin.com/blog/engineering/knowledge/building-the-linkedin-knowledge-graph https://www.linkedin.com/pulse/building-linkedins-skills-graph-power-skills-first-world-macsk%C3%A1ssy/ Building and maintaining the skills taxonomy that powers LinkedIn's Skills Graph How LinkedIn is moving towards a skills-based economy with the Skills Graph | by George Anadiotis | Medium https://www.linkedin.com/blog/engineering/graph-systems/liquid-the-soul-of-a-new-graph-database-part-1 https://www.linkedin.com/blog/engineering/graph-systems/liquid-the-soul-of-a-new-graph-database-part-2