Analisi dei CV con AI: i compromessi di accuratezza tra Regex, NLP e LLM

L'evoluzione dell'analisi dei CV (e le sue tracce)

L'analisi dei CV era davvero terribile. Per decenni, la soluzione migliore era affidarsi a un'azienda come Sovren che eseguisse pattern regex su PDF ed estraesse name, email, phone, experience. I pattern funzionavano nel 60% dei casi — CV ben formattati con strutture prevedibili. I casi anomali (layout non convenzionali, formati internazionali, emoji, tabelle, intestazioni) cadevano negli interstizi.

Questo compromesso era accettabile perché non esistevano alternative. Così i team di recruiting crearono workaround: revisione manuale dei dati estratti, controlli di qualità backend, validazione dei numeri di telefono e una malinconica accettazione che il 15% dei dati dei candidati sarebbe stato compromesso.

Poi NLP (spaCy, StanfordNLP) promise qualcosa di meglio. Riconoscimento di entità nominate su testo grezzo, senza bisogno di regex. Ha funzionato — per compiti di identificazione di entità. Ma l'analisi dei CV non è solo identificazione di entità. Un CV è un documento semantico: "2020–2022" sotto un'intestazione non è solo una data, è una data di inizio e fine del lavoro. Un modello NLP addestrato su articoli di notizie non cattura quel contesto.

Ora gli LLM (Claude, GPT) possono leggere il contesto semantico. Ma gli LLM sono probabilistici. Senza struttura, allucinano campi, inventano titoli di lavoro e talvolta saltano intere sezioni di esperienza. La domanda è: come si fa a ottenere che un LLM analizzi in modo affidabile?

Dove ciascun approccio fallisce

Regex (era Sovren):

• Fallisce con: Formattazione non standard (timeline orizzontale anziché elenchi puntati), intestazioni di sezione in font diversi, formati di nomi internazionali, artefatti dell'estrazione PDF (spazi extra, interruzioni di riga compromesse).
• Funziona con: CV ben formattati, a singola colonna, in inglese di neolaureati o da ambienti aziendali.
• Problema: Fragilità. Un PDF da Canva rompe il pattern.

NLP (spaCy, StanfordNLP):

• Fallisce con: Comprensione semantica. "2020–2022" sembra una data per NLP. Ma perché è su questo CV? Sotto quale lavoro? È una data di inizio/fine o una credenziale autonoma?
• Funziona con: Estrazione di entità se il documento è pulito ed etichettato chiaramente.
• Problema: Nessun contesto semantico. Un modello NLP non sa che "Python" sotto "Competenze" è diverso da "Python" in "azienda di consulenza Python" (strumento vs. nome aziendale).

LLM senza struttura:

• Fallisce con: Allucinazione. "Estrai l'esperienza lavorativa del candidato" restituisce: [{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }] — ma solo uno di questi è nel CV. O sezioni intere mancanti perché la finestra di contesto del modello si è esaurita.
• Funziona con: Riassunti e interpretazioni aperte.
• Problema: Nessun guardrail. Il modello può inventare dati che suonano plausibili.

LLM con structured prompting (Zod/JSON Schema):

• Fallisce con: Casi edge complessi (candidato con 15 lavori, CV in inglese misto/non inglese, formato di certificazione inusuale). Ma raramente allucinazione.
• Funziona con: ~95% dei CV che non sono adversariali.
• Problema: Richiede definizione dello schema upfront e tuning del prompt.

Cosa risolve veramente il structured prompting

Lo structured prompting + validazione (Zod, JSON Schema) forza l'LLM a stare entro i guardrail:

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.

Lo schema + validazione cattura le allucinazioni. Se il modello inventa un sesto lavoro quando il CV ne elenca quattro, un validatore può segnalarlo. Se restituisce start: "early 2020" (non valido), lo schema lo rifiuta e chiede al modello di conformarsi.

Questo non elimina gli errori — un LLM può ancora malleggere "2020–2022" come "2020–2023" — ma previene i tipi di errori che regex e NLP non possono catturare: riordenamento semantico, estrazione contestuale e parsing multi-documento.

I compromessi di accuratezza

*Accuratezza = i campi estratti corrispondono al CV di riferimento (nome, email, date di lavoro, competenze). Varia in base al formato e alla complessità del CV.

Quando usare ciascuno

• Startup di recruiting con 50 CV/mese: LLM + struttura. Il costo è trascurabile, l'accuratezza conta per l'esperienza del candidato.
• ATS aziendale con 10.000 CV/mese: Ibrido. LLM per l'intake iniziale, ma convalida rispetto al database dei dipendenti esistenti. Se LLM fallisce, ricadi sulla revisione umana.
• Sourcing ad alto volume basso contatto: Regex sul tuo stack di parsing PDF. Accetta il 20% di errore e usa filtri downstream per catturarlo.
• Conformità/Legale: Non affidarti mai all'estrazione automatizzata da sola. Verifica sempre manualmente prima dell'archiviazione.

Come ClarityHire gestisce l'analisi dei CV

Quando un candidato carica o incolla un CV, ClarityHire estrae dati strutturati utilizzando Claude + validazione Zod. L'estrazione include nome, informazioni di contatto, cronologia lavorativa, istruzione e competenze. I candidati rivedono e correggono i dati estratti prima che entrino nella pipeline — human-in-the-loop che riduce il rischio dell'output dell'LLM.

Questo approccio compromette il costo (chiamate API) per l'accuratezza e l'esperienza del candidato. Un candidato vede i propri dati estratti e sa che sono corretti prima di essere valutato. Previene anche la sorpresa "abbiamo i tuoi dati sbagliati" più tardi quando una lettera di offerta ha il loro nome scritto male o il tuo sistema HR mostra che hanno lavorato da qualche parte dove non hanno lavorato.

Prova l'analisi dei CV su ClarityHire