4 min read
How AI job matching actually works — and when a match score means anything
Keyword overlap, embeddings and LLM judgement produce very different match scores. What each method can and cannot see, and how to tell which one you're getting.
Every job tool now shows you a match score. The number looks the same everywhere — a percentage, a grade, a coloured ring — but the machinery behind it varies enormously, and the machinery is what decides whether the number is worth anything. There are three broad ways to compute "how well does this person fit this role", and they fail in different ways.
Method one: keyword overlap
The oldest and still the most common. Extract terms from the posting, extract terms from the CV, count the intersection. The posting says Python, your CV says Python — a point. Say it more times, more points.
This is cheap, fast, and explains most of the match scores you have seen. It is also vocabulary matching, not fit matching. It cannot distinguish a staff engineer from a graduate when both CVs contain the same technology names. It scores adjacent experience — the thing you did that isn't named in the posting but is obviously the same skill — as zero. And it is trivially gamed, which is why the folk advice about stuffing your CV with the posting's phrasing exists.
If a tool's score moves dramatically when you paste in synonyms, this is what you're using.
Method two: embeddings
The step up. Both the posting and your CV are converted into vectors — long lists of numbers encoding meaning — and similarity is measured geometrically. Embeddings do capture the fact that "built ETL pipelines" and "data engineering" are the same idea in different words, which fixes keyword matching's blindness to phrasing.
What embeddings still can't do is reason. Similarity is symmetric and requirements are not: a posting that requires five years of production experience is semantically close to a CV describing one internship in the same stack, and the vectors will happily report the resemblance. Embeddings answer "are these two documents about the same topic?" — which is necessary, and genuinely useful for surfacing candidates from a large pool — but the question you care about is "should this person spend an evening applying?", and that's a different question.
Method three: an actual reading
The expensive option: have a language model read the posting and the CV and make the comparisons a recruiter would. Which of the fifteen listed technologies are genuinely required and which are wishlist. Whether the seniority matches. Whether a gap is bridgeable ("has done the same job in a different stack") or fundamental ("has never done this job"). Whether the role fits where the candidate is trying to go, not just where they've been.
This is the only method that produces a score you can argue with, because it can produce reasons alongside the number. It is also too expensive to run on every posting on the internet, which points at the architecture that actually works in practice.
Why the practical answer is a pipeline
Quarrion runs the three methods as tiers rather than picking one. Cheap rule-based filtering discards the obviously wrong first — wrong country, wrong seniority band, a duplicate of a listing already seen. A fast AI pass scores what survives. Only the roles that clear that bar get the expensive treatment: a deeper research pass that reads properly, checks the details and tags what it found.
The economics are the point. Spending real reasoning on four hundred postings is wasteful; spending it on the thirty that survived triage is how you afford to do it well. The tier structure is what lets the final scores come from actual reading rather than word-counting, without the cost making the product impossible.
How to evaluate any match score
Whatever tool you're using, three questions separate a meaningful score from a decorative one:
Does it show its reasoning? A bare number is unfalsifiable. If the tool can say why — required skill covered, seniority aligned, salary band plausible — you can spot when it's wrong and correct it. If it can't, you'll trust it until the first obviously bad match, then never again.
Does it know the difference between required and nice-to-have? Show it a posting listing fifteen technologies. If a CV covering the four load-bearing ones scores worse than a CV name-checking ten peripheral ones, it's counting words.
Does it penalise seniority mismatch? Search a senior title with a junior profile. A pure similarity engine will cheerfully rank the senior roles at the top, because the vocabulary matches perfectly. A tool that reads will not.
A match score is a claim about your future time: apply here, not there. The machinery behind the claim decides whether following it is delegation or gambling — so it's worth the five minutes it takes to find out which machinery you're trusting.