Parsing CV cu AI: Compromisuri de precizie între Regex, NLP și LLM-uri

Evoluția parsing-ului CV-urilor (și urmele sale)

Parsing-ul CV-urilor era cu adevărat teribil. Timp de decenii, cea mai bună soluție era să angajezi o companie ca Sovren să ruleze modele regex pe PDF-uri și să extragă name, email, phone, experience. Modelele funcționau pentru 60% din cazuri — CV-uri bine formatate cu structuri previzibile. Excepțiile (aranjamente neconvenționale, formate internaționale, emoji, tabele, titluri) cădeau prin răchiturile.

Acest compromis era acceptabil fiindcă nu existau alternative. Deci echipele de recrutare au creat soluții improvizate: revizuire manuală a datelor extrase, verificări de calitate backend, validare numere de telefon, și o acceptare pe jumătate că 15% din datele candidaților ar fi mutilate.

Apoi NLP (spaCy, StanfordNLP) a promis mai mult. Recunoașterea entităților numite pe text brut, fără a fi nevoie de regex. A funcționat—pentru sarcini de identificare entități. Dar parsing-ul CV-ului nu este doar identificare entități. Un CV este un document semantic: „2020–2022" sub un titlu nu este doar o dată, este o dată de început și sfărșit a unui job. Un model NLP antrenat pe articole de știri nu surprinde acel context.

Acum LLM-urile (Claude, GPT) pot citi context semantic. Dar LLM-urile sunt probabilistice. Fără structură, ele halucinez câmpuri, inventează titluri de job și uneori omit secțiuni întregi de experiență. Întrebarea este: cum faci ca un LLM să parseze în mod fiabil?

Unde se crapă fiecare abordare

Regex (era Sovren):

• Se crapă pe: Formatare non-standard (cronologie orizontală în loc de gloanțe), titluri de secțiuni în fonturi diferite, formate internaționale de nume, artefacte din extragere PDF (spații suplimentare, întreruperi de linie sparte).
• Funcționează pe: CV-uri bine formatate, cu o singură coloană, în engleză, de la absolvenți recenți sau medii corporative.
• Problemă: Fragilitate. Un PDF de pe Canva strică modelul.

NLP (spaCy, StanfordNLP):

• Se crapă pe: Înțelegerea semantică. „2020–2022" pare o dată pentru NLP. Dar de ce este pe acest CV? Sub ce job? Este o dată de început/sfărșit sau o calificare independentă?
• Funcționează pe: Extragerea entităților dacă documentul este curat și etichetat clar.
• Problemă: Fără context semantic. Un model NLP nu știe că „Python" sub „Skills" este diferit de „Python" în „Python consulting firm" (unealtă vs. nume companie).

LLM fără structură:

• Se crapă pe: Halucinații. „Extrage experiența de lucru a candidatului" returnează: [{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }] — dar doar una dintre acestea este pe CV. Sau omite secțiuni întregi fiindcă fereastra de context a modelului s-a închis.
• Funcționează pe: Rezumate și interpretări deschise.
• Problemă: Fără ghidaje. Modelul poate inventa date care sună plauzibil.

LLM cu promptare structurată (Zod/JSON Schema):

• Se crapă pe: Cazuri edge complexe (candidat cu 15 joburi, CV în engleză mixtă/non-engleză, format de certificare neobișnuit). Dar rar halucinații.
• Funcționează pe: ~95% din CV-uri care nu sunt adversariale.
• Problemă: Necesită definire schemă upfront și tuning prompt.

Ce rezolvă cu adevărat promptarea structurată

Promptarea structurată + validare (Zod, JSON Schema) forțează LLM-ul să rămână în ghidaje:

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.

Schema + validarea detectează halucinații. Dacă modelul inventează un al șaselea job când CV-ul listează patru, un validator poate să-l semnaleze. Dacă returnează start: "early 2020" (nu este valid), schema o respinge și cere modelului să se conformeze.

Aceasta nu elimină erorile—un LLM poate în continuare să citească greșit „2020–2022" ca „2020–2023"—dar previne tipurile de erori pe care regex și NLP nu le pot prinde: reordonare semantică, extragere contextuală, și parsing multi-document.

Compromisurile de precizie

*Precizie = câmpurile extrase se potrivesc cu adevărul terenului din CV (nume, email, date job, skills). Variază în funcție de format și complexitate CV.

Când să folosești fiecare

• Startup de recrutare cu 50 CV-uri/lună: LLM + structură. Costul este neglijabil, precizia contează pentru experiența candidatului.
• Enterprise ATS cu 10,000 CV-uri/lună: Hibrid. LLM pentru intrare nouă, dar validează pe baza bazei de date de angajați existenți. Dacă LLM eșuează, revine la revizuire umană.
• Sourcing high-volume low-touch: Regex pe stiva ta de parsing PDF. Acceptă 20% eroare și folosește filtre downstream pentru a o prinde.
• Conformitate/legal: Nu te baza niciodată doar pe extragere automatizată. Verifică întotdeauna cu om înainte de arhivare.

Cum gestionează ClarityHire parsing-ul CV-ului

Când un candidat încarcă sau lipește un CV, ClarityHire extrage date structurate folosind Claude + validare Zod. Extragerea include nume, informații de contact, istoric de lucru, educație și skills. Candidații apoi revizuiesc și corectează datele extrase înainte ca acestea să intre în pipeline—om în buclă, deriscând ieșirea LLM.

Această abordare schimbă costul (apeluri API) cu precizie și experiență candidat. Un candidat vede datele parsate și știe că sunt corecte înainte de a fi evaluat. De asemenea, previne surpriza „avem datele tale greșite" mai târziu când o ofertă de muncă are numele greșit scris sau sistemul tău HR arată că au lucrat undeva unde nu au lucrat.

Încearcă parsing CV pe ClarityHire