Skills-matching algorithm

Platform, partners, and integrations.

Ethiopia's public employment service is delivered through a network of physical Job Centers managed by MoLS and its digital backbone, the E-LMIS . Tabiya supports the redesign of the Job Centers' workflows and operating procedures and has shared its open-source matching engine with the E-LMIS team, whose engineers are integrating it into their new platform.

Integrating an improved skills-based matching algorithm

Previously, the E-LMIS matched jobseekers to vacancies with a basic, deterministic rule based on skill overlap, and its skills data was a flat list of ~25,000 entries not aligned to any international standard. Tabiya's matching service replaces this rule-based matching with a skill-to-skill matching algorithm that compares every skill a jobseeker holds against every skill a vacancy requires in a shared semantic space, so that closely related skills, not only identical ones, count toward a match. Each required skill is scored against the jobseeker's nearest equivalent on a continuous 0–1 scale. Skill similarity is the core signal, which the service then combines with location, jobseeker preferences, education eligibility, and labour-market demand to produce a final ranking.

---

How the matching engine works

Matching runs on a structured skills profile, not keyword search. The engine compares what a person can do against what a vacancy requires, weighs that against what the person wants and how likely an employer is to hire them, and returns a ranked shortlist a counsellor and jobseeker can act on.

1

Map both sides onto a shared skills taxonomy

Jobseeker profiles and vacancy descriptions are resolved onto the same ~14,000 skills repository of the localized Ethiopian taxonomy, so a skill described differently on a CV and in a job advert resolves to a single entry.

2

Place every skill in a semantic space

Each skill is represented as a vector positioned by meaning, letting the engine measure how close any two skills are rather than only whether they are identical. This is what allows related and transferable skills to count toward a match.

3

Shortlist the closest candidates with a fast pass

Each jobseeker's skills are averaged into one vector, and that profile is compared against the job in one fast sweep. Using FAISS, the candidates whose skills sit closest to what the role needs rise to the top; the nearest 50 or so continue.

4

Score each shortlisted candidate skill by skill

For every skill a vacancy requires, the engine finds the jobseeker's closest skill and scores that pair from 0 to 1. Essential requirements are combined strictly, so a serious gap in a must-have skill pulls the score down and cannot be offset by strength elsewhere. Optional skills add credit more gently.

5

One final ranking

The skill score is combined with the jobseeker's stated preferences and with an estimate of how likely an employer is to hire them — essential-skill coverage, wider readiness, and current demand for the role.

Running on models the government has full ownership of:

The matching service depends on models to classify vacancies, place skills in semantic space and to re-read the shortlist. These can be commercial services reached over an API, or open-weight models hosted on infrastructure the government runs. As part of this work, the two teams are testing and optimizing the engines for the second option.

Local deployment keeps jobseekers' personal data on systems the government administers rather than passing it to an external provider, addressing data sovereignty requirements for a national system holding personal records. It also removes the per-request cost of matching, which makes the service more affordable to operate at the volumes a full Job Center network generates.