Bias in the Loop: Auditing LLM-as-a-Judge for Software Engineering

1. Il Problema

L'uso dei Modelli Linguistici di Grande Dimensione (LLM) come "giudici" per valutare artefatti di codice (come generazione, riparazione e generazione di test) è diventato una pratica comune nello sviluppo software, specialmente nei flussi di lavoro agentic dove la revisione umana o la copertura dei test eseguibili non sono fattibili. Tuttavia, la ricerca attuale manca di una valutazione sistematica dell'affidabilità e dei pregiudizi (bias) di questi giudici.

Il problema centrale identificato è che le decisioni dei giudici LLM sono estremamente sensibili a cues (segnali) presenti nel prompt, anche quando il codice sottostante e la verità fondamentale (ground truth) rimangono invariati. Piccole modifiche nel prompt (come l'ordine di presentazione, la verbosità, o l'aggiunta di citazioni di autorità) possono alterare drasticamente il verdetto. Questo compromette la validità, la riproducibilità e l'equità delle valutazioni nel settore dell'Ingegneria del Software (SE), rendendo i risultati fragili e manipolabili.

2. Metodologia

Gli autori adottano un approccio "measurement-first" (basato sulla misurazione) per analizzare due regimi di giudizio puntuale su tre compiti principali:

1. Generazione di Codice (Code Generation)
2. Riparazione del Codice (Code Repair)
3. Generazione di Test Unitari (Unit Test Generation)

Modelli e Dataset

• Modelli Giudice: Sono stati testati tre modelli rappresentativi:
  • Qwen3-4B: Un modello open-source generico.
  • Qwen2.5-Coder-3B: Un modello open-source specializzato nel codice.
  • GPT (versione API): Un modello proprietario chiuso.
• Dataset: Utilizzo di CodeJudgeBench, che contiene 5.352 coppie di risposte (una corretta/gold e una errata) suddivise per difficoltà (Facile, Medio, Difficile).

Design Sperimentale

Lo studio si concentra su due domande di ricerca (RQ):

• RQ1 (Sensibilità al Bias): Quanto cambiano i risultati del giudizio quando vengono introdotti bias espliciti nel prompt?
• RQ2 (Affidabilità Test-Retest): Quanto è coerente il giudizio dello stesso modello sullo stesso caso ripetuto più volte con prompt e rubriche identiche?

Per RQ1, sono stati progettati 12 tipi di bias specifici per il codice, adattati dalla letteratura NLP ma contestualizzati per l'ingegneria del software:

• Posizione: Ordine di presentazione (A prima vs B prima).
• Autorità: Citazione di standard o guide (es. "PEP 8").
• Bandwagon: Affermazioni sulla preferenza della maggioranza.
• Chain-of-Thought (CoT): Inclusione di ragionamenti passo-passo.
• Distrazione: Cues professionali non pertinenti alla correttezza funzionale.
• Stile/Diversità: Preferenze stilistiche (es. "Pythonic").
• Solo Finale: Giustificazioni confidenti ma potenzialmente errate.
• Nome del Modello: Provenienza tecnica (es. "Prodotto da AlphaCode").
• Raffinato: Etichetta di "versione raffinata".
• Auto-rafforzamento (Self-enhance): Indicare che la risposta proviene dalla stessa famiglia del modello giudice.
• Sentiment: Tono assertivo vs esitante.
• Verbosità: Lunghezza eccessiva delle spiegazioni.

Per ogni item, il giudizio è stato eseguito in condizioni di controllo (no-bias) e sotto ciascuna delle 12 condizioni di bias, misurando l'accuratezza micro-averaged e il tasso di coerenza.

3. Risultati Chiave

Sensibilità al Bias (RQ1)

• Impatto Drastico: Le decisioni dei giudici sono altamente sensibili ai bias del prompt. Quando un bias favorisce la risposta corretta, l'accuratezza aumenta significativamente; quando favorisce quella errata, crolla.
• Effetto Posizione: Esiste un forte effetto di ordine. Ad esempio, per Qwen2.5-Coder-3B, l'accuratezza di base è molto più alta quando la risposta corretta è in posizione A (prima) rispetto a B (seconda).
• Bias Specifici:
  • CoT, Autorità, Sentiment, Raffinato: Tendono ad aumentare l'accuratezza quando la risposta corretta è in posizione A, ma la riducono drasticamente quando è in B.
  • Verbosità: Mostra un comportamento opposto, spesso favorendo la posizione B.
  • Task Gen (Test Generation): È il compito più vulnerabile ai bias, con grandi fluttuazioni di accuratezza.
• Generalizzazione: Questi pattern sono coerenti sia per i modelli open-source (Qwen) che per quelli chiusi (GPT), sebbene GPT mostri una baseline di accuratezza più alta.

Affidabilità e Coerenza (RQ2)

• Instabilità di Base: I modelli mostrano una variabilità significativa nelle valutazioni ripetute.
  • Qwen2.5-Coder-3B: Ha una coerenza di base (Consistency Rate - CR) molto bassa, specialmente su TestGen (circa 50%, equivalente a un lancio di moneta).
  • GPT: Mostra una coerenza di base molto alta (sopra l'80-90% per CodeGen/CodeRepair).
• Il Paradosso della Coerenza: L'introduzione di bias forti (come Sentiment o Raffinato) aumenta artificialmente la coerenza (CR) anche per i modelli instabili. Questo crea un'illusione di affidabilità: il modello diventa coerente nel suo errore, ancorandosi al segnale superficiale del prompt invece di valutare il codice.
• Tasso di Risposta (Answer Rate): Un risultato critico riguarda la capacità di produrre un verdetto strutturato.
  • Qwen2.5-Coder-3B: Produce verdetto A/B corretto nel 99% dei casi.
  • Qwen3-4B (Generico): Produce un verdetto strutturato solo nel ~44% dei casi, spesso generando testo libero fino a superare il limite del contesto. Ignorare questi fallimenti di formato distorce completamente le metriche di accuratezza.

Analisi della Fiducia (Confidence)

L'analisi a livello di token rivela che i bias non cambiano solo la risposta finale, ma alterano la distribuzione della probabilità interna del modello. In casi difficili, l'aggiunta di un bias può far saltare la fiducia del modello da valori bassi a valori alti, spingendolo a scegliere una risposta che altrimenti avrebbe scartato.

4. Contributi Principali

1. Suite di Bias per il Codice: Definizione e validazione di 12 bias specifici per l'ingegneria del software, adattando concetti NLP al dominio del codice.
2. Metriche di Affidabilità: Formalizzazione della coerenza test-retest per i giudici di codice, dimostrando che l'accuratezza da sola non è sufficiente.
3. Scoperta del "Tasso di Risposta": Evidenziazione del fatto che molti modelli generici falliscono nel produrre output strutturati, un fattore critico spesso ignorato nelle valutazioni esistenti.
4. Linee Guida Pratiche: Dimostrazione che le conclusioni sui benchmark di codice possono essere invertite o distorte semplicemente cambiando il prompt, rendendo necessarie nuove pratiche di reporting.

5. Significato e Implicazioni

Il paper conclude che l'approccio "LLM-as-a-Judge" per il codice non è un sostituto diretto e affidabile della revisione umana o dei test eseguibili senza controlli rigorosi.

• Per i Ricercatori: È necessario riportare non solo l'accuratezza media, ma anche la sensibilità al bias e la coerenza (stabilità tra run). Le valutazioni devono includere controlli come lo scambio di ordine (A/B swapping) e perturbazioni controllate del prompt.
• Per la Pratica (Practitioners): Nei flussi di lavoro agentic, i giudizi LLM non dovrebbero essere usati ciecamente. È necessario implementare meccanismi di escalation (es. compilazione, test statici, revisione umana) quando il giudice mostra instabilità o quando il compito è complesso (es. generazione di test).
• Standardizzazione: La comunità deve adottare protocolli di valutazione che trattino la robustezza come un requisito testabile, verificando l'invarianza delle conclusioni rispetto a variazioni sintattiche e di formattazione non semantiche.

In sintesi, lo studio avverte che le prestazioni riportate nei giudizi LLM attuali riflettono spesso artefatti del prompt piuttosto che capacità di valutazione stabili, ponendo una minaccia diretta alla validità della ricerca e dello sviluppo software basato su questi strumenti.