Come calcoliamo

Guadagno informativo

Il lettore arriva a un testo con delle domande: cosa deve succedere esattamente, dove, quando, quanto, a quali condizioni e perché. Il guadagno informativo è la quota di queste domande a cui il testo risponde. Al 100% il lettore non ha più nulla da chiedere; un modulo con i campi vuoti è vicino allo 0%. Il modello nel tuo browser stima questa quota come un voto da 0 a 10 e la mostra con incrementi del 5%.

L’idea risale a Claude Shannon, che misurava l’informazione in bit: un bit è la risposta a una domanda sì o no (Shannon, 1948). Un bug report che dice «le esportazioni grandi falliscono» lascia lo sviluppatore a chiedersi se si tratti di 12.300 righe o di 11.000, una domanda sì o no dopo l’altra; «le esportazioni oltre 10.000 righe falliscono» risponde a tutte in una volta. Warren Weaver ha descritto tre livelli della comunicazione: se i simboli arrivano, se portano il significato voluto e se cambiano ciò che fa chi li riceve (Weaver, 1949). Slopcheck lavora sul secondo e sul terzo livello.

Il guadagno informativo nella SEO

Nella SEO il termine «information gain» (guadagno informativo) indica ciò che una pagina aggiunge rispetto alle pagine che il lettore ha già visto. Google detiene un brevetto su un punteggio di questo tipo, «Contextual estimation of link information gain» (US 11,354,342 B2, concesso il 7 giugno 2022). Un brevetto non dimostra che un punteggio venga usato nel ranking; le linee guida pubbliche di Google chiedono se i contenuti offrono «informazioni, reportage, ricerche o analisi originali» (in inglese “original information, reporting, research, or analysis”, Google Search Central). Slopcheck misura la parte che 1 testo mostra da solo, senza confrontarlo con altre pagine: la quota delle domande del lettore a cui risponde, da 0 a 100%.

Cosa esclude un’affermazione

Rudolf Carnap e Yehoshua Bar-Hillel hanno descritto il lato semantico dell’informazione: un’affermazione porta tanta più informazione quanti più stati possibili del mondo esclude (Carnap e Bar-Hillel, 1952). «L’esportazione fallisce per gli ordini con più di 500 righe in Chrome 128» esclude molto più di «l’esportazione a volte fallisce». Una soglia esplicita è la forma più forte: «3.1.4 funziona, 3.2.0 fallisce» dice allo sviluppatore quale release aprire.

Se un’affermazione sia vera è un’altra questione (Stanford Encyclopedia of Philosophy). Slopcheck non verifica i fatti: «ordini con più di 500 righe» ottiene lo stesso punteggio che la soglia reale sia 500 o 5.000.

Cosa conta per il lettore

Ronald Howard ha mostrato nel 1966 che un’informazione vale quanto cambia una decisione (Howard, 1966). Per uno sviluppatore, «Chrome 128» decide quale dei 3 browser testare; «l’esportazione è importante» non decide nulla. In una pagina prodotto, «4 € per utente al mese, primi 30 giorni gratis» cambia la decisione d’acquisto; «un’esperienza senza interruzioni» no. In un bug report sono la versione, i passi e la soglia a cambiare la mossa successiva dello sviluppatore.

Slop

Lo slop è la quota del testo, contata in parole, che non risponde a nessuna domanda del lettore. Ne distinguiamo 4 tipi: frasi vuote adatte a qualsiasi testo, frasi ovvie che non escludono nulla di quanto il lettore considerava, frasi irrilevanti che non cambiano alcuna decisione e frasi irrisolvibili come «come da accordi» o «come nell’altro». Contano anche le ripetizioni, cioè quando il testo dice di nuovo ciò che ha già detto. Nel risultato del controllo ogni frase di slop viene evidenziata.

In termini di conversazione, lo slop viola 2 delle massime descritte da Paul Grice: dare tutta l’informazione richiesta e non di più, e dire ciò che è pertinente (Grice, 1975). Le ripetizioni sono ciò che Shannon chiamava ridondanza: la parte di un messaggio che il lettore può prevedere dal resto.

Lo stile non è slop: «abbiamo sistemato l’export CSV» e «il problema dell’export CSV è stato risolto» contano allo stesso modo.

Come si legano i due numeri

Lo slop non porta informazione, quindi più slop c’è in un testo, più basso è il tetto del suo guadagno: un testo con il 60% di slop arriva al massimo a circa il 50%, e uno con il 95% di slop o più arriva al massimo al 10%. Il 100% pieno compare solo quando nessuna frase è slop; altrimenti il guadagno si ferma al 95%. La lunghezza non è l’obiettivo: un bug report di 50 parole può arrivare al 90%.

Bug report, task e pagine prodotto

Abbiamo scritto 27 domande che il lettore porta a un testo: 7 per qualsiasi testo, 8 per i bug report, 7 per i task e 5 per le pagine prodotto. Un bug report risponde a: quale versione, quali passi, cosa ci si aspettava e cosa è successo, sempre o a volte, e da quale release. Un task o una user story risponde a: cosa, dove, perché, come verificare che sia fatto e cosa non toccare; un esempio di buoni criteri di accettazione è «34 impostazioni, 4 schede, nessuna modifica ai testi». Una pagina o una descrizione prodotto risponde a: per chi, cosa fa, cosa lo dimostra, il prezzo e il passo successivo. Il modello ha imparato queste differenze da 2.424 esempi valutati da un modello linguistico: non serve scegliere un genere prima di incollare un testo.

5 versioni in 4 giorni

La versione 1, il 19 ottobre 2026, contava parole funzionali, riempitivi e dettagli concreti ogni 100 parole. La versione 2 ha aggiunto la rarità delle parole, misurata su liste di frequenza che abbiamo ricavato da circa 600.000 parole di testi di Wikipedia per lingua; su 55 pagine web valutate da due modelli linguistici era rumore (AUROC da 0,45 a 0,49), quindi l’abbiamo scartata. La versione 3 giudicava in base alla concretezza ogni 100 parole; su 37 nuove pagine tenute da parte per i test, il suo verdetto «troppo poca sostanza» era giusto in 1 caso su 9, quindi è diventato un suggerimento.

La versione 4 usava un catalogo di circa 1.000 pattern in 5 lingue e separava le pagine gonfiate da quelle dense sulle stesse 37 pagine (AUROC 0,75; avevamo visto quei risultati durante lo sviluppo, quindi il dato è ottimistico). Sui bug report reali non andava oltre il caso (da 0,47 a 0,52). Quel fallimento ci ha portati dal contare le parole al contare le domande aperte del lettore, e alla versione 5 (s2) il 22 ottobre; il 24 ottobre l’abbiamo riaddestrata per 12 lingue (s3).

Cosa ci hanno insegnato i bug tracker

Abbiamo preso 1.355 bug report di Mozilla Bugzilla dal 2023 al 2025. I report chiusi come incompleti o «works for me», o il cui autore era stato invitato a fornire più informazioni, erano più lunghi di quelli risolti senza una richiesta simile (mediana di 165 parole contro 124) e più concreti: chi è esterno al progetto compila il template completo, che compare nel 38% dei report «works for me» e nel 14% di quelli risolti, mentre gli ingegneri scrivono note brevi che si basano su un contesto condiviso. L’esito misurava chi aveva scritto il report, quindi da allora abbiamo confrontato report dello stesso autore.

Su Apache Jira abbiamo raccolto 11.129 bug report di 165 progetti, aperti dal 2022, e abbiamo confrontato quelli risolti con quelli chiusi come «Cannot Reproduce» o «Incomplete». Un risultato ha dato forma al metodo: un modello linguistico ha letto 240 di questi report, 120 coppie dello stesso autore, senza conoscere l’esito né l’autore. Alla domanda se fosse indicata una versione o un ambiente, ha risposto sì più spesso per i report accolti male (63% contro 50%). Alla domanda su cosa servisse ancora a uno sviluppatore, ha indicato la versione o l’ambiente più spesso per gli stessi report (48% contro 33%). Menzionare un dettaglio non equivale a rispondere alla domanda.

Regole da una revisione manuale

Abbiamo valutato a mano 35 testi, la maggior parte su una scala da 0 a 10: 0 è un modulo vuoto, da 5 a 6 si può fare dopo un paio di domande, 9 lascia una domanda aperta, 10 non lascia nulla da aggiungere. Su 28 di questi testi il nostro primo catalogo di domande ha sollevato 86 domande; ne abbiamo segnate 35, 26 come giuste e 9 come eccessive. Il risultato è una guida scritta di 37 regole e 33 casi di test.

Esempi di regole: un’affermazione senza limiti vale sempre e ovunque, quindi una versione mancante non costa nulla a meno che il testo non dica «a volte» o «dopo l’aggiornamento»; un divieto conta solo se chiude una strada che il task lascia intendere; i requisiti in contraddizione tra loro costano più di tutto. In un test gli stessi fatti, riscritti con un collegamento esplicito e un oggetto nominato, sono passati da 1 a 9–10 su 10. In un altro, un report valutato 10 a mano era stato chiuso come «Cannot Reproduce»: l’esito nel tracker è un segnale, non un verdetto.

Modelli linguistici come valutatori e come insegnante

Abbiamo trasformato le 37 regole in una guida di valutazione per i grandi modelli linguistici e confrontato 5 modelli sui 27 testi con voti numerici dati a mano. Le regole venivano da questi testi, quindi il confronto mostra quanto ogni modello segue le regole, non come se la cava su testi nuovi: i due migliori sono rimasti entro 1 punto dal voto manuale in 22 testi su 27 (correlazione di rango fino a 0,94); il più debole, in 12 su 27.

Uno dei due ha poi valutato 2.424 testi frase per frase: 600 task e bug report pubblici di Apache Jira, 384 testi con gli stessi fatti scritti da modelli linguistici in 4 stili, 600 testi che lo stesso modello ha scritto per l’addestramento in tedesco, polacco, ceco, croato e russo, e 840 testi, 120 per ciascuna lingua tra slovacco, sloveno, bulgaro, francese, italiano, spagnolo e olandese, scritti da modelli linguistici senza vedere le regole. In tutto sono 18.420 frasi etichettate, il 21,4% delle quali è slop. Il piccolo modello nel tuo browser ha imparato da queste etichette. Nella validazione incrociata concorda con l’insegnante con una correlazione di rango di 0,85, e sui testi da cui non ha imparato trova le frasi di slop dell’insegnante con un AUROC di 0,92. Su 25 testi valutati a mano concorda con i voti manuali con una correlazione di rango di 0,81, ma le regole applicate sopra di esso vengono dagli stessi testi, quindi i test su dati esclusi descritti più sotto sono la misura più equa.

Nessun modello linguistico legge il tuo testo quando lo controlli. Una chiamata a un modello invia il testo a terzi, può dare una risposta diversa allo stesso testo e costa denaro a ogni controllo; il piccolo modello gira con circa 350 KB di pesi fissi.

Previsioni scritte prima

Per 5 esperimenti abbiamo scritto le nostre previsioni in un file prima di eseguire il test; per il test dei pattern del 20 ottobre 2026 il checksum MD5 del file inizia con ff01ce1a. Avevamo previsto che la versione semplice di un testo avrebbe battuto quella in stile assistente tra l’85% e il 95% delle coppie; è successo nel 79%. Avevamo previsto che i report di Bugzilla respinti sarebbero stati più brevi; erano più lunghi, con una mediana di 165 parole contro 124. Sulle coppie Jira dello stesso autore 3 previsioni su 4 sono fallite. Dopo l’errore su Bugzilla, ogni confronto successivo ha usato report dello stesso autore.

Cosa non ha funzionato

La rarità delle parole (AUROC da 0,45 a 0,49). La quota di parole funzionali e riempitivi, che sulle pagine tenute da parte ha raggiunto un AUROC di appena 0,31, peggio del caso. Un verdetto «troppo poca sostanza» giusto 1 volta su 9. Contare le unità di significato o spuntare una checklist di completezza a 5 punti, che concordava con una lettura dell’intero testo con una correlazione di rango di appena 0,18–0,26. 8 indicatori modellati sui segnali dei motori di ricerca, scartati in fase di progettazione. Confrontare una pagina con i primi 3–10 risultati di ricerca, che richiede un’API di ricerca a pagamento. Versioni ampie delle regole esplicite, che sono scattate su 33 report Jira; ogni caso che abbiamo verificato era un falso allarme. Un modello linguistico al momento del controllo: era il più vicino ai voti manuali, ma invierebbe il tuo testo a terzi.

Come testiamo il metodo

Teniamo da parte 24 brief in inglese e tedesco, ciascuno scritto in 4 versioni da modelli linguistici. La versione semplice ottiene un punteggio più alto di quella gonfiata in tutte le 24 coppie e più alto di quella in stile assistente nell’83%. Per ognuna delle 7 lingue aggiunte il 24 ottobre teniamo da parte altri 6 brief in 4 versioni: la versione semplice batte quella gonfiata in ogni coppia, e quella in stile assistente nel 100% delle coppie in slovacco e sloveno, nel 92% in italiano e olandese, nell’83% in bulgaro e francese e nel 58% in spagnolo.

Su 120 coppie escluse di report Jira dello stesso autore, il report risolto ottiene un punteggio più alto in circa il 60% delle coppie. Un modello linguistico che legge alla cieca gli stessi 240 report, senza l’esito né l’autore, arriva al 64%. I brief in inglese e tedesco e le coppie Jira sono stati esclusi dall’addestramento, ma li abbiamo usati per scegliere tra varianti delle regole esplicite, quindi su testi nuovi i risultati possono essere leggermente più bassi. Se un report finisce risolto o chiuso come «Cannot Reproduce» dipende anche dal bug stesso: può essere già corretto in una versione più recente, presentarsi in un solo ambiente o derivare da un errore di configurazione, quindi su questo test il 100% non è possibile.

Come si calcola la stima

Per l’intero testo il modello legge 182 segnali, come numeri, versioni, condizioni, soglie, nomi, messaggi citati, parole vaghe, affermazioni non supportate, ripetizioni e intestazioni vuote di un template, più parole e coppie di parole mappate con hashing in 16.384 celle; un secondo modello con 68 segnali e le stesse parole decide per ogni frase se è slop. Il modello del testo è una regressione lineare su questi segnali e quello delle frasi una regressione logistica, entrambi stimati sui 2.424 testi valutati. Sopra il modello si applicano 3 regole della revisione manuale. Un orario di inizio successivo alla scadenza costa 25 punti. Un task che si apre con «dividere in 4 schede» e non dice mai cosa dividere ottiene al massimo il 20%. Un template con intestazioni vuote ottiene al massimo il 10%. I pesi occupano circa 350 KB e si caricano con la pagina, e un testo di 3.000 caratteri viene controllato in meno di 100 millisecondi.

Frasi e lingue

Dividiamo il testo in frasi in corrispondenza di punti fermi, punti interrogativi ed esclamativi, puntini di sospensione e a capo, ma non dentro «v8.1», «1.200» o un indirizzo web, e non dopo una data come «7. Juni». Sono supportate 12 lingue: inglese, polacco, ceco, slovacco, croato, sloveno, bulgaro, tedesco, francese, italiano, spagnolo e olandese. La lingua viene rilevata automaticamente: correttamente nel 99,6% dei casi sui nostri set di test precedenti e nel 97,1% sui testi brevi nelle nuove lingue. Gli elenchi di frasi di slop per le 11 lingue diverse dall’inglese li abbiamo compilati noi; per tedesco, polacco, ceco e croato non ne abbiamo trovati di aperti. I controlli gratuiti accettano da 80 a 3.000 caratteri, il che copre il 97,5% dei bug report Jira che abbiamo raccolto, esclusi i blocchi di codice. Distorsione nota: la sola lingua sposta la stima di qualche punto. A parità di segnali, i testi in spagnolo, francese, ceco e italiano ottengono da 5 a 8 punti in meno di quelli in inglese, quelli in tedesco e olandese circa 4 punti in più, quindi confronta i punteggi all’interno di una stessa lingua.

Cosa non misuriamo

Slopcheck non misura chi ha scritto un testo, se è vero o come si posizionerà su Google o Bing. Su un campione del benchmark pubblico RAID in inglese, le caratteristiche testuali basate su regole hanno individuato al massimo il 28% dei testi scritti dall’AI con un tasso di falsi allarmi del 5%: per questo non offriamo il rilevamento dell’autore. Una nota di 2 righe può essere esattamente giusta per un team che condivide il proprio contesto: la stima vede solo il testo.

Domande

Come controllo se un testo contiene AI slop?

Incollalo nel campo della home page: da 80 a 3.000 caratteri, fino a 5 testi al giorno gratis. Ottieni il guadagno informativo, la quota di slop e le frasi di slop segnate nel testo.

Il mio testo viene conservato o inviato da qualche parte?

No. Il controllo avviene nel tuo browser: il testo non ci viene inviato e non viene conservato. Il link al risultato contiene il testo nella parte dell’indirizzo dopo il segno #, che i browser non inviano ai server.

Quali testi posso controllare?

Articoli, pagine prodotto, post, task, user story e bug report in 12 lingue: inglese, polacco, ceco, slovacco, croato, sloveno, bulgaro, tedesco, francese, italiano, spagnolo e olandese, da 80 a 3.000 caratteri.

Come si scrive un buon bug report?

Indica come riprodurre il problema: quali passi, quale versione, quale dispositivo e da quale soglia inizia a fallire. In uno studio su 180 bug report Android riproducibili, nel 92,2% mancava almeno 1 passo (Johnson et al., 2022). «L’esportazione fallisce per gli ordini con più di 500 righe in Chrome 128» esclude molto più di «l’esportazione a volte fallisce». Incolla il report nel controllo per vedere quali frasi non rispondono a nessuna di queste domande.

Slopcheck è un rilevatore di AI?

No. Slopcheck stima quanto un testo dice al suo lettore. Non dice chi o cosa l’ha scritto: un testo generato con fatti reali può ottenere un punteggio alto, e uno scritto a mano senza fatti ottiene un punteggio basso.

In cosa si distingue dai tool che cercano gli indizi dell’AI?

Gli strumenti che contano i trattini lunghi, «delve» o «tapestry» guardano la superficie di un testo. Slopcheck guarda cosa riceve il lettore: un testo può evitare ogni indizio e comunque non rispondere a nessuna delle sue domande.

Cos’è un passaporto del testo?

Un attestato di un testo preciso: il suo hash, il guadagno informativo, lo slop, la versione del metodo e la data del controllo, su una pagina con un proprio link. Chi ha il testo può incollarlo lì e vedere se corrisponde: se anche 1 solo carattere è diverso, l’hash è diverso. Ogni modifica viene salvata come nuova versione con i propri punteggi.

Mi serve un plugin o un SDK per usare l’API?

No. Con il piano Team il controllo è una richiesta HTTP con il testo. Si inserisce in uno step di CI, in un hook di pre-pubblicazione di un CMS o in un campo del tuo task tracker.

Fonti

1. C. E. Shannon (1948). A Mathematical Theory of Communication. Bell System Technical Journal
2. C. E. Shannon, W. Weaver (1949). The Mathematical Theory of Communication. University of Illinois Press
3. Google LLC (2022). Contextual estimation of link information gain. Brevetto US 11,354,342 B2
4. Google Search Central. Creating helpful, reliable, people-first content
5. R. Carnap, Y. Bar-Hillel (1952). An Outline of a Theory of Semantic Information. MIT Research Laboratory of Electronics
6. S. Sequoiah-Grayson, L. Floridi. Semantic Conceptions of Information. Stanford Encyclopedia of Philosophy
7. R. A. Howard (1966). Information Value Theory. IEEE Transactions on Systems Science and Cybernetics
8. H. P. Grice (1975). Logic and Conversation; le massime sono riassunte in «Implicature», Stanford Encyclopedia of Philosophy
9. J. Johnson et al. (2022). An Empirical Investigation into the Reproduction of Bug Reports for Android Apps. SANER 2022, sezione IV-C
10. Apache Software Foundation. Issue tracker Jira, bug report e task pubblici 2022–2026
11. Mozilla. Bugzilla, bug report pubblici 2023–2025
12. L. Dugan et al. (2024). «RAID: A Shared Benchmark for Robust Evaluation of Machine-Generated Text Detectors». ACL 2024