Are LLMs Truly Multilingual? Exploring Zero-Shot Multilingual Capability of LLMs for Information Retrieval: An Italian Healthcare Use Case

Di /
stato della ricerca deep learning

Che cosa racconta il paper, perché è una novità e panoramica

Questo paper parte da una domanda molto concreta: posso usare un LLM “multilingue” per leggere cartelle cliniche in italiano e tirare fuori, in automatico, le comorbidità più importanti dei miei pazienti, senza addestramento, senza prompt engineering sofisticato, direttamente “out of the box”?

Gli autori lavorano su cartelle cliniche elettroniche (EHR) di un grande ospedale italiano e si concentrano su un’area specifica ma cruciale: l’anamnesi di pazienti cardiologici. Da quei testi in italiano vogliono estrarre la presenza o assenza di cinque comorbidità fondamentali per valutare il rischio cardiaco: fibrillazione atriale, insufficienza renale, BPCO, diabete mellito e ipertensione arteriosa.

La “novità” principale sta nel tipo di scenario che viene testato. Non si parla di modelli chiusi in cloud come GPT-4, ma solo di modelli open-source, eseguibili on-premise per rispettare i vincoli di privacy sanitaria. Inoltre, non si fa fine-tuning né few-shot: tutto avviene in zero-shot, con un prompt standard uguale per tutti i modelli, come succederebbe a un medico che apre un’interfaccia e scrive una domanda il più possibile naturale e diretta.

Per costruire un confronto solido, gli autori non si limitano a chiedere a LLM di classificare le cartelle. Prima costruiscono una baseline molto curata usando regular expression (regexp) progettate insieme ai clinici, così da avere una classificazione automatica ma “tradizionale”. Poi prendono un sottoinsieme di cartelle classificate come negative dalle regexp e lo fanno annotare a mano da due medici, creando un piccolo ma prezioso gold standard umano.

Su questi dati testano sei LLM open-source e multilingue, appartenenti a tre famiglie:
OpenLLaMA 3B e 7B, Mistral 7B, Mixtral 8x7B, Qwen2.5 3B e 7B. L’idea è capire, dati questi vincoli molto realistici (lingua italiana, privacy, zero-shot, nessun ML engineer in corsia), quanto ci si possa fidare dei modelli.

I risultati, letti solo come accuracy media, sembrano promettenti: alcuni modelli superano il 70% rispetto alla classificazione automatica con regexp, e in alcuni casi Mistral 7B arriva oltre l’80%.

Ma quando si entra nel dettaglio e si guardano precision, recall, F1-score e matrici di confusione, l’immagine cambia. Per alcune combinazioni modello-comorbidità si vede che il modello tende a classificare quasi tutto come positivo oppure quasi tutto come negativo, sfruttando lo sbilanciamento del dataset e “barando” sul fatto che la maggior parte dei pazienti non ha una certa patologia. Qwen2.5, per esempio, arriva ad avere precision e recall pari a zero per la classe positiva nella comparazione con le regexp.

Quando il confronto si sposta sul piccolo set annotato a mano, la regexp ottiene un’accuracy complessiva di circa il 92%, mentre i modelli arrivano spesso a valori più bassi e, soprattutto, mostrano comportamenti sistematici poco rassicuranti: ci sono modelli che sul subset manuale classificano praticamente tutto come positivo, altri che tendono a scegliere quasi sempre la classe maggioritaria. In altre parole, le belle medie nascondono generalizzazioni fragili.

Il messaggio chiave del paper è quindi piuttosto netto: in questo scenario LLM multilingue open-source, usati in zero-shot e senza competenze tecniche, non possono sostituire la pipeline basata su regexp per estrarre comorbidità da EHR in italiano. Sono uno strumento interessante, ma richiedono molta più cura, valutazione e probabilmente adattamento specifico prima di essere usati in un contesto clinico reale ad alto rischio.

Alla domanda del titolo, “Are LLMs truly multilingual?”, gli autori rispondono in modo sfumato: questi modelli sono multilingue nel senso che “capiscono” e “parlano” italiano, ma non sono ancora affidabili per un compito clinico di estrazione strutturata in zero-shot, almeno non quanto una soluzione rule-based progettata con cura.

Alla fine della sezione, ecco le informazioni pratiche che ti evitano tempo perso:

Risorse: GitHub: non risulta alcun GitHub repo pubblico specifico per questo lavoro al momento della scrittura. Paper: arXiv: 2512.04834. Dataset: non disponibile pubblicamente, perché basato su EHR reali di pazienti raccolti in un ospedale italiano e soggetti a forti vincoli di privacy.

Indice

Come funziona l’approccio del paper: pipeline dati, modelli e setup sperimentale

Per capire davvero il valore dei risultati, conviene vedere come funziona l’intero sistema, passo dopo passo, come se seguissimo una “guida completa” della pipeline.

Gli autori partono da una grande base dati di 8223 pazienti, tutti con un record di anamnesi scritto in italiano. L’ospedale usa un sistema EHR che memorizza i dati in varie tabelle; gli autori costruiscono una pipeline ETL usando Oracle e Python per raccogliere e normalizzare le informazioni cliniche. Da questo ETL ottengono diversi dataframe (Anamnesis, Interventions, Labs, Procedure, ecc.), ma per questo studio si concentrano solo sulla tabella Anamnesis, che contiene tre colonne: un identificativo di ricovero, un identificativo di struttura e il testo libero dell’anamnesi.

Nel testo di anamnesi è dove si nasconde il valore: il medico descrive storia clinica, patologie pregresse, trattamenti in corso. È un testo ricco di abbreviazioni, sinonimi, acronimi, refusi, variazioni lessicali tipiche del linguaggio medico in italiano. Da quel testo bisogna estrarre, per ogni paziente, un sì/no per ciascuna delle cinque comorbidità selezionate.

La baseline con le regexp

Come “punto di partenza”, gli autori costruiscono una baseline a regexp. Non è una cosetta buttata lì: lavorano a stretto contatto con i clinici per definire pattern che catturino tutte le varianti rilevanti.

Prendiamo il diabete come esempio. Un medico può scrivere “diabete mellito”, “DM”, “diabete tipo 2”, “IDDM”, “NIDDM”, “diabete con nefropatia”, e così via. Ogni variante ha sfumature cliniche diverse, ma tutte indicano la presenza del macro-concetto “diabete mellito”. Per questo servono esperti di dominio: un data scientist da solo rischia di perdersi pezzi importanti o di confondere casi borderline.

Il risultato di questo lavoro è un classificatore basato su regexp che, per ogni EHR, decide se la comorbidità è presente (classe 1) o assente (classe 0). Questa baseline viene poi usata in due modi:
come riferimento “automatizzato” per la comparazione con i LLM sui 8223 record;
come filtro per selezionare 100 record che la regexp etichetta come negativi, ma sui quali vale la pena fare una seconda verifica manuale.

Mini-gold standard annotata a mano

Il passo successivo è la creazione di un piccolo gold standard umano. Vengono presi 100 record che la regexp ha classificato come assenza di comorbidità per tutte le cinque patologie. Due medici li rileggono e li annotano a mano, comorbidità per comorbidità, discutendo i casi dubbi fino ad arrivare a un accordo.

Questa mini-gold standard ha due funzioni:

  • misurare quanto la regexp sbaglia proprio nelle situazioni più delicate, cioè i falsi negativi;
  • avere un piccolo ma affidabile set di verità a cui confrontare i LLM, per capire se davvero colgono le sfumature semantiche o se stanno solo imparando a sfruttare la distribuzione delle classi.

Gli autori scoprono, per esempio, che la regexp è molto forte su alcune comorbidità (come BPCO) e più debole su altre (ipertensione, fibrillazione atriale), ma nel complesso raggiunge un’accuracy complessiva di circa il 92%.

La scelta dei LLM e il vincolo “multilingue + on-premises”

A questo punto entra in gioco la domanda “novità LLM in italiano, come funziona davvero in sanità?“. Gli autori non possono usare modelli chiusi in cloud per motivi di privacy e licensing: dati sanitari non possono uscire dall’ospedale, quindi serve un setup on-premises su infrastruttura HPC con più GPU.

In più, per garantire che i modelli possano gestire bene l’italiano, scelgono solo modelli multilingue: niente LLM esclusivamente inglesi. La selezione finale include:

  • OpenLLaMA con 3 e 7 miliardi di parametri;
  • Mistral 7B e la variante Mixtral 8x7B (mixture-of-experts);
  • Qwen2.5 con 3B e 7B.

Sono tutti modelli open-source, noti per le buone performance generali e per uno score non pessimo sull’italiano nelle leaderboard pubbliche.

Zero-shot, un prompt semplice e una classificazione alla volta

La parte più interessante, se ti stai chiedendo “come funziona la valutazione zero-shot in pratica”, è il design del prompt e dell’inferenza. Gli autori decidono di usare:

  • un solo prompt standard per tutti i modelli;
  • un solo comorbidity-check per inferenza, cioè ogni EHR viene passato al modello cinque volte, una per comorbidità, anziché chiedere al modello di estrarre tutte le patologie in una sola chiamata.

Questa scelta ha uno scopo chiaro: evitare che il modello confonda compiti diversi nella stessa risposta e ridurre il rischio di misinterpretazioni. In un contesto clinico, un falso positivo o negativo di troppo non è un dettaglio.

Non viene fatto alcun fine-tuning e non vengono usate tecniche come few-shot o chain-of-thought: il paper vuole simulare un caso d’uso in cui il medico non è un ML engineer, ma solo un utente che usa un’interfaccia e scrive prompt semplici.

Per misurare le performance, gli autori usano sia accuracy (quanto spesso il modello indovina globalmente) sia metriche più mirate sulla classe positiva come precision, recall e F1-score. Spiegate in termini intuitivi: la precision indica quanti dei casi etichettati come “malato” sono davvero malati, il recall indica quanti dei malati veri vengono trovati, l’F1 prova a bilanciare le due cose.

Risultati in dettaglio: cosa succede quando mettiamo LLM, regexp e umani a confronto

Entriamo ora nella parte “guida completa ai risultati”: che cosa succede, numeri alla mano, quando confrontiamo LLM, regexp e annotatori umani?

LLM vs regexp: la trappola dell’accuracy

Nel primo set di esperimenti, il riferimento è la classificazione automatica fatta con le regexp su tutti gli 8223 record. In apparenza le cose vanno piuttosto bene: modelli come OpenLLaMA 7B, Mistral 7B, Qwen2.5 3B e 7B superano un’accuracy del 70% rispetto alle etichette regexp, mentre OpenLLaMA 3B e Mixtral 8x7B restano molto più indietro, sotto il 35%.

Se leggessimo solo questo numero, potremmo dire: “bene, i LLM sono abbastanza vicini alla baseline, in qualche caso quasi la eguagliano, novità interessante”. Il problema è che l’accuracy non dice nulla su come vengono trattati i casi positivi, che in un dataset clinico sono spesso minoritari.

Quando gli autori guardano precision, recall e F1-score per la classe positiva (presenza della comorbidità), la storia cambia. OpenLLaMA 3B, per esempio, ha recall perfetto (1.0) per tutte le comorbidità, ma precision molto bassa, a volte 0.09 o 0.13. In altre parole, etichetta troppi pazienti come malati, producendo moltissimi falsi positivi. Qwen2.5 3B e 7B sono ancora più estremi: in questo confronto con le regexp arrivano ad avere precision e recall pari a zero sulla classe positiva, perché di fatto non riescono a intercettare correttamente nessun vero caso di comorbidità secondo il riferimento regexp.

Mistral 7B appare come il modello più promettente: ottiene precision molto elevata (vicina o pari a 1 per alcune comorbidità), ma recall più basso, quindi tende a essere molto prudente, riconoscendo bene i casi positivi che individua, ma perdendone molti altri. Mixtral 8x7B ha un comportamento speculare: recall alto ma precision basso, quindi buona sensibilità ma molti falsi positivi.

Questa analisi mostra una cosa importante: in un contesto così sbilanciato e sensibile, non basta un singolo numero medio per dire “funziona” o “non funziona”. Modelli con alta accuracy possono essere inutilizzabili perché predicono sempre la classe dominante (spesso il “nessuna comorbidità”), mentre altri, sembrando generosi nella scoperta di casi, producono troppi allarmi falsi.

LLM vs annotazione umana: il reality check

Il secondo blocco di esperimenti è quello che risponde in modo più diretto alla domanda “come funziona davvero un LLM quando lo confronto con un medico?”. Qui il riferimento non sono più le regexp ma la mini-gold standard di 100 record annotati a mano da due clinici.

Su questo subset, la regexp arriva a un’accuracy complessiva di circa il 92.2%. È un valore alto, ma soprattutto è supportato da un pattern di errori che ha senso dal punto di vista clinico: per alcune comorbidità come BPCO la regexp è quasi perfetta, per altre come ipertensione o fibrillazione atriale fatica di più e genera alcuni falsi negativi in più.

I LLM, su questo stesso subset, mostrano risultati misti:

  • OpenLLaMA 3B ha performance disastrose, con accuracy complessiva sotto il 10% e una tendenza sistematica a classificare quasi tutto come positivo sul subset scelto per la verifica manuale.
  • OpenLLaMA 7B, Mistral 7B, Mixtral 8x7B, Qwen2.5 3B e 7B sembrano andare molto meglio come accuracy media (spesso sopra l’80%), ma quando si guardano le matrici di confusione si scopre che parte di questa performance deriva dal fatto che alcuni modelli finiscono per predire quasi sempre la classe dominante, più che da una vera comprensione semantica.

Mistral 7B, per esempio, mostra sul dataset completo un buon equilibrio fra comorbidità, ma sul subset manuale tende a classificare la maggior parte dei casi nella stessa classe, seguendo lo sbilanciamento del campione. Questa tendenza fa sì che il modello sembri “bravo” in termini medi, ma in realtà non generalizza davvero sui casi rari e difficili.

Il confronto diretto con la regexp porta quindi a una conclusione chiara: anche il miglior LLM fra quelli testati non riesce a offrire un comportamento più affidabile e interpretabile di una pipeline rule-based ben progettata, almeno non in questo regime di zero-shot senza prompt engineering.

Risposte alle tre domande del paper

Il lavoro è costruito attorno a tre domande chiave, che possiamo riassumere così, usando un linguaggio vicino a quello che potrebbe usare un medico curioso di “novità LLM”:

La prima domanda è se si possano usare LLM in zero-shot per estrarre comorbidità da EHR in italiano. La risposta è che si può, ma con risultati molto variabili, che dipendono fortemente dal modello, dalla comorbidità e dallo sbilanciamento delle classi. I modelli generano output coerenti e plausibili, ma non abbastanza affidabili per un uso clinico diretto.

La seconda domanda è se i LLM possano sostituire il metodo a regexp. I dati dicono chiaramente di no: le regexp rimangono superiori in termini di affidabilità globale e di comportamento sui casi critici, in particolare quando si guarda alla gold standard umana.

La terza domanda è se esista un “miglior LLM” fra quelli testati. In termini di performance aggregata rispetto alle regexp, Mistral 7B sembra il più promettente, ma non basta a renderlo un sostituto sicuro. Dal confronto con le annotazioni umane emerge che il modello non dimostra una vera comprensione delle sfumature semantiche delle comorbidità, ma piuttosto un adattamento superficiale alle distribuzioni del dataset.

Concetti chiave da capire per leggere il paper

Per sfruttare davvero questo lavoro come “guida completa” a come funziona l’uso dei LLM in contesti clinici multilingue, vale la pena chiarire alcune nozioni fondamentali.

EHR, comorbidità e linguaggio clinico in italiano

Gli Electronic Health Records (EHR) sono il cuore del dato clinico moderno: contengono la storia del paziente, referti, terapie, diagnosi, esami e note testuali. La parte testuale non è strutturata: è piena di abbreviazioni, acronimi e idiosincrasie linguistiche, che cambiano da ospedale a ospedale e da medico a medico.

Le comorbidità sono patologie che co-esistono con la malattia principale e ne influenzano prognosi e trattamento. Nel caso del paper, il focus è sulla cardiologia, quindi comorbidità come diabete o insufficienza renale possono cambiare radicalmente il rischio e le scelte terapeutiche. La sfida è passare da testo libero a campi strutturati del tipo “ipertensione: sì/no” in modo automatico.

Far questo in italiano è più difficile che in inglese, perché:

  • ci sono meno dataset pubblici annotati;
  • il linguaggio clinico italiano è meno standardizzato nei corpora;
  • molti modelli sono addestrati con una prevalenza di testo inglese e solo una quota minore di altre lingue.

Zero-shot e perché importa

Un modello lavora in zero-shot quando affronta un compito senza aver visto esempi etichettati di quel compito durante l’addestramento o il prompt. Gli chiedi “dimmi se in questo testo c’è evidenza di BPCO” e lui deve cavarsela basandosi solo sulla sua conoscenza del linguaggio e del dominio appresa in pre-training.

Zero-shot è molto attraente perché evita costi di etichettatura e fine-tuning, ma in ambito clinico è anche rischioso: se il modello ha visto poco testo clinico italiano o ha imparato pattern basati soprattutto sull’inglese, può fare errori sistematici difficili da prevedere. Questo paper mostra proprio come, in zero-shot, i LLM possano sembrare competenti a colpo d’occhio, ma fallire nel cogliere le sfumature che un medico considera scontate.

Regexp vs LLM: pattern espliciti contro pattern impliciti

Le regexp sono l’esempio perfetto di approccio “pattern esplicito”: un umano decide quali stringhe devono far scattare una certa etichetta e il sistema si limita ad applicare queste regole. I vantaggi sono:

  • comportamento trasparente;
  • controllo fine su sinonimi, abbreviazioni, casistiche rare;
  • facile spiegabilità verso i clinici.

Gli svantaggi sono altrettanto chiari: costruire e mantenere queste regole è costoso, fragile rispetto ai cambiamenti di stile di scrittura e poco generalizzabile ad altre patologie o reparti.

I LLM fanno l’opposto: imparano pattern in modo implicito nei loro latents e negli hidden states, combinando milioni di esempi durante il pre-training. Il vantaggio è che possono potenzialmente catturare una gamma enorme di varianti linguistiche senza scrivere a mano regole; lo svantaggio è che, se il dato di training non rappresenta bene il dominio (per esempio, EHR italiani), il modello può “inventarsi” correlazioni che non reggono in clinica.

Questo paper non dice che i LLM siano inutili, ma pone un limite chiaro: senza adattamento e senza valutazioni molto attente, i LLM non possono ancora sostituire le soluzioni rule-based nei flussi critici di estrazione dati clinici.

Metriche: perché accuracy non basta

In un dataset dove, per una certa comorbidità, la stragrande maggioranza dei pazienti è negativa, un classificatore che dice sempre “negativo” ottiene un’accuracy molto alta pur essendo totalmente inutile. Per questo servono metriche come:

  • precision sulla classe positiva: “fra i pazienti che il modello dichiara malati, quanti lo sono davvero?”;
  • recall sulla classe positiva: “fra i pazienti davvero malati, quanti ne trova il modello?”;
  • F1-score: un modo equilibrato per combinare precision e recall in un singolo numero.

Nel paper vediamo chiaramente casi in cui modelli con buona accuracy hanno precision o recall disastrosi sulla classe positiva. Alcuni LLM predicono quasi sempre la classe 0 o quasi sempre la classe 1, e la confusione introdotta da un semplice numero medio si vede solo guardando le matrici di confusione.

Multilinguismo: “truly multilingual” o solo “parlo un po’ tante lingue”?

Negli ultimi anni molti LLM sono stati addestrati su grandi corpora multilingue e mostrano performance decenti su tante lingue diverse. Tuttavia, diverse analisi recenti mostrano che le prestazioni sono spesso molto migliori in inglese e calano in modo sensibile su lingue meno rappresentate o su domini specialistici come quello medico.

Questo lavoro si inserisce proprio in questa linea di ricerca: chiede se, in un caso realistico e ad alto rischio come l’estrazione di comorbidità da EHR italiani, i LLM multilingue open-source siano “veramente” multilingue nel senso di essere affidabili. La risposta è che il multilinguismo c’è, ma la robustezza non è ancora sufficiente per sostituire metodi più semplici e controllabili.

Quiz: domande e risposte per fissare i concetti

Perché gli autori hanno scelto solo modelli open-source eseguibili on-premises?

La scelta di modelli open-source e on-premises è dettata da vincoli di privacy e regolamentazione tipici della sanità: le EHR contengono dati estremamente sensibili che non possono essere inviati a servizi cloud esterni senza complicazioni legali e di sicurezza. Con modelli open-source eseguiti dentro l’infrastruttura dell’ospedale, i dati non escono mai dal perimetro istituzionale e c’è più controllo su accessi, logging e auditing. Inoltre, i modelli open-source possono essere ispezionati, configurati e, in futuro, anche fine-tuned internamente.

Che cosa significa davvero usare i LLM in modalità zero-shot in questo studio?

In questo studio, zero-shot significa che i modelli non vengono addestrati o fine-tuned sul dataset di EHR italiane, né vengono mostrati esempi etichettati nel prompt. A ogni modello viene passato il testo dell’anamnesi e una richiesta del tipo “indica se in questo testo è presente la patologia X”, e il modello deve rispondere sì/no basandosi solo sulla propria conoscenza pregressa del linguaggio e della medicina. Non ci sono esempi guida, non ci sono few-shot prompt: è esattamente lo scenario “apro la chat del modello e gli chiedo qualcosa” che un medico reale potrebbe avere in mente.

Perché l’accuracy da sola è fuorviante per valutare questi modelli?

L’accuracy è fuorviante perché, in un contesto clinico con classi fortemente sbilanciate, un modello può ottenere una percentuale alta di risposte corrette semplicemente indovinando sempre la classe più frequente. Se, per una certa patologia, il 90% dei pazienti è davvero negativo, un modello che dice sempre “negativo” farà il 90% di accuracy, ma non identificherà nessun caso positivo, cioè sarà clinicamente inutile. Per questo nel paper si insiste su metriche come precision e recall sulla classe positiva e sulle matrici di confusione, che mostrano se il modello sta realmente riconoscendo le comorbidità o se sta solo sfruttando lo sbilanciamento del dataset.

In che cosa la baseline a regexp è ancora superiore ai LLM testati?

La baseline a regexp è superiore principalmente per tre motivi. Primo, ha un comportamento più stabile e interpretabile: se una comorbidità viene riconosciuta o meno, è possibile risalire al pattern che ha fatto scattare la decisione. Secondo, quando confrontata con le annotazioni dei clinici, la pipeline regexp raggiunge un’accuracy complessiva intorno al 92%, con errori distribuiti in modo coerente con la pratica clinica. Terzo, non mostra le “derive” tipiche dei LLM in zero-shot, come la tendenza per alcuni modelli a classificare quasi tutto come positivo o negativo, che rende difficile fidarsi del sistema in un ambiente ad alto rischio come l’ospedale.

Perché Mistral 7B viene spesso citato come il “migliore”, ma non basta per sostituire le regexp?

Mistral 7B emerge come il “migliore” perché, rispetto agli altri LLM testati, offre un compromesso relativamente buono tra le varie comorbidità, con accuracy elevate e metriche decenti in diversi scenari. Tuttavia, quando si osservano le matrici di confusione sui dati annotati a mano, si vede che il modello tende a sfruttare le distribuzioni di classe più che a comprendere davvero le sfumature del testo. In altre parole, funziona meglio degli altri modelli, ma continua a non raggiungere un livello di affidabilità comparabile a quello della pipeline regexp, soprattutto se guardiamo ai casi rari e clinicamente più delicati.

Che cosa ci insegna questo paper sulla “vera” natura multilingue dei LLM?

Il paper mostra che il multilinguismo dei LLM è reale ma incompleto. I modelli capiscono e generano italiano, riescono a interpretare in modo plausibile testo clinico e a rispondere a domande rilevanti. Tuttavia, quando vengono messi alla prova su un compito strutturato, con vincoli forti di precisione e sicurezza come l’estrazione di comorbidità da EHR reali, in zero-shot e senza adattamento, mostrano limiti evidenti. Questo suggerisce che, almeno per ora, i LLM non sono “truly multilingual” nel senso di garantire prestazioni robuste e affidabili in domini specialistici non inglesi; richiedono ancora dataset dedicati, valutazioni attente e probabilmente strategie di adattamento come fine-tuning o in-context learning.

Studi correlati e come si collegano: guida completa alle novità su LLM, multilinguismo e sanità

Questo lavoro non vive nel vuoto: si inserisce in un filone di ricerca molto attivo che si chiede come funziona davvero l’uso dei LLM per l’estrazione di informazioni cliniche e quanto siano affidabili fuori dall’inglese.

Diversi survey recenti sul ruolo dei LLM in medicina mostrano che vengono già usati per medical question answering, summarization di dialoghi clinici, generazione di documentazione e supporto alle decisioni. Tuttavia, sottolineano anche la presenza di forti sfide legate a sicurezza, bias e valutazione delle prestazioni in scenari reali.

Sul fronte specifico dell’information extraction da EHR, ci sono studi che mostrano come i LLM possano competere o superare approcci tradizionali su corpora annotati in inglese. Alcuni lavori, per esempio, mostrano che GPT-4 può estrarre fenotipi oncologici complessi da note cliniche con performance molto alte, superando modelli precedenti basati su BERT o su regole.

Altri lavori guardano alla zero-shot information extraction da clinical notes e trial report, evidenziando che i LLM possono ridurre in modo drastico il costo di annotazione e accelerare attività come la meta-analisi, ma anche che le performance variano molto a seconda della qualità del prompt e del tipo di informazione da estrarre.

Sul versante “siamo pronti a sostituire i modelli classici con i LLM per l’IE clinica?”, alcuni studi recenti arrivano a conclusioni più caute e complementari a questo paper: mostrano che, anche quando i LLM superano modelli come BERT su alcune metriche, restano problemi di costo computazionale, throughput, stabilità delle predizioni e difficoltà di spiegare il comportamento del modello ai clinici.

C’è poi un filone dedicato al multilinguismo in sanità e alla valutazione cross-linguale dei LLM. Alcuni lavori su dataset multilingue mostrano che la qualità delle risposte dei LLM a domande mediche è sistematicamente più bassa per lingue non inglesi, con differenze marcate in correttezza, consistenza e verificabilità delle risposte. Altri propongono framework di valutazione e modelli “evaluator LLM” focalizzati proprio sul colmare questo gap, sottolineando l’importanza di creare benchmark dedicati per lingue meno rappresentate.

Infine, sul fronte specifico dell’italiano biomedico, esistono lavori che costruiscono dataset annotati e modelli transformer dedicati all’estrazione di entità cliniche e alla classificazione di testi, mostrando che si possono ottenere ottime performance quando si investe in risorse linguistiche mirate, anche in assenza di LLM giganteschi.

Mettendo insieme questi pezzi, il paper “Are LLMs Truly Multilingual?” si colloca come un tassello importante di questa “guida completa” alle novità su LLM e sanità, in particolare per l’ecosistema italiano. Il messaggio finale non è di sfiducia verso i LLM, ma di realismo: sono strumenti potenti, ma richiedono un uso maturo, valutazioni severe, attenzione al multilinguismo e una chiara comprensione dei trade-off rispetto a soluzioni più tradizionali come le regexp.

Per chi lavora con dati clinici in italiano e sta pensando di integrare LLM nei propri flussi di lavoro, questo paper è quindi un punto di partenza ideale per capire come funziona davvero l’integrazione fra intelligenza artificiale generativa, privacy, valutazione e sicurezza in un contesto reale di ospedale.

Torna in alto