Amazon ha costruito un'IA per il reclutamento che ha imparato da sola a odiare le donne. Io ne ho costruita una che non può farlo.

Nel 2014, un team di ingegneri di machine learning a Edimburgo si mise a risolvere il reclutamento su scala Amazon. Dai in pasto al sistema 100 curriculum, ottieni indietro i cinque migliori, classificati da una a cinque stelle — come si valutano i prodotti. Elegante. Efficiente. E nel giro di tre anni, scoprirono che il sistema aveva imparato da solo che essere donna era una caratteristica squalificante.

L'IA penalizzava i curriculum che contenevano la parola "femminile" — come in "Capitana del Club di Scacchi Femminile." Retrocedeva le laureate di due college interamente femminili. Non perché qualcuno gliel'avesse detto. Ma perché quando addestri un modello su dieci anni di dati di assunzione provenienti da un settore a predominanza maschile, "essere uomo" diventa, statisticamente, uno dei predittori più forti dell'"essere assunto."

Ricordo di aver letto l'inchiesta di Reuters quando uscì. Ero già immerso nella costruzione di sistemi basati su grafi della conoscenza in Veriprajna, e la mia prima reazione non fu lo shock — fu il riconoscimento. Sostenevo da mesi che i motori di correlazione statistica non avevano alcun titolo per prendere decisioni sul potenziale umano. La vicenda Amazon non era un'anomalia. Era un'inevitabilità matematica. E mi radicalizzò fino a farmi credere che l'intero approccio architetturale al reclutamento tramite IA fosse guasto — non ai margini, ma alle fondamenta.

Il problema non è il pregiudizio. È l'architettura.

Ecco cosa la maggior parte delle persone fraintende della debacle Amazon: pensa che gli ingegneri fossero sbadati. Non lo erano. Erano tra i migliori ingegneri di ML del pianeta. Quando scoprirono il pregiudizio di genere, provarono a correggerlo. Programmarono esplicitamente il modello affinché ignorasse i termini specifici di genere. E il modello trovò delle scappatoie.

Questo è il concetto di variabili proxy, ed è la cosa che mi tiene sveglio la notte. I modelli di deep learning sono cercatori di pattern implacabili. Rimuovi la parola "donna" dall'input, e il modello si aggrappa alla struttura della frase. Gli studi mostrano che i curriculum maschili tendono a usare verbi come "eseguito" e "conquistato," mentre i curriculum femminili propendono per un linguaggio più comunitario. Il modello vede "eseguito" correlare con "assunto" e ricostruisce silenziosamente il pregiudizio di genere attraverso la sola linguistica.

Gli ingegneri di Amazon non riuscivano a rimuovere chirurgicamente il pregiudizio senza distruggere la capacità predittiva del modello. Così uccisero l'intero progetto.

Non puoi correggere un sistema che discrimina per caso. Devi costruirne uno che non possa discriminare per progettazione.

Quella frase è stata la mia stella polare per tre anni. Ed è il motivo per cui abbiamo costruito il motore di reclutamento di Veriprajna su grafi della conoscenza invece che su reti neurali.

Perché ogni IA reclutatrice finisce prima o poi per imparare a discriminare?

Ho bisogno che tu comprenda una cosa su come funziona il deep learning nel reclutamento, perché la modalità di fallimento è controintuitiva.

Una rete neurale non capisce cosa significhi "Python." Non sa che Python è un linguaggio di programmazione utile per la data science. Sa soltanto che la stringa "Python" compariva frequentemente nei curriculum delle persone che venivano assunte. Se anche "Lacrosse" comparisse frequentemente — magari a causa di correlazioni socioeconomiche tra certi sport e certe scuole che alimentano certe aziende — il modello potrebbe pesare "Lacrosse" quanto "Python."

Questa è correlazione che si maschera da intelligenza. Il modello non ragiona su causa ed effetto. Trova pattern e li ottimizza. Ed ecco la parte insidiosa: amplificazione del pregiudizio significa che questi modelli non si limitano a replicare i pregiudizi storici — li esagerano. Se gli uomini rappresentavano il 60% della forza lavoro nei dati di addestramento, il modello potrebbe spingere verso l'assunzione dell'80% o 90% di uomini per massimizzare il proprio punteggio di accuratezza.

Ebbi una conversazione con un potenziale investitore all'inizio, che mi disse: "Usa semplicemente GPT-4 per lo screening dei curriculum. Lo fanno tutti gli altri." Gli chiesi: se dai in pasto lo stesso curriculum a GPT-4 due volte, ottieni lo stesso punteggio? Esitò. La risposta è no — gli LLM sono stocastici. Sono non deterministici. Esegui lo stesso input due volte, ottieni due output diversi. In uno scenario di audit, non è una stranezza. È un fallimento di conformità.

I muri normativi si stanno stringendo

Questo non è più teorico. I governi hanno visto la vicenda Amazon e stanno legiferando.

La NYC Local Law 144, in vigore da luglio 2023, richiede che qualsiasi datore di lavoro che utilizzi uno strumento automatizzato di decisione occupazionale si sottoponga a un audit annuale indipendente sui pregiudizi. Non un vago audit del tipo "abbiamo verificato l'equità" — uno specifico e quantitativo. La legge impone il calcolo dei tassi di selezione e dei rapporti di impatto per ogni categoria di razza, etnia e sesso. Se il tasso di selezione di un gruppo protetto diviso per il tasso del gruppo più selezionato scende sotto lo 0,8 — la "regola dei quattro quinti" — questo costituisce prova prima facie di impatto disparato.

L'EU AI Act si spinge oltre. Classifica i sistemi di IA utilizzati per il reclutamento come ad Alto Rischio — la stessa categoria dei dispositivi medici e delle infrastrutture critiche. L'Articolo 13 esige che questi sistemi siano "sufficientemente trasparenti da consentire agli utenti di interpretare l'output del sistema." L'Articolo 14 richiede la supervisione umana — la capacità di annullare le decisioni dell'IA. Ma non puoi annullare in modo significativo una decisione che non comprendi.

E ai sensi del GDPR, l'Articolo 15(1)(h) concede agli interessati il diritto di accedere a "informazioni significative sulla logica utilizzata" nelle decisioni automatizzate. Il Considerando 71 menziona esplicitamente il diritto di "ottenere una spiegazione della decisione raggiunta."

Prova a spiegare la decisione di una rete neurale. Provaci. "Il neurone 4.502 si è attivato con intensità 0,8" non è una spiegazione significativa. E nemmeno lo è "il modello ha determinato che eri compatibile al 73%" senza ulteriori dettagli.

Il divario tra la complessità tecnica e il requisito legale di una spiegazione semplice è la crisi centrale della moderna HR Tech.

Ho scritto in modo più approfondito su questo panorama normativo nella versione interattiva del nostro whitepaper, che illustra esattamente come ciascuna normativa si applichi alle diverse architetture di IA.

E se l'IA non potesse affatto vedere il genere?

È qui che ho bisogno di raccontarti della notte in cui tutto ha avuto un senso per me.

Avevamo sperimentato approcci diversi al debiasing — addestramento avversariale, aumento controfattuale, il solito repertorio. Ed ero seduto nel nostro ufficio alle 23, a fissare una visualizzazione a grafo sul mio schermo, quando ebbi una di quelle intuizioni ovvie a posteriori: stavamo cercando di insegnare al modello a ignorare il pregiudizio. E se avessimo costruito un'architettura in cui il pregiudizio letteralmente non potesse entrare nel motore di ragionamento?

In un grafo della conoscenza, i dati sono archiviati come nodi (entità) e archi (relazioni). Un nodo Persona si collega a nodi Competenza. I nodi Competenza si collegano ad altri nodi Competenza tramite relazioni semantiche. Il grafo sa che "PyTorch" è una libreria per il "Deep Learning," che è un sottoinsieme dell'"Intelligenza Artificiale." Quindi se un lavoro richiede "esperienza in IA" e un candidato elenca "PyTorch," il grafo traccia il percorso e trova una corrispondenza — anche senza che la parola chiave "IA" compaia da nessuna parte nel curriculum.

Ecco la decisione architetturale cruciale: quando il nostro algoritmo di matching viene eseguito, opera su un sottografo ristretto. Questo grafo di inferenza contiene Competenze, Ruoli, Livelli di esperienza e Certificazioni. Esclude esplicitamente i nodi per Nome, Genere, Etnia, Indirizzo e date di laurea.

Il pregiudizio non viene soppresso. Viene strutturalmente reciso. Non esiste alcun percorso da "Candidato" a "Genere" a "Ruolo" perché il nodo Genere non esiste nel grafo che l'algoritmo può vedere.

Confronta questo con un modello di deep learning, che ingerisce l'intero testo grezzo. Anche se rimuovi il campo "Genere," il modello legge "Club di Scacchi Femminile" e deduce il genere. Nel nostro sistema, l'LLM che analizza il curriculum mappa "Club di Scacchi Femminile" su un nodo neutralizzato: (:Activity {type: "Strategy Club", role: "Leadership"}). Il modificatore di genere viene rimosso prima che entri nel motore di ragionamento.

Ricordo la discussione del team a riguardo. Uno dei miei ingegneri oppose una forte resistenza — riteneva che stessimo perdendo un segnale prezioso rimuovendo il contesto. "E se il Club di Scacchi Femminile fosse in realtà più competitivo di quello normale?" Osservazione legittima. Ma non stavamo ottimizzando per la massima estrazione di informazioni. Stavamo ottimizzando per l'equità sotto il vaglio legale. E preferisco perdere un segnale marginale piuttosto che costruire un sistema che impara a penalizzare metà della popolazione.

Come si misura davvero il talento senza pregiudizi?

Non prevediamo chi avrà successo. Misuriamo la distanza tra competenze — il divario geometrico tra ciò che un candidato possiede e ciò che un lavoro richiede. Questo sposta il reclutamento dalla probabilità soggettiva alla misurazione oggettiva.

I tradizionali sistemi di tracciamento delle candidature usano la logica booleana: il curriculum contiene la parola chiave "Java"? Sì o no. Questo è fragile e stupido. Manca chiunque usi una terminologia diversa per la stessa competenza.

Noi usiamo i graph embedding — algoritmi come Node2Vec che apprendono una rappresentazione vettoriale per ogni competenza nella nostra ontologia. Le competenze che co-occorrono frequentemente nel grafo (come "Python" e "Pandas") finiscono vicine tra loro nello spazio vettoriale. Le competenze non correlate (come "Python" e "Flebotomia") finiscono lontane tra loro.

Per assegnare un punteggio a un candidato, calcoliamo la similarità del coseno tra l'insieme di vettori delle competenze del candidato e l'insieme di vettori dei requisiti del lavoro. Questo ci dà un credito parziale. Un candidato a cui manca "Tableau" ma che ha "Power BI" ottiene un alto punteggio di similarità perché quei nodi sono vicini semantici nel cluster della "Business Intelligence." Una ricerca per parola chiave gli assegnerebbe uno zero.

Aggiungiamo a livelli la similarità di Jaccard per la sovrapposizione grezza delle competenze e la distanza geodetica — calcoli del percorso più breve attraverso il grafo — per l'analisi dei divari. Se un lavoro richiede Kubernetes e un candidato ha Docker, il grafo trova il percorso: Docker → Containerizzazione → Orchestrazione → Kubernetes. Distanza: 3 salti. Interpretazione: addestrabile. Se la distanza è di 6+ salti, è un divario incolmabile.

Il punteggio finale di distanza tra competenze è una metrica puramente basata sulle competenze, completamente cieca alle caratteristiche demografiche. Non indoviniamo chi è bravo. Misuriamo quanto sono vicini.

Per l'analisi tecnica completa di questi algoritmi — inclusa la matematica dietro la similarità del coseno e il nostro modello di punteggio composito — consulta il nostro paper di ricerca.

Il momento "SQL mancante"

Lasciami rendere questo concreto con qualcosa accaduto durante i test.

Abbiamo fatto passare il profilo di un candidato sia attraverso un reclutatore scatola nera standard sia attraverso il nostro sistema. La scatola nera ha respinto il candidato. Nessuna ragione fornita. (In seguito abbiamo determinato che il candidato aveva frequentato un piccolo college poco conosciuto — una classica penalizzazione da pedigree.)

Il nostro sistema ha restituito questo: "Al candidato manca un'esperienza esplicita in SQL. Tuttavia, l'analisi del grafo mostra una vasta esperienza con Pandas DataFrame e R dplyr. La distanza nel grafo tra DataFrame e SQL è breve (concetto condiviso: Manipolazione dei Dati). Raccomandazione: Colloquio. Alta trasferibilità."

Quel candidato — quello che la scatola nera aveva scartato — aveva ogni competenza di cui il lavoro aveva bisogno. Usava semplicemente parole diverse per esprimerle. Ed era andato in una scuola che la scatola nera non aveva visto abbastanza nei suoi dati di addestramento da considerare "di successo."

Questo è ciò che intendo quando dico che i grafi della conoscenza ampliano il bacino di talenti. Trovano persone che hanno le competenze ma non il pedigree o il vocabolario esatto. E questo migliora naturalmente la diversità — non attraverso quote o correzioni, ma attraverso una misurazione migliore.

Cosa succede quando il sistema segnala un problema?

Le persone mi chiedono: "E se il tuo sistema producesse comunque esiti pregiudiziali?" È una domanda legittima, e diffiderei di chiunque affermasse che il proprio sistema è perfetto.

Ecco la differenza: quando una scatola nera produce esiti pregiudiziali, sei bloccato. Puoi vedere l'impatto disparato nei numeri, ma non puoi vedere perché. Sono i nomi delle università? I codici postali? Lo stile di scrittura? Stai facendo il debug di un sistema con milioni di parametri e nessuna logica leggibile.

Quando il nostro sistema produce un'anomalia statistica — diciamo, un rapporto di impatto inferiore a 0,8 per un particolare gruppo demografico — possiamo tracciarla. Possiamo identificare gli specifici nodi del grafo che causano la disparità. Magari una descrizione del lavoro richiede una particolare certificazione costosa che correla con lo status socioeconomico. Possiamo vederlo, segnalarlo, e il team di assunzione può decidere se quella certificazione sia davvero necessaria o solo un requisito ereditato che nessuno ha mai messo in discussione.

La scatola di vetro non significa che il sistema abbia sempre ragione. Significa che quando sbaglia, puoi scoprire perché e correggerlo.

L'LLM ha ancora un lavoro — solo non quello importante

Voglio essere chiaro: usiamo gli LLM. Non siamo luddisti. Ma li usiamo nel modo in cui useresti un traduttore — per leggere e scrivere, non per giudicare.

La nostra architettura impone una rigorosa separazione delle responsabilità. L'LLM si occupa della percezione: legge il testo non strutturato del curriculum ed estrae le entità. "Ho orchestrato un team di 5 sviluppatori per costruire un'app React Native" diventa dati strutturati — Competenza: React Native, Competenza: Leadership di Team, Contesto: Sviluppo Mobile. L'LLM normalizza i sinonimi: "ReactJS" e "React.js" mappano entrambi sullo stesso nodo.

Ma l'LLM non prende mai una decisione di assunzione. Tutto il matching, il punteggio e la classificazione avvengono attraverso l'attraversamento deterministico del grafo. Stesso grafo più stessa query uguale stesso risultato, ogni volta. Usiamo l'LLM anche all'estremità dell'output — genera spiegazioni leggibili dall'uomo, ma solo a partire da fatti verificati dal grafo. Non può allucinare una corrispondenza di competenze che il grafo non supporta.

Lo penso come se l'LLM fosse gli occhi e la bocca del sistema, mentre il grafo della conoscenza è il cervello. Non lasceresti che la tua bocca prenda decisioni al posto tuo. (Beh, la maggior parte di noi non lo farebbe.)

Tra cosa stiamo davvero scegliendo?

Per come la vedo io, il settore è a un bivio. Un percorso porta a modelli più grandi, più parametri, più opacità — e a un interminabile gioco di acchiapparella con il pregiudizio che continua a trovare nuove variabili proxy da sfruttare. L'altro percorso porta al ragionamento strutturato, alla misurazione semantica e a sistemi che possono spiegarsi a un regolatore, a un reclutatore o a un candidato respinto.

Ho parlato con responsabili HR di aziende che usano ancora strumenti di screening scatola nera. Conoscono il rischio. Hanno letto di Amazon. Ma cambiare architettura appare costoso e incerto, così continuano a rattoppare. Aggiungono "strati di mitigazione del pregiudizio" sopra sistemi fondamentalmente pregiudiziali. Assumono consulenti per condurre audit annuali che dicono loro cosa è rotto senza dar loro gli strumenti per ripararlo.

I dati sono uno specchio. Se addestri un modello sul passato, replichi il passato. In un mondo che aspira all'equità, replicare il passato è una condizione di fallimento.

Non chiuderò con una cautela. Ho passato anni a costruire questo, ho visto l'alternativa fallire in modo spettacolare, e sono sicuro della conclusione: il futuro dell'IA per il reclutamento non consiste nel prevedere chi avrà successo in base a chi ha avuto successo prima. Consiste nel misurare la distanza reale tra ciò che qualcuno sa fare e ciò che un lavoro richiede — e nel rendere quella misurazione trasparente, deterministica e strutturalmente incapace di discriminare.

Puoi continuare a prevedere il passato. Oppure puoi iniziare a misurare il futuro.