Asıl Zorluk Model Değil, Veri

TarımGöz'ü tasarlarken ilk haftalarımı yanlış soruya harcadım: hangi model? Doğru soru şuymuş — bu model sahada gerçekte neyi görecek?

TarımGöz, bir yaprağın fotoğrafından bitki hastalığı teşhisi yapmayı hedefleyen bir Ar-Ge çalışmam. Henüz tek satır kod yazmadım; tasarım ve fizibilite aşamasındayım. Ama tam da bu aşamada anladığım şey, projenin en kritik kararının model seçimi değil veri olduğu.

Başlangıç planım basitti: internette bitki hastalıkları için etiketlenmiş açık veri setleri var, onlarla eğitirim, sonra cihazda çalışacak küçük bir modele indiririm. Planın ilk yarısı işe yarıyor. İkinci yarısı, yani modelin gerçek bir tarlada işe yarayıp yaramayacağı, tamamen başka bir problem.

Açık veri setindeki fotoğraf, çiftçinin çektiği fotoğraf değil

Açık veri setlerindeki görüntülerin çoğu kontrollü koşullarda toplanmış. Yaprak koparılmış, düz bir zemine konmuş, eşit ışıkta, kadrajın tam ortasında çekilmiş. Bu iyi bir veri seti olduğu için değil, veri toplamanın en ucuz yolu bu olduğu için böyle.

Sahadan gelecek fotoğraf ise şuna benziyor: öğle güneşi, yaprağın yarısı gölgede, arkada toprak ve başka bitkiler, elde çekildiği için hafif bulanık, kadrajda üç yaprak birden var ve bir tanesi kadraj dışına taşmış.

Bu tabloyu ben teoriden çıkarmadım. 2.El Bilet'te kullanıcılar ellerindeki biletin fotoğrafını yüklüyordu. Gelen görüntülerin ne kadar farklı olabildiğini orada gördüm: ters çekilmiş, parmakla yarısı kapatılmış, ekrandan ekrana fotoğraflanmış. İnsanlar fotoğrafı sizin beklediğiniz gibi çekmiyor; ellerindeki telefonla, bulundukları yerde, hızlıca çekiyor.

Model, sizin öğretmek istediğinizi değil, en kolay ipucunu öğrenir

İşin sinsi tarafı şu: model, açık veri setinde çok yüksek bir başarı gösterebilir ve bunu hastalığın kendisini öğrendiği için yapmayabilir.

Diyelim ki bir hastalık sınıfının fotoğrafları ağırlıkla aynı gün, aynı sera masasında çekilmiş. Model, o hastalığı yaprak dokusundan değil arka plandaki masanın renginden ayırt etmeyi öğrenebilir. Doğrulama seti de aynı koşullardan geldiği için hata görünmez. Sonra tarlada, toprağın üstündeki bir yaprakta model dağılır.

Transfer öğrenme neyi çözer, neyi çözmez

Transfer öğrenme, tasarımın vazgeçilmez parçası. Sıfırdan bir görüntü modeli eğitmek için gereken veri ve donanım benim ölçeğimde yok. Genel görüntülerle önceden eğitilmiş bir modelin üzerine kendi sınıflarımı öğretmek çok daha gerçekçi.

Ama transfer öğrenme bir veri problemi çözücüsü değil, bir başlangıç noktası. Çözdüğü şey şu: kenar, doku, renk geçişi gibi temel görsel özellikleri baştan öğretmek zorunda kalmıyorum. Çözmediği şey şu: sizin son katmanınıza hangi fotoğrafları gösterdiyseniz, model sahada onlara benzeyen fotoğraflarda çalışır. Önceden eğitilmiş gövde, kötü bir veri setini iyi hale getirmiyor.

Veri artırma: sahayı taklit etmek, sınırlarını bilerek

Elde sınırlı sayıda saha fotoğrafı varken veri artırma mantıklı bir ara çözüm. TarımGöz tasarımında planladığım dönüşümler, doğrudan yukarıdaki tablodan türedi:

• Rastgele döndürme ve aynalama — kimse yaprağı hep aynı yönde tutmuyor.
• Parlaklık ve kontrast oynaması — öğle güneşiyle bulutlu havayı taklit etmek için.
• Kısmi gölge bindirme — yaprağın bir bölümünü karartmak.
• Hafif bulanıklık ve gürültü — elde çekim ve düşük ışık.
• Agresif JPEG sıkıştırma — mesajlaşmadan geçmiş görüntüler.
• Rastgele kırpma — kadraj dışına taşan yapraklar.

Buradaki sınır şu: veri artırma çeşitlilik üretmez, var olan çeşitliliği esnetir. Elinizde sadece bir bölgeden, tek bir çeşide ait yapraklar varsa, hepsini döndürüp karartsanız da model başka bir çeşidin yaprağını hiç görmemiş olur. Artırma, eksik veriyi gizler; yerine geçmez.

Kademeli veri toplama: veriyi bir kerede değil, döngüyle biriktirmek

"Önce büyük bir veri seti toplayayım, sonra başlayayım" planı bu projede işlemiyor; çünkü hangi fotoğrafların eksik olduğunu ancak model yanılmaya başlayınca öğreniyorsunuz. Tasarımda kurduğum döngü şöyle:

1. Açık veri setiyle bir ilk sürüm model. İddiası düşük, amacı öğrenmek.
2. Sınırlı bir kullanıcı grubuyla saha kullanımı. Her tahmin bir soru soruyor: doğru mu?
3. Modelin kararsız kaldığı ve yanıldığı fotoğrafların önceliklendirilmesi.
4. Bu fotoğrafların uzman doğrulamasıyla etiketlenmesi ve setin genişletilmesi.
5. Yeniden eğitim ve aynı ölçüm setiyle karşılaştırma.

Rastgele bin fotoğraf toplamak yerine, modelin zorlandığı yerlerden yüz fotoğraf toplamak daha değerli. Bunun için de modelin nerede zorlandığını size söylemesi gerekiyor — ki bu bizi son parçaya getiriyor.

“Emin değilim” diyebilen model

Bir sınıflandırma modeli, kendisine ne gösterirseniz gösterin bir cevap üretir. Yaprak yerine ayakkabı fotoğrafı verirseniz de en yakın hastalığı söyler. Kullanıcı için bu, yanlış cevaptan daha kötü: emin görünen yanlış bir cevap.

Bu yüzden TarımGöz'ün karar akışını tek bir tahmin üzerine değil, üç kademeli bir kontrol üzerine kurdum:

karar(fotograf):
    kalite = bulaniklik_ve_isik_kontrolu(fotograf)
    eger kalite dusukse:
        -> "Bu fotoğrafı değerlendiremedim"
        -> nasıl çekileceğine dair yönerge göster
        dur

    tahminler = model(fotograf)      # sınıf başına bir skor
    en_iyi  = tahminler[0]
    ikinci  = tahminler[1]

    eger en_iyi.skor < ESIK:
        -> "Emin değilim"
        -> en olası iki seçeneği göster, uzmana yönlendir

    degilse eger (en_iyi.skor - ikinci.skor) < FARK_ESIGI:
        -> "İki olasılık birbirine çok yakın"
        -> ikisini de göster

    degilse:
        -> teşhis + güven seviyesi + doğrulama sorusu

ESIK ve FARK_ESIGI değerleri sabit değil; saha verisi biriktikçe ayarlanacak parametreler. Ayrıca bu eşikler her sınıf için aynı olmak zorunda da değil.

Tasarımda vardığım yer

TarımGöz henüz yazılmadı. Ama bu tasarım turunun sonunda elimde net bir öncelik sırası var ve sırada model en üstte değil:

• Önce veri toplama akışı ve etiketleme disiplini.
• Sonra fotoğraf kalitesini çekim anında kontrol eden bir ön eleme.
• Sonra “emin değilim” cevabını mümkün kılan karar mantığı ve arayüz.
• En sonda model — çünkü model, veri değiştikçe değiştirilebilecek en ucuz parça.

Bir yapay zekâ projesinde demo yapmak ile ürün yapmak arasındaki fark tam olarak burada. Demo, elinizdeki temiz fotoğrafla çalışır. Ürün, kullanıcının gölgede aceleyle çektiği fotoğrafla çalışmak zorunda. İkisi arasındaki mesafeyi kapatan şey de daha büyük bir model değil, o fotoğrafa benzeyen veri.

• Ar-Ge
• Yapay Zekâ
• Veri Seti
• Görüntü İşleme
• TarımGöz