Human-in-the-loop (HITL): cosa decide una persona e cosa non garantisce

Definizione: un intervento umano in un punto definito

Human-in-the-loop, o HITL, è un modello di progettazione in cui una persona partecipa a una fase definita del funzionamento di un sistema automatizzato. Può esaminare informazioni, classificare un caso, correggere un risultato, autorizzare un’azione o fornire feedback. Il termine descrive la partecipazione umana al processo, ma non stabilisce di per sé quale compito svolga la persona né quanta autorità conservi.

Dire che un sistema è HITL, quindi, non significa necessariamente che una persona esamini ogni input e ogni risultato. L’intervento può essere limitato ai casi dubbi, avvenire prima di una specifica azione oppure fornire informazioni utili in una fase successiva. Per comprendere la progettazione occorre precisare il punto d’intervento, le opzioni a disposizione della persona e che cosa accade in seguito alla sua decisione.

Le definizioni introduttive consultate descrivono HITL come partecipazione umana al ciclo di vita del machine learning oppure al funzionamento, alla supervisione e al processo decisionale. Si tratta di formulazioni generali, non di un’unica specifica tecnica né di una garanzia di qualità.

Dove può intervenire una persona

L’intervento può collocarsi in fasi diverse. Durante la verifica degli input, la persona controlla o completa i dati prima che il sistema li elabori. Nella verifica degli output, valuta una raccomandazione o una classificazione prima che venga utilizzata. Con un’autorizzazione preventiva, decide se un’azione può essere eseguita. Durante l’operatività può monitorare il processo e intervenire quando si presenta un’eccezione. In seguito, il suo feedback può contribuire a rivedere le regole o a preparare miglioramenti futuri.

Queste funzioni non sono intercambiabili. Esaminare una risposta non equivale ad avere l’autorità di bloccarla; approvare un pagamento non equivale a verificare come siano stati estratti i dati; ricevere una notifica non equivale ad avere il tempo e la capacità di intervenire. Una progettazione chiara distingue il compito della persona da quello automatizzato e specifica quale risultato produce ciascuno.

Occorre anche definire che cosa succede se la persona non è disponibile, non risponde o non è d’accordo con il sistema. Se, dopo un certo intervallo, il processo prosegue automaticamente, anche questa regola fa parte della progettazione. Se invece si interrompe, bisogna chiarire chi è responsabile di risolvere il blocco. Senza queste condizioni, l’espressione HITL lascia senza risposta una questione pratica importante.

Come funziona il ciclo d’intervento

Un ciclo HITL dovrebbe poter essere descritto dall’inizio alla fine. Per prima cosa, il sistema individua il caso che richiede un intervento umano oppure, se questa è la politica scelta, presenta tutti i casi. Poi mostra alla persona le informazioni necessarie per valutare la situazione. La persona dispone di una o più azioni concrete. Infine, il sistema applica, registra o inoltra la decisione secondo regole definite in anticipo.

L’interfaccia e il contesto sono importanti quanto la presenza di una fase di verifica. Se viene mostrato soltanto un punteggio senza i suoi limiti, se mancano dati rilevanti o se non è chiaro se si tratti di una raccomandazione o di una decisione già presa, la persona potrebbe non essere in condizione di valutare il caso. La progettazione dovrebbe rendere comprensibile che cosa viene proposto, che cosa è ancora in sospeso e quali conseguenze derivano dall’accettazione o dal rifiuto.

Un’implementazione tecnica può sospendere l’esecuzione fino a quando non arriva una decisione umana. Per esempio, la documentazione di LangChain descrive un meccanismo che può interrompere le chiamate agli strumenti e attendere una decisione. È un esempio concreto di come introdurre una pausa; non definisce universalmente HITL né dimostra, da solo, che la verifica sia adeguata a ogni processo.

Tre esempi pratici

Gli scenari seguenti sono esempi di progettazione, non affermazioni sul funzionamento di uno specifico servizio. In ciascun caso si distingue il compito automatizzato dalla decisione che resta in capo a una persona. Questa distinzione permette di verificare se l’intervento sia sostanziale o se esista soltanto la possibilità formale di inoltrare un caso per un’escalation.

blocks

Concetti vicini da distinguere

HITL è un’etichetta ampia per indicare la partecipazione umana a un processo. Non va considerata automaticamente sinonimo di supervisione umana in senso normativo. La supervisione può comportare requisiti specifici a seconda del contesto e del quadro applicabile; le fonti considerate qui non bastano a descrivere obblighi giuridici concreti. Questa scheda illustra quindi un modello di progettazione, non determina la conformità normativa.

Si usano anche espressioni come *human-on-the-loop* per descrivere una persona che osserva il funzionamento e può intervenire, e *human-out-of-the-loop* per un processo che, in quella fase, procede senza un intervento umano individuale. Queste etichette sono utili come distinzione generale, ma il loro uso non è uniforme. In un’implementazione reale è più preciso descrivere le azioni, l’autorità e il momento dell’intervento che affidarsi soltanto al nome del modello.

L’intervento in produzione va distinto dal feedback utilizzato per sviluppare o adattare un modello. Nell’RLHF — apprendimento per rinforzo a partire dal feedback umano — la partecipazione umana viene utilizzata durante una fase di addestramento o adattamento. Il fatto che delle persone abbiano fornito feedback in quella fase non implica che una persona esamini ogni decisione del sistema quando è in uso. Al contrario, una persona può intervenire in produzione senza che la sua decisione venga utilizzata per addestrare un modello.

Anche l’apprendimento attivo è un concetto distinto: in termini generali, indica una strategia per selezionare esempi che potrebbero trarre beneficio da un’etichettatura o da una verifica. La selezione può coinvolgere persone, ma non stabilisce di per sé chi abbia l’autorità su un’azione operativa. Le fonti verificate per questa scheda non forniscono un confronto tecnico dettagliato tra apprendimento attivo e RLHF; queste distinzioni sono quindi un orientamento concettuale, non una tassonomia completa.

Limiti ed errori frequenti

La presenza di una fase umana non garantisce, da sola, che il sistema sia sicuro, preciso, efficace o conforme a una norma. Per individuare un problema, una persona ha bisogno di informazioni pertinenti, tempo, competenze adeguate e autorità per agire. Se manca uno di questi elementi, l’intervento può comparire nel diagramma del processo senza tradursi in un controllo effettivo.

Un rischio di progettazione consiste nel presumere che una persona individui qualsiasi errore solo perché può esaminare una raccomandazione. Potrebbe non avere il contesto necessario, essere incaricata di troppi casi o non disporre di un’opzione chiara per respingerla. Potrebbe anche subire pressioni ad accettare il risultato automatizzato, oppure trovarsi davanti a una procedura di escalation che non porta a una soluzione. Sono limiti possibili da valutare in ogni contesto; le fonti consultate non ne misurano la frequenza né consentono di quantificarne gli effetti.

Un altro errore è usare la verifica come etichetta generica senza precisarne la portata. «C’è una persona nel circuito» non chiarisce se questa veda tutti i casi, soltanto le eccezioni o un campione; se intervenga prima o dopo l’azione; né chi risponda della decisione. Non chiarisce neppure come correggere un risultato errato o se sia possibile annullare un’azione.

Infine, bisogna evitare di confondere la supervisione con l’approvazione. Una persona che può guardare una schermata ma non fermare un’azione svolge un ruolo diverso da chi deve autorizzarla. Allo stesso modo, avere qualcuno disponibile a ricevere un’escalation non equivale ad assegnare una persona informata, responsabile e in grado di risolvere il caso.

Criteri pratici per descrivere una progettazione HITL

Per valutare o documentare un sistema, occorre descrivere il punto preciso in cui interviene la persona e quale evento attiva l’intervento. Indicare se la partecipazione sia obbligatoria, selettiva o successiva all’azione. Se vengono verificate soltanto le eccezioni, spiegare come sono individuate e quali casi potrebbero restare fuori dal controllo.

Specificare quali informazioni vede la persona, quali opzioni può esercitare e quale autorità sostenga tali opzioni. Una raccomandazione che può essere accettata, corretta o rifiutata richiede controlli diversi da un avviso che si può soltanto confermare di aver ricevuto. È inoltre opportuno indicare chi può fermare il processo, chiedere una seconda verifica o annullare un’azione.

Descrivere che cosa succede se la persona non risponde, non è disponibile o non è d’accordo con il sistema. Definire tempi di risposta adeguati al processo, senza presumere che un’unica scadenza sia adatta a ogni contesto. Registrare decisioni e modifiche in modo che sia possibile ricostruire chi è intervenuto, su quali informazioni e con quale esito.

Nel complesso, una descrizione utile risponde a sei domande: dove interviene la persona; che cosa vede; che cosa decide; che cosa può modificare; che cosa succede in caso di eccezione o mancata risposta; e come si verifica che il meccanismo funzioni come previsto. Queste domande rendono esplicite le responsabilità che l’etichetta, da sola, lascia indeterminate.

Portata delle fonti

Le fonti verificate per questa scheda comprendono spiegazioni generali di HITL, una pubblicazione istituzionale sui meccanismi d’intervento e la documentazione tecnica di un meccanismo specifico che sospende le chiamate agli strumenti in attesa di una decisione umana. La loro portata è diversa: una definizione introduttiva non equivale a una norma e la documentazione di un prodotto non stabilisce come debbano essere progettati tutti i sistemi.

Non è stata fornita una fonte normativa che consenta di riassumere obblighi giuridici specifici, né evidenza che misuri l’efficacia degli esempi ipotetici o la frequenza dei rischi descritti. Per questo la scheda non afferma che una progettazione HITL soddisfi requisiti normativi, né che la partecipazione umana produca automaticamente risultati migliori. Le categorie e gli esempi servono a formulare domande di progettazione, a cui occorre rispondere con evidenze adeguate al contesto.

Concetti correlati