Back to Blog

Product

Inside the Relevance Model: How Huzzl Finds the Best Candidate Fit

A look inside the multi-stage AI pipeline that turns unstructured recruitment data into structured evidence and explainable candidate recommendations.

Balaji Sadasivan Jul 13, 20269 min read

A candidate uploads a three-page resume.

A hiring manager provides a job description filled with required skills, preferred skills, responsibilities, internal terminology, and sometimes requirements copied from an older role.

Within seconds, a recruitment platform is expected to answer a deceptively difficult question:

How well does this candidate actually fit this job?

A simple system searches for matching words.

A more advanced system must understand what the words mean, how they relate to one another, which requirements matter most, how deeply the candidate has used each skill, and whether apparently different experiences are functionally similar.

That is the purpose of the Huzzl relevance model.

Huzzl does not treat candidate matching as a single prompt sent to a large language model. It uses a multi-stage AI pipeline that transforms unstructured recruitment data into structured evidence, retrieves potentially relevant candidates efficiently, evaluates them more deeply, and explains the final recommendation.

Here is what happens inside that process.

Step 1: Turning Resumes Into Structured Candidate Intelligence

Resumes are designed for people, not machines.

The same information may appear in a summary, skill list, project description, employment section, certification block, or even a table. Dates may be incomplete. Job titles may be unconventional. Candidates may list technologies without explaining where they used them.

Before Huzzl can evaluate relevance, it must first understand the resume.

We use OpenAI-powered text extraction to identify and organise information such as:

The goal is not merely to convert a PDF into text. It is to transform unstructured text into a consistent candidate profile that the relevance engine can evaluate.

Structured model outputs are useful in workflows like this because the model can be constrained to return information in a defined schema rather than producing loosely formatted prose.

This distinction matters.

Consider the sentence:

“Led the modernisation of a legacy claims platform using containerised services deployed on Azure.”

A basic parser may identify “Azure.”

A richer extraction process can recognise that the candidate:

That context becomes evidence for relevance.

Step 2: Understanding the Job Beyond Its Keywords

The job description goes through a similar process.

Huzzl identifies the role’s responsibilities, mandatory capabilities, preferred capabilities, expected seniority, domain context, leadership requirements, and technical environment.

It also separates different types of requirements.

For example, a job description may mention:

These requirements should not automatically receive equal weight.

Java and Spring Boot may be essential. Kubernetes may be preferred. AWS experience may be transferable from another cloud platform. Banking experience may be valuable but not mandatory. Team leadership may be critical only if the person will directly manage engineers.

The relevance model therefore attempts to understand the structure of the requirement, rather than treating the job description as one large collection of words.

Step 3: Taxonomy Normalisation

Candidates and employers rarely use identical terminology.

One resume may say “Amazon Web Services.” Another may say “AWS.” A third may list specific services such as EC2, Lambda, S3, and RDS without using either phrase prominently.

Similar variation appears across job titles:

The titles may overlap significantly, but a literal system may treat them as unrelated.

Huzzl uses taxonomy normalisation to map different expressions into a more consistent representation. This helps the system recognise:

Taxonomy normalisation does not mean that every related skill becomes equivalent.

Java and C# are both enterprise programming languages, but they are not the same skill. AWS and Azure share cloud concepts, but experience in one does not automatically prove proficiency in the other.

The model preserves these distinctions while understanding the relationships between them.

This creates a more intelligent middle ground between exact matching and overly broad similarity.

Step 4: Semantic Representation and Candidate Retrieval

Once the candidate and job have been structured and normalised, Huzzl creates semantic representations of their experience and requirements.

Text embeddings convert passages of text into numerical representations that allow systems to compare their meaning rather than relying entirely on identical wording. OpenAI describes embeddings as useful for applications including search, recommendations, clustering, and classification.

In practical terms, this means Huzzl can recognise that:

“Built distributed APIs for high-volume payment processing”

may be relevant to:

“Experience designing scalable transaction-processing microservices”

even though the two statements contain relatively few identical words.

A bi-encoder retrieval stage allows the system to compare a job against a large candidate pool efficiently. Candidate profiles can be represented and indexed in advance, while the job requirement is encoded when the search is performed.

This first retrieval stage is designed for reach.

Its purpose is to identify a strong pool of potentially relevant candidates without performing the most expensive form of analysis against every resume in the database.

Research on sentence embeddings has shown why this architecture is useful: independently generated semantic representations can make similarity search dramatically more efficient than evaluating every possible text pair jointly.

But retrieval is only the beginning.

Step 5: Re-Ranking the Strongest Candidates

Fast semantic retrieval is good at creating a candidate pool.

It is not always precise enough to produce the final order.

The top candidates therefore move into a deeper re-ranking stage.

During re-ranking, the job and candidate are evaluated together. This allows the system to examine finer relationships between the role and the individual profile.

The re-ranker may consider questions such as:

Combining efficient retrieval with a more precise re-ranker is a widely used pattern in semantic search. The initial model retrieves a manageable candidate set, while the second model performs more detailed pairwise evaluation.

This is where two candidates with similar keyword coverage can receive very different relevance scores.

Step 6: Applying Business Rules and Hard Constraints

Not every hiring requirement should be left to semantic similarity.

Some conditions are explicit.

A role may require a particular location, work authorisation, notice period, certification, language, shift availability, or minimum level of experience.

Huzzl can apply these as filters or scoring constraints separately from semantic relevance.

This prevents a candidate from receiving a high overall rank merely because the profile is conceptually similar while failing a genuinely mandatory requirement.

It also gives recruitment teams control over how the model behaves.

A preferred requirement may influence ranking.

A mandatory requirement may determine eligibility.

The system should know the difference.

Step 7: Explaining the Match

A relevance score without an explanation is difficult to trust.

Huzzl therefore presents the evidence behind the recommendation.

Instead of displaying only “87% match,” the system can help recruiters understand:

This explanation is important because candidate matching is not a mathematical fact.

It is a recommendation based on available evidence.

The resume may be incomplete. The job description may be imperfect. A candidate may possess capabilities that were never written down. Recruiters and hiring managers must remain part of the decision.

The role of the model is to help them evaluate better—not to make the final hiring decision for them.

Step 8: Improving Through Evaluation and Feedback

A relevance model should not be treated as finished simply because it produces convincing results.

It must be evaluated continuously.

Recruiter feedback, shortlist decisions, screening outcomes, interview progression, and hiring results can help identify where the model is performing well and where it requires adjustment.

Evaluation datasets can test whether the system:

OpenAI’s evaluation guidance emphasises testing model outputs against defined criteria and using repeated evaluations as systems, prompts, and models evolve.

For Huzzl, this means relevance is not a one-time AI output. It is an engineered and measurable process.

The Best Match Is Built in Stages

There is no single model that can perfectly understand every resume, interpret every job description, apply every business rule, rank thousands of candidates, and explain the decision equally well in one step.

That is why Huzzl uses a layered approach:

OpenAI-powered extraction → structured profiles → taxonomy normalisation → semantic retrieval → re-ranking → business-rule validation → explainable recommendations

Each stage solves a different part of the problem.

Extraction creates usable information.

Normalisation creates consistency.

Semantic retrieval finds candidates whose experience means the right thing.

Re-ranking determines which candidates fit the role most closely.

Explainability gives recruiters the evidence needed to act.

The result is not simply a list of resumes containing the expected words.

It is a more informed view of who may actually be capable of doing the work.

That is what candidate relevance should mean.