CelloAI Benchmarks: Toward Repeatable Evaluation of AI Assistants

Il paper presenta CelloAI, un framework di benchmark pratici e ripetibili per valutare le prestazioni dei modelli linguistici nell'assistenza alla programmazione per la fisica delle alte energie e il calcolo ad alte prestazioni, coprendo la generazione di documentazione, la creazione di kernel GPU e l'analisi visiva dei dati.

L'essenziale

Immagina di avere un assistente personale super-intelligente (un'Intelligenza Artificiale) che ti aiuta a scrivere codice per computer. Sembra fantastico, vero? Ma c'è un problema: la maggior parte di questi assistenti è stata addestrata su compiti generici, come scrivere una ricetta o creare un sito web semplice.

Il problema è che nel mondo della Fisica delle Alte Energie (come quella usata per studiare l'universo al CERN) e dei Supercomputer, le regole sono molto più rigide. Qui, un errore non significa solo "il sito non si apre", ma potrebbe significare che i dati di un esperimento scientifico sono sbagliati o che il computer si blocca.

Gli autori di questo paper hanno creato "CelloAI", un assistente speciale progettato per questi ambienti difficili, e hanno costruito una palestra di allenamento (i benchmark) per vedere quanto è davvero bravo.

Ecco i tre "sport" principali in cui hanno messo alla prova queste intelligenze artificiali:

1. Il Traduttore di Manuali (Documentazione del Codice)

L'analogia: Immagina di avere un libro di istruzioni scritto in un linguaggio segreto, con migliaia di pagine e nessun indice. Se cambi una vite, devi aggiornare il manuale.
La sfida: L'IA deve leggere il codice e scrivere automaticamente le note a margine (i commenti) spiegando cosa fa ogni parte, usando un formato preciso (come il "Doxygen").
Il risultato:

• Le IA più vecchie o piccole erano come studenti che dimenticavano di scrivere le cose più importanti (es. "questo pulsante serve per...").
• Le IA più grandi erano molto brave a scrivere tutto quello che serviva (copertura), ma a volte le spiegazioni erano un po' vaghe o poco precise, come se qualcuno ti dicesse "questo serve per qualcosa di importante" invece di dirti esattamente cosa fa.
• Lezione: Le IA sanno copiare la struttura, ma faticano ancora a capire il "significato profondo" scientifico senza un aiuto extra.

2. Il Traduttore di Motori (Generazione e Porting del Codice)

L'analogia: Immagina di avere un'auto da corsa costruita per correre su una pista di ghiaia (il vecchio computer) e doverla trasformare per correre su una pista di ghiaccio (un nuovo tipo di processore grafico, come le GPU). Devi cambiare il motore, le gomme e la sospensioni, ma l'auto deve continuare a vincere la gara senza esplodere.
La sfida: L'IA deve prendere un pezzo di codice complesso e riscriverlo per un nuovo tipo di computer, mantenendo la precisione scientifica.
Il risultato:

• Per i compiti semplici (come "azzera la memoria"), l'IA ci riusciva quasi sempre.
• Per i compiti medi (contare i pezzi), faceva qualche errore.
• Per il compito più difficile (il "motore" principale della simulazione), l'IA falliva quasi sempre. Anche le IA più potenti facevano fatica a gestire la complessità senza rompere qualcosa.
• Lezione: Quando si tratta di compiti critici e complessi, l'IA da sola non basta. Ha bisogno di un "tutor" (il sistema CelloAI) che le mostri il contesto e le regole del gioco per non fare disastri.

3. L'Osservatore di Grafici (Analisi Dati Visiva)

L'analogia: Immagina di avere 10.000 grafici che mostrano l'andamento del tempo. Un umano impiegherebbe giorni a trovarne uno strano. L'IA deve guardare questi grafici e dire: "Ehi, qui c'è un picco che non dovrebbe esserci!".
La sfida: L'IA deve "vedere" i grafici (non solo leggere i numeri) e capire se c'è un errore o una scoperta.
Il risultato:

• Alcune IA (come quelle basate su modelli visivi avanzati) riuscivano a vedere le differenze, ma spesso con poca precisione (come un bambino che indica "qualcosa è cambiato" ma non sa dire cosa).
• Altre IA non vedevano proprio nulla.
• Lezione: Far capire a un'IA la differenza tra un errore di calcolo e una nuova scoperta scientifica è ancora molto difficile. Serve un occhio più esperto.

Il Verdetto Finale

Questo paper ci dice che l'Intelligenza Artificiale per la scienza è promettente, ma non è ancora un "pilota automatico" completo.

• È brava a fare il lavoro di "segretario" (scrivere note).
• È brava a fare piccoli aggiustamenti.
• Ma quando si tratta di costruire il cuore di un sistema scientifico complesso, ha ancora bisogno di supervisione umana e di strumenti che le diano il contesto giusto.

Gli autori hanno creato questi test per assicurarsi che, prima di affidare a un'IA la sicurezza di un esperimento scientifico, sappiamo esattamente dove sbaglia e dove riesce. È come avere una prova pratica prima di assumere un nuovo dipendente per un lavoro pericoloso: non basta che sia intelligente, deve dimostrare di saper lavorare sotto pressione senza rompere nulla.

Sommario tecnico

Titolo: CelloAI Benchmarks: Verso una Valutazione Ripetibile degli Assistenti AI

1. Il Problema

I Large Language Models (LLM) stanno diventando strumenti sempre più utilizzati per lo sviluppo software, ma le attuali metriche di benchmarking per l'assistenza alla codifica non riflettono le specifiche e stringenti esigenze della fisica delle alte energie (HEP) e del calcolo ad alte prestazioni (HPC).

• Limiti delle valutazioni attuali: I benchmark esistenti si concentrano su compiti di codifica generale o su correzioni guidate da test unitari in ambienti isolati. Non catturano la complessità dei grandi repository scientifici, che richiedono:
  • Integrazione in codebase massive con dipendenze complesse.
  • Rispetto dei vincoli scientifici (intento fisico, stabilità numerica).
  • Gestione di architetture eterogenee (es. CPU-GPU) dove errori di traduzione o gestione dei dati possono invalidare i risultati scientifici o degradare le prestazioni.
• Mancanza di contesto: L'adozione pratica è ostacolata dalla difficoltà di fornire ai modelli un contesto sufficiente per navigare in codebase scarsamente documentate e sparse.

2. Metodologia e Framework

Il paper introduce CelloAI, un assistente di codifica basato su retrieval-augmented generation (RAG) ospitato localmente, progettato specificamente per i flussi di lavoro scientifici HPC. Il sistema si basa su tre pilastri fondamentali:

1. RAG Scientifico: Recupero di contesto sia da testi scientifici che da codice sorgente.
2. Chunking Consapevole della Sintassi: Frammentazione del codice che preserva i confini semantici per evitare recuperi frammentati.
3. Prompt Enhancement Consapevole del Callgraph: Arricchimento del prompt con informazioni sulle dipendenze (chi chiama chi) per garantire che le risposte rispettino il flusso di esecuzione reale.

Per valutare l'efficacia di CelloAI e dei modelli sottostanti, gli autori hanno sviluppato una suite di benchmark ripetibili e automatizzati divisa in tre tracce di valutazione:

• A. Documentazione del Codice (CelloAI-Doc-Bench):

  • Obiettivo: Valutare la capacità di generare commenti strutturati in stile Doxygen.
  • Metriche:
    • Punteggio di Copertura (Tag-based): Estensione dello score F1 a livello di tag (@param, @return) per misurare completezza e precisione strutturale.
    • Similarità Semantica: Utilizza l'embedding vettoriale e la similarità del coseno per misurare la coerenza tra descrizioni di funzioni correlate (Caller-Callee) e la vicinanza semantica rispetto alla documentazione scritta da esperti umani.
  • Dataset: Funzioni del pacchetto ATLAS Athena (es. FastCaloSim).

• B. Generazione e Porting del Codice (CelloAI-Code-Bench):

  • Obiettivo: Valutare l'usabilità end-to-end nel porting di kernel GPU (da CUDA a OpenMP/SYCL) mantenendo correttezza e prestazioni.
  • Dataset: Tre kernel del workflow FastCaloSim: Reset (inizializzazione array), Count (identificazione hit e atomiche), Simulate (calcolo complesso con accumulo atomico e trasferimento dati).
  • Valutazione: Pipeline automatizzata che tenta di compilare, eseguire e validare il codice generato. Un trial è considerato riuscito solo se supera tutti i controlli di integrazione.

• C. Analisi di Dati Grafici (CelloAI-Multimodal-Bench):

  • Obiettivo: Valutare i LLM multimodali nella capacità di analizzare istogrammi sintetici tipici degli esperimenti HEP.
  • Task: Rilevare discrepanze tra curve di riferimento e monitorate, e identificare i punti anomali (outliers).
  • Output: JSON strutturato con intervalli di discrepanza e punti anomali, valutati tramite Precision, Recall e F1 rispetto al ground truth.

3. Risultati Chiave

• Documentazione (Doc-Bench):

  • I modelli più recenti (es. GPT-oss-120b) raggiungono un recall molto alto (1.0) e un F1 elevato (0.96) nella copertura dei tag, indicando che riescono a includere tutti i parametri richiesti.
  • Tuttavia, la qualità semantica rimane limitata. La similarità con la documentazione degli esperti è moderata (~0.60), suggerendo che i modelli faticano a catturare l'intento scientifico profondo senza un addestramento specifico di dominio.
  • L'uso del contesto CelloAI migliora marginalmente le metriche, ma non risolve completamente il problema della coerenza semantica.

• Generazione Codice (Code-Bench):

  • Esiste una forte correlazione tra complessità del kernel e successo:
    • Kernel 1 (Reset): Alta percentuale di successo (fino a 10/10 con CelloAI).
    • Kernel 2 (Count): Successo moderato, dipende dalla corretta gestione delle operazioni atomiche.
    • Kernel 3 (Simulate): Fallimento quasi totale. Anche i modelli migliori riescono a portarlo con successo solo in 1-2 casi su 10. Questo evidenzia che la generazione end-to-end di kernel scientifici complessi, che richiedono coerenza tra memoria, dipendenze e logica fisica, è ancora un problema irrisolto.
  • Il contesto CelloAI migliora significativamente i risultati sui kernel semplici rispetto alla baseline RAG, ma non risolve le difficoltà del kernel di simulazione.

• Analisi Grafica (Multimodal-Bench):

  • I risultati sono moderati. Il modello InternVL 3.5 8B mostra le migliori prestazioni nel rilevamento degli outlier (F1 ~0.57) a temperature basse.
  • Qwen3-VL mantiene una performance costante ma non eccellente (F1 ~0.5).
  • Gemma-3n fallisce nel rilevare qualsiasi outlier ground truth.
  • La capacità di identificare correttamente le regioni di discrepanza degrada all'aumentare della temperatura di generazione, indicando una necessità di modelli multimodali più capaci o adattati al dominio.

4. Contributi Principali

1. Framework di Benchmarking Ripetibile: Introduzione di una suite di test standardizzati e automatizzati specifici per HEP/HPC, spostando il focus da impressioni qualitative a metriche quantitative.
2. Definizione di Nuove Metriche: Sviluppo di metriche ibride (strutturali + semantiche) per la documentazione e metriche di validazione end-to-end (compilazione + esecuzione) per la generazione di codice, superando i limiti dei semplici test unitari.
3. Identificazione dei Modelli di Fallimento: Il paper dimostra chiaramente che, mentre i LLM sono competenti nella struttura del codice e nei task semplici, falliscono sistematicamente su task scientifici complessi che richiedono una profonda comprensione delle dipendenze, della fisica sottostante e della stabilità numerica.
4. Valutazione Multimodale: Estensione della valutazione degli assistenti AI all'analisi visiva di dati scientifici (istogrammi), un aspetto spesso ignorato ma cruciale per il ciclo di sviluppo scientifico.

5. Significato e Prospettive Future

Questo lavoro è fondamentale per guidare lo sviluppo di assistenti AI affidabili per la scienza. Dimostra che l'adozione di LLM in ambienti HPC non può basarsi su capacità generiche, ma richiede:

• Adattamento al Dominio: Necessità di modelli fine-tuned o RAG avanzati per comprendere vincoli scientifici specifici.
• Validazione Rigorosa: L'importanza di testare non solo la sintassi, ma l'integrazione e l'esecuzione reale del codice.
• Trasparenza: La creazione di benchmark aperti permette confronti equi tra modelli e strategie, accelerando la ricerca su metodi che migliorino l'affidabilità.

In futuro, gli autori intendono espandere la suite a più modelli (open e closed), includere task più diversificati e repository reali, consolidando così una base solida per misurare i progressi verso assistenti di codifica "consapevoli della scienza".