Alur kerja coding agentic dengan model kecil

Oke.

Halo, semuanya.

Nama saya Jose, dan saya di sini bersama Ian dan Zoe.

Kita semua tahu tentang LLM.

Kami menggunakannya untuk berbagai hal: menemukan resep, meringkas video YouTube, dan coding.

Ada LLM yang sangat besar, seperti model Gemini, yang mampu melakukan hal-hal yang benar-benar luar biasa, tetapi dalam pembahasan ini, kita akan membahas model bahasa kecil.

Model ini juga merupakan LLM karena sesuatu yang memiliki 4 miliar parameter tidak mungkin kecil, tetapi mulai sekarang kita akan membedakannya, Model Termutakhir dan Model Bahasa Kecil, roket dan sepeda.

Kita akan membahas model kecil bukan sebagai alternatif untuk model termutakhir, tetapi sebagian besar untuk melengkapinya.

Kita akan mempelajari semua manfaat model bahasa kecil, terutama jika model tersebut bersifat terbuka, memiliki bobot terbuka, dan dapat didownload, tetapi mari kita lihat biayanya sejenak.

Untuk presentasi ini, saya telah menjalankan banyak benchmark, dan salah satunya adalah set data berisi 200 tugas sedang dan sulit yang menggunakan hampir 131 juta token dengan biaya kurang dari $9.

Saya menggunakan Gemma 4 untuk ini, jadi saya bisa mendownloadnya dan menjalankannya di hardware saya sendiri secara gratis, tetapi saya menjalankannya di gateway komersial hanya untuk perbandingan yang adil.

Jadi, berapa biaya yang diperlukan untuk model termutakhir?

Sekitar 20 hingga 200 kali lebih banyak, bergantung pada caching token dan faktor lainnya.

Jadi, sepeda mungkin bukan alat transportasi tercepat, tetapi jelas merupakan yang paling efisien.

Benar.

Jadi, pertanyaan yang jelas adalah apa perbedaan kualitas dan akurasinya?

Dalam set data khusus ini, Gemma 4 dapat menyelesaikan 53% tugas.

Artinya, ada dua hal.

Jika Anda menggunakan model termutakhir untuk menjalankan tugas di sebelah kiri, hal ini mungkin berlebihan.

Jika Anda menggunakan model kecil untuk menjalankan tugas di sebelah kanan, Anda harus memandu model menuju solusi atau menggunakan model yang lebih besar.

Dalam diskusi ini, kami ingin membantu Anda memaksimalkan setiap token.

Zoe akan memandu Anda memilih model kecil, dan Ian akan membahas model Gemma agar Anda memahami cara menyusun pemikiran tentang apa yang dapat dilakukan model tersebut.

Kemudian, kami akan menunjukkan cara cepat untuk mencoba Gemma 4 di Android Studio, dan terakhir, kami akan menunjukkan cara menyesuaikan model kecil ke dalam alur kerja harian Anda serta tolok ukur pengembangan Android yang sebenarnya untuk membantu Anda membangun intuisi tentang apa yang dapat dilakukan model tersebut.

Sekarang, mari kita dengarkan penjelasan Zoe.

Terima kasih banyak, Jose.

Jadi, menggunakan satu model untuk semuanya itu seperti memecahkan kacang dengan palu godam, bukan?

Cara ini efisien, tetapi agak tidak proporsional.

Jadi, saat Anda memikirkan model kecil, ini hampir seperti Anda memperluas kumpulan alat Anda.

Untuk mengetahui apa yang harus Anda bawa ke dalam alur kerja, Anda perlu membuka set alat, melihat apa yang tersedia, apa spesifikasinya, dan apa kegunaannya.

Jadi, untuk memilih model kecil, Anda perlu mengetahui model kecil.

Jenis model yang paling sering dipikirkan orang saat memikirkan model bahasa adalah model bahasa autoregresif.

Ini bersifat autoregresif karena berdasarkan input yang dipotong menjadi token, model ini memilih token berikutnya yang paling mungkin dari daftar kandidat.

Kemudian, token berikutnya yang paling mungkin dipilih akan kembali ke input, dan seterusnya, yang mampu menghasilkan respons yang koheren dan terdengar cerdas, tetapi memiliki beberapa peringatan, termasuk, tetapi tidak terbatas pada, bekerja secara linear.

Jadi, kita dapat bekerja secara non-linear.

Model difusi memiliki pendekatan yang sama, tetapi berfungsi pada satu blok token sekaligus.

Ini hampir seperti sketsa yang mulai terlihat jelas.

Dalam hal ini, DiffusionGemma bekerja pada potongan 256 token sekaligus.

Jadi, pada dasarnya, Anda mendapatkan tiket yang berfungsi di seluruh blok, sehingga dapat menghasilkan hasil dengan latensi yang lebih rendah.

Jadi, oke, set alat kita memiliki model yang dapat menulis, bukan?

Salah.

Jadi, pada dasarnya, model embedding mengubah objek seperti gambar, teks, atau konsep lainnya menjadi vektor.

Jadi, hal ini memberi kita pemetaan, katakanlah koordinat, ke dalam ruang berdimensi tinggi yang memungkinkan kita membandingkan dua hal secara konseptual.

Jadi, misalnya, jika hot dog adalah sandwich, keduanya kemungkinan akan mengarah ke atau berakhir di ruang yang berdekatan.

Oleh karena itu, kemampuan untuk memeriksa apakah dua konsep terkait menjadi, katakanlah, sedikit matematika, bukan model pass, yang bisa dibilang juga sedikit matematika, tetapi Jadi, paradigma ini melangkah lebih jauh, bukan?

Ada juga model yang lebih kecil dan terspesialisasi yang mampu melakukan satu tugas, dan melakukannya dengan sangat baik.

Beberapa contohnya adalah, misalnya, kita memiliki model fungsi yang mengubah bahasa alami menjadi panggilan API, model vision yang saya yakin Anda tahu kemampuannya dari namanya, atau, misalnya, pengklasifikasi yang dapat memberikan skor pada input berdasarkan parameter tertentu.

Oke, jadi ada banyak pilihan, bukan?

Ada banyak jenis model, dan model tersebut memiliki dimensi, ukuran, jendela konteks, kemampuan, dan jejak memori yang berbeda. Setelah Anda membuka kotak alat dan mempertimbangkan setiap kemungkinan, opsinya akan bertambah secara eksponensial hingga membuat penggemar DIY merasa sangat gembira atau bingung karena terlalu banyak pilihan.

Jadi, bagaimana cara memilih model kecil?

Mari kita mulai dengan membuka toolbox model kecil terbuka yang dapat berjalan secara lokal, yaitu model Gemma.

Silakan, Ian.

Terima kasih, Zoe.

Jadi, seperti yang disebutkan Jose di awal, model bahasa kecil mungkin dapat melakukan sekitar 50% tugas secara langsung.

Namun, mengapa Anda memilih model lokal?

Jadi, ada empat hal yang perlu diperhatikan.

Jadi, yang pertama adalah privasi.

Misalnya, Anda mungkin memiliki kunci API, kode eksklusif, atau hal-hal yang benar-benar tidak boleh keluar dari laptop Anda.

Yang kedua adalah latensi.

Jadi, saat model benar-benar dimuat ke dalam memori, baik memori grafis maupun memori terpadu, Anda akan mendapatkan respons segera setelah komputasi selesai.

Jadi, tidak ada waktu round-trip ke server, tidak ada biaya latensi tambahan di sana.

Berikutnya adalah biaya marginal nol.

Jadi, model akan hemat biaya jika Anda dapat mengontrol tempat model tersebut dijalankan.

Jadi, dalam kasus menjalankan sesuatu di komputer lokal, misalnya, hal ini mungkin melakukan percobaan ulang tambahan dalam loop error.

Anda tidak perlu membayar apa pun, dan tidak ada biaya API yang tidak terduga untuk bagian tersebut.

Dan terakhir, yang keempat adalah akses offline.

Jadi, bayangkan Anda dapat menggunakannya di pesawat, kereta, bus, atau kereta bawah tanah, pada dasarnya di mana pun Anda menjalankan model di hardware Anda.

Kedengarannya bagus, tetapi ada dua faktor utama yang perlu kita pertimbangkan saat membuat keputusan ini.

Jadi, yang pertama adalah memori, dan yang kedua adalah kecepatan.

Jadi, jika Anda melihat diagram ini, jika Anda melihat dua model terbawah, 26B dan 31B, keduanya memerlukan lebih dari 50 GB RAM video untuk dijalankan di BF16, yang merupakan kuantisasi 16-bit.

Jadi, tantangannya di sini adalah hal itu tidak akan muat di banyak hardware.

Jadi, kita melakukan proses yang disebut kuantisasi yang mengurangi presisi tersebut menjadi, misalnya, 4-bit menjadi float.

Sekarang, harganya sedikit lebih masuk akal.

Kita berbicara tentang 14 GB dan 17 GB, bukan?

Model tersebut kini akan muat di perangkat seperti Mac dengan memori terpadu.

Tantangan dalam kuantisasi pasca-pelatihan normal adalah saat Anda mengompresi bobot tersebut, Anda akan kehilangan sedikit akurasi dalam model dari model dasar, dan kami memiliki teknik untuk mengatasinya.

Ini disebut pelatihan berbasis kuantisasi.

Dan yang terjadi saat kita melakukannya adalah saat model dilatih, model dilatih untuk mengetahui bahwa model akan berada pada ukuran yang lebih kecil ini, sehingga sebenarnya ada lebih sedikit kerugian dibandingkan dengan itu.

Jadi, kami mendapatkan pengurangan 75% dalam persyaratan RAM, dan sekarang model ini dapat muat di perangkat tersebut.

Dan kami melangkah lebih jauh.

Jadi, pendekatan kuantisasi seluler yang kami miliki dan berfungsi di banyak ponsel dapat memperkecil ukuran model tersebut lebih jauh dengan memahami cara kerja semua lapisan yang berbeda dan ukuran yang dapat digunakan.

Jadi, kita memiliki semacam paket kuantisasi campuran.

Jadi, kita beralih dari Gemma E2B 11,4 GB ke 1,1 GB.

Jadi, sekarang sebenarnya jauh lebih masuk akal di ponsel kelas menengah hingga kelas atas.

Berikutnya adalah kecepatan.

Jadi, saat menggunakan model autoregresif, seperti yang disebutkan Zoe, Anda memprediksi kumpulan token berikutnya.

Jadi, dalam tugas coding, Anda mungkin menemukan banyak token ini sebenarnya cukup dapat diprediksi, seperti akhir dari tanda tangan metode, atau tanda kurung buka atau tutup.

Jadi, Anda dapat menggunakan teknik yang disebut decoding spekulatif.

Hal ini akan menggunakan model drafter yang lebih kecil untuk memprediksi sejumlah token yang kemudian divalidasi oleh model yang lebih besar.

Alasan hal ini berfungsi dalam arsitektur Gemma 4 adalah karena keduanya menggunakan cache KV yang sama.

Jadi, anggap ini sebagai semacam memori jangka pendek model.

Jadi, yang akan terjadi adalah model drafter kecil akan memprediksi tiga atau empat token terlebih dahulu, dan model yang lebih besar kemudian akan melihat KV cache yang sama dan pada dasarnya akan memvalidasi output.

Hasilnya adalah peningkatan kecepatan sekitar 3x lipat dalam hal performa tanpa penurunan kualitas output model, karena model hanya memprediksi hal-hal, lalu memutuskan apakah hal tersebut lulus atau gagal, apakah hal tersebut benar atau tidak.

Jadi, sekali lagi, hal ini sedikit bergantung pada tugas yang Anda lakukan.

Jadi, hal ini tidak terlalu efektif untuk hal-hal seperti penulisan kreatif, karena ada lebih banyak variabilitas, tetapi sangat efektif untuk hal-hal yang dapat diprediksi seperti struktur JSON dan coding.

Jadi, bagaimana Anda akan mengevaluasi salah satu model ini?

Jadi, hal paling jelas yang mungkin Anda lakukan adalah melihat tolok ukur seperti, LiveCodeBench, atau MMLU, dan Anda melihat skornya.

Namun, hal itu hanya akan memberi Anda indikator tingkat tinggi tentang kemampuan model.

Yang benar-benar perlu Anda lakukan adalah mengevaluasi seluruh stack tempat aplikasi berjalan.

Jadi, ini adalah model yang Anda gunakan, bobot dan pendekatan kuantisasi, ini adalah inferensi runtime, jadi Anda mungkin menggunakan sesuatu seperti llama.cpp atau Ollama atau LiteRT, infrastruktur pengelola agen yang Anda gunakan, apakah itu seperti Pi atau OpenCode atau Antigravity, lalu jendela konteks, yang merupakan semacam ruang untuk semua data yang Anda inginkan agar dapat diproses oleh model Anda.

Dan kombinasi dari semua hal ini menghasilkan apakah hal itu layak atau tidak.

Jadi, sebagai contoh singkat, kami melakukan beberapa pengujian dengan Gemma 4 di Android Bench, dan kami menjalankan versi Ollama dengan konteks default 32k.

Dan yang kami temukan adalah dalam salah satu pengujian, saat mencari bug, pemadatan infrastruktur pengelola agen akan memindahkan file tersebut kehabisan memori, sehingga model tidak dapat menyelesaikan tugas, dan akan gagal.

Jadi, hanya dengan meningkatkan konteks dari 32k menjadi 256k, model kini dapat menyimpan informasi tersebut dalam memori, dan model dapat lulus pengujian tersebut.

Dan kami melihat rasio keberhasilan meningkat dua kali lipat pada tugas tertentu tersebut.

Jadi, hal ini menunjukkan bahwa satu faktor kecil pun dapat berdampak besar pada kesesuaian model ini.

Jadi, bagaimana cara melakukan evaluasi sendiri?

Jadi, berikut tiga saran singkat.

Jadi, salah satunya adalah Anda dapat mengambil histori Git, yaitu sekumpulan PR yang sudah berhasil, dan Anda dapat menggunakannya sebagai input perintah ke model dan melihat seberapa baik performanya pada PR tersebut.

Selanjutnya, Anda memerlukan sesuatu seperti penilai deterministik yang akan membantu Anda mengevaluasi apakah output model sudah benar atau belum.

Kami punya dua contoh yang sangat bagus untuk hal itu.

Kita sudah memiliki compiler dan pengujian unit.

Apa pun yang dihasilkan, Anda dapat menjalankannya melalui itu, dan itu akan memberi tahu Anda semacam lulus/gagal apakah Anda berhasil menyelesaikan tugas tertentu tersebut.

Lalu, yang ketiga adalah mencatat lintasan.

Jadi, saat menjalankan agen, Anda ingin dapat melacak berbagai perilaku yang dimiliki agen, melihat keberhasilan dan kegagalannya, dan Anda dapat menggunakannya untuk mengevaluasi seberapa baik model dapat berinteraksi dan menggunakan alat.

Dan saya ingin Anda mencoba mengubah cara Anda menyusun pertanyaan dari, "Apakah model ini secerdas model termutakhir yang besar ini?"

Menjadi, "Apakah tugas ini dapat dilakukan pada hardware ini dengan konfigurasi khusus ini?"

Untuk mengetahuinya, kami telah menciptakan framework yang disebut Sudah siapkah kita?

Atau AWTY.

Dan seluruh prinsip framework ini adalah untuk menilai semua tugas yang berbeda ini dalam hal kesiapan pada sumbu tersebut.

Jadi, model itu sendiri, mesin inferensi yang Anda gunakan, harness, lalu konfigurasi hardware.

Hal itu akan memberi tahu Anda apakah Anda sudah siap atau belum.

Jadi, misalnya, Anda mungkin melihat seberapa andal tugas tertentu tersebut.

Jika Anda menjalankannya, misalnya, 10 kali berturut-turut, apakah hasilnya selalu sama?

Anda mungkin melihat latensi.

Mungkin Anda memerlukan respons real-time.

Jadi, apa batas Anda untuk kecepatan melakukan tugas?

Kemudian, Anda mungkin akan melihat persyaratan RAM.

Jadi, bukan hanya, Anda tahu, RAM yang dimiliki perangkat, tetapi RAM yang dimiliki perangkat-- bagian yang dapat Anda ambil, dan aplikasi lain serta alat lain yang juga perlu Anda jalankan di hardware tersebut.

Jadi, apakah Anda dapat menggunakan 50% atau hanya dapat menggunakan 10% RAM?

Dan Anda akan mendapatkan skor kesiapan akhir ini.

Jadi, jika berwarna hijau, berarti konfigurasi tersebut sudah siap digunakan.

Jika berwarna oranye atau kuning dan atau merah, berarti Anda mungkin perlu mengubah sesuatu pada konfigurasi.

Mungkin Anda memerlukan akselerator yang lebih cepat untuk latensi yang lebih rendah, atau mungkin Anda memerlukan model yang lebih besar dan lebih mumpuni.

Jadi, sebaiknya Anda melihatnya.

Saat ini kami memiliki pratinjau dan ingin mendapatkan masukan Anda tentang seberapa berguna alat ini.

Jadi, Zoe akan membahas lebih lanjut cara kami menyiapkan beberapa evaluasi nanti, tetapi sekarang saya akan menyerahkan kepada Jose, yang akan menunjukkan cara yang sangat cepat untuk mulai menggunakan Gemma 4.

Terima kasih, Ian.

Jadi, cara tercepat untuk mencoba Gemma 4 saat ini mungkin melalui Android Studio.

Jadi, akan saya tunjukkan caranya.

Mari kita beralih ke laptop.

Itu dia.

Jadi, jika saya membuka halaman penyedia model di setelan dan memilih Gemma, Anda akan mendapatkan gambaran yang cukup jelas tentang seberapa besar setiap model.

Saya hanya perlu mendownload model ke hard drive saya.

Jadi, tindakan ini akan membuka atau memulai server llama.cpp, dan server tersebut dikonfigurasi dengan benar untuk Anda, sejak awal.

Namun, Anda juga dapat menggunakan server llama.cpp, Ollama, atau LM Studio Anda sendiri, apa pun yang Anda inginkan.

Untuk itu, Anda cukup membuka bagian ini, lalu menambahkan penyedia lokal.

Selain itu, penggunaan model kecil melalui penyedia jarak jauh juga sangat masuk akal.

Jadi, Anda dapat menambahkannya di sini, selama kompatibel dengan OpenAI atau Anthropic, Anda dapat terhubung ke sana.

Baiklah, mari kita lihat.

Jadi, sekarang, oh, omong-omong, jadi, cara Anda memilih model di Android Studio adalah melalui drop-down ini, tentu saja.

Jadi, saya telah memilih Gemma 4 26B, dan saya dapat bertanya, "Apa itu ViewModel?"

Oke.

Jadi, satu hal yang sangat penting untuk diingat adalah, setiap kali Anda mengubah model, seluruh percakapan akan dikirim lagi ke model baru dari awal.

Jadi, jika Anda membuat percakapan yang sangat panjang dengan sebuah model, dan Anda ingin beralih ke model baru, sebaiknya Anda memulai percakapan baru, atau meringkasnya, atau apa pun.

Sekarang, mari kita kembali ke slide dan Zoe untuk mempelajari berbagai alur kerja yang dapat Anda jalankan dengan model kecil.

Terima kasih banyak, Jose, dan terima kasih, Ian, atas ringkasan tentang model Gemma, dan apakah kita sudah sampai di sana atau belum.

Jadi, kita telah melihat jenis model yang ada, spesifikasinya, dan sekarang saatnya memahami beberapa jenis tugas yang dapat Anda berikan kepada model tersebut.

Jenis tugas pertama yang mungkin sudah Anda lakukan adalah, Anda tahu, alur kerja coding seperti proses debug, atau seperti pemecahan masalah, atau sesuatu yang, saya yakin, semua orang, atau, setidaknya, saya akan sangat sarkastis merindukan melakukannya secara manual, yaitu meningkatkan cakupan pengujian.

Iya, 'kan?

Jadi, ini adalah, Anda tahu, beberapa hal yang saya yakin sudah dilakukan semua orang, bahkan, mungkin, tanpa disadari.

Namun, saya ingin mendorong Anda, atau saya ingin mendorong Anda untuk berpikir lebih dari itu, bukan?

Jadi, mengingat model kecil dapat bersifat open-weight dan dijalankan secara lokal, apa yang dapat menghemat waktu Anda?

Iya, 'kan?

Kita sedang membahas tentang tidak menggunakan roket, jadi mengapa kita menggunakan otak untuk itu?

Jadi, jika kita bisa melampaui itu, apa saja yang bisa dilakukan model kecil?

Apa saja alur kerja yang dapat Anda gunakan untuk mempermudah hidup Anda dan memberi Anda lebih banyak kapasitas untuk melakukan hal-hal yang, Anda tahu, mungkin ingin Anda lakukan lebih banyak?

Jadi, misalnya, memastikan dokumentasi Anda selalu diperbarui dengan perubahan yang Anda buat, atau memastikan Anda memiliki pengujian regresi otomatis yang merupakan bagian dari hook pra-commit, atau bahkan memastikan bahwa konteks yang mungkin diterima agen Anda sebagai bagian dari alur kerja dioptimalkan untuknya, dan bekerja lebih cepat.

Jadi, ini adalah beberapa contohnya, bukan?

Pada akhirnya, tidak ada batasan kreativitas, atau arsitektur adalah batasnya, dan ada banyak hal yang dapat Anda pikirkan tentang cara menerapkannya.

Namun, setelah memiliki spesifikasi, alat, dan alur kerja, apakah Anda masih belum yakin harus mulai dari mana?

Nah, itulah gunanya tolok ukur.

Dan, seperti yang dikatakan Ian, leaderboard umum, terutama untuk Python, tidak akan memberi tahu Anda banyak hal tentang apakah model kecil akan berguna untuk alur kerja Android Anda.

Sama seperti bor drywall yang mungkin tidak memberi tahu Anda banyak hal tentang bor beton.

Namun, Anda harus berinvestasi dalam evaluasi Anda sendiri.

Anda harus berinvestasi dalam menguji arsitektur Anda sendiri, tetapi sebelum melakukannya, Anda mungkin tidak ingin menggunakan semua resource.

Proses ini memerlukan waktu, uang, dan upaya, sehingga melihat tolok ukur yang tersedia secara publik dapat memberi Anda gambaran dan daftar singkat sebelum Anda memutuskan untuk berinvestasi pada evaluasi Anda sendiri.

Ada tiga hal yang harus Anda perhatikan setiap kali mengevaluasi tolok ukur, bukan?

Ini agak meta, tetapi, pada dasarnya, hal pertama adalah, apa jenis tugas yang dilakukan model ini?

Seberapa spesifik konten tersebut.

Apakah tugas tersebut terlihat seperti jenis tugas yang akan Anda berikan?

Hal kedua adalah cakupan tugas.

Jadi, apakah itu menulis dokumentasi, menyelesaikan PR, atau sesuatu yang terlihat seperti jenis pekerjaan yang Anda miliki?

Terakhir, apakah kompleksitas sistem tersebut mirip dengan kompleksitas yang akan Anda berikan?

Di sinilah kita dapat melihat mengapa benchmark Python tidak akan terlalu representatif untuk Android.

Itulah alasan kami membangun Android Bench, yang merupakan tolok ukur yang mencakup ekosistem Android dan pekerjaan Android.

Versi pertama memiliki 100 tugas Android berukuran PR, dan Anda dapat menjalankannya sendiri sekarang melalui Harbor untuk memeriksa kombinasi agen, model, dan keterampilan apa pun.

Kami meluncurkan 2.0 dengan tugas jangka panjang yang lebih kompleks untuk memahami kemampuan model termutakhir dalam mengerjakan tugas seperti yang Anda berikan saat ini.

Jadi, sekarang saya akan menyerahkan kepada Jose untuk menunjukkan hasil yang kami dapatkan melalui ini dan beberapa cara untuk mengoptimalkan penggunaan model kecil.

Oke, terima kasih, Zoe.

Baiklah, mari kita lihat tugas yang dapat diselesaikan oleh model kecil dan di mana model tersebut mulai mengalami kesulitan.

Mari kita tentukan empat kategori tugas secara acak: kecil, sedang, besar, dan jangka panjang.

Tugas jangka panjang adalah tugas yang mungkin memerlukan waktu berhari-hari atau berminggu-minggu untuk diselesaikan oleh manusia.

Misalnya, migrasi, refaktorisasi besar, dan bocoran, Anda tidak dapat melakukannya dengan model kecil.

Setidaknya dalam sekali jalan.

Kita akan membahasnya nanti.

Oke, tugas-tugas kecil.

Pekerjaan ini memerlukan pembacaan dan penulisan mungkin satu atau dua file, dan tidak memerlukan banyak pengetahuan.

Misalnya, model kecil cukup bagus dalam Compose, setidaknya dasar-dasar Compose.

Jadi, hal-hal seperti harus ada 8 dp di antara elemen, atau menggunakan tema, bukan warna hardcode, atau mengekstrak string.

Hal tersebut sangat mudah bagi model kecil.

Namun, tugas ini membahas topik yang lebih lanjut, tetapi tugasnya masih mudah.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

Kesulitan dalam kasus ini adalah tentang cakupan, bukan tentang pengetahuan.

Jadi, perintah tersebut sebenarnya memberi tahu kita composable mana yang harus dioptimalkan dan apa masalahnya: composable tersebut melakukan rekomposisi pada setiap frame.

Jadi, hal ini membuat tugasnya cukup mudah bahkan untuk model kecil, seperti Gemma 4.

Dalam kasus ini, prosesnya memerlukan waktu 3 menit, dan hanya memerlukan perubahan satu baris.

Oke.

Jadi, saya rasa kita sudah memiliki gambaran yang cukup jelas tentang apa itu model kecil.

Mari kita lihat apa itu tugas kecil.

Mari kita lihat tugas sedang.

Model kecil seharusnya dapat melakukan sebagian besar tugas tersebut.

Dalam tugas ini, dari aplikasi Pocket Casts, agen pengguna tidak ada dalam permintaan, dan ada juga error dalam logika percobaan ulang.

Jadi, yang satu ini sedikit lebih sulit karena pertama-tama kita meminta dua hal sekaligus, dan tidak ada petunjuk tentang di mana hal-hal ini berada dalam code base.

Namun, hal itu sudah berlalu.

Proses ini memerlukan waktu 10 menit.

Perintah ini mengubah tiga file.

Dan, omong-omong, biayanya 6 sen melalui OpenRouter.

Sekarang, mari kita lihat tugas yang gagal dari set data yang sama.

Ini adalah contoh Now in Android dengan laporan atau perintah yang cukup komprehensif, tetapi tidak menyebutkan nama class atau file, sehingga agen perlu melakukan lebih banyak upaya untuk memahami arsitektur aplikasi, lapisan data, mekanisme sinkronisasi, dan dalam hal ini, dll. Jadi, dalam proses khusus ini, agen gagal.

Semuanya diimplementasikan hampir dengan benar, tetapi hanya mengasumsikan bahwa nilai sinkronisasi awal adalah -1, padahal sebenarnya 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

Selesai.

Bug ini akan terdeteksi jika agen menjalankan pengujian unit, yaitu pengujian unit yang ada.

Jadi, hal ini menunjukkan bagaimana model yang lebih kecil, secara umum, cenderung berhenti sedikit lebih awal daripada model frontier.

Kami hanya meminta agen untuk memperbaiki masalah, bukan memverifikasinya.

Jadi, mungkin kita harus mengubah tugas tersebut agar berisi langkah verifikasi.

Kita juga akan membahasnya sebentar lagi.

Jadi, mari kita bahas tugas besar.

Sekitar setengah dari tugas besar, dalam definisi ini, selalu lulus.

Beberapa yang gagal sebenarnya terlalu panjang dan kompleks untuk model kecil, tidak banyak yang bisa dilakukan di sana.

Namun, ada beberapa yang ketika Anda melihat apa yang sebenarnya terjadi, Anda menyadari bahwa model tersebut sudah 90 atau 90 persen benar.

Jadi, mari kita pilih salah satunya.

Saya memilih yang ini karena teksturnya renyah.

Pengujian ini lulus sekitar separuh waktu pengujian dijalankan.

Jadi, kami menganggap ini sebagai batas kemampuan model kecil.

Atau, setidaknya, model dari bulan April.

Ini tentang mengurai URL yang salah format di library Coil.

Seperti yang Anda lihat, deskripsi PR cukup komprehensif, yang merupakan hal bagus, tetapi ada satu persyaratan yang terlewat.

Jadi, mari kita lihat sekilas.

Semua pengujian memeriksa encoding dan error URL umum, tetapi hanya beberapa, setengahnya, yang menambahkan pengujian untuk karakter yang dienkode dengan buruk, sehingga kasus pengujian tersebut ada di sana.

Yang tidak lulus evaluasi.

Jadi, semua eksekusi hampir sempurna, tetapi ini menunjukkan sekali lagi bahwa model kecil tidak selalu melakukan langkah ekstra.

Model ini mengikuti petunjuk, tetapi tidak mencoba membuat Anda terkesan seperti model termutakhir.

Anda tahu cara menetapkan upaya dalam agen saat ini?

Pertimbangkan bahwa nilai ini ditetapkan terlalu rendah saat Anda menggunakan model kecil.

Jadi, mari kita definisikan tugas besar sebagai tugas yang mungkin diselesaikan oleh model kecil sekitar 50% dari waktu, yang dapat dicapai Gemma 4 31B terhadap set data Android Bench v1, yang telah dibahas Zoe sebelumnya.

Jadi, sebelum membahas tugas jangka panjang, apakah ada yang bisa kita lakukan untuk membantu model kecil dalam tugas tersebut?

Tentu saja, dan hal-hal ini sama sekali tidak memerlukan upaya apa pun.

Pertama, jika Anda menggunakan model seperti Gemma 4 secara lokal seperti yang disebutkan Ian, pastikan model tersebut dikonfigurasi dengan benar.

Misalnya, jika Anda menggunakan Ollama untuk menyajikan Gemma 4, jendela konteks defaultnya adalah 32.000 token, padahal sebenarnya mendukung delapan kali lebih banyak.

Tentu saja, jika Anda menggunakan Gemma 4 melalui Android Studio, Anda tidak perlu mengonfigurasinya.

Alat ini dikonfigurasi dengan benar secara default.

Dalam kumpulan evaluasi kami, mengaktifkan konteks lengkap membuat hasil meningkat dari 26% menjadi 53%.

Selanjutnya, gunakan Android CLI, alat CLI Android, terutama untuk menelusuri dokumentasi.

Hal ini tidak selalu berlaku, karena model cukup baik dalam hal dasar-dasar, tetapi setiap kali Anda menggunakan API baru atau khusus, memiliki dokumentasi adalah kuncinya.

Menurut pengalaman kami, ini jauh lebih baik daripada menggunakan alat penelusuran web.

Selanjutnya, tambahkan petunjuk verifikasi.

We talked about this.

Beri tahu model cara menjalankan pengujian, jenis pengujian yang tersedia, cara mengelola emulator, dll. Anda dapat melakukannya dalam file AGENTS.md, yang akan membuat petunjuk tersedia untuk semua agen, tetapi, maksud saya, itu adalah hal yang baik.

Anda harus memilikinya.

Namun, perhatikan juga file AGENTS.md yang sangat panjang, karena jika Anda mencoba berbagai agen, Anda akan melihat bahwa beberapa di antaranya memiliki perintah sistem dan deskripsi alat yang sangat besar, dan tampaknya menurunkan performa model kecil.

Kami sebenarnya mencoba menjalankan benchmark ini dengan OpenCode, dan performanya jauh lebih rendah daripada pi, mungkin karena menggunakan deskripsi alat dan perintah sistem yang lebih besar.

Selanjutnya, tambahkan keterampilan, tetapi juga hapus keterampilan.

Model kecil mungkin memerlukan dorongan saat menggunakan API baru dan khusus, tetapi sebaiknya jangan mengisi konteksnya dengan keterampilan Compose umum, misalnya.

Jadi, bagaimana dengan tugas jangka panjang?

Tugas-tugas ini mencakup puluhan file, memerlukan keputusan arsitektur yang serius, dan biasanya ditangani oleh model penalaran yang membuat rencana dan memulai sekelompok sub-agen yang menjalankan berbagai tugas.

Contoh tugas jangka panjang adalah memigrasikan seluruh aplikasi dari XML ke Compose, membuat aplikasi kompleks dari awal, atau mengonversi aplikasi lintas platform ke Android native.

Jika kita melihat hasil dari Android Bench V2, yang berfokus secara eksklusif pada jangka panjang, kita melihat bahwa model termutakhir mendapatkan skor 3 hingga 40%.

Jadi, untuk model kecil, sepertinya aman untuk mengatakan bahwa hal ini di luar kemampuan mereka.

Namun, mengarahkan analisis awal melalui model termutakhir, lalu mengalirkan tugas yang lebih sederhana ke model yang lebih kecil akan jauh lebih efisien dalam penggunaan token dan kredit.

Mari kita lihat cara melakukannya.

Kembali ke Zoe.

Terima kasih banyak, Jose.

Kita akan membahas cascade, tetapi sebelum saya menunjukkan beberapa cara, atau sebelum kita membahasnya secara mendalam, saya ingin mundur selangkah dan menunjukkan cara lain yang dapat membantu Anda dalam mengorkestrasi berbagai model.

Jadi, misalnya, orkestrasi dapat membantu Anda agar tidak pernah diblokir, bukan?

Jadi, baik saat Anda melihat penyedia mengalami gangguan, atau saat Anda mencapai batas kapasitas API, atau saat Anda berada di pesawat atau kereta, seperti yang dikatakan Ian, Anda dapat menyiapkan model penggantian dan membuatnya sedemikian rupa sehingga baik saat online maupun lokal, Anda dapat terus melanjutkan jika terjadi sesuatu.

Hal lain yang dapat Anda lakukan melalui orkestrasi adalah mendapatkan jawaban yang lebih baik.

Misalnya, Anda dapat meminta model kecil bekerja sendiri dan memanggil penasihat setiap kali memerlukan sedikit dukungan, bukan, untuk mendapatkan bantuan tersebut.

Anda juga dapat menyiapkan dewan yang berisi berbagai jenis model, atau model yang berbeda, yang semuanya menjalankan tugas yang sama sekaligus, lalu Anda dapat mengevaluasi berbagai respons dan pengaruh bobot serta bias setiap model terhadap hasilnya.

Anda juga dapat menggunakan model terpisah sebagai, katakanlah, pengujian.

Jadi, ini seperti ulasan sejawat.

Dan Anda bisa melihatnya melalui ini.

Namun, tentu saja, pada akhirnya, orkestrasi dapat membantu Anda menghemat biaya melalui sesuatu seperti cascade tersebut.

Pada dasarnya, Anda dapat menyiapkannya secara manual, sehingga Anda dapat menetapkan satu model untuk perencanaan, model yang berbeda untuk eksekusi, dan model lainnya untuk pengujian.

Ada beberapa cara untuk melakukannya, baik di cloud atau Anda dapat menyiapkan proxy LiteLLM untuk melakukannya secara lokal.

Atau, Anda dapat menggunakan pengklasifikasi untuk merutekannya secara otomatis ke jenis model yang tepat berdasarkan permintaan, yang merupakan ide proxy yang disebutkan Ian, tetapi otomatis.

Jadi, mari kita akhiri dengan kembali ke pertanyaan yang diajukan Jose di awal pembicaraan, yaitu, apa perbedaan kualitas dan akurasi antara model kecil dan model termutakhir?

Dan jawabannya, seperti banyak hal dalam ilmu komputer, adalah tergantung.

Namun, ini adalah sesuatu yang ingin saya sampaikan kepada Anda, bahwa ini adalah sesuatu yang dapat Anda rekayasa.

Ini adalah sesuatu yang dapat Anda ubah, bergantung pada cara Anda menyiapkannya dan cara Anda bermain dengan bidak-bidaknya.

Jadi, bagian pertama di sini adalah, memilih alat yang tepat, bukan?

Ada beberapa jenis alat.

Kenali dan jelajahi, bukan?

Lalu, cari tahu pekerjaan apa yang cocok untuk mereka atau bahkan pekerjaan apa yang bisa mereka lakukan.

Kedua, pastikan untuk menyesuaikan cakupan yang diperoleh model untuk melakukan tugasnya.

Jadi, misalnya, hal-hal seperti petunjuk untuk tugas, hal-hal seperti memberikan konteks yang tepat untuk tugas dan hanya konteks yang tepat untuk tugas, serta cara untuk memeriksa pekerjaannya sendiri.

Kemudian, tentu saja, Anda perlu menyiapkan-- menguji seluruh penyiapan dan bukan hanya model secara terpisah, karena hal ini akan membuat perbedaan dan mungkin hasil yang Anda dapatkan dapat disesuaikan jika Anda menyiapkannya dengan, katakanlah, konfigurasi elemen yang berbeda.

Pada akhirnya, Anda perlu menyiapkan atau membuat evaluasi sendiri.

Terakhir, Anda dapat mengorkestrasi sepeda dan roket sehingga Anda tidak perlu memilih salah satunya dan dapat membelanjakan anggaran secara efektif dengan cara ini.

Namun yang terpenting, Anda dapat terus bereksplorasi, terus membangun, dan terus bersenang-senang, bukan?

Anda dapat memulainya sekarang dengan menyiapkan daftar model melalui Android Bench dan temuan yang Anda miliki di sana, atau memulai dengan Gemma 4 di Android Studio sekarang.

Jadi, terima kasih banyak.