Semantic Search vs Keywords: Skills-First Matching

Why Keywords Fail Recruitment

Consider a hiring manager searching for a "Registered Nurse" with paediatric ICU experience. A keyword search matches those exact terms, but misses the candidate whose CV says "RN" instead of "Registered Nurse," the one who lists "PICU Staff Nurse" as their title, and the one from the UK whose CV reads "Paediatric Intensive Care Sister." These are all the same role. They share zero keyword overlap with the search query.

This isn't an edge case. It's the norm. Healthcare professionals use different terminology across regions, hospitals, and career stages. Software engineers describe the same skills as "React," "ReactJS," "React.js," or simply list projects built with the framework without naming it explicitly. Keyword search treats all of these as different things. A human reading those CVs would instantly recognise them as equivalent.

The consequence is systematic invisibility. Qualified candidates don't surface, not because they lack the skills, but because they described those skills using different vocabulary. In a talent market where every qualified candidate matters, this isn't a minor inconvenience. It's a structural failure in how most recruitment platforms connect supply to demand.

The Embedding Approach

Semantic search solves the vocabulary problem by operating in meaning space rather than word space. Instead of matching text strings, we convert skills, experience descriptions, and qualifications into high-dimensional vectors (numerical representations that capture the semantic relationships between concepts). Vectors for "wound care specialist" and "tissue viability nurse" end up close together in this space because they describe the same expertise, even though they share no words.

When a recruiter searches for "paediatric ICU nurse with ventilator management experience," the search query is converted into the same vector space. Results are ranked by semantic similarity, how close each candidate's embedded profile is to the meaning of the query, not how many keywords match. This means a candidate whose CV describes "mechanical ventilation in PICU" ranks highly, even though neither "ventilator management" nor "paediatric ICU nurse" appears in their text.

The embedding model we use has been specifically tuned for professional skills and qualifications. General-purpose embeddings understand that "nurse" and "nursing" are related, but domain-tuned embeddings understand that "tissue viability" is a specialisation within wound care, that "ACLS certified" implies cardiac emergency competence, and that "CNC" in healthcare means "Clinical Nurse Consultant," not "Computer Numerical Control."

Hybrid Search: Precision Meets Understanding

Pure semantic search has its own failure mode: it's too forgiving. A search for a "registered nurse in Sydney" might semantically match candidates in Melbourne because the embedding captures "Australian healthcare professional" as the dominant signal, de-weighting geography. For certain criteria (locations, specific certifications, exact qualification levels) you need boolean precision, not semantic flexibility.

Our search architecture combines both approaches. Hard requirements (location, visa status, mandatory certifications, availability dates) are enforced as boolean filters. They produce an initial candidate set where every result meets non-negotiable criteria. Semantic search then operates within that set, ranking candidates by genuine skill and experience alignment with the role.

This hybrid approach gives recruiters the best of both worlds. They get the precision of "must be in Sydney, must hold AHPRA registration" combined with the intelligence of "rank by how closely their actual clinical experience matches what this ICU needs." Neither approach alone delivers this. Keywords are too rigid, pure semantics too loose. The combination is what makes search actually useful for recruitment decisions.

The Re-Ranking Layer

Initial retrieval is designed to be generous. The embedding similarity search casts a wide net, surfacing hundreds of candidates whose profiles have some semantic relationship to the query. This is intentional. The cost of missing a great candidate at the retrieval stage is permanent, they'll never appear in results. The cost of including a marginal candidate is trivial, because the re-ranking layer handles refinement.

Re-ranking uses a more computationally expensive model that examines each candidate in the context of the full query. Where the initial retrieval asks "is this profile semantically related to the search?", the re-ranker asks "how well does this specific person fit this specific role?" It considers the interplay between skills - not just whether someone has ICU experience and paediatric experience separately, but whether they have paediatric ICU experience specifically.

This two-stage architecture lets us balance thoroughness with precision. The initial retrieval is fast and broad (vector similarity is computationally cheap). The re-ranking is slow and precise (cross-encoding every candidate against the query is expensive). By applying the expensive step only to the broad retrieval set, we get both speed and accuracy without compromise.

Why Dimensions Matter

Vector embeddings exist in a space defined by dimensions. The more dimensions, the more nuance the embedding can capture. A 384-dimensional embedding can represent "nurse" as distinct from "doctor" but might struggle to distinguish "paediatric ICU nurse" from "neonatal ICU nurse." A 1536-dimensional embedding captures those fine-grained distinctions but requires more storage, more computation, and more memory for every similarity comparison.

We chose our embedding dimensionality based on recruitment-specific evaluation. We tested how well different dimension counts distinguished between genuinely different roles versus merely different descriptions of the same role. The sweet spot (where adding more dimensions stopped improving recruitment-relevant distinctions) determined our architecture. Too few dimensions and wound care specialists get confused with general nurses. Too many and you're paying computational cost for distinctions that don't affect hiring decisions.

Real-World Impact

The practical difference shows up in searches that would simply fail with keywords. A recruiter searching for a "wound care specialist" surfaces candidates whose profiles mention "tissue viability nursing," "chronic wound management," "pressure injury prevention," and "skin integrity assessment." These are semantically identical competencies described with completely different vocabulary. In a keyword system, none of these candidates would appear. In our semantic system, they're ranked by how closely their specific wound care experience matches what the recruiter needs.

For organisations with large candidate databases (thousands or tens of thousands of profiles) this means the difference between finding your best candidates and never knowing they existed. The talent was always there, in your database, waiting to be discovered. It was invisible only because previous search technology couldn't bridge the vocabulary gap between how recruiters search and how candidates describe themselves.

What We Tried First, and Why It Failed

Before the hybrid design, we shipped a pure semantic search. Embed everything, rank by cosine similarity, return the top results. It demoed beautifully on the vocabulary-gap cases (the "tissue viability" versus "wound care" examples) and then fell over on the ones that matter operationally. A recruiter searched for a Sydney-based nurse and the top results included excellent candidates in Melbourne, because the embedding treated "Australian clinical professional" as the dominant signal and quietly de-weighted geography. Semantically, the model was right. Operationally, it wasted the recruiter's time, because a Melbourne candidate cannot fill a Sydney roster.

We tried to fix that inside the embedding by weighting location terms more heavily. That made geography behave and broke skill matching, because now two nurses in the same suburb ranked above a far better-qualified nurse one suburb over. Cramming a hard constraint (location) into a soft similarity score is the wrong tool for the job. Hard requirements are boolean by nature: you are either registered with AHPRA or you are not, you either hold a current visa or you do not. Trying to express that as a distance in vector space is fighting the mathematics.

That failure is the entire reason the architecture is hybrid rather than purely semantic. Boolean filters enforce the non-negotiables and produce a candidate set where every result is legally and logistically viable. Semantic ranking then does what it is genuinely good at, ordering that set by real skill alignment. Each layer does the job it is suited to, and neither is asked to do the other's.

Latency and the Two-Stage Trade-Off

The two-stage retrieve-then-rerank design exists because of a concrete cost asymmetry. Vector similarity is cheap: comparing a query embedding against an indexed profile is a fast operation, and an approximate-nearest-neighbour index returns a broad candidate set in the low tens of milliseconds even over tens of thousands of profiles. Cross-encoder re-ranking is the opposite: it runs the query and each candidate through a model together, which is far more expensive per candidate and scales linearly with how many candidates you feed it.

If we re-ranked every profile in the database, a single search would take seconds and cost far more compute than the result justifies. If we skipped re-ranking entirely, we would return the generous, slightly-too-forgiving output of the first stage. The compromise is deliberate: retrieve a wide set cheaply, then spend the expensive re-ranking budget only on that set. As an illustrative shape, first-stage retrieval over a large database stays in the tens of milliseconds; re-ranking a few hundred candidates adds a further slice on top, keeping an interactive search comfortably sub-second while still applying the precise model where it changes the ordering.

• Stage one (vector retrieval): cheap, broad, tuned for recall so a strong candidate is never dropped before ranking.
• Stage two (cross-encoder re-rank): expensive, narrow, tuned for precision and applied only to the retrieved set.
• Boolean filters: applied before both, enforcing the constraints that must never be traded off for similarity.

Keeping Embeddings Fresh

An embedding index is a cache, and caches go stale. A candidate updates their profile with a new certification, a recruiter imports a batch of CVs, or we improve the embedding model itself. Each of those events means the vectors on disk no longer reflect reality, and a stale index quietly reintroduces the exact invisibility problem semantic search was meant to solve. We treat re-embedding as a first-class background job rather than an afterthought: profile changes queue an incremental re-embed, and a model upgrade triggers a full re-index run.

The honest trade-off here is that a model upgrade is expensive to roll out. Changing the embedding model means every stored vector must be regenerated, because vectors from two different models are not comparable, mixing them silently corrupts ranking. So an upgrade is not a config flip; it is a re-index of the entire corpus, which we run in the background and cut over only once complete. We accept that operational weight because the alternative (living with an older embedding model to avoid the re-index cost) means leaving retrieval quality on the table.