contenuto
In Il problema dell'harness, Can Bölük ha mostrato che le modifiche in stile hashline (ancorate ai numeri di riga, come 4#WB) superano quelle tradizionali in modalità replace (corrispondenza old_string/new_string) per gli agenti di programmazione.
Sto sperimentando la creazione di un mio harness (tau) e volevo verificare questo risultato e capire se prendere in considerazione hashline come strategia di modifica predefinita.
Così ho sviluppato edit-bench per verificarlo di persona su più linguaggi e modelli.
Configurazione
edit-bench genera test basati su mutazioni a partire da codebase esistenti. Indichi una directory a uno script, che genera mutazioni come eliminare un'istruzione, invertire un booleano, scambiare argomenti, ecc.
- Linguaggi: Python (da hive), TypeScript (da oh-my-pi), Rust (da irradiate)
- Modelli:
gpt-4.1-mini,google/gemini-3-flash-preview,qwen/qwen3.5-397b-a17b - Modalità di modifica: replace (old_string/new_string) vs hashline (con ancoraggio ai numeri di riga)
- 20 task per linguaggio, esecuzioni one-shot con un solo tentativo
- Di recente ho anche aggiunto il fuzzy matching a
tau(trim a cascata:trim_end → trim_both → unicode normalization) e volevo vedere se fosse utile
Risultati
Modalità replace:
| Modello | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 95% | 80% | 95% |
| qwen3.5-397b | 90% | 85% | 85% |
| gpt-4.1-mini | 65% | 75% | 45% |
Modalità hashline (da esecuzioni precedenti):
| Modello | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 70% | 85% | 90% |
| qwen3.5-397b | 85% | 85% | 90% |
| gpt-4.1-mini | 50% | 70% | 55% |
Hashline peggiora sensibilmente i risultati su Python e sembra avere un effetto pressoché neutro su TypeScript e Rust. La dipendenza dal linguaggio è interessante — il fatto che in Python gli spazi bianchi abbiano un significato sintattico potrebbe rendere le modifiche ancorate alle righe più soggette a errori.
Il fuzzy matching aiuta?
A quanto pare, no.
Ho aggiunto la raccolta delle tracce per vedere se il fuzzy matching con trim a cascata di tau si attiva mai durante le esecuzioni in modalità replace. Su 114 modifiche riuscite e 20 modifiche fallite (3 modelli × 3 linguaggi), il fuzzy matching si è attivato zero volte.
Delle 20 modifiche fallite:
- 1 presentava spazi bianchi a fine riga (in teoria correggibile)
- ~8 includevano numeri di riga in
old_string(errore del modello) - ~11 contenevano contenuti completamente inventati
Quando i modelli riportano correttamente old_string, riportano correttamente anche gli spazi bianchi.
Quando sbagliano, sbagliano di grosso — il trim a cascata non aiuta.
(Dettagli dell'analisi delle tracce)
Conclusioni
-
Nel confronto tra hashline e replace non c'è un vincitore netto. L'effetto dipende dal linguaggio e dal modello. Python penalizza hashline; TypeScript è neutro; per Rust l'esito è incerto.
-
I risultati di Can sono difficili da generalizzare. Il react-edit-benchmark usa solo JavaScript e un LSP per il feedback di validazione. La nostra configurazione (senza LSP, con più linguaggi) mostra un quadro diverso. In particolare, il ciclo di feedback dell'LSP è probabilmente un fattore confondente. Fornire al modello gli errori di tipo perché possa riprovare offre un vantaggio significativo che interagisce con il formato di modifica.
-
Il fuzzy matching è un falso problema per i modelli attuali. Gli LLM riproducono il testo sorgente esattamente oppure inventano qualcosa di completamente diverso. Il caso di una corrispondenza quasi esatta con differenze negli spazi bianchi, che il fuzzy matching mira a gestire, nella pratica non si presenta quasi mai.
-
Per i modelli dell'attuale generazione negli harness odierni, il formato di modifica non è il collo di bottiglia. Il divario tra i modelli (gemini-3-flash al 90%+ contro gpt-4.1-mini al 55-65%) è molto più ampio di quello tra i formati di modifica. Investi nella scelta del modello e nel prompt engineering prima di preoccuparti del formato di modifica.
Avvertenza di rito: n piccolo, analisi non rigorosa dal punto di vista statistico, da interpretare di conseguenza.
Tutti i dati: nwyin/edit-bench, issue #13 e #14.