The lesson in one sentence
Vector search is a strong recall tool for job matching. It is a weak product brain.
This post is about that lesson only. The full product path — ATS ingestion, eligibility gates, ranking components, and evaluation — is in the Hirivo case study.
What embeddings actually optimize
Embeddings optimize for neighborhood recall in a continuous space. They are good at catching paraphrase, related vocabulary, and roles that sit near each other when wording drifts — “platform engineer” near “infrastructure engineer,” “Go” near “Golang,” “customer success” near “account management.”
That is a retrieval strength. It is not a hiring decision.
Job matching has hard predicates: required skills, work authorization and sponsorship, employment type, seniority floors, location and work-mode constraints, compensation bands, and eligibility gates tied to an approved profile. Those are not soft preferences you can bury inside a cosine score. If you do, you lose two capabilities at once: the ability to explain a skip, and the ability to measure whether a model change made matching better or merely differently wrong.
Where the demo breaks
Early embedding demos look solved. Embed a resume. Embed a job post. Retrieve nearest neighbors. Show a ranked list. Stakeholders nod.
Then you run it against real ATS feeds and real candidates. A senior backend engineer targeting Kubernetes-heavy roles starts seeing frontend-adjacent jobs that are semantically similar but practically irrelevant. A candidate who cannot relocate gets remote-optional noise. A title match that should be obvious loses to a soft semantic neighbor. The list still looks confident. It is just wrong in ways you cannot debug.
The failure is not that embeddings are useless. The failure is treating similarity as the product.
Eligibility is not a ranking feature
Hard constraints have to decide whether a job enters the set at all. Fit is a ranking problem applied only after eligibility is satisfied.
Once those concerns are mixed into one similarity score, every miss looks like a slightly worse neighbor. Operators cannot tell which miss mattered. Candidates cannot trust the feed. Product teams cannot attribute quality changes to a specific cause.
That is why the working pipeline is retrieve → filter → rank → explain. Retrieval finds a plausible set. Filters remove invalid options. Ranking chooses among the rest. Explanation makes the decision inspectable. Asking one embedding score to do all of that is how demos survive and products drift.
Keep generation off the sort order
LLMs can help extract, normalize, and explain. They are a poor primary ranker: expensive, unstable, and hard to regress. When recommendation quality is the product claim, ranking authority should live in measurable components and thresholds. Let the model narrate Strong / Gaps after the decision if needed — not invent the decision.
The takeaway
Use vector search to find neighborhoods. Use eligibility for hard constraints. Use explicit ranking components for fit. Measure whether changes improve labeled outcomes.
If matching is “just embeddings,” you do not have a recommendation system yet. You have neighborhood search with a confidence costume.
For how that separation showed up in Hirivo’s architecture over time, read the case study.