Match on meaning, not just matching words
Keyword search finds the candidates who happened to use your words. Semantic matching also finds the ones who described the same experience differently — the people already in your database that a literal search quietly skips.
Two signals, not one
Semantic scoring is added alongside the existing keyword search rather than replacing it, because the two are good at different things and you want both.
Meaning, as a number
Candidate profiles and a requisition are each turned into a vector, and closeness between them becomes a score — so "built distributed services in Go" can match a role asking for backend scalability work.
Keywords still count
Exact terms remain their own signal. A hard requirement spelled out in the requisition does not get diluted just because something reads as broadly similar.
Combined into one ranking
The two scores are weighed together, which keeps literal precision where it matters and adds reach where a strict term match would have returned nothing.
The matching step adds no outside call
The model that turns text into vectors is small enough to run inside your own deployment, on ordinary CPU. That has consequences worth caring about.
Candidate text stays put
Scoring a match does not ship profiles to a third-party embedding service, because the embedding happens in your own deployment.
No per-match bill
Matching is not metered against an external API, so ranking a large database is a compute question rather than a cost decision.
It fails quietly, not loudly
If the model is unavailable, matching falls back to keyword search alone. Search keeps working exactly as it did before rather than erroring out.
To be precise about it
This applies to the matching step. Other AI features here — resume parsing, the assistant's conversation, interview evaluation — do call a hosted language model, and are a separate question from where embeddings run. Ask us for the specifics on any of them.
In the places you were already looking
Candidate search
Describe who you need and rank your existing database by fit, instead of guessing which terms the right person happened to use on their resume.
Matching against a job
Open a requisition and see who in your database already fits it, before spending anything on sourcing the same profile again.
Through the AI Recruiter (→ /product/ai/) — ask the assistant to shortlist for a role and this is the ranking behind what comes back.
Questions about AI matching
No, it is layered on top. Keyword matching remains its own signal and the two are combined, so exact requirements keep their weight.
Nowhere external for this step. Embeddings are produced inside your own deployment by a small local model, so a match calculation involves no third-party embedding service.
Matching degrades to the keyword search that existed before it. Candidate search and ranking keep working rather than failing.
The ones already in your workspace — from prior sourcing, applications, and resource pools. It surfaces people you have already paid to acquire.
No. It is a ranking to help you decide where to look first. Screening, interviewing and the decision itself stay with your team.
See what is already sitting in your database
We'll run matching against your own candidate data and a live requisition on the call.