Fable 5, Opus 4.8 और Sonnet 4.6: अपने कोड पर LLM की ईमानदार तुलना कैसे करें

जब कोई नया मॉडल आता है, तो घोषणा इस सवाल का जवाब देती है कि «यह बेंचमार्क पर कितना बेहतर है» — और उस एकमात्र सवाल का जवाब नहीं देती जो मुझे दिलचस्प लगता है: यह मेरे काम में क्या बदलेगा। मैंने एक नियंत्रित प्रयोग किया: तीन Claude मॉडल — Fable 5, Opus 4.8 और Sonnet 4.6 — को इस ब्लॉग के कोडबेस के ऑडिट के लिए शब्दशः एक ही कार्य मिला, हर एक को रिपॉज़िटरी की अलग प्रति में, पहले से सहमत मूल्यांकन रूब्रिक के साथ। लेख में — वह कार्यप्रणाली जिसे किसी भी प्रोजेक्ट पर दोहराया जा सकता है, परिणाम, और अलग से — कि प्रयोग दो बार कैसे टूटा और इसने क्या सिखाया।

बेंचमार्क मेरे सवाल का जवाब क्यों नहीं देते

सार्वजनिक बेंचमार्क में दो समस्याएँ हैं, और दोनों मूलभूत हैं। पहली — डेटा संदूषण: परीक्षण के उदाहरण प्रशिक्षण सेट में रिस जाते हैं, और मॉडल कार्य हल करने के बजाय आंशिक रूप से जवाब «याद» कर लेता है। यह कोई मामूली संदेह नहीं, बल्कि पूरी शोध दिशा का विषय है: Xu और सह-लेखकों का सर्वेक्षण (2024) बेंचमार्क संदूषण के शोधों को व्यवस्थित करता है, और EMNLP 2025 का सर्वेक्षण उद्योग की प्रतिक्रिया दर्ज करता है — स्थिर परीक्षणों से गतिशील रूप से उत्पन्न परीक्षणों की ओर संक्रमण।

दूसरी समस्या सरल है: बेंचमार्क मेरा कार्य नहीं मापता। मुझे ऐसा मॉडल नहीं चाहिए जो ओलंपियाड के सवाल सबसे अच्छे हल करे। मुझे ऐसा मॉडल चाहिए जो मेरे Laravel ब्लॉग में वास्तविक बग ढूँढे, गैर-मौजूद बग न गढ़े, और साबित करे कि उसका फिक्स काम करता है।

इससे एक सरल विचार निकलता है: मॉडलों की तुलना के लिए सबसे अच्छा परीक्षण मंच — अपना ही प्रोजेक्ट। इसके कोड का ऐसा संयोजन प्रशिक्षण सेट में नहीं है, इस पर कार्य ठीक वही हैं जिनके लिए मैं भुगतान करता हूँ, और परिणाम मैं हाथ से जाँच सकता हूँ, क्योंकि मैं यह कोड जानता हूँ।

प्रयोग का डिज़ाइन: एक प्रॉम्प्ट, तीन अलग दुनियाएँ

तीनों मॉडलों के लिए कार्य शब्दशः एक ही था — केवल ब्रांच का नाम और परिणाम फ़ोल्डर अलग थे। चार चरण: ब्लॉग की द्विभाषी लेख प्रणाली का ऑडिट, हर निष्कर्ष के प्रमाण के साथ файл:строка के रूप में कोड उद्धरण सहित; तीन मुख्य निष्कर्षों के लिए समाधानों का चयन, समझौतों के विवरण के साथ; एक फिक्स का कार्यान्वयन स्व-जाँच के साथ; रूसी और अंग्रेज़ी में परिणामों पर टिप्पणी। पूरा इंजीनियरिंग कार्य-चक्र, न कि अलग-थलग «प्रश्न-उत्तर» — यही दृष्टिकोण Anthropic भी सुझाता है: एजेंटों का मूल्यांकन वास्तविक उत्पाद के कार्यों पर करें, लॉन्च से पहले सहमत रूब्रिक के अनुसार।

तीन नियमों ने तुलना को ईमानदार बनाया:

पृथक्करण। हर मॉडल अलग git worktree में काम करता था — कार्यशील निर्देशिका की अपनी प्रति, अपनी ब्रांच के साथ। मॉडल शारीरिक रूप से एक-दूसरे के परिणाम नहीं देख सकते थे और न ही एक-दूसरे को बाधित कर सकते थे।

मतिभ्रम से सुरक्षा — प्रॉम्प्ट में ही। कार्य की मुख्य पंक्ति: «गढ़ा हुआ निष्कर्ष (गैर-मौजूद कोड, गलत पंक्ति) निष्कर्ष के अभाव से बुरा है»। इस प्रोत्साहन के बिना, जिस मॉडल से समस्याएँ ढूँढने को कहा जाए, वह उन्हें हर हाल में «ढूँढ» लेता है। इसके साथ — हर निष्कर्ष को मैन्युअल जाँच से गुज़रना अनिवार्य है।

संकेतों को अंक से बाहर रखना। रिपॉज़िटरी में CLAUDE.md है, जिसमें प्रोजेक्ट के ज्ञात गड्ढे बताए गए हैं — उदाहरण के लिए, एसेट्स के सापेक्ष पथ, जो भाषा-उपसर्ग वाले URL पर टूट जाते हैं। तीनों मॉडल यह फ़ाइल पढ़ते हैं, इसलिए ऐसे निष्कर्ष «मुफ़्त» हैं: वे सावधानी के लिए गिने जाते हैं, गहराई के लिए नहीं।

रूब्रिक: केवल वही आँकें जो हाथ से जाँचा जा सके

लॉन्च से पहले मैंने पाँच-पाँच अंकों के छह अक्ष तय किए: ऑडिट की सटीकता (निष्कर्षों के नमूने की файл:строкаके अनुसार मैन्युअल जाँच), गहराई (पुष्ट निष्कर्ष जो संकेतों में नहीं हैं), समझौतों पर तर्क की गुणवत्ता, कोड और स्व-जाँच की वास्तविकता, रूसी और अंग्रेज़ी पाठ की गुणवत्ता, अनुशासन (मनुष्य से शून्य प्रश्न, प्रतिबंधों का एक भी उल्लंघन नहीं)। सिद्धांत वही है जो अच्छे कोड-रिव्यू का है: अक्ष जितना कम स्वाद पर और जितना अधिक सत्यापन-योग्य तथ्य पर टिका हो, उतना ही उस पर भरोसा किया जा सकता है।

पहली बार सब कैसे टूटा

पहला रन मैंने गलत किया — और यही प्रयोग का सबसे स्थानांतरणीय हिस्सा निकला। मैंने एक ही रिपॉज़िटरी फ़ोल्डर में समानांतर तीन इंटरैक्टिव सत्र खोले। कुछ मिनटों में कार्यशील ट्री में ऐसे अन-कमिटेड बदलाव पड़े जिन्हें किसी को जिम्मेदार नहीं ठहराया जा सकता था: साझा checkout का अर्थ है कि जब एक सत्र git checkout -bकरता है, ब्रांच तीनों के लिए बदल जाती है, और उनके बदलाव और कमिट आपस में मिल जाते हैं। एक सत्र ने इसके अलावा git stash कर दिया और उसमें सब कुछ बहा दिया — मेरी अपनी फ़ाइलें भी, जिनका प्रयोग से कोई संबंध नहीं था।

“एक ही फ़ोल्डर में समानांतर AI-एजेंट समानांतर प्रयोग नहीं हैं। यह तीन लेखकों वाला एक बड़ा संघर्ष है।”

– वह निष्कर्ष जिसकी कीमत मुझे पुनः-प्रारंभ से चुकानी पड़ी

दो सत्रों के परिणामों को अनुपयुक्त मानना पड़ा: भले ही वे अंत तक काम पूरा कर लेते, मैं ईमानदारी से यह नहीं कह पाता कि मैं किसके संशोधनों का मूल्यांकन कर रहा हूँ। दूसरा रन — अलग-अलग worktree में — टैरिफ़ की सीमाओं से टकरा गया: दो एजेंट शुरुआत में ही मर गए, और तीसरा अटक गया, फिर भी इंटरफ़ेस में «काम करता हुआ» दिखता रहा। निदान स्टेटस इंडिकेटर ने नहीं, बल्कि फ़ाइल सिस्टम ने किया: बीस मिनट में उसकी वर्किंग कॉपी में एक भी फ़ाइल नहीं आई। यह दूसरा स्थानांतरणीय सबक है: एजेंट की जीवंतता डिस्क पर हुए बदलावों से जाँची जाती है। पुनः आरंभ के बाद तीनों मॉडलों ने समान परिस्थितियों में पूरा चक्र पूरा किया।

परिणाम: मॉडल कहाँ समान हैं और कहाँ भिन्न

सबसे महत्वपूर्ण परिणाम वह है जो नहीं हुआ: किसी भी मॉडल में कोई भ्रम नहीं है. मैंने प्रत्येक की तीन या अधिक खोजों को मैन्युअल रूप से जाँचा — सभी उद्धरण और पंक्ति संख्याएँ अक्षर तक सटीक हैं। ऑडिट कार्यों के लिए यह विश्वास की मुख्य सीमा है, और तीनों ने इसे पार किया।

आगे अंतर शुरू होते हैं:

	Fable 5	Opus 4.8	Sonnet 4.6
पुष्ट खोजें	11	5	9
गैर-तुच्छ अद्वितीय	3	1	2
फ़िक्स की स्व-जाँच	अस्थायी डेटाबेस पर इंटीग्रेशन रेंडर, xmllint, किसी और के विफल टेस्ट का एट्रिब्यूशन	लिंटर + रेंडर; अपनी ही बग पकड़ी	केवल लिंटर और रूट की सूची
टोकन / समय	164k / 21 मिनट	101k / 12 मिनट	131k / 12 मिनट
रूब्रिक के अनुसार कुल (30 में से)	30	24	25,5

गुणात्मक अंतर अंकों से अधिक सूचनाप्रद हैं। Opus 4.8 — एकमात्र जिसने sitemap में टूटा हुआ शीर्षक Content-Type नहीं देखा (अन्य दो ने इसे पाया) और उसे अपने ही फ़िक्स में छोड़ दिया; और उसके रूसी पाठ में एक अंग्रेज़ी शब्द रिस गया — «и even путь к картинке»। Sonnet 4.6 ने सही फ़िक्स किया, लेकिन उसकी स्व-जाँच औपचारिक थी: चलाने के बजाय लिंटर। Fable 5 स्व-जाँच में ही अलग दिखी: उसने पाया कि php मेरी मशीन पर मुख्य निर्देशिका पर माउंट किए गए docker-कंटेनर का रैपर है, सभी जाँचों को एकबारगी कंटेनरों के माध्यम से पुनर्गठित किया और अपना फ़िक्स अस्थायी डेटाबेस पर इंटीग्रेशन रूप से चलाया। «मैंने किया» और «मैंने साबित किया कि किया» के बीच का अंतर — यही एजेंटिक कार्यों के लिए सबसे विभेदक अक्ष है।

एक और उपयोगी संकेत — अभिसरण: तीनों मॉडलों ने स्वतंत्र रूप से एक ही sitemap समस्या को मुख्य खोज बताया। जब स्वतंत्र ऑडिटर शीर्ष-खोज पर सहमत होते हैं, तो यह अंतर-विशेषज्ञ सहमति का सस्ता विकल्प है: समस्या लगभग निश्चित रूप से वास्तविक है।

प्रतिभागियों में से एक निर्णायक

रूब्रिक के अनुसार मूल्यांकन Fable 5 ने किया — वही मॉडल जो तुलना में शामिल था। यह पद्धतिगत छिद्र है, और इसके बारे में सीधे बात करनी चाहिए: LLM-निर्णायक अपने ही पाठों को व्यवस्थित रूप से अधिक अंक देते हैं, और यह प्रवृत्ति उतनी ही प्रबल होती है जितनी बेहतर मॉडल अपने पाठों को पहचानता है — यह Panickssery और सह-लेखकों के NeurIPS 2024 के काममें दिखाया गया है। पूर्वाग्रह को दो तरह से कम किया जा सकता है, और मैंने दोनों का उपयोग किया: पहला, रूब्रिक को स्वाद-अक्षों से अधिकतम सत्यापन योग्य तथ्यों की ओर स्थानांतरित करना — पंक्ति सटीकता, फ़िक्स की पूर्णता, रिसा हुआ विदेशी शब्द निर्णायक की पसंद पर निर्भर नहीं करते; दूसरा, संघर्ष को स्पष्ट रूप से घोषित करना और विवादित अक्षों को किसी अन्य मॉडल या व्यक्ति की क्रॉस-जाँच के लिए देना। मेरे कुल का व्यक्तिपरक अक्ष — पाठ की गुणवत्ता, तर्क की गुणवत्ता — इस सुधार के साथ पढ़ा जाना चाहिए।

ईमानदारी की सीमाएँ

प्रति मॉडल एक रन — यह n=1 है: एक-दो अंकों के अंतर का कोई अर्थ नहीं, केवल गुणात्मक अंतरालों पर भरोसा करना चाहिए — छूटी हुई बग, स्व-जाँच की गहराई। प्रयोग एक ही डोमेन में एक कार्य पर तीन मॉडलों को मापता है; इससे यह नहीं निकलता कि «Fable 5 समग्र रूप से बेहतर है»। और कीमत याद रखनी चाहिए: शीर्ष मॉडल ने सबसे किफ़ायती प्रतिभागी की तुलना में 1,6 गुना अधिक टोकन और लगभग दोगुना समय खर्च किया, और उसका टोकन मूल्य सूची के अनुसार अपने आप में भी महँगा है — नियमित कार्यों के लिए यह सरल मॉडलों के पक्ष में एक ठोस तर्क है।

मैं अपने लिए क्या ले जाता हूँ

पद्धति एक संक्षिप्त चेकलिस्ट में सिमट गई, जो किसी भी प्रोजेक्ट और किसी भी मॉडल के लिए काम करती है:

• परीक्षण कार्य — अपने कोड पर वास्तविक काम का पूरा चक्र, न कि कृत्रिम समस्या।
• सभी के लिए एक प्रॉम्प्ट, अलग-अलग worktree के माध्यम से अलगाव, परिणाम — अलग शाखाओं में।
• प्रॉम्प्ट में भ्रम की स्पष्ट कीमत: गढ़ी हुई खोज खोज के अभाव से बदतर है।
• सभी के लिए उपलब्ध संकेत (दस्तावेज़ीकरण, रिपॉज़िटरी में नोट्स) गहराई के मूल्यांकन से बाहर रखे जाते हैं।
• रूब्रिक रन से पहले तय होती है और सत्यापन योग्य तथ्यों पर आधारित होती है, न कि प्रभाव पर।
• खोजों के नमूने हाथ से जाँचें; स्वतंत्र मॉडलों में शीर्ष-खोजों का मेल — उनकी वास्तविकता का संकेत।
• निर्णायक-प्रतिभागी — घोषित संघर्ष: विवादित अक्ष क्रॉस-मूल्यांकन के लिए दें।
• एजेंट की जीवंतता डिस्क से जाँचें, इंटरफ़ेस के इंडिकेटर से नहीं।

एक बोनस जो योजना में नहीं था: प्रयोग ने स्वयं लागत निकाल ली। तीन स्वतंत्र ऑडिटों ने ब्लॉग में वास्तविक समस्याएँ पाईं — अंग्रेज़ी पृष्ठों के बिना sitemap से लेकर कंट्रोलर में मृत क्वेरीज़ तक — और दो तैयार फ़िक्स पहले से शाखाओं में प्रोड में स्थानांतरण की प्रतीक्षा में पड़े हैं। अपने कोड पर मॉडलों की तुलना, बेंचमार्क पढ़ने के विपरीत, केवल राय नहीं छोड़ती।

स्रोत और संदर्भ

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — बेंचमार्क संदूषण समस्या का व्यवस्थितकरण; अपने कोड पर परीक्षण के पक्ष में मुख्य तर्क।
• डेटा संदूषण के अंतर्गत LLMs का बेंचमार्किंग: स्थिर से गतिशील मूल्यांकन तक (EMNLP 2025) — उद्योग स्थिर परीक्षणों से गतिशील परीक्षणों की ओर कैसे बढ़ रहा है; मेरा प्रयोग गतिशील परीक्षण का एक विशेष मामला है।
• AI एजेंटों के लिए मूल्यांकन को सरल बनाना (Anthropic Engineering, 2026) — एजेंटों के मूल्यांकन का व्यवहार: वास्तविक उत्पाद से कार्य, सत्यापन योग्य रूब्रिक, प्रक्षेपवक्र और परिणाम के बीच अंतर।
• LLM मूल्यांकनकर्ता अपनी ही पीढ़ियों को पहचानते और पसंद करते हैं (NeurIPS 2024) — मॉडल-न्यायाधीश स्वयं को अधिक अंक क्यों देता है और इसके बारे में क्या करना चाहिए।
• वर्कट्रीज़ के साथ समानांतर सत्र चलाएँ (Claude Code Docs) — समानांतर एजेंट सत्रों को अलग करने का मानक तंत्र, जिसके बिना प्रयोग का पहला रन ही विफल हो गया।