LinkedIn: LLM-based skills extraction — 200 profile edits per second with a model 80% smaller at no quality loss

• Extracting skills from content to fuel the LinkedIn Skills Graph — LinkedIn Engineering Blog (Ji Yan et al.), 2023-12-13
• Building and maintaining the skills taxonomy that powers LinkedIn's Skills Graph (39K навыков, 374K алиасов, KGBert) — LinkedIn Engineering Blog (Macskássy et al.), 2023-03-21

Background

LinkedIn is methodically rebuilding the labor market around skills rather than titles and degrees: the company's bet is that a skills-first approach opens wider candidate pools for employers and career trajectories for professionals that a job title alone cannot convey. The technical foundation of the strategy is the Skills Graph: a taxonomy of skills linked to members, job postings, courses, and platform content.

The taxonomy's scale is described in a separate engineering post (March 2023): nearly 39,000 skills, 374,000 aliases across 26 locales (different spellings of one skill, like 'data analysis' and 'data analytics'), and more than 200,000 edges between nodes; since February 2021 the graph had grown almost 35%. Skills form a polyhierarchy of 'knowledge lineages': for instance, 'Offshore Construction' inherits from both 'Construction' and 'Oil and Gas'. Taxonomists maintain the graph in tandem with ML: the KGBert model (building on the KG-BERT idea) predicts skill relationships more than 20% better than the previous system by F1. By late 2023 the taxonomy exceeded 41,000 skills.

But the graph by itself is just a dictionary. Value emerges when every platform entity — profile, job posting, course, post — is correctly tagged with skills from that dictionary. In December 2023 the LinkedIn AI team (tech lead Ji Yan and co-authors) published a deep dive into the production pipeline that extracts skills from all platform content using LLM encoders — within hard production constraints: the global stream of profile edits on CPU infrastructure, with no costly GPUs.

Problem

Skills in profiles, job postings, and posts are free text, in dozens of languages, and often implicit: does 'built ETL pipelines' mean Spark? Airflow? SQL? Naive dictionary matching misses context and drowns in homonyms, while people name the same skill hundreds of ways — hence the 374,000 aliases in the taxonomy. And text must be linked not to abstract tags but to specific nodes in a 41,000-skill graph — including hierarchical inference: 'BERT' on a profile also says something about 'NLP' and 'Deep Learning'.

The other half of the problem is production constraints. Full-size LLMs are too slow and expensive for the edit stream: member profiles are edited roughly 200 times per second globally, and each message must be processed in under 100 milliseconds — on Samza-BEAM CPU streaming infrastructure, not GPU clusters. Periodic offline reprocessing of the entire corpus — hundreds of millions of profiles and postings — adds its own throughput requirements for the pipeline.

Finally, an extraction error is not an abstract metric: job recommendations, job search, candidate matching, and recruiter search all depend on skill tagging. A missed skill is a candidate who never saw the right job; a spurious one is an irrelevant application and a recruiter's wasted time. Extraction quality converts directly into the hiring funnel of the whole platform.

Solution

The extraction pipeline consists of four sequential stages. First, segmentation: unstructured text (a job posting, profile, resume) is parsed into structural sections — requirements here, responsibilities there, company description elsewhere. Then skill tagging via two parallel routes: token-based dictionary matching against the taxonomy and semantic matching. Semantics is handled by a two-tower model built on Multilingual BERT: one tower encodes the sentence, the other a taxonomy skill, and text is matched to skills in a shared vector space — so 'built data processing pipelines' finds 'ETL' without a literal match, in any supported language. The third stage is expansion: for the skills found, the pipeline walks the Skills Graph and adds related candidate nodes from the hierarchy. The final stage is multitask cross-domain scoring: a transformer-based contextual text encoder and an entity encoder (shared modules) plus separate towers per content type — job postings, profiles, feed — score the relevance of each content-skill pair.

The key move that made all this possible in real time is knowledge distillation: a compact student model trained to reproduce the full-size model's behavior came out 80% smaller with no performance loss. It is this model that serves the stream of ~200 profile edits per second at up to 100 ms per message — on existing Samza-BEAM CPU infrastructure, in a hybrid scheme: nearline processing of edits in real time plus offline jobs for full corpus reprocessing when models or the taxonomy update.

A separate loop is product feedback built right into the interfaces: recruiters confirm or correct skills when posting jobs, job seekers rate the relevance of matched skills when applying, and members give feedback after LinkedIn Skill Assessments. These signals flow back into training, closing the extraction improvement cycle. The extracted skills feed the Skills Graph and every product on top of it: job recommendations, job search, candidate matching. For the future the team named LLM-generated rich skill descriptions and a move to fully embedding-based skill representations for semantic matching.

Result

In production the system handles ~200 profile edits per second at up to 100 ms per message — on CPU, thanks to a distilled model 80% smaller than the original. In online A/B tests, improved skills extraction lifted metrics across three products at once. Job-member skills matching: +0.87% qualified applications, +0.40% qualified application rate, +0.48% apply clicks, +0.24% predicted confirmed hires. Job search: +0.76% PPC revenue, +0.15% sessions, +0.23% engagement. Job recommendations: +0.46% predicted confirmed hires and +0.14% applications.

These figures need two caveats. First, scale: on a platform with hundreds of millions of members, fractions of a percent in the hiring funnel are meaningful absolute values and direct money (PPC revenue). Second, the source: all percentages are LinkedIn's internal A/B tests from the engineering blog, with no external audit; that said, the detailed metric breakdown and the explicit 'predicted' (rather than actual) hires speak to the report's care.

In our view, the case's main engineering lesson is that 'LLM in production' almost never means 'the biggest model in production'. LinkedIn's actual formula: a large model as the teacher, a distilled student in serving, CPU infrastructure instead of GPU — and the pipeline's intelligence residing in the pairing with a knowledge graph rather than in one giant transformer. This is an 'LLM + knowledge graph' architecture where the taxonomy provides interpretability and control while the neural network provides context understanding; against the fashion for end-to-end solutions such a hybrid looks conservative, but it is what sustains 200 events per second on CPU.

Our second observation is organizational: LinkedIn reports the ML pipeline's impact in end-product metrics (applications, hires, revenue), not extraction accuracy. That is a discipline: an infrastructure team whose success is measured by other teams' product metrics is forced to build feedback loops with those products — which LinkedIn did by embedding skill validation into recruiter and job-seeker interfaces.

Lessons learned

1. Production LLM almost never means 'the biggest model' but a distilled one: −80% size at no quality loss made CPU serving within a 100 ms budget possible.
2. The 'LLM + knowledge graph' hybrid beats end-to-end: the taxonomy provides interpretability and hierarchical inference, the neural network provides context understanding and multilinguality.
3. Report impact in end-product metrics: LinkedIn cites qualified applications (+0.87%), PPC revenue (+0.76%), and predicted hires — not extraction accuracy alone.
4. Build feedback into the product: recruiter skill validation, job-seeker feedback, and Skill Assessment results flow back into training, closing the quality loop.
5. A two-tower architecture (text and taxonomy in a shared space) scales to new content types and 26 locales without retraining the whole pipeline.
6. On platforms with hundreds of millions of users, fractions of a percent are serious money: don't dismiss 'small' A/B wins.
7. A single skills graph as a shared data layer multiplies one ML pipeline's value across many products: search, recommendations, matching, recruiter tools.

Frequently asked questions