सामग्री
Can Bölük के हार्नेस की समस्या लेख में दिखाया गया कि कोडिंग एजेंटों के लिए hashline शैली के एडिट (लाइन नंबर पर आधारित, जैसे 4#WB) पारंपरिक replace मोड के एडिट (old_string/new_string का मिलान) से बेहतर प्रदर्शन करते हैं।
मैं अपना खुद का harness (tau) बनाने को लेकर प्रयोग कर रहा हूँ, और इस नतीजे की पुष्टि करने के साथ यह देखना चाहता था कि क्या मुझे उसमें hashline को डिफ़ॉल्ट एडिट रणनीति के तौर पर इस्तेमाल करने पर विचार करना चाहिए।
इसलिए मैंने कई भाषाओं और मॉडलों पर खुद इसका परीक्षण करने के लिए edit-bench बनाया।
सेटअप
edit-bench मौजूदा कोडबेस से म्यूटेशन पर आधारित टेस्ट बनाता है। आप स्क्रिप्ट को एक डायरेक्टरी देते हैं, और वह म्यूटेशन तैयार करती है, जैसे किसी स्टेटमेंट को हटाना, बूलियन का मान उलटना, आर्ग्युमेंट की अदला-बदली करना आदि।
- भाषाएँ: Python (hive से), TypeScript (oh-my-pi से), Rust (irradiate से)
- मॉडल:
gpt-4.1-mini,google/gemini-3-flash-preview,qwen/qwen3.5-397b-a17b - एडिट मोड: replace (old_string/new_string) बनाम hashline (लाइन नंबर पर आधारित)
- हर भाषा के लिए 20 टास्क, एक प्रयास वाले, वन-शॉट रन
- मैंने हाल ही में
tauमें फ़ज़ी मैचिंग भी जोड़ी है (ट्रिम कैस्केड:trim_end → trim_both → unicode normalization) और देखना चाहता था कि क्या इससे मदद मिलती है
नतीजे
Replace मोड:
| मॉडल | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 95% | 80% | 95% |
| qwen3.5-397b | 90% | 85% | 85% |
| gpt-4.1-mini | 65% | 75% | 45% |
Hashline मोड (पहले के रन से):
| मॉडल | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 70% | 85% | 90% |
| qwen3.5-397b | 85% | 85% | 90% |
| gpt-4.1-mini | 50% | 70% | 55% |
Hashline से Python के प्रदर्शन में साफ़ गिरावट आती है, और TypeScript और Rust पर इसका असर लगभग तटस्थ लगता है। यह भाषा पर निर्भरता दिलचस्प है — Python में व्हाइटस्पेस के मायने होने की वजह से लाइन पर आधारित एडिट में गलतियों की संभावना बढ़ सकती है।
क्या फ़ज़ी मैचिंग से मदद मिलती है?
ऐसा लगता है कि नहीं।
मैंने ट्रेस इकट्ठा करने की सुविधा जोड़ी, ताकि देख सकूँ कि replace मोड के रन के दौरान tau का फ़ज़ी ट्रिम कैस्केड कभी सक्रिय होता भी है या नहीं। कुल 114 सफल एडिट और 20 असफल एडिट (3 मॉडल × 3 भाषाएँ) में फ़ज़ी मैचिंग एक बार भी नहीं चली।
इन 20 असफल एडिट में से:
- 1 में अंत में व्हाइटस्पेस था (सैद्धांतिक रूप से ठीक किया जा सकता था)
- ~8 में
old_stringके अंदर लाइन नंबर शामिल थे (मॉडल का बग) - ~11 में पूरी तरह मनगढ़ंत सामग्री थी
जब मॉडल old_string सही लिखते हैं, तो व्हाइटस्पेस भी सही लिखते हैं।
जब वे इसे गलत लिखते हैं, तो बहुत ही गलत लिखते हैं — ट्रिम कैस्केडिंग से मदद नहीं मिलती।
निष्कर्ष
-
Hashline और replace में से कोई भी स्पष्ट विजेता नहीं है। असर भाषा और मॉडल पर निर्भर करता है। Python में hashline पिछड़ता है; TypeScript में असर तटस्थ है; Rust में बाज़ी किसी भी तरफ़ जा सकती है।
-
Can के नतीजों को सामान्य रूप से लागू करना मुश्किल है। react-edit-benchmark केवल JavaScript के लिए है और वैलिडेशन फ़ीडबैक के लिए LSP इस्तेमाल करता है। हमारा सेटअप (LSP के बिना, कई भाषाओं के साथ) एक अलग तस्वीर दिखाता है। खास तौर पर LSP का फ़ीडबैक लूप शायद एडिट फ़ॉर्मैट के अपने असर को अलग से आँकना मुश्किल बनाता है। मॉडल को टाइप एरर दिखाकर उन्हें ठीक करने के लिए दोबारा कोशिश करने देना एक अहम बढ़त देता है, और इस बढ़त का असर एडिट फ़ॉर्मैट से भी जुड़ा होता है।
-
मौजूदा मॉडलों के लिए फ़ज़ी मैचिंग कोई मुद्दा ही नहीं है। LLM या तो सोर्स टेक्स्ट को हूबहू दोहराते हैं या पूरी तरह अलग कुछ गढ़ देते हैं। व्हाइटस्पेस में मामूली फ़र्क़ वाला मामला, जिसे फ़ज़ी मैचिंग संभालने की कोशिश करती है, व्यवहार में लगभग कभी होता ही नहीं।
-
आज के harness में मौजूदा पीढ़ी के मॉडलों के लिए एडिट फ़ॉर्मैट प्रदर्शन को सीमित करने वाला कारक नहीं है। मॉडलों के बीच का अंतर (gemini-3-flash के 90%+ के मुकाबले gpt-4.1-mini के 55-65%) एडिट फ़ॉर्मैट के बीच के अंतर से कहीं बड़ा है। एडिट फ़ॉर्मैट की चिंता करने से पहले मॉडल के चुनाव और प्रॉम्प्ट इंजीनियरिंग में निवेश करें।
ज़रूरी स्पष्टीकरण: नमूना छोटा है, सांख्यिकीय तौर पर पुख़्ता नहीं है, नतीजों को उसी हिसाब से लें।
सारा डेटा: nwyin/edit-bench, इश्यू #13 और #14।