AI Parsing CV: Compromisuri acuratete între Regex, NLP și LLM-uri
Evoluția parsing CV (și amprentele)
Parsing CV obișnuit să fie groaznic. Decenii, cea mai bună soluție era angajare companie ca Sovren pentru a rula modele regex pe PDF-uri și extrage nume, email, telefon, experiență. Modelele funcționau 60% din cazuri—CV-uri bine formatate cu structuri previzibil. Outliers (layout neconvențional, formate internațional, emoji, tabele, header-e) cădeau prin cărări.
Compromisul era acceptabil fiindcă alternativă nu exista. Deci echipe recrutare construiau workaround-uri: revizuire manuală date parsate, quality-check-uri backend, validare număr telefon și o acceptare reticență că 15% din date candidat ar fi stricată.
Apoi NLP (spaCy, StanfordNLP) promit mai bine. Named-entity recognition pe text brut, fără regex. Funcția—pentru sarcini entity-identification. Dar parsing CV nu-i doar entity identification. Un CV-u-i document semantic: "2020–2022" sub header nu-i doar dată,-i dată început și sfârșit muncă. Model NLP antrenată pe articole știri nu capturează context asta.
Acum LLM-uri (Claude, GPT) pot citi context semantic. Dar LLM-uri sunt probabilistice. Fără structură, halucinează câmpuri, inventează titluri job și uneori săresc secțiuni experiență. Întrebarea: cum obții LLM reliabil?
Unde se sparge fiecare abordare
Regex (era Sovren):
- Sparge pe: Formatare non-standard (timeline orizontal în loc bullet), header-e secțiuni în fonturi diferite, formate nume internațional, artefacte extracție PDF (spații extra, line break-uri rupte).
- Funcționează pe: CV-uri bine formatate, coloană singură, engleză din recent-absolvenți sau background corp.
- Problemă: Fragilitate. Un PDF din Canva rupe modelul.
NLP (spaCy, StanfordNLP):
- Sparge pe: Înțelegere semantic. "2020–2022" arată ca dată la NLP. Dar de ce e pe CV-ul ăsta? Sub care job? Dată început/sfârșit sau credential standalone?
- Funcționează pe: Extracție entitate dacă document curat și etichetat clar.
- Problemă: Fără context semantic. Model NLP nu știe că "Python" sub "Skills" diferă de "Python" în "Python consulting firm" (tool vs. nume companie).
LLM fără structură:
- Sparge pe: Halucinație. "Extract-ă experiența muncă" returnează:
[{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }]—dar doar unu din alea-i pe CV. Sau secțiuni missing complet fiindcă context window modelului-a tăiat. - Funcționează pe: Rezumate open-ended și interpretări.
- Problemă: Fără garde-rails. Model-ul poate inventa date plauzibil-sunând.
LLM cu structured prompting (Zod/JSON Schema):
- Sparge pe: Cazuri edge complexe (candidat cu 15 job-uri, CV mixt engleză/non-engleză, format certificare neobișnuit). Dar rar halucinație.
- Funcționează pe: ~95% din CV-uri care nu sunt adversare.
- Problemă: Cere definire schema upfront și tuning prompt.
Ce structured prompting rezolvă
Structured prompting + validare (Zod, JSON Schema) forțează LLM în garde-rails:
Extract date CV în schema asta:
{
name: string,
email: string,
phone: string,
experience: [{ title, company, start, end, summary }],
skills: [string],
education: [{ degree, field, school, graduationYear }]
}
Reguli:
- Dacă câmp missing, returnează null, nu valoare fabricată.
- Datelele trebuie YYYY sau YYYY-MM, nu string-uri fuzzy.
- Skills trebuie tool-uri/limbi menționate, nu adjective vague.
Schema + validare capturează halucinații. Dacă model inventează al șaselea job când CV-ul listează patru, validator-ul-o poate marca. Dacă returnează start: "early 2020" (invalid), schema-l respinge și cere model conform.
Asta nu elimină erorile—LLM-ul poate citi greșit "2020–2022" ca "2020–2023"—dar previne tipuri de erori ce regex și NLP nu pot: reordine semantic, extracție contextual și parsing multi-document.
Tradeoff-uri acuratete
| Abordare | Acuratete* | Latență | Cost | Robustețe |
|---|---|---|---|---|
| Regex | 60–70% | <100ms | $0.01/CV (onsite) | Fragil |
| NLP | 70–80% | 200–500ms | $0.02/CV | Medium |
| LLM (unstructured) | 80–90% | 1–3s | $0.10–0.50/CV | Apte halucinație |
| LLM + structură + validare | 92–98% | 1–3s | $0.10–0.50/CV | Robust |
*Acuratete = câmpuri extrase se potrivesc CV-u adevărat (nume, email, date muncă, skills). Variază format CV și complexitate.
Când folosești fiecare
- Startup recrutare cu 50 CV-uri/lună: LLM + structură. Cost neglijabil, acuratete contează pentru experiență candidat.
- Enterprise ATS cu 10.000 CV-uri/lună: Hibrid. LLM pentru intake nou dar validează contra bază date angajat existent. LLM-ul fals, cade la revizuire om.
- Sourcing volum-mare low-touch: Regex pe stack PDF parsing propriu. Accept 20% eroare și foloseşte downstream filtre catch asta.
- Conformitate/legal: Nu te baza pe extracție automatizată singur. Întotdeauna human-verify înainte de arhivă.
Cum tratează ClarityHire parsing CV
Când candidat uploadează sau pastează CV, ClarityHire extrage date structurate folosind Claude + validare Zod. Extracția includ nume, info contact, istoric muncă, educație și skills. Candidații apoi revizuiesc și corectează date extrase înainte să meargă în pipeline—human-in-the-loop derisc output LLM-ului.
Abordare asta trade-off cost (API calls) pentru acuratete și experiență candidat. Candidat vede date parsate și știe-i corect înainte de evaluare. Previne și surpriza "avem date ta greșit" mai târziu când scrisoare ofertă-i nume greșit sau sistem HR arată lucrat undeva nu ai.