Wikipedia Article Classifier

Cos'è il progetto

Wikipedia Article Classifier è una pipeline NLP in PySpark per preparare, vettorizzare e classificare articoli Wikipedia in categorie tematiche. Il progetto valorizza data quality, persistenza Parquet, feature engineering TF-IDF, baseline Naive Bayes e analisi qualitativa delle label.

Contesto tecnico

Un dataset Wikipedia con più di 153 mila articoli contiene titolo, categoria, summary e corpo testuale, ma non è subito pronto per addestrare un classificatore affidabile. Alcune righe hanno testi mancanti, alcune categorie richiedono ispezione qualitativa e il contenuto testuale deve essere trasformato in feature numeriche prima di poter essere usato da Spark MLlib.

Il problema non consisteva soltanto nel costruire un modello NLP. La parte più interessante era progettare una pipeline dati capace di caricare un CSV grande in PySpark, controllare la qualità del dato, creare una rappresentazione testuale riproducibile e predisporre una valutazione leggibile su 15 classi tematiche.

Obiettivo

L'obiettivo era costruire una pipeline NLP end-to-end in PySpark per classificare automaticamente articoli Wikipedia in categorie tematiche:

• caricare il CSV da Google Drive in ambiente Google Colab;
• eseguire EDA con Spark SQL su schema, valori mancanti e distribuzione delle categorie;
• rimuovere i record non utilizzabili per assenza di summary e documents;
• salvare il dataset pulito in Parquet per evitare rielaborazioni ripetute;
• combinare summary e documents in un unico campo testuale;
• trasformare il testo con Tokenizer, StopWordsRemover, HashingTF e IDF;
• addestrare un classificatore Multinomial Naive Bayes;
• predisporre metriche aggregate, metriche per classe, confusion matrix e cross-validation.

Il progetto mostra quindi un flusso completo dal dato grezzo al modello, con attenzione sia alla scalabilità operativa sia alla leggibilità degli insight ottenuti durante l'analisi.

Architettura

Il workflow è organizzato in otto passaggi principali:

1. wikipedia.csv viene letto da Google Drive con PySpark, abilitando header, inferenza schema, multiline, quote ed escape;
2. il DataFrame grezzo viene registrato come vista temporanea wikipedia_data per interrogazioni Spark SQL;
3. la funzione dataset_summary controlla schema, numero di righe, colonne e valori nulli;
4. i record con summary e documents mancanti vengono rimossi;
5. il dataset pulito viene scritto in wikipedia_clean.parquet e ricaricato se già disponibile;
6. summary e documents vengono concatenati nel campo text;
7. la pipeline Spark ML trasforma il testo in feature TF-IDF e indicizza la categoria;
8. Naive Bayes produce le predizioni, valutate con metriche multiclass e analisi per categoria.

Questa struttura separa la fase di data preparation dal training, riducendo il costo di iterazione quando si modifica il modello o la parte di valutazione.

Mappa del ragionamento

Il progetto è stato costruito come una sequenza di decisioni tecniche, non come un semplice notebook di classificazione. La logica di fondo è accompagnare il dato dal CSV grezzo a un output valutabile, rendendo espliciti i punti in cui qualità, formato e modello influenzano il risultato.

1. Dataset testuale grande e semi-strutturato: il CSV contiene 153.232 articoli e 15 categorie. PySpark permette di raccontare il problema come pipeline dati, usando DataFrame, Spark SQL e Spark MLlib invece di una soluzione locale solo Pandas.
2. Qualità minima prima del modello: 928 record hanno summary e documents mancanti. Rimuoverli evita di addestrare il classificatore su righe prive di informazione testuale.
3. Persistenza intermedia: il dataset pulito viene salvato in Parquet, così la fase di data preparation resta separata dal training e le iterazioni successive non ripetono passaggi deterministici.
4. Controllo qualitativo delle label: le word cloud aiutano a individuare 20 articoli fuori tema nella categoria finance. Questo passaggio mostra che la data quality riguarda anche coerenza semantica, non solo null e duplicati.
5. Feature engineering scalabile: Tokenizer, StopWordsRemover, HashingTF e IDF trasformano il testo in una rappresentazione sparsa a 20.000 dimensioni senza costruire manualmente un vocabolario completo.
6. Baseline interpretabile: Multinomial Naive Bayes è una scelta coerente con feature TF-IDF e permette di validare rapidamente l'intera pipeline prima di introdurre modelli più complessi.
7. Valutazione responsabile: accuracy, F1, precision, recall, metriche per classe, confusion matrix e cross-validation permettono di andare oltre una singola metrica aggregata.

Il messaggio principale è che il progetto dimostra capacità di progettazione del flusso dati: prima rendere il dato affidabile, poi trasformarlo, infine valutare il modello senza confondere pipeline funzionante e metriche definitive.

Dataset e pulizia

Il caricamento iniziale contiene 153.232 articoli. L'analisi dei missing value mostra 928 righe in cui summary e documents sono entrambi nulli, mentre titolo e categoria risultano popolati. Questi record non forniscono testo utile al classificatore e vengono rimossi.

Dopo questa pulizia, il dataset contiene 152.304 record. Il notebook usa una funzione dedicata, load_or_create_clean_dataset, per scrivere il risultato in Parquet su Google Drive e riutilizzarlo nelle esecuzioni successive. Questo rende il flusso più efficiente e più vicino a una pipeline dati reale rispetto a una semplice analisi in memoria.

Data quality qualitativa

Oltre ai controlli numerici, il progetto usa word cloud per ispezionare il contenuto delle categorie. Questa fase ha individuato un problema nella categoria finance: 20 articoli relativi a He-Man and the Masters of the Universe erano stati etichettati come finance, probabilmente per sovrapposizioni lessicali ambigue.

Questi record vengono filtrati con un pattern case-insensitive su termini come he-man, masters of the universe, skeletor, grayskull, cartoon, toyline e filmation. La scelta mostra un punto importante del Data Engineering applicato al testo: la qualità del dataset non si esaurisce con null e duplicati, ma richiede anche controlli semantici quando le label possono essere rumorose.

Feature engineering NLP

Il campo text viene trasformato con una pipeline Spark ML composta da:

• Tokenizer per dividere il testo in parole;
• StopWordsRemover per rimuovere parole frequenti a basso contenuto informativo;
• HashingTF con numFeatures=20000 per ottenere una rappresentazione sparsa a dimensione fissa;
• IDF con minDocFreq=5 per penalizzare termini troppo comuni;
• StringIndexer per convertire le categorie testuali in label numeriche.

La combinazione HashingTF e IDF permette di trattare un corpus testuale ampio senza costruire manualmente un vocabolario completo, mantenendo una rappresentazione adatta a un classificatore multiclass.

Modello e validazione

Il modello scelto è NaiveBayes, una baseline solida per classificazione testuale con feature di frequenza. Il dataset viene suddiviso con randomSplit([0.8, 0.2], seed=42), mantenendo una separazione tra training e test set.

La valutazione è predisposta con MulticlassClassificationEvaluator per calcolare accuracy, F1, precision e recall pesate. Il notebook include inoltre il calcolo manuale di precision, recall e F1 per ciascuna categoria, più una confusion matrix normalizzata per riga.

Per testare la robustezza della baseline, il progetto configura anche una CrossValidator a 3 fold con tre valori di smoothing per Naive Bayes: 0.5, 1.0 e 2.0. Questa struttura permette di confrontare configurazioni diverse mantenendo una valutazione coerente e documentabile.

Analisi delle categorie

Il progetto controlla la distribuzione delle 15 categorie e osserva un bilanciamento abbastanza uniforme. Le categorie si attestano intorno a circa 10 mila articoli ciascuna, con politics come categoria più rappresentata e finance come meno rappresentata dopo la pulizia.

Le word cloud vengono generate categoria per categoria per evitare timeout in Colab e per mantenere leggibile l'ispezione. Questo approccio rende l'EDA più operativa: non serve solo a creare grafici, ma aiuta a trovare anomalie, bias tematici e possibili problemi di labeling.

Scelte tecniche

Perché PySpark?

PySpark permette di trattare il dataset come un flusso distribuito anche in ambiente Colab, usando DataFrame, Spark SQL e Spark MLlib nello stesso notebook. Questo rende il progetto più vicino a un workflow Data Engineering rispetto a una soluzione solo Pandas.

Perché salvare in Parquet?

La pulizia iniziale viene separata dal training e salvata in formato Parquet. In questo modo le esecuzioni successive possono ripartire dal dataset già validato, riducendo tempo di caricamento e ripetizione di passaggi deterministici.

Perché Naive Bayes?

Naive Bayes è una baseline efficace per testi trasformati in feature di frequenza o TF-IDF. La scelta consente di concentrare il progetto sulla pipeline, sulla qualità del dato e sulla valutazione multiclass, senza introdurre subito modelli più pesanti.

Perché usare word cloud?

Le word cloud non sono usate come metrica del modello, ma come strumento diagnostico. Nel progetto hanno permesso di individuare etichette rumorose nella categoria finance, mostrando il valore di controlli qualitativi durante la data preparation.

Risultati

• 153.232 articoli caricati dal CSV sorgente;
• 928 record rimossi perché privi sia di summary sia di documents;
• 152.304 record conservati dopo la pulizia dei missing value;
• 15 categorie tematiche analizzate con distribuzione abbastanza bilanciata;
• 20 articoli mislabeled identificati nella categoria finance tramite analisi qualitativa;
• 20.000 dimensioni TF-IDF generate con HashingTF e IDF;
• pipeline Spark ML completa con tokenizzazione, stopword removal, feature engineering, label indexing e Naive Bayes;
• valutazione predisposta con metriche aggregate, metriche per classe, confusion matrix e cross-validation a 3 fold.

Evoluzioni future

Le evoluzioni più naturali riguardano il passaggio da notebook esplorativo a pipeline NLP più industrializzata, mantenendo la stessa logica Spark e gli stessi controlli qualitativi.

• pubblicare una versione consolidata delle metriche finali nel README e nella pagina progetto;
• versionare confusion matrix e tabelle per classe come artefatti di valutazione;
• documentare una procedura riproducibile per il caricamento del dataset sorgente;
• automatizzare controlli sui conteggi dopo pulizia e validazione delle label;
• confrontare il baseline Naive Bayes con Logistic Regression e Linear SVM sulla stessa pipeline TF-IDF;
• serializzare il modello Spark ML per scenari di inference documentati;
• trasformare il notebook in uno script parametrico per esecuzioni schedulate.

FAQ tecniche

Che tipo di metriche produce la pipeline?

La pipeline prepara accuracy, F1, precision, recall, metriche per classe, confusion matrix e cross-validation. La pagina valorizza soprattutto la struttura di valutazione, perché dimostra come il progetto possa documentare le performance in modo leggibile e riproducibile.

Perché rimuovere i record con summary e documents nulli?

Perché il classificatore usa il contenuto testuale come input. Quando entrambi i campi sono assenti, la riga conserva una categoria ma non contiene informazione utile per apprendere pattern linguistici.

Come viene gestito il dataset sorgente?

Il workflow usa wikipedia.csv come sorgente esterna caricata su Google Drive, una scelta adatta a un dataset di grandi dimensioni. Il notebook documenta il punto di ingresso e poi salva il risultato pulito in Parquet per rendere più efficienti le esecuzioni successive.

Che ruolo hanno le word cloud?

Servono come controllo qualitativo sulle categorie. Nel caso della categoria finance hanno aiutato a individuare 20 articoli fuori tema, poi rimossi prima del training.