Il 21 aprile 2020 NVIDIA e King’s College London hanno presentato MONAI — Medical Open Network for AI — una libreria PyTorch con licenza Apache 2.0 per il deep learning sull’imaging medicale, ospitata su github.com/Project-MONAI/MONAI. La novità non è un modello né un risultato sperimentale: è che il codice di pre-processing, addestramento e valutazione che ogni gruppo riscriveva da sé adesso sta in un posto solo.

Contesto

Chi addestra reti su tomografie computerizzate (TC) o risonanze magnetiche (RM) lavora in PyTorch da anni, ma intorno al framework generalista resta uno strato di codice specifico per il dato medico che nessuno ha mai standardizzato. Sono sempre le stesse operazioni, ripetute in ogni laboratorio con piccole varianti: ricampionamento dei voxel a uno spacing target, riallineamento dell’orientamento anatomico, normalizzazione delle unità Hounsfield per la TC, estrazione di patch dai volumi troppo grandi per stare in memoria. A questo si aggiungono le loss e le metriche che servono in radiologia — il coefficiente di Dice, la distanza di Hausdorff, la distanza media alla superficie — implementate caso per caso, spesso con convenzioni diverse sui bordi e sui voxel di sfondo.

Il risultato è duplicazione di codice e una riproducibilità più fragile. Due articoli che dichiarano lo stesso preprocessing possono averlo scritto in modi diversi, e senza il codice è difficile accorgersene. NVIDIA aveva già affrontato il problema dal suo lato con Clara Train, parte dello stack Clara, ma legato all’ecosistema NVIDIA. C’erano poi librerie accademiche precedenti — NiftyNet, DLTK, DeepNeuro — da cui MONAI dichiara apertamente di ereditare le pratiche. Mancava un componente neutrale, costruito direttamente sopra PyTorch, su cui far confluire i contributi invece di disperderli.

Architettura

MONAI è una libreria Python sopra PyTorch, con integrazione opzionale di PyTorch Ignite per il ciclo di addestramento. La divisione in moduli ricalca le fasi di una pipeline di imaging.

monai.transforms è la parte che rende di più da subito. Raccoglie le trasformazioni del dominio: Spacing per il ricampionamento a uno spacing target, Orientation per il riallineamento agli assi anatomici, ScaleIntensityRange per mappare le unità Hounsfield, oltre alla data augmentation tridimensionale (RandAffine, Rand3DElastic, RandGaussianNoise). Ogni trasformazione esiste in due forme: una che lavora su un array e una variante “dictionary-based” — per convenzione con suffisso d — che opera su un dizionario {"image": ..., "label": ...} e applica in modo coerente la stessa trasformazione spaziale a immagine e segmentazione. È il dettaglio che evita l’errore più frequente: scollare la maschera dall’immagine quando si ruota o si ritaglia.

monai.data carica i formati che servono — NIfTI, DICOM via ITK/SimpleITK, NRRD — e conserva i metadati (spacing, origine, orientamento) lungo la pipeline invece di ridurre tutto a un tensore nudo. monai.networks offre architetture pronte, fra cui implementazioni 2D/3D di U-Net e alcune varianti residuali, più i moduli primitivi (convoluzioni, unità residuali, upsampling) per costruirne di nuove. monai.losses raccoglie le loss da segmentazione — Dice, la combinazione Dice più cross-entropy, le varianti Focal e Tversky per le classi sbilanciate; monai.metrics le metriche di valutazione, sotto la stessa convenzione condivisa.

L’idea che torna è la componibilità: la pipeline è una lista di trasformazioni che si compongono, le reti si assemblano dalle primitive, il ciclo di training resta separato dal modello e dai dati. Nulla di concettualmente nuovo per chi conosce PyTorch — il valore sta nell’avere queste primitive specifiche per il dominio già scritte e in un solo posto.

Il punto critico

Il valore di MONAI sta nella convenzione condivisa che regge i componenti, più che nell’elenco dei componenti stessi. Il coefficiente di Dice e la distanza di Hausdorff sono definiti senza ambiguità solo finché tutti concordano sul trattamento dei bordi, dei voxel di sfondo e del caso degenere in cui una classe manca nella verità di riferimento. Quando ogni laboratorio scrive la propria metrica, due numeri nominalmente uguali possono non essere confrontabili. Una libreria condivisa rende quella convenzione esplicita e ispezionabile: due gruppi che usano DiceMetric calcolano davvero la stessa cosa.

Vale lo stesso per le trasformazioni geometriche. Spacing e Orientation codificano scelte — interpolazione, sistema di riferimento — che altrimenti restano implicite e quasi mai documentate negli articoli. Portarle dentro una libreria con versioni rende la dipendenza citabile: dichiarare la versione di MONAI fissa una parte del preprocessing in modo verificabile.

Il rovescio è che il valore dipende per intero dall’adozione. Una libreria comune usata da un solo laboratorio resta una libreria come tante. Nei prossimi mesi il segnale da guardare non sono le funzionalità, ma quanti gruppi esterni aprono pull request e quanti articoli dichiarano una versione di MONAI nel proprio metodo.

Implicazioni

Per chi costruisce pipeline cliniche interne il conto cambia: una parte del lavoro infrastrutturale finora ripetuto in ogni progetto diventa una dipendenza esterna mantenuta da più istituzioni. La licenza Apache 2.0 lo rende usabile anche dentro prodotti commerciali e flussi di lavoro destinati alla certificazione, senza i vincoli di uno stack proprietario — la conformità normativa di un dispositivo medico software resta tutta sulle spalle di chi lo costruisce, ma lo strato sottostante smette di essere un blocco legato a un solo fornitore.

Per la ricerca l’effetto atteso è sulla riproducibilità. Trasformazioni e cicli di training noti e versionati restringono lo spazio in cui due implementazioni “uguali” divergono in silenzio. Non elimina il problema — i dati, gli iperparametri e i pesi contano molto di più — ma toglie di mezzo una delle sue cause meno visibili.

Limiti

Alla pubblicazione MONAI è un progetto giovane, alla versione 0.1, con un’API ancora da consolidare e una documentazione in crescita: la riga 0.x va letta come avviso che le firme possono cambiare. Lo scope è la ricerca — caricamento dei dati, addestramento, valutazione — non il deployment in produzione, che resta fuori dal perimetro iniziale. Per la segmentazione pronta all’uso il riferimento sui risultati immediati restano i framework auto-configuranti come nnU-Net; MONAI chiede più configurazione a mano in cambio di componenti riusabili. E la standardizzazione, per ora, è solo un’ipotesi: una libreria diventa standard solo se la comunità la adotta, e a due mesi dall’annuncio è troppo presto per dirlo.

https://developer.nvidia.com/blog/nvidia-and-kings-college-london-announce-monai-ai-framework-for-healthcare-research/ https://www.kcl.ac.uk/news/london-ai-centre-and-nvidia-launch-monai-a-new-ai-framework-for-healthcare https://github.com/Project-MONAI/MONAI https://project-monai.github.io/ https://www.noze.it/insights/monai-imaging-ai-open/

Immagine di copertina: Slice assiale di una risonanza magnetica cerebrale con un tumore (glioblastoma) evidenziato da una maschera di segmentazione colorata… — foto di EmmaWiki2020, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Studierfenster_Brain_Tumor_Segmentation.png