Apple Vision OCR yerel bir 27B VLM'den 300 kat hızlı çalışıyor ama tablo yapısını yok ediyor

Yerel kullanım için OCR seçeneklerini karşılaştıran bir geliştirici, Apple'ın yerleşik Vision framework'ünün metni yerel olarak barındırılan bir 27B vision-language modelinden yaklaşık 300 kat daha hızlı çıkardığını — ama yine de karşılaştırmayı kaybettiğini buldu; çünkü çıktısı, az önce okuduğu belgenin yapısını sessizce yok ediyordu.

Kurulum

dev.to'da paylaşılan uygulamalı bir benchmark'a göre yazar, 27B görsel modeli yerel olarak çalıştırdı; IQ4_XS quantization kullanarak yaklaşık 15GB bellekte tuttu ve macOS'in Vision framework'ü ile onun VNRecognizeTextRequest API'si ile karşılaştırdı — ücretsiz olan ve bellek ayak izi eklemeyen özel bir metin tanıma motoru. Başlangıçtaki beklenti gelenekseldi: uzman araç karakter doğruluğunda kazanmalı, genel amaçlı model ise anlamsal işler için saklanmalıydı.

Yazar, gerçek belgeler üzerinde değil — çünkü gerçek belgelerde makul çıktıyı doğru çıktıdan ayıracak bir ground truth yoktur — cevabı önceden sabitlenmiş 1100×720 bir test görseli oluşturdu: Korece bir başlık ve tarih, dört sütunlu üç satırlı bir tablo (model, bellek, hız, durum), dört satır düz metin, tire içeren iki boş tablo hücresi ve bir karşıt (adversarial) satır — A0-1lO9-B8 — rakam 1'i küçük harf l ile, büyük harf O'yu rakam 0 ile eşleştiriyordu.

İlk oluşturulan görsel çöpe atılmak zorunda kaldı: monospace font bu glifleri içermediği için Korece etiket tofu kutuları olarak geldi. Yazarın da belirttiği gibi, ground truth'u sabitlediğiniz anda bozuksa, sonrasındaki her ölçüm geçersizdir — ve bu kontrol otuz saniye sürer.

Sonuçlar

Metrik	Yerel 27B VLM	Apple Vision
Karakter hatası	2	8
Okuma sırası	Korundu	Yok edildi
Düşen tablo hücresi	0	2
Geçen süre	82.8s (soğuk)	0.27s

Vision'ın sekiz hatası arasında IQ4_XS'i I04_XS olarak okumak, cloud'u iki kez cLoud olarak okumak, tok/s'yi tok/5 olarak okumak, bir kod dizgisindeki iki karakter, em dash'in tireye dönüşmesi ve bir ok işaretinin -> olarak çıkması vardı.

Kararı yazım değil, yapı belirledi

Vision tabloyu sütunlara göre ayrıştırılmış döndürdü: önce üç model adının tamamı, sonra bellek değerleri, hız ve durum sütunları ise belgenin sonuna eklenmişti. Karakterler doğru ve düzgün biçimlendirilmişti ama satır ilişkileri kaybolmuştu — bozulmamış, sadece yok olmuştu ve çıktıdan kurtarılamazdı. VLM satırları sağlam tuttu. Bunun yanında iki hata ile sekiz hata arasındaki fark, yazarın ifadesiyle bir yuvarlama farkıdır.

Yazı dersi dar çerçevede ortaya koyuyor: özel bir aracın genel bir aracı yenip yenemeyeceği tamamen görevi nereden böldüğünüze bağlı. Vision karakter tanımaya, belge anlamaya değil adanmıştır ve benchmark araçları ilk kritere göre seçerken iş ikincisini gerektiriyordu.

Neden önce-ucuz mimarisi çöküyor

Bariz mimari — ucuz motoru çalıştır, hatayı tespit et, pahalı olana yükselt — hatanın tespit edilebilir olmasını gerektirir. Sütunlara ayrıştırılmış çıktı sözdizimsel olarak kusursuzdur; makul metin içerir ve hiçbir hata sinyali vermez, dolayısıyla aşağı akıştaki (downstream) kod onu doğru bir okumadan ayırt edemez. Düşen bilgi hiçbir iz bırakmaz. Yazar bu noktayı OCR'nin ötesine genelleştiriyor: ister ucuz modelden pahalı modele ister cache'ten origin'e, her yükseltme merdiveni ancak ucuz kademenin hata modu sınırda gözlemlenebilir olduğunda sağlıklıdır. Aksi halde yanına bir maliyet tasarrufu eklenmiş, algılanmayan bir veri kaybı yoludur.

Homoglyph'ler iki motoru da yendi

Karşıt dizgide VLM tam görselden A0-1109-B8 üretti; 4 kat büyütülmüş bir kırpılmış görüntü ve 0/O ile 1/l'yi ayırması için açık bir talimat verildiğinde l'yi kurtardı ama O'yu yine kaybetti (A0-1l09-B8). Vision büyütülmüş kırpılmış görüntüde değişmedi. Yazar büyütülmüş görüntüyü inceledi ve fontun sıfırı çizgili, büyük O'yu düz bir oval olarak çizdiğini gördü — görünür şekilde farklı glifler; yani iki motor da gerçekten ayırt edilebilir bir karakteri yanlış okudu ve daha yüksek çözünürlük yardımcı olmuyor. Sonuç: homoglyph'lerin anlamı değiştirdiği dizgilerde — kodlar, kimlikler, hash'ler, adresler, lisans anahtarları — hiçbir OCR motoruna güvenilmemeli ve çözüm daha iyi bir motor değil, insan onayı veya bir checksum'dur.

Yazarın benimsediği yaklaşım

Vision ilk geçiş olarak kullanılıyor ve yalnızca okuma sırasının anlam taşıdığı belgelerde — tablolar ve formlar gibi — VLM'e yükseltiliyor; tek düzeltme şu: sütun parçalama aşağı akışta tespit edilemediği için, tablo ağırlıklı derlemler doğrudan VLM'e gitmeli ve 300 kat maliyeti göze almalı. Yazar hükmü değiştirecekleri de listeliyor: düz metin ağırlıklı belgelerde Vision tek başına yeterlidir ve Vision yerleşim analizi kazanmaya ve tablo yapısını korumaya başlarsa bu sonuç geçersiz olur. Homoglyph hatası iki motorda da ortak olduğundan, birini geliştirmek o kısmı etkilemez.

Neden önemli

Modelleri yerel olarak çalıştıran herkes için bu benchmark, başlık metriğine göre araç seçimi için faydalı bir düzeltmedir. 0.27 saniyede biten ücretsiz bir motor, belgeyi okumaya değer kılan ilişkileri sessizce çöpe atana ve bu hata aşağı akış doğrulamasına görünmez olana kadar bariz varsayılan gibi görünür. Görev belge anlama olduğunda hız ve hatta karakter doğruluğu yanlış eksenlerdir ve her önce-ucuz pipeline'ı kendi ucuz kademesinin hata ile değil ihmal ile başarısız olup olamayacağını sormalıdır.