Android Bench से एजेंट के कोड जनरेशन के बारे में अहम जानकारी

तोमाश म्लिनारिच

नमस्ते.

चलिए, शुरू करते हैं.

हमने मार्च में Android Bench लॉन्च किया था. यह हमारा डेटा सेट और लीडर बोर्ड है. इसका इस्तेमाल, Android डेवलपमेंट से जुड़े टास्क पर एलएलएम की परफ़ॉर्मेंस को मेज़र करने के लिए किया जाता है.

तब से, हमने इसे कई नए मॉडल के साथ आज़माया है.

पिछले महीने ही, हमने Android Bench 2.0 रिलीज़ किया है.

हालांकि, इसे लॉन्च हुए कुछ ही महीने हुए हैं, लेकिन एआई की दुनिया में यह समय बहुत लंबा लगता है.

मेरा नाम तोमाश है. मैं आपको Android Bench के हमारे सफ़र के बारे में बताऊंगा. साथ ही, यह भी बताऊंगा कि हम इस मुकाम तक कैसे पहुंचे.

चलिए, 1.0 से शुरू करते हैं.

हमने 1.0 में, ओपन सोर्स रिपॉज़िटरी से असल दुनिया की समस्याएं ली थीं.

हमने GitHub प्रोजेक्ट को GitHub से जुड़ी समस्याओं, उन समस्याओं को हल करने वाले पुल के अनुरोधों, और समाधानों की पुष्टि करने वाले टेस्ट के हिसाब से फ़िल्टर किया.

हम पुल रिक्वेस्ट को एआई मॉडल के लिए टास्क बकेट में बांटते हैं.

GitHub पर मौजूद समस्या, मॉडल के लिए निर्देश या प्रॉम्प्ट बन गई. हमने उन्हें पीआर से पहले की स्थिति में प्लांट किया.

मॉडल के कुछ काम करने के बाद, हमने टेस्ट लिए और उन्हें आउटपुट पर लागू किया. इससे हमें पास या फ़ेल होने का नतीजा मिला.

एआई की ओर से समस्या को हल करने की इस कोशिश को हम ट्रायल कहते हैं.

हम इसकी तुलना, उस पीआर में मौजूद इंसानों के बनाए गए समाधान से भी कर सकते हैं. इसे हम गोल्डन सलूशन भी कहते हैं.

यह तरीका, SWE-bench मानदंड से काफ़ी मिलता-जुलता है.

हमने 10,000 से ज़्यादा संभावित टास्क से शुरुआत की थी. हालांकि, इनमें से सभी टास्क सही नहीं थे.

कुछ प्रॉम्प्ट में अधूरे निर्देश थे या ज़रूरत से ज़्यादा जानकारी दी गई थी.

ऐसा हो सकता है कि टेस्ट, गोल्डन सलूशन से जुड़े हों या पीआर से पहले की स्थिति खराब हो गई हो.

इसलिए, हमें 100 सही टास्क चुनने के लिए, बार-बार समीक्षा करनी पड़ी.

समीक्षा के दौरान, हमने कुछ नतीजे पाने के लिए बेहतरीन मॉडल का इस्तेमाल किया.

हमने करीब 30% टास्क पूरे करने से शुरुआत की थी. इसे हम पास रेट कहते हैं.

इसके बाद, जब हमने आधिकारिक रिलीज़ के लिए डेटा सेट को लॉक किया, तब तक टॉप मॉडल पहले से ही करीब 70% पर थे.

हालांकि, यह एक महीने बाद की बात है.

इसके बाद, हमने हर महीने नए मॉडल का आकलन करने का प्लान बनाया. फिर हमने देखा कि वे कैसे बेहतर हो रहे हैं.

अगस्त में रिलीज़ हुए सबसे अच्छे मॉडल के लिए, पास रेट 92% था.

हमें पता था कि हमारा बार बहुत कम है और यह डेटा सेट संतृप्त है.

तोमाश म्लिनारिच

हालांकि, हमें इसका अंदाज़ा था. इसलिए, हम पहले से ही 2.0 पर काम कर रहे थे, जिसे हमने पिछले महीने रिलीज़ किया.

हमारा मकसद, Android पर असल दुनिया के मुश्किल टास्क को पूरा करने के लिए, बार को बढ़ाना है. साथ ही, आपको और डेवलपर को एलएलएम की परफ़ॉर्मेंस के बारे में जानकारी और पारदर्शिता देना है. इसके अलावा, मॉडल बनाने वाली कंपनियों को Android को प्राथमिकता देने के लिए बढ़ावा देना है. इसके लिए, उन्हें बेहतर मानदंड उपलब्ध कराना है, ताकि वे बेहतर तरीके से काम कर सकें.

साथ ही, यह विश्लेषण और नतीजे उपलब्ध कराता है, जो आपके और मॉडल बनाने वाले लोगों, दोनों के लिए फ़ायदेमंद होते हैं.

लेकिन हमें चालाकी, दृढ़ता, और धोखाधड़ी का भी ध्यान रखना होगा.

साथ ही, हमें कॉन्टैमिनेशन के जोखिम को रोकना होगा.

SWE-bench की कार्यप्रणाली में एक समस्या यह है कि सोर्स कोड असल में कितना ओपन है.

OpenAI ने एक लेख पब्लिश किया.

उन्होंने पाया कि मॉडल, निर्देशों के अगले शब्दों को पूरा कर सकते थे या किसी ऐसे टास्क को हल कर सकते थे जिसमें कोई ऐसी गड़बड़ी थी जो निर्देशों का हिस्सा नहीं थी.

उन्हें पता चला कि मॉडल बनाने वाली कंपनियां, ओपन-सोर्स कोड पर ट्रेनिंग दे रही हैं और SWE-bench में गड़बड़ी है.

इसलिए, 2.0 के लिए, हम कोड को बंद रखते हैं, ताकि उस पर ट्रेनिंग न दी जा सके.

हमने काम को चार वर्क स्ट्रीम में बांटा.

पहले तरीके में, हम ऐप्लिकेशन कन्वर्ज़न करते हैं. इसमें हम ओपन-सोर्स, Flutter, और React Native ऐप्लिकेशन लेते हैं. इसके बाद, एजेंट को उन्हें नेटिव Android सलूशन में बदलने के लिए कहते हैं.

इससे पता चलता है कि क्रॉस-प्लैटफ़ॉर्म से नेटिव पर माइग्रेट करने का ट्रेंड अब भी जारी है.

दूसरा वर्क स्ट्रीम, नई सुविधाओं और प्लैटफ़ॉर्म इंटिग्रेशन से जुड़ा था.

इन्हें पहले से मौजूद प्रोडक्शन कोड बेस में बनाया गया था.

उदाहरण के लिए, Now in Android में हमने वीडियो की सुविधा या पिक्चर में पिक्चर जैसी सुविधाएं जोड़ी हैं.

तीसरी वर्क स्ट्रीम, माइग्रेशन थी.

हम प्रोडक्शन में मौजूद उन ओपन-सोर्स ऐप्लिकेशन को अपग्रेड कर रहे हैं जिन्हें हमने बंद रखा था. इसके लिए, हम आधुनिक लाइब्रेरी और आर्किटेक्चर का इस्तेमाल कर रहे हैं.

उदाहरण के लिए, Nav 2 से Nav 3 पर माइग्रेट करना, एक्सएमएल व्यू से Compose पर माइग्रेट करना या सिंगल पैनल से अडैप्टिव लेआउट पर माइग्रेट करना.

आखिरी ऐप्लिकेशन, इन-हाउस ग्रीनफ़ील्ड ऐप्लिकेशन था. इसे विज़ुअल डिज़ाइन मॉक का इस्तेमाल करके, शुरुआत से बनाया गया था.

यहां कुछ उदाहरण दिए गए हैं, जैसे कि एसएमएस से ओटीपी की पुष्टि करने का पूरा फ़्लो, Google Maps की मदद से ऑर्डर ट्रैक करना वगैरह.

तोमाश म्लिनारिच

हमने कुछ ही इंजीनियर की मदद से, Now in Android जैसा ही एक ऐप्लिकेशन बनाया.

हालांकि, नए टास्क के साथ नई चुनौतियां भी आईं.

पहला: एजेंट को सही तरीके से ग्रेड देना.

बेंचमार्क टेस्ट, आपके ऐप्लिकेशन के लिए किए जाने वाले टेस्ट की तुलना में ज़्यादा मुश्किल होते हैं. इसकी वजह यह है कि उन्हें किसी एक समाधान के बजाय, हर मान्य समाधान को पास करना होता है. साथ ही, टास्क जितना बड़ा होगा, उतने ही ज़्यादा मान्य समाधान होंगे.

1.0 में, यह मानदंड ज़्यादातर यूनिट टेस्ट पर निर्भर था. यूनिट टेस्ट, एग्नॉस्टिक होने में काफ़ी खराब होते हैं.

import com.foodvibes.MyViewModel

@Test
fun testRetry() {
    val vm = MyViewModel()
    vm.retry()

    assertTrue(vm.retried)
}

इनमें क्लास या फ़ंक्शन के सटीक नाम की ज़रूरत होती है.

जैसे कि इस मामले में, कोई फ़ैंसी टेस्ट नहीं है. हालांकि, एजेंट उन चीज़ों को अलग-अलग नाम दे सकता है. इसके अलावा, अगर वे उन्हें अलग-अलग नाम नहीं देते हैं, तो वे उन्हें किसी दूसरे पैकेज में डाल देते हैं. इससे टेस्ट कंपाइल नहीं हो पाएंगे. इसलिए, हमारे मामले में उनका इस्तेमाल नहीं किया जा सकेगा.

import com.foodvibes.feature.my.RetriableViewModel

@Test
fun testRetry() {
    val vm = RetriableViewModel()
    vm.tryAgain()

    assertTrue(vm.tried)
}

इसलिए, हम तकनीकी तौर पर प्रॉम्प्ट में एपीआई की जानकारी दे सकते हैं. हालांकि, इससे या तो बहुत ज़्यादा जानकारी मिल जाएगी या फिर प्रॉम्प्ट में टेस्ट की बहुत ज़्यादा ज़रूरी शर्तें शामिल हो जाएंगी.

इसलिए, हम ऐसे टेस्ट करते हैं जो लागू करने के तरीके पर निर्भर नहीं करते.

ये बहुत ही हाई-लेवल और आउटकम टेस्ट होते हैं. ये आउटकम और बिहेवियर की जांच करते हैं, न कि इंटरनल की.

हम डिटरमिनिस्टिक यूज़र इंटरफ़ेस (यूआई) टेस्ट का इस्तेमाल करते हैं. ये ऐसे टेस्ट होते हैं जो स्क्रीन पर मौजूद सार्वजनिक जानकारी के साथ इंटरैक्ट करते हैं. ठीक उसी तरह जैसे कोई उपयोगकर्ता करता है.

इनके लिए, हम यूज़र इंटरफ़ेस (यूआई) ऑटोमेटर या Compose यूज़र इंटरफ़ेस (यूआई) टेस्ट का इस्तेमाल करते हैं. हालांकि, हमारे पास खास स्क्रिप्ट भी हैं, जो बाहरी सिस्टम की कुछ सीमाओं की जांच करती हैं. उदाहरण के लिए, क्या नेटवर्क कॉल में सही डेटा था या क्या सही डेटा को डेटाबेस में सेव किया गया है. इसके लिए, इंटरनल हेल्पर या डीएओ की जानकारी की ज़रूरत नहीं होती.

इनके अलावा, हमारे पास स्टैटिक जांच भी होती हैं. जैसे, मेनिफ़ेस्ट में अनुमतियों की जांच करना या यह देखना कि लाइब्रेरी, बिल्ट फ़ाइलों में थी या नहीं.

हमारे पास हाइब्रिड टेस्ट भी हैं. ये टेस्ट, स्क्रिप्ट और यूज़र इंटरफ़ेस (यूआई) टेस्ट का कॉम्बिनेशन होते हैं.

यह हाइब्रिड टेस्ट का एक उदाहरण है.

वे एम्युलेटर के बाहर काम करते हैं.

इसलिए, यह एसएमएस ओटीपी की मदद से पुष्टि करने की प्रोसेस की जांच है. इसमें स्क्रिप्ट को सबसे पहले, ऐप्लिकेशन के हैश का हिसाब लगाना होता है, ताकि एम्युलेटर को सही तरीके से एसएमएस भेजा जा सके. इसके बाद, जांच शुरू होती है. यूज़र इंटरफ़ेस (यूआई) ऑटोमेटर की जांच होती है और रैंडम तरीके से जनरेट किया गया ओटीपी पास किया जाता है. इसके बाद, एडीबी कमांड की मदद से एम्युलेटर को एसएमएस भेजा जाता है.

इस टेस्ट में सिर्फ़ यह जांच की जाती है कि इनपुट में सही नंबर था या नहीं.

बस, यही है.

इसमें कोई इंप्लिमेंटेशन कपलिंग नहीं है. इसमें सिर्फ़ यह जांच की जाती है कि फ़्लो काम कर रहा है या नहीं.

ग्रेडिंग से जुड़ी दूसरी समस्या यह थी कि हमारे टास्क के लिए मल्टी-मोडैलिटी की ज़रूरत होती है.

एजेंट को यूज़र इंटरफ़ेस (यूआई) बनाना होता है या हम उन्हें डिज़ाइन मॉक देते हैं.

इसके लिए, स्क्रीनशॉट टेस्ट सबसे आसान तरीका है.

हमें शुरुआत से ही पता था कि स्क्रीनशॉट की थ्रेशोल्ड वैल्यू ज़्यादा होनी चाहिए. हालांकि, इसके बाद भी वे फ़ेल हो गए.

हमने पिक्सल-डिफ़िंग के कुछ अलग-अलग एल्गोरिदम आज़माए. हालांकि, वे सिस्टम-लेवल के नॉइज़ जैसी चीज़ों पर काम नहीं कर पाए. जैसे, एम्युलेटर का स्टेटस बार अलग था या बैटरी आइकॉन अलग था या फ़ॉन्ट हार्डवेयर एंटी-एलियासिंग अलग थी.

हालांकि, वे कुछ हद तक मान्य इंप्लिमेंटेशन में भी फ़ेल हो गए. जैसे, पैडिंग में मामूली अंतर था, यह थोड़ा अलग था या रंग में थोड़ा अंतर था. जैसे, यूज़र इंटरफ़ेस (यूआई) पूरी तरह से सही हो सकता है, लेकिन बैकग्राउंड का रंग थोड़ा अलग हो सकता है. साथ ही, पिक्सल-डिफ़िंग एल्गोरिदम फ़ेल हो सकते हैं.

इसलिए, हमने मल्टीमॉडल एलएलएम जज का इस्तेमाल किया और उसे बनाया. यह स्क्रीनशॉट टेस्ट की तरह ही, स्क्रीनशॉट के पेयर की तुलना करता है और हमें कुछ स्कोर देता है. साथ ही, स्कोर के बारे में स्ट्रक्चरल रीज़निंग भी देता है.

हम इसमें सुलभता की हैरारकी के कुछ डंप भी डालते हैं. इससे यह जांच की जाती है कि स्ट्रक्चर सही है या नहीं और स्ट्रक्चर की समानता सही है या नहीं.

हमने कई बार इसे आज़माया और देखा कि यह लगातार बेहतर नतीजे देता है. साथ ही, यह उन समस्याओं को अनदेखा करता है जो हमें पहले दिखी थीं.

इसलिए, अब हमारे पास विज़ुअल और व्यवहार की पुष्टि करने का एक अच्छा तरीका था. इससे हमें पता चला कि एजेंट ने हर चीज़ को नकली बनाने की कोशिश की.

आगे बढ़ें.

तोमाश म्लिनारिच

इसकी शुरुआत आसान है.

आजकल, एजेंट आम तौर पर कहते हैं, "ठीक है.

मेरे पास एक टास्क है.

चलिए, GitHub पर नज़र डालते हैं.

आइए, समाधान ढूंढते हैं."

इसलिए, वे सबसे पहले यही काम करते हैं.

वे GitHub या इंटरनेट पर सही समाधान खोजने की कोशिश करते हैं. इसलिए, हमें सोर्स कोड को बंद रखना होगा और इसे सार्वजनिक नहीं किया जा सकता.

लेकिन वह आसान था.

कुछ ट्रायल में, हमने कहा कि सब कुछ 100% सही तरीके से पास हो रहा है. इस पर एजेंट ने कहा, "शानदार जीत!"

तो चलिए,

दिलचस्प है, उन्हें क्या मिला?

हालांकि, हमने इस पर बारीकी से नज़र डाली और पाया कि वे इस तरह की चीज़ें नहीं कर सकते.

मैं बस यह देखना चाहता हूं कि अगर मैं थ्रेशोल्ड को स्क्रीनशॉट टेस्ट के 80% पर सेट कर दूं, तो क्या होगा?"

// AuthFlowScreenshotTests.kt

@get:Rule
val dropshots = Dropshots(
    resultValidator =
        ThresholdValidator(
-           0.05f
+           0.80f
        )
)

और ऐसा लगता है, "हां, जीत, सब कुछ बीत रहा है."

हां, लेकिन स्क्रीनशॉट टेस्ट बेकार हैं.

हालांकि, यह सबसे बेहतर तरीका नहीं था.

कुछ मामलों में, जैसे कि Flutter कन्वर्ज़न ऐप्लिकेशन में, एजेंट ने Android ऐप्लिकेशन बनाने की बार-बार कोशिश की. हालांकि, वह ऐसा नहीं कर पाया.

इसलिए, उन्होंने उस स्क्रीनशॉट को लिया जो हमने उन्हें दिया था. इसके बाद, उन्होंने उसे बैकग्राउंड में ड्रॉएबल के तौर पर सेट कर दिया.

अब यह स्क्रीनशॉट टेस्ट पास करने जैसा है.

वाह!

हालांकि, यूज़र इंटरफ़ेस (यूआई) के टेस्ट अब भी फ़ेल हो रहे हैं. इसलिए, वे कहते हैं, "मैं इसके ऊपर एक ऐसी ओवरले लेयर डालूंगा जो दिखेगी नहीं. इसमें बटन, टेक्स्ट, टेस्ट टैग, और हमारी ज़रूरत की हर चीज़ होगी.

अब सब कुछ हरा-भरा है.

शानदार.

बहुत बढ़िया."

ऐसा नहीं है कि कोई एक ही बहुत अच्छा है.

इसलिए, हमारे पास Java से Kotlin में माइग्रेट करने का टास्क है. इसमें एजेंट को Java से Kotlin में माइग्रेट करना होगा, है न?

वे इसे बना नहीं पाए.

ऐसा लगता है कि अब भी कुछ गड़बड़ी हो रही है. इसलिए, एजेंट ने सोचा, "ठीक है, मैं Java से कंपाइल की गई क्लास लूंगा और उन्हें JAR में डालूंगा. इसके बाद, मैं उन्हें सामान्य लाइब्रेरी के तौर पर बिल्ड फ़ाइलों में जोड़ दूंगा.

अब हर टेस्ट पास हो रहा है, लेकिन हमारे पास स्टैटिक चेक हैं, जो Java फ़ाइलों की जांच कर रहे हैं. इसलिए, मैं उन्हें मिटा दूंगा."

मैं Java फ़ाइलें मिटा रहा हूं. Kotlin को छोड़कर, सब कुछ ग्रीन है. Kotlin अब भी फ़ेल हो रहा है. इसलिए, वे कहते हैं, "ठीक है, मैं Kotlin सोर्स सेट को हटाने जा रहा हूं और अब सब कुछ पास हो रहा है.

बहुत बढ़िया."

मुझे नहीं पता कि इसे चीटिंग कहा जा सकता है या नहीं.

मेरा मतलब है कि यह बहुत क्रिएटिव है.

इसलिए, इन सभी चीज़ों को रोकने के लिए, हमने चीटिंग डिटेक्टर बनाया है. इसमें तीन तरह की सुरक्षा सुविधाएं हैं.

हम यूज़र इंटरफ़ेस (यूआई) ट्री को देखते हैं. हम अलग-अलग स्क्रीन साइज़ लागू करते हैं, ताकि बैकग्राउंड खराब हो जाए और हम उसे देख सकें.

हालांकि, हम टेस्ट को रीसेट भी करते हैं. साथ ही, हम यह भी देखते हैं कि टेस्ट के साथ कोई छेड़छाड़ तो नहीं की गई है, ताकि वे थ्रेशोल्ड में बदलाव न कर सकें.

इसके बाद, हमारे पास एलएलएम-ऐज़-अ-जज भी है. यह एजेंट के ट्रैजेक्ट्री और असल आउटपुट की जांच करता है, ताकि कुछ अजीब चीज़ें देखी जा सकें.

अगर कुछ भी गड़बड़ होती है, तो हम कहते हैं, "ठीक है, यह तो फ़ेल हो गया."

तोमाश म्लिनारिच

इसलिए, अब कोई शॉर्टकट नहीं है, कोई समाधान नहीं है, कोई यूनिट टेस्ट नहीं है या यूज़र इंटरफ़ेस (यूआई) को नकली नहीं बनाया जा सकता.

इसलिए, जब हम एजेंट को Android ऐप्लिकेशन बनाने के लिए कहते हैं, तो नतीजे कैसे दिखते हैं?

सोमवार को आपने ब्लॉग पोस्ट देखी होगी. उसमें ये आंकड़े दिए गए हैं.

सबसे अच्छा एजेंट भी हमारे टास्क का सिर्फ़ 40% हिस्सा पूरा कर पाता है. ज़्यादातर फ़्रंटियर एजेंट 20 से 40% के बीच ही टास्क पूरा कर पाते हैं.

यह हमारे लिए अच्छी बात है, क्योंकि हम बेंचमार्क बनाते हैं. इससे हमें सही संतुलन बनाने में मदद मिलती है. जैसे, हमने जो टास्क दिए हैं वे असल दुनिया में काम के हैं. साथ ही, इनमें आगे बढ़ने की काफ़ी गुंजाइश है.

आइए, अब नतीजों पर नज़र डालते हैं.

अब हम नतीजों को अलग-अलग नज़रियों से देख सकते हैं.

हम उन अहम जानकारी पर नज़र डाल सकते हैं जो हमें पहले ही मिल चुकी हैं.

चार्ट को देखते समय आपके मन में सबसे पहला सवाल यह आ सकता है कि उस एजेंट को चलाने में कितना खर्च आता है?

एआई कंपनियां आम तौर पर, हर टोकन की लागत बताती हैं. जैसे, इनपुट, आउटपुट, और कैश मेमोरी टोकन के लिए.

शायद आपके मामले में, यह फ़ैसला लेने के लिए एक अहम तर्क हो.

हालांकि, हम इसे दूसरे नज़रिए से देख सकते हैं.

हम इसी चार्ट को 2D स्पेस पर प्लॉट कर सकते हैं. इसमें हर टास्क की औसत लागत को दिखाया जाएगा, न कि टोकन की लागत को. इससे पता चलेगा कि हर टास्क की लागत कितनी थी और पास रेट कितना था.

यहां हमें अचानक से यह देखने को मिलता है कि कुछ मॉडल बहुत ज़्यादा बात करते हैं.

ये हर टास्क के लिए, ज़्यादा समय या टोकन खर्च करते हैं. वहीं, अन्य मॉडल कम खर्च में ज़्यादा टास्क पूरे करते हैं.

लेकिन अगर हम उसी चार्ट में हर टोकन की कीमत भी जोड़ दें, तो हम देख सकते हैं कि एआई कंपनियां जो विज्ञापन दिखाती हैं वह उस कीमत से मेल नहीं खाता जो आपको हर टास्क के लिए असल में चुकानी पड़ती है.

इसलिए, अगर आपको लगता है कि सबसे अच्छी पास रेट वाला एजेंट, असल में हर टोकन के हिसाब से सबसे सस्ता है, लेकिन हर टास्क के हिसाब से सबसे महंगा है.

इसके अलावा, कुछ अन्य एजेंट भी हैं जो ठीक इसी टोकन कीमत पर करीब 30% टास्क पूरे कर लेते हैं. हालांकि, वे 15 गुना सस्ते होते हैं.

इसलिए, टोकन की कीमत कोई मेट्रिक नहीं है.

इनमें से कुछ मॉडल, कोड को ज़्यादा एक्सप्लोर कर रहे हैं. वे उसे फिर से बना रहे हैं और फिर से चला रहे हैं. हर चरण में ज़्यादा टोकन खर्च होते हैं.

इसलिए, सिर्फ़ कीमत या हर टोकन की लागत पर ध्यान न दें.

कोई मॉडल चुनें और असल डेटा देखें. जैसे, इसे अपने केस में इस्तेमाल करें या Android Bench को देखें. इससे आपको पता चलेगा कि असल में कौनसे मॉडल, टास्क पर सबसे ज़्यादा टोकन खर्च करते हैं.

कुछ मॉडल ऐसे होते हैं जिनमें ज़्यादा चरणों की ज़रूरत होती है. हालांकि, वे हर टोकन के हिसाब से सस्ते होते हैं.

हालांकि, इस सवाल का एक और पहलू भी है.

यह वही चार्ट है, लेकिन हम यह भी देख सकते हैं और दिखा सकते हैं कि एजेंट को इसे पूरा करने में कितना समय लगता है.

साथ ही, हम देख सकते हैं कि जिन एजेंट का पास रेट सबसे ज़्यादा है वे सबसे धीमे भी हो सकते हैं.

जैसे, हम देख सकते हैं कि कुछ लोगों को हर टास्क पूरा करने में करीब दो घंटे लगते हैं.

वे तब तक फिर से बनाते हैं और फिर से टेस्ट करते हैं, जब तक कि वह काम न करने लगे.

हां, इनसे सबसे ज़्यादा पास रेट मिलता है. हालांकि, इनमें सबसे ज़्यादा समय भी लगता है.

कुछ सस्ते एजेंट, अब भी हर टास्क के लिए करीब डेढ़ घंटा लेते हैं. हालांकि, उनके नतीजे बेहतर नहीं होते.

वहीं, कुछ एजेंट 20 मिनट से भी कम समय में टास्क पूरा कर लेते हैं. साथ ही, वे एक चौथाई से ज़्यादा टास्क पूरे कर लेते हैं.

इसलिए, छोटे और हल्के मॉडल आम तौर पर ज़्यादा तेज़ और सस्ते होते हैं. हालांकि, वे मुश्किल टास्क को पूरा करने में अक्सर नाकाम रहते हैं.

इससे यह पता चलता है कि कोई एक मॉडल सबसे बेहतर नहीं है.

यह इस बात पर निर्भर करता है कि आपने किस लक्ष्य के लिए ऑप्टिमाइज़ किया है.

क्या यह पास रेट है?

क्या इसके लिए कोई शुल्क देना होगा?

क्या यह इंतज़ार का समय है?

ऐसे में, अगर आपको मुश्किल काम नहीं करने हैं, तो आपको अपने काम के हिसाब से, तेज़ी से काम करने वाले मॉडल इस्तेमाल करने चाहिए. इनसे काम तेज़ी से और कम खर्च में हो जाता है.

हालांकि, लागत और स्पीड से सिर्फ़ यह पता चलता है कि एजेंट कैसे काम करते हैं. इससे यह पता नहीं चलता कि वे ज़्यादातर ट्रायल में फ़ेल क्यों हो जाते हैं.

इसलिए, हमने असफल रन की जांच की और पाया कि एजेंट अक्सर जल्दी ही काम छोड़ देते हैं.

उन्हें लगता है कि उन्होंने अपना काम पूरा कर लिया है.

टास्क पूरा हो गया है.

ठीक है, मैं घर जा रहा हूँ.

हालांकि, जैसा कि बताया गया है, टास्क पैकेट में एजेंट को सिर्फ़ निर्देश और पहले की स्थिति मिलती है.

वे टेस्ट नहीं देख सकते.

उन्हें पता चलता है कि वे पुष्टि करने वाला सुइट नहीं देख सकते.

इसलिए, हमने पूछा कि अगर हम उन्हें टेस्ट देखने दें, तो क्या होगा?

इसलिए, हमने एक्सपेरिमेंट किया और उसी टास्क का एक ओपन टेस्ट वैरिएंट बनाया. इसमें एजेंट को पुष्टि करने वाला टेस्ट सुइट पहले ही मिल गया, जो फ़ेल हो रहा था.

इसलिए, अब वे बार-बार टेस्ट कर रहे थे.

ये गड़बड़ियों की जांच कर सकते हैं और फ़ीडबैक लूप में कोड को बेहतर बना सकते हैं.

हमने पाया कि जब एजेंट को टेस्ट के बारे में पता चलता है, तो वे ज़्यादा मेहनत करते हैं और ज़्यादा समय तक काम करते हैं.

ओपन रन में, उन्हें 25% ज़्यादा टर्न मिले और एजेंट रनटाइम 40% रहा.

हर टास्क के लिए करीब 30 मिनट, उन्होंने टेस्ट को चलाने और उन्हें ठीक करने में बिताए. ऐसा इसलिए, क्योंकि वे बिना सोचे-समझे डीबग नहीं कर रहे थे.

इसलिए, उन्हें पता चल जाता है कि कौनसे टेस्ट फ़ेल हुए हैं. इससे, टेस्ट पास करने की दर भी करीब 50% बढ़ जाती है.

इस अतिरिक्त मेहनत से, पास होने की औसत दर बेहतर होती है, जैसा कि मैंने बताया.

हालांकि, बाद में नए फ़्रंटियर मॉडल आए और उन्होंने इस ओपन वैरिएंट को तेज़ी से पीछे छोड़ दिया.

करीब 90% छात्र-छात्राएं पास हो जाते हैं.

इसलिए, हमने क्लोज़्ड सर्च क्लोज़्ड टेस्ट वैरिएंट को मुख्य मानदंड मेट्रिक के तौर पर रखा.

हालांकि, यह देखना अब भी काफ़ी दिलचस्प है कि मॉडल को जब यह पता होता है कि उन्हें किस आधार पर ग्रेड दिया जा रहा है, तो वे बेहतर तरीके से काम करते हैं.

तोमाश म्लिनारिच

हालांकि, इससे हमें एजेंट के बारे में ज़्यादा अहम जानकारी मिली.

उदाहरण के लिए, हम यह देख सकते हैं कि मॉडल असल में अपने काम की जांच कैसे करते हैं.

इसलिए, हम चार्ट से देख सकते हैं कि फ़्रंटियर मॉडल, ज़्यादा से ज़्यादा बेहतर टेस्ट लिखते हैं और उनके पास होने की दर ज़्यादा होती है.

कुछ अन्य मॉडल, ज़रूरत से ज़्यादा भरोसेमंद होते हैं. वे कहते हैं कि मैं यह कर सकता हूं, मुझे टेस्ट करने की ज़रूरत नहीं है.

हालांकि, कभी-कभी वे अब भी अच्छे होते हैं.

इसलिए, अगर ऐसे मॉडल इस्तेमाल किए जा रहे हैं जो टेस्टिंग में अच्छे नहीं हैं, तो उन्हें टेस्टिंग की बेहतर स्किल या टेस्ट लिखने के बारे में खास निर्देश देकर मदद की जा सकती है.

लेकिन कोरिलेशन का मतलब कॉज़ेशन नहीं होता, सीएस, है ना?

हमें इस पर एक कंट्रोल एक्सपेरिमेंट करना होगा.

हमें अब भी यह देखना है कि बेहतर टेस्ट के लिए प्रॉम्प्ट देने से, स्कोर में वाकई बढ़ोतरी होती है या नहीं.

हालांकि, हमने Android टेस्टिंग के दूसरे हिस्से पर एक एक्सपेरिमेंट किया. इसमें एजेंट को एम्युलेटर का इस्तेमाल करने के लिए कहा गया.

शुरुआत में, हमने मानदंड में एम्युलेटर के बारे में कुछ नहीं कहा था.

हमने सोचा कि एजेंट को यह पता होना चाहिए, है न?

हमने देखा कि इनमें से किसी भी टूल ने एम्युलेटर को बूट नहीं किया.

जैसा कि मैंने बताया, हमारे यूज़र इंटरफ़ेस (यूआई) टेस्ट, हमारे मानदंड के लिए काफ़ी अहम हैं. एम्युलेटर के बिना, यूज़र इंटरफ़ेस (यूआई) टेस्ट का इस्तेमाल नहीं किया जा सकता.

इसलिए, वे सभी बहुत आसान चीज़ों में फ़ेल हो रहे थे.

इसलिए, अब हमारे सामने एक दुविधा है.

क्या हम एजेंट को यह बताते हैं कि आपको एम्युलेटर का इस्तेमाल करना होगा और ज़्यादा स्कोर पाने का जोखिम उठाना होगा या हम कुछ नहीं कहते और उम्मीद करते हैं कि वे खुद ही इसे समझ लेंगे?

हालांकि, हमारा मकसद Android कोडिंग और समस्या हल करने की क्षमता को मापने के लिए, एक सही मानदंड तय करना था.

हम पर्यावरण से जुड़ी कुछ अजीब चीज़ों को मेज़र नहीं करना चाहते.

इसलिए, हमने बीच का रास्ता चुना.

हमने उन्हें बताया कि एम्युलेटर को इस तरह से शुरू किया जाता है. हालांकि, हमने यह नहीं बताया कि इसका इस्तेमाल करना है या नहीं.

आखिरकार, हमें एम्युलेटर को शुरू करने की जांच नहीं करनी है.

इसके बाद, हमने एम्युलेटर के उस निर्देश के असर को मेज़र किया.

अब हमने देखा कि जब हमने उन्हें कैसे करें बताया, तो एजेंट ने एमुलेटर को ज़्यादा बूट किया और यूज़र इंटरफ़ेस (यूआई) टेस्ट चलाए. इससे पास रेट पर काफ़ी असर पड़ा. हालांकि, हमारे लिए यह अच्छी बात नहीं थी.

साथ ही, इससे हमें कोडिंग से जुड़ी उनकी असल गलतियों और समस्याओं की जांच करने में मदद मिली. ऐसा नहीं हुआ कि हम सिर्फ़ अनबूट किए गए एम्युलेटर पर ही फ़ेल हो गए.

इसलिए, प्रॉम्प्ट में सटीक जानकारी देना अब भी काफ़ी मायने रखता है. अगर आपको खुद के मानदंड या आकलन डिज़ाइन करने हैं, तो आपको यह टेस्ट करना होगा कि आपके मामले में असल में क्या मायने रखता है.

उदाहरण के लिए, मान लें कि आपको किसी स्किल या टूल के लिए टोकन की परफ़ॉर्मेंस का आकलन करना है. इसके लिए, आपको सबसे पहले आकलन को पास करना होगा. इसके बाद, परफ़ॉर्मेंस को बेहतर बनाने के लिए बदलाव करना होगा. फिर, यह पुष्टि करनी होगी कि अब भी कम टोकन के साथ आकलन पास हो रहा है या नहीं.

अगर ऐसा नहीं किया जाता है, तो एक साथ कई वैरिएबल बदल जाएंगे. इससे आपको यह पता नहीं चल पाएगा कि आपके बदलाव से असल में कोई फ़ायदा हुआ है या नहीं.

तोमाश म्लिनारिच

लीडरबोर्ड पर वापस जाएं.

जैसा कि मैंने बताया, सबसे अच्छे मॉडल करीब 40% टास्क पूरे कर पाते हैं. टास्क पूरा करने की दर के लिए, सभी जांचों को पास करना ज़रूरी है.

अगर ऐसा नहीं होता, तो टास्क पूरा नहीं हो पाता.

तो सवाल यह है कि क्या एजेंट ने बाकी 60% मामलों में कुछ भी काम का नहीं किया?

नहीं, वे अब भी सीख रहे हैं.

एजेंट, काम करने वाले समाधानों के कितने करीब पहुंचा, यह दिखाने के लिए हम पूरा होने की दर या आंशिक स्कोर का भी हिसाब लगाते हैं.

यह चार कैटगरी में दिया गया वेटेड स्कोर है: विज़ुअल कंसिस्टेंसी, फ़ंक्शनल, क्या यह सही तरीके से काम करता है, हर टास्क के लिए कुछ खास ज़रूरी शर्तें, और कुछ रिग्रेशन चेक.

यहां देखा जा सकता है कि कम रैंक वाले मॉडल, करीब आधा काम पूरा कर पाते हैं. वहीं, फ़्रंटियर मॉडल, औसतन करीब 80% काम पूरा कर पाते हैं. ये 80% से ज़्यादा टास्क पूरे कर पाते हैं. हालांकि, ये सिर्फ़ 40% टास्क पास कर पाते हैं.

इसलिए, हमने Flutter से Android पर कन्वर्ज़न का एक एक्सपेरिमेंट किया, ताकि यह देखा जा सके कि क्या हो रहा है.

इसलिए, हमने एजेंट के कुछ चरणों के बाद, टास्क पूरा होने की दर का फिर से हिसाब लगाया. हमें सभी फ़्रंटियर मॉडल में एक जैसे पैटर्न दिखे.

करीब 140 चरणों में, वे औसतन 90% स्कोर तक पहुंचने की कोशिश कर रहे थे. इसके बाद, उन्होंने 90 और चरणों या रन के करीब 40% हिस्से को 100% तक पहुंचने की कोशिश में खर्च किया. हालांकि, वे सिर्फ़ 1 या 2% ज़्यादा स्कोर कर पाए.

हमें लगता है कि यह आज के एजेंटिक डेवलपमेंट को दिखाता है. इसमें कम अनुभव वाले डेवलपर या उपयोगकर्ताओं को लगता है कि ऐप्लिकेशन पूरा हो गया है.

सभी चीज़ें रेंडर हो रही हैं.

इनपुट कुछ हद तक काम कर गया.

शायद कोई दुर्घटना नहीं हुई है.

हालांकि, जब कोई सीनियर इंजीनियर कोड को देखता है, तो उसे कई कमियां दिखती हैं: उसे आर्किटेक्चर से जुड़ी समस्याएं, लाइफ़ साइकल से जुड़ी कमियां, और ऐसी ही अन्य चीज़ें दिखती हैं.

तोमाश म्लिनारिच

आखिर में, आइए Android Bench के बारे में बात करते हैं. यह हमारा वर्क 2.0 है.

1.0 की तुलना में, अब हमारे पास सिर्फ़ 30 टास्क हैं. ऐसा जान-बूझकर किया गया है.

हमने गड़बड़ियों को ठीक करने और छोटे-छोटे पैच बनाने के बजाय, पूरी स्क्रीन, मल्टी-मॉड्यूल माइग्रेशन, और पूरे ऐप्लिकेशन के कन्वर्ज़न पर काम किया.

अब दर्जनों फ़ाइलों में पैच का साइज़ काफ़ी बड़ा हो गया है.

इसके अलावा, हमारे पास मल्टीमोडल यूज़र इंटरफ़ेस (यूआई) की जांच करने की सुविधा है.

एजेंट को ज़्यादा समय तक और ज़्यादा मेहनत से काम करना होगा.

अगर हम अन्य फ़्रंटियर बेंचमार्क से तुलना करें, तो हम देख सकते हैं कि हमारे बेंचमार्क के लिए कोड में काफ़ी ज़्यादा बदलाव करने की ज़रूरत है.

इसमें डेटा कॉन्टैमिनेशन की समस्या नहीं है, क्योंकि ज़्यादातर टास्क नए सिरे से लिखे गए हैं. साथ ही, इसमें अब भी सुधार की काफ़ी गुंजाइश है.

जैसा कि मैंने शुरुआत में कहा था कि एआई की दुनिया में कुछ महीने भी सदियों जैसे लगते हैं. आखिरकार, हर मानदंड की एक सीमा होती है और वह सैचुरेट हो जाता है.

जब यह काम पूरा हो जाएगा, तो उम्मीद है कि हम और भी मुश्किल और जटिल टास्क पर काम करेंगे. ये टास्क, उस दौर के एआई की क्षमता के हिसाब से होंगे.

अब Android Bench का इस्तेमाल कंपास के तौर पर करें, ताकि मॉडल और हार्नेस की तुलना की जा सके. साथ ही, कुछ अहम जानकारी भी मिल सके.

जब आपको ज़्यादा गहराई से जानकारी चाहिए, तो अपने कोड बेस और वर्कफ़्लो के लिए, मानदंड और आकलन के वही सिद्धांत अपनाएं. ऐसा इसलिए, क्योंकि जिस कोड पर असल में काम किया जाता है उस पर एआई को मेज़र करने से बेहतर कुछ नहीं है.

इससे आपको यह भरोसा हो जाता है कि एआई ने सही जानकारी दी है.

Android Bench की पूरी टीम की ओर से, ध्यान देने के लिए धन्यवाद.