Questo è uno dei blog post che mi sono prefisso di scrivere per documentare il mio percorso sperimentale nella costruzione di un sistema NLP (italiano) per identificare quali entità contano di più nei documenti. La sfida principale: riconoscimento delle entità e risoluzione delle coreferenze, testando molteplici approcci e capendo perché ciascuno è risultato insufficiente.

La domanda centrale

Il problema sembra semplice: determinare quali entità un documento tratta fondamentalmente, invece di contare semplicemente la frequenza. Uno scenario che richiede di risolvere due sfide distinte simultaneamente.

La risoluzione delle entita' (NER)

I limiti di spaCy

Come quasi tutti (i data scientist di ultima generazione), la prima cosa che ho pensato quando ho deciso di imbarcarmi nell'impresa di riconoscimento delle entità e' stata quella di scegliere spaCy, ma l'ho trovato inadeguato. spaCy è un sistema English-first esteso ad altre lingue, ma come ripiego. I tipi di entità personalizzati e il fine-tuning si sono rivelati macchinosi, e il sistema mancava di un'architettura genuinamente language-agnostic.

Modelli basati su transformer

XLM-RoBERTa e mBERT offrivano supporto multilingue genuino fin dall'inizio. Tuttavia, venivano con set di label pre-addestrati (PER, ORG, LOC, MISC) incompatibili con la mia tassonomia personalizzata per entità specifiche del dominio come ingredienti e strumenti legali.

Modelli linguistici locali via Ollama

Testando llama3.2:3b, qwen2.5:7b, qwen2.5:14b e mistral:7b, ho trovato che gli LLM comprendono bene il contesto ma soffrono di problemi di scalabilità. Il tempo di elaborazione diventa proibitivo su larga scala, l'output manca di determinismo, e i modelli possono inventare tipi di entità non richiesti o allucinare completamente.

Sfide nella risoluzione delle coreferenze

L'obsolescenza di coreferee

Costruito su spaCy, coreferee aveva problemi di manutenzione. L'ultimo rilascio testava Python 3.11 e spaCy 3.5, con l'ultimo aggiornamento significativo del progetto nel 2022. A novembre 2025, i problemi di compatibilità lo rendevano inaffidabile per l'uso in produzione.

Il vincolo linguistico di AllenNLP

SpanBERT mostrava dei vaghi segni di promessa, ma anche il suo supporto linguisto nativo e' estremamente ridotto: inglese, cinese e arabo. Per un riconoscimento initaliano avrei avuto bisogno du un retraining totale con dati etichettati non disponibili al momento in cui ho initiato.

I problemi di performance di fastcoref

Questo modello dimostrava architettura moderna e migliore accuratezza multilingue ma rivelava problemi specifici dell'italiano. Su CPU, l'elaborazione di 1.000 documenti richiedeva 8 secondi ciascuno — proibitivamente lento. Più criticamente, faticava con le caratteristiche linguistiche dell'italiano: strutture pro-drop, clitici e soggetti nulli che trasportano informazioni di coreferenza nel testo italiano autentico.

Conclusione

Gli LLM general-purpose non possono servire come soluzioni NER — mancano di controllo dello schema, determinismo e scalabilità. La direzione necessaria: un transformer purpose-built che abiliti il rilevamento degli span con label-in-context, permettendo tipi di entità personalizzati al momento dell'inferenza invece di incorporarli nei pesi del modello.