Pokémon Kart Tarayıcımı Sunucudan Telefona Nasıl Taşıdım?

Pooka adlı Pokémon kart koleksiyonu uygulaması, 2.0 sürümüne kadar kart tarama işlemini sunucu tarafında yürütüyordu. Kullanıcının çektiği fotoğraf sunucuya gönderiliyor, CLIP embedding modeline dönüştürülüyor ve veritabanındaki tüm kartlar üzerinde vektör araması yapılıyordu. Bu mimari çalışsa da ağ gecikmesi yaratıyor ve sunucu maliyetini artırıyordu. 2.0 sürümünde ise tüm işlem hattı Flutter aracılığıyla doğrudan telefona taşındı.

İşlem Hattı#

Kamera görüntüsünden eşleşmeye uzanan cihaz içi işlem hattı dört adımdan oluşur:

• Köşe Tespiti: Kamera karesindeki her kartı ve dört köşesini algılar; böylece dokuz kartlık bir albüm sayfası dokuz düz kırpılmış görsele dönüştürülür.
• Embedding Modeli: Kırpılan her görseli 256 boyutlu bir vektöre dönüştürür.
• Vektör Eşleştirme: Üretilen vektör, uygulama içine gömülü yaklaşık 47.000 İngilizce ve Japonca kartlık yerel indeksle eşleştirilir.
• Kabul Kuralı: Kartın doğrudan koleksiyona eklenmesine ya da kullanıcıya kısa bir seçim listesi sunulmasına karar verir.

Mimaride OCR kullanılmamıştır. Kart metinleri küçük, çoğunlukla Japonca ve parlak koruyucu kılıfların arkasındadır; kart çizimi (artwork) metne göre çok daha belirgin bir sinyal taşır.

Var Olmayan Eğitim Verisi#

En büyük zorluk model değil, veriydi. 47.000 kartı kapsayan etiketli gerçek telefon fotoğrafları bulunmadığı için sentetik bir veri hattı kuruldu:

• Simülatör: Temiz katalog taramaları; perspektif, oyun örtüleri, ışık değişimleri, gölgeler, parlama, bulanıklık, yığınlar ve albüm sayfaları eklenerek sahte telefon fotoğraflarına dönüştürüldü. Kartlar ve köşeler otomatik etiketlendi.
• Blender ile Doğrulama: Gerçekçiliği sınamak için kılıflı, koruyuculu ve albümdeki kartlar Blender'da 3D render edilerek 992 kartlık 605 değerlendirme görseli üretildi.
• Gerçek Fotoğraf Testi: Sisteme elle etiketlenen küçük bir gerçek fotoğraf kümesi eklendi. Ancak test kartlarının sadece 39'u gerçek fotoğraf olduğundan, tek bir kart genel skoru 2,6 puan etkiledi.

Omurga Model Seçimi#

Aynı 60 dakikalık eğitim bütçesiyle üç aday eğitildi:

• DINOv2-small: Perception Encoder (PE) modeliyle aynı doğruluğu yakaladı; dışa aktarıldığında 1,6 kat daha hızlı ve küçük olmasıyla öne geçti. İnce ayar sonrasında kart çiziminde %97, tam baskı türünde %91 doğruluk sağladı.
• Perception Encoder: Yüksek doğruluk sunsa da hız ve boyut optimizasyonunda geride kaldı.
• MobileNetV4: Gerçek fotoğraflar üzerinde diğer modellerin belirgin şekilde gerisinde kaldı.

Telefona Aktarma ve Pratik Dersler#

Model PyTorch'tan LiteRT (eski adıyla TensorFlow Lite) formatına aktarıldı ve flutter_litert ile çalıştırıldı:

• Ağırlık Kuantizasyonu: fp32 modeli 87,3 MB iken, int8 ağırlık kuantizasyonu ile ölçülebilir bir doğruluk kaybı olmadan 23,2 MB'a indirildi.
• Çalışma Zamanı Uyumsuzluğu: Dinamik int8 modeli Python'da kusursuz çalışırken iOS simülatöründe hiçbir kartı eşleştiremedi (12'de 0). Yalnızca ağırlıkları kuantize edilen model ise Python çıktılarıyla birebir eşleşip 12'de 12 başarı sağladı. Ders: Kuantize modelleri dışa aktardığınız ortamda değil, yayınlayacağınız gerçek çalışma zamanında test edin.
• Donanım Hızlandırma: Varsayılan olarak kapalı olan XNNPACK nedeniyle çıkarım 1.060 ms sürüyordu. XNNPackDelegate(numThreads: 4) eklenmesiyle bu süre 150 ms'ye geriledi.
• Lisans Bağımsızlığı: Önceki AGPL lisanslı YOLO modeli, özel olarak eğitilen küçük bir köşe tespit modeliyle değiştirildi.

---

Bu konuyu derinlemesine öğrenmek isterseniz: Edge Runtime ve Production Optimizasyonu modülüne göz atın.