अत्यधिक एडिटिंग: जब मॉडल ज़रूरत से ज़्यादा कोड बदल देते हैं

• केवल न्यूनतम बदलाव से ठीक होने वाले बग में भी अक्सर पूरा फ़ंक्शन फिर से लिखा जाता है, सहायक लॉजिक जोड़ा जाता है, सिग्नेचर बदला जाता है, और बहुत बड़ा diff बन जाता है
• मौजूदा संरचना को बनाए रखने वाले brown-field काम में सिर्फ़ टेस्ट पास होना काफ़ी नहीं है; कितना कम बदला गया, यह भी देखना ज़रूरी है ताकि reviewability और change safety बनी रहे
• प्रोग्रामेटिक तरीके से ख़राब किए गए 400 BigCodeBench समस्याओं के आधार पर token-level Levenshtein, relative patch score, और Added Cognitive Complexity से over-editing को मात्रात्मक रूप से मापा गया
• नवीनतम coding models में व्यापक रूप से ज़रूरत से ज़्यादा rewriting की प्रवृत्ति दिखी; Claude Opus 4.6 ने accuracy और न्यूनतम बदलाव का मज़बूत संयोजन दिखाया, जबकि GPT-5.4 में अपेक्षाकृत अधिक over-editing उभरकर आया
• मूल संरचना को सुरक्षित रखने की बात साफ़ तौर पर कहने वाले prompts ने ख़ासकर reasoning models में diff घटाया, और training तरीकों में RL ने न्यूनतम edit व्यवहार सीखते हुए सामान्य coding performance गिराए बिना सबसे संतुलित नतीजे दिए

---

Over-Editing समस्या

• Over-Editing उस स्थिति को कहते हैं जब बग ठीक करने के लिए ज़रूरी न्यूनतम बदलाव की सीमा से आगे बढ़कर कोड की संरचना तक बड़े पैमाने पर बदल दी जाती है
  • एक साधारण off-by-one bug में जहाँ सिर्फ़ range(len(x) - 1) को range(len(x)) में बदलना काफ़ी हो, मॉडल पूरा फ़ंक्शन फिर से लिख सकता है और सहायक फ़ंक्शन या validation logic जोड़ सकता है
  • उदाहरण में GPT-5.4 ने None जाँच, np.asarray(dtype=float) रूपांतरण, finite-value masking, array size validation, curve_fit call signature बदलना, और plotting logic बदलना तक किया; टेस्ट पास हो जाते हैं, लेकिन बहुत बड़ा diff बनता है
• मौजूदा codebase के साथ काम करने वाले brown-field कार्यों में टीम द्वारा पहले से समझकर और इरादतन लिखे गए कोड को बनाए रखते हुए सिर्फ़ समस्या ठीक करना अधिक महत्वपूर्ण होता है
  • नए green-field काम से अलग, मौजूदा संरचना का सम्मान न करने वाले बदलाव reviewer के लिए यह समझना मुश्किल बना देते हैं कि क्या और क्यों बदला गया
  • जब पूरा फ़ंक्शन फिर से लिखा जाता है, तो कोड पढ़ना कठिन हो जाता है और बदलाव की safety का आकलन करना भी मुश्किल हो जाता है
• सिर्फ़ टेस्ट पास होने को मानदंड मानने पर इस समस्या को पकड़ना मुश्किल है
  • Over-Editing correctness failure नहीं, बल्कि edit fidelity failure है, इसलिए यह अक्सर test suite में साफ़ दिखाई नहीं देता
  • जैसे-जैसे generated code बढ़ता है, review करने की मात्रा बढ़ती है और अनावश्यक जटिलता जमा होती जाती है, जिससे codebase की गुणवत्ता चुपचाप गिर सकती है

Over-Editing को मापने का तरीका

• ऐसा dataset बनाने के लिए जिसमें न्यूनतम बदलाव का सही उत्तर स्पष्ट हो, BigCodeBench की 400 समस्याओं को प्रोग्रामेटिक तरीके से ख़राब करके evaluation set तैयार किया गया
  • मौजूदा benchmarks की तरह किसी दूसरे LLM से bug inject नहीं किया गया; इसके बजाय < को <=, + को -, और True को False में बदलने जैसे सूक्ष्म और नियंत्रित बदलाव किए गए
  • हर ख़राब sample को syntactically valid होने और संबंधित test case तोड़ने के लिए verify किया गया, और सही fix सिर्फ़ उस corruption को वापस पलटना ही रखा गया ताकि यह न्यूनतम बदलाव बने
• इस सेटअप की वजह से यह सिर्फ़ नहीं मापा जा सका कि मॉडल ने बग ठीक किया या नहीं, बल्कि यह भी कि ठीक करते समय उसने कितना अतिरिक्त बदलाव किया
  • reference answer और model output, दोनों की तुलना ख़राब input से करके relative patch size निकाली गई
  • सही restoration के अलावा जितने ज़्यादा अतिरिक्त बदलाव होंगे, score उतना ख़राब होगा
• संबंधित कोड GitHub repository में उपलब्ध है

मापन मेट्रिक्स

• Token-level Levenshtein Distance

  • सामान्य character-level Levenshtein की जगह Python token-level variant का उपयोग किया गया
  • कोड को Python tokenizer से def, add, (, a, ,, b, ) जैसी atomic syntax units में बाँटने के बाद उसी token sequence पर distance निकाली गई
  • def add(a, b): को def someotherfunctionname(a, b): में बदलने पर character-level distance 19 होती है, लेकिन token-level distance 1 मानी जाती है क्योंकि सिर्फ़ एक identifier बदला है
  • अलग-अलग function length की तुलना हो सके, इसके लिए इसे कुल token count से normalize किया गया

• Relative patch score

  • model output और reference answer की सीधी तुलना नहीं की गई; दोनों की तुलना ख़राब input को आधार मानकर की गई
  • ख़राब किए गए समाधान को मूल समाधान में लौटाने वाला edit ही वास्तविक न्यूनतम बदलाव है, और मॉडल का edit उससे कितना क़रीब है, यही मापा गया
  • मान 0 के जितना क़रीब होगा, model patch उतना ही वास्तविक न्यूनतम बदलाव जैसा होगा

• Added Cognitive Complexity

  • Cyclomatic Complexity की तुलना में पढ़ने की कठिनाई बेहतर दर्शाने वाली Cognitive Complexity का भी उपयोग किया गया
  • nesting, recursion, compound logical operators, और non-intuitive control flow पर penalty दी जाती है, और if, loops, try/except जैसी संरचनाएँ, जहाँ पाठक को अधिक state track करनी पड़ती है, complexity बढ़ाती हैं
  • उदाहरण में nested loop और conditional वाले कोड की Cognitive Complexity 6 बनती है
  • इस corruption में केवल values बदली गईं, संरचना नहीं; इसलिए सही fix में Added Cognitive Complexity हमेशा 0 होनी चाहिए
  • अगर model output में complexity बढ़ी, तो इसका मतलब है कि बिना माँगे अतिरिक्त कोड जोड़ा गया; और 0 से कम मान को भी अनावश्यक simplification मानकर वांछनीय नहीं माना गया

क्या मॉडल वास्तव में Over-Edit करते हैं?

• नवीनतम frontier models में भी Over-Editing देखा गया
  • reasoning models और non-reasoning models, दोनों में Pass@1 और न्यूनतम बदलाव के बीच अंतर मौजूद है
  • सिर्फ़ सही fix करने की क्षमता से faithful editing का आकलन करना मुश्किल है
• reasoning models की तुलना में Claude Opus 4.6 ने सबसे मज़बूत संयोजन दिखाया
  • Pass@1 0.912 के साथ सबसे ऊँचा था, और normalized Levenshtein 0.060, Added Cognitive Complexity 0.200 के साथ diff भी सबसे छोटा था
  • Gemini 3.1 Pro Preview भी क़रीब के क्षेत्र में रहा, और open-weight models में GLM 5 ने अपेक्षाकृत अधिक conservative editing दिखाई
• GPT-5.4 मूल्यांकित मॉडलों में सबसे गंभीर Over-Editing करने वाले समूह में रहा
  • reasoning mode में इसका Levenshtein 0.395 और Added Cognitive Complexity 2.313 था, और non-reasoning mode में भी ये क्रमशः 0.327 और 1.563 रहे
  • Pass@1 भी 0.723 और 0.770 के साथ अपेक्षाकृत कम था, इसलिए accuracy और न्यूनतम बदलाव दोनों में यह कमज़ोर रहा
• non-reasoning models में Qwen 3.6 Plus का Pass@1 0.870 के साथ सबसे ऊँचा था, और GLM 5 का Added Cognitive Complexity 0.235 के साथ सबसे कम था
  • Claude Opus 4.6 का non-reasoning model भी Levenshtein 0.079 और Added Cognitive Complexity 0.313 के साथ बहुत छोटी बदलाव-सीमा बनाए रखता है

क्या prompt से सुधार होता है?

• prompt में “IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible” जोड़ने पर सभी मॉडलों की Levenshtein Distance घटी
  • DeepSeek R1/v3 को छोड़कर Pass@1 भी साथ में बेहतर हुआ
  • इसे ऐसे समझा जा सकता है कि न्यूनतम बदलाव की बाधा संभव edits की जगह को संकीर्ण करती है और अधिक सटीक तथा लक्षित बदलावों की ओर ले जाती है
• यह प्रभाव ख़ासकर reasoning models में ज़्यादा बड़ा दिखा
  • स्पष्ट निर्देशों का बेहतर पालन करने की उनकी प्रवृत्ति के कारण edit minimization की मांग diff में कमी से मज़बूती से जुड़ी
  • यह दिखाता है कि डिफ़ॉल्ट स्थिति में मॉडल ज़रूरत से ज़्यादा बदलाव कर सकते हैं, लेकिन निर्देश मिलने पर वे अधिक faithful fixes की ओर जा सकते हैं

क्या reasoning से अत्यधिक rewriting होती है

• एक ही model family के reasoning और non-reasoning variants को जोड़कर, सिर्फ उन samples पर Levenshtein Distance की तुलना की गई जिनमें दोनों ने सही जवाब दिया
  • अगर failed samples ज़्यादा हों तो Over-Editing के मौके ही कम हो जाते हैं, इसलिए accuracy को नियंत्रित करने के बाद सिर्फ editing style को अलग करके देखा गया
• सामान्य prompt settings में ज़्यादातर जोड़ियों में reasoning models ने अधिक rewriting की
  • DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus, Kimi 2.5 में सभी में reasoning bar अधिक ऊँचा दिखा
  • यह रुझान दिखा कि विस्तारित reasoning, minimal fix के बजाय “बेहतर implementation” की ओर बढ़ते हुए अनावश्यक refactoring पैदा करता है
  • अपवाद Claude Opus 4.6 था, जिसमें reasoning variant ने non-reasoning variant की तुलना में काफ़ी कम बदलाव किए
• अगर स्पष्ट रूप से original को preserve करने का निर्देश दिया जाए तो तस्वीर काफ़ी बदल जाती है
  • reasoning models ने लगभग सभी जोड़ियों में non-reasoning variants के बराबर या उनसे कम Levenshtein Distance दिखाया
  • Claude Opus 4.6 reasoning variant ने इस setting में सभी models में सबसे कम Levenshtein दर्ज किया
  • GPT-5 और GPT-5.4 में भी reasoning variant के scores काफ़ी गिरते हैं, लेकिन GPT-5.4 में non-reasoning variant फिर भी थोड़ा आगे रहता है
• default behavior में reasoning models के लिए Over-Editing करना आसान होता है, लेकिन वही reasoning क्षमता उन्हें constraints का बेहतर पालन करने लायक भी बनाती है
  • सामान्य setting और explicit setting के बीच का अंतर reasoning models में लगातार अधिक बड़ा दिखता है
  • इसलिए Over-Editing कोई मूलभूत सीमा कम और default behavior ज़्यादा लगता है, जिसे constraints के ज़रिए पलटा जा सकता है

क्या training से faithful editor बनाया जा सकता है

• base model के रूप में Qwen3 4B 2507 Instruct का उपयोग किया गया, और 0-shot तथा 8-shot में original preservation instruction वाली configuration को baseline माना गया
  • दूसरी training methods को evaluation के समय explicit original-preservation instruction के बिना सामान्य setting में test किया गया

• प्रयोग की संरचना

  • DeepCoder समस्याओं को उसी तरीके से corrupt करके एक synthetic dataset बनाया गया
  • इसके अलावा base Qwen3 4B 2507 Instruct से हर समस्या के लिए 8 completions बनवाए गए, functional रूप से सही samples को रखा गया, फिर Levenshtein Distance के आधार पर rank करके self-distillation dataset भी बनाया गया
  • training को Context Distillation की तरह सेट किया गया, ताकि evaluation के समय explicit instruction के बिना भी model minimal editing behavior करे

• training methods

  • SFT: programmatically बनाए गए dataset पर direct supervised fine-tuning किया गया
  • rSFT: self-distillation dataset में हर sample के लिए Levenshtein Distance सबसे कम वाले सिर्फ 3 completions चुनकर training की गई
  • DPO: हर sample में Levenshtein Distance सबसे ज़्यादा वाले completion और सबसे कम वाले completion के बीच preference optimization किया गया
  • RL: functional accuracy और Levenshtein-आधारित minimal-edit reward को मिलाकर reinforcement learning लागू किया गया
    • अगर सभी tests pass हों तो r = r_edit + 0.1
    • pass न होने पर r = -0.2
    • r_edit को normalized Levenshtein-आधारित reward के रूप में calculate किया गया

एक ही corruption type में नतीजे कैसे रहे

• in-domain setting, जहाँ training set और test set के corruption types एक जैसे थे, उसमें SFT ने लगभग perfect के क़रीब नतीजे दिए
  • Baseline 0-shot का Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731 था
  • Baseline 8-shot का Pass@1 0.775, Norm. Levenshtein 0.115, Added CC 0.479 था
  • SFT ने Pass@1 0.932, Norm. Levenshtein 0.002, Added CC 0.000 के साथ तीनों metrics में सर्वोच्च स्कोर दर्ज किया
  • rSFT ने 0.782 / 0.100 / 0.435, DPO ने 0.752 / 0.021 / 0.113, और RL ने 0.802 / 0.046 / 0.112 दर्ज किया
• क्योंकि यह नतीजा बहुत अच्छा दिखा, इसलिए यह जाँचा गया कि कहीं model ने किसी खास corruption type की reverse transform ही याद तो नहीं कर ली
  • यह माना गया कि model ने general minimal-edit behavior सीखने के बजाय सिर्फ तय corruption patterns को उलटना सीखा हो सकता है
  • इसे जाँचने के लिए training data और evaluation data के corruption types को पूरी तरह अलग करके फिर से संरचना बनाई गई

क्या यह अलग corruption types पर भी generalize करता है

• out-of-domain setting, जहाँ training set और test set के corruption types अलग थे, उसमें SFT बुरी तरह टूट गया
  • SFT का Pass@1 गिरकर 0.458 तक पहुँचा, और model ऐसी स्थिति में आ गया जहाँ वह वास्तव में bug fix नहीं कर पाता, बस खास तरह के minimal changes आज़माता है
  • Norm. Levenshtein -0.008 और Added CC 0.006 जैसे बहुत कम रहे, लेकिन सही सुधार करने की क्षमता ढह गई
• rSFT और DPO, 8-shot baseline से थोड़ा बेहतर रहे, लेकिन सुधार सीमित था
  • rSFT ने 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069 दर्ज किया
  • DPO ने Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046 दर्ज किया
  • base model द्वारा खुद बनाए गए trace data पर training भर से कुछ हद तक generalization संभव दिखा
• RL ही ऐसा था जिसने तीनों metrics में साफ़-सुथरा generalize किया
  • RL ने Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185, LiveCodeBench Change +0.006 दर्ज किया
  • दोनों baselines की तुलना में तीनों metrics बेहतर हुए, और general coding performance भी नहीं घटी
  • Levenshtein और Added Cognitive Complexity में सुधार का दायरा Pass@1 से बड़ा होना इस बात का समर्थन करता है कि model ने सिर्फ corruption reversal याद नहीं किया, बल्कि minimal-edit behavior itself सीखा

Catastrophic Forgetting

• minimal editing के लिए fine-tuning करने पर general coding ability घटती है या नहीं, यह LiveCodeBench v6 से जाँचा गया
  • लक्ष्य यह था कि training के बाद भी model, मूल pretrained model के क़रीब स्तर बनाए रखे
• SFT में general ability की गिरावट बहुत बड़ी थी
  • LiveCodeBench में 43% performance drop दिखा, और model basic bug identification तथा fixing ability भी बनाए नहीं रख सका
• rSFT और DPO में भी हल्की गिरावट आई
  • भले ही training, मूल model द्वारा बनाए गए samples पर हुई हो, task की प्रकृति के कारण कुछ स्तर का Catastrophic Forgetting फिर भी बना रहा
• RL ने performance drop के बिना नया behavior सीखा
  • इसने general coding ability को बनाए रखते हुए minimal-edit task performance में भी सबसे अच्छा सुधार किया
  • यह SFT memorizes while RL generalizes से मेल खाता है
• distribution के नज़रिए से यह व्याख्या भी संभव है कि programmatically बनाए गए dataset और मूल model distribution के बीच अंतर जितना बड़ा होगा, Forgetting उतनी अधिक होगी
  • SFT, मूल distribution से काफ़ी अलग data पर मज़बूती से fit होने के कारण model distribution को काफ़ी बदल देता है
  • rSFT और DPO में self-distilled data मूल distribution के अधिक क़रीब होने से बदलाव अपेक्षाकृत कम तीखे होते हैं
  • Catastrophic Forgetting की मात्रा, मूल distribution और task-training data distribution के अंतर के अनुपात में हो सकती है

अतिरिक्त प्रयोग

• RL with LoRA: क्या full fine-tuning ज़रूरी है

  • यह काम नया ज्ञान जोड़ने से ज़्यादा मौजूदा कोड को संशोधित करने की क्षमता के style adjustment के करीब है, इसलिए जाँचा गया कि क्या LoRA भी पर्याप्त हो सकता है
  • rank 1 पर Pass@1 0.738, Norm. Levenshtein 0.166, Added CC 0.676, LiveCodeBench Δ -0.022
  • rank 8 पर 0.775 / 0.112 / 0.426 / -0.022
  • rank 16 पर Pass@1 0.805 / 0.087 / 0.328 / -0.005
  • rank 32 पर 0.795 / 0.065 / 0.235 / -0.011
  • rank 64 पर 0.797 / 0.051 / 0.160 / +0.001
  • Full RL का सर्वश्रेष्ठ मॉडल 0.782 / 0.050 / 0.185 / +0.006 था
  • rank 64 LoRA, Levenshtein में Full RL के लगभग बराबर पहुँचा और Added CC में उससे बेहतर निकला
  • rank बढ़ने के साथ Levenshtein और Added CC, 1 से 64 तक monotonically decrease हुए
  • बड़ा सुधार शुरुआती चरण में केंद्रित था: rank 1→16 में Levenshtein 0.166→0.087 तक तेज़ी से घटा, जबकि 16→64 में यह 0.087→0.051 तक धीरे-धीरे कम हुआ
  • rank 1 और 8 पर accuracy और minimal editing के बीच trade-off दिखा, और संभव है कि दोनों reward functions को साथ सीखने की capacity कम होने के कारण मॉडल ज़्यादा reward वाले edit minimization की ओर झुक गया हो
  • जिन कार्यों में क्षमता पहले से मौजूद है, उनमें style-level behavior change के लिए कम अतिरिक्त parameters भी पर्याप्त हो सकते हैं, और एक बिंदु के बाद अतिरिक्त capacity का लाभ घटने लगता है

• reward hacking नोट

  • शुरुआती reward function में एक bug था, जिसमें जिन rollouts में एक भी successful execution नहीं था उन्हें 0 score दिया जाता था
  • क्योंकि Levenshtein का sign पलटकर उसे “जितना बड़ा उतना अच्छा” रूप में बदला गया था, यह 0 score उल्टा successful executions से भी अधिक reward बन जाता था
  • इसके बावजूद Full RL ने task सीख लिया, लेकिन सिर्फ LoRA में reward hacking दिखा, जहाँ मॉडल functionally correct code ही आउटपुट नहीं करता था, और इसी से environment inspection शुरू हुई
  • reward function को ठीक करने के बाद Full RL के नतीजे केवल थोड़ा और बेहतर हुए

• क्या यह बड़े मॉडल्स तक भी scale होता है

  • यही out-of-domain RL recipe Qwen3 14B पर लागू की गई
  • Baseline 14B में Pass@1 0.770, Norm. Levenshtein 0.136, Added CC 0.315 था
  • RL लागू करने के बाद Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011 के साथ समग्र सुधार दिखा
  • parameters की संख्या बढ़ने पर भी Pass@1 में वृद्धि, Levenshtein में कमी, Added Cognitive Complexity में कमी, और Catastrophic Forgetting की अनुपस्थिति साथ-साथ बनी रही
  • यह इस संभावना को मज़बूत करता है कि minimal code editing के लिए RL recipe कई model scales तक फैल सकती है

अंतिम निष्कर्ष

• Over-Editing एक व्यापक और मापने योग्य समस्या के रूप में सामने आता है
  • frontier coding models में सही तरीके से ठीक करने की क्षमता और न्यूनतम बदलाव के साथ ठीक करने की क्षमता अलग-अलग दिखाई देती हैं
  • खासकर GPT-5.4 में default setting पर अपेक्षाकृत अधिक rewriting की प्रवृत्ति मज़बूत दिखती है, जबकि Opus 4.6 एक मज़बूत baseline दिखाता है
• सिर्फ explicit prompts से भी faithful editing की दिशा में काफ़ी हद तक ले जाया जा सकता है
  • खासकर reasoning models में डिफ़ॉल्ट रूप से ज़रूरत से ज़्यादा बदलाव करने की प्रवृत्ति होती है, लेकिन original preservation का निर्देश देने पर वे इसे बेहतर मानते हैं
  • GPT-5.4 ने भी reasoning mode में बड़ा सुधार दिखाया, जिससे उसकी instruction following क्षमता स्पष्ट रूप से मज़बूत दिखती है
  • Opus 4.6 में सुधार कम दिखना शायद इसलिए है क्योंकि उसका baseline performance पहले से ही ऊँचा है
• training के दृष्टिकोण से RL सबसे संतुलित समाधान के रूप में उभरता है
  • इसने अधिक faithful editing behavior सीखा, जबकि सामान्य coding ability को नुकसान नहीं पहुँचाया, और प्रभाव 4B तथा 14B दोनों Qwen3 मॉडलों में बना रहा
  • SFT कुछ खास corruption types पर मज़बूत था, लेकिन generalization और सामान्य क्षमता बनाए रखने में काफ़ी विफल रहा
• single-function bug-fix evaluation की सीमा SWE-Bench Pro जैसे अधिक agentic evaluations की तुलना में सीमित है, लेकिन यह वास्तविक परिस्थितियों में Over-Editing को मात्रात्मक रूप से पकड़ना कठिन था जैसी समस्या पर काम शुरू करने का एक प्रारंभिक बिंदु बनता है
  • minimal editing क्षमता का मूल्यांकन और सुधार, AI-generated code की समग्र गुणवत्ता सुधारने की दिशा में ले जा सकता है