Insight tentang pembuatan kode agen dari Android Bench

Tomáš Mlynarič

Pagi, semuanya.

Mari kita mulai.

Pada bulan Maret, kami meluncurkan Android Bench, set data dan papan peringkat kami untuk mengukur LLM pada tugas pengembangan Android.

Sejak itu, kami telah menjalankannya pada banyak model baru.

Dan baru bulan lalu, kami merilis Android Bench 2.0.

Meskipun baru beberapa bulan, dalam dunia AI, waktu tersebut terasa seperti selamanya.

Nama saya Tomáš, dan saya akan menceritakan perjalanan Android Bench dan bagaimana kami bisa sampai di posisi kami saat ini.

Mari kita mulai dengan 1.0.

Dalam versi 1.0, kami mengambil masalah dunia nyata dari repositori open source.

Kami memfilter project GitHub dengan masalah GitHub, permintaan pull yang menyelesaikan masalah tersebut, dan pengujian yang memverifikasi solusinya.

Kami membagi permintaan pull menjadi bucket tugas untuk model AI.

Laporan masalah GitHub menjadi petunjuk atau perintah untuk model, dan kami menempatkannya dalam status sebelum PR.

Setelah model membuat beberapa pekerjaan, kami mengambil pengujian dan menerapkannya ke output, yang memberi kami hasil lulus atau gagal.

Satu upaya AI untuk mencoba menyelesaikannya disebut uji coba.

Kita juga dapat membandingkannya berdasarkan solusi yang dibuat manusia dari PR tersebut, atau yang kami sebut sebagai solusi emas.

Metodologi ini mirip dengan tolok ukur SWE-bench yang cukup dikenal.

Kami memulai dengan lebih dari 10.000 tugas potensial, dan tidak semuanya cocok.

Beberapa memiliki petunjuk yang tidak lengkap atau petunjuk yang terlalu spesifik.

Pengujian mungkin telah digabungkan dengan solusi emas, atau status sebelum PR rusak.

Jadi, kami harus meninjau dan meninjau lagi untuk mendapatkan 100 tugas yang adil.

Selama peninjauan tersebut, kami menggunakan model tercanggih untuk mendapatkan beberapa hasil.

Kami memulai dengan sekitar 30% tugas yang diselesaikan, yang kami sebut sebagai tingkat kelulusan.

Kemudian, saat kami mengunci set data untuk rilis resmi, model teratas sudah mencapai sekitar 70%.

Tapi itu seperti sebulan kemudian.

Kemudian, kami memiliki rencana untuk mengevaluasi model baru setiap bulan, lalu kami mengamati bagaimana model tersebut menjadi lebih baik.

Dan dalam rilis Agustus, tingkat kelulusan 92% adalah untuk model terbaik.

Kami tahu bahwa standar kami terlalu rendah, dan set data ini sudah jenuh.

Tomáš Mlynarič

Namun, kami mengantisipasi hal itu, dan kami sudah bekerja keras untuk versi 2.0, yang kami rilis bulan lalu.

Tujuannya adalah, dan selalu, untuk meningkatkan standar dengan tugas Android yang kompleks dan nyata, serta memberikan panduan dan transparansi tentang performa LLM bagi Anda, para developer, sekaligus mendorong pembuat model untuk memprioritaskan Android dengan memberikan tolok ukur yang baik untuk, mendaki bukit.

Serta memberikan analisis dan hasil yang bermanfaat bagi Anda dan pembuat model.

Namun, kita juga perlu memperhitungkan kecerdasan, kegigihan, dan kecurangan.

Dan kita perlu mencegah risiko kontaminasi.

Salah satu masalah dengan metodologi SWE-bench adalah keterbukaan kode sumber yang sebenarnya.

OpenAI memublikasikan artikel.

Mereka menemukan bahwa model dapat menyelesaikan kata-kata berikutnya dari petunjuk, atau dapat menyelesaikan tugas dengan error yang tidak jelas yang bukan bagian dari petunjuk.

Mereka menyadari bahwa pembuat model melatih modelnya menggunakan kode open source dan SWE-bench terkontaminasi.

Jadi, untuk versi 2.0, kami sebenarnya merahasiakan kodenya untuk mencegah pelatihan pada kode tersebut.

Kami membagi pekerjaan menjadi empat alur kerja.

Pertama, kami melakukan konversi aplikasi, dengan mengambil aplikasi open source, Flutter, dan React Native, lalu memberi tahu agen untuk mengonversinya menjadi solusi Android native.

Hal ini sebenarnya mencerminkan tren migrasi lintas platform ke native yang kita lihat sekarang.

Alur kerja kedua adalah fitur baru dan integrasi platform.

Mereka diintegrasikan ke dalam code base produksi yang sudah ada.

Misalnya, di Now in Android, kami menambahkan fitur video, atau picture-in-picture, dan semacamnya.

Alur kerja ketiga adalah migrasi.

Kami mengupgrade aplikasi open source produksi yang kami tutup, dengan library dan arsitektur modern.

Misalnya, Nav 2 ke Nav 3, tampilan XML ke Compose, atau hal-hal seperti panel tunggal ke tata letak adaptif.

Dan yang terakhir adalah aplikasi greenfield internal yang dibuat dari awal menggunakan tiruan desain visual.

Di sini, contohnya adalah alur autentikasi OTP SMS lengkap, pelacakan pesanan dengan Google Maps, dan lainnya.

Tomáš Mlynarič

Hanya dengan beberapa engineer, kami membuat aplikasi dengan ukuran yang sama seperti Now in Android.

Namun, tugas baru menghadirkan tantangan baru.

Pertama: menilai agen dengan benar.

Pengujian benchmark jauh lebih sulit daripada pengujian untuk aplikasi Anda karena harus lulus solusi yang valid, bukan hanya satu, dan semakin besar tugasnya, semakin banyak solusi yang valid.

Di versi 1.0, benchmark ini sebagian besar mengandalkan pengujian unit, dan pengujian unit sangat buruk dalam hal agnostik.

import com.foodvibes.MyViewModel

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

    assertTrue(vm.retried)
}

Keduanya memerlukan nama class atau fungsi yang tepat.

Seperti dalam kasus ini, tidak ada pengujian yang rumit, tetapi pada dasarnya, agen dapat memberi nama yang berbeda untuk hal-hal tersebut, atau bahkan jika mereka tidak memberi nama yang berbeda, jika mereka memasukkannya ke dalam paket yang berbeda, pengujian akan gagal dikompilasi, dan oleh karena itu, tidak akan dapat digunakan untuk kasus kita.

import com.foodvibes.feature.my.RetriableViewModel

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

    assertTrue(vm.tried)
}

Jadi, secara teknis kita bisa menentukan API dalam perintah, tetapi itu akan memberikan terlalu banyak detail, atau akan membuat perintah terlalu panjang dengan terlalu banyak persyaratan pengujian.

Jadi, solusinya adalah kita melakukan pengujian agnostik implementasi.

Pengujian ini sangat umum dan berfokus pada hasil, menguji hasil dan perilaku, bukan internal.

Kami menggunakan Pengujian UI deterministik, yaitu pengujian yang berinteraksi dengan informasi layar publik, seperti yang dilakukan pengguna.

Untuk itu, kami menggunakan UI Automator atau pengujian Compose UI, tetapi kami juga memiliki skrip khusus, yang memeriksa beberapa batasan sistem eksternal, seperti, misalnya, apakah panggilan jaringan memiliki data yang tepat, atau apakah data yang tepat disimpan ke dalam database tanpa mengetahui helper internal atau DAO.

Selain itu, kami juga memiliki pemeriksaan statis, untuk, Anda tahu, memeriksa seperti izin dalam manifes atau apakah library ada dalam file build dan hal-hal semacam itu.

Selain itu, kami juga memiliki pengujian hybrid yang merupakan kombinasi dari skrip tersebut dan pengujian UI.

Ini adalah contoh salah satu pengujian hibrid.

Mereka mengemudi di luar emulator.

Jadi, ini adalah pengujian untuk alur autentikasi OTP SMS, yang mengharuskan skrip menghitung hash aplikasi terlebih dahulu agar dapat mengirim SMS dengan benar ke emulator, lalu memulai pengujian, pengujian UI Automator, dan meneruskan beberapa OTP yang dihasilkan secara acak yang diperlukan, dan mengirim SMS ke emulator dengan perintah ADB.

Dan pengujian hanya memeriksa apakah input memiliki angka yang tepat.

Pada dasarnya, seperti itu.

Tidak ada penggabungan implementasi, hanya pemeriksaan, hanya memeriksa apakah alurnya berfungsi.

Masalah penilaian kedua adalah tugas kami memerlukan multimodalitas.

Agen harus membuat UI, atau kita memberikan tiruan desain kepada mereka.

Untuk itu, cara termudah adalah menggunakan pengujian screenshot.

And we knew from the beginning that the screenshot thresholds will need to be higher, but, they failed anyway.

Kami mencoba beberapa algoritma perbedaan piksel yang berbeda, tetapi gagal pada hal-hal seperti derau tingkat sistem, di mana status bar emulator berbeda, atau ikon baterai, atau bahkan seperti anti-aliasing hardware font yang berbeda.

Namun, pengujian ini juga gagal pada implementasi yang agak valid, misalnya, padding-nya kecil, sedikit berbeda, atau ada sedikit perbedaan warna, seperti UI-nya bisa sepenuhnya benar, tetapi latar belakangnya akan sedikit berbeda warna, dan algoritma pembedaan piksel akan gagal.

Jadi, untuk itu, kami menggunakan dan membangun Multimodal LLM Judge yang membandingkan pasangan screenshot seperti dalam pengujian screenshot dan memberi kami skor, tetapi juga, Penalaran Struktural tentang skor tersebut.

Kami juga memberinya beberapa dump hierarki aksesibilitas yang memeriksa apakah strukturnya sudah benar dan apakah paritas strukturalnya sudah benar.

Kami mencobanya secara empiris dalam banyak uji coba, dan kami melihat bahwa model ini memiliki konsistensi yang tinggi dan mengabaikan masalah yang kami lihat.

Jadi, sekarang, kami memiliki cara yang baik untuk memverifikasi visual dan perilaku secara agnostik, dan kami melihat bahwa agen mencoba memalsukan semuanya.

Silakan.

Tomáš Mlynarič

Dimulai dengan sederhana.

Saat ini, agen pada dasarnya, "Oke.

Saya punya tugas.

Mari kita lihat GitHub.

Mari kita cari solusinya."

Jadi, itulah yang mereka lakukan sebagai langkah pertama.

Mereka mencoba menelusuri GitHub atau internet untuk menemukan solusi yang valid, itulah sebabnya kita perlu menjaga kode sumber tetap tertutup dan tidak dapat diakses publik.

Tapi itu, kayaknya, mudah.

Dalam beberapa uji coba, kami mengatakan bahwa semuanya lulus 100%, dan agennya berkata, "Kemenangan yang luar biasa!"

Oke.

Menarik, apa yang mereka temukan?

Namun, kami mengamati lintasannya lebih dekat, dan mereka seperti, "Saya tidak bisa melakukan ini.

Saya akan, bagaimana jika saya mengubah nilai minimum menjadi 80% dari pengujian screenshot?"

// AuthFlowScreenshotTests.kt

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

Dan rasanya seperti, "Ya, kemenangan, semuanya berlalu."

Ya, tetapi pengujian screenshot tidak berguna.

Namun, itu bukanlah yang paling canggih.

Dalam beberapa kasus, sebenarnya di aplikasi konversi Flutter, agen mencoba dan mencoba membangun Android, dan seperti, "Saya tidak tahu harus berbuat apa."

Jadi, mereka mengambil screenshot yang kami berikan, lalu menempatkannya sebagai drawable di latar belakang.

Dan sekarang, pengujian screenshot berhasil.

Asyik!

Namun, pengujian UI masih gagal, jadi mereka berpikir, "Saya akan menempatkan lapisan overlay yang tidak terlihat di atasnya dengan tombol, teks, dan tag pengujian, semua yang kita perlukan.

Sekarang semuanya berwarna hijau.

Luar biasa.

Kerja bagus."

Tidak, ada satu yang sangat bagus.

Jadi, kita memiliki tugas migrasi Java ke Kotlin, yang pada dasarnya mengharuskan agen untuk melakukan migrasi dari Java ke Kotlin, bukan?

Mereka tidak dapat membuatnya berfungsi.

Sepertinya masih ada yang gagal, jadi agen berpikir, "Baiklah, saya akan mengambil class yang dikompilasi dari Java, dan saya akan memasukkannya ke dalam JAR, lalu saya akan menambahkannya ke file build sebagai library biasa.

Jadi sekarang, setiap pengujian lulus, tetapi kita memiliki pemeriksaan statis yang memeriksa file Java, jadi, ya, saya akan menghapusnya."

Saya menghapus file Java, semuanya berwarna hijau, kecuali Kotlin yang masih gagal, jadi mereka seperti, "Baiklah, saya akan menghapus set sumber Kotlin, dan sekarang semuanya lulus.

Bagus."

Saya tidak tahu apakah ini termasuk curang.

Maksud saya, ini sangat kreatif.

Jadi, untuk mencegah semua itu, kami membuat pendeteksi kecurangan yang memiliki tiga pertahanan.

Kita melihat hierarki UI, menerapkan berbagai ukuran layar sehingga latar belakangnya terdistorsi, dan kita melihatnya.

Namun, kami juga mereset pengujian, dan kami memeriksa apakah ada pengujian yang dimanipulasi sehingga tidak dapat mengubah nilai minimum.

Lalu, kami juga memiliki, misalnya, LLM-as-a-Judge, yang mengaudit lintasan dan output aktual agen untuk melihat hal-hal yang aneh.

Dan jika terjadi sesuatu, kita tinggal berkata, "Oke, langsung gagal."

Tomáš Mlynarič

Jadi sekarang, semua jalan pintas hilang, tidak ada pencarian solusi, tidak ada pengujian unit yang rapuh atau UI palsu.

Jadi, saat kita memaksa agen untuk benar-benar merekayasa aplikasi Android, seperti apa hasilnya?

Jadi, per hari Senin, mungkin Anda melihat postingan blog, angkanya terlihat seperti ini.

Bahkan agen terbaik hanya lulus sekitar 40% dari tugas kami, dan sebagian besar agen tercanggih berada di antara 20 hingga 40%.

Hal ini bagus bagi kami sebagai pembuat tolok ukur, karena memberikan keseimbangan yang tepat, yaitu ada nilai dunia nyata dari tugas yang kami berikan, tetapi juga ada banyak ruang untuk berkembang.

Jadi, mari kita lihat hasilnya.

Sekarang kita dapat melihat hasilnya dari berbagai perspektif.

Kita dapat melihat beberapa insight yang telah kita temukan.

Pertanyaan pertama yang mungkin Anda miliki saat melihat diagram adalah, berapa biaya untuk menjalankan agen tersebut?

Dan perusahaan AI biasanya melaporkan biaya per token, untuk beberapa token input, output, mungkin token cache.

Dan mungkin itu adalah argumen pengambilan keputusan dalam kasus Anda.

Namun, kita bisa melihatnya dari perspektif lain.

Kita dapat memetakan diagram yang sama pada ruang 2D dengan biaya rata-rata per tugas, bukan token, jadi berapa biaya per tugas dibandingkan dengan tingkat kelulusan.

Dan di sini, kita dapat melihat bahwa beberapa model tiba-tiba menjadi jauh lebih banyak bicara.

Model ini menghabiskan lebih banyak waktu atau token per tugas, sementara model lain menyelesaikan lebih banyak tugas dengan biaya lebih rendah.

Namun, jika kita juga menambahkan harga per token ke diagram yang sama, kita dapat melihat bahwa, apa yang benar-benar diiklankan oleh perusahaan AI tidak sesuai dengan apa yang benar-benar Anda bayar, per tugas.

Jadi, Anda dapat melihat bahwa agen dengan tingkat kelulusan terbaik sebenarnya adalah salah satu yang termurah per token, tetapi paling mahal per tugas.

Atau, agen lain dengan harga token yang sama persis lulus sekitar 30% tugas, tetapi harganya 15 kali lebih murah.

Jadi, harga token bukanlah metriknya.

Beberapa di antaranya adalah model yang mengeksplorasi kode lebih lanjut, membangun ulang, menjalankan ulang, dan setiap langkah menghabiskan lebih banyak token.

Jadi, kesimpulannya adalah jangan hanya melihat harga, per, biaya per token.

Pilih model, lihat data sebenarnya, seperti menggunakannya dalam kasus Anda, atau lihat Android Bench untuk mengetahui model mana yang benar-benar menghabiskan paling banyak tugas, token pada tugas.

Beberapa di antaranya, Anda tahu, beberapa memerlukan lebih banyak langkah meskipun lebih murah per token.

Namun, ada aspek tambahan untuk pertanyaan yang sama.

Ini adalah diagram yang sama, tetapi kita juga dapat melihat dan menampilkan durasi yang diperlukan agen untuk menyelesaikannya.

Kita dapat melihat bahwa agen dengan tingkat kelulusan tertinggi mungkin adalah yang paling lambat.

Misalnya, kita dapat melihat bahwa beberapa tugas memerlukan waktu hampir dua jam per tugas.

Mereka terus membangun ulang, menguji ulang hingga berhasil.

Ya, pengujian ini memiliki tingkat kelulusan terbaik, tetapi juga memerlukan waktu paling lama.

Beberapa agen yang lebih murah masih membutuhkan waktu sekitar satu setengah jam per tugas, tetapi tanpa hasil yang lebih baik.

Atau, agen lain, mereka menyelesaikannya dalam waktu kurang dari 20 menit dan masih menyelesaikan lebih dari seperempat tugas.

Jadi, model yang kecil dan ringan biasanya lebih cepat dan lebih murah, tetapi lebih sering gagal dalam tugas-tugas yang sulit.

Kesimpulannya adalah tidak ada satu model terbaik.

Hal ini bergantung pada hal yang Anda optimalkan.

Apakah tingkat kelulusan?

Apakah biaya?

Apakah fitur ini adalah Waktu tunggu?

Dalam hal ini, bergantung pada jenis pekerjaan yang Anda lakukan, jika Anda tidak mengerjakan tugas yang sulit, pertimbangkan untuk menggunakan model yang lebih cepat yang menyelesaikan pekerjaan dengan lebih murah dan lebih cepat.

Namun, biaya dan kecepatan hanya memberi tahu Anda cara agen berjalan, bukan alasan agen gagal dalam sebagian besar uji coba.

Jadi, kami memeriksa eksekusi yang gagal, dan kami melihat bahwa agen sering berhenti lebih awal.

Mereka yakin bahwa mereka sudah selesai.

Tugas selesai.

Oke, aku pulang.

Namun, seperti yang disebutkan, dalam paket tugas, agen hanya menerima petunjuk dan status sebelum.

Mereka tidak dapat melihat pengujian.

Mereka melihat bahwa mereka tidak dapat melihat rangkaian verifikasi.

Jadi, kami bertanya, bagaimana jika, apa yang terjadi jika kami membiarkan mereka melihat tesnya?

Jadi, kami bereksperimen dan memiliki varian pengujian terbuka dari tugas yang sama, dengan agen mendapatkan suite pengujian verifikasi yang gagal di awal.

Jadi, sekarang, mereka menjalankan pengujian secara iteratif.

Mereka dapat memeriksa error, memperbaiki kode dalam feedback loop.

Dan kami menemukan bahwa ketika agen melihat tes, mereka berusaha lebih keras dan bekerja lebih lama.

Dan dalam operasi terbuka, mereka memiliki giliran 25% lebih banyak dan runtime agen 40%.

Hampir 30 menit per tugas, mereka menghabiskan waktu untuk menjalankan dan memperbaiki pengujian yang gagal, karena mereka tidak melakukan proses debug secara membabi buta.

Jadi, mereka melihat dengan jelas apa yang gagal, dan sayangnya tingkat kelulusan juga melonjak hampir 50 poin persentase.

Upaya ekstra ini meningkatkan tingkat kelulusan rata-rata, seperti yang saya sebutkan.

Namun, model termutakhir baru akhirnya muncul, dan dengan cepat mengungguli varian terbuka ini.

Hampir 90% dari tingkat kelulusan.

Jadi, kami mempertahankan varian pengujian tertutup penelusuran tertutup sebagai metrik tolok ukur utama.

Namun, tetap sangat menarik untuk melihat bagaimana model sebenarnya lebih baik saat mengetahui apa yang dinilai.

Tomáš Mlynarič

Namun, hal ini memungkinkan kami membangun lebih banyak insight seputar agen.

Misalnya, kita dapat memeriksa cara model menguji pekerjaannya sendiri.

Jadi, kita dapat melihat dari diagram bahwa model termutakhir menulis lebih banyak pengujian yang lebih baik, dan memiliki tingkat kelulusan yang lebih tinggi.

Beberapa model lain terlalu percaya diri, saya bisa melakukannya, tanpa pengujian.

Terkadang, makanan tersebut masih layak dikonsumsi.

Jadi, jika Anda menggunakan model yang kurang baik dalam pengujian, Anda dapat membantunya dengan memberikan keterampilan pengujian yang lebih baik, atau petunjuk khusus tentang cara menulis pengujian.

Tapi korelasi tidak berarti kausalitas, CS, kan?

Kita perlu melakukan eksperimen terkontrol untuk hal ini.

Kita masih perlu melakukan pengujian, apakah perintah untuk pengujian yang lebih baik benar-benar meningkatkan skor.

Namun, kami menjalankan eksperimen pada separuh pengujian Android lainnya, dan eksperimen tersebut membuat agen menggunakan emulator.

Di awal, dalam benchmark, kami tidak membahas emulator.

Kami berasumsi, agen seharusnya bisa mengetahuinya, bukan?

Jadi, kami melihat, sebagai hasilnya, hampir tidak ada yang benar-benar melakukan booting pada emulator.

Seperti yang saya sebutkan, pengujian UI kami cukup penting dalam benchmark, dan tanpa emulator, Anda tidak dapat benar-benar menggunakan pengujian UI.

Jadi, semuanya gagal dalam hal yang sangat sederhana.

Jadi, sekarang kita menghadapi dilema.

Apakah kita memberi tahu agen bahwa mereka perlu menggunakan emulator, dan berisiko mendapatkan skor yang lebih tinggi, atau apakah kita tidak mengatakan apa-apa, dan berharap mereka, Anda tahu, mengetahuinya?

Namun, tujuan kami adalah menjadi tolok ukur yang adil dalam mengukur coding dan pemecahan masalah Android.

Kita tidak ingin mengukur keunikan lingkungan.

Jadi, kami memilih jalan tengah.

Kami memberi tahu mereka bahwa ini adalah cara memulai emulator, tetapi kami tidak menyebutkan apakah mereka harus menggunakannya atau tidak.

Lagi pula, memulai emulator bukanlah hal yang benar-benar perlu atau ingin kita uji.

Lalu, kami mengukur efek dari instruksi emulator tersebut.

Dan sekarang, kami benar-benar melihat bahwa ketika kami memberi mereka petunjuk, agen benar-benar melakukan booting emulator lebih banyak dan benar-benar menjalankan pengujian UI, dan sayangnya bagi kami, hal itu berdampak besar pada tingkat kelulusan.

Namun, hal ini juga memungkinkan kami memeriksa kesalahan dan masalah coding yang sebenarnya, bukan hanya, misalnya, kegagalan pada emulator yang tidak di-booting.

Jadi, kesimpulannya, spesifikasi perintah masih sangat penting, dan jika Anda mendesain tolok ukur atau evaluasi sendiri, Anda perlu menguji apa yang benar-benar penting dalam kasus Anda.

Misalnya, Anda mengevaluasi efisiensi token atau keterampilan atau alat. Pertama, Anda harus memulai dengan evaluasi yang lulus, melakukan perubahan untuk efisiensi, lalu memverifikasi bahwa evaluasi tersebut masih lulus dengan lebih sedikit token.

Jika Anda melakukannya dengan cara lain, Anda akan memiliki terlalu banyak variabel yang berubah sekaligus, dan Anda tidak akan tahu apakah perubahan tersebut benar-benar membuat performa menjadi lebih baik.

Tomáš Mlynarič

Kembali ke papan peringkat.

Seperti yang saya sebutkan, model terbaik lulus sekitar 40% tugas, dan tingkat kelulusan mengharuskan semua pemeriksaan lulus.

Jika tidak, tugas akan gagal.

Jadi, pertanyaannya adalah, apakah agen tidak menghasilkan apa pun yang berguna untuk 60% sisanya?

Tidak, mereka sedang menuju ke sana.

Untuk menunjukkan seberapa dekat agen sebenarnya dengan solusi yang berfungsi, seperti jarak, kami juga menghitung rasio penyelesaian atau semacam skor parsial.

Skor ini adalah skor berbobot di empat kategori: konsistensi visual, fungsional, apakah berfungsi dengan baik, beberapa persyaratan khusus per tugas, dan beberapa pemeriksaan regresi.

Anda dapat melihat bahwa model dengan peringkat lebih rendah mampu menyelesaikan sekitar setengah dari pekerjaan, sedangkan model termutakhir mampu menyelesaikan dan mencapai rata-rata hampir 80%, lebih dari 80% tugas, tetapi hanya lulus 40%.

Jadi, kami melakukan eksperimen pada konversi Flutter ke Android untuk memeriksa apa yang terjadi.

Jadi, kami menghitung ulang rasio penyelesaian setiap beberapa langkah agen, dan kami melihat pola yang sama di semua model termutakhir.

Sekitar 140 langkah, mereka berupaya mencapai skor rata-rata hampir 90%, lalu menghabiskan 90 langkah lagi atau hampir 40% dari proses untuk mencoba menutup kesenjangan hingga 100%, tetapi mereka hanya mampu mencetak skor sekitar 1 atau 2% lebih banyak.

Dan kami rasa ini mencerminkan pengembangan agen saat ini, di mana developer atau pengguna yang belum berpengalaman melihat aplikasi sudah selesai.

Semuanya sedang dirender.

Inputnya lumayan berhasil.

Mungkin tidak ada error.

Namun, saat engineer senior datang dan melihat kodenya, mereka akan melihat banyak kekurangan: mereka melihat masalah arsitektur, kekurangan siklus proses, dan hal-hal semacam itu.

Tomáš Mlynarič

Sebagai penutup, mari kita lihat Android Bench, karya 2.0 kami, dari perspektif yang lebih luas.

Dibandingkan dengan 1.0, kini kami hanya memiliki 30 tugas, dan itu disengaja.

Alih-alih perbaikan bug yang terisolasi dan patch kecil, kami memiliki layar lengkap, migrasi multi-modul, dan konversi seluruh aplikasi.

Patch kini jauh lebih besar di puluhan file.

Dan kami memiliki pemeriksaan UI multimodal.

Agen harus berjalan lebih lama dan bekerja lebih keras.

Jika dibandingkan dengan benchmark frontier lainnya, kita masih dapat melihat bahwa benchmark kita memerlukan perubahan kode yang jauh lebih besar.

Benchmark ini bebas kontaminasi karena sebagian besar tugas ditulis dari awal, dan masih ada banyak ruang untuk berkembang.

Seperti yang saya katakan di awal, beberapa bulan di dunia AI terasa seperti selamanya, dan pada akhirnya, setiap tolok ukur akan mencapai batas maksimal dan jenuh.

Dan saat hal ini terjadi, semoga kita akan mendorong ke arah tugas yang lebih sulit dan lebih kompleks yang akan kembali beresonansi dengan era tersebut dengan status AI tersebut.

Sekarang, gunakan Android Bench sebagai kompas untuk membandingkan model dan harness, serta mungkin mempelajari beberapa insight.

Dan saat Anda siap untuk mempelajari lebih dalam, terapkan prinsip tolok ukur dan prinsip evaluasi yang sama ke code base dan alur kerja Anda sendiri karena tidak ada yang lebih baik daripada mengukur AI pada kode yang benar-benar Anda gunakan.

Dengan begitu, Anda tidak perlu lagi menebak-nebak apakah AI memberikan jawaban yang benar atau tidak.

Atas nama seluruh tim Android Bench, terima kasih atas perhatian Anda.