Resume Parsing con IA: Tradeoff di Accuratezza tra Regex, NLP e LLM

L'evoluzione del resume parsing (e le sue impronte)

Il resume parsing era terribile davvero. Per decenni, la miglior soluzione era assumere un'azienda come Sovren per eseguire pattern regex su PDF ed estrarre name, email, phone, experience. I pattern funzionavano per il 60% dei casi — resume ben formattati con strutture prevedibili. Gli outlier (layout non convenzionali, formati internazionali, emoji, tabelle, intestazioni) cadevano in gap.

Questo tradeoff era accettabile perché nessuna alternativa esisteva. Così i team di assunzione costruirono workaround: revisione manuale dei dati parsati, quality-check backend, validazione numero di telefono e un'accettazione riluttante che il 15% dei dati dei candidati sarebbe stata manomessa.

Poi NLP (spaCy, StanfordNLP) promisero meglio. Named-entity recognition su testo grezzo, nessun regex necessario. Funzionava — per compiti di identificazione di entità. Ma il resume parsing non è solo identificazione di entità. Un resume è 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 a volte saltano interi sezioni di esperienza. La domanda è: come fai un LLM a parsare in modo affidabile?

Dove ogni approccio fallisce

Regex (era Sovren):

• Fallisce su: Formattazione non standard (timeline orizzontale invece di bullet), intestazioni di sezione in font diversi, formati di nomi internazionali, artefatti di estrazione PDF (spazi extra, line break rotte).
• Funziona su: Resume ben formattati, colonna singola, in inglese di neolaureati o background aziendale.
• Problema: Fragilità. Un PDF da Canva rompe il pattern.

NLP (spaCy, StanfordNLP):

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

LLM senza struttura:

• Fallisce su: Allucinazione. "Estrai l'esperienza lavorativa del candidato" ritorna: [{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }] — ma solo uno di questi è sul resume. O sezioni mancanti completamente perché la finestra di contesto del modello si è tagliata.
• Funziona su: Riassunti e interpretazioni open-ended.
• Problema: Nessun guardrail. Il modello può inventare dati plausibili.

LLM con structured prompting (Zod/JSON Schema):

• Fallisce su: Edge case complessi (candidato con 15 lavori, resume in inglese/non-inglese misto, formato di certificazione inusuale). Ma raramente allucinazione.
• Funziona su: ~95% di resume che non sono avversari.
• Problema: Richiede definizione di schema anticipata e tuning del prompt.

Cosa lo structured prompting risolve davvero

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

Estrai dati di resume in questo schema:
{
  name: string,
  email: string,
  phone: string,
  experience: [{ title, company, start, end, summary }],
  skills: [string],
  education: [{ degree, field, school, graduationYear }]
}

Regole:
- Se un campo è mancante, ritorna null, non un valore fabbricato.
- Le date devono essere YYYY o YYYY-MM, non stringhe fuzzy.
- Le competenze dovrebbero essere strumenti/linguaggi menzionati, non aggettivi vaghi.

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

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

I tradeoff di accuratezza

*Accuratezza = campi estratti corrispondono al resume ground truth (nome, email, date di lavoro, competenze). Varia per formato di resume e complessità.

Quando usare ognuno

• Startup di recruiting con 50 resume/mese: LLM + struttura. Il costo è trascurabile, l'accuratezza conta per l'esperienza candidato.
• ATS aziendale con 10.000 resume/mese: Ibrido. LLM per new intake, ma valida contro database di dipendenti esistenti. Se LLM fallisce, fallback a revisione umana.
• Sourcing ad alto volume basso contatto: Regex sul tuo stack di parsing PDF. Accetta errore del 20% e usa filtri a valle per prenderlo.
• Conformità/legale: Non fare mai affidamento su estrazione automatizzata sola. Sempre verifica umana prima di archivio.

Come ClarityHire gestisce il resume parsing

Quando un candidato carica o incolla un resume, ClarityHire estrae dati strutturati usando Claude + validazione Zod. L'estrazione include nome, info di contatto, cronologia lavoro, educazione e competenze. I candidati rivedono e correggono i dati estratti prima che vadano nella pipeline — human-in-the-loop derisking dell'output dell'LLM.

Questo approccio fa tradeoff del costo (chiamate API) per accuratezza ed esperienza candidato. Un candidato vede i suoi dati parsati e sa che è corretto prima di essere valutato. Previene anche la sorpresa "abbiamo i tuoi dati sbagliati" più tardi quando una lettera di offerta ha il loro nome maldelineato o il tuo sistema HR mostra che hanno lavorato da qualche parte che non hanno.

Prova resume parsing su ClarityHire