Android Bench থেকে এজেন্ট কোড জেনারেশন সংক্রান্ত ইনসাইট

Tomáš Mlynarič

সুপ্রভাত, সবাইকে।

তাহলে শুরু করা যাক।

মার্চ মাসে, আমরা Android Bench লঞ্চ করেছি, যা Android ডেভেলপমেন্ট টাস্কে LLM পরিমাপ করার জন্য আমাদের ডেটা সেট এবং লিডার বোর্ড।

তারপর থেকে, আমরা অনেক নতুন মডেলের বিরুদ্ধে এটি রান করেছি।

আর গত মাসেই আমরা Android Bench 2.0 রিলিজ করেছি।

যদিও মাত্র কয়েক মাস হয়েছে, AI-এর দুনিয়ায় এটি অনন্তকাল বলে মনে হয়।

আমার নাম টমাস এবং আমি Android Bench-এর যাত্রা এবং আমরা কীভাবে বর্তমান অবস্থায় পৌঁছেছি তা শেয়ার করতে চলেছি।

আসুন ১.০ দিয়ে শুরু করা যাক।

1.0-এ, আমরা ওপেন-সোর্স রিপোজিটরি থেকে বাস্তব-জগতের সমস্যাগুলি নিয়েছি।

আমরা GitHub প্রোজেক্ট ফিল্টার করেছি, যেখানে GitHub সমস্যা, সেইসব সমস্যা সমাধানকারী পুল রিকোয়েস্ট এবং সমাধান যাচাইকারী টেস্ট রয়েছে।

আমরা AI মডেলের জন্য পুল রিকোয়েস্টকে টাস্ক বাকেটে ভাগ করি।

GitHub সমস্যাটি মডেলের জন্য নির্দেশাবলী বা প্রম্পট হয়ে ওঠে এবং আমরা সেগুলিকে PR-এর আগের অবস্থায় প্ল্যান্ট করি।

মডেলটি কিছু কাজ তৈরি করার পরে, আমরা পরীক্ষাগুলি নিয়েছি এবং আউটপুটে প্রয়োগ করেছি, যা আমাদের পাস বা ফেল ফলাফল দিয়েছে।

AI-এর এই সমাধান করার চেষ্টাকে আমরা ট্রায়াল বলি।

এবং আমরা সেই PR থেকে মানুষের তৈরি সমাধানের ভিত্তিতেও এটি তুলনা করতে পারি, বা আমরা এটিকে গোল্ডেন সলিউশন বলি।

এই পদ্ধতিটি সুপরিচিত SWE-বেঞ্চ বেঞ্চমার্কের মতো।

আমরা ১০,০০০-এর বেশি সম্ভাব্য টাস্ক নিয়ে শুরু করেছিলাম এবং তার মধ্যে সবকটি উপযুক্ত ছিল না।

কিছু কিছু ক্ষেত্রে নির্দেশাবলী অসম্পূর্ণ ছিল বা অতিরিক্ত নির্দেশাবলী ছিল।

টেস্টগুলি গোল্ডেন সলিউশনের সাথে যুক্ত করা হতে পারে অথবা PR-এর আগের অবস্থা ভেঙে গেছে।

তাই, ১০০টি ন্যায্য টাস্ক বেছে নিতে আমাদের বারবার পর্যালোচনা করতে হয়েছে।

সেইসব পর্যালোচনার সময়, কিছু ফলাফল পেতে আমরা অত্যাধুনিক মডেল ব্যবহার করেছি।

আমরা প্রায় ৩০% টাস্ক সমাধান করে শুরু করেছিলাম, যাকে আমরা পাস রেট বলি।

তারপর, অফিসিয়াল রিলিজের জন্য ডেটাসেট লক করার সময়, সেরা মডেলগুলি ইতিমধ্যেই প্রায় ৭০% সঠিক উত্তর দিচ্ছিল।

কিন্তু সেটা তো এক মাস পরে।

তারপর আমরা প্রতি মাসে নতুন মডেল মূল্যায়ন করার পরিকল্পনা করি এবং তারপর আমরা দেখি যে সেগুলি কীভাবে আরও ভাল হচ্ছে।

আগস্টের রিলিজে, সেরা মডেলের জন্য পাস রেট ছিল ৯২%।

আমরা জানতাম যে আমাদের বারটি খুব কম এবং এই ডেটা সেটটি স্যাচুরেটেড।

Tomáš Mlynarič

তবে আমরা তা আগেই অনুমান করেছিলাম এবং 2.0 ভার্সন নিয়ে কাজ শুরু করে দিয়েছিলাম, যা গত মাসে রিলিজ করা হয়েছে।

লক্ষ্য হল, এবং ছিল, জটিল, বাস্তব-জগতের Android টাস্কের মাধ্যমে মান উন্নত করা এবং আপনার, ডেভেলপারদের জন্য LLM পারফর্ম্যান্সের উপর নির্দেশিকা এবং স্বচ্ছতা প্রদান করা, তবে মডেল নির্মাতাদের Android-কে অগ্রাধিকার দেওয়ার জন্য তাদের ভাল বেঞ্চমার্ক প্রদান করা, যার বিরুদ্ধে তারা প্রতিদ্বন্দ্বিতা করতে পারে।

এছাড়াও, আপনাকে এবং মডেল নির্মাতাদের বিশ্লেষণ এবং ফলাফল প্রদান করা।

কিন্তু আমাদের চতুরতা, অধ্যবসায় এবং প্রতারণার কথাও মাথায় রাখতে হবে।

আর আমাদের দূষণের ঝুঁকি প্রতিরোধ করতে হবে।

SWE-bench পদ্ধতির একটি সমস্যা হল সোর্স কোডের প্রকৃত উন্মুক্ততা।

OpenAI একটি নিবন্ধ প্রকাশ করেছে।

তারা দেখেছেন যে মডেলগুলি নির্দেশের পরবর্তী শব্দগুলি সম্পূর্ণ করতে পেরেছে, অথবা তারা এমন একটি অস্পষ্ট ত্রুটি সহ একটি টাস্ক সমাধান করতে পেরেছে যা নির্দেশের অংশ ছিল না।

এবং তারা বুঝতে পেরেছেন যে মডেল নির্মাতারা ওপেন-সোর্স কোডে ট্রেনিং দিচ্ছেন এবং SWE-bench দূষিত।

তাই, 2.0-এর জন্য, আমরা আসলে কোডটি বন্ধ রাখছি যাতে এটিতে ট্রেনিং দেওয়া না যায়।

আমরা কাজটিকে চারটি ওয়ার্ক স্ট্রিমে ভাগ করেছি।

প্রথমত, আমরা অ্যাপ কনভার্সন করি, যেখানে আমরা ওপেন-ফ্লুর-- ওপেন-সোর্স, Flutter এবং React Native অ্যাপ নিয়েছি এবং এজেন্টদের বলেছি সেগুলিকে নেটিভ Android সলিউশনে কনভার্ট করতে।

এটি আসলে ক্রস-প্ল্যাটফর্ম থেকে নেটিভে মাইগ্রেট করার প্রবণতা দেখায় যা আমরা এখন দেখতে পাই।

দ্বিতীয় ওয়ার্ক স্ট্রিম ছিল নতুন ফিচার ও প্ল্যাটফর্ম ইন্টিগ্রেশন।

এগুলি প্রতিষ্ঠিত প্রোডাকশন কোড বেসে তৈরি করা হয়েছে।

যেমন, Now in Android-এ আমরা ভিডিও ফিচার বা ছবির-মধ্যে-ছবি, এই ধরনের জিনিস যোগ করেছি।

তৃতীয় ওয়ার্ক স্ট্রিম ছিল মাইগ্রেশন।

আমরা প্রোডাকশন ওপেন-সোর্স অ্যাপ আপগ্রেড করছি যা আমরা আধুনিক লাইব্রেরি এবং আর্কিটেকচারের সাথে বন্ধ রেখেছিলাম।

যেমন, Nav 2 থেকে Nav 3, XML ভিউ থেকে Compose অথবা সিঙ্গেল প্যান থেকে অ্যাডাপ্টিভ লেআউটের মতো বিষয়।

এবং শেষটি ছিল ভিজ্যুয়াল ডিজাইন মক ব্যবহার করে স্ক্র্যাচ থেকে তৈরি ইন-হাউস গ্রিনফিল্ড অ্যাপ।

এখানে, উদাহরণগুলি ছিল, সম্পূর্ণ SMS OTP যাচাইকরণ ফ্লো, Google Maps-এর মাধ্যমে অর্ডার ট্র্যাক করা এবং আরও অনেক কিছু।

Tomáš Mlynarič

মাত্র কয়েকজন ইঞ্জিনিয়ারকে নিয়ে আমরা 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)
}

তাই, আমরা টেকনিক্যালি প্রম্পটে API নির্দিষ্ট করতে পারি, কিন্তু সেটি করলে হয় অনেক বেশি বিবরণ প্রকাশ হয়ে যাবে অথবা অনেক বেশি টেস্টের প্রয়োজনীয়তা দিয়ে প্রম্পট ভরে যাবে।

তাই, সমাধান হল আমরা ইমপ্লিমেন্টেশন-অ্যাগনস্টিক টেস্ট করি।

এগুলি খুব উচ্চ-স্তরের এবং ফলাফল, তারা ফলাফল এবং আচরণ পরীক্ষা করে, ইন্টার্নাল নয়।

আমরা ডিটারমিনিস্টিক UI টেস্ট ব্যবহার করি, এই টেস্ট সর্বজনীন স্ক্রিন তথ্যের সাথে ইন্টার‍্যাক্ট করে, ঠিক যেমন একজন ব্যবহারকারী করেন।

সেগুলির জন্য, আমরা UI অটোমেটর বা কম্পোজ UI টেস্ট ব্যবহার করি, তবে আমাদের কাছে বিশেষ স্ক্রিপ্টও আছে, যা কিছু এক্সটার্নাল সিস্টেমের সীমানা চেক করছে, যেমন, কোনও নেটওয়ার্ক কলে সঠিক ডেটা আছে কিনা বা ইন্টার্নাল হেল্পার বা DAO না জেনে সঠিক ডেটা কোনও ডেটাবেসে সেভ করা হয়েছে কিনা।

এর অংশ হিসেবে, আমাদের কাছে স্ট্যাটিক চেকও আছে, যেমন, আপনি জানেন, ম্যানিফেস্টে অনুমতি চেক করা বা লাইব্রেরিটি বিল্ট ফাইলে ছিল কিনা এবং এই ধরনের জিনিস।

এছাড়াও, আমাদের কাছে হাইব্রিড টেস্ট আছে যা এইসব স্ক্রিপ্ট ও UI টেস্টের সংমিশ্রণ।

এটি হাইব্রিড টেস্টের একটি উদাহরণ।

তারা এমুলেটরের বাইরে ড্রাইভ করে।

সুতরাং, এটি হল এসএমএস ওটিপি যাচাইকরণ ফ্লোর পরীক্ষা, যেখানে স্ক্রিপ্টকে প্রথমে অ্যাপের হ্যাশ গণনা করতে হবে যাতে এমুলেটরে সঠিকভাবে এসএমএস পাঠানো যায়, তারপর পরীক্ষা শুরু হয়, UI অটোমেটর পরীক্ষা করে এবং কিছু র‍্যান্ডমলি জেনারেট করা ওটিপি পাস করে যা এটির প্রয়োজন হয় এবং এডিবি কমান্ড সহ একটি এমুলেটরে এসএমএস পাঠায়।

এবং ইনপুটে সঠিক নম্বর আছে কিনা তা টেস্টের মাধ্যমে চেক করা হয়।

That's, that's basically it.

কোনও ইমপ্লিমেন্টেশন কাপলিং নেই, শুধু চেক করে, এটি শুধু চেক করে যে ফ্লো কাজ করছে কিনা।

গ্রেডিং সংক্রান্ত দ্বিতীয় সমস্যাটি হল, আমাদের টাস্কের জন্য মাল্টি-মডালিটি প্রয়োজন।

They either, the agents either are required to produce UI, or we give them the design mocks.

আর, সেই জন্য স্ক্রিনশট টেস্ট ব্যবহার করা সবচেয়ে সহজ।

আমরা প্রথম থেকেই জানতাম যে স্ক্রিনশট থ্রেশহোল্ড আরও বেশি হতে হবে, কিন্তু তা সত্ত্বেও সেগুলি ব্যর্থ হয়েছে।

আমরা কিছু ভিন্ন পিক্সেল-ডিফিং অ্যালগরিদম চেষ্টা করেছি, কিন্তু সেগুলি সিস্টেম-লেভেল নয়েজের মতো জিনিসে ব্যর্থ হয়েছে, যেখানে এমুলেটর স্ট্যাটাস বার আলাদা ছিল, বা ব্যাটারি আইকন, বা এমনকি ফন্ট হার্ডওয়্যার অ্যান্টি-অ্যালাইজিং আলাদা ছিল।

তবে, তারা কিছুটা বৈধ বাস্তবায়নেও ব্যর্থ হয়েছে, যেখানে, আপনি জানেন, প্যাডিংগুলি ছোট ছিল, এটি কিছুটা আলাদা, বা কিছু সামান্য টিন্ট পার্থক্য ছিল, যেমন UI সম্পূর্ণ সঠিক হতে পারে, তবে ব্যাকগ্রাউন্ডটি কিছুটা আলাদাভাবে টিন্ট করা হবে এবং পিক্সেল-ডিফিং, অ্যালগরিদম ব্যর্থ হবে।

তাই, এর জন্য আমরা মাল্টিমোডাল LLM জাজ ব্যবহার ও তৈরি করেছি যা স্ক্রিনশট টেস্টের মতো স্ক্রিনশট পেয়ারের তুলনা করে এবং আমাদের কিছু স্কোর দেয়, তবে, স্কোরের ব্যাপারে স্ট্রাকচারাল রিজনিংও দেয়।

এছাড়াও, আমরা কিছু অ্যাক্সেসিবিলিটি হায়ারার্কি ডাম্পের মাধ্যমে এটি ফিড করি যা স্ট্রাকচারটি সঠিক কিনা এবং স্ট্রাকচারাল প্যারিটি সঠিক কিনা তা চেক করে।

আমরা অনেক অনেক ট্রায়ালে এটি ব্যবহারিক উপায়ে পরীক্ষা করে দেখেছি যে এটি অত্যন্ত সামঞ্জস্যপূর্ণ এবং আমরা যেসব সমস্যার সম্মুখীন হয়েছি সেগুলি উপেক্ষা করে।

তাই, এখন, আমাদের কাছে ভিজ্যুয়াল এবং আচরণ অ্যাগনস্টিক্যালি যাচাই করার একটি ভালো উপায় ছিল এবং তাই আমরা দেখেছি যে এজেন্টরা সবকিছু নকল করার চেষ্টা করেছে।

চালিয়ে যান।

Tomáš Mlynarič

এটি খুব সহজেই শুরু হয়।

আজকাল, এজেন্টরা মূলত, "ঠিক আছে।

আমার কাছে একটা টাস্ক আছে।

GitHub-এ দেখা যাক, আপনি জানেন।

চলুন, সমাধান খুঁজে বের করি।"

সুতরাং, তারা প্রথমে এই ধরনের কাজই করে।

তারা সঠিক সমাধানের জন্য GitHub বা ইন্টারনেট সার্চ করার চেষ্টা করে, তাই আমাদের সোর্স কোড বন্ধ রাখতে হবে এবং এটি সর্বজনীন করা যাবে না।

কিন্তু সেটা, মানে, সহজ ছিল।

কিছু ট্রায়ালে আমরা বলেছি যে সবকিছু ১০০% নিখুঁতভাবে পাস করেছে এবং এজেন্ট বলেছে, "অসাধারণ সাফল্য!"

তাহলে।

দারুণ, তারা কী খুঁজে পেয়েছেন?

কিন্তু আমরা ট্র্যাজেক্টরি আরও ঘনিষ্ঠভাবে দেখেছি এবং তারা বলেছে, "আমি এটা করতে পারব না।

আমি শুধু, স্ক্রিনশট টেস্টের থ্রেশহোল্ড পরিবর্তন করে ৮০% করলে কেমন হয়?"

// AuthFlowScreenshotTests.kt

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

আর এটা যেন, "হ্যাঁ, জয়, সবকিছুই কেটে যাচ্ছে।"

হ্যাঁ, কিন্তু স্ক্রিনশট টেস্টগুলি কোনও কাজের নয়।

কিন্তু সেটি সবচেয়ে অত্যাধুনিক ছিল না।

কিছু ক্ষেত্রে, আসলে Flutter কনভার্সন অ্যাপে, এজেন্ট Android তৈরি করার চেষ্টা করেই যাচ্ছিল এবং বলছিল, "আমি জানি না কী করতে হবে।"

তাই, তারা স্ক্রিনশটটি নিয়ে ব্যাকগ্রাউন্ডে ড্রয়েবল হিসেবে সেট করে।

আর এখন এটি স্ক্রিনশট টেস্টে পাস করার মতো।

অসাধারণ!

কিন্তু তারপরে, আপনি জানেন, UI টেস্ট এখনও ব্যর্থ হচ্ছে, তাই তারা বলে, "আমি বোতাম এবং টেক্সট এবং টেস্ট ট্যাগ সহ তার উপরে একটি অদৃশ্য ওভারলে লেয়ার রাখতে যাচ্ছি, আমাদের যা প্রয়োজন।

এখন সবকিছু সবুজ।

অসাধারণ।

দারুণ করেছ।"

সেটা নয়, যেমন, এমন একটা আছে যেটা, যেমন, সত্যিই ভালো।

তাহলে, আমাদের কাছে Java থেকে Kotlin-এ মাইগ্রেট করার টাস্ক আছে যেখানে এজেন্টকে মূলত Java থেকে Kotlin-এ মাইগ্রেট করতে হবে, তাই তো?

তারা এটি তৈরি করতে পারেনি।

এটি, যেমন, এখনও কিছু ব্যর্থ হচ্ছে, তাই এজেন্ট ভেবেছিল, "ঠিক আছে, আমি শুধু জাভা থেকে কম্পাইল করা ক্লাসগুলি নিতে যাচ্ছি, এবং আমি এটিকে একটি JAR-এ রাখব, এবং তারপরে আমি এটিকে একটি নিয়মিত লাইব্রেরি হিসাবে বিল্ড ফাইলগুলিতে যোগ করব।

তাই এখন, প্রতিটি টেস্ট পাস করছে, তবে আমাদের কাছে স্ট্যাটিক চেক আছে যা জাভা ফাইলগুলি চেক করছে, তাই, হ্যাঁ, আমি সেগুলি মুছে ফেলতে যাচ্ছি।"

আমি Java ফাইলগুলি মুছে ফেলছি, Kotlin এখনও ব্যর্থ হচ্ছে, তাই তারা বলছে, "ঠিক আছে, আমি Kotlin সোর্স সেটটি সরাতে যাচ্ছি, এবং এখন সবকিছু পাস হচ্ছে।

দারুণ।"

আমি জানি না যে এটি আদৌ প্রতারণা কিনা।

মানে, এটা সত্যিই খুব ক্রিয়েটিভ।

তাই, এই সমস্ত কিছু প্রতিরোধ করার জন্য, আমরা একটি চিটিং ডিটেক্টর তৈরি করেছি যাতে, তিনটি প্রতিরক্ষা ব্যবস্থা রয়েছে।

আমরা UI ট্রি দেখি, বিভিন্ন স্ক্রিন সাইজ প্রয়োগ করি যাতে ব্যাকগ্রাউন্ড বিকৃত হয় এবং আমরা তা দেখি।

তবে আমরা টেস্ট রিসেটও করি এবং টেস্টে কোনও কারচুপি করা হয়েছে কিনা তা চেক করি যাতে থ্রেশহোল্ড পরিবর্তন করা না যায়।

এছাড়াও, আমাদের কাছে LLM-as-a-Judge-এর মতো টুল আছে যা ট্র্যাজেক্টরি এবং এজেন্টের আসল আউটপুট অডিট করে কোনও অদ্ভুত জিনিস আছে কিনা তা দেখে।

আর কিছু হলে, আমরা শুধু বলি, "ঠিক আছে, সরাসরি ব্যর্থ।"

Tomáš Mlynarič

তাই এখন, প্রতিটি শর্টকাট চলে গেছে, সমাধান খোঁজা, ভঙ্গুর ইউনিট টেস্ট বা নকল UI নেই।

তাই, আমরা যখন এজেন্টদের Android অ্যাপ তৈরি করতে বাধ্য করি, তখন সংখ্যাগুলি কেমন দেখায়?

তাই, সোমবার আপনি ব্লগ পোস্টটি দেখে থাকলে, সংখ্যাগুলি এইরকম দেখাবে।

এমনকি সেরা এজেন্টও আমাদের টাস্কের মাত্র ৪০% পাস করে এবং বেশিরভাগ ফ্রন্টিয়ার এজেন্ট ২০ থেকে ৪০% পাস করে।

আর বেঞ্চমার্ক লেখক হিসেবে এটি আমাদের জন্য ভালো, কারণ এটি সঠিক ভারসাম্য বজায় রাখে, যেমন, আমাদের দেওয়া টাস্কের বাস্তব জগতে মূল্য আছে, কিন্তু আরও উন্নত করার জন্য অনেক সুযোগও আছে।

তাহলে, ফলাফলগুলি দেখে নেওয়া যাক।

আমরা এখন একাধিক দৃষ্টিকোণ থেকে ফলাফল দেখতে পারি।

আমরা আগে থেকে খুঁজে পাওয়া কিছু ইনসাইট দেখতে পারি।

চার্টটি দেখার সময় আপনার প্রথম প্রশ্ন হতে পারে, যেমন, সেই এজেন্ট চালাতে কত খরচ হয়?

এবং AI কোম্পানিগুলি সাধারণত টোকেন প্রতি খরচ রিপোর্ট করে, কিছু ইনপুট, আউটপুট, সম্ভবত ক্যাশে টোকেনের জন্য।

এবং আপনার ক্ষেত্রে এটি সিদ্ধান্ত নেওয়ার জন্য একটি যুক্তি হতে পারে।

তবে আমরা অন্য দৃষ্টিকোণ থেকে এটি দেখতে পারি।

আমরা 2D স্পেসে একই চার্ট প্লট করতে পারি, যেখানে টাস্ক প্রতি গড় খরচ দেখানো হবে, টোকেন নয়। অর্থাৎ, টাস্ক প্রতি খরচ বনাম পাস রেট।

এবং এখানে, আমরা হঠাৎ দেখতে পাচ্ছি যে কিছু মডেল অনেক বেশি কথা বলে।

তারা প্রতিটি টাস্কে অনেক বেশি সময় বা টোকেন ব্যয় করে, অন্যদিকে, অন্যরা কম খরচে আরও বেশি টাস্ক পাস করে।

কিন্তু আমরা যদি একই চার্টে টোকেন প্রতি দামও যোগ করি, তাহলে আমরা দেখতে পাব যে, AI কোম্পানিগুলি আসলে যা বিজ্ঞাপন দেয় তা টাস্ক প্রতি আপনি যা পেমেন্ট করেন তার সাথে মেলে না।

সুতরাং, আপনি যদি দেখতে পান যে সেরা, সেরা পাস রেট সহ এজেন্ট আসলে টোকেন প্রতি সবচেয়ে সস্তা, তবুও টাস্ক প্রতি সবচেয়ে ব্যয়বহুল।

অথবা, একই টোকেন মূল্যের অন্যান্য এজেন্ট প্রায় ৩০% টাস্ক পাস করে, কিন্তু সেগুলি ১৫ গুণ সস্তা।

তাই, টোকেনের দাম মেট্রিক নয়।

এর মধ্যে কিছু মডেল কোড আরও এক্সপ্লোর করছে, সেগুলি আবার তৈরি করছে, আবার রান করছে এবং প্রতিটি ধাপে আরও টোকেন খরচ হচ্ছে।

সুতরাং, শুধু টোকেন পিছু দাম, খরচ দেখলে চলবে না।

একটি মডেল বেছে নিন, আসল ডেটা দেখুন, যেমন আপনার ক্ষেত্রে এটি ব্যবহার করুন অথবা Android Bench-এ দেখুন যে কোন মডেলগুলি আসলে টাস্কে সবচেয়ে বেশি টোকেন খরচ করে।

কিছু, আপনি জানেন, কিছুতে আরও ধাপের প্রয়োজন হয় যদিও সেগুলি টোকেন প্রতি সস্তা।

তবে, একই প্রশ্নের আরেকটি দিক আছে।

এটি একই চার্ট, তবে আমরা এটিও দেখতে এবং দেখাতে পারি যে এজেন্টদের এটি সম্পূর্ণ করতে কত সময় লাগে।

এবং আমরা দেখতে পাচ্ছি যে যেসব এজেন্টের পাস রেট সবচেয়ে বেশি, তারা হয়ত সবচেয়ে ধীর গতিতে কাজ করেন।

যেমন, আমরা দেখতে পাচ্ছি যে কিছু টাস্কের জন্য প্রায় দুই ঘণ্টা সময় লাগে।

কাজ না হওয়া পর্যন্ত তারা এটি আবার তৈরি ও পরীক্ষা করতে থাকে।

হ্যাঁ, এগুলি সবচেয়ে বেশি পাস রেট পায়, তবে এগুলি সবচেয়ে বেশি সময়ও নেয়।

কিছু সস্তা এজেন্ট, তারা এখনও টাস্ক প্রতি প্রায় দেড় ঘণ্টা সময় নেয়, কিন্তু আরও ভাল ফলাফল ছাড়াই।

অথবা, অন্যান্য এজেন্ট, তারা ২০ মিনিটের কম সময়ে এটি শেষ করে এবং এখনও এক চতুর্থাংশের বেশি টাস্ক সমাধান করে।

তাই, ছোট, হালকা মডেলগুলি সাধারণত দ্রুত এবং সস্তা হয়, কিন্তু কঠিন টাস্কের ক্ষেত্রে প্রায়ই ব্যর্থ হয়।

The takeaway is like there's no single best model.

আপনি কীসের জন্য অপ্টিমাইজ করছেন তার উপর এটি নির্ভর করে।

এটি কি পাস রেট?

Is it cost?

এটা কি অপেক্ষা করার সময়?

আপনি যে ধরনের কাজ করছেন তার উপর নির্ভর করে, আপনি যদি এই ধরনের কঠিন কাজ না করেন, তাহলে আপনি দ্রুত মডেল ব্যবহার করার কথা বিবেচনা করতে পারেন যা সস্তা এবং দ্রুত কাজ করে।

কিন্তু, খরচ এবং গতি আপনাকে কেবল বলে যে এজেন্টরা কীভাবে রান করে, কিন্তু কেন তারা বেশিরভাগ ট্রায়ালে ব্যর্থ হয় তা নয়।

তাই, আমরা ব্যর্থ রানগুলি পরীক্ষা করেছি এবং আমরা লক্ষ্য করেছি যে এজেন্টরা প্রায়শই তাড়াতাড়ি ছেড়ে দেয়।

তারা নিশ্চিত যে তারা এটি করেছে।

টাস্ক সম্পূর্ণ হয়েছে।

ঠিক আছে, আমি বাড়ি যাচ্ছি।

তবে, যেমন উল্লেখ করা হয়েছে, টাস্ক প্যাকেটে, এজেন্টরা শুধুমাত্র নির্দেশাবলী এবং আগের অবস্থা পান।

তারা টেস্ট দেখতে পাবেন না।

তারা দেখতে পায় যে তারা যাচাইকরণ স্যুট দেখতে পাচ্ছে না।

তাই, আমরা জিজ্ঞাসা করলাম, কী হবে, যদি আমরা তাদের শুধু টেস্ট দেখতে দিই?

তাই, আমরা পরীক্ষা করেছি এবং একই টাস্কের একটি ওপেন টেস্ট ভেরিয়েন্ট ছিল, যেখানে এজেন্ট ব্যর্থ যাচাইকরণ টেস্ট স্যুটটি সামনে পেয়েছেন।

তাই, এখন, তারা বারবার পরীক্ষা চালাচ্ছিল।

তারা ত্রুটিগুলি পরীক্ষা করতে পারে, একটি প্রতিক্রিয়া লুপে কোডগুলি পরিমার্জন করতে পারে।

আমরা দেখেছি যে এজেন্টরা টেস্ট দেখতে পেলে, তারা আরও বেশি চেষ্টা করেন এবং দীর্ঘ সময় ধরে কাজ করেন।

এবং ওপেন রানে, তাদের ২৫% বেশি টার্ন এবং ৪০% এজেন্ট রানটাইম ছিল।

প্রতিটি টাস্কে প্রায় ৩০ মিনিট, তারা ব্যর্থ টেস্টগুলি চালানো এবং ঠিক করার জন্য ব্যয় করেছে, কারণ তারা অন্ধভাবে ডিবাগিং করছিল না।

তাই, তারা ঠিক কী ব্যর্থ হয় তা দেখতে পায় এবং দুর্ভাগ্যবশত পাসের হারও প্রায় ৫০ শতাংশ পয়েন্ট বেড়ে যায়।

এবং এই অতিরিক্ত প্রচেষ্টা গড় পাস রেট উন্নত করে, যেমন আমি উল্লেখ করেছি।

কিন্তু শেষ পর্যন্ত নতুন ফ্রন্টিয়ার মডেল আসে এবং সেগুলি দ্রুত এই ওপেন ভ্যারিয়েন্টকে স্যাচুরেট করে দেয়।

Well, almost 90% of done of pass rate.

তাই, আমরা প্রাথমিক বেঞ্চমার্ক মেট্রিক হিসেবে বন্ধ সার্চ বন্ধ টেস্ট ভেরিয়েন্ট রেখেছি।

তবে, মডেলগুলি যখন জানে যে তাদের কীসের ভিত্তিতে গ্রেড করা হচ্ছে, তখন তারা কীভাবে আরও ভাল পারফর্ম করে তা দেখা এখনও খুব আকর্ষণীয়।

Tomáš Mlynarič

তবে, এটি আমাদের এজেন্টদের সম্পর্কে আরও ইনসাইট তৈরি করতে সাহায্য করেছে।

যেমন, মডেলগুলি কীভাবে তাদের নিজস্ব কাজ পরীক্ষা করে তা আমরা চেক করতে পারি।

সুতরাং, আমরা চার্ট থেকে দেখতে পাচ্ছি যে ফ্রন্টিয়ার মডেলগুলি আরও বেশি এবং আরও ভাল পরীক্ষা লেখে এবং তাদের পাসের হার বেশি।

অন্যান্য কিছু মডেল, তারা অতিরিক্ত আত্মবিশ্বাসী, আমি এটা করতে পারি, কোনও পরীক্ষা নেই।

তবে, কখনও কখনও সেগুলি এখনও ভালো।

তাই, আপনি যদি এমন মডেল ব্যবহার করেন যা টেস্টিংয়ের ক্ষেত্রে ততটা ভালো নয়, তাহলে আপনি সেগুলিকে আরও ভালো টেস্টিং স্কিল বা টেস্ট কীভাবে লিখতে হয় সেই বিষয়ে নির্দিষ্ট নির্দেশাবলী দিয়ে সাহায্য করতে পারেন।

কিন্তু পারস্পরিক সম্পর্ক মানেই কার্যকারণ সম্পর্ক নয়, CS, তাই না?

We need to have controlled experiment actually on this.

আরও ভাল টেস্টের জন্য প্রম্পট করলে স্কোর বাড়ে কিনা তা এখনও আমাদের দেখতে হবে।

তবে, আমরা Android পরীক্ষার অন্য অর্ধেকের উপর একটি পরীক্ষা চালিয়েছি এবং সেটি হল এজেন্টদের এমুলেটর ব্যবহার করতে দেওয়া।

শুরুতে, আমাদের বেঞ্চমার্কে, আমরা এমুলেটর সম্পর্কে কিছুই বলিনি।

আমরা ভেবেছিলাম, এজেন্টরা এটি বুঝতে পারবে, তাই না?

তাই, আমরা দেখেছি, ফলাফল হিসেবে, তাদের মধ্যে প্রায় কেউই আসলে এমুলেটর বুট করেনি।

আমি যেমন বলেছি, আমাদের বেঞ্চমার্কে UI টেস্ট খুবই গুরুত্বপূর্ণ এবং এমুলেটর ছাড়া UI টেস্ট করা সম্ভব নয়।

তাই, তারা সবাই খুব সহজ জিনিসে ব্যর্থ হচ্ছিল।

তাই, এখন আমরা দ্বিধায় পড়েছি।

আমরা কি এজেন্টদের বলি যে, আপনাকে এমুলেটর ব্যবহার করতে হবে এবং আসলে বেশি স্কোর করার ঝুঁকি নিতে হবে, নাকি আমরা কিছুই বলি না এবং আমরা আশা করি যে, আপনি জানেন, তারা এটি খুঁজে বের করবে?

তবে, আমাদের লক্ষ্য ছিল Android কোডিং এবং সমস্যা সমাধানের পরিমাপ করার জন্য একটি ন্যায্য বেঞ্চমার্ক হওয়া।

আমরা কিছু এনভায়রনমেন্টাল কোয়ার্কের মতো পরিমাপ করতে চাই না।

তাই, আমরা একটি মধ্যবর্তী পথ বেছে নিয়েছি।

আমরা তাদের বলেছি যে এভাবেই এমুলেটর শুরু করতে হয়, তবে এটি ব্যবহার করতে হবে কিনা, সেই বিষয়ে আমরা কিছু বলিনি।

সর্বোপরি, এমুলেটর শুরু করা এমন কিছু নয় যা আমাদের আসলে পরীক্ষা করতে হবে বা পরীক্ষা করতে চাই।

এবং আমরা সেই এমুলেটর নির্দেশের প্রভাব পরিমাপ করেছি।

এবং এখন, আমরা আসলে দেখেছি যে যখন আমরা তাদের কীভাবে করতে হবে তা দিয়েছিলাম, এজেন্টরা আসলে এমুলেটরটিকে আরও অনেক বেশি বুট করেছিল এবং আসলে UI পরীক্ষাগুলি চালিয়েছিল এবং এটি পাসের হারের উপর বড় প্রভাব ফেলেছিল, দুর্ভাগ্যবশত আমাদের জন্য।

তবে এটি আমাদের তাদের আসল কোডিং ভুল এবং সমস্যাগুলিও পরীক্ষা করতে দেয় এবং শুধু আনবুট করা এমুলেটরে ব্যর্থ হওয়ার মতো নয়।

তাই, সারসংক্ষেপ হল, প্রম্পটের নির্দিষ্টতা এখনও অনেক গুরুত্বপূর্ণ এবং আপনি যদি নিজের বেঞ্চমার্ক বা মূল্যায়ন ডিজাইন করেন, তাহলে আপনার ক্ষেত্রে আসলে কী গুরুত্বপূর্ণ তা পরীক্ষা করতে হবে।

যেমন, একটি উদাহরণ দেওয়া যাক: আপনি কোনও দক্ষতা বা টুলের টোকেন এফিশিয়েন্সি বা অন্য কিছু মূল্যায়ন করছেন, প্রথমে আপনাকে আসলে মূল্যায়ন পাস করার মাধ্যমে শুরু করতে হবে, এফিশিয়েন্সির জন্য পরিবর্তন করতে হবে এবং তারপরেও যাচাই করতে হবে যে এটি এখনও কম টোকেন দিয়ে পাস করছে কিনা।

আপনি অন্যভাবে করলে, আপনাকে একসাথে অনেক ভেরিয়েবল পরিবর্তন করতে হবে এবং আপনি জানতে পারবেন না যে আপনার করা পরিবর্তনটি আসলে এটিকে আরও ভাল করেছে কিনা।

Tomáš Mlynarič

লিডারবোর্ডে ফিরে যান।

আমি যেমন বলেছি, সেরা মডেলগুলি প্রায় ৪০% টাস্ক পাস করে এবং পাস রেটের জন্য সমস্ত চেক পাস করতে হবে।

আর তা না হলে, টাস্কটি সম্পূর্ণ করা যাবে না।

তাহলে প্রশ্ন হল, এজেন্টরা কি বাকি ৬০% ক্ষেত্রে কোনও কাজের জিনিস তৈরি করেনি?

না, তারা সেখানে পৌঁছে যাচ্ছে।

এজেন্ট আসলে কার্যকরী সমাধানের কতটা কাছাকাছি পৌঁছেছে তা দেখানোর জন্য, এক ধরনের দূরত্বের মতো, আমরা সম্পূর্ণ করার হার বা এক ধরনের আংশিক স্কোরও গণনা করি।

এটি চারটি বিভাগ জুড়ে একটি ওয়েটেড স্কোর: ভিজ্যুয়াল সামঞ্জস্য, ফাংশনাল, এটি সঠিকভাবে কাজ করে কিনা, কিছু টাস্ক-নির্দিষ্ট প্রয়োজনীয়তা এবং কিছু রিগ্রেশন চেক।

এবং আপনি দেখতে পাচ্ছেন যে নিম্ন র‍্যাঙ্কের মডেলগুলি প্রায় অর্ধেক কাজ শেষ করতে সক্ষম হয়, যেখানে ফ্রন্টিয়ার মডেলগুলি গড়ে প্রায় ৮০% কাজ সম্পূর্ণ করতে পারে, ৮০% এর বেশি কাজ, তবুও তারা মাত্র ৪০ ৪০% পাস করে।

তাই, কী হচ্ছে তা চেক করার জন্য আমরা Flutter থেকে Android-এ কনভার্সন নিয়ে একটি পরীক্ষা করেছি।

তাই আমরা প্রতি কয়েকটা এজেন্ট স্টেপ অন্তর সম্পূর্ণ করার হার আবার হিসেব করে দেখেছি যে সব ফ্রন্টিয়ার মডেলেই একই প্যাটার্ন দেখা যাচ্ছে।

প্রায় ১৪০টি ধাপে, তারা গড়ে প্রায় ৯০% স্কোর করার জন্য কাজ করছিল এবং তারপরে তারা আরও ৯০টি ধাপ বা প্রায় ৪০% রান খরচ করে ১০০% স্কোর করার চেষ্টা করছিল, কিন্তু তারা মাত্র ১ বা ২% বেশি স্কোর করতে পেরেছিল।

এবং আমরা মনে করি যে এটি আসলে আজকের এজেন্টিক ডেভেলপমেন্টকে প্রতিফলিত করে, যেখানে অনভিজ্ঞ ডেভেলপার বা ব্যবহারকারীরা দেখেন যে অ্যাপটি সম্পূর্ণ।

সবকিছু রেন্ডার করা হচ্ছে।

ইনপুট কিছুটা কাজ করেছে।

কোনও ক্র্যাশ নাও হতে পারে।

কিন্তু যখন একজন সিনিয়র ইঞ্জিনিয়ার এসে কোডটি দেখেন, তখন তিনি অনেক ত্রুটি দেখতে পান: তিনি আর্কিটেকচারাল সমস্যা, লাইফ সাইকেল সংক্রান্ত ত্রুটি এবং এই ধরনের জিনিস দেখতে পান।

Tomáš Mlynarič

শেষ করার আগে, Android Bench, আমাদের Work 2.0-কে আরও ভালোভাবে বুঝে নেওয়া যাক।

1.0-এর সাথে তুলনা করলে, আমাদের কাছে এখন মাত্র ৩০টি টাস্ক আছে এবং এটি ইচ্ছাকৃতভাবে করা হয়েছে।

আলাদা আলাদা ত্রুটি সমাধান এবং ছোট প্যাচের পরিবর্তে, আমাদের কাছে সম্পূর্ণ স্ক্রিন, মাল্টি-মডিউল মাইগ্রেশন, সম্পূর্ণ অ্যাপ কনভার্সন রয়েছে।

প্যাচগুলি এখন ডজন ডজন ফাইল জুড়ে অনেক বড়।

এবং আমাদের কাছে মাল্টিমোডাল UI চেক আছে।

এজেন্টদের আরও বেশি সময় ধরে এবং আরও কঠোর পরিশ্রম করতে হবে।

অন্যান্য ফ্রন্টিয়ার বেঞ্চমার্কের সাথে তুলনা করলে, আমরা এখনও দেখতে পাই যে আমাদের বেঞ্চমার্কে অনেক বেশি কোড পরিবর্তন করতে হয়।

এটি দূষণ-মুক্ত কারণ বেশিরভাগ টাস্কই একদম শুরু থেকে লেখা হয়েছে এবং এখনও উন্নতির অনেক সুযোগ রয়েছে।

আমি শুরুতেই বলেছি যে AI-এর দুনিয়ায় কয়েক মাসকে অনন্তকাল বলে মনে হয় এবং শেষ পর্যন্ত প্রতিটি বেঞ্চমার্ক সর্বোচ্চ সীমায় পৌঁছে যায় এবং স্যাচুরেটেড হয়ে যায়।

এবং যখন এটি করবে, আশা করি, আমরা আরও কঠিন এবং আরও জটিল কাজের দিকে এগিয়ে যাব যা আবার সেই যুগের সাথে AI-এর সেই অবস্থার সাথে অনুরণিত হবে।

এখন, মডেল এবং হার্নেসের তুলনা করতে এবং কিছু ইনসাইট পেতে Android Bench কম্পাস হিসেবে ব্যবহার করুন।

এবং আপনি যখন আরও গভীরে যেতে প্রস্তুত হবেন, তখন আপনার নিজস্ব কোড বেস এবং ওয়ার্কফ্লোতে একই বেঞ্চমার্কিং নীতি এবং মূল্যায়ন নীতিগুলি প্রয়োগ করুন কারণ আপনি আসলে যে কোডটি নিয়ে কাজ করেন তার উপর AI পরিমাপ করার চেয়ে ভাল আর কিছুই নেই।

এইভাবে আপনি AI-এর উত্তর সঠিক হওয়ার আশা করা থেকে শুরু করে সঠিক উত্তর পাওয়ার ব্যাপারে নিশ্চিত হতে পারবেন।

Android Bench-এর পক্ষ থেকে, আপনার মনোযোগের জন্য ধন্যবাদ।