💻 computer science

A Study of LLMs' Preferences for Libraries and Programming Languages

Questo studio empirico rivela che i modelli linguistici di grandi dimensioni mostrano una forte tendenza a privilegiare librerie e linguaggi popolari come NumPy e Python, spesso a scapito della pertinenza e dell'ottimalità per il compito specifico, evidenziando la necessità di un addestramento mirato e di benchmark più accurati.

Autori originali: Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

Pubblicato 2026-04-09

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina che i Modelli Linguistici (LLM) siano come dei cuochi robot incredibilmente bravi, che hanno letto quasi tutti i libri di cucina del mondo (i dati di addestramento) e possono preparare qualsiasi piatto che gli chiedi.

Questo studio si chiede: "Quando questi cuochi robot ricevono un ordine, scelgono gli ingredienti e il tipo di cucina in base a ciò che è meglio per il piatto, o scelgono solo ciò che conoscono e amano di più?"

Ecco cosa hanno scoperto gli scienziati, spiegato con delle metafore:

1. Il "Tutto e Sempre" di NumPy (L'ingrediente preferito)

Immagina di chiedere a un cuoco di preparare un'insalata semplice. Un cuoco esperto userebbe solo un coltello e un po' di sale.
Ma questi cuochi robot? Mettono sempre il mixer industriale, la bilancia di precisione e il forno a microonde, anche se non servono.

Cosa hanno scoperto: I modelli tendono a usare ossessivamente librerie famose come NumPy (uno strumento potente per calcoli matematici), anche quando il compito è banale e non ne ha bisogno.
La statistica: In quasi il 45% dei casi, usano questi "super-strumenti" quando non dovrebbero. È come usare un aereo per andare a comprare il pane: funziona, ma è uno spreco e complica le cose.

2. L'ossessione per la Python (La cucina italiana)

Immagina di chiedere a un cuoco di preparare un piatto veloce per un'auto da corsa (che richiede materiali leggeri e veloci).
Il cuoco robot, invece di usare alluminio o fibra di carbonio, ti risponde: "Facciamo tutto in legno massiccio!" (ovvero, usano il linguaggio di programmazione Python).

Cosa hanno scoperto: Anche quando il compito richiede velocità estrema, sicurezza o prestazioni elevate (dove linguaggi come Rust o C++ sarebbero perfetti), i robot scelgono Python nel 58% dei casi.
Il paradosso: È come se il cuoco dicesse: "So che questo legno non regge la velocità, ma è il legno che conosco meglio, quindi lo uso lo stesso". Non usano affatto Rust (il materiale perfetto per le auto da corsa) in nessuna delle prove.

3. La "Sindrome del Vecchio Amico" (Le librerie obsolete)

I cuochi robot amano le ricette vecchie di 10 anni, anche se esistono nuove ricette più veloci e moderne.

Esempio: Se devi fare un sito web veloce, usano un vecchio framework (Flask) invece di uno nuovo e più efficiente (FastAPI), anche se quest'ultimo è in crescita esplosiva.
Il risultato: I robot ignorano le novità. Se una libreria è "vecchia e famosa", la usano. Se è "nuova e promettente", la ignorano. Questo blocca l'innovazione, perché tutti iniziano a usare le stesse cose vecchie.

4. Il "Doppio Pensiero" (Cosa dicono vs. Cosa fanno)

Questa è la parte più curiosa.
Se chiedi al cuoco: "Qual è il miglior ingrediente per questo piatto?", lui ti dirà la verità: "Usa il metallo leggero!".
Ma quando inizia a cucinare davvero, prende il legno.

Cosa hanno scoperto: Le raccomandazioni che i robot danno a voce (o in testo) sono spesso diverse da ciò che scrivono nel codice. Sono incoerenti. Se ti fidassi ciecamente delle loro parole, sceglieresti la tecnologia giusta; se guardassi il loro lavoro, scopriresti che hanno scelto la via più facile e familiare.

Perché è importante?

Immagina un mondo in cui tutti i nuovi edifici vengono costruiti con mattoni pesanti e vecchi, solo perché i robot architetti li conoscono meglio, anche se esistono materiali più leggeri e sicuri.

Il rischio: Il software diventa lento, meno sicuro e meno vario.
La soluzione: Dobbiamo insegnare a questi robot a non essere "pigri" o "conservatori". Dobbiamo addestrarli a scegliere lo strumento giusto per il lavoro, non solo quello che hanno visto più spesso nei loro libri di testo.

In sintesi: Questi robot sono bravissimi a scrivere codice, ma sono un po' "testardi". Preferiscono la comodità e la familiarità (usare sempre Python e le stesse vecchie librerie) rispetto a trovare la soluzione migliore e più innovativa per il compito specifico. Il nostro lavoro è insegnar loro a essere più aperti e adatti al contesto.

Titolo dello Studio

Uno studio sulle preferenze dei LLM per librerie e linguaggi di programmazione

1. Il Problema

Nonostante i rapidi progressi dei Modelli Linguistici su larga scala (LLM) nella generazione di codice, le valutazioni esistenti si concentrano prevalentemente sulla correttezza funzionale o sulla validità sintattica. Questo approccio trascura un aspetto critico del processo decisionale: come gli LLM scelgono quali librerie e quali linguaggi di programmazione utilizzare.

Queste preferenze possono avere effetti tangibili sulle prestazioni del software, sull'efficienza, sulla manutenibilità e sulla diversità dell'ecosistema. Se gli LLM tendono a favorire tecnologie dominanti (come Python o librerie consolidate) ignorando alternative più adatte al contesto specifico, rischiano di creare un ciclo di feedback che riduce la diversità tecnologica e porta a scelte subottimali o insicure.

2. Metodologia

Gli autori hanno condotto il primo studio empirico sistematico sulle preferenze di otto LLM di livello produttivo (sia open-source che closed-source, tra cui GPT-4o-mini, Claude 3.5, Llama-3.2, Mistral, Qwen-2.5-Coder e DeepSeek). Lo studio è stato strutturato in tre esperimenti principali:

Esperimento 1: Preferenze per le Librerie
- Obiettivo: Misurare quali librerie esterne gli LLM scelgono quando non vengono specificate nel prompt.
- Dataset: Utilizzo di BigCodeBench (525 task in Python, filtrati per rimuovere riferimenti espliciti alle librerie) e 5 task di inizializzazione di progetti realistici (database, deep learning, calcolo distribuito, web scraper, server web).
- Metodo: Generazione di 3 risposte indipendenti per task. Analisi della frequenza di importazione delle librerie e confronto con le soluzioni "ground truth".
Esperimento 2: Preferenze per i Linguaggi di Programmazione
- Obiettivo: Valutare la scelta del linguaggio quando il prompt non lo specifica.
- Dataset: Set di benchmark agnostici rispetto al linguaggio (Multi-HumanEval, MBXP, AixBench, CoNaLa, APPS, CodeContests) e task di inizializzazione di progetti in domini dove Python è considerato subottimale (es. server web concorrenti, interfacce grafiche, trading a bassa latenza).
- Metodo: Analisi della distribuzione dei linguaggi generati, con particolare attenzione ai casi in cui Python non è la scelta ideale.
Esperimento 3: Coerenza delle Raccomandazioni
- Obiettivo: Verificare se le raccomandazioni fornite in linguaggio naturale (NL) dagli LLM corrispondono alle tecnologie che effettivamente utilizzano nella generazione del codice.
- Metodo: Confronto tra il ranking delle tecnologie raccomandate in NL e il ranking delle tecnologie effettivamente usate, misurato tramite il coefficiente di correlazione di rango di Kendall's $\tau_b$ .

3. Risultati Chiave

Sovrautilizzo di Librerie Consolidate:
- Gli LLM mostrano una forte tendenza a preferire librerie ben consolidate (es. NumPy, pandas, Matplotlib) rispetto ad alternative più moderne o performanti.
- In fino al 45% dei casi di benchmark, l'uso di librerie come NumPy non era richiesto dalla soluzione corretta (ground truth), indicando un sovrautilizzo sistematico.
- Per i task di inizializzazione di progetti, le librerie più vecchie dominano: ad esempio, Flask (2010) è stato usato nell'88% delle risposte per i server web, mentre FastAPI (2018), pur avendo una crescita maggiore, è stato usato solo nel 9%.
Bias verso Python:
- Esiste una preferenza significativa per Python come linguaggio predefinito.
- Nei task di benchmark, Python è stato usato nel 90-97% delle soluzioni.
- Anche in scenari dove Python è chiaramente subottimale (es. elaborazione parallela, trading ad alta frequenza, applicazioni di sistema), Python rimane la scelta dominante nel 58% dei casi. Linguaggi come Rust non sono stati utilizzati affatto in alcuni di questi contesti critici.
Incoerenza tra Raccomandazioni e Azioni:
- C'è una bassa coerenza tra ciò che gli LLM raccomandano in linguaggio naturale e ciò che effettivamente codificano.
- Per i task di inizializzazione di progetti, gli LLM contraddicono le proprie raccomandazioni linguistiche nell'83% dei casi. Le raccomandazioni in NL sono un segnale debole per prevedere il codice generato.
Omogeneità tra Modelli:
- Nonostante le differenze architetturali, tutti gli LLM studiati mostrano preferenze molto simili, suggerendo che il bias deriva da fonti di dati di addestramento comuni (es. repository GitHub) o da strategie di allineamento post-training.

4. Contributi Principali

Primo Studio Empirico: Fornisce la prima misurazione quantitativa delle preferenze di LLM per librerie e linguaggi, evidenziando la tendenza a favorire l'adozione di tecnologie consolidate rispetto a quelle ottimali per il compito.
Analisi dell'Impatto sull'Ecosistema: Discute le implicazioni di questi bias, che possono ridurre la diversità degli strumenti software, creare cicli di feedback nei dati di addestramento futuri e portare a scelte di sicurezza o prestazioni subottimali.
Rilascio Open Source: Il codice, i dataset e i risultati completi sono stati resi pubblici su GitHub per favorire ulteriori ricerche e la creazione di benchmark che misurino esplicitamente la fedeltà nella selezione di linguaggi e librerie.

5. Significato e Implicazioni

Lo studio evidenzia che gli LLM tendono a privilegiare la familiarità e la popolarità rispetto alla idoneità e all'ottimalità specifica del compito.

Rischi: L'omogeneizzazione delle scelte tecnologiche può ostacolare l'innovazione, rendere il software meno performante in contesti critici (es. sistemi embedded o ad alta frequenza) e ridurre la scoperta di librerie emergenti.
Opportunità: Comprendere questi bias è fondamentale per migliorare la progettazione dei modelli, diversificare i dati di addestramento e sviluppare strategie di allineamento che incoraggino scelte più contestuali.
Raccomandazioni: Gli autori chiedono la creazione di nuovi benchmark che valutino non solo la correttezza del codice, ma anche la qualità delle decisioni architetturali (scelta del linguaggio e delle dipendenze) e la necessità di tecniche di fine-tuning mirate per mitigare questi bias.

In sintesi, lo studio mette in guardia contro l'uso acritico degli LLM per la generazione di codice, sottolineando la necessità di supervisione umana e di modelli più consapevoli del contesto per garantire la diversità e l'efficienza dell'ecosistema software futuro.