Vai al contenuto

Stilometria computazionale: misurare lo stile senza confonderlo col tema

Stilometria computazionale: come misuriamo ‘voce’ su 50M articoli

La stilometria computazionale analizza caratteristiche ricorrenti della scrittura: lessico, sintassi, punteggiatura e organizzazione delle frasi. Può aiutare a confrontare testi e profili autoriali, ma un punteggio di somiglianza non certifica chi ha scritto un articolo.

Nel lavoro su AI Multisite mi interessa soprattutto il suo impiego editoriale: descrivere una voce e valutare quanto un testo se ne discosti. Per rendere utile questo confronto bisogna distinguere stile, argomento e interventi della redazione. Un articolo su un tema insolito può essere perfettamente autentico.

Partire da caratteristiche che si possano discutere

Un primo profilo può raccogliere lunghezza e variabilità delle frasi, frequenza di parole funzionali, distribuzione delle parti del discorso e uso della punteggiatura. Le caratteristiche interpretabili permettono di aprire una discussione concreta con chi scrive.

Guarderei anche la distribuzione, non soltanto la media. Due testi con frasi mediamente della stessa lunghezza possono alternare periodi brevi e lunghi in modi diversi. Titoli, citazioni e liste vanno trattati con una regola esplicita, perché possono cambiare molto il risultato.

La diversità lessicale risente della lunghezza del campione. Confrontare una breve notizia con un lungo editoriale richiede cautela anche quando entrambi hanno la stessa firma. Il profilo dovrebbe conservare il contesto dei testi da cui è stato calcolato.

Il tema può diventare una scorciatoia

Se un autore scrive sempre di sport e un altro di tecnologia, un classificatore può riconoscerli attraverso l’argomento. Il risultato sembra una misura di stile finché uno dei due cambia rubrica.

La ricerca Addressing Topic Leakage in Cross-Topic Evaluation for Authorship Verification mostra perché anche la valutazione tra temi richiede controlli sulla sovrapposizione. Il lavoro Same Author or Just Same Topic? affronta la costruzione di rappresentazioni stilistiche meno dipendenti dal contenuto.

Un embedding semantico può aggiungere informazioni utili, ma non lo chiamerei automaticamente “vettore dello stile”. Proverei separatamente caratteristiche stilistiche, rappresentazione semantica e loro combinazione, osservando cosa succede quando cambiano argomento e periodo.

Costruire un test che non contenga copie del training

Prima della suddivisione dei dati rimuoverei duplicati e versioni quasi identiche. Un articolo ripubblicato con poche modifiche non dovrebbe comparire sia nell’addestramento sia nel test. Anche segmenti dello stesso pezzo devono restare nello stesso gruppo.

Valuterei risultati per autore, rubrica, lunghezza e periodo. Un valore aggregato può nascondere un sistema efficace sugli autori più rappresentati e poco attendibile sugli altri.

Inserirei anche testi di autori assenti dal training quando il caso d’uso li prevede. Un classificatore costretto a scegliere fra firme conosciute può assegnare con sicurezza apparente un testo che non appartiene a nessuna di esse.

Dare un significato operativo alla soglia

Definirei prima quale evento il sistema deve segnalare. Se la classe positiva è “testo da rivedere”, la precision misura quanti dei testi segnalati richiedono davvero revisione; il recall misura quanti dei testi che la richiedono vengono intercettati. Invertire la classe cambia l’interpretazione delle metriche.

La soglia si sceglie considerando il costo degli errori. Un controllo che interrompe automaticamente la pubblicazione richiede una valutazione diversa da una lista di suggerimenti facoltativi per un editor.

Presenterei il risultato come un elemento di revisione, con esempi e contesto. Un outlier può dipendere da una citazione lunga, da editing redazionale o da un cambiamento intenzionale del registro. Non è una prova sufficiente di uso dell’AI o di falsa attribuzione.

Misurare la pipeline senza sacrificare il confronto

Dopo aver fissato il test, profilerei le fasi di elaborazione. spaCy documenta batching e multiprocessing con nlp.pipe; il numero utile di processi dipende da modello, testi, memoria e costo di avvio. Più worker non garantiscono un’accelerazione proporzionale.

Per ogni ottimizzazione confronterei tempo totale, memoria e variazione dei risultati sullo stesso campione. Conservare versione del modello, regole di pulizia e identificazione del dataset rende il confronto ripetibile.

Il risultato editoriale che cerco è una segnalazione comprensibile: quale caratteristica è cambiata, rispetto a quali testi e con quali limiti. La decisione sulla voce resta a chi conosce l’autore e il contesto della pubblicazione.