What semantic search changes in enterprise recruiting

Keyword search fails for talent discovery

A recruiter searching for “machine learning engineer with healthcare experience” gets zero results if candidates wrote “ML” instead of “machine learning” or described their work at a hospital system without using the word “healthcare.” Keyword search only finds what was literally written. In recruiting, where terminology varies wildly across résumés, that creates a massive discovery gap.

Semantic search closes this gap by matching on meaning. But moving from a keyword system to a semantic one introduces a new set of problems that aren’t obvious until you’re operating at scale.

Off-the-shelf embeddings aren’t enough

General-purpose embedding models (OpenAI, Cohere, etc.) capture broad semantic similarity, but they don’t understand recruiting-specific relevance. “5 years of Python” and “5 years of Java” are semantically similar — both describe programming experience — but a recruiter searching for Python engineers doesn’t want Java results.

We fine-tuned domain-specific embeddings using recruiter feedback signals: which candidates were shortlisted, which were rejected, and which queries produced useful results. This creates an embedding space where relevance means what recruiters think it means, not what cosine similarity thinks it means.

Hybrid retrieval solves the precision problem

Pure vector search has a recall problem: it’s good at finding conceptually related candidates but returns too many loosely-related results. Pure keyword search has a coverage problem. The solution is hybrid retrieval — combining dense vector scores with sparse BM25 scores — with a learned weighting that varies by query type.

For specific skill queries (“AWS Lambda, Terraform, 3+ years”), BM25 dominates. For conceptual queries (“technical leader who can scale an ML platform team”), vector search dominates. The system learns these weightings from usage patterns rather than using a fixed ratio.

Freshness at 2M+ documents

Résumé databases aren’t static. New candidates arrive hourly. Existing profiles get updated. A stale index means the system misses new candidates and returns people who are no longer available. At 2M+ documents, full reindexing takes hours and is operationally expensive.

We use incremental indexing with a change-detection layer. New and updated documents enter a priority queue, get embedded, and are added to a write-ahead segment that’s merged into the main index asynchronously. Queries always hit both the main index and the write-ahead segment, so new candidates are searchable within minutes of ingestion rather than hours.

Recruiter trust is the product problem

The hardest challenge isn’t technical — it’s trust. Recruiters have spent years developing Boolean search expertise. A semantic system that returns results they can’t explain (“why is this candidate here?”) gets abandoned regardless of how good the underlying retrieval is.

We surface relevance explanations alongside each result: which parts of the query matched which parts of the résumé, what skills were inferred vs. explicitly stated, and a confidence indicator. This gives recruiters a mental model of what the system is doing, which builds the trust needed for adoption.