Engineering

Candidate scoring strategy: beyond naive vector search

How CloudFlow Compass uses LLMs for accurate, explainable candidate evaluation, and the retrieval trap that makes standard RAG recommend the wrong people.

A practical framework for using LLMs to score candidates accurately against role requirements, and why the obvious approach, naive vector search, produces confident wrong answers. This is the methodology behind CloudFlow Compass, our AI candidate search add-on.

The trap: the giant search query

Start with a clean list of requirements, say 1) 5+ years Java, 2) Spring Boot, 3) AWS deployment. The tempting shortcut is to mash them into one big vector query against your candidate database. The problem is arithmetic: a single embedding averages everything, so a candidate can score highly overall by over-indexing on one minor skill while completely lacking a core requirement.

The false positive: with standard RAG, a candidate with 0 years of Java but 10 years of AWS comes back as a “strong match”: the vector math averaged them past the requirement that actually mattered.

The solution: a three-step pipeline

Separate broad retrieval from strict evaluation.

1. Broad retrieval: the net

Use the job title and top requirements in a standard hybrid search (vector + keyword) against the candidate database. The goal is a broad pool of 50–100 generally relevant candidates. Don’t aim for precision here; aim for recall.

2. The LLM scorecard: the filter

Pass the retrieved candidates plus the requirements list to a fast LLM with a strict rubric: score each requirement 0 (no evidence), 1 (partial), or 2 (explicit match); return structured JSON. The model reads each CV the way a recruiter would, catching that a “Manager of Java Developers” is not a hands-on Java developer, which keyword and synonym matching routinely miss.

3. Weighted math: the ranking

Because the output is structured, ranking becomes simple application logic: multiply by category weights (must-have ×3, should-have ×2, nice-to-have ×1) and sum. A candidate scoring 11 of 12 weighted points cleanly outranks one at 5 of 12, and you can show exactly why.

Why this works for recruitment

Legacy semantic search vs the LLM scorecard

Legacy engines match keyword ontologies but stumble on context, return opaque percentage scores nobody can defend to a hiring manager, and need re-tuning whenever requirements change. The scorecard approach reads contextually, explains completely, and re-weights on the fly.

This is the engine inside CloudFlow Compass: point a live job spec at the candidates you already have and surface qualified people from past applications, value you’ve already paid for, before spending on new adverts. See the scoring style yourself in the live demo.

FAQ

Quick answers

Why does plain vector search fail for candidate matching?

Because averaging dilutes strict requirements. Mash “5+ years Java, Spring Boot, AWS” into one embedding query and a candidate with zero Java but ten years of AWS can surface as a “strong match”, because the vector math averages their way past a hard requirement. Retrieval is fine for casting a wide net; it’s the wrong tool for the final ranking.

Is LLM-based candidate scoring explainable?

Yes, and that is its biggest advantage over semantic-similarity scores. The LLM scores each requirement 0, 1 or 2 with the evidence it found, so when a client asks why a candidate was recommended, you show the line-by-line scorecard: “matched 2 of 3 requirements, missing AWS”, instead of an unexplainable 87%.

See it on one live role

Paste a real job spec and a real CV into the live demo and watch the scored, evidence-backed analysis come back. Then imagine it done for every application, automatically.