Küçük modellerle temsilci tabanlı kodlama iş akışları

İşte böyle.

Herkese merhaba.

Ben Jose. Ian ve Zoe ile birlikteyiz.

LLM'leri hepimiz biliyoruz.

Yemek tarifi bulmaktan YouTube videolarını özetlemeye ve kod yazmaya kadar her şey için bu araçları kullanıyoruz.

Gemini modelleri gibi gerçekten inanılmaz şeyler yapabilen çok büyük LLM'ler var ancak bu konuşmada küçük dil modellerinden bahsedeceğiz.

Bunlar da LLM'dir çünkü 4 milyar parametreye sahip bir şey küçük olamaz. Ancak bundan sonra bu ayrımı yapacağız: öncü modeller ve küçük dil modelleri, yani roket ve bisiklet.

Küçük modelleri, öncü modellere alternatif olarak değil, çoğunlukla onları tamamlayıcı olarak ele alacağız.

Küçük dil modellerinin tüm avantajlarını, özellikle de açık, açık ağırlıklı ve indirilebilir olduklarında nasıl avantajlar sağladıklarını inceleyeceğiz. Ancak önce maliyet konusuna bakalım.

Bu konuşma için birçok karşılaştırma testi yaptım. Bunlardan biri, 9 dolardan daha düşük bir maliyetle yaklaşık 131 milyon jeton kullanan 200 orta ve zor görevden oluşan bir veri kümesiydi.

Bunun için Gemma 4'ü kullandım. Bu modeli indirip kendi donanımımda ücretsiz olarak çalıştırabilirdim ancak adil bir karşılaştırma yapmak için ticari bir ağ geçidinde çalıştırdım.

Peki, öncü bir modelin maliyeti ne kadar olur?

Jeton önbelleğe alma ve diğer faktörlere bağlı olarak yaklaşık 20 ila 200 kat daha fazla.

Yani bisiklet en hızlı ulaşım aracı olmayabilir ancak kesinlikle en verimli olanıdır.

Gerçekten de öyle.

Şimdi akla gelen soru, kalite ve doğruluk açısından ne fark olduğu.

Bu veri kümesinde Gemma 4, görevlerin %53'ünü çözebiliyor.

Bunun iki anlamı vardır.

Soldaki görevleri çalıştırmak için öncü bir model kullanıyorsanız bu gereğinden fazla olabilir.

Sağdaki görevleri çalıştırmak için küçük bir model kullanıyorsanız modeli bir çözüme yönlendirmeniz veya daha büyük bir model kullanmanız gerekir.

Bu konuşmada, her jetondan daha fazla yararlanmanıza yardımcı olmak istiyoruz.

Zoe, küçük bir modeli nasıl seçeceğinizi anlatacak. Ian ise Gemma modellerinden bahsedecek. Böylece, bu modellerin neler yapabileceğiyle ilgili düşüncelerinizi nasıl şekillendireceğinizi anlayacaksınız.

Ardından, Android Studio'da Gemma 4'ü nasıl deneyebileceğinizi kısaca göstereceğim. Son olarak, küçük modelleri günlük iş akışlarınıza nasıl dahil edebileceğinizi ve neler yapabileceklerini anlamanıza yardımcı olacak gerçek Android geliştirici karşılaştırmalarını göstereceğiz.

Şimdi sözü Zehra'ya bırakıyorum.

Çok teşekkürler Jose.

Yani her şey için tek bir model kullanmak, fındık kırmak için balyoz kullanmaya benziyor, değil mi?

Verimli bir yöntem olsa da biraz orantısızdır.

Küçük modelleri, araç setinizi genişleten birer unsur olarak düşünebilirsiniz.

İş akışlarınıza neleri dahil etmeniz gerektiğini bilmek için araç setini açmanız, nelerin mevcut olduğunu, özelliklerinin neler olduğunu ve ne işe yaradıklarını görmeniz gerekir.

Küçük modelleri seçmek için küçük modelleri tanımanız gerekir.

Çoğu kişinin dil modeli dendiğinde aklına gelen model türü, otoregresif dil modelidir.

Bu model, parçalara ayrılmış bir girişe göre aday listesinden en olası bir sonraki parçayı seçtiği için otoregresiftir.

Ardından, seçilen en olası sonraki parça girişe geri döner ve bu şekilde devam eder. Bu yöntem, tutarlı ve akıllıca görünen yanıtlar üretebilir ancak doğrusal çalışma dahil ancak bunlarla sınırlı olmamak üzere bazı sınırlamaları vardır.

Yani doğrusal olmayan bir şekilde çalışabiliriz.

Difüzyon modeli de aynı yaklaşımı kullanır ancak her seferinde bir jeton bloğu üzerinde çalışır.

Neredeyse odaklanılan bir eskiz gibi.

Bu durumda DiffusionGemma, her seferinde 256 jetonluk parçalar üzerinde çalışır.

Yani temel olarak, tüm blokta çalışan bir geçiş elde edersiniz ve daha az gecikmeyle sonuç üretebilirsiniz.

Araç setimizde yazabilen modeller var, değil mi?

Yanlış.

Yani yerleştirme modelleri, resim veya metin gibi nesneleri ya da diğer kavramları vektöre dönüştürür.

Bu sayede, koordinatları yüksek boyutlu bir uzaya eşleyerek iki şeyi kavramsal olarak karşılaştırabiliriz.

Örneğin, sosisli sandviç bir sandviçse muhtemelen yakın bir yerde biter veya yakın bir alanda sonlanır.

Bu nedenle, iki kavramın ilişkili olup olmadığını kontrol etmek, model geçişi yerine biraz matematik gerektirir. Bu da biraz matematik gerektirir, ancak bu paradigma daha da ileri gider, değil mi?

Bir de tek bir işi yapabilen ve bu işi gerçekten iyi yapan daha küçük ve özelleştirilmiş modeller vardır.

Örneğin, doğal dili API çağrılarına dönüştüren işlev modellerimiz, adından da anlaşılacağı üzere neler yapabileceğini bildiğiniz görüntü modellerimiz veya belirli parametrelere göre bir girişe puan verebilen sınıflandırıcılarımız var.

Seçebileceğiniz çok fazla şey var, değil mi?

Birçok farklı model türü var. Bunların farklı boyutları, farklı bağlam pencereleri, farklı özellikleri, bellekte kapladıkları farklı alanlar var. Araç kutusunu açıp her olasılığı hesaba kattığınızda seçenekler katlanarak artıyor. Bu durum, kendin yap meraklılarını kesinlikle heyecanlandırabilir veya karar verme konusunda kararsızlığa sürükleyebilir.

Peki, küçük bir modeli nasıl seçersiniz?

Yerel olarak çalıştırılabilen açık küçük modellerden oluşan Gemma modelleri araç kutusunu açarak başlayalım.

Söz sende, Ian.

Teşekkürler, Zoe.

Jose'nin de başta belirttiği gibi, küçük dil modelleri görevlerin yaklaşık %50'sini hazır olarak yapabilir.

Peki neden özellikle yerel bir model seçebilirsiniz?

Bu da yaklaşık dört şeye karşılık gelir.

İlk olarak gizlilikten bahsedelim.

Örneğin, API anahtarlarınız, tescilli kodlarınız veya dizüstü bilgisayarınızdan kesinlikle çıkmaması gereken verileriniz olabilir.

İkincisi ise gecikmedir.

Model, ekran kartı belleğine veya birleşik belleğe yüklendiğinde hesaplama tamamlanır tamamlanmaz yanıt alırsınız.

Bu nedenle, sunuculara gidiş dönüş süresi yoktur ve ek gecikme maliyeti olmaz.

Sırada sıfır marjinal maliyet var.

Bu nedenle, modellerin nerede çalıştırılacağını kontrol edebildiğinizde modeller uygun maliyetli olur.

Örneğin, yerel bir makinede bir şey çalıştırırken hata döngüsünde ek yeniden denemeler yapılıyor olabilir.

Bu işlem için herhangi bir ücret ödemezsiniz ve bu bölüm için beklenmedik API maliyetleri söz konusu olmaz.

Son olarak dördüncü özellik, çevrimdışı erişimdir.

Yani bunu uçakta, trende, otobüste veya metroda, kısacası modeli donanımınızda çalıştırabileceğiniz her yerde kullanabilirsiniz.

Bu kulağa hoş geliyor ancak bu kararları verirken göz önünde bulundurmamız gereken iki önemli faktör var.

Yani biri bellek, ikincisi ise hız.

Bu diyagrama bakarsanız en alttaki iki model olan 26B ve 31B'nin, 16 bitlik bir niceleme olan BF16'da çalışması için 50 GB'tan fazla video RAM'i gerektiğini görürsünüz.

Bu nedenle, buradaki zorluk, birçok donanıma sığmamasıdır.

Bu nedenle, niceleme adı verilen bir işlemle bu hassasiyeti 4 bitlik bir kayan sayıya düşürüyoruz.

Şimdi biraz daha makul oldu.

14 GB ve 17 GB'tan bahsediyoruz, değil mi?

Bu model, birleşik bellekli Mac gibi bir cihazda çalıştırılabilir.

Ancak normal eğitim sonrası nicelemede, ağırlıkları sıkıştırdığınızda modelin doğruluğunun bir kısmını kaybedersiniz. Bu sorunu çözmek için bir teknik geliştirdik.

Buna niceleme duyarlı eğitim denir.

Bunu yaptığımızda model, eğitilirken bu daha küçük boyutlarda olacağını bilecek şekilde eğitilir ve bu nedenle aslında buna kıyasla daha az kayıp olur.

Böylece RAM gereksinimlerinde %75'lik bir azalma elde ederiz ve artık bu cihazlara sığabilir.

Bunu bir adım daha ileriye taşıyoruz.

Bu nedenle, birçok cep telefonunda çalışan mobil kuantizasyon yaklaşımlarımız, tüm farklı katmanların nasıl çalıştığını ve hangi boyutlarda çalışabileceğini anlayarak bu modelleri daha da küçültebilir.

Yani, karma bir niceleme çantamız var.

Böylece 11,4 GB'lık Gemma E2B'yi 1,1 GB'a düşürmüş olduk.

Bu nedenle, artık orta ve üst düzey telefonlarda çok daha makul bir fiyata sahip.

Bir sonraki ise hızdır.

Yani Zoe'nin de belirttiği gibi, otoregresif model kullandığınızda bir sonraki jeton grubunu tahmin edersiniz.

Örneğin, bir kodlama görevinde bu jetonların çoğunun aslında oldukça tahmin edilebilir olduğunu görebilirsiniz. Örneğin, bir yöntem imzasının sonu veya açılış ya da kapanış parantezi olabilir.

Bu durumda, spekülatif kod çözme adlı bir teknikten yararlanabilirsiniz.

Bu yöntem, daha küçük bir taslak model kullanarak bir dizi jetonu tahmin eder ve bu jetonlar daha sonra daha büyük bir model tarafından doğrulanır.

Bu yöntemin Gemma 4 mimarisinde çalışmasının nedeni, aynı KV önbelleğini paylaşmalarıdır.

Bunu modelin kısa süreli belleği gibi düşünebilirsiniz.

Bu durumda, küçük bir taslak model üç veya dört jetonu önceden tahmin eder ve daha büyük model aynı KV önbelleğine bakarak çıkışı doğrular.

Bu sayede, modelin çıktısının kalitesinde herhangi bir kayıp olmadan performans açısından yaklaşık 3 kat hızlanma elde edilebilir. Çünkü model yalnızca tahminlerde bulunur ve ardından başarılı mı yoksa başarısız mı, doğru mu yoksa yanlış mı olduğuna karar verir.

Yani bu, yaptığınız göreve bağlıdır.

Bu nedenle, daha fazla değişkenlik olduğu için yaratıcı yazarlık gibi konularda pek işe yaramaz ancak JSON yapıları ve kodlama gibi öngörülebilir konularda çok iyi çalışır.

Peki, bu modellerden birini nasıl değerlendirirsiniz?

Bu durumda yapabileceğiniz en bariz şey, LiveCodeBench veya MMLU gibi bir karşılaştırma testine bakıp puanı incelemek olur.

Ancak bu, modelin kapasitesi hakkında yalnızca üst düzey bir gösterge sağlar.

Asıl yapmanız gereken, çalıştığı tüm yığını değerlendirmektir.

Yani kullandığınız model, ağırlıklar ve niceleme yaklaşımı, çalışma zamanının çıkarımı (llama.cpp, Ollama veya LiteRT gibi bir şey kullanabilirsiniz), kullandığınız ajan düzeneği (Pi, OpenCode veya Antigravity gibi) ve bağlam penceresi (modelinizin işleyebilmesini istediğiniz tüm verilerin alanı) bu bileşenler arasındadır.

Tüm bu unsurların birleşimi, projenin uygulanabilir olup olmadığını belirler.

Kısaca bir örnek vermek gerekirse Android Bench'te Gemma 4 ile bazı testler yapıyorduk ve varsayılan 32 bin bağlamlı bir Ollama sürümü çalıştırıyorduk.

Testlerden birinde, hata ararken ajan düzeneğinin sıkıştırılması nedeniyle dosyanın yetersiz bellek nedeniyle bellekten kaldırıldığını ve modelin görevi tamamlayamadığını tespit ettik.

Bağlamı 32.000'den 256.000'e çıkararak modelin bu bilgiyi hafızasında tutmasını ve testi geçmesini sağladık.

Bu özel görevde başarı oranının iki katına çıktığını gördük.

Bu küçük faktörlerden birinin bile modelin uygun olup olmadığı konusunda büyük bir etkisi olabileceğini görüyoruz.

Peki, kendi değerlendirmelerinizi nasıl yaparsınız?

Bu konuda üç kısa önerim var.

Örneğin, Git geçmişini, yani başarılı olmuş bir dizi PR'yi alıp bunları modele istem girişi olarak kullanabilir ve modelin bu istemlerde ne kadar iyi performans gösterdiğini görebilirsiniz.

Ardından, modelin çıkışının doğru olup olmadığını değerlendirmenize yardımcı olacak deterministik bir değerlendiriciye ihtiyacınız vardır.

Bununla ilgili iki güzel örneğimiz var.

Derleyicimiz ve birim testlerimiz var.

Üretilen her şeyi bu araçla test edebilirsiniz. Araç, belirli bir görevde başarılı olup olmadığınızı gösteren bir başarılı/başarısız sonucu verir.

Üçüncü olarak da yörüngeleri günlüğe kaydetme.

Bu nedenle, bir temsilci çalıştırırken temsilcinin farklı davranışlarını izleyebilmek, nerede başarılı ve nerede başarısız olduğunu görmek istersiniz. Bu bilgileri, modelin ne kadar iyi etkileşim kurabildiğini ve araçları ne kadar iyi kullanabildiğini değerlendirmek için kullanabilirsiniz.

Sizden, soruyu "Bu model, büyük öncü model kadar akıllı mı?" şeklinde sormaktan vazgeçmenizi istiyorum.

"Bu görev, bu donanımda bu yapılandırmayla mümkün mü?"

Bunu anlamak için "Vardık mı?" adlı bir çerçeve geliştirdik.

Veya AWTY.

Bu çerçevenin temel ilkesi, tüm bu farklı görevleri hazırlık durumu açısından bu eksende puanlamaktır.

Yani modelin kendisi, kullandığınız çıkarım motoru, donanım ve ardından donanım yapılandırması.

Bu da hazır olup olmadığınızı gösterir.

Örneğin, belirli bir görevin ne kadar güvenilir olduğuna bakabilirsiniz.

Örneğin, 10 kez arka arkaya çalıştırdığınızda her seferinde aynı şeyi mi yapıyor?

Gecikme süresine bakıyor olabilirsiniz.

Belki de gerçek zamanlı bir yanıt almanız gerekiyordur.

Örneğin, görevi tamamlama hızıyla ilgili eşikleriniz neler?

Ardından RAM gereksinimlerine bakabilirsiniz.

Yani sadece cihazın sahip olduğu RAM değil, cihazın RAM'i, ayırabileceğiniz pay ve o donanımda çalıştırmanız gereken diğer uygulamalar ve diğer araçlar da önemlidir.

Yani RAM'in %50'sini mi yoksa yalnızca %10'unu mu kullanabilirsiniz?

Son olarak da hazır olma puanı alırsınız.

Yeşil renk, yapılandırmanın hazır olduğu anlamına gelir.

Turuncu, sarı veya kırmızıysa yapılandırmayla ilgili bir değişiklik yapmanız gerekebilir.

Daha düşük gecikme süresi için daha hızlı bir hızlandırıcıya veya daha yetenekli, daha büyük bir modele ihtiyacınız olabilir.

Bu nedenle, buna göz atmanızı öneririm.

Şu anda önizleme aşamasında olan bu aracın ne kadar faydalı olduğuyla ilgili geri bildirimlerinizi bizimle paylaşabilirsiniz.

Zoe, değerlendirmelerden bazılarını nasıl oluşturduğumuz hakkında daha fazla bilgi verecek. Şimdi sözü Jose'ye bırakıyorum. Jose, Gemma 4'ü kullanmaya başlamanın çok hızlı bir yolunu gösterecek.

Teşekkürler Ian.

Yani Gemma 4'ü hemen denemenin en hızlı yolu muhtemelen Android Studio'yu kullanmak.

Bunu nasıl yapacağınızı göstereyim.

Lütfen dizüstü bilgisayara geçelim.

İşte böyle.

Ayarlardaki model sağlayıcılar sayfasına gidip Gemma'yı seçersem her modelin ne kadar büyük olduğu hakkında net bir fikir edinebilirsiniz.

Modelleri sabit diskime indirmem yeterli.

Bu komut, bir llama.cpp sunucusu açar veya başlatır ve sunucu, en başından itibaren sizin için doğru şekilde yapılandırılır.

Ancak kendi llama.cpp sunucunuzu, Ollama'yı veya LM Studio'yu da kullanabilirsiniz.

Bunun için buraya gelip yerel bir sağlayıcı eklemeniz yeterlidir.

Ayrıca, küçük modelleri uzak bir sağlayıcı üzerinden kullanmak da çok mantıklıdır.

OpenAI veya Anthropic ile uyumlu olduğu sürece buraya bir model ekleyip bağlanabilirsiniz.

Şimdi bakalım.

Android Studio'da model seçmek için bu açılır menüyü kullanabilirsiniz.

Gemma 4 26B'yi seçtikten sonra "ViewModel nedir?" diye sorabilirim.

Anladım.

Unutulmaması gereken çok önemli bir nokta var: Modeli her değiştirdiğinizde tüm sohbet baştan yeni modele tekrar gönderilir.

Dolayısıyla, bir modelle çok uzun bir sohbet oluşturursanız ve yeni bir modele geçmek isterseniz muhtemelen yeni bir sohbet başlatmanız veya sohbeti sıkıştırmanız gerekir.

Şimdi slaytlara ve Zoe'ye dönerek küçük modellerle çalıştırabileceğiniz farklı iş akışları hakkında bilgi edinelim.

Çok teşekkürler Jose. Gemma modelleri hakkında genel bilgi verdiğin ve bu modellerin hazır olup olmadığına dair değerlendirmelerin için sana da teşekkürler Ian.

Modellerin türlerini ve özelliklerini gördük. Şimdi de bu modelleri hangi işlerde kullanabileceğinizi anlamaya çalışalım.

Muhtemelen zaten yaptığınız ilk iş türü, hata ayıklama veya sorun giderme gibi kodlama iş akışları ya da herkesin veya en azından benim elle yapmayı çok özleyeceğim bir şey olan test kapsamını artırma.

Doğru mu?

Bunlar, herkesin muhtemelen farkında olmadan yaptığı şeylerden bazıları.

Ancak sizi bunun ötesinde düşünmeye teşvik etmek isterim.

Küçük modellerin açık ağırlıklı olabileceğini ve yerel olarak çalıştırılabileceğini göz önünde bulundurursak size zaman kazandırabilecek şey ne olabilir?

Doğru mu?

Roketi kullanmamaktan bahsediyoruz, neden bunun için beyin kullanıyoruz?

Bunun ötesine geçebilirsek küçük modeller neler yapabilir?

Onları dahil edebileceğiniz ve hayatınızı kolaylaştırıp daha fazla yapmak istediğiniz şeyleri yapabilmeniz için size daha fazla kapasite sağlayabilecek bazı iş akışları nelerdir?

Örneğin, belgelerinizin yaptığınız değişikliklerle her zaman güncel olduğundan emin olmak, önceden taahhüt edilen bir kancanın parçası olan otomatik regresyon testleriniz olduğundan emin olmak, hatta temsilcinizin iş akışlarınızın bir parçası olarak aldığı bağlamın optimize edildiğinden ve daha da hızlı çalıştığından emin olmak gibi.

Bunlar sadece birkaç örnek.

Sonuç olarak, bir dereceye kadar sınır yok veya sınır mimari ve bunu nasıl uygulayacağınızı düşünebileceğiniz pek çok şey var.

Ancak teknik özelliklere, araçlara ve iş akışlarına sahip olmanıza rağmen hâlâ nereden başlayacağınızdan emin değil misiniz?

Karşılaştırma verileri tam da bu işe yarar.

Ian'ın da belirttiği gibi, genel bir skor tablosu (özellikle de Python için olanlar), küçük bir modelin Android iş akışlarınızda faydalı olup olmayacağı konusunda size çok az bilgi verir.

Alçıpan matkabı, beton matkabı hakkında pek bir şey söylemeyebilir.

Ancak kendi değerlendirmelerinize yatırım yapmanız gerekir.

Kendi mimarinizi test etmeye yatırım yapmanız gerekir ancak bunu yapmadan önce tüm kaynakları kullanmak istemeyebilirsiniz.

Zaman, para ve çaba gerektiren bir süreçtir. Bu nedenle, kendi değerlendirmelerinize yatırım yapmaya karar vermeden önce herkese açık karşılaştırmalara bakarak fikir edinebilir ve kısa bir liste oluşturabilirsiniz.

Karşılaştırmayı değerlendirirken dikkat etmeniz gereken üç şey var, değil mi?

Biraz meta bir soru ama öncelikle bu modelin ne tür bir görev yaptığını bilmemiz gerekiyor.

Ne kadar ayrıntılı olduğu

Vereceğiniz görev türüne benziyor mu?

İkincisi ise görevin kapsamıdır.

Belge yazmak mı, PR çözmek mi, yoksa sizin yaptığınız işe benzeyen bir şey mi?

Son olarak, sistemin karmaşıklığı, vereceğiniz karmaşıklığa benziyor mu?

Python karşılaştırmasının Android'i neden çok iyi temsil etmediğini burada görebiliriz.

Bu nedenle, Android ekosistemini ve Android çalışmalarını kapsayan bir karşılaştırma aracı olan Android Bench'i geliştirdik.

İlk sürümde PR boyutunda 100 Android görevi bulunuyor. Herhangi bir temsilci, model ve beceri kombinasyonunu kontrol etmek için bu sürümü Harbor üzerinden hemen çalıştırabilirsiniz.

2.0'ı daha karmaşık ve uzun süreli görevlerle kullanıma sunuyoruz. Böylece, öncü modellerin bugün verdiğiniz görevlerdeki performansını anlayabileceğiz.

Şimdi sözü Jose'ye bırakıyorum. Jose, bu yöntemle elde ettiğimiz sonuçları gösterecek ve küçük modellerle çalışmayı optimize etmenin bazı yollarını anlatacak.

Tamam, teşekkürler, Zoe.

Şimdi küçük bir modelin çözebileceği görevlere ve zorlanmaya başladığı noktalara bakalım.

Görevleri rastgele dört kategoriye ayıralım: küçük, orta, büyük ve uzun vadeli.

Uzun vadeli görevler, bir insanın tamamlaması günler veya haftalar sürebilecek görevlerdir.

Örneğin, taşıma veya büyük bir yeniden düzenleme işlemi. Sürprizbozan uyarısı: Bunları küçük bir modelle yapamazsınız.

En azından tek seferde.

Bu konuya daha sonra değineceğiz.

Tamam, küçük görevler.

Bunlar, bir veya iki dosyanın okunup yazılmasını gerektiren ve çok fazla bilgi gerektirmeyen işlerdir.

Örneğin, küçük modeller Compose'da, en azından Compose'un temel özelliklerinde oldukça iyidir.

Örneğin, öğeler arasında 8 dp boşluk bırakmak, sabit kodlanmış renkler yerine tema kullanmak veya dizeleri ayıklamak gibi.

Küçük bir model için bunları yapmak çok kolaydır.

Ancak bu görev daha ileri düzey bir konuyu kapsıyor, yine de kolay bir görev.

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

Bu durumda zorluk, bilgiyle değil, kapsamla ilgilidir.

Yani istem, aslında hangi composable'ı optimize etmemiz gerektiğini ve bununla ilgili sorunun ne olduğunu (her karede yeniden oluşturuluyor) söylüyor.

Bu sayede, Gemma 4 gibi küçük bir model için bile iş oldukça kolaylaşır.

Bu örnekte, işlem 3 dakika sürdü ve tek satırlık bir değişiklik yapıldı.

İşte böyle.

Küçük modelin ne olduğu konusunda artık iyi bir fikrimiz var.

Şimdi küçük bir görevin ne olduğuna bakalım.

Şimdi orta düzey görevlere bakalım.

Küçük modeller bunların çoğunu yapabilir.

Bu görevde, Pocket Casts uygulamasından gelen bir istekte kullanıcı aracısı eksik ve yeniden deneme mantığında bir hata var.

Bu biraz daha zor çünkü öncelikle aynı anda iki şey istiyoruz ve bunların kod tabanında nerede olduğuna dair bir ipucu yok.

Ancak bu durum geçti.

10 dakika sürdü.

Üç dosyada değişiklik yaptı.

Bu arada, OpenRouter üzerinden 6 sente mal oldu.

Şimdi aynı veri kümesinden başarısız olan bir göreve bakalım.

Bu, Now in Android'in oldukça kapsamlı bir rapor veya istem içeren bir örneğidir ancak sınıf adı veya dosya belirtilmediği için temsilcinin uygulamanın mimarisini, veri katmanını, senkronizasyon mekanizmasını vb. anlamak için daha fazla çaba harcaması gerekir. Bu nedenle, bu özel çalıştırmada başarısız oldu.

Her şey neredeyse doğru şekilde uygulandı ancak ilk senkronizasyonun değerinin -1 olacağı varsayıldı. Oysa bu değer aslında 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

Bu kadar basit.

Temsilci, mevcut birim testlerini çalıştırmış olsaydı bu hata tespit edilirdi.

Bu da daha küçük modellerin genellikle öncü modellere göre biraz daha erken durma eğiliminde olduğunu gösteriyor.

Temsilciden sorunu doğrulamasını değil, düzeltmesini istedik.

Bu nedenle, görevi bir doğrulama adımı içerecek şekilde değiştirmemiz gerekebilir.

Birazdan bu konuya da değineceğiz.

Şimdi büyük görevlerden bahsedelim.

Bu tanıma göre, büyük görevlerin yaklaşık yarısı her zaman başarılı olur.

Başarısız olanlardan bazıları aslında küçük bir model için çok uzun ve karmaşık. Bu konuda yapabileceğimiz pek bir şey yok.

Ancak bazı durumlarda, gerçekte ne olduğuna baktığınızda modelin %90 oranında doğru olduğunu fark edersiniz.

Bunlardan birini seçelim.

Bu testi, kararsız olduğu için seçtim.

Çalıştırıldığı sürenin yaklaşık yarısında başarılı oluyor.

Bu nedenle, küçük bir modelin yapabileceklerinin sınırında olduğunu düşünüyorum.

En azından Nisan ayından bir model.

Bu, Coil kitaplığındaki hatalı biçimlendirilmiş URL'leri ayrıştırmayla ilgilidir.

Gördüğünüz gibi, PR açıklaması oldukça kapsamlı. Bu harika bir şey ancak bir şartı atlamış.

Kısaca buna bakalım.

Tüm çalıştırmalarda tipik URL kodlamaları ve hatalar kontrol edildi ancak yalnızca bazıları (yarısı) hatalı kodlanmış karakterler için testler ekledi. Bu nedenle, test durumu burada.

Değerlendirmede başarısız olmayanlar.

Tüm denemeler neredeyse mükemmel sonuç verdi ancak bu durum, küçük modellerin her zaman ek adımı atmadığını bir kez daha gösteriyor.

Talimatlara uyarlar ancak öncü modeller gibi sizi etkilemeye çalışmazlar.

Artık temsilcilerde çaba düzeyini ayarlayabileceğinizi biliyor musunuz?

Küçük bir model kullandığınızda bu değerin çok düşük ayarlandığını göz önünde bulundurun.

Büyük görevleri, küçük modeller tarafından yaklaşık %50 oranında tamamlanabilen görevler olarak tanımlayalım. Bu, Zoe'nin daha önce bahsettiği Android Bench v1 veri kümesine karşı Gemma 4 31B'nin ulaşabileceği bir oran.

Uzun vadeli görevlerden bahsetmeden önce, küçük modellerin bu görevleri yerine getirmesine yardımcı olmak için yapabileceğimiz bir şey var mı?

Kesinlikle. Üstelik bunlar için hiç çaba sarf etmeniz gerekmez.

Öncelikle, Ian'ın bahsettiği gibi Gemma 4 gibi bir modeli yerel olarak kullanıyorsanız doğru şekilde yapılandırıldığından emin olun.

Örneğin, Gemma 4'ü sunmak için Ollama'yı kullanırsanız varsayılan olarak 32.000 jetonluk bir bağlam penceresi kullanılır ancak aslında sekiz kat daha fazlasını destekler.

Elbette Gemma 4'ü Android Studio üzerinden kullanıyorsanız yapılandırmanız gerekmez.

Varsayılan olarak doğru şekilde yapılandırılmıştır.

Değerlendirmelerimizde, tam bağlamın etkinleştirilmesi sonuçları %26'dan %53'e çıkardı.

Ardından, özellikle dokümanlarda arama yapmak için Android KSA aracını kullanın.

Modeller temel konularda oldukça iyi olduğundan bu her zaman geçerli değildir. Ancak yeni veya niş bir API kullandığınızda dokümanlara sahip olmak çok önemlidir.

Deneyimlerimize göre, web arama araçlarını kullanmaktan çok daha iyi.

Ardından, doğrulama ipuçları ekleyin.

Bu konuyu konuşmuştuk.

Modele testleri nasıl çalıştıracağını, hangi test türlerinin mevcut olduğunu, emülatörleri nasıl yöneteceğini vb. söyleyin. Bunu bir AGENTS.md dosyasında yapabilirsiniz. Bu sayede talimatlar tüm temsilciler tarafından kullanılabilir. Bu da iyi bir şeydir.

Bu belgeyi edinmeniz gerekir.

Ancak çok uzun AGENTS.md dosyalarına da dikkat edin. Farklı temsilciler denerseniz bazılarının çok büyük sistem talimatları ve araç açıklamaları olduğunu ve küçük modellerin performansını düşürdüğünü görürsünüz.

Bu karşılaştırmaları OpenCode ile çalıştırmayı denedik ancak muhtemelen daha büyük araç açıklamaları ve sistem istemleri kullandığı için pi'den çok daha düşük performans gösterdi.

Ardından, beceri ekleyin ve kaldırın.

Küçük modeller, yeni ve niş API'leri kullanırken yönlendirmeye ihtiyaç duyabilir ancak bağlamlarını genel Compose becerileriyle doldurmamak daha iyidir.

Peki, uzun vadeli görevler ne olacak?

Bunlar, onlarca dosyayı kapsayan, ciddi mimari kararlar gerektiren ve normalde bir plan oluşturan ve farklı görevleri yürüten bir alt temsilci sürüsü başlatan bir düşünme modeli tarafından ele alınan görevlerdir.

Uzun vadeli görevlere örnek olarak bir uygulamanın tamamını XML'den Compose'a taşıma, sıfırdan karmaşık bir uygulama oluşturma veya platformlar arası uygulamaları yerel Android'e dönüştürme verilebilir.

Yalnızca uzun vadeli görevlere odaklanan Android Bench V2'nin sonuçlarına baktığımızda, öncü modellerin %3 ila %40 arasında puan aldığını görüyoruz.

Bu nedenle, küçük modellerin bu konuda yetersiz kaldığını söyleyebiliriz.

Ancak ilk analizi öncü bir model üzerinden yönlendirip daha basit görevleri daha küçük modellere basamaklandırmak, parça ve kredi açısından çok daha verimli olur.

Bunu nasıl yapabileceğimize bakalım.

Zeynep'e dönelim.

Çok teşekkürler Jose.

Basamaklı düzene değineceğiz ancak size bazı yöntemler göstermeden veya bu konuyu ayrıntılı olarak incelemeden önce bir adım geri gidip farklı modellerin düzenlenmesinin size yardımcı olabileceği diğer yöntemleri göstermek istiyorum.

Yani düzenleme, örneğin, hiçbir zaman engellenmemenize yardımcı olabilir, değil mi?

Yani bir sağlayıcının çöktüğünü gördüğünüzde, API sıklık sınırlamasına ulaştığınızda veya Ian'ın dediği gibi uçakta ya da trende olduğunuzda yedek bir model oluşturabilir ve bu modeli çevrimiçi veya yerel olarak ayarlayabilirsiniz. Böylece herhangi bir sorun yaşandığında devam edebilirsiniz.

Orkestrasyon sayesinde daha iyi yanıtlar da alabilirsiniz.

Örneğin, küçük bir modelin kendi başına çalışmasını sağlayabilir ve biraz desteğe ihtiyaç duyduğunda bir danışmanı arayarak yardım alabilirsiniz.

Ayrıca farklı model türlerinin veya farklı modellerin aynı görevi aynı anda yürüttüğü bir konsey oluşturabilir, ardından farklı yanıtları ve her modelin ağırlıklarının ve sapmalarının sonucu nasıl etkilediğini değerlendirebilirsiniz.

Testler için ayrı bir model de kullanabilirsiniz.

Yani bir akran değerlendirmesi gibi.

Bunu bu şekilde görebilirsiniz.

Son olarak, orkestrasyon, basamaklı yapı gibi bir yöntemle maliyet verimliliği elde etmenize yardımcı olabilir.

Temel olarak, manuel olarak ayarlayabilirsiniz. Böylece planlama için bir model, yürütme için farklı bir model, testler için başka bir model ayarlayabilirsiniz.

Bunu yapmanın birden fazla yolu vardır. Bulutta yapabilir veya yerel olarak yapmak için bir LiteLLM proxy'si oluşturabilirsiniz.

Ya da isteğe göre otomatik olarak doğru model türüne yönlendirmek için bir sınıflandırıcı kullanabilirsiniz. Bu, Ian'ın bahsettiği proxy fikridir ancak otomatiktir.

Şimdi Jose'nin konuşmanın başında sorduğu soruya dönerek toparlayalım: Küçük modeller ile öncü modeller arasındaki kalite ve doğruluk farkı nedir?

Bilgisayar bilimindeki birçok şeyde olduğu gibi bu sorunun yanıtı da duruma göre değişir.

Ancak bu, sizin de bildiğiniz gibi, üzerinde çalışabileceğiniz bir konu.

Bu, nasıl ayarladığınıza ve parçalarla nasıl oynadığınıza bağlı olarak fark yaratabileceğiniz bir şeydir.

İlk adım, doğru aracı seçmek.

Birden fazla araç türü vardır.

Onları tanımak, keşfetmek istersiniz, değil mi?

Ardından, hangi işlerde iyi olduklarını ve hatta hangi işleri yapabileceklerini öğrenin.

İkincisi, modelin işi yapmak için aldığı kapsamı ayarladığınızdan emin olun.

Örneğin, görevle ilgili talimatlar, görev için doğru bağlamın sağlanması ve yalnızca doğru bağlamın sağlanması ve kendi çalışmasını kontrol etme yöntemleri gibi şeyler.

Ardından, elbette, yalnızca modeli tek başına değil, tüm kurulumu test etmeniz gerekir. Çünkü bu bir fark yaratacaktır ve elde ettiğiniz sonuçlar, farklı bir öğe yapılandırmasıyla ayarlarsanız değiştirilebilir.

Sonuç olarak, kendi değerlendirmelerinizi oluşturmanız veya ayarlamanız gerekir.

Son olarak, bisiklet ve roket arasında seçim yapmak zorunda kalmadan ikisini de yönetebilir ve bu sayede etkili bir şekilde harcama yapabilirsiniz.

Ancak en önemlisi, keşfetmeye, inşa etmeye ve eğlenmeye devam edebilirsiniz.

Android Bench'te ve buradaki bulgularınızda bir model listesi oluşturarak veya Android Studio'da Gemma 4 ile başlayarak bu süreci hemen başlatabilirsiniz.

Çok teşekkür ederim.