treść
Can Bölük w artykule Problem harnessu pokazał, że edycje w stylu hashline (oparte na numerach wierszy, jak 4#WB) są skuteczniejsze w przypadku agentów programistycznych od tradycyjnych edycji w trybie replace (dopasowywanie old_string/new_string).
Eksperymentuję z budową własnego harnessu (tau) i chciałem zweryfikować ten wynik oraz sprawdzić, czy warto rozważyć w nim hashline jako domyślną strategię edycji.
Dlatego stworzyłem edit-bench, by samemu przetestować to w wielu językach i na wielu modelach.
Konfiguracja
edit-bench generuje testy oparte na mutacjach na podstawie istniejących baz kodu. Wskazujesz skryptowi katalog, a on generuje mutacje, takie jak usunięcie instrukcji, odwrócenie wartości logicznej, zamiana kolejności argumentów itd.
- Języki: Python (z hive), TypeScript (z oh-my-pi), Rust (z irradiate)
- Modele:
gpt-4.1-mini,google/gemini-3-flash-preview,qwen/qwen3.5-397b-a17b - Tryby edycji: replace (old_string/new_string) kontra hashline (oparty na numerach wierszy)
- 20 zadań na język, przebiegi z jedną próbą, w trybie one-shot
- Niedawno dodałem też dopasowywanie przybliżone do
tau(kaskadowe przycinanie białych znaków:trim_end → trim_both → unicode normalization) i chciałem sprawdzić, czy to pomaga
Wyniki
Tryb replace:
| Model | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 95% | 80% | 95% |
| qwen3.5-397b | 90% | 85% | 85% |
| gpt-4.1-mini | 65% | 75% | 45% |
Tryb hashline (z wcześniejszych przebiegów):
| Model | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 70% | 85% | 90% |
| qwen3.5-397b | 85% | 85% | 90% |
| gpt-4.1-mini | 50% | 70% | 55% |
Hashline wyraźnie pogarsza wyniki w Pythonie, a w językach TypeScript i Rust wydaje się mieć mniej więcej neutralny wpływ. Ta zależność od języka jest interesująca — białe znaki o znaczeniu składniowym w Pythonie mogą zwiększać podatność na błędy przy edycjach opartych na numerach wierszy.
Czy dopasowywanie przybliżone pomaga?
Najwyraźniej nie.
Dodałem zbieranie śladów wykonania, by sprawdzić, czy kaskadowe przycinanie białych znaków z dopasowywaniem przybliżonym w tau w ogóle uruchamia się podczas przebiegów w trybie replace. Przy 114 udanych edycjach i 20 nieudanych edycjach (3 modele × 3 języki) dopasowywanie przybliżone uruchomiło się zero razy.
Spośród 20 nieudanych edycji:
- 1 zawierała białe znaki na końcu (teoretycznie do naprawienia)
- ~8 zawierało numery wierszy w
old_string(błąd modelu) - ~11 zawierało całkowicie zmyśloną treść
Gdy modele poprawnie odtwarzają old_string, poprawnie odtwarzają też białe znaki.
Gdy się mylą, mylą się bardzo — kaskadowe przycinanie białych znaków nie pomaga.
(Szczegóły analizy śladów wykonania)
Wnioski
-
Porównanie hashline z replace nie wskazuje jednoznacznego zwycięzcy. Wpływ zależy od języka i modelu. W Pythonie hashline obniża wyniki; w TypeScripcie jest neutralny; w Ruście trudno wskazać zwycięzcę.
-
Wyniki Cana trudno uogólnić. react-edit-benchmark obejmuje wyłącznie JavaScript i korzysta z LSP do przekazywania informacji zwrotnych z walidacji. Nasza konfiguracja (bez LSP, wiele języków) daje inny obraz. W szczególności pętla informacji zwrotnych z LSP jest prawdopodobnie czynnikiem zakłócającym. Przekazywanie modelowi błędów typów, by na ich podstawie ponawiał próby, daje istotną poprawę wyników, zależną również od formatu edycji.
-
Dopasowywanie przybliżone nie rozwiązuje istotnego problemu obecnych modeli. LLM-y albo dokładnie odtwarzają tekst źródłowy, albo halucynują coś zupełnie innego. Sytuacje, w których tekst różni się tylko białymi znakami i do których służy dopasowywanie przybliżone, w praktyce niemal się nie zdarzają.
-
W przypadku modeli obecnej generacji we współczesnych harnessach format edycji nie jest wąskim gardłem. Różnica między modelami (gemini-3-flash z wynikiem 90%+ a gpt-4.1-mini z wynikiem 55-65%) jest znacznie większa niż różnica między formatami edycji. Zainwestuj w dobór modelu i inżynierię promptów, zanim zaczniesz martwić się formatem edycji.
Obowiązkowe zastrzeżenie: małe n, brak rygoru statystycznego, więc traktuj wyniki z odpowiednim dystansem.
Wszystkie dane: nwyin/edit-bench, zgłoszenia #13 i #14.