Comparing Developer and LLM Biases in Code Evaluation

1. Il Problema

Con l'aumento dell'uso dei Large Language Models (LLM) come "giudici" automatici per valutare l'output del codice, è emersa la necessità di metodi di valutazione affidabili che riflettano scenari reali. La ricerca attuale si basa spesso su setting statici (es. repository GitHub ben mantenuti o compiti di programmazione competitiva), che non catturano le condizioni disordinate, parzialmente contestualizzate e ambigue in cui gli sviluppatori reali lavorano e affinano il codice.

Il problema centrale è: quali bias mostrano i giudici LLM quando valutano il codice e come si confrontano con le preferenze degli sviluppatori umani? Gli autori ipotizzano che esistano discrepanze sistematiche tra come i modelli valutano la qualità del codice e come gli sviluppatori umani la percepiscono in contesti pratici (completamento, modifica istruita, chat).

2. Metodologia: Il Framework TRACE

Gli autori presentano TRACE (Tool for Rubric Analysis in Code Evaluation), un framework progettato per valutare e interpretare i giudici basati su LLM in flussi di lavoro realistici. TRACE opera in tre fasi principali:

1. Misurazione dell'Allineamento:

   • Vengono raccolti dataset di preferenze umane (coppie di risposte $y_A, y_B$ con un'etichetta binaria $w$ indicante la scelta umana).
   • I giudici LLM vengono interrogati per scegliere la risposta migliore tra le due.
   • Viene calcolata l'accuratezza complessiva e l'accuratezza "posizionalmente consistente" (per correggere il bias di posizione, ovvero la tendenza a preferire la prima o la seconda opzione indipendentemente dal contenuto).

2. Identificazione Automatica dei Criteri (Rubric Items):

   • Per spiegare le divergenze tra umani e modelli, TRACE estrae automaticamente criteri di valutazione ("rubric items").
   • Utilizza un approccio ibrido:
     • Generazione LLM: Un modello analizza le differenze tra le coppie di risposte per estrarre assi di variazione comportamentale (ispirato a VibeCheck).
     • Annotazione Umana: Gli ingegneri forniscono giustificazioni per le loro scelte, che vengono poi astratte in criteri generali.
   • Questi criteri vengono aggregati in un set di rubriche interpretabili (es. "Gestione degli errori", "Chiarezza dei commenti", "Robustezza").

3. Analisi dei Bias e Misurazione della Disallineazione:

   • Vengono costruiti vettori di caratteristiche basati sui punteggi delle rubriche per ogni campione.
   • Vengono addestrati modelli di regressione logistica separati per le preferenze umane e per ciascun giudice LLM, utilizzando i punteggi delle rubriche come input.
   • Confrontando i coefficienti appresi ($\beta_H$ per gli umani, $\beta_J$ per il giudice), il framework quantifica quanto un giudice sovrappesa o sottopesa un determinato criterio rispetto agli umani. Una differenza significativa nei coefficienti indica un bias sistematico.

3. Set di Dati e Sperimentazione

Lo studio è stato condotto su tre modalità di interazione rappresentative identificate nelle tassonomie di sviluppo software:

1. Completamento del codice (Code Completion): Basato su Copilot Arena (VSCode extension).
2. Modifica del codice istruita (Instructed Code Edits): Basato su EDIT-Bench (modifiche a regioni di codice con istruzioni).
3. Chat-based Coding: Basato su Chatbot Arena (filtrato per esempi specifici di codice).

Modelli Valutati:
Sono stati testati 13 giudici LLM diversi, inclusi:

• Modelli generici di terze parti (GPT-5, GPT-4o, DeepSeek-R1, Llama-3.1, Claude Sonnet 4).
• Modelli specializzati per la valutazione (Prometheus 2, Atla Selene, Skywork Critic).
• Modelli di ricompensa (PairRM, GRM).

4. Risultati Chiave

• Sottoperformance dei Giudici LLM:

  • I migliori giudici LLM sottoperformano sistematicamente rispetto agli annotatori umani aggregati. Il gap di accuratezza varia dal 12% al 23% attraverso tutte le modalità.
  • Non esiste un singolo modello che domini costantemente.
  • I modelli "fine-tuned" specifici per la valutazione non superano in modo affidabile i modelli generici, suggerendo che i problemi attuali non sono risolvibili solo con più dati di training o specializzazione.

• Disallineamento sui Criteri di Qualità (Rubric Misalignment):

  • Sono stati identificati 35 punti di disallineamento significativi tra umani e giudici.
  • Completamento: I giudici tendono a sovrappesare la "correttezza funzionale e logica" e a sottopesare la "chiarezza e l'esplicitazione". Gli umani preferiscono codice più chiaro e ben documentato anche se leggermente meno conciso logicamente.
  • Chat: I giudici premiano spiegazioni generiche e chiare, mentre gli umani preferiscono soluzioni consapevoli del dominio specifico e adattate al contesto, penalizzando le spiegazioni eccessive.
  • Modifiche: I giudici trattano le modifiche come compiti di soddisfacimento dei vincoli (focus sulla correttezza minima), mentre gli umani vedono le modifiche come opportunità per migliorare la qualità complessiva (struttura, leggibilità).

• Disallineamento su Criteri Ingegneristici Consolidati:

  • Anche su 11 temi ricorrenti che corrispondono a criteri ingegneristici canonici (es. correttezza sintattica, formattazione, robustezza), i giudici LLM mostrano disallineamenti significativi in 6 su 11 casi.
  • Ad esempio, nella chat, i giudici sono biasati verso spiegazioni più lunghe, mentre gli sviluppatori preferiscono spiegazioni più brevi e contestuali.

• Bias Posizionale:

  • I modelli linguistici mostrano un forte bias posizionale (preferenza per la prima o seconda risposta), con un divario tra accuratezza complessiva e accuratezza posizionalmente consistente che varia dall'8% al 45% per i modelli fine-tuned. I modelli di ricompensa, essendo invarianti all'ordine, non mostrano questo problema.

5. Contributi e Significato

• Framework TRACE: Fornisce un metodo sistematico non solo per misurare se un giudice sbaglia, ma perché sbaglia, decomponendo le decisioni in criteri interpretabili.
• Evidence di Bias Sistematici: Dimostra che i giudici LLM attuali non catturano le sfumature del "buon codice" in contesti reali, privilegiando metriche superficiali o facilmente verificabili (come la lunghezza o la logica isolata) rispetto a fattori contestuali (come la leggibilità in un file esistente o l'adattamento al dominio).
• Implicazioni per l'Addestramento: I risultati suggeriscono che le strategie attuali di allineamento (RLHF, fine-tuning su preferenze) non sono sufficienti a colmare il divario con le preferenze umane in scenari di ingegneria del software complessi.
• Direzioni Future: Il paper propone che il futuro dell'automazione nella valutazione del codice richieda:
  • Calibrazione consapevole delle rubriche.
  • Obiettivi di addestramento condizionati alle rubriche (invece di un punteggio unico).
  • Selezione mirata dei dati di training su esempi che esponevano fallimenti critici nelle rubriche.

In sintesi, il paper evidenzia che l'uso di LLM come giudici nel ciclo di sviluppo software è attualmente limitato da bias sistematici che li allontanano dalle preferenze reali degli sviluppatori, rendendo necessario un approccio più sofisticato e interpretabile per la valutazione automatica.