Sprache

Hashline vs. Replace: Macht das Editierformat einen Unterschied?

veröffentlicht · aktualisiert · 601 Wörter

Maschinelle Übersetzung Originalartikel.

Inhalt

Can Bölüks Das Harness-Problem zeigte, dass Änderungen im Hashline-Stil (an Zeilennummern verankert, etwa 4#WB) bei Coding-Agenten besser abschnitten als herkömmliche Änderungen im Replace-Modus (Abgleich über old_string/new_string). Ich experimentiere mit der Entwicklung meines eigenen Harness (tau) und wollte dieses Ergebnis überprüfen und herausfinden, ob ich Hashline dort als standardmäßige Bearbeitungsstrategie in Betracht ziehen sollte. Also habe ich edit-bench gebaut, um das selbst mit mehreren Sprachen und Modellen zu testen.

Versuchsaufbau

edit-bench erzeugt mutationsbasierte Tests aus bestehenden Codebasen. Du übergibst einem Skript ein Verzeichnis, und es erzeugt Mutationen wie das Löschen einer Anweisung, das Umkehren eines booleschen Werts, das Vertauschen von Argumenten usw.

  • Sprachen: Python (aus hive), TypeScript (aus oh-my-pi), Rust (aus irradiate)
  • Modelle: gpt-4.1-mini, google/gemini-3-flash-preview, qwen/qwen3.5-397b-a17b
  • Bearbeitungsmodi: replace (old_string/new_string) vs. hashline (an Zeilennummern verankert)
  • 20 Aufgaben pro Sprache, einmalige Durchläufe mit jeweils einem Versuch
  • Außerdem habe ich kürzlich Fuzzy Matching zu tau hinzugefügt (Trim-Kaskade: trim_end → trim_both → unicode normalization) und wollte sehen, ob das hilft

Ergebnisse

Replace-Modus:

Modell Python TypeScript Rust
gemini-3-flash 95% 80% 95%
qwen3.5-397b 90% 85% 85%
gpt-4.1-mini 65% 75% 45%

Hashline-Modus (aus früheren Durchläufen):

Modell Python TypeScript Rust
gemini-3-flash 70% 85% 90%
qwen3.5-397b 85% 85% 90%
gpt-4.1-mini 50% 70% 55%

Hashline verschlechtert die Ergebnisse bei Python merklich und scheint sich bei TypeScript und Rust ungefähr neutral auszuwirken. Die Sprachabhängigkeit ist interessant – Pythons syntaktisch relevanter Whitespace könnte zeilenverankerte Änderungen fehleranfälliger machen.

Hilft Fuzzy Matching?

Offenbar nicht.

Ich habe das Sammeln von Traces hinzugefügt, um zu sehen, ob die Fuzzy-Trim-Kaskade von tau bei Durchläufen im Replace-Modus überhaupt greift. Bei 114 erfolgreichen Änderungen und 20 fehlgeschlagenen Änderungen (3 Modelle × 3 Sprachen) wurde Fuzzy Matching kein einziges Mal ausgelöst.

Von den 20 fehlgeschlagenen Änderungen:

  • 1 enthielt nachgestellte Leerzeichen (theoretisch behebbar)
  • ~8 enthielten Zeilennummern in old_string (Modellfehler)
  • ~11 enthielten vollständig halluzinierte Inhalte

Wenn Modelle old_string richtig hinbekommen, bekommen sie auch den Whitespace richtig hin. Wenn sie danebenliegen, liegen sie völlig daneben – eine Trim-Kaskade hilft da nicht.

(Details zur Trace-Analyse)

Erkenntnisse

  1. Im Vergleich zwischen Hashline und Replace gibt es keinen klaren Sieger. Die Wirkung hängt von der Sprache und dem Modell ab. Bei Python schneidet Hashline schlechter ab; bei TypeScript gibt es keinen Unterschied; bei Rust ist die Sache offen.

  2. Cans Ergebnisse lassen sich nur schwer verallgemeinern. Der react-edit-benchmark beschränkt sich auf JavaScript und verwendet einen LSP für Validierungsfeedback. Unser Versuchsaufbau (ohne LSP, mehrere Sprachen) zeigt ein anderes Bild. Insbesondere die LSP-Feedbackschleife wirkt vermutlich als Störfaktor. Dem Modell für einen erneuten Versuch Fehler aus der Typprüfung zurückzumelden, bringt einen erheblichen Vorteil, der mit dem Editierformat in Wechselwirkung steht.

  3. Fuzzy Matching löst bei aktuellen Modellen kein relevantes Problem. LLMs geben Quelltext entweder exakt wieder oder halluzinieren etwas völlig anderes. Die geringfügigen Abweichungen beim Whitespace, auf die Fuzzy Matching abzielt, treten in der Praxis so gut wie nie auf.

  4. Bei Modellen der aktuellen Generation in modernen Harnesses ist das Editierformat nicht der Engpass. Der Unterschied zwischen den Modellen (gemini-3-flash bei 90%+ gegenüber gpt-4.1-mini bei 55-65%) ist um ein Vielfaches größer als der Unterschied zwischen den Editierformaten. Investiere in die Modellauswahl und ins Prompt Engineering, bevor du dir Gedanken über das Editierformat machst.

Obligatorischer Hinweis: kleines n, statistisch nicht streng abgesichert, entsprechend einordnen.

Alle Daten: nwyin/edit-bench, Issues #13 und #14.