OCR motorunu neden ölçerek seçtim
Veri çıkışı olmayan bir üretim makinesinin ekranını okumak için üç OCR seçeneğini doğruluk, gecikme ve maliyetle karşılaştırdım. Kazanan, en "güçlü" olan değil, sahaya en iyi oturan oldu.
Problem: veri yalnızca ekranda
Samsun Teknopark'taki stajımda karşılaştığım makineler üretim sayaçlarını yalnızca operatör ekranında gösteriyordu. PLC çıkışı, veritabanı ya da rapor dosyası yoktu; vardiya sonunda kaç dakika duruş yaşandığını kimse bilmiyordu.
Çözüm fikri basitti: ekranın görüntüsünü yakala, okunması gereken alanları OCR ile oku, okumaları olaylara çevir. Asıl karar, hangi OCR motorunun sahada güvenilir çalışacağıydı.
Üç aday
- Mistral OCR — bulut tabanlı.
- PaddleOCR — açık kaynak, yerelde çalışıyor.
- RapidOCR — PaddleOCR ile aynı modelleri ONNX Runtime üzerinde çalıştırıyor.
Bulut neden elendi
Bulut OCR üç sebeple elendi: gecikme, maliyet ve veri gizliliği. Saniyede birkaç okuma yapan bir sistemde her kareyi buluta göndermek hem yavaş hem pahalı; üstelik fabrika ekranı dışarıya çıkmaması gereken bir veri.
PaddleOCR mı, RapidOCR mı?
İkisi aynı modeli kullandığı için doğruluk farkı beklemiyordum. Fark kurulumda çıktı: saha cihazı bir Raspberry Pi 5, yani ARM. RapidOCR (ONNX) ARM'de sorunsuz kuruldu; seçim buna göre yapıldı.
Model boyutunu da ölçtüm: small model, medium ile aynı doğrulukta ve 3,7 kat daha hızlı çıktı. Daha büyük model burada hiçbir şey kazandırmıyordu.
Doğru motor yetmez: doğrulama
Hiçbir OCR her kareyi doğru okumaz. Bu yüzden okumaları birbirine karşı denetledim: ekrandaki kalite oranı, sağlam/toplam ürün sayısından yeniden hesaplanıp okunan değerle karşılaştırılıyor. Tutmayan okuma reddediliyor. Hatalı bir okumayı kaydetmek, hiç okumamaktan daha kötü.
Sonuç
| Doğrulanan | Sonuç |
|---|---|
| 6 alanın okunması | 6/6 doğru, güven skoru %99+ |
| Duruş tespiti | gerçek 90 sn → ölçülen 88 sn |
| Kesinti dayanıklılığı | 38 bekleyen okuma diskten geri yüklendi |
Ders: "en iyi model" diye bir şey yok, bu sahaya en uygun model var — ve onu ancak ölçerek bulursun.