एक पिछली पोस्ट में हमने एक दावा किया था और यह माना था कि हमने इसे परखा नहीं है: कि हमारी फ्रंट-एंड एजेंट स्किल्स को एक फ्रंटियर मॉडल की तुलना में कमज़ोर, सस्ते मॉडलों की ज़्यादा मदद करनी चाहिए। तर्क ठोस था — जो ज्ञान आपको सौंपा जाता है, वह उस मॉडल के लिए कम मूल्यवान होता है जो पहले से ही उसे जानता है — पर तर्क प्रमाण नहीं होता। इसलिए हमने प्रयोग किया। यह वही है जो आँकड़े कहते हैं।
सेटअप
हमने वही बिल्ड कार्य दो कमज़ोर एग्ज़िक्यूटरों — Haiku 4.5 और Sonnet 4.6 — के साथ दोबारा चलाए, स्किल्स के साथ और उनके बिना, और उन्हें उन्हीं उपकरणों से आँका जिनका हमने फ्रंटियर मॉडल (Opus 4.8) पर इस्तेमाल किया था। जो संख्या मायने रखती है वह है लिफ्ट: स्किल आउटपुट को कितना बेहतर बनाती है, हर मॉडल स्तर पर मापी गई।
दो परीक्षण: सात ज्ञान स्किल्स (वस्तुनिष्ठ सटीकता पर आँकी गईं), और प्रक्रिया "विज़ुअल पॉलिश" स्किल (गुणवत्ता पर बिना पहचान बताए आँकी गई)।
नतीजा 1: मॉडल जितना कमज़ोर, लिफ्ट उतनी बड़ी
सटीकता के मामले में, पैटर्न साफ़ और एकदिशीय है:
| मॉडल | स्किल्स के बिना | स्किल्स के साथ | लिफ्ट |
|---|---|---|---|
| Opus 4.8 (फ्रंटियर) | 95.8% | 100% | +4.2 अंक |
| Sonnet 4.6 | 91.7% | 100% | +8.3 अंक |
| Haiku 4.5 (सबसे छोटा) | 87.5% | 100% | +12.5 अंक |
स्किल हर स्तर को 100% तक खींच लाती है — पर मॉडल जितना कमज़ोर, वह उतना बड़ा अंतर पाटती है। लिफ्ट फ्रंटियर मॉडल से सबसे छोटे मॉडल तक लगभग तीन गुना हो जाती है। बिना सहायता वाले कमज़ोर मॉडल ठीक उन्हीं परंपराओं को छोड़ते रहे जिन्हें स्किल्स कोड करती हैं (एक सुसंगत साइज़िंग रणनीति, सुगम्यता का सम्मान करने वाले ब्रेकपॉइंट, मोबाइल-नेव स्थिति, प्रदर्शन संकेत); स्किल ने हर बार उन्हें बहाल कर दिया। परिकल्पना की पुष्टि हुई।
नतीजा 2: रुचि नीचे तक पहुँचती है — सत्यापन नहीं
गुणवत्ता स्किल ज़्यादा दिलचस्प थी। बिना पहचान बताए आँके जाने पर, स्किल-युक्त आउटपुट ने कमज़ोर मॉडलों पर 4 में से 3 आमने-सामने की जोड़ियाँ जीतीं (फ्रंटियर मॉडल, जो पूरा रेंडर लूप चला रहा था, अपनी दोनों जोड़ियाँ जीत चुका था)। समीक्षक ने फिर से बिना-सहायता वाले संस्करणों को सामान्य-AI डिफ़ॉल्ट और स्किल-युक्त संस्करणों को "कस्टम-डिज़ाइन किया गया" बताया।
"जीतने वाले डिज़ाइन आत्मविश्वासी पैलेट और संपादकीय टाइप को तरजीह देते हैं; हारने वाले सामान्य डिफ़ॉल्ट पर टिके रहते हैं — बैंगनी/इंडिगो ग्रेडिएंट, ग्रेडिएंट हेडलाइन टेक्स्ट, एक जैसे केंद्रित कार्ड।"
पर एकमात्र हार पूरे अध्ययन का सबसे उपयोगी नतीजा है। सबसे छोटा मॉडल, स्किल के साथ भी, एक जोड़ी हार गया — सामान्य दिखने के कारण नहीं, बल्कि एक टूटे-कॉन्ट्रास्ट वाले कॉल-टू-एक्शन (सफ़ेद पृष्ठभूमि पर सफ़ेद टेक्स्ट) को भेजने के कारण। यह ठीक वैसा ही निष्पादन दोष है जिसे स्किल का रेंडर-और-रिफाइन लूप रेंडर किए गए पृष्ठ को देखकर पकड़ने के लिए बना है — और एक कमज़ोर, ब्राउज़र-रहित मॉडल उस लूप को भरोसेमंद ढंग से नहीं चला सका।
तो जैसे-जैसे मॉडल कमज़ोर होते हैं, स्किल के दो हिस्से अलग-अलग व्यवहार करते हैं: भेजी गई रुचि (एक जाँची-परखी डिज़ाइन प्रणाली, एंटी-पैटर्न रक्षक) निचले स्तर तक पहुँचती है और आउटपुट को सामान्य दिखने से रोकती है। सत्यापन (रेंडर, आलोचना, सुधार) नहीं पहुँचता — इसे एक ब्राउज़र और स्क्रीनशॉट को आँकने के लिए पर्याप्त क्षमता, दोनों की ज़रूरत होती है।
हमने क्या बदला
निष्कर्षों का एक स्पष्ट समाधान है: अगर कोई कमज़ोर मॉडल देखने-और-सुधारने वाला लूप नहीं चला सकता, तो उसे एक सत्यापन-आधार दें जो मॉडल के निर्णय पर निर्भर न हो। इसलिए हमने पॉलिश स्किल में जोड़ा:
- एक निर्भरता-रहित स्वचालित गुणवत्ता गेट — एक स्क्रिप्ट जो निर्धारक दोषों (गायब फ़ोकस स्टेट, कोई रिड्यूस्ड-मोशन गार्ड नहीं, गायब व्यूपोर्ट टैग, JS तक छिपी सामग्री, सामान्य-AI पैलेट, चपटी छायाएँ, स्पष्ट कॉन्ट्रास्ट विफलताएँ) को चिह्नित करती है और भेजने से पहले पास होनी चाहिए। परीक्षण में इसने सही ढंग से सामान्य बेसलाइनों को विफल किया और संदर्भ पृष्ठ को पास किया।
- एक परिदृश्य मैट्रिक्स — मॉडल की मज़बूती और ब्राउज़र उपलब्धता के हर संयोजन के लिए कौन-सा सत्यापन चलाना है, जिसमें स्वचालित गेट वह स्थिरांक है जो हर मामले में बना रहता है।
यह गेट एक अनुमानी है, रेंडरर नहीं — यह असली पिक्सेल कॉन्ट्रास्ट नहीं देख सकता — इसलिए जब ब्राउज़र उपलब्ध होता है तब पूरी रेंडर जाँच फिर भी चलती है। पर यह "मुझे लगता है यह ठीक है" को एक जाँचे गए नतीजे में बदल देता है, चाहे मॉडल कितना भी सक्षम क्यों न हो।
टीमों के लिए इसका क्या मतलब है
- ज्ञान स्किल्स सस्ते मॉडलों पर बड़ी जीत हैं — शायद उनका सबसे अच्छा उपयोग-मामला। अगर आप उत्पादन में कोई छोटा या बजट मॉडल चलाते हैं, तो अच्छी तरह बनाई गई स्किल्स से ही आपकी बहुत सी गुणवत्ता आती है।
- फ्रंटियर मॉडल पर वैसा ही होने की उम्मीद न करें — वह पहले से ही परंपराओं को जानता है, इसलिए एक सटीकता स्किल उसे मुश्किल से हिला पाती है।
- भेजी गई रुचि यात्रा करती है; स्व-सत्यापन नहीं। एक डिज़ाइन प्रणाली किसी भी मॉडल के आउटपुट को उठाती है; देखने-और-सुधारने वाले लूप को क्षमता और एक ब्राउज़र की ज़रूरत होती है।
- हर स्तर को एक स्वचालित गेट दें। यही वह तरीका है जिससे आप एक सस्ते मॉडल को वह बग भेजने से रोकते हैं जिसे वह खुद नहीं देख सकता।
SplatDev इसे कैसे लागू करता है
हम उस मॉडल के अनुरूप AI-संवर्धित विकास प्रणालियाँ बनाते हैं जिसे आप वास्तव में चलाते हैं — फ्रंटियर हो या बजट — उन स्किल्स, रक्षकों और स्वचालित गेटों के साथ जो उस स्तर पर आउटपुट को भरोसेमंद बनाते हैं। और हम इसे मापते हैं: फ़ायदे कहाँ हैं, कहाँ नहीं, और अंतर पाटने के लिए क्या जोड़ना है।
कोई लागत-संवेदनशील मॉडल चला रहे हैं और उससे ज़्यादा गुणवत्ता चाहते हैं?
SplatDev से संपर्क करें — AI के साथ बेहतर बनाएँ
या हमें [email protected] पर ईमेल करें