Three different things get sold as "AI matching". They work differently and they fail differently. Knowing which one you have explains most of what you will see in your results.
1. Keyword matching
The oldest method. Does this word appear in this document? Fast, cheap, completely predictable, and you can always say exactly why something matched.
What it cannot do is understand meaning. It misses every alternative word you did not think of, every short form, every regional variation.
It also cannot tell the difference between a skill someone has and a skill they mention. "No experience with Kubernetes" matches a search for Kubernetes. And it rewards stuffing your CV with keywords, which candidates now do at scale because they know it works.
Good for: hard requirements with a fixed vocabulary — a licence number, a named certificate, a specific legal framework. Anything where you want a rule that does exactly what it says.
2. Semantic matching
"Semantic" just means based on meaning. The software turns text into a form that captures what it is about, then compares candidates to the job.
In practice, this means different wording still matches. "Built ETL pipelines" and "developed data ingestion workflows" end up close together without you having to list both.
Where it goes wrong:
- It matches the topic, not the requirement. Someone who writes a lot about a subject scores near someone who has done it. A person who managed data engineers ends up close to a data engineer, because the words are about the same things.
- It is bad at "not". "Never worked in fintech" and "worked in fintech" look very similar. People find this the most surprising failure.
- Longer documents score higher. More text means more chances to look relevant. That favours people who write fluent professional English, which is not the skill you are hiring for in most jobs.
Good for: putting a pile in order when the relevant experience gets described many different ways — which is most professional jobs.
3. Learning from your past hires
The software looks at who you hired before and ranks people by how much they resemble them. Usually sold as the most advanced option.
Two problems, and neither is fixed by better software.
What counts as a good example? People you hired? People who got past screening? Both are records of past decisions, not of how well anyone did the job. Unless you are feeding in performance data — and almost nobody is, because it is messy, delayed and sensitive — the system is learning to copy your screening decisions, including the ones you would not defend.
It inherits whatever was there. Any pattern in your past hiring gets built in, including things you never chose. "Find candidates like our best hires" is an instruction to repeat the past — and the past is usually what people are trying to change.
Good for: very high volume, with real performance data and a bias check attached. Rare.
Which to use
| Situation | Use |
|---|---|
| A hard, checkable requirement | Keyword, as a filter |
| Putting a professional pool in order | Semantic |
| Small pool, high stakes | Semantic to order, then read everyone |
| Very high volume with real outcome data | Learning, with a bias check |
| You cannot tell which the tool uses | Ask. If the answer is vague, assume learning |
What good setups actually do
Keywords for the two or three genuine must-haves, because you want those to behave exactly as written. Semantic matching to order everything that gets through, because that is where the different-wording problem lives. And learning from past hires switched off until someone has checked it — which, for most teams, means off.
One question for your supplier
"If I remove all my own rules, does the ranking change?" If it still produces an order, something is ranking on things you did not ask for. You need to know what.