Modeli Buluta Değil Telefona Koymak

Bir yapay zekâ modelini sunucuda çalıştırmak kolay yoldur. Makine güçlüdür, bellek sınırı canınızı sıkmaz, modeli güncellemek istediğinizde tek bir dağıtım yeter. Buna rağmen Ar-Ge tarafında tasarladığım işlerin çoğunda modeli telefonun içine koymayı planladım.

Bu tercih bedavaya gelmiyor. Ne kazandığımı ve karşılığında neyi verdiğimi olabildiğince açık anlatmak istiyorum.

Önce kolay yolun hakkını vereyim

Bulut tarafında çıkarım yapmanın gerçek avantajları var. Modelin boyutu neredeyse umurunuzda değil; yüz megabaytlık bir ağı da yükleyebilirsiniz. Tek bir yerde güncelleme yaparsınız, kullanıcı hiçbir şey indirmez. Modelde bir hata bulduğunuzda düzeltmesi bir dağıtım sürüyor, mağaza inceleme sırası beklemiyorsunuz.

Cihaz çeşitliliğiyle de uğraşmazsınız. Beş yıllık bir Android telefon da, yeni bir iPhone da aynı cevabı alır; hangi donanımın neyi hızlandırdığını düşünmek zorunda kalmazsınız. Bunlar küçümsenecek şeyler değil.

Bu yüzden “her şeyi cihaza koyun” demiyorum. Söylediğim şey daha dar: bulut varsayılan değil, bir tercih. Ve pek çok üründe yanlış tercih.

Cihaz üstünün dört somut kazancı

Kararı verirken dört başlığa bakıyorum. Hepsi kolay ölçülen şeyler değil ama hepsi kullanıcının doğrudan hissettiği şeyler.

Gecikme kalemi kâğıt üzerinde küçük görünüyor ama kullanıcı deneyimini birebir belirliyor. Fotoğrafı yükleyen bir akışta kullanıcı yükleme çubuğu görüyor, iptal edebiliyor, geri tuşuna basınca ne olacağını sormak zorunda kalıyorsunuz. Çıkarım cihazda olduğunda bu ekranların çoğu ortadan kalkıyor; kod tarafında da azalıyor.

Maliyet kalemi ise uzun vadede en belirleyicisi. Bir görüntü sınıflandırma özelliğini buluta koyduğunuzda, ücretsiz kullanıcı sayınız arttıkça masrafınız da artıyor. Cihazda ise kullanıcı sayısı ile sunucu faturası arasındaki bağı tamamen koparıyorsunuz. Ücretsiz bir aracın hayatta kalabilmesi çoğu zaman buna bakıyor.

Ödenen bedel: boyut ve niceleme

Cihaz üstü çıkarımın asıl fiyatı şurada: modelin uygulamanızın içine sığması gerekiyor. Eğitim sırasında rahatça kullandığınız ağı olduğu gibi telefona koyamazsınız.

Niceleme (quantization) burada devreye giriyor. Ağırlıkları 32 bit kayan noktalı sayı yerine 8 bit tam sayı olarak tutuyorsunuz. Aritmetiği basit: ağırlık başına dört bayt yerine bir bayt, yani ağırlıkların kapladığı yer kabaca dörtte birine iniyor. Bellek kullanımı da, çoğu cihazda çıkarım süresi de bundan faydalanıyor.

Karşılığında doğruluk kaybediyorsunuz. Kaybın büyüklüğü modele ve veriye göre değişiyor, bu yüzden “şu kadar düşer” diyen bir kural yok — nicelenmiş modeli aynı test setinden tekrar geçirip kendiniz görmek zorundasınız.

Boyut da tek başına bir sayı değil. Modelin diskte kapladığı yer ayrı, çalışırken tuttuğu bellek ayrı. Eski bir telefonda arka planda çalışan başka şeyler varken model yüklenirken uygulamanın kapanması mümkün. Bunu tasarım aşamasında hesaba katmak, sonradan “neden bazı cihazlarda çöküyor” diye aramaktan daha ucuz.

Doğruluk kaybını nasıl karşılamayı planladım

Küçük bir modelin en dürüst özelliği, emin olmadığını söyleyebilmesi. Tasarımlarımda çıkarımı tek başına bir cevap değil, güven değeriyle birlikte gelen bir öneri olarak kurguladım.

      // Sözde kod: önce cihazda dene, emin değilsen dürüst ol
      final sonuc = await yerelModel.calistir(goruntu);

      if (sonuc.guven >= esik) {
        return Teshis.yerel(sonuc);          // internete hiç çıkılmadı
      }

      if (!await agVar()) {
        return Teshis.belirsiz(sonuc);       // “emin değilim” de, uydurma
      }

      return await bulutModel.calistir(goruntu);   // ağır model, yalnızca gerektiğinde

Buradaki eşik sabit bir doğru değil; sahadan gelen görüntülerle kalibre edilmesi gereken bir tasarım parametresi. Ama yapının kendisi önemli: amaç, isteklerin çoğunun hiç internete çıkmadan karşılanması; bulut yalnızca modelin zorlandığı vakalar için ve yalnızca bağlantı varken devreye giriyor.

Bu kurgunun bir yan faydası daha var: buluta düşen istekler aslında modelin zorlandığı örnekler oluyor. Yani fatura ödediğiniz her istek, aynı zamanda bir sonraki eğitim turunda işinize yarayacak bir veri noktası.

TarımGöz: kararı saha verdi

TarımGöz'ü, telefon kamerasıyla bitki hastalığı teşhisi yapan bir araç olarak tasarladım. Kullanıcı tarlanın ortasında duruyor. Bağlantı ya yok ya da tek çubuk. Fotoğrafı sunucuya yüklemesini bekleyen bir akış, tam olarak işe yaraması gereken anda çalışmıyor demektir.

Bu yüzden teşhis modelini baştan cihaz üstü çalışacak şekilde planladım: açık veri setiyle transfer öğrenmeyle bir sınıflandırıcı, ardından niceleme ve LiteRT ile Core ML biçimine indirgeme.

Ama planda uygulamanın tamamı cihaza taşınmıyor. Kendime sorduğum ayırıcı soru şuydu: bu özellik zaten internete muhtaç mı? Sulama hesabı meteoroloji ve uydu verisi istiyor; o veri zaten ağdan geliyor, dolayısıyla hesabı sunucuda yapmanın bir zararı yok. Teşhis ise hiçbir dış veriye ihtiyaç duymuyor — yalnızca fotoğraf ve model. O yüzden teşhis cihazda, sulama bulutta.

Mahremiyet tarafı da bu ayrımla kolaylaşıyor. Çiftçinin tarlasından çektiği fotoğraf, kendi arazisi hakkında bilgi taşıyan bir veri. Teşhis cihazda kaldığı sürece o fotoğrafın nereye gittiğini açıklamak zorunda kalmıyorsunuz; kullanıcı isterse düzeltmesini paylaşıyor, istemezse hiçbir şey çıkmıyor.

Sağlam: burada tartışılacak bir şey yoktu

Sağlam'da durum daha keskin. Deprem sonrasında ilk kopan şey bağlantı oluyor. Çatlak tespitini, tahliye haritasını ve risk skorunu sunucuya bağlarsanız, uygulama tam da var olma sebebinin ortasında ölür.

Dolayısıyla soru “cihazda mı bulutta mı” değildi. Soru şuydu: telefonda ne kadar yer harcamaya hakkım var? Çünkü aynı indirmenin içinde hem çatlak tespiti modeli hem de çevrimdışı harita verisi duruyor. İkisi de yer kaplıyor ve ikisi de pazarlık kabul etmiyor.

Tasarımda vardığım denge şu oldu: model olabildiğince küçük tutulacak — tek işi var, yüz sınıf tanıması gerekmiyor — harita ise bölge bölge indirilecek. Kullanıcı yalnızca yaşadığı ili indiriyor, tüm ülkeyi taşımıyor. Model küçük kaldığı için indirmenin sabit maliyeti harita tarafına ayrılabiliyor.

LiteRT ve Core ML: tek model, iki hedef

Cihaz üstüne geçtiğiniz anda tek bir modelin değil, iki dağıtım biçiminin sorumluluğunu alıyorsunuz. Android tarafında LiteRT (eski adıyla TensorFlow Lite), iOS tarafında Core ML. Eğitim tek yerde yapılıyor, sonra aynı ağırlıklar iki ayrı biçime dönüştürülüyor.

Bunun pratikte iki sonucu var. Birincisi, iki çıktı aynı görüntüye bit bit aynı cevabı vermek zorunda değil; niceleme ve donanım hızlandırma farkları küçük sapmalar üretebiliyor. Bu yüzden aynı doğrulama görsellerini iki platformda ayrı ayrı geçirmeyi sürecin parçası yaptım — “Android'de çalışıyor, iOS'ta da çalışır” varsayımı burada geçmiyor.

İkincisi, Flutter tarafında model çağrısı doğrudan Dart'ta durmuyor. Çıkarımı platform kanalıyla yerel tarafa devredip sonucu geri almayı planladım; arayüz Flutter'da kalıyor, modelin çalıştığı yer her platformun kendi çalışma zamanı oluyor. Bu ayrım aynı zamanda çıkarımı arayüz iş parçacığından uzak tutmayı da kolaylaştırıyor — model çalışırken ekranın donmaması gerekiyor.

Donanım hızlandırma tarafında da tek bir yol yok. Yeni cihazlarda hızlandırılmış çalışan bir model, eski bir cihazda işlemciye düşebiliyor. O yüzden tasarımda hızlandırmanın bulunmadığı durumu bir hata değil, normal bir çalışma biçimi olarak kabul ettim: yavaş ama çalışan bir cevap, hiç cevap vermemekten iyi.

Karar verirken sorduğum sorular

Bu kararı her seferinde sıfırdan tartışmamak için kendime sorduğum liste kısaldı:

• Özellik zaten internete muhtaç mı? Muhtaçsa cihaza taşımanın kazancı azalıyor; dış veri olmadan çalışmıyorsa hesabı sunucuda yapmak daha temiz.
• Kullanıcı bu özelliği nerede kullanıyor? Tarla, afet alanı, metro, bodrum kat — bağlantının olmadığı yerlerse cevap zaten belli.
• Veri hassas mı? Fotoğraf, konum veya sağlık verisi cihazdan çıkmıyorsa yazacak rıza metni de, taşıyacak sorumluluk da azalıyor.
• Model küçültülebiliyor mu? Tek işi olan bir sınıflandırıcı küçülür; genel amaçlı büyük bir ağ küçülmez, zorlarsanız işe yaramaz hale gelir.
• Hata pahalı mı? Pahalıysa cihazda çıkarım tek başına yetmez; güven eşiği ve “emin değilim” hali şart.

Ar-Ge tarafındaki bu iki tasarım da henüz kod aşamasında değil, üzerinde çalıştığım mimari kararlar. Ama bu kararların çoğu bir satır kod yazılmadan önce verilmesi gereken kararlar. Modeli buluta koyup sonra “aslında bu internetsiz de çalışmalıydı” demek, ürünün yarısını yeniden yazmak anlamına geliyor. Kolay yol her zaman ucuz yol değil.

• Yapay Zekâ
• Cihaz Üstü Çıkarım
• LiteRT
• Core ML
• Niceleme
• Çevrimdışı