Skip to content
Guides9 min read

Certificare le etichette di un LLM con un campione umano in cieco

Tieni le etichette di un LLM solo dove un campione umano casuale e in cieco mostra un errore sotto l'obiettivo, e riporta la prevalenza con intervalli corretti.

Potato Team

Per decidere quali etichette di un LLM tenere senza controllarle una per una, fai etichettare alle persone un campione casuale e in cieco, scegli una soglia di confidenza su metà di quel campione e verifica sull'altra metà che il tasso di errore tra le etichette sopra la soglia sia sotto il tuo obiettivo. Per le cifre di prevalenza, correggi la stima del modello con i suoi errori sullo stesso campione: ottieni un intervallo che resta valido per quanto buono sia il modello.

Un modo comune di controllare le etichette di un LLM è leggere qualche decina di output e, se sembrano giusti, distribuire il dataset con una frase come "un LLM ha etichettato i dati e li abbiamo controllati a campione". Quella frase non dice quanto spesso le etichette sono sbagliate, e un revisore non può sapere se il controllo avrebbe scoperto un tasso di errore del 15%. Un controllo che sostiene un numero risponde a tre domande: quali etichette automatiche tenere, quanto si discosta un tasso calcolato dalle etichette automatiche e se un modello può prendere il posto di una persona.

Il bias dei controlli a campione e delle pre-etichette revisionate

Due abitudini fanno sembrare un'etichetta automatica migliore di quanto sia. La prima è controllare gli item su cui il modello era meno sicuro. Controllare quegli item trova gli errori in fretta, ma gli item controllati non sono un campione del dataset, quindi il tasso di errore su di essi non stima nulla sul resto. La seconda è misurare l'accordo su etichette che le persone hanno dato mentre la risposta del modello era sullo schermo. Un suggerimento attira la risposta verso di sé, quindi l'accordo misurato su pre-etichette revisionate risulta più alto dell'accordo misurato in cieco. Pre-annotazione con LLM tratta più in dettaglio questo bias da automazione.

Un controllo che sostiene un numero ha quindi bisogno di tre proprietà. Gli item controllati vengono estratti a caso con probabilità di inclusione note. Le persone che li etichettano non possono vedere la risposta del modello. Le etichette che scelgono una regola sono diverse da quelle che la testano.

Predizione selettiva e rischio selettivo

Predizione selettiva significa che un modello etichetta solo gli item su cui la sua confidenza supera una soglia e si astiene sugli altri, che vanno alle persone. La quantità da controllare è il rischio selettivo, il tasso di errore tra le etichette che il modello tiene. Per esempio, una soglia che tiene il 70% degli item con un tasso di errore del 4% può essere più utile di un modello che etichetta tutto con il 12%.

Scegliere la soglia e testarla sulle stesse etichette sopravvaluta quanto funziona, quindi il campione umano viene diviso. Una metà, la partizione dev, sceglie la soglia. L'altra metà, la partizione cert, la testa con un test binomiale unilaterale dell'ipotesi che l'errore tra le etichette accettate sia sopra l'obiettivo. Se quell'ipotesi viene rifiutata, la soglia è certificata alla confidenza dichiarata. Learn-then-Test (Angelopoulos et al., 2025) tratta la scelta di una soglia come un problema di test multipli. Una delle sue procedure testa le soglie candidate in un ordine fisso e si ferma alla prima che fallisce, il che le permette di provare diverse soglie senza perdere la garanzia.

Questi test richiedono campioni più grandi della maggior parte dei controlli a campione. Supponiamo che l'obiettivo sia al massimo il 10% di errori con una confidenza del 90%, e che questo sia il primo test di un singolo modello senza suddivisione per classe, che Potato esegue a un livello di circa 0,06 (la sezione successiva spiega perché). Con 100 etichette accettate nella partizione cert, il test passa solo se al massimo 5 sono sbagliate. Un obiettivo del 5% richiede al massimo 1 etichetta sbagliata su 100, oppure al massimo 4 su 200. Un modello il cui vero tasso di errore è del 7% supera quel primo test circa il 29% delle volte con 100 etichette cert accettate, e circa il 56% delle volte con 300.

Test ripetuti e budget di errore

Le persone continuano a etichettare dopo il primo test, e ripetere il test finché non passa trasformerebbe una probabilità del 10% di un certificato sbagliato in qualcosa di molto più grande. Una soluzione è dare a ogni test una quota decrescente del budget di errore. Potato dà al test numero k la quota 6 / (pi^2 k^2) dell'errore ammesso, quindi il primo test riceve il 61%, il secondo il 15%, e le quote sommate su tutti i test possibili danno l'intero budget. Provare un nuovo prompt o un nuovo modello conta come un nuovo test, perché è una possibilità in più di passare per fortuna.

La prevalenza con la prediction-powered inference

Molti studi hanno bisogno di un tasso più che di un dataset, come la quota di post tossici o la quota di esecuzioni di un agente che vanno a buon fine. Contare le etichette automatiche dà un tasso distorto ogni volta che gli errori del modello pendono da una parte. Contare solo il campione umano dà un tasso non distorto con un intervallo ampio.

La prediction-powered inference (Angelopoulos et al., 2023) combina le due cose. Calcola il tasso dalle etichette automatiche su ogni item, poi lo corregge con l'errore medio del modello sul campione etichettato dalle persone. L'intervallo è valido qualunque sia la qualità del modello. PPI++ regola quanto peso ricevono le etichette automatiche, così un buon modello rende l'intervallo più stretto di quanto potrebbero le sole persone e uno scarso non lo rende più ampio. Quando il campione umano è stato estratto con probabilità diverse, uno stimatore per differenza di Horvitz-Thompson svolge lo stesso ruolo.

Nell'esempio con le tracce degli agenti distribuito con Potato, un giudice LLM ha valutato 288 tracce sintetiche di agenti scritte per l'esempio, ciascuna con un esito di riferimento, e ha detto che il 76% era andato a buon fine. L'intervallo prediction-powered ottenuto dallo stesso giudice e da un campione umano era 0,66 [0,57; 0,76], e il tasso di riferimento nei dati era 0,60. Il giudice aveva ragione sull'80% delle singole tracce eppure ha sovrastimato il tasso di 16 punti, perché i suoi errori pendevano verso "successo".

L'alternative annotator test

Un obiettivo fisso di accuratezza può essere la domanda sbagliata quando le persone sono in disaccordo. Se due annotatori attenti concordano sull'85% degli item, non si può dimostrare che un etichettatore abbia "ragione" al 95%, perché anche il riferimento è rumoroso. L'alternative annotator test (Calderon et al., 2025) pone invece una domanda relativa. Escludendo a turno ogni persona, verifica se il modello concorda con le persone rimanenti almeno tanto spesso quanto la persona esclusa, entro un margine. Richiede item etichettati da più persone, e l'implementazione di Potato aspetta almeno tre annotatori con 30 item ciascuno. Accordo dei giudici LLM tratta la versione di questo confronto basata sul kappa e come verificare la calibrazione di un giudice.

I contratti nel motore di etichettatura di Potato

Dalla versione 2.11, il motore di etichettatura di Potato esegue questi test come contratti. Estrae il campione casuale in cieco, lo serve agli annotatori con ogni risposta della macchina nascosta, lo divide in dev e cert e certifica man mano che arrivano le etichette. Questa configurazione tiene le etichette di sentiment di un LLM dove al massimo il 10% è sbagliato con una confidenza del 90%, e riporta la prevalenza di ogni etichetta con un intervallo al 90%:

yaml
assignment_strategy: engine
 
labeling_engine:
  enabled: true
  sources:
    - id: llm
      kind: llm
      endpoint_type: vllm
      model: google/gemma-4-12B-it-qat-w4a16-ct
      base_url: http://localhost:8001/v1
      confidence: {method: logprob}
  contracts:
    - id: accuracy
      kind: selective_risk
      schema: sentiment
      error: 0.1
      confidence: 0.9
    - id: prevalence
      kind: ppi
      schema: sentiment
      confidence: 0.9
  budgets:
    human_labels: 400

Una confidence di 0.9 è il default di Potato per ogni contratto. La fonte legge la confidenza dalle log-probabilità dei token perché una soglia ha bisogno di una confidenza che separi le risposte giuste da quelle sbagliate, e una confidenza che il modello dichiara a parole è il meno affidabile dei metodi che Potato offre. L'esempio testuale di Potato elabora 481 recensioni con Laya per primo e questo LLM come ultimo livello. In quell'esecuzione il contratto al 10% è stato soddisfatto con 165 etichette umane, e il motore ha accettato 316 etichette automatiche, tutte dell'LLM perché la soglia di Laya non è mai stata fissata. Il loro errore misurato rispetto alle etichette di riferimento era del 7,6%. potato label certificate config.yaml stampa che cosa è stato testato, su quante etichette e con quali versioni di modello e di prompt.

I limiti della certificazione su un campione in cieco

Ognuna di queste garanzie riguarda l'accordo con le persone che hanno etichettato il campione. Se sono distratte o formate male, un contratto soddisfatto certifica l'accordo con persone distratte, quindi verifica gli annotatori con la sovrapposizione e il controllo della qualità prima di fidarti di un certificato.

Una confidenza che non varia mai non dà a una soglia nulla da separare. Il giudice nell'esempio con le tracce degli agenti ha dato una confidenza di 1,0 a ogni traccia, quindi nessuna soglia poteva passare, e Potato segna un contratto del genere come infeasible invece di accettare tutto. L'intervallo di prevalenza funzionava comunque sugli stessi dati, perché non dipende dalla confidenza.

Nei task soggettivi, dove le persone sono in disaccordo per ragioni che fanno parte dei dati, potrebbe non esistere un'unica risposta giusta per item. Confronta invece la distribuzione delle etichette del modello con il modo in cui le persone si dividono, che il contratto distributional di Potato riporta rispetto a un tetto di rumore split-half. Esegui potato label status config.yaml dopo il primo passaggio per vedere quante altre etichette umane servono a ogni contratto prima che possa passare.

Approfondimenti

Riferimenti

  1. Angelopoulos, A. N., Bates, S., Candès, E. J., et al. (2025). Learn then test: Calibrating predictive algorithms to achieve risk control. The Annals of Applied Statistics. https://doi.org/10.1214/24-AOAS1998
  2. Angelopoulos, A. N., Bates, S., Fannjiang, C., et al. (2023). Prediction-powered inference. Science, 382(6671). https://doi.org/10.1126/science.adi6000
  3. Angelopoulos, A. N., Duchi, J. C., and Zrnic, T. (2023). PPI++: Efficient prediction-powered inference. arXiv. https://arxiv.org/abs/2311.01453
  4. Calderon, N., Reichart, R., and Dror, R. (2025). The alternative annotator test for LLM-as-a-judge: How to statistically justify replacing human annotators with LLMs. Proceedings of ACL 2025. https://aclanthology.org/2025.acl-long.782/