SOLUTIONS · EXPERTINI ATS

AI & ML Semantic Matching for Recruitment

The underlying technique, for a more technical reader — embeddings, cosine similarity, and where Gemini fits in.

3 min read · Updated July 2026 · Expertini Editorial

A more technical treatment of how semantic matching works under the hood, for readers evaluating the methodology rather than the product surface — data scientists, compliance reviewers, or anyone who wants the mechanics rather than the marketing framing.

▶ Watch the 30-second overview — no sign-up needed

Two distinct techniques, used for different jobs
Why the LLM's output is constrained to extraction
Bias implications
Choosing between the two techniques — a practical decision rule
Reproducibility as an engineering property, not a promise
How this is architected in the platform
Operational and audit posture
Frequently asked questions

01Two distinct techniques, used for different jobs

Resume Score uses classical vector-space cosine similarity between a CV's text and a job description's text — fast, lightweight, no LLM call, good for a quick standalone fit check. CMS scoring uses an LLM (Gemini) for structured reading comprehension — identifying which specific competency dimensions a CV evidences — which cosine similarity alone cannot do, since it can't distinguish "claims a skill" from "demonstrates a skill with specifics."

02Why the LLM's output is constrained to extraction

Asking an LLM to output a final numeric score directly is well-documented to be non-reproducible — the same inputs can yield different scores on different runs, since generative models are next-token predictors, not calculators. Constraining Gemini's role to structured extraction (find evidence, cite it) and computing the score with fixed arithmetic outside the model sidesteps that failure mode entirely.

03Bias implications

Semantic matching can reduce certain biases (vocabulary/accent-driven false negatives) relative to keyword search, but it inherits whatever bias exists in the job description's own requirements — it will faithfully score against a poorly-written, exclusionary JD rather than silently correct for it. See the DEI in Hiring resource for the fuller treatment.

04Choosing between the two techniques — a practical decision rule

Cosine similarity answers "how much does this document resemble that one" — lightweight, instant, and adequate when the question is a rough pre-screen or a candidate's self-serve fit check. It cannot tell you which requirement is missing, whether a claim is evidenced, or why the number came out where it did. LLM extraction answers "what specific evidence exists for each specific requirement" — slower and with a real per-call cost, but the output is a structured, citable artifact rather than a single opaque similarity number. The platform uses both where each is honest: Resume Score for the quick check (no API cost, higher monthly allowance), CMS for the decision-supporting shortlist where explanation and auditability are the point.

05Reproducibility as an engineering property, not a promise

The reproducibility claim is narrow and checkable: given the same CV text, the same job description, and the same extraction model version, the pipeline produces the same dimensions, the same evidence citations feed the same fixed arithmetic, and the identical score comes out. The stochastic part of the system (the LLM) is confined to a stage whose output is inspectable structured data, so any variation is visible at the extraction layer rather than laundered into an unexplainable final number. This is the specific design choice the published methodology (Expertini Research Team, 2026) formalises, and it's what separates "deterministic scoring" as an architecture from "consistent-ish scoring" as a marketing adjective. For the compliance angle — NYC Local Law 144 audits, EU AI Act obligations — see the AI recruiting overview.

Engineering notes

Platform architecture & operations

A1How this is architected in the platform

AI & ML Semantic Matching for Recruitment is not a bundle of point products — it is a slice through one platform. The platform is deliberately server-rendered: every view is prepared by the application server and shipped as complete HTML, with no client-side framework, no third-party CDN scripts, and no build pipeline between the data and the page. What renders is what the server computed — the property that makes the interface auditable.

All persistence runs on a single search-native document store; every query carries the organisation's identifier as a mandatory filter at the lowest query layer. Tenant isolation is therefore structural — a property of how every request is composed — rather than a policy that relies on application code remembering to check.

Every capability referenced on this page resolves to a registered tool or connector: the tools directory and the integrations catalogue are renderings of the same registries the application enforces at runtime, so what this page describes and what the product gates can never drift apart.

A2Operational and audit posture

Screening is deterministic and published — the same inputs produce the same outputs, hard requirements block rather than average away, and the methodology is public on the research page. Actions that touch external systems are explicit and journalled per event; usage reporting aggregates the same journals the actions write, not a parallel telemetry system.

Anything that leaves the request path — notification fan-out, webhook delivery, activity journalling, mail — runs in fire-and-forget background threads. A slow external endpoint can never make the interface hang, and a failed side effect is logged rather than silently retried into inconsistency.

Everything written is yours to take: CSV exports and the Data Export app cover the same stores the product itself reads. The exit is as open as the entrance — by design, not concession.

Frequently asked questions

Why not just use embeddings and cosine similarity for everything?⌄

Because similarity can't distinguish "claims a skill" from "demonstrates a skill with specifics," can't identify which mandatory requirement is missing, and can't explain itself. Those are exactly the properties a decision-supporting score needs — hence the extraction-plus-arithmetic architecture for CMS.

Is the extraction step really deterministic if it uses an LLM?⌄

The extraction stage is where any variation can occur, which is precisely why it outputs inspectable structured evidence rather than a number — variation is visible and reviewable there. The scoring stage downstream is pure fixed arithmetic. Same inputs plus same model version yields the same score.

Where can I read the methodology in full?⌄

It's published as a citable academic paper through Expertini Research (research.expertini.com) — Syed, 2026 — and the formula itself is walked through on the CMS page, including a worked numeric example.

At a glance

Cosine similarity (Resume Score) vs LLM extraction (CMS) — different techniques for different jobs
LLM constrained to extraction, never asked for a final score directly
Deterministic arithmetic outside the model computes the actual score
Inherits JD bias rather than correcting for it — see DEI in Hiring
Stochastic stage confined to inspectable structured output
Methodology published and citable, not proprietary

See ai & ml semantic matching for recruitment on your own hiring.

Bring a real job description to a 30-minute demo — free trial included.

Book a demo