💬 NLP

RuBench: A Repository-Level Agentic Coding Benchmark with Natively Authored Russian Task Specifications

RuBench è un benchmark di codifica agentica a livello di repository che presenta 25 specifiche di task scritte nativamente in russo da progetti open-source reali, progettato per valutare agenti di codifica di grado professionale su veri lavori di manutenzione, garantendo al contempo la resistenza alla contaminazione dei dati e rivelando intuizioni critiche sui comportamenti dei sistemi distribuiti attraverso un'analisi statistica rigorosa e l'audit delle traiettorie.

Autori originali: Evgeny Shilov (Independent Researcher)

Pubblicato 2026-07-08

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Evgeny Shilov (Independent Researcher)

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 di assumere un team di meccanici esperti per riparare una flotta di auto da corsa complesse e personalizzate. Fino ad ora, la maggior parte dei test per questi meccanici era stata scritta in un inglese perfetto e formale, come un manuale tecnico. Ma nel mondo reale, i clienti non parlano come un manuale; parlano come le persone. Dicono cose come: "La mia auto ha iniziato a tremare ogni volta che frenavo in un martedì di pioggia", nella propria lingua madre.

RuBench è un nuovo test progettato per vedere se gli assistenti di programmazione AI siano effettivamente in grado di comprendere queste richieste disordinate e reali dei clienti quando sono scritte in russo, non in inglese.

Ecco una ripartizione di come funziona il test, cosa è successo e il colpo di scena sorprendente che i ricercatori hanno scoperto, utilizzando semplici analogie.

1. Il Test: Un'officina del "Mondo Reale"

La maggior parte dei test precedenti forniva agli agenti AI una descrizione pulita e in inglese di un bug. RuBench è diverso:

Le Auto: Il test utilizza cinque progetti software open-source reali e popolari (come aiohttp o Laravel). Questi non sono puzzle finti; sono basi di codice vive utilizzate da migliaoli di sviluppatori.
Le Richieste: Invece di un rapporto sui bug formale, i ricercatori hanno scritto 25 nuove richieste da zero in russo. Suonano come un proprietario di un'azienda che si lamenta con un appaltatore: "Il bot crasha quando lo rendiamo un admin; sistemalo, ma non rompere le chat esistenti."
La Scatola Misteriosa: I ricercatori hanno nascosto la "chiave di risposta" (la correzione del codice effettivo e i test che ne provano il funzionamento). L'AI deve capire la correzione da sola. Solo i ricercatori possiedono la chiave per verificare se l'AI ha avuto successo.
Freschezza: Tutti i bug sono stati trovati in aggiornamenti del codice successivi all'addestramento dei modelli AI. Ciò assicura che l'AI non possa aver semplicemente memorizzato la risposta dai suoi dati di addestramento.

2. I Meccanici: Chi ha portato a termine il lavoro?

I ricercatori hanno testato quattro diversi "team di meccanici" (combinazioni di strumenti software e modelli AI). Hanno sottoposto ogni team ai 25 interventi di riparazione tre volte per vedere quanto fossero coerenti.

Il Top Performer: Il team che utilizzava Claude Code con il modello "Opus 4.8" è stato il migliore. Ha risolto con successo circa il 79% dei problemi.
La Fascia Media: Il modello "Sonnet 5" ha fatto quasi altrettanto bene (75%), e il modello "GPT-5.5" (tramite Codex CLI) ha risolto circa il 67%.
Il Meccanico in Difficoltà: Il modello "Haiku 4.5" (una versione più economica e veloce) ha risolto solo circa il 53% dei compiti.

Il Problema: Poiché c'erano solo 25 compiti, la differenza tra i primi tre team non era statisticamente "provata" come reale — potrebbe essere stata solo fortuna. Tuttavia, il divario tra i top team e il debole modello Haiku era enorme e chiaro. I top team hanno risolto una classe di problemi completamente diversa rispetto al modello inferiore.

3. La Grande Sorpresa: La "Sostituzione Silenziosa"

Questa è la parte più interessante del paper. I ricercatori hanno anche testato un quinto team utilizzando un modello nuovissimo chiamato Fable 5.

Quando hanno esaminato attentamente i log della "scatola nera" di ciò che l'AI stava facendo, hanno scoperto un segreto:

Nel 20% dei compiti, il modello Fable 5 non ha effettivamente svolto il lavoro.
Invece, il prodotto software (Claude Code) ha sostituito silenziosamente Fable 5 con il più vecchio e forte modello Opus 4.8 nel mezzo del lavoro.
Perché? Fable 5 ha dei protocolli di sicurezza molto severi. Quando ha visto un compito che coinvolgeva protocolli internet standard (come la correzione di un header web), il suo protocollo di sicurezza si è agitato e ha detto: "Non mi è permesso toccare questo", e il sistema ha passato automaticamente il lavoro a Opus 4.8 per finirlo.

La Lezione: I ricercatori si sono resi conto che quando testiamo i prodotti AI, non stiamo testando solo il "cervello" (il modello); stiamo testando il "corpo" (l'intero pacchetto software). Se il software sostituisce segretamente il cervello a metà compito, i risultati del test mentono su ciò che quel particolare cervello può fare.

4. Il Verdetto

Successo: Gli agenti AI di livello professionale sono già abbastanza bravi da gestire il lavoro di manutenzione reale specificato in una lingua non inglese (il russo). La migliore configurazione ha risolto quasi 8 compiti su 10.
Controllo di Realtà: I modelli "economici" (come Haiku) sono ancora significativamente più deboli, risolvendo solo circa la metà dei problemi.
Metodologia: Il paper dimostra che per ottenere risultati onesti, dobbiamo osservare l'intera "diaria" (traiettoria) dell'AI per assicurarsi che non abbia barato sostituendo i modelli o cercando le risposte online.

In breve, RuBench mostra che l'AI sta diventando brava a parlare "umano" (in russo), ma ha anche rivelato che il software che avvolge queste AI può talvolta essere subdolo, sostituendo il lavoratore con uno migliore senza dirlo a nessuno.

Riepilogo Tecnico: RuBench 1.0

Definizione del Problema

Gli attuali benchmark per agenti di codifica a livello di repository (ad esempio, SWE-bench) non riescono a valutare una capacità critica del mondo reale: la capacità degli agenti di codifica di interpretare ed eseguire compiti specificati nativamente in lingue non inglesi, in particolare nello stile delle richieste dei clienti piuttosto che in quelle di issue GitHub curate in inglese. I benchmark "multilingue" esistenti si affidano per design a dichiarazioni in inglese o operano a livello di snippet/singolo file, mancando della complessità della manutenzione di un intero repository. Inoltre, i benchmark statici soffrono di leakage delle soluzioni e memorizzazione, mentre le valutazioni spesso scindono l'harness dell'agente dal modello, ignorando come le configurazioni di prodotto distribuite (CLI + modello + sforzo di ragionamento) influenzino materialmente il comportamento.

Metodologia

RuBench 1.0 introduce un benchmark progettato per misurare la codifica agentica a livello di repository con specifiche native in russo.

Costruzione del Benchmark

Task Mining: 25 task sono stati estratti da commit di correzione (fix) uniti tra febbraio e giugno 2026 in cinque repository open-source attivi: aiohttp, aiogram, Laravel, NestJS e Fastify. Questi spaziano tra Python, PHP, TypeScript e JavaScript.
Specifiche Native: A differenza dei benchmark tradotti, ogni task presenta una specifica scritta da zero in russo, che imita la richiesta di un proprietario di un'attività (descrivendo sintomi, comportamenti richiesti e vincoli) piuttosto che l'entry di un tracker di issue di uno sviluppatore. Queste specifiche non esistono sul web pubblico prima del rilascio.
Gate di Freschezza: Tutti i 25 task sono successivi ai cutoff dei dati di addestramento di ogni modello valutato (che variano da luglio 2025 a gennaio 2026), garantendo un argomento di contaminazione task per task.
Oracolo Privato: La valutazione è eseguita dalle suite di test di regressione del manutentore a monte, che sono trattenute dal rilascio pubblico. Un manifesto SHA-256 di questi oracoli viene caricato per verificare l'integrità senza rivelare i test.
Workspace: Gli agenti ricevono uno snapshot del repository al commit genitore della correzione, privato della cronologia git e dei test dell'oracolo.

Protocollo Sperimentale

Configurazioni: Lo studio valuta quattro configurazioni di prodotto distribuite (agente CLI + modello + sforzo di ragionamento impostato al massimo):
- Claude Code con Opus 4.8
- Claude Code con Sonnet 5
- Claude Code con Haiku 4.5
- Codex CLI con GPT-5.5
- Hors concours: Claude Code con Fable 5 (rilascio del 2 luglio 2026).
Esecuzione: Ogni configurazione viene eseguita tre volte in modo indipendente per ogni task in workspace isolati con accesso alla rete (necessario per l'installazione dei pacchetti).
Metriche: Le prestazioni sono riportate come pass@1 (frazione di esecuzioni riuscite tra 3 tentativi) mediata su 25 task. L'incertezza è quantificata tramite intervalli di confidenza di Wilson al 95% a livello di task e confronti bootstrap accoppiati (10.000 campionamenti).
Audit di Validità: Le traiettorie sono sottoposte ad audit per l'uscita dall'oracolo (oracle escape) e, crucialmente, per la sostituzione del modello (assicurando che il modello in esecuzione corrisponda al modello richiesto).

Risultati Chiave

Prestazioni: La migliore configurazione, Claude Code + Opus 4.8, ha risolto il 78,7% dei task (media su 3 esecuzioni). La più debole, Claude Code + Haiku 4.5, ha risolto il 53,3%.
Significatività Statistica: Con $N=25$ , il limite di risoluzione del benchmark è di circa 25 punti percentuali. Gap statisticamente risolvibili (dove l'intervallo bootstrap esclude lo zero) sono stati trovati solo tra il modello più debole (Haiku 4.5) e gli altri. Le differenze tra le prime tre configurazioni (Opus 4.8, Sonnet 5, GPT-5.5) erano entro i margini di rumore.
Costo ed Efficienza:
- Sonnet 5 ha raggiunto una risoluzione del 74,7% al 78% del costo di Opus 4.8 ($2,42 vs $3,12 per task).
- Codex CLI + GPT-5.5 è stato il più efficiente in termini di token (16k output token contro 33k per Opus 4.8) ma ha risolto meno task (66,7%).
Riscontro sulla Sostituzione di Safeguard: Un audit della configurazione hors concours Claude Code + Fable 5 ha rivelato che in 5 task su 25 (20%), il prodotto ha sostituito silenziosamente il modello richiesto (Fable 5) con Opus 4.8 a causa di trigger di salvaguardia interni (specificamente per correzioni di routine del protocollo HTTP). Ciò ha portato a una classificazione "safeguard-fallback" per quei task, dimostrando che il prodotto distribuito, e non solo il modello, è l'unità di misura.

Significato e Rivendicazioni

Il paper rivendica tre contributi primari:

Un Nuovo Protocollo di Benchmark: RuBench è il primo benchmark a livello di repository che utilizza specifiche scritte nativamente in una lingua non inglese con oracoli privati e un gate di freschezza, affrontando il vuoto nella valutazione del recupero dell'intento in lingua nativa.
Misurazione Onesta dell'Incertezza: Riportando intervalli di confidenza a livello di task e confronti accoppiati, lo studio riconosce esplicitamente i limiti statistici dei benchmark con piccoli valori di N ( $N=25$ ), evitando affermazioni eccessivamente sicure sulle classifiche dove i gap non sono statisticamente risolvibili.
Regola di Validità a Livello di Prodotto: La scoperta della sostituzione silenziosa del modello stabilisce una regola di validità: un'evaluazione è valida solo se la traiettoria conferma che il modello in esecuzione corrisponde al modello richiesto. Ciò evidenzia che le valutazioni degli "agenti" spesso misurano il sistema di salvaguardia e di routing del vendor piuttosto che la capacità grezza del modello.

Gli autori concludono che, sebbene gli agenti di grado prodotto possano gestire il lavoro di manutenzione reale specificato in russo (78,7% di successo per il top tier), il campo è attualmente separato più dal "tier economico" (Haiku) che dai modelli di frontiera, e che le valutazioni future devono sottoporre le traiettorie ad audit per garantire l'integrità del modello testato.