6.7% से 68.3% सफलता दर: 10x का फ़र्क मॉडल ने नहीं, harness ने बनाया

Grok Code Fast की एक कोडिंग बेंचमार्क में सफलता दर 6.7% थी। मॉडल बदले बिना, सिर्फ एक एडिटिंग फ़ॉर्मेट बदला और यह 68.3% हो गई। मॉडल के एक भी पैरामीटर को छुआ नहीं गया।

छुट्टियों के दौरान मैंने खुद एजेंट चलाए और ऐसा ही अनुभव हुआ। मॉडल रिलीज़ की रफ़्तार साँस रोकने वाली है, लेकिन व्यवहार में प्रदर्शन को चरम रूप से अलग करने वाली चीज़ मॉडल खुद नहीं था। वह था मॉडल को लपेटने वाला harness यानी system prompt, टूल कॉन्फ़िगरेशन और middleware का संयोजन।

एक ही मॉडल, अलग-अलग रैंकिंग

LangChain टीम ने अपने खुद के कोडिंग एजेंट से Terminal Bench 2.0 चलाया। GPT-5.2-Codex को वैसा ही रखते हुए सिर्फ system prompt, टूल कॉन्फ़िगरेशन और middleware बदला। स्कोर 52.8 से 66.5 हो गया और leaderboard में top 30 से बाहर से top 5 में प्रवेश हो गया। मॉडल ट्रेनिंग पर खर्च: शून्य।

मुख्य बात थी reasoning budget का वितरण। सभी tasks पर xhigh एकसमान लगाने से परिणाम 53.9% पर ही रहा, लेकिन task की कठिनाई के अनुसार xhigh-high-xhigh में बाँटने से 66.5% तक पहुँचा। timeout से फ़ेल होने वाली समस्याएँ इसी वितरण रणनीति से हल हुईं। एक ही मॉडल, एक ही token budget, बस allocation अलग था।

एडिटिंग फ़ॉर्मेट के पीछे छिपी असली काबिलियत

एक open source एजेंट डेवलपर ने hashline नाम का एडिटिंग तरीका बनाया। फ़ाइल पढ़ते समय हर लाइन को 2-3 अक्षरों का hash tag मिलता है, और संशोधन के समय मॉडल सिर्फ उस tag को संदर्भित करता है।

पुराने तरीके में मॉडल को एक भी अक्षर गलत किए बिना मूल टेक्स्ट को फिर से लिखना होता था। एक भी space गलत होने पर fail हो जाता। जिसने कोडिंग एजेंट खुद इस्तेमाल किया हो, वह बार-बार आने वाली “String not found” error की तकलीफ़ जानता है। hashline इस समस्या को संरचनात्मक रूप से दरकिनार करता है।

नतीजे नाटकीय थे। Grok Code Fast 6.7% से 68.3% पर पहुँचा और Grok 4 Fast के output tokens 61% कम हो गए। GPT-4 Turbo सिर्फ फ़ॉर्मेट बदलने से 26% से 59% हो गया और Gemini 3 Flash ने अपना पिछला सर्वोच्च रिकॉर्ड 5 प्रतिशत अंक से पार किया। मॉडल ट्रेनिंग पर कोई खर्च नहीं, बस एक एडिटिंग इंटरफ़ेस बदला।

validation loop नहीं तो एजेंट पहले जवाब पर ही रुक जाता है

एक बेहद आम failure pattern है। एजेंट कोड लिखता है, लिखा हुआ फिर से पढ़ता है, ठीक लगता है और वहीं रुक जाता है। एक भी test run किए बिना।

LangChain टीम ने एजेंट के बंद होने से ठीक पहले task specification के विरुद्ध validation ज़बरदस्ती करने वाला middleware डाला। एक ही फ़ाइल को बार-बार edit करने वाले “doom loop” को भी एक अलग middleware से detect कर approach पर पुनर्विचार के लिए प्रेरित किया जाता है। इन दोनों उपायों के बिना score में बढ़ोतरी काफ़ी कम होती। एजेंट में directory structure और उपलब्ध tools पहले से inject करना और time budget warning से validation phase में प्रवेश के लिए प्रेरित करना भी प्रभावशाली रहा।

सस्ते मॉडल harness के प्रति ज़्यादा संवेदनशील होते हैं

MiniMax M2.5 और Kimi K2.5 तेज़ हैं और एजेंट टूल उपयोग में माहिर हैं। कीमत भी बड़े मॉडलों की तुलना में काफ़ी कम है। बदले में, बुनियादी ज्ञान अमेरिकी बड़े मॉडलों से कम है। MiniMax को शुरू से ही एजेंट-विशेष मॉडल के रूप में train किया गया महसूस होता है। कम संसाधनों के कारण सामान्य की जगह विशेष मॉडल चुना गया, और सस्ती कीमत की बदौलत Openclaw जैसे platforms पर इसका उपयोग तेज़ी से बढ़ रहा है।

hashline benchmark के नतीजे देखें तो कमज़ोर मॉडलों में फ़ॉर्मेट बदलाव से performance में उतार-चढ़ाव बेहद चरम था। MiniMax की hashline लागू होने के बाद सफलता दर दोगुने से भी ज़्यादा हो गई। पूरे benchmark की लागत करीब $300 थी।

benchmark व्यावहारिक काम नहीं है

एक बात ध्यान देने वाली है। Terminal Bench हो या hashline benchmark, ये नियंत्रित वातावरण में मापे गए आँकड़े हैं। असली production में codebase का आकार, dependency conflicts, अस्पष्ट आवश्यकताएँ जैसे कहीं ज़्यादा variables होते हैं। benchmark में 66.5% score करने वाला एजेंट 1 लाख लाइन के legacy project में भी वही प्रदर्शन देगा, यह अभी तक सत्यापित नहीं है। harness optimization प्रभावी है यह स्पष्ट है, लेकिन benchmark रैंकिंग को सीधे व्यावहारिक प्रदर्शन में बदलना जोखिम भरा है।

फिर भी दिशा स्पष्ट है। एक ऐसा दायरा ज़रूर है जहाँ मॉडल चुनाव की जगह harness design ROI में आगे रहता है। आज जो benchmark रैंकिंग हम देख रहे हैं उसका बड़ा हिस्सा मॉडल की काबिलियत नहीं बल्कि harness की गुणवत्ता है।