LLM resume parsing: from raw CV to structured data

LLM resume parsing replaces pattern-matching with reading: a language model takes the raw CV and, instead of being asked to summarise it, is forced to fill a strict schema with the candidate’s name, contact details, work history, skills and education. Because the model interprets the document rather than scanning it for known keywords, the layouts that break traditional parsers, two-column templates above all, stop being a problem. The trade is determinism for comprehension, which is why the output still gets validated and the doubtful cases still go to a human.

Why do rules-based parsers break on real CVs?

Traditional parsers, the kind we walk through in CV parsing explained, work in two passes: extract the text from the file, then run rules over it. Regular expressions catch emails and phone numbers, a lookup list finds section headings like “Experience” and “Education”, a skills taxonomy matches known terms, and date patterns stitch the work history together. This holds up beautifully when the CV reads like a 2009 Word document: one column, conventional headings, top to bottom.

Real CVs stopped looking like that. Design-tool templates put skills and contact details in a coloured sidebar, headline the work history as “My journey so far”, replace the word “phone” with an icon, and rate skills with little bars. Two failure modes do most of the damage:

• Reading order. A PDF stores positioned text fragments, not a reading sequence. Extract text from a two-column layout and the columns interleave: sidebar skills spliced into the middle of a job description, dates separated from the employers they belong to. The rules are now matching against noise. File format matters here too, which is why we compare them in DOCX vs PDF: which CV format parses best.
• Headings and headers. Section detection keys on a finite list of expected headings. “Professional journey”, “Wat ik heb gedaan”, or a heading rendered as an image is not on the list, so the whole section silently vanishes. Meanwhile page headers and footers repeat the candidate’s name on every page and get mistaken for content.

The worst part is that the failure is quiet. The parser does not crash; it produces a profile with the most recent job missing or the skills attached to nothing. The recruiter later filters the talent pool by that skill and the candidate simply never appears.

How does schema-forced extraction actually work?

Four steps, and the order matters.

Define the structure first. Decide exactly what a parsed candidate looks like before any model gets involved. A minimal, useful schema:

class Experience(BaseModel):
    job_title: str
    company: str
    start: str | None  # "YYYY-MM", null when the CV does not say
    end: str | None    # null also covers "current role"

class CandidateProfile(BaseModel):
    full_name: str
    email: str | None
    phone: str | None
    location: str | None
    experience: list[Experience]
    skills: list[str]
    education: list[str]

Force the model to fill it. Modern model APIs accept a schema like this and constrain the output to valid instances of it, usually called structured output or function calling. This is not “please respond in JSON” prompting, which models drift away from; the decoding itself is constrained, so stray prose or a misspelled field name is impossible. The one prompt rule that earns its keep: null over guess. A missing end date stays null rather than getting invented.

Validate mechanically. Schema conformity is the floor, not the ceiling. Cheap deterministic checks catch the model’s bad days: the email actually parses, date ranges run forward, nobody’s employment ends in 2031, the same employer does not appear twice with overlapping dates.

Keep a review lane. Anything that fails a check, or passes but looks off, goes to a person with the original document displayed alongside the extracted fields. The lane should be a first-class part of the pipeline, not an exception handler bolted on later.

How does it compare with a rules engine?

Dimension	Rules-based parser	Schema-forced LLM
Two-column and designed layouts	Breaks on reading order	Reassembles from context
Unusual section headings	Unknown heading, lost section	Reads meaning, not labels
Speed and cost per CV	Milliseconds, near-free	Seconds, a model call each
Determinism	Same file in, same data out	Minor run-to-run variation
Failure mode	Loud: empty or missing fields	Quiet: plausible wrong value
Multilingual CVs	A rule set per language	Strong across languages by default

The row to internalise is the failure mode. A rules engine fails visibly: a blank field announces itself. A model fails plausibly: a tidy end date that the CV never stated. That asymmetry is why the validation layer is non-negotiable, and why hybrid setups are common in practice. Running the old regex pass for emails and phone numbers costs nothing and gives you a cross-check on the two fields you can least afford to get wrong.

Where do the remaining errors hide, and who catches them?

The dangerous errors are the believable ones: a normalised job title that quietly promotes the candidate, two short stints merged into one long one, a skills list padded with terms the model associated rather than read. Mechanical validation catches the arithmetic; it does not catch the plausible. That next layer, checking the CV’s claims against each other and against the rest of the application, is its own discipline, covered in using LLMs to flag CV inconsistencies.

Two operational notes before the pipeline is honest. First, a clean profile still has to land in your database without spawning a second record for someone who applied last year, the problem unpacked in adding LLM screening without duplicate records. Second, the review lane is not bureaucratic overhead: under EU rules, hiring AI sits in the high-risk category with human oversight duties attached, as covered in the EU AI Act and recruitment software. A pipeline where a person confirms the extracted data before it drives decisions is the compliant shape, not the slow one.

Where does Recruitifly fit?

Parsing CVs into profiles is one of the everyday jobs of Fly, the assistant that works across all of Recruitifly: hand it documents, get structured profiles back. The review lane is built into the platform’s design rather than added around it, because every write in Recruitifly is propose-then-confirm. A parsed profile arrives as a proposal the recruiter approves before it becomes a record, and the same gate applies when Fly goes on to score those candidates against a job or assemble a shortlist from them. Nothing about a candidate changes unsupervised, and we consider that the correct design for hiring software, not a limitation. Recruitifly is built in the EU, with EU data residency and GDPR tooling for retention windows, consent tracking and deletion requests.

We are in private beta at the moment. If your current parser keeps mangling designed CVs, talk to us and bring your ugliest two-column template; it makes for a good demo.