AI Resume Parsing: Nauwkeurigheid Afwegingen Tussen Regex, NLP, en LLMs

De evolutie van resume parsing (en haar voetafdrukken)

Resume parsing was eens echt vreselijk. Decennialang was de beste oplossing het inhuren van een bedrijf zoals Sovren om regex patronen op PDF's uit te voeren en naam, e-mail, telefoon, ervaring te extraheren. De patronen werkten voor 60% van gevallen — goed opgemaakt résumé's met voorspelbare structuren. Uitschieters (onconventionele lay-outs, internationale formaten, emoji, tabellen, headers) vielen door de mand.

Deze afweging was acceptabel omdat geen alternatief bestond. Dus wervingsteams bouwden workarounds: handmatige review van geparseerde gegevens, backend kwaliteit-controles, telefoonnummer validatie, en een grimmige acceptatie dat 15% van kandidaat's gegevens zou worden verknoeId.

Daarna beloofde NLP (spaCy, StanfordNLP) beter. Named-entity recognition op ruwe tekst, geen regex nodig. Het werkte - voor entiteit-identificatie taken. Maar resume parsing is niet alleen entiteit identificatie. Een resume is een semantisch document: "2020-2022" onder een header is niet alleen een datum, het's een werkstart en einddatum. Een NLP model getraind op nieuwsartikelen legt die context niet vast.

Nu kunnen LLMs (Claude, GPT) semantische context lezen. Maar LLMs zijn probabilistisch. Zonder structuur, ze hallucineren velden, verzinnen baantitels, en overslaan soms hele ervaringssecties. De vraag is: hoe zet je een LLM in om betrouwbaar te parseren?

Waar elk benadering breken

Regex (Sovren-tijdperk):

• Breken op: Non-standaard opmaak (horizontale tijdlijn in plaats van opsommingstekens), sectieheaders in verschillende lettertypen, internationale naamnamen, PDF extractie artefacten (extra spaties, gebroken regelbreaks).
• Werken op: Goed opgemaakt, single-kolom, Engelse résumé's uit recente afgestudeerden of corporate achtergronden.
• Probleem: Broosheid. Één PDF uit Canva breken het patroon.

NLP (spaCy, StanfordNLP):

• Breken op: Semantische begrip. "2020-2022" ziet eruit als een datum voor NLP. Maar waarom staat het op dit résumé? Onder welk baantje? Is het een start/einddatum of een alleenstaande referentie?
• Werken op: Entiteit extractie als het document schoon en duidelijk gelabeld is.
• Probleem: Geen semantische context. Een NLP model weet niet dat "Python" onder "Vaardigheden" anders is dan "Python" in "Python consultant bedrijf" (gereedschap vs. bedrijfsnaam).

LLM zonder structuur:

• Breken op: Hallucinatie. "Extraheer werk ervaring van kandidaat" keert terug: [{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }] — maar slechts één hiervan staat op het résumé. Of sections helemaal mist omdat het model's contextvenster afsneed.
• Werken op: Open-ended samenvattingen en interpretaties.
• Probleem: Geen guardrails. Het model kan plausibele-klinkende gegevens verzinnen.

LLM met gestructureerde prompting (Zod/JSON Schema):

• Breken op: Complexe edge cases (kandidaat met 15 baantjes, résumé in gemengd Engels/niet-Engels, ongebruikelijk certificeringsformat). Maar zelden hallucinatie.
• Werken op: ~95% van résumé's die niet antagonistisch zijn.
• Probleem: Vereist upfront schema definitie en prompt tuning.

Wat gestructureerde prompting eigenlijk oploost

Gestructureerde prompting + validatie (Zod, JSON Schema) forceert het LLM om binnen guardrails te blijven:

Extracteer resumégegevens in dit schema:
{
  name: string,
  email: string,
  phone: string,
  experience: [{ title, company, start, end, summary }],
  skills: [string],
  education: [{ degree, field, school, graduationYear }]
}

Regels:
- Als een veld ontbreekt, retourneer null, niet een verzonnen waarde.
- Data's moeten YYYY of YYYY-MM zijn, niet fuzzy strings.
- Vaardigheden zouden gereedschap/talen die genoemd worden, niet vage adjectieven.

Het schema + validatie vangt hallucinaties. Als het model een zesde baan verzint terwijl het résumé vier vermeldt, kan een validator het markeren. Als het start: "early 2020" terugkeert (niet geldig), weigert het schema het en vraagt het model om zich aan te passen.

Dit elimineert fouten niet — een LLM kan nog steeds "2020-2022" verkeerd lezen als "2020-2023" — maar het verhindert de soorten fouten die regex en NLP niet kunnen opvangen: semantische herordening, contextuele extractie, en multi-document parsing.

De nauwkeurigheid afwegingen

*Nauwkeurigheid = geëxtraheerde velden matchen grondwaarheden résumé (naam, e-mail, werkdata's, vaardigheden). Varieert per résumé format en complexiteit.

Wanneer elk gebruiken

• Wervings startup met 50 résumé's/maand: LLM + structuur. Kosten zijn verwaarloosbaar, nauwkeurigheid belangrijk voor kandidaat ervaring.
• Enterprise ATS met 10.000 résumé's/maand: Hybrid. LLM voor nieuwe intake, maar valideer tegen bestaande werknemers database. Als LLM faalt, teruggaan naar menselijke review.
• Hoog-volume laag-touch sourcing: Regex op je eigen PDF parsing stack. Accepteer 20% fout en gebruik downstream filters om het te vangen.
• Naleving/juridisch: Verlaat je nooit op geautomatiseerde extractie alleen. Altijd mens-verificatie vóór archivering.

Hoe ClarityHire resume parsing handelt

Wanneer een kandidaat een résumé uploadt of plakt, extraheert ClarityHire gestructureerde gegevens met Claude + Zod validatie. De extractie omvat naam, contactgegevens, werkgeschiedenis, onderwijs, en vaardigheden. Kandidaten herzien dan en corrigeren de geëxtraheerde gegevens voordat het in de pijplijn gaat — mens-in-de-lus derisicoserend het LLM's output.

Deze benadering handelt kosten (API oproepen) voor nauwkeurigheid en kandidaat ervaring. Een kandidaat ziet hun geparseerde gegevens en weet dat het goed is voordat zij worden geëvalueerd. Het voorkomt ook de "we hebben je gegevens verkeerd" verrassing later als een aanbiedingsbrief hun naam verkeerd gespeld heeft of je HR systeem laat zien dat ze ergens hebben gewerkt waar ze niet hebben.

Probeer resume parsing op ClarityHire