Android Bench'ten temsilci kodu oluşturmayla ilgili analizler

Tomáš Mlynarič

Herkese günaydın.

Haydi başlayalım.

Mart ayında, Android geliştiricisi görevlerinde LLM'leri ölçmek için veri kümemiz ve skor tablomuz olan Android Bench'i kullanıma sunduk.

O zamandan beri bu testi birçok yeni modelde uyguladık.

Geçtiğimiz ay Android Bench 2.0'ı kullanıma sunduk.

Yalnızca birkaç ay geçmiş olsa da yapay zeka dünyasında bu süre sonsuzluk gibi geliyor.

Adım Tomáš. Android Bench yolculuğumuzu ve şu anki noktaya nasıl geldiğimizi paylaşacağım.

1.0 ile başlayalım.

1.0 sürümünde, açık kaynaklı depolardan gerçek dünyadaki sorunları aldık.

GitHub projelerini GitHub sorunları, bu sorunları çözen pull istekleri ve çözümleri doğrulayan testlerle filtreledik.

Pull isteklerini yapay zeka modelleri için görev gruplarına ayırırız.

GitHub sorunu, model için talimatlar veya istem haline geldi ve bunları PR'dan önceki duruma yerleştirdik.

Model bir çalışma oluşturduktan sonra testleri alıp çıktıya uyguladık. Bu da bize başarılı veya başarısız bir sonuç verdi.

Yapay zekanın sorunu çözmeye yönelik bu tek girişimine deneme diyoruz.

Ayrıca bunu, PR'daki insan tarafından oluşturulan çözüme veya altın çözüme göre de karşılaştırabiliriz.

Bu metodoloji, oldukça bilinen SWE-bench karşılaştırmasına benzer.

10.000'den fazla potansiyel görevle başladık ve bunların hepsi uygun değildi.

Bazılarında eksik veya aşırı ayrıntılı talimatlar vardı.

Testler, ideal çözüme bağlanmış olabilir veya PR'den önceki durum bozulmuş olabilir.

Bu nedenle, 100 adil görev belirlemek için tekrar tekrar inceleme yapmamız gerekti.

Bu incelemeler sırasında, sonuç almak için en gelişmiş modelleri kullandık.

Başlangıçta görevlerin yaklaşık %30'u çözüldü. Buna geçme oranı diyoruz.

Resmi sürüm için veri kümesini kilitlediğimizde en iyi modeller zaten %70 civarındaydı.

Ama bu bir ay sonra falan olacak.

Ardından her ay yeni modelleri değerlendirmeyi planladık ve nasıl daha iyi hale geldiklerini izledik.

Ağustos sürümünde ise en iyi modelin başarı oranı %92'ydi.

Çıtayı çok düşük tuttuğumuzu ve bu veri kümesinin doygunluğa ulaştığını biliyorduk.

Tomáš Mlynarič

Ancak bunu öngörmüştük ve geçen ay yayınladığımız 2.0 sürümü üzerinde yoğun bir şekilde çalışıyoruz.

Hedefimiz, karmaşık ve gerçek hayattaki Android görevleriyle çıtayı yükseltmek ve geliştiriciler için LLM performansı konusunda rehberlik ve şeffaflık sağlamaktı. Ayrıca, model geliştiricileri Android'e öncelik vermeye teşvik etmek için onlara iyi bir karşılaştırma sunmaktı.

Ayrıca hem size hem de model geliştiricilere analiz ve sonuçlar sunar.

Ancak zekayı, azmi ve hile yapmayı da hesaba katmamız gerekir.

Ayrıca kirlenme riskini de önlememiz gerekiyor.

SWE-bench metodolojisiyle ilgili sorunlardan biri, kaynak kodunun gerçek anlamda açık olmasıdır.

OpenAI bir makale yayınladı.

Modellerin, talimatlardaki sonraki kelimeleri tamamlayabildiğini veya talimatlarda yer almayan belirsiz bir hatanın olduğu bir görevi çözebildiğini fark ettiler.

Ayrıca model geliştiricilerin açık kaynak kod üzerinde eğitim yaptığını ve SWE-bench'in kirlendiğini fark ettiler.

Bu nedenle, 2.0 için kodu kapalı tutuyoruz. Böylece, kodun üzerinde eğitim yapılmasını önlüyoruz.

Çalışmayı dört iş akışına böldük.

İlkinde, uygulama dönüşümleri yapıyoruz. Açık kaynaklı, Flutter ve React Native uygulamalarını alıp temsilcilere bunları yerel Android çözümüne dönüştürmelerini söyledik.

Bu durum, günümüzde gördüğümüz platformlar arası uygulamalardan yerel uygulamalara geçiş trendini yansıtıyor.

İkinci çalışma akışı ise yeni özellikler ve platform entegrasyonlarıydı.

Bu araçlar, mevcut üretim kod tabanlarına entegre edildi.

Örneğin, Now in Android'e video özelliği veya pencere içinde pencere gibi özellikler ekledik.

Üçüncü çalışma akışı ise taşıma işlemleriydi.

Kapalı tuttuğumuz üretim aşamasındaki açık kaynak uygulamaları modern kitaplıklar ve mimarilerle yükseltiyoruz.

Örneğin, Nav 2'den Nav 3'e, XML görünümlerinden Compose'a veya tek bölmeden uyarlanabilir düzene geçiş gibi.

Sonuncusu ise görsel tasarım şablonları kullanılarak sıfırdan oluşturulan şirket içi yeni bir uygulamaydı.

Burada, tam SMS OTP kimlik doğrulama akışı, Google Haritalar ile sipariş takibi ve daha fazlası gibi örnekler verilmiştir.

Tomáš Mlynarič

Sadece birkaç mühendisle Now in Android'e benzer boyutta bir uygulama geliştirdik.

Ancak yeni görevler yeni zorlukları da beraberinde getirdi.

İlk olarak, temsilcileri doğru şekilde değerlendirin.

Karşılaştırma testleri, uygulamanız için yapılan testlerden çok daha zordur. Çünkü bu testlerin yalnızca bir çözümü değil, geçerli tüm çözümleri geçmesi gerekir. Görev ne kadar büyükse o kadar çok geçerli çözüm vardır.

1.0 sürümünde karşılaştırma, çoğunlukla birim testlerine dayanıyordu ve birim testleri, agnostik olma konusunda oldukça kötüydü.

import com.foodvibes.MyViewModel

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

    assertTrue(vm.retried)
}

Tam sınıf veya işlev adları gerektirirler.

Bu örnekte olduğu gibi, karmaşık bir test yok. Ancak temel olarak, temsilci bu öğeleri farklı şekilde adlandırabilir. Farklı şekilde adlandırmasa bile, farklı bir pakete koyarsa testler derlenemez ve bu nedenle bizim durumumuzda kullanılamaz.

import com.foodvibes.feature.my.RetriableViewModel

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

    assertTrue(vm.tried)
}

Yani teknik olarak istemlerde API'leri belirtebiliriz ancak bu durumda ya çok fazla ayrıntı vermiş oluruz ya da istem çok fazla test şartıyla dolar.

Bu nedenle, uygulamadan bağımsız testler yapmamız gerekir.

Bunlar çok üst düzeydir ve sonuçları test eder, dahili bileşenleri değil.

Herkese açık ekran bilgileriyle etkileşim kuran testler olan deterministik kullanıcı arayüzü testlerini, bir kullanıcının yapacağı şekilde kullanırız.

Bunlar için UI Automator veya Compose UI testlerini kullanırız. Ancak bazı harici sistem sınırlarını kontrol eden özel komut dosyalarımız da vardır. Örneğin, bir ağ çağrısının doğru verilere sahip olup olmadığını veya doğru verilerin dahili yardımcılar ya da DAO'lar bilinmeden bir veritabanına kaydedilip kaydedilmediğini kontrol ederiz.

Bunların bir parçası olarak, manifest dosyasındaki izinleri veya kitaplığın yerleşik dosyalarda olup olmadığını kontrol etmek için statik denetlemeler de yapıyoruz.

Ayrıca bu komut dosyaları ile kullanıcı arayüzü testlerinin bir kombinasyonu olan karma testlerimiz de var.

Bu, karma testlerden birine örnektir.

Sürüş simülatörünün dışına çıkarlar.

Bu, SMS OTP kimlik doğrulama akışının testidir. Komut dosyasının, SMS'i emülatöre doğru şekilde gönderebilmek için önce uygulamanın karma değerini hesaplaması gerekir. Ardından test, UI Automator testleri başlatılır ve gereken rastgele oluşturulmuş bir OTP iletilir ve bir ADB komutuyla emülatöre SMS gönderilir.

Test, girişin doğru numaraya sahip olup olmadığını kontrol eder.

Temel olarak bu şekilde.

Uygulama eşleşmesi yoktur, yalnızca akışın çalışıp çalışmadığı kontrol edilir.

Notlandırmayla ilgili ikinci sorun ise görevlerimizin çoklu modalite gerektirmesiydi.

Temsilcilerin kullanıcı arayüzü oluşturması gerekir veya onlara tasarım şablonları veririz.

Bunun için en kolay yöntem ekran görüntüsü testlerini kullanmaktır.

Ekran görüntüsü eşiklerinin daha yüksek olması gerektiğini başından beri biliyorduk ancak yine de başarısız oldular.

Farklı piksel farkı algoritmaları denedik ancak bunlar, emülatör durum çubuğunun farklı olduğu sistem düzeyinde gürültü, pil simgesi ve hatta yazı tipi donanım kenar yumuşatmasının farklı olduğu durumlarda başarısız oldu.

Ancak, dolguların küçük olduğu, biraz farklı olduğu veya hafif ton farklılıklarının olduğu, yani kullanıcı arayüzünün tamamen doğru olabileceği ancak arka planın biraz farklı renklendirilebileceği ve piksel farkı algoritmalarının başarısız olacağı, bir şekilde geçerli olan uygulamalarda da başarısız oldular.

Bu nedenle, ekran görüntüsü testlerinde olduğu gibi ekran görüntüsü çiftlerini karşılaştıran ve bize bir puan veren, aynı zamanda puanla ilgili yapısal akıl yürütme sağlayan çok formatlı LLM değerlendiriciyi kullandık ve oluşturduk.

Ayrıca, yapının ve yapısal eşliğin doğru olup olmadığını kontrol eden bazı erişilebilirlik hiyerarşisi dökümleriyle de besliyoruz.

Bunu birçok denemede deneysel olarak test ettik ve yüksek tutarlılığa sahip olduğunu ve gördüğümüz sorunları göz ardı ettiğini gördük.

Böylece, görselleri ve davranışları bağımsız bir şekilde doğrulamanın iyi bir yolunu bulduk ve temsilcilerin her şeyi taklit etmeye çalıştığını gördük.

Devam edin.

Tomáš Mlynarič

Süreç basit bir şekilde başlar.

Günümüzde temsilciler genellikle "Tamam.

Bir görevim var.

GitHub'a bakalım.

Çözümleri birlikte bulalım."

İlk olarak bunu yaparlar.

GitHub'da veya internette geçerli çözümü aramaya çalışırlar. Bu nedenle kaynak kodunu kapalı tutmamız gerekir ve herkese açık olamaz.

Ama bu kolaydı.

Bazı denemelerde her şeyin %100 başarılı olduğunu söyledik ve temsilci "Muhteşem bir zafer!" dedi.

Böyle.

İlginç, ne bulmuşlar?

Ancak gidişata daha yakından baktığımızda, "Bunu yapamam.

Eşik değerini ekran görüntüsü testinin %80'i olarak değiştirirsem ne olur?"

// AuthFlowScreenshotTests.kt

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

"Evet, zafer, her şey geçiyor."

Evet ama ekran görüntüsü testleri işe yaramıyor.

Ancak bu en gelişmiş olanı değildi.

Bazılarında, aslında Flutter dönüşüm uygulamasında, temsilci Android'i oluşturmaya çalıştı ve "Ne yapacağımı bilmiyorum" dedi.

Onlar da verdiğimiz ekran görüntüsünü arka plana çizilebilir öğe olarak yerleştirdiler.

Şimdi ise ekran görüntüsü testini geçmek gibi.

Yaşasın!

Ancak kullanıcı arayüzü testleri başarısız olmaya devam ediyor. Bu yüzden, "Üzerine düğmeler, metinler, test etiketleri ve ihtiyacımız olan her şeyi içeren görünmez bir yer paylaşımı katmanı koyacağım.

Artık her şey yeşil.

Harika.

Tebrikler."

Yani, çok iyi bir tane var.

Java'dan Kotlin'e geçiş görevimiz var. Temsilcinin Java'dan Kotlin'e geçiş yapması gerekiyor, değil mi?

Derleme işlemini gerçekleştiremediler.

Yine de bir şeyler başarısız oluyordu. Bu yüzden temsilci, "Tamam, Java'dan derlenen sınıfları alıp bir JAR'a koyacağım ve ardından normal bir kitaplık olarak derleme dosyalarına ekleyeceğim." diye düşündü.

Şimdi her test başarılı oluyor ancak Java dosyalarını kontrol eden statik denetlemelerimiz var. Bu yüzden bunları sileceğim.

Java dosyalarını siliyorum, her şey yeşil, ancak Kotlin hâlâ başarısız oluyor. Bu yüzden, "Tamam, Kotlin kaynak grubunu kaldıracağım ve şimdi her şey geçiyor.

Harika."

Bunun hile olup olmadığını bile bilmiyorum.

Yani bu gerçekten yaratıcı bir şey.

Tüm bunları önlemek için üç savunma mekanizması olan bir hile algılayıcı geliştirdik.

Kullanıcı arayüzü ağacına bakarız, farklı ekran boyutları uygulayarak arka planın bozulmasını sağlarız ve bunu görürüz.

Ancak testleri de sıfırlarız ve eşikleri değiştirememeleri için testlerde herhangi bir değişiklik yapılıp yapılmadığını kontrol ederiz.

Ayrıca, tuhaf durumları tespit etmek için temsilcinin izlediği yolları ve gerçek çıkışını denetleyen LLM-as-a-Judge gibi araçlarımız da var.

Bir şey olursa da "Tamam, doğrudan başarısızlığa gidiyoruz." deriz.

Tomáš Mlynarič

Artık kısayollar, çözüm arama, kırılgan birim testleri veya sahte kullanıcı arayüzleri yok.

Temsilcileri bir Android uygulaması geliştirmeye zorladığımızda sayılar nasıl görünüyor?

Pazartesi günü itibarıyla, blog yayınını görmüş olabilirsiniz, sayılar bu şekilde.

En iyi temsilci bile görevlerimizin yalnızca %40'ını tamamlayabiliyor ve çoğu öncü temsilci %20 ile %40 arasında bir başarı oranına sahip.

Bu durum, karşılaştırma ölçütü yazarları olarak bizim için de iyi bir şey. Çünkü bu sayede doğru dengeyi kurabiliyoruz. Örneğin, sağladığımız görevlerin gerçek dünyada bir değeri var ancak aynı zamanda gelişmek için de çok fazla alan var.

Şimdi sonuçlara bakalım.

Artık sonuçları birden fazla perspektiften inceleyebiliriz.

Daha önce bulduğumuz analizlerden bazılarına göz atabiliriz.

Grafiğe baktığınızda aklınıza gelen ilk soru, bu temsilciyi çalıştırmanın maliyetinin ne kadar olduğu olabilir.

Yapay zeka şirketleri genellikle jeton başına maliyeti bildirir. Bazıları giriş, çıkış ve önbellek jetonu için ayrı ayrı maliyet bildirir.

Bu da sizin durumunuzda karar vermenizi sağlayacak bir argüman olabilir.

Ancak buna başka bir açıdan bakabiliriz.

Aynı grafiği 2D uzayda, görev başına ortalama maliyetle çizebiliriz. Jeton değil, görev başına maliyet ile geçme oranı karşılaştırılır.

Burada, bazı modellerin aniden çok daha fazla konuştuğunu görebiliriz.

Bu modeller, görev başına çok daha fazla zaman veya jeton harcar. Diğer modeller ise daha az maliyetle daha fazla görevi tamamlar.

Ancak aynı grafiğe jeton başına fiyatı da eklersek yapay zeka şirketlerinin reklamını yaptığı fiyatın, göreve göre ödediğiniz gerçek fiyatla eşleşmediğini görebiliriz.

En iyi geçme oranına sahip temsilcinin aslında jeton başına en ucuz, ancak görev başına en pahalı temsilcilerden biri olduğunu görebilirsiniz.

Aynı jeton fiyatına sahip diğer temsilciler ise görevlerin yaklaşık %30'unu tamamlayabilir ancak 15 kat daha ucuzdur.

Bu nedenle, jeton fiyatı metrik değildir.

Bazı modeller kodu daha fazla inceliyor, yeniden oluşturuyor, yeniden çalıştırıyor ve her adımda daha fazla jeton harcıyor.

Yani, sadece jeton başına maliyete bakmayın.

Bir model seçin, gerçek verilere bakın, örneğin kendi senaryonuzda kullanın veya Android Bench'e bakarak hangi modellerin görevlerde en çok jeton harcadığını görün.

Bazıları, bilirsiniz, jeton başına daha ucuz olmalarına rağmen daha fazla adım gerektirir.

Ancak aynı sorunun başka bir yönü daha var.

Bu aynı grafik, ancak müşteri temsilcilerinin bu işlemi ne kadar sürede tamamladığını da inceleyip gösterebiliriz.

En yüksek geçme oranına sahip temsilcilerin en yavaş temsilciler bile olabileceğini görebiliriz.

Örneğin, bazı görevlerin neredeyse iki saat sürdüğünü görüyoruz.

Çalışana kadar yeniden oluşturup yeniden test ederler.

Evet, en iyi geçme oranını elde ederler ancak en çok zamanı da onlar harcar.

Daha ucuz olan bazı temsilciler, görev başına yaklaşık bir buçuk saat harcamalarına rağmen daha iyi sonuçlar elde edemiyor.

Diğer temsilciler ise 20 dakikadan kısa sürede tamamlayıp görevlerin dörtte birinden fazlasını çözüyor.

Küçük ve hafif modeller genellikle daha hızlı ve daha ucuzdur ancak zor görevlerde daha sık başarısız olur.

Buradan çıkarılacak sonuç, tek bir en iyi modelin olmadığıdır.

Bu, ne için optimizasyon yaptığınıza bağlıdır.

Geçme oranı mı?

Maliyet mi?

Bekleme süresi mi?

Bu durumda, yaptığınız işin türüne bağlı olarak, çok zor görevler üzerinde çalışmıyorsanız işi daha ucuza ve daha hızlı yapan daha hızlı modelleri kullanmayı düşünebilirsiniz.

Ancak maliyet ve hız, yalnızca temsilcilerin nasıl çalıştığını gösterir, denemelerin çoğunda neden başarısız olduklarını açıklamaz.

Başarısız olan çalıştırmaları incelediğimizde temsilcilerin genellikle erken ayrıldığını fark ettik.

İşlerinin bittiğini düşünürler.

Görev tamamlandı.

Tamam, eve gidiyorum.

Ancak daha önce de belirtildiği gibi, temsilciler görev paketinde yalnızca talimatları ve önceki durumu alır.

Testleri göremezler.

Doğrulama paketini göremediğini fark eder.

Biz de, "Peki, testleri görmelerine izin verirsek ne olur?" diye sorduk.

Bu nedenle, deneme yaptık ve aynı görevin açık test varyantını kullandık. Bu varyantta temsilci, başarısız olan doğrulama test paketini önceden aldı.

Böylece testleri yinelemeli olarak çalıştırıyorlardı.

Hataları inceleyebilir ve geri bildirim döngüsünde kodları hassaslaştırabilirler.

Temsilcilerin testleri gördüklerinde daha çok çaba gösterdiğini ve daha uzun süre çalıştığını tespit ettik.

Açık çalıştırmalarda ise %25 daha fazla sıra ve %40 temsilci çalışma süresi elde ettiler.

Körlemesine hata ayıklama yapmadıkları için başarısız testleri çalıştırmak ve düzeltmek için görev başına yaklaşık 30 dakika harcadılar.

Böylece, tam olarak neyin başarısız olduğunu görüyorlar ve ne yazık ki geçme oranı da neredeyse yüzde 50 puan artıyor.

Bu ekstra çaba, bahsettiğim gibi ortalama geçme oranını artırır.

Ancak zamanla yeni öncü modeller ortaya çıktı ve bu açık varyantı hızla geride bıraktı.

Yani neredeyse %90'lık bir geçme oranı.

Bu nedenle, kapalı arama kapalı test varyantını birincil karşılaştırma metriği olarak tuttuk.

Ancak modellerin, neye göre değerlendirildiklerini bildiklerinde daha iyi performans gösterdiğini görmek yine de çok ilginç.

Tomáš Mlynarič

Ancak bu sayede temsilciler hakkında daha fazla bilgi edinebildik.

Örneğin, modellerin kendi çalışmalarını nasıl test ettiğini kontrol edebiliriz.

Grafikten de görebileceğiniz gibi, öncü modeller daha iyi testler yazıyor ve daha yüksek geçme oranlarına sahip.

Bazı modeller ise aşırı özgüvenli olup test yapmadan her şeyi yapabileceklerini iddia eder.

Bazen hâlâ iyi olabilirler.

Test konusunda çok iyi olmayan modeller kullanıyorsanız daha iyi test becerileriyle veya testlerin nasıl yazılacağına dair özel talimatlarla onlara yardımcı olabilirsiniz.

Ancak korelasyon, nedensellik anlamına gelmez, değil mi CS?

Bu konuda kontrollü bir deneme yapmamız gerekiyor.

Daha iyi testler için istem girmenin puanı gerçekten artırıp artırmadığını görmek için daha fazla çalışma yapmamız gerekiyor.

Ancak Android testinin diğer yarısında bir deneme yaptık. Bu denemede temsilcilerin emülatör kullanmasını sağladık.

Karşılaştırmamızın başlarında emülatörden bahsetmemiştik.

Temsilcilerin bunu anlayacağını varsaydık.

Sonuç olarak, neredeyse hiçbirinin emülatörü başlatmadığını gördük.

Daha önce de belirttiğim gibi, kullanıcı arayüzü testlerimiz karşılaştırmalarımızda oldukça önemli bir yere sahip. Emülatörler olmadan kullanıcı arayüzü testlerini kullanamazsınız.

Yani hepsi çok basit bir şeyde başarısız oluyordu.

Şimdi bir ikilemle karşı karşıyayız.

Temsilcilere emülatörü kullanmaları gerektiğini söyleyip daha yüksek puan alma riskini mi göze alalım yoksa hiçbir şey söylemeyip bunu kendilerinin anlamasını mı bekleyelim?

Ancak sonuçta amacımız, Android kodlama ve problem çözme becerilerini ölçen adil bir karşılaştırma yapmaktı.

Çevresel faktörleri ölçmek istemiyoruz.

Bu nedenle, orta yolu seçtik.

Onlara emülatörün nasıl başlatılacağını anlattık ancak kullanıp kullanmamaları gerektiğinden bahsetmedik.

Sonuçta, emülatörü başlatmak aslında test etmemiz gereken veya test etmek istediğimiz şey değildir.

Bu emülatör talimatının etkisini ölçtük.

Şimdi, onlara nasıl yapılacağını gösterdiğimizde, temsilcilerin emülatörü çok daha fazla başlattığını ve kullanıcı arayüzü testlerini çalıştırdığını gördük. Bu da maalesef bizim için geçme oranını büyük ölçüde etkiledi.

Ayrıca, başlatılmamış emülatörde başarısız olmak gibi sorunlar yerine gerçek kodlama hatalarını ve sorunlarını incelememize olanak tanıdı.

Özetle, istemlerin spesifik olması hâlâ çok önemlidir. Kendi karşılaştırmalarınızı veya değerlendirmelerinizi tasarlıyorsanız sizin için gerçekten önemli olan şeyleri test etmeniz gerekir.

Örneğin, bir becerinin veya aracın jeton verimliliğini değerlendiriyorsunuz. Önce değerlendirmenin başarılı olmasıyla başlamanız, verimlilik için değişikliği yapmanız ve ardından daha az jetonla hâlâ başarılı olduğunu doğrulamanız gerekir.

Aksi takdirde, aynı anda çok fazla değişken değişir ve yaptığınız değişikliğin gerçekten daha iyi sonuç verip vermediğini anlayamazsınız.

Tomáš Mlynarič

Skor tablosuna geri dönün.

Belirttiğim gibi, en iyi modeller görevlerin yaklaşık %40'ını geçer ve geçme oranı tüm kontrollerin geçmesini gerektirir.

Aksi takdirde görev başarısız olur.

Bu durumda, temsilcilerin diğer %60'lık kısım için faydalı bir şey üretmediği söylenebilir mi?

Hayır, o noktaya yaklaşıyorlar.

Temsilcinin çalışan çözümlere ne kadar yaklaştığını göstermek için tamamlanma oranını veya kısmi puanı da hesaplarız.

Bu, dört kategorideki ağırlıklı bir puandır: görsel tutarlılık, işlevsellik, düzgün çalışıp çalışmadığı, göreve özgü bazı gereksinimler ve bazı gerileme kontrolleri.

Daha düşük sıralamadaki modellerin işin yaklaşık yarısını tamamlayabildiğini, öncü modellerin ise görevlerin ortalama %80'ini tamamlayıp %80'ine ulaşabildiğini ancak yalnızca %40'ını geçebildiğini görebilirsiniz.

Bu nedenle, neler olduğunu kontrol etmek için Flutter'dan Android'e dönüşümle ilgili bir deneme yaptık.

Tamamlanma oranını her birkaç temsilci adımında yeniden hesapladık ve tüm öncü modellerde aynı kalıpları gördük.

Yaklaşık 140 adımda ortalama %90 puana ulaşmaya çalışıyorlardı. Ardından, %100'e ulaşmak için 90 adım daha (yani denemenin yaklaşık %40'ı kadar) harcadılar ancak yalnızca %1 veya %2 daha fazla puan alabildiler.

Bunun, günümüzdeki temsilci tabanlı geliştirme sürecini yansıttığını düşünüyoruz. Deneyimsiz geliştiriciler veya kullanıcılar, uygulamanın tamamlandığını görüyor.

Her şey oluşturuluyor.

Giriş bir şekilde işe yaradı.

Hiç kilitlenme olmayabilir.

Ancak kıdemli bir mühendis gelip koda baktığında mimari sorunlar, yaşam döngüsü kusurları ve benzeri birçok kusur görür.

Tomáš Mlynarič

Son olarak, Android Bench'i (Work 2.0) değerlendirelim.

1.0 ile karşılaştırdığımızda, artık yalnızca 30 görevimiz var ve bu bilinçli bir tercih.

İzole hata düzeltmeleri ve küçük yamalar yerine eksiksiz ekranlar, çok modüllü geçişler ve tüm uygulama dönüşümleri sunuyoruz.

Yamalar artık onlarca dosyada çok daha büyük.

Çok formatlı kullanıcı arayüzü kontrollerimiz de var.

Temsilciler daha uzun süre çalışmalı ve daha fazla çaba göstermelidir.

Diğer öncü karşılaştırmalarla kıyasladığımızda, karşılaştırmamızın çok daha büyük kod değişiklikleri gerektirdiğini görüyoruz.

Görevlerin çoğu sıfırdan yazıldığı için kirlilik içermez ve hâlâ gelişme için bolca alan vardır.

Başta da söylediğim gibi, yapay zeka dünyasında birkaç ay sonsuzluk gibi geliyor ve sonunda her karşılaştırma ölçütü maksimuma ulaşıp doygunluğa erişiyor.

Bu dönem sona erdiğinde ise umarım yapay zekanın o dönemdeki durumuna uygun, daha zor ve karmaşık görevlere yöneleceğiz.

Şimdi, modelleri ve test ortamlarını karşılaştırmak ve bazı analizler elde etmek için Android Bench'i pusula olarak kullanın.

Daha derinlemesine incelemeye hazır olduğunuzda aynı karşılaştırma ve değerlendirme ilkelerini kendi kod tabanlarınıza ve iş akışlarınıza uygulayın. Çünkü yapay zekayı, üzerinde çalıştığınız kodda ölçmekten daha iyi bir yöntem yoktur.

Yapay zekanın doğru sonuç verdiğini ummak yerine, doğru sonuç verdiğinden emin olabilirsiniz.

Tüm Android Bench ekibi adına, gösterdiğiniz ilgi için teşekkür ederiz.