اندروید بنچ ۲.۰: پیشروی در مرزها با وظایف چالش‌برانگیز و بلندمدت

وقتی برای اولین بار Android Bench را راه‌اندازی کردیم، پایه و اساس دقیقی برای ارزیابی چگونگی کمک مدل‌های زبانی بزرگ (LLM) به توسعه‌دهندگان در انجام وظایف اندروید در دنیای واقعی ایجاد کردیم. با تکامل سریع مدل‌ها و عامل‌های هوش مصنوعی، ما روش‌شناسی خود را به‌روزرسانی کرده‌ایم، مانند همسو کردن چارچوب معیار خود با چارچوب Harbor . امروز ما اولین مجموعه از وظایف بلندمدت (LHT) را منتشر می‌کنیم ، که وظایفی با پیچیدگی زیاد هستند که یک مهندس چندین روز یا حتی یک هفته برای تکمیل آنها زمان می‌برد. ما همچنین ارزیابی عامل‌محور را معرفی می‌کنیم که با عامل‌های ارائه‌دهندگان مدل مربوطه شروع می‌شود. این افزوده ما را به Android Bench 2.0 می‌رساند - یک ارتقاء عمده که برای ارزیابی مدل‌ها و عامل‌های هوش مصنوعی در برابر مقیاس، ابهام و حل مسئله چند مرحله‌ای پیچیده‌ای که هر روز با آن مواجه می‌شوید، طراحی شده است.

از اصلاحات تدریجی تا وظایف بلندمدت

اولین نسخه از اندروید بنچ، همراه با بنچمارک‌های مشابه اولیه کدنویسی هوش مصنوعی، بر تغییرات تدریجی در مخازن موجود تمرکز داشت که در بسیاری از موارد به رفع اشکالات یا درخواست‌های ویژگی‌های کوچک‌تر محدود می‌شد. این نشان‌دهنده قابلیت‌های کمک هوش مصنوعی در آن زمان و همچنین نحوه استفاده شما از آن بود.

برای ادامه کمک به شما در یافتن مدل‌ها و عامل‌های کدنویسی که به بهترین وجه با گردش کار توسعه شما مطابقت دارند، سطح ارزیابی‌های خود را ارتقا داده‌ایم تا با کاری که به هوش مصنوعی واگذار می‌کنید، مطابقت داشته باشد. Android Bench 2.0 این چالش‌های بلندپروازانه را با LHTها که شامل ارتقاء وابستگی‌ها، افزودن ویژگی‌های جدید، ساخت برنامه‌ها از ابتدا یا تبدیل یک برنامه چند پلتفرمی به اندروید است، منعکس می‌کند.

وظایف پیچیده نیاز به ارزیابی و امتیازدهی دقیق‌تری دارند

در وظایف مهندسی چند روزه، درجه‌بندی دودوییِ قبول یا رد، تصویر کاملی را ارائه نمی‌دهد.

برای مثال، یک عامل ممکن است ۴۰ صفحه را برای Jetpack Compose بازسازی کند، جداول پایگاه داده را تنظیم کند و ۹۰٪ الزامات را برآورده کند، اما در یک ادعای تک موردی شکست بخورد. امتیازدهی دودویی این اجرا را ۰٪ ارزیابی می‌کند که قابلیت‌های معماری مدل را پنهان می‌کند. ما در حال حرکت به سمت امتیازدهی مداوم هستیم تا سیگنال معنادارتری ارائه دهیم، هم برای توسعه مدل و هم برای درک شما از اینکه چگونه هوش مصنوعی می‌تواند به شما کمک کند.

ما این نرخ تکمیل را از طریق ترکیبی از عواملی مانند عملکرد، دقت بصری و اجتناب از رگرسیون محاسبه می‌کنیم. ما همچنین جریمه‌های امتیازدهی عینی را برای انحراف از دستورالعمل‌های ارزیابی یا محدودیت‌های ساختاری اعمال می‌کنیم. جدول امتیازات به‌روز شده را بررسی کنید و برای مشاهده عناصر اضافی مانند نرخ قبولی، نرخ تکمیل و میانگین هزینه‌ها برای هر مدل و هر وظیفه، روی نمای کارت هر مدل کلیک کنید.

بالاترین نرخ قبولی برای LHTها حدود ۲۸٪ است که بسیار پایین‌تر از حدود ۹۱٪ برای وظایف اصلی در معیار است.

وظایف بلندمدت، بینش‌های مفیدی را برای کمک هوش مصنوعی آشکار می‌کنند

فراتر از سنجش اینکه هوش مصنوعی چقدر خوب وظایف طولانی مدت را انجام می‌دهد، مجموعه داده‌های LHT به ما کمک می‌کند تا در مورد نقاط قوت و ضعف مدل‌های آزمایش شده اطلاعات بیشتری کسب کنیم و راهنمایی‌های کاربردی‌تری به شما ارائه دهیم.

در سطوح مختلف مدل، هوش مصنوعی در نوشتن کد جدید نسبت به بازسازی کد موجود، عملکرد بهتری دارد. بازسازی‌ها و مهاجرت‌ها پیچیده‌تر می‌شوند زیرا موفقیت به پیچیدگی معماری بستگی دارد تا حجم کد.

مدل‌ها قابلیت‌های قوی در تبدیل‌های قطعی و جاافتاده، مانند تبدیل جاوا به کاتلین، جایگزینی Retrofit با Ktor یا معرفی یک لایه ViewModel، نشان می‌دهند. آن‌ها این الگوها را به طور مداوم، حتی در بیش از ۱۲۵ فایل و بیش از ۸۰۰۰ خط کد، اعمال می‌کنند.

با این حال، مدل‌ها زمانی که وظایف نیاز به اعتبارسنجی در زمان اجرا دارند (مانند از دست دادن نمودارهای تزریق وابستگی)، شامل شکستن تغییرات چارچوب یا مواجهه با شکاف‌های دانش با کتابخانه‌های منتشر نشده، با مشکل مواجه می‌شوند. انتقال برنامه‌های چند پلتفرمی به اندروید همچنان یک چالش باز است - هیچ مدلی به نرخ قبولی ۱۰۰٪ نمی‌رسد و مدل‌های مرزی حداکثر به نرخ تکمیل ۸۰٪ می‌رسند.

معرفی ارزیابی‌های کارگزاران

برای اینکه به شما کمک کنیم درک بهتری از عملکرد مدل‌ها هنگام ادغام در گردش‌های کاری عامل‌محور خود داشته باشید، ما عامل‌های پرکاربرد را به ارزیابی خود اضافه می‌کنیم. ما با اجرای مدل‌های جدید در برابر LHTها با عامل‌هایی از ارائه‌دهنده مدل مربوطه شروع می‌کنیم. به عنوان مثال، ما GPT 5.6 Sol را روی Codex و Gemini 3.8 Flash را روی Google Antigravity اجرا کردیم. این جفت‌سازی نشان می‌دهد که چگونه طراحی مهار (harness design) بر نتایج توسعه‌دهندگان تأثیر مثبت می‌گذارد، زیرا دیده‌ایم که ذخیره‌سازی سریع و پنجره‌بندی فشرده ابزار می‌تواند منجر به کاهش توکن شود.

ما در آینده این موضوع را با برجسته کردن نتایج در ترکیب‌های مختلف مدل و عامل گسترش خواهیم داد تا به شما کمک کنیم کشف کنید کدام ترکیب‌ها برای شما و تیمتان بهترین عملکرد را دارند.

ما روی این معیار سرمایه‌گذاری می‌کنیم زیرا مهم است که شما بتوانید از عامل و مدل انتخابی خود برای توسعه اندروید استفاده کنید و در هفته‌های آینده اطلاعات بیشتری برای به اشتراک گذاشتن با شما خواهیم داشت.

مدل‌های جدید اضافه شد

علاوه بر این، ما همچنان در حال گسترش جدول امتیازات خود هستیم تا اطمینان حاصل کنیم که شما به‌روزترین داده‌ها را برای تصمیمات توسعه خود دارید. ما Gemini 3.8 Flash، Gemini 3.7 Flash، OpenAI's GPT-6، Anthropic's Fable 5.1، Kimi K3 و Qwen 3.8 Max را اضافه کرده‌ایم که در این بین، OpenAI's GPT-6 Astra با نرخ قبولی ۲۸٪ در صدر قرار دارد .

با نگاهی به آینده

Android Bench 2.0 محیطی قوی برای سنجش هوش مصنوعی برای توسعه اندروید ارائه می‌دهد. با ترکیب وظایف بلندمدت، ارزیابی چندوجهی، عامل‌ها و امتیازدهی مداوم، امیدواریم تیم‌های تحقیقاتی هوش مصنوعی را برای ایجاد شرکای کدنویسی هوش مصنوعی توانمندتر و قابل اعتمادتر توانمند کنیم و امیدواریم شفافیت بیشتری در مورد گزینه‌های شما برای توسعه هوش مصنوعی ارائه دهیم.

جدول امتیازات به‌روزرسانی‌شده را به همراه روش‌شناسی به‌روزرسانی‌شده بررسی کنید. بازخورد شما مستقیماً بر نحوه‌ی تکامل Android Bench تأثیر می‌گذارد، بنابراین لطفاً همچنان بازخورد خود را با ما در GitHub و همچنین کانال‌های اجتماعی ما مانند X و LinkedIn به اشتراک بگذارید.