LLM-Powered-Resume-Screener Turns Resume Screening Into an Evidence Check
A hybrid Python engine that extracts structured claims, verifies them against proof, and blends exact, fuzzy, and semantic matching into one explainable score.
An enterprise-grade ATS emulator utilizing hybrid matching (Exact, Fuzzy, Semantic) and Gemini 2.5 Flash to bridge the gap between candidate experience and job requirements.
- The repo’s main innovation is not Gemini, but the way extraction is kept separate from judgment.
- It treats resume bullets as claims that need corroborating evidence before they can influence a score.
- Hybrid scoring makes the system more defensible than keyword ATS tools and less opaque than pure semantic matchers.
- The design still feels early, but the architecture shows a clear pattern for auditable AI decision systems.
Most resume screeners ask a blunt question: does this document contain the right words? LLM-Powered-Resume-Screener asks a better one: can the resume prove the skill, not just mention it? That shift changes the product from a keyword filter into an evidence system.
Why this screener is different
The repo is built around a simple refusal. It does not trust a resume claim just because a model saw it. It looks for supporting text, normalizes the language, and only then lets the matching layers decide what matters.
That matters because hiring data is messy. Candidates write "ML," "machine learning," or a project name that implies the same thing. Traditional ATS tools miss that nuance, while pure LLM tools can become too loose. This project tries to sit in the middle.
The hybrid pipeline that keeps the LLM honest
The codebase is organized like a controlled assembly line. Raw resume and job description text is chunked, preprocessed, and pushed through Gemini for structured extraction. If the output is malformed, the repo repairs it with schema-aware tooling instead of pretending the model was perfect.
This separation is the core design choice. The LLM extracts. Python decides. That keeps the system explainable, and it makes the scoring logic far easier to audit than a single end-to-end prompt.
How the score is actually decided
The final score lives in hybrid_scorer.py. The repo blends three signals: must-have coverage, semantic similarity, and a fairness floor for imperfect parsing. The weighting is explicit, with most of the weight reserved for exact requirements and the rest used as a safety net.
final_score = (
0.55 * must_have_coverage +
0.30 * semantic_score +
0.15 * baseline_fairness
)
final_score *= evidence_multiplier
The interesting part is the multiplier. If a skill shows up in multiple places, such as Skills, Projects, and Experience, the score gets a boost. That is a small detail with big consequences, because it rewards corroboration rather than repetition.
| Approach | What it optimizes for | Main weakness | Where this repo differs |
|---|---|---|---|
| Keyword ATS | Literal term matching | Misses synonyms and context | Adds normalization, fuzzy logic, and semantic backup |
| Semantic-only matcher | Conceptual similarity | Hard to explain and easy to overmatch | Keeps exact checks and evidence visible |
| Agentic screener | Autonomy and orchestration | More moving parts than needed | Uses a simpler, auditable scoring chain |
| This repo | Explainable hybrid screening | Still depends on model quality and API calls | Separates extraction from judgment and rewards evidence |
Why semantic matching matters when keywords fail
The semantic layer uses sentence embeddings to compare job responsibilities with resume projects and evidence chunks. That matters because a candidate can describe the same work with different language and still deserve a match.
Instead of comparing whole documents as blobs, the matcher looks at smaller pieces and takes the best overlap. That is a practical choice. It lets the system catch conceptual matches without giving up exact must-have checks.
The normalizer helps too. By mapping variants like acronyms to a canonical term, it reduces false misses before the semantic layer even starts doing work.
What it gets right, and where it still feels early
The strongest part of the project is its discipline. The schema boundaries are clear, the scoring is modular, and the output is more defensible than what most resume tools produce. It is easy to see how a recruiter could trust the reasoning more than a plain model score.
It is also still clearly a prototype. The API dependency, the throttle delay in the pipeline, and the need to keep cleaning model output all signal a system that is carefully built but not yet production-hardened.
| Strength | Risk | Why it matters |
|---|---|---|
| Schema-driven extraction | Model output can still drift | Keeps the system predictable |
| Evidence multiplier | Can favor longer resumes | Makes corroboration visible |
| Semantic safety net | Can soften strict requirements | Prevents unfair keyword failures |
| Hybrid design | More moving parts than a single prompt | Creates room for auditability |
How it stacks up against other resume screeners
Compared with commercial tools and agent-heavy open source projects, this repo occupies a narrower but useful lane. It is not trying to enrich LinkedIn profiles or orchestrate a crew of agents. It is trying to make screening legible.
| Tooling style | Strength | Trade-off | Positioning |
|---|---|---|---|
| Traditional ATS | Simple workflow | Keyword blind spots | Fast, but brittle |
| Semantic matcher | Concept fit | Harder to explain | Flexible, but opaque |
| Agentic screener | Broad automation | Complexity and latency | Powerful, but heavier |
| LLM-Powered-Resume-Screener | Explainable hybrid scoring | Still early and API dependent | Transparent, evidence-first screening |
The bigger idea
The most useful pattern here is broader than recruiting. Let the model extract. Let deterministic code decide. Keep evidence visible. That is how you build AI systems that people can interrogate instead of merely accept.