LLM Code Smells: A Taxonomy and Detection Approach

Titolo: LLM Code Smells: Una Tassonomia e un Approccio di Rilevamento

Enunciato del Problema
I Large Language Models (LLM) sono sempre più integrati nei sistemi software per la loro versatilità e capacità di ragionamento. Tuttavia, la loro natura non deterministica e i modelli di interazione distinti (ad esempio, prompt in linguaggio naturale, fatturazione basata sui token) introducono nuovi rischi quando vengono integrati nel codice sorgente. Pratiche di integrazione scadenti possono compromettere gli attributi di qualità del software come manutenibilità, affidabilità, prestazioni e robustezza. Sebbene lavori precedenti abbiano affrontato difetti generali nei sistemi LLM o "odori" nel codice generato dagli LLM, mancava un concetto dedicato alle pratiche di codifica scadenti nel codice sorgente scritto da umani che orchestra l'inferenza degli LLM. Questo articolo colma tale lacuna definendo, catalogando e rilevando gli "LLM code smells".

Metodologia
Lo studio segue una metodologia in tre fasi:

1. Costruzione del Catalogo: Gli autori hanno costruito un catalogo degli LLM code smells triangolando le evidenze da tre fonti:

   • Revisione Sistematica della Letteratura: Una revisione guidata da PRISMA della letteratura sottoposta a revisione paritaria (2017–2025) che identifica problemi di integrazione e abusi.
   • Estrazione di Letteratura Grigia ed Empirica: Utilizzo dello strumento GLiSE per estrarre e filtrare rapporti di professionisti, documentazione ufficiale, issue di GitHub e blog ingegneristici per catturare pratiche reali non ancora presenti nella letteratura accademica.
   • Sintesi: Gli odori candidati sono stati mantenuti se osservabili a livello di codice, supportati da più fonti e associati a una strategia di rimedio.

2. Approccio di Rilevamento (SpecDetect4LLM):

   • Gli autori hanno sviluppato SpecDetect4LLM, uno strumento di analisi statica del codice sorgente derivato dal framework esistente SpecDetect4AI.
   • Lo strumento utilizza un Linguaggio Specifico di Dominio (DSL) per definire regole dichiarative sull'Albero Sintattico Astratto (AST) dei file Python.
   • Si concentra sull'analisi intra-file, basandosi su evidenze recuperabili localmente (struttura delle chiamate, argomenti, variabili locali) per rilevare gli odori senza richiedere una complessa ricostruzione del flusso di dati inter-procedurale, garantendo così la scalabilità.

3. Valutazione Empirica:

   • Corpus: Un dataset di 692 sistemi open-source che integrano LLM, comprendente 171.194 file sorgente Python.
   • Verità Fondamentale (Ground Truth): Un campione casuale stratificato di 381 file è stato annotato manualmente da sette esperti per stabilire una verità fondamentale per la convalida del rilevamento.
   • Metriche: L'efficacia dello strumento è stata misurata utilizzando precisione, richiamo (recall) e punteggio F1.

Contributi Chiave

1. Tassonomia e Catalogo: L'articolo presenta una tassonomia consolidata di nove LLM code smells, categorizzati in tre gruppi:

   • Struttura o Utilizzo dell'API: Problemi relativi alla composizione della richiesta (ad esempio, No System Message, Anonymous Inference Call).
   • Semantica dei Dati: Problemi riguardanti la validità e la struttura degli input/output (ad esempio, No Structured Output, Raw Vision Payload).
   • Protocollo: Problemi concernenti i contratti di inferenza a livello di sistema e la stabilità (ad esempio, Unbounded Max Metrics, LLM Temperature Not Explicitly Set, No Model Version Pinning, Reasoning Effort Not Explicitly Set, Overspecified Sampling Parameters).
   • Nota: Cinque odori sono stati introdotti in questo articolo (segnalati con *), ampliando un precedente catalogo preliminare di cinque.

2. Strumento di Rilevamento: Il rilascio di SpecDetect4LLM, un analizzatore statico in grado di rilevare questi nove odori nel codice Python.

3. Studio Empirico su Larga Scala: Una valutazione completa della prevalenza di questi odori in 692 progetti e una valutazione dell'accuratezza del rilevamento dello strumento.

Risultati

• Efficacia del Rilevamento: Sul set annotato di 381 file, SpecDetect4LLM ha raggiunto una precisione macro-media del 91,3% e un richiamo macro-medio del 71,8%. La precisione micro-media era dell'85,5% e il richiamo del 76,9%.
  • È stata osservata un'alta precisione per odori come No System Message (100%), Raw Vision Payload (100%) e Overspecified Sampling Parameters (100%).
  • Un richiamo inferiore per alcuni odori (ad esempio, Unbounded Max Metrics al 56,2%) è stato attribuito alla portata intra-file dello strumento; i falsi negativi si sono verificati spesso quando i vincoli erano imposti tramite wrapper inter-modulo o configurazioni runtime non visibili nel singolo file analizzato.
• Prevalenza: Gli LLM code smells si sono rivelati diffusi.
  • Il 73,5% dei progetti analizzati conteneva almeno un LLM code smell.
  • Il 4,32% dei file sorgente totali è stato segnalato.
  • L'odore più prevalente è stato No Model Version Pinning (NMVP), che ha interessato il 55,06% dei progetti, seguito da LLM Temperature Not Explicitly Set (43,93%) e No Structured Output (43,64%).
  • Gli odori relativi al protocollo (NMVP, TNES, UMM, RENES) hanno rappresentato quasi l'80% di tutte le occorrenze rilevate, indicando che la mancanza di esplicitazione nei contratti di invocazione a livello di sistema è il rischio dominante.

Significato e Affermazioni
L'articolo afferma che gli LLM code smells rappresentano una categoria distinta e critica di problemi di qualità del software specifici per l'integrazione degli LLM. Fornendo una tassonomia autonoma e uno strumento di rilevamento, gli autori mirano a:

• Aiutare gli sviluppatori a riconoscere e mitigare i rischi di integrazione che degradano l'affidabilità e la manutenibilità del sistema.
• Stabilire un vocabolario comune per discutere i difetti di integrazione.
• Dimostrare che, sebbene questi problemi siano pervasivi (interessando la maggior parte dei progetti open-source), sono spesso concentrati in moduli di integrazione specifici, suggerendo che un rimedio mirato (ad esempio, centralizzare le factory dei client) potrebbe essere altamente efficace.

Gli autori riconoscono le limitazioni, in particolare riguardo all'incapacità dello strumento di rilevare odori che dipendono dal flusso di dati inter-file o dalla configurazione runtime, e alla possibilità che certi odori diventino obsoleti con l'evoluzione delle API degli LLM. Tuttavia, sostengono che i principi sottostanti (ad esempio, la necessità di versionamento esplicito o output strutturato) rimangano rilevanti anche quando cambiano le implementazioni specifiche delle API.