AI-hervattingsparsering: Nauwkeurigheidsafwegingen tussen Regex, NLP en LLM's
De evolutie van hervattingsparsering (en haar voetafdrukken)
Hervattingsparsering was eens echt afschuwelijk. Decennialang was de beste oplossing het inhuren van een bedrijf zoals Sovren om regexpatronen op PDF's uit te voeren en naam, e-mail, telefoonnummer, ervaring te extraheren. De patronen werkten in 60% van de gevallen — goed opgestelde hervattingen met voorspelbare structuren. Afwijkingen (onconventionele lay-outs, internationale formaten, emoji's, tabellen, koppen) vielen door het net.
Deze afweging was acceptabel omdat geen alternatief bestond. Dus bouwden wervingsteams workarounds: handmatige controle van geparseerde gegevens, backend kwaliteitschecks, telefoonnummervalidatie en een tegenzin om te accepteren dat 15% van de kandidaatgegevens beschadigd zou zijn.
Daarna beloofde NLP (spaCy, StanfordNLP) beter. Named-entity recognition op onbewerkte tekst, geen regex nodig. Het werkte — voor entiteitsidentificatietaken. Maar hervattingsparsering is niet alleen entiteitsidentificatie. Een hervatting is een semantisch document: "2020–2022" onder een kop is niet alleen een datum, het is een werkstart- en einddatum. Een NLP-model dat is getraind op nieuwsartikelen legt die context niet vast.
Nu kunnen LLM's (Claude, GPT) semantische context lezen. Maar LLM's zijn probabilistisch. Zonder structuur hallucineren ze velden, verzinnen functietitels en slaan soms hele ervaringssecties over. De vraag is: hoe zorg je ervoor dat een LLM betrouwbaar parseert?
Waar elke benadering faalt
Regex (Sovren-era):
- Faalt bij: Niet-standaard opmaak (horizontale tijdlijn in plaats van opsommingstekens), sectiekoppen in verschillende lettertypen, internationale naamformaten, PDF-extractiefouten (extra spaties, onderbroken regelbreeuken).
- Werkt bij: Goed opgestelde, single-column, Engelse hervattingen van recent afgestudeerden of bedrijfsachtergronden.
- Probleem: Fragiel. Één PDF van Canva breekt het patroon.
NLP (spaCy, StanfordNLP):
- Faalt bij: Semantisch begrip. "2020–2022" ziet eruit als een datum voor NLP. Maar waarom staat het op deze hervatting? Onder welke baan? Is het een begin-/einddatum of een zelfstandige kwalificatie?
- Werkt bij: Entiteitsextractie 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-consultingbedrijf" (tool versus bedrijfsnaam).
LLM zonder structuur:
- Faalt bij: Hallucinatie. "Haal de werkervaring van de kandidaat uit" geeft:
[{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }]— maar slechts één daarvan staat op de hervatting. Of hele secties ontbreken omdat het contextvenster van het model werd afgekapt. - Werkt bij: Open eindesamenvattingen en interpretaties.
- Probleem: Geen richtlijnen. Het model kan plausibel klinkende gegevens verzinnen.
LLM met gestructureerde prompting (Zod/JSON Schema):
- Faalt bij: Complexe randgevallen (kandidaat met 15 banen, hervatting in gemengd Engels/niet-Engels, ongewone certificeringsopmaak). Maar zelden hallucinatie.
- Werkt bij: ~95% van hervattingen die niet adversariaal zijn.
- Probleem: Vereist voorafgaande schemadefinitie en prompttuning.
Wat gestructureerde prompting werkelijk oplost
Gestructureerde prompting + validatie (Zod, JSON Schema) forceert de LLM om binnen richtlijnen te blijven:
Extract resume data into this schema:
{
name: string,
email: string,
phone: string,
experience: [{ title, company, start, end, summary }],
skills: [string],
education: [{ degree, field, school, graduationYear }]
}
Rules:
- If a field is missing, return null, not a fabricated value.
- Dates must be YYYY or YYYY-MM, not fuzzy strings.
- Skills should be tools/languages mentioned, not vague adjectives.
Het schema + validatie vangt hallucinaties. Als het model een zesde baan verzint terwijl de hervatting vier vermeldt, kan een validator dit markeren. Als het start: "early 2020" teruggeeft (niet geldig), weigert het schema het en vraagt het model zich aan te passen.
Dit elimineert fouten niet — een LLM kan "2020–2022" nog steeds als "2020–2023" misinterpreteren — maar het voorkomt de soorten fouten die regex en NLP niet kunnen opvangen: semantische herschikking, contextuele extractie en parsing van meerdere documenten.
De nauwkeurigheidsafwegingen
| Benadering | Nauwkeurigheid* | Latentie | Kosten | Robuustheid |
|---|---|---|---|---|
| Regex | 60–70% | <100ms | $0,01/hervatting (ter plaatse) | Fragiel |
| NLP | 70–80% | 200–500ms | $0,02/hervatting | Gemiddeld |
| LLM (ongestructureerd) | 80–90% | 1–3s | $0,10–0,50/hervatting | Gevoelig voor hallucinatie |
| LLM + structuur + validatie | 92–98% | 1–3s | $0,10–0,50/hervatting | Robuust |
*Nauwkeurigheid = geëxtraheerde velden komen overeen met de originele hervatting (naam, e-mail, werkdatums, vaardigheden). Varieert afhankelijk van hervatteringsopmaak en complexiteit.
Wanneer elk gebruiken
- Starterswervingsbedrijf met 50 hervattingen/maand: LLM + structuur. Kosten zijn verwaarloosbaar, nauwkeurigheid is belangrijk voor kandidaatervaring.
- Enterprise ATS met 10.000 hervattingen/maand: Hybride. LLM voor nieuwe inname, maar validatie tegen bestaande werknemersdatabase. Als LLM faalt, val terug op menselijke beoordeling.
- Bronnen met hoog volume en laag contact: Regex op uw eigen PDF-parsestack. Accepteer 20% fout en gebruik downstreamfilters om het op te vangen.
- Naleving/juridisch: Vertrouw nooit alleen op geautomatiseerde extractie. Laat altijd door mensen verifiëren vóór archivering.
Hoe ClarityHire hervattingsparsering aanpakt
Wanneer een kandidaat een hervatting uploadt of plakt, extraheert ClarityHire gestructureerde gegevens met behulp van Claude + Zod-validatie. De extractie omvat naam, contactgegevens, werkgeschiedenis, onderwijs en vaardigheden. Kandidaten beoordelen en corrigeren de geëxtraheerde gegevens vervolgens voordat deze in de pijplijn gaan — menselijke controle vermindert het risico van de LLM-uitvoer.
Deze benadering handelt kosten (API-aanroepen) in voor nauwkeurigheid en kandidaatervaring. Een kandidaat ziet zijn of haar geparseerde gegevens en weet dat het juist is voordat deze worden geëvalueerd. Het voorkomt ook de verrassing van "we hebben uw gegevens verkeerd" later wanneer een aanbiedingsbrief hun naam verkeerd spelt of uw HR-systeem aangeeft dat zij ergens hebben gewerkt waar zij niet hebben gewerkt.