Fairness-in-the-Workflow: How Machine Learning Practitioners at Big Tech Companies Approach Fairness in Recommender Systems

Attraverso interviste a 11 professionisti di grandi aziende tecnologiche, questo studio analizza le sfide pratiche nell'integrare l'equità nei sistemi di raccomandazione e offre raccomandazioni concrete per migliorare la collaborazione interdisciplinare e i flussi di lavoro tecnici.

L'essenziale

Immaginate che i sistemi di raccomandazione (quelli che vi suggeriscono film su Netflix, prodotti su Amazon o video su TikTok) siano come dei grandi chef che cucinano un menu personalizzato per milioni di persone ogni giorno.

Il problema è che questi chef, se non stanno attenti, potrebbero servire sempre lo stesso piatto a tutti, o peggio, servire piatti che piacciono solo a un certo gruppo di persone, ignorando o addirittura danneggiando gli altri. Questo è il problema della ingiustizia (o "bias") negli algoritmi.

Questo articolo racconta cosa succede "dietro le quinte" nelle grandi aziende tecnologiche (come Google, Meta, Amazon, ecc.) quando i programmatori cercano di rendere questi chef più giusti. Gli autori hanno intervistato 11 di questi chef (ingegneri e ricercatori) per capire come lavorano davvero.

Ecco i punti chiave spiegati con parole semplici e metafore:

1. Il Ricettario è Confuso (La Sfida Tecnica)

Cosa significa essere "giusti"? È come chiedere a uno chef: "Devo servire porzioni uguali a tutti, o devo assicurarmi che tutti abbiano lo stesso sapore?".

• Il dilemma: Per un sistema di raccomandazione, la giustizia non è un concetto fisso. A volte significa dare visibilità a chi è meno famoso (il "povero" che vende le sue creazioni), altre volte significa mostrare a un utente esattamente ciò che gli piace (anche se è un gusto di nicchia).
• Il problema: Spesso questi obiettivi si scontrano. Se il chef cerca di aiutare i piccoli venditori, potrebbe mostrare prodotti che all'utente non piacciono affatto. Gli ingegneri devono decidere chi ascoltare: il venditore o il compratore? E come si misura questa "giustizia" quando non esiste una legge precisa che lo dica? Spesso devono inventare le loro regole mentre lavorano, senza un manuale di istruzioni chiaro.

2. Troppi Ospiti al Tavolo (Molti Interessi in Gioco)

Immaginate un ristorante dove, oltre ai clienti, ci sono anche i fornitori di ingredienti, i proprietari del locale e gli investitori. Tutti vogliono cose diverse:

• I fornitori (creatori di contenuti) vogliono essere visti da tutti.
• I clienti (utenti) vogliono vedere solo ciò che amano.
• L'azienda vuole che tutti rimangano nel ristorante il più a lungo possibile.
  Gli ingegneri devono bilanciare questi interessi come un equilibrista su una corda. Se sposta troppo il peso da una parte, tutto crolla. Inoltre, ci sono migliaia di gruppi diversi (persone di diverse età, culture, gusti), e assicurarsi che nessuno venga ignorato è come cercare di accontentare ogni singolo commensale in una sala da ballo enorme.

3. Il Ristorante è in Movimento (Ambienti Dinamici)

A differenza di un test in laboratorio, questi sistemi sono come un ristorante che cambia menu ogni secondo in base a cosa ordinano i clienti.

• Il ciclo di feedback: Se mostri a un utente un video divertente, lui lo guarda. L'algoritmo pensa: "Aha! Gli piacciono i video divertenti!" e ne mostra altri simili. Ma se quell'utente era solo curioso e non vuole vedere solo quel tipo di video, l'algoritmo lo intrappola in una "bolla".
• Gli ingegneri devono correggere questi errori mentre il sistema è già in funzione, come un chef che deve cambiare gli ingredienti della zuppa mentre è già sul fuoco e la gente la sta mangiando. È rischioso e difficile.

4. La Comunicazione tra i Dipartimenti (Le Sfide Organizzative)

Qui entra in gioco la parte umana e aziendale.

• Il problema del tempo: Gli ingegneri sono sotto pressione. Devono fare in modo che il sito non si blocchi e che le vendite salgano. La "giustizia" è spesso vista come un compito extra, qualcosa da fare "se avanza tempo". Ma come dice uno degli intervistati: "Non abbiamo il tempo di dedicare metà della giornata a pulire il sistema, anche se vorremmo".
• Due lingue diverse: C'è un muro tra i tecnici (gli ingegneri) e i team di "etica/fairness" (gli esperti di giustizia).
  • I tecnici parlano di "codice", "metriche" e "modelli".
  • Gli esperti di etica parlano di "psicologia", "bias sociali" e "diritti".
  • È come se uno parlasse italiano e l'altro cinese: capiscono che l'altro sta cercando di aiutare, ma faticano a tradurre le richieste in azioni concrete.
• La differenza con gli avvocati: Curiosamente, gli ingegneri dicono di comunicare molto bene con il dipartimento legale. Gli avvocati dicono: "Non puoi usare questo dato, è illegale". Punto. È chiaro. Con il team etico, invece, le regole sono sfumate: "Dovresti provare a essere più equo", ma non dicono come. Questo crea confusione.

5. Cosa Suggeriscono gli Autori? (I Consigli per il Futuro)

Per migliorare la situazione, gli autori propongono alcune soluzioni pratiche:

1. Scrivere meglio le ricette (Documentazione): Le aziende devono tenere traccia di come hanno deciso di essere giusti, così che quando un nuovo ingegnere arriva, non deve ricominciare da zero.
2. Coinvolgere l'etica prima: Invece di chiamare il team etico solo quando il sistema è già pronto (quando è troppo tardi per cambiare), dovrebbero essere coinvolti fin dalla fase di progettazione, come un architetto che disegna un edificio accessibile fin dal primo schizzo.
3. Creare un "linguaggio comune": Bisogna trovare un modo per far parlare tecnici ed esperti di etica nella stessa lingua, magari creando strumenti che traducano i principi morali in istruzioni tecniche chiare.
4. Investire tempo: Le aziende devono riconoscere che fare il lavoro di "giustizia" richiede tempo e risorse, e non deve essere un compito nascosto che gli ingegneri fanno nel tempo libero.

In Sintesi

Il messaggio finale è ottimista ma realistico: gli ingegneri delle grandi aziende vogliono fare la cosa giusta e si sentono in dovere morale di farlo. Tuttavia, sono intrappolati in un sistema complesso dove le regole non sono chiare, il tempo scarseggia e le lingue tecniche e umane non si capiscono perfettamente. Per risolvere il problema, non serve solo più codice, ma un cambiamento nel modo in cui le aziende organizzano il lavoro e parlano tra loro.

Sommario tecnico

1. Il Problema

I sistemi di raccomandazione (RS) sono onnipresenti in settori ad alto rischio come l'e-commerce e i social media, ma sono suscettibili a bias che possono generare impatti sociali, psicologici e ideologici su larga scala. Sebbene la ricerca accademica abbia proposto numerosi metodi per misurare e mitigare tali bias, esiste un divario significativo tra la teoria accademica e la pratica industriale.
La complessità risiede nel fatto che:

• Definizione dinamica: La "fairness" (equità) non è un concetto statico nei RS, ma varia a seconda del contesto.
• Multi-stakeholder: I RS operano in mercati a più lati, bilanciando gli interessi spesso conflittuali di fornitori (creatori di contenuti, venditori) e utenti finali.
• Ambienti dinamici: I RS sono sistemi collaborativi soggetti a loop di feedback, dove le interazioni degli utenti influenzano i futuri risultati, amplificando potenziali disparità.
• Vincoli reali: L'implementazione pratica richiede di navigare vincoli normativi, aziendali e tecnici, spesso in assenza di strumenti standardizzati pronti all'uso.

2. Metodologia

Gli autori hanno condotto uno studio empirico qualitativo basato su 11 interviste semi-strutturate con praticanti tecnici (Machine Learning Engineer, Researcher, Scientist) che lavorano su sistemi di raccomandazione in sette grandi aziende tecnologiche ("Big Tech").

• Partecipanti: Tutti i partecipanti lavorano per aziende che servono oltre un miliardo di utenti l'anno e hanno una media di 5,36 anni di esperienza.
• Obiettivi della ricerca:
  • RQ1: Mappare i flussi di lavoro tecnici e di equità dei praticanti RS e come questi si intersecano.
  • RQ2: Identificare le sfide tecniche e organizzative nell'integrare l'equità nei flussi di lavoro tecnici.
• Analisi: È stata utilizzata un'analisi tematica induttiva sui trascritti delle interviste per mappare i flussi di lavoro e identificare i temi ricorrenti relativi alle sfide.

3. Contributi Chiave

Il paper offre tre contributi principali:

1. Mappatura del Flusso di Lavoro RS: Una visualizzazione dettagliata di come i team tecnici integrano l'equità (a) internamente e (b) in collaborazione con team legali, dati e fairness.
2. Panorama delle Sfide: Un'analisi strutturata delle sfide tecniche (definizioni, metriche, gruppi multipli) e organizzative (tempo, comunicazione) nell'implementazione dell'equità.
3. Raccomandazioni Azionabili: Suggerimenti pratici per la comunità dei RS (praticanti e ricercatori HCI) su come migliorare l'integrazione dell'equità, delineando responsabilità per le aziende e opportunità per la ricerca.

4. Risultati e Scoperte

A. Mappatura del Flusso di Lavoro (Workflow)

Il flusso di lavoro è diviso in fasi offline (sviluppo) e online (distribuzione), con un processo di equità parallelo che coinvolge diversi team:

• Fase di Prototipazione: Il team tecnico interagisce con il team legale (per l'approvazione dei dati) e il team dati. Qui nascono le prime ipotesi sui bias e si sviluppano metriche basate sull'intuizione o su metriche interne preesistenti, piuttosto che sulla letteratura accademica.
• Fase Interna (Validazione Offline): Il team tecnico valida le metriche e cerca manualmente bias inaspettati. Questa fase è considerata incerta e difficile a causa della necessità di modellare il comportamento degli utenti.
• Fase Collaborativa (Online/Post-Deploy): Dopo il rilascio, il team "Fairness" (o Responsible AI) fornisce feedback. Tuttavia, i praticanti tecnici hanno spesso discrezionalità su quanto integrare questi feedback, specialmente se richiedono molto lavoro o rischiano di degradare le prestazioni del modello.

B. Sfide Tecniche (All'interno dei Team RS)

1. Definire l'Equità: È difficile definire l'equità in contesti non regolamentati (es. raccomandazioni di dating vs. lavoro). I praticanti faticano ad adattare le metriche accademiche ai loro flussi di lavoro specifici e spesso mancano di strumenti standardizzati.
2. Gestione di Multi-Stakeholder: I praticanti devono bilanciare interessi conflittuali (es. equità per i creatori vs. rilevanza per gli utenti) e gestire un numero enorme di gruppi di utenti (migliaia), rendendo impossibile garantire uniformità su tutti.
3. Ambienti Dinamici e Loop di Feedback: Le valutazioni offline sono limitate perché non possono prevedere accuratamente le interazioni future degli utenti. I praticanti devono spesso creare metriche ad hoc e iterare basandosi sui dati reali post-deploy, un processo rischioso e manuale.

C. Sfide Organizzative (Cross-Team)

1. Mancanza di Tempo: I praticanti dedicano meno del 10% del loro tempo all'equità. L'equità non è vista come un'emergenza operativa (come un downtime del servizio) e viene spesso sacrificata per metriche di business primarie.
2. Mancanza di una "Lingua Franca" dell'Equità: Esiste un divario comunicativo tra i team tecnici e i team di equità (spesso composti da esperti di psicologia, comunicazione, ecc.). I termini tecnici non sono condivisi, e i feedback del team di equità sono spesso percepiti come poco azionabili o basati su design obsoleti.
   • Nota interessante: La comunicazione con i team legali è invece descritta come chiara, diretta e basata su linee guida rigide, a differenza della fluidità e ambiguità dei team di equità.

5. Significato e Raccomandazioni

Lo studio evidenzia che, nonostante lo stress e le difficoltà, i praticanti vedono il lavoro sull'equità come eticamente necessario e gratificante. Per colmare il divario tra teoria e pratica, gli autori propongono:

• Costruzione di Conoscenza Istituzionale: Migliorare la documentazione delle metriche e dei processi di equità per evitare di "reinventare la ruota" in ogni progetto. I ricercatori HCI dovrebbero progettare strumenti di documentazione flessibili e adattabili.
• Investimento nell'Equità Multi-Stakeholder: Le aziende devono investire in ricerca per ottimizzare obiettivi multipli e gestire la complessità dei gruppi di utenti (inclusa l'equità intra-gruppo).
• Integrazione Precoce: Coinvolgere i team di equità già nelle fasi di prototipazione (offline) e non solo dopo il deploy, per prevenire problemi prima che diventino critici.
• Sviluppo di una "Lingua Franca": Creare ponti comunicativi tra team tecnici e di equità, possibilmente attraverso ruoli di "ponte" (bridging roles) e formazione incrociata, per rendere i feedback più comprensibili e azionabili.

In conclusione, il paper dimostra che l'implementazione dell'equità nei RS non è solo un problema algoritmico, ma un processo socio-tecnico complesso che richiede cambiamenti strutturali nei flussi di lavoro aziendali, nella comunicazione inter-dipartimentale e negli strumenti di supporto decisionale.