Il dato più interessante dello studio non è il 64,9% di accuratezza ottenuto dalla Rationale Labeling contro il 57,8% del codebook rivisto dagli esperti. È che il risultato arriva senza chiedere più potenza di calcolo o modelli più grandi: arriva chiedendo agli esperti di lavorare solo sui punti in cui più LLM non sono d'accordo. Su migliaia di trascrizioni di sessioni di tutoraggio, i ricercatori hanno confrontato tre modi per integrare il feedback umano nella revisione di un codebook: modificare le revisioni generate dai modelli a partire dai disaccordi, rispondere a domande sui disaccordi stessi e annotare i casi di disaccordo con spiegazioni. L'ultimo metodo ha prodotto l'accuratezza più alta e ha superato anche il codebook rivisto manualmente dagli esperti. La variante migliore del Question Answering si è fermata al 60,5%, comunque sopra la baseline esperta.

La posta in gioco qui non è soltanto l'annotazione. Un codebook robusto richiede mesi perché ogni regola va verificata su casi reali, e i casi ambigui emergono lentamente. Se il disaccordo tra modelli può segnalarli in anticipo, il tempo degli esperti diventa una risorsa da allocare con un criterio, non da distribuire a pioggia. Per chi gestisce pipeline di annotazione su larga scala, questo ribalta il collo di bottiglia: non è più il modello a essere il limite, ma la capacità di selezionare gli esempi giusti da far verificare a un umano.

Cosa cambia per i deployment locali

Per chi valuta stack self-hosted, il meccanismo ha una conseguenza strutturale. Il disaccordo tra più LLM è un segnale economico che non richiede API esterne né etichette preesistenti: bastano due o più modelli locali, anche non di ultima generazione, applicati agli stessi documenti. In uno scenario on-premise, questo significa poter costruire codebook di dominio senza spostare i dati fuori dal perimetro aziendale, e senza aspettare che un fornitore cloud aggiorni il proprio servizio di annotazione. Il costo, però, si sposta altrove: servono VRAM per eseguire più modelli in parallelo, oppure una pipeline che li esegua in sequenza con tempi di inference più lunghi. La quantization può ridurre l'occupazione di memoria, ma introduce un'altra variabile nel comportamento dei modelli e quindi nella qualità del segnale di disaccordo.

Il guadagno non è uniforme. Chi lavora con domini ad alta specificità — documentazione legale, referti, supporto tecnico, contenuti formativi — ottiene più valore perché il codebook generico fornito con i modelli aperti è spesso lontano dal vocabolario reale. Chi invece gestisce annotazioni generaliste con un solo modello proprietario può trovare il metodo meno utile, perché il disaccordo tra modelli diversi non è disponibile o è considerato rumore da eliminare. È qui che lo studio segnala un cambiamento di incentivi: la qualità delle etichette non dipende più solo dalla scala del modello, ma dall'architettura del flusso di revisione umana. E questo favorisce chi controlla i modelli e i dati, non chi vende soluzioni chiuse.

Resta un punto aperto: il 64,9% è un risultato su un dominio specifico, con una metrica di accuratezza contro etichette esperte. Prima di generalizzare serviranno test su altri tipi di testo e su codebook più grandi. Ma il principio è chiaro: il disaccordo non è un errore da sopprimere, è una risorsa per decidere dove investire l'attenzione umana. In un settore ossessionato dalla potenza delle GPU, è un promemoria che il bottleneck può essere organizzativo, non computazionale.