Ajanlara "Yerel Gözler" Kazandırmak: PP-OCRv6 Tarayıcı Tabanlı OCR için Pratik Bir Kılavuz

Baidu Paddle yakın zamanda yeni nesil OCR modeli PP-OCRv6'yı resmi olarak yayınladı.

Üç model boyutu sunuyor: Tiny, Small ve Medium. 50'den fazla dil desteği ile tarayıcı tarafı, gömülü cihazlar ve sunucular dahil tüm senaryoları kapsıyor.

Temel Veriler:

• Metin algılama ve tanıma görev puanları: 86.2 ve 83.2
• Kapsamlı OCR performansında (algılama + tanıma) Dünya 1. Qwen3-VL-235B, GPT-5.5 ve Gemini-3.1-Pro gibi genel görsel-dil modellerini geride bırakıyor.
• Tiny model yalnızca 1.5MB boyutunda ve tek görsel tahmini 97ms'de (CPU) tamamlıyor, tarayıcı ortamlarında çalışabiliyor.
• UmiOCR ve MinerU gibi araçlara entegre edilmiş durumda, 82.200'ün üzerinde GitHub Yıldızına sahip.

Üç "cehennem gibi zor" görsel ile test ettim, ne kadar ileri gidebildiğini görmek için.

OCR tanıma oranınız %68 ise bu ne anlama geliyor?

Bir senaryo düşünün:

İçinde Çince ve İngilizce maddeler, sayısal tutarlar ve hukuki terminoloji bulunan bir mali sözleşme.

Tesseract kullanarak OCR çalıştırıyorsunuz ve tanıma oranı %68.

İçeriğin üçte biri yanlış.

Sonraki LLM analizi, risk çıkarımı ve otomatik arşivleme, hatalı verilere dayanarak körlemesine çalışıyor.

Bu, Tesseract'ın kendisiyle ilgili bir sorun değil.

Geleneksel açık kaynaklı OCR'ın ortak ikilemi: karmaşık düzenlerde (formüller, tablolar, damgalar, çoklu dil karışımı) metin tanıma oranları genellikle %70'in altına düşer. kaynak

Daha da kötüsü, şunu düşünebilirsiniz: "Neden OCR için GPT-5.5 kullanmıyorum?"

235B parametreyle, yüksek performanslı bir GPU'da tek bir görseli tanımak 2 saniye sürüyor, ücretli ve doğruluk oranı eh işte.

PP-OCRv6 ne yaptı?

Tiny model yalnızca 1.5MB ve tarayıcı tarafında (CPU) 97ms'de bitiyor. Medium model 34.5M parametreye, %90'ın üzerinde OCR tanıma doğruluğuna sahip ve metin algılama ile tanımada GPT-5.5 ile tüm geleneksel açık kaynaklı OCR'ı geride bırakıyor.

Veriler yalan söylemez:

Bu %10-20'lik puan farkı, "kullanılabilir" ile "kullanılamaz" arasındaki farktır.

Üç "cehennem gibi zor" görsel test ettim; işte sonuçlar.

Test 1: Koyu Arka Plan + Yoğun Küçük Metin

Bu, OCR için cehennem gibi zorluktur.

Test için teknoloji tarzı bir poster aldım—koyu neon arka plan, parlayan veri panelleri, yoğun Çince-İngilizce karışımı ve çeşitli yazı tipi boyutları birbirine karışmış durumda.

Bu tür bir görsel, birçok OCR'ın feci şekilde başarısız olduğu yerdir.

Test Sonuçları:

✅ Ana başlıklar "Mastering Codex", "Master 97% of functions in 30 minutes" — Parlayan yazı tipleri, tek bir karakter bile kaçırılmamış

✅ Küçük etiketler "14 steps", "Skills", "MCP Connection" — Koyu arka planda küçük metin, hepsi eksiksiz

✅ İstatistiksel rakamlar "98%", "1200+", "85%" — Hiçbiri kaçırılmamış

✅ "Efficient Intelligent Data Processing Capability" gibi alt detaylar — En küçük yazı boyutu bile tanınmış

✅ Çince-İngilizce karışımı, tek bir modelle tek seferde tamamlanmış

Tanıma Hızı:

Çevrimiçi tanıma yaklaşık 1-2 saniye sürdü (ağ yükleme süresi dahil)

Sonuç: Karmaşık arka plan + parlama efektleri + ultra küçük metin + Çince-İngilizce karışımı; dört zorluğu aynı anda ele aldı. "Görüşü", bir Ajan'ın gözleri olarak hizmet edecek kadar iyi.

Test 2: Mali Faturalar

Bu gerçek bir iş senaryosu.

Sonra, bir KDV faturası test ettim—işletmeler için en yaygın OCR gereksinimi ve verilerin kesinlikle dışarı gönderilemeyeceği senaryo.

Tanıma Etkisi:

✅ Fatura Kodu/Numarası 031002200711, 59905674 — Ultra küçük yazı tipi, %100 doğru

✅ Karmaşık sayısal dize 1+3-887•97•-9642-6-62967770 — Özel semboller içeren uzun dize, tek bir hata yok

✅ Para miktarları ¥535.00, ¥504.72, ¥30.28, Vergi Oranı %6 — Hassas tanıma

✅ Şifre alanındaki uzun rastgele karakter dizisi — Tamamen yeniden oluşturuldu

✅ Alıcı/Satıcı adları, vergi kimlikleri, adresler ve telefon numaraları — Hepsi doğru

✅ Kırmızı damganın içindeki metin de tanındı (kırmızı dairenin girişimine rağmen)

En şaşırtıcı kısım:

Fatura üzerindeki son derece küçük yazı boyutları (muhtemelen sadece 8-10 punto), yoğun sayılar ve özel semboller (•, -, +) PP-OCRv6 tarafından doğru bir şekilde tanındı. Bu hassasiyet seviyesine geleneksel OCR ile ulaşılamaz.

Anahtar Keşif: Yapısal Çıkarma Yeteneği

Her alanın koordinat konumlarını döndürebilir, yani doğrudan yapılandırılmış çıkarma yapabilirsiniz:

1// Koordinat konumuna göre alan türünü belirle
2results.forEach(item => {
3  if (item.box.y < 100) {
4    // Üst alan → Fatura kodu/numarası
5  } else if (item.text.includes('¥')) {
6    // Para birimi sembolü içeriyor → Tutar alanı
7  }
8});

Bu yetenek, PP-OCRv6'nın yalnızca "metni görmesine" değil, aynı zamanda "belge yapısını anlamasına" da olanak tanır. Bu, OCR'dan Belge Yapay Zekasına doğru önemli bir adımdır.

Test 3: El Yazısı Notlar

Sıra stres testinde.

Son olarak, bir el yazısı notu test ettim—geleneksel bir OCR zorluğu. Dağınık el yazısı, birleşik vuruşlar ve kağıt kıvrımları.

Test Sonuçları:

✅ Tarih tanıma "August 30, 2025" — Tamamen doğru

✅ El yazısı metin gövdesi "Stayed at home all day today, missed dancing twice" — "那"nın dağınık yazısı bile tanındı

✅ Tadilat listesi tamamen tanındı:

• "Hard decoration 109k," "3 ACs: 26k," "3 Glass: 11.5k"
• "Appliances 180k," "Water heater: 3000"
• "Stove/Hood: 7000," "Washer/Dryer: 5000"
• "Fridge 3000" ✅ Karmaşık sayılar "Sent 44k today (including fridge)," "Current: 214.5k" — El yazısı sayılar ve tutarların tümü doğru tanındı

Tanıma Oranı Değerlendirmesi:

• Düzenli el yazısı: Yaklaşık %90 tanıma oranı
• Anahtar bilgiler (tarihler, proje adları, tutarlar): Neredeyse %100
• Dağınık bitişik eğik yazı kısımları: Yaklaşık %70-80 tanıma oranı, ancak genel anlayışı etkilemez

Beklenmedik Keşif:

El yazısında bile PP-OCRv6, yapılandırılmış bilgiler (tarihler, tutarlar, listeler) için güçlü tanıma yeteneklerine sahiptir. Bu, el yazısı formlar, faturalar ve toplantı notları için kullanılabileceği anlamına gelir—anahtar alanları yakaladığı sürece %100 doğru olması gerekmez.

Sonuç:

PP-OCRv6 her şeye gücü yeten değildir; aşırı dağınık el yazısı hala bir zorluktur. Ancak, düzenli el yazısı, basılı metin, net ekran görüntüleri ve taramalar için performansı ticari sınıfa ulaşmıştır.

Hangi senaryolar yerelleştirilmelidir?

PP-OCRv6'nın uygulama senaryoları kurumsal ofisler, sağlık hizmetleri, eğitim/araştırma, geliştirici araçları, devlet arşivleri, e-ticaret ve finans/sigorta sektörlerini kapsar.

İşte birkaç tipik senaryo.

💼 Kurumsal Ofis: Otomatik Harcama Geri Ödemesi

Bir ilaç şirketi, PP-OCR'ı entegre ettikten sonra seyahat masrafları geri ödeme süresini 5.3 günden 4.2 saate düşürdü. kaynak

Süreç:

Çalışan faturayı yükler → Tarayıcı tarafı alan çıkarma (tutar, tarih, satıcı) → Kural doğrulama → İstisnalar LLM'ye gönderilir → Otomatik giriş.

Neden yerelleştirilmelidir?

Mali belgeler tedarikçiler, fiyatlar ve maliyet yapıları gibi operasyonel veriler içerir; bunları üçüncü taraf bir API'ye yüklemek bir uyumluluk kırmızı çizgisidir. Yerelleştirme, verileri tarayıcı içinde tutar.

🏥 Sağlık Hizmetleri: Elektronik Tıbbi Kayıtlar

Tıbbi kayıtlar hasta mahremiyeti (isim, kimlik, durum) içerir ve genel buluta yüklenemez.

Çözüm Karşılaştırması:

• Geleneksel özel dağıtım: Yüksek maliyet, ağır bakım
• PP-OCRv6 Tarayıcı Tarafı: Doğrudan çalışır, sıfır sunucu maliyeti

Süreç:

Tarayıcı tıbbi kayıt görselini yükler → Yerel OCR tanıma → Veriler duyarsızlaştırıldıktan sonra saklanır. Orijinal veriler asla operatörün bilgisayarını terk etmez.

⚖️ Hukuki Sözleşmeler: Ticari Sır Koruması

Hukuk bürosu yapay zeka asistanlarının sözleşme maddelerini (taraflar, tutarlar, şartlar, sorumluluk) çıkarması gerekir. Ancak sözleşmeler, müşterilerin temel ticari sırlarıdır.

Yerelleştirilmiş Süreç:

Sözleşme taramasını yükleyin → Tarayıcı tarafı OCR tam metni çıkarır → Yerel LLM madde çıkarma işlemini gerçekleştirir → İnceleme raporu oluşturun. Veriler asla avukatın iş istasyonunu terk etmez, böylece avukat-müvekkil gizlilik anlaşmaları karşılanır.

Bu senaryoda, yerelleştirme "mümkün" ile "imkansız" arasındaki farktır.

Gerçek Geri Bildirim:

PP-OCRv6'ya yükselten bir hukuk bürosu geliştiricisi şunları bildirdi: "Hız ve etki V5'ten gerçekten çok daha iyi." Dava dosyalarının biçim temizliği ve duyarsızlaştırılması için doğrudan kullanılıyor. kaynak

💻 Geliştirici Araçları: Ekran Görüntüsünden Metne

Geliştiricilerin genellikle tasarım çizimlerinden, belgelerden veya günlüklerden metin çıkarması gerekir. Bulut API'lerinde ağ gecikmesi (200-500ms), çağrı limitleri vardır ve kod parçacıkları harici iletim için uygun değildir.

Yerelleştirilmiş Deneyim:

Ekran Görüntüsü → Kısayol Tuşu → Yerel Tanıma → Yapıştır. Tüm süreç 200ms sürer ve internet gerektirmez. OCR, "API bekleme" durumundan "kısayol tuşuna basma" durumuna geçerek iş akışının bir parçası haline gelir.

📚 Daha Fazla Senaryo

Eğitim/Araştırma: Not verme yardımı, akademik literatür sayısallaştırma, el yazısı not düzenleme.

Devlet Arşivleri: Tarihi arşiv sayısallaştırma, kimlik bilgisi çıkarma, belge akışı.

E-ticaret: Ürün bilgisi girişi, lojistik belge tanıma, fatura doğrulama.

Finans/Sigorta: Poliçe bilgisi çıkarma, banka dekontu tanıma, risk kontrol materyali işleme.

Tam Bir Yerelleştirilmiş Ajan Döngüsü

PP-OCRv6'nın değeri yalnızca "doğru tanıma" değildir. Aynı zamanda "bu tanıma adımının internet gerektirmemesidir."

Tarayıcıda çalışmak, bir verinin asla yerelden ayrılmadığı döngü oluşturabileceğiniz anlamına gelir:

1Yerel Görsel/Ekran Görüntüsü
2   ↓
3PP-OCRv6 (Tarayıcı Tarafı, 97ms)   ← Veri bu makineden ayrılmaz
4   ↓
5Yapılandırılmış Metin
6   ↓
7Yerel LLM / Yerel Kural İşleme
8   ↓
9Otomatik Kategorizasyon / Form Doldurma / Depolama

Bu döngüde, hem görsel hem de tanıma sonuçları kullanıcının cihazında kalır. Hassas belgelerin olduğu senaryolar için bu yalnızca "daha iyi" değil, "mümkün" ile "imkansız" arasındaki farktır.

Daha önce, bu tür gereksinimler pahalı özel dağıtımlar gerektiriyordu; şimdi sadece bir tarayıcı açıp çalıştırabilirsiniz.

"Ajanlara yerel gözler vermek" ifadesinin gerçek anlamı budur: Ajanlar nihayet "görebilir" ve görme süreci gözlerini bir başkasına ödünç vermeyi gerektirmez.

Nasıl kullanılır? Üç entegrasyon yöntemi

Yöntem 1: Çevrimiçi Deneyim (0 dakikada başla)

En hızlı yol, paddleocr.com adresini ziyaret etmek ve etkiyi görmek için bir görsel yüklemektir.

Uygun: Yetenekleri hızla doğrulamak, belirli görselleri test etmek için.

Sınırlama: Veriler sunucuya yüklenir, hassas içerik için uygun değildir.

Yöntem 2: Tarayıcı Tarafı Entegrasyonu (Önerilen)

Yerelleştirme gerektiren web uygulamaları için PaddleOCR.js'yi doğrudan entegre edin:

1// 1. Kurulum
2npm install paddleocr-js
3
4// 2. Modeli başlat
5import { createOCR } from 'paddleocr-js';
6const ocr = await createOCR({
7  detPath: '/models/det_tiny.onnx', 
8  recPath: '/models/rec_tiny.onnx',
9  dictPath: '/models/dict.txt'
10});
11
12// 3. Görseli tanı
13const results = await ocr.recognize(imageElement);

Anahtar Avantajlar:

• Model dosyaları bir kez yüklenir; sonraki tanıma ağ gerektirmez.
• Tek görsel tanıma 97ms'den başlar (CPU, resmi veri).
• İnce taneli düzen restorasyonu için tek karakter koordinatlarını döndürmeyi destekler.

Uygun: Tarayıcı uzantıları, Web uygulamaları, Electron masaüstü uygulamaları. kaynak

Yöntem 3: Python Yerel Dağıtımı (Yüksek Hassasiyetli Senaryolar)

Maksimum hassasiyet veya toplu işleme gerektiren senaryolar için Python SDK'yı kullanın:

1# 1. Kurulum
2pip install paddleocr paddlepaddle
3
4# 2. En yüksek hassasiyet için orta sürümü kullan
5from paddleocr import PaddleOCR
6ocr = PaddleOCR(use_angle_cls=True, lang='ch')
7
8# 3. Toplu tanıma
9result = ocr.ocr('invoice.jpg', cls=True)

Gelişmiş Kullanım:

• Alan çıkarma için NER modelleriyle birleştirin.
• Tam belge anlama Ajanları oluşturmak için yerel LLM'lere bağlanın.
• Ekip paylaşımı için dahili bir API olarak FastAPI ile sarın.

Uygun: Sunucu tarafı toplu işleme, yüksek hassasiyet gereksinimleri, ikincil geliştirme. kaynak

Teknik Derinlemesine: Neden 34.5M'lik bir OCR modeli 235B'lik genel bir modelden daha doğru?

Büyük modellerin yüz milyarlarca parametreye sahip olduğu bir çağda, PP-OCRv6 yalnızca 34.5M parametre ile Qwen3-VL-235B, GPT-5.5 ve Gemini-3.1-Pro'dan daha yüksek doğruluk elde ediyor. Nasıl?

Birleşik Temel: İki görev için tek bir mimari

PP-OCRv6'nın temel yeniliği, hem algılama hem de tanıma için kullanılan LCNetV4 omurga ağıdır.

İşlem arasındaki fark:

• Algılama: Özellikleri çıkarmak ve metni bulmak için normal görsel ölçekleme.
• Tanıma: Metin görselini bir diziye dönüştürerek karakter karakter okumak için yüksekliği sıkıştırırken genişliği korur.

Aynı mimari kodu üç boyuta (Tiny/Small/Medium) hizmet eder, geliştirme ve bakım maliyetlerini önemli ölçüde azaltır.

Neden önemli: Bu "birleşik temel" tasarımı, geleneksel ikili bağımsız ağlardan daha hafif ve daha güçlüdür.

Daha Doğru Algılama: Büyük Alıcı Alanlı Özellik Piramidi

PP-OCRv6, "görüş alanını" 3x3'ten 7x7'ye genişleten büyük bir alıcı alanlı özellik piramidi kullanır.

Etki: Daha az parametre, ancak küçük ve yoğun metinlerin algılanmasında önemli ölçüde iyileşme.

Daha Güçlü Tanıma: Hafif Dikkat + Tek Modelde 50 Dil

Tanıma kısmı, karakterler arasındaki bağlamı anlamak için hafif bir dikkat modülü eklerken, sözlük aksanlı yaklaşık 200 karakter genişletildi.

Anahtar Atılım: Tek bir model, her dil için model değiştirmeye gerek kalmadan Çince, İngilizce, Japonca ve 46 Latin kökenli dili—toplam 50 dil—tanıyabilir.

Neden önemli: Çok dilli karışık senaryolar (Çince maddeler içeren İngilizce sözleşmeler gibi) için niteliksel bir sıçramadır.

Performans Verileri: Uzmanlaşmış Modellerin Avantajı

PP-OCRv6_medium yalnızca 34.5M parametreye sahiptir, ancak PaddleOCR ekibinin dahili çok senaryolu testlerinde OCR metin tanıma doğruluğu Qwen3-VL-235B (235 milyar parametre), GPT-5.5 ve Gemini-3.1-Pro'yu geçmiştir. kaynak

Neden? Uzmanlaşmış modeller, dikey görevler için genel büyük modellerden daha verimli olmaya devam ediyor. VLM'ler belge anlama, akıl yürütme ve üretimi dengelemelidir; OCR yalnızca bir alt görevdir. PP-OCRv6, mimariden veri eğitimine kadar yalnızca "metni net görmek" için optimize edilmiştir.

Anahtar Veriler:

• Tanıma doğruluğu %83.2, önceki nesle göre %5.1 arttı.
• Algılama Hmean'i %86.2, önceki nesle göre %4.6 arttı.
• GPU çıkarım hızı 2.37 kat arttı.

VLM'lerin Ölümcül Kusuru: Halüsinasyon Düzeltmesi

VLM'ler gibi çok modlu modellerin OCR işleme sırasında ölümcül bir kusuru vardır: dil önceliklerine dayalı "halüsinasyon düzeltmesi."

Örneğin: Görsel "Welcme" (yazım hatası) diyorsa, GPT-5.5 bunu "akıllıca" "Welcome" olarak düzeltebilir.

Karakter karakter restorasyon gerektiren senaryolar (hukuki belgeler, kod ekran görüntüleri, ürün seri numaraları) için bu "akıllılık" felakettir.

Veri Karşılaştırması:

• PP-OCRv6 Tam Eşleşme Oranı: %93.2 — Görseldeki her karakteri sadık bir şekilde yeniden oluşturur.
• Qwen3-VL-235B Tam Eşleşme Oranı: %80.6 — Görselde olmayan metinleri "doldurmaya" eğilimlidir.

Bu %12.6 puan farkı, hassas restorasyon gerektiren senaryolarda uzmanlaşmış hafif modellerin genel büyük modellerden daha güvenilir olduğu anlamına gelir.

PP-OCRv6'nın tasarım felsefesi, dil modellerine dayanarak tahminler yapmadan "görsel içeriği sadakatle yeniden oluşturmak"tır. Resmi karşılaştırmalar, endüstriyel karakterler, nokta vuruşlu metin veya lastik izleri ile uğraşırken VLM'lerin belirgin halüsinasyonlar ürettiğini, PP-OCRv6'nın ise orijinal karakterleri doğru bir şekilde tanıdığını göstermektedir. kaynak

Üç Model İçin Seçim Tavsiyesi

PP-OCRv6, uç cihazlardan sunuculara kadar her şeyi kapsayan üç kademe sağlar.

Seçim Tavsiyesi: Tarayıcı tarafı Ajanlar Tiny/Small ile başlamalıdır (yeterli ve hızlı yüklenir); arka uç toplu işleme için Medium kullanın. kaynak

Maliyet Karşılaştırması

Bulut API'leri kullanım başına ödemelidir (ayda 100k görsel için yaklaşık 200-1500 RMB), yerelleştirilmiş modeller ise ücretsiz, açık kaynaklıdır, sıfır çalışma maliyeti vardır, eşzamanlılık limiti yoktur ve çevrimdışı çalışır.

Son Olarak

OCR yıllardır rekabetçidir; doğruluk artık kıt bir meta değildir. Kıt olan şey, verilerinizi teslim etmeden metni net görmektir.

PP-OCRv6 bunu tarayıcıda 97ms'lik bir çağrı haline getirir (Tiny model, CPU). Ajanlar oluşturanlar için bu, "görsel okuma" yeteneğinin nihayet "sıfır veri sızıntısı" vaat eden bir ürüne dahil edilebileceği anlamına gelir.

Ajanınıza yerel gözler vermek, o tek satırlık bulut OCR çağrısını değiştirmekle başlayabilir.

İlgili Kaynaklar

• PaddleOCR Resmi Sitesi: paddleocr.com
• GitHub: github.com/PaddlePaddle/PaddleOCR
• HuggingFace: huggingface.co/collections/PaddlePaddle/pp-ocrv6
• Çevrimiçi Deneyim: paddleocr.com (Doğrudan görsel yükleyerek test etmeyi destekler)

Teknik Makale: PP-OCRv6: 1.5M'den 34.5M Parametreye, OCR Görevlerinde Milyar Ölçekli VLM'leri Geride Bırakmak (arXiv:2606.13108)

👉 Bu makale yardımcı olduysa, lütfen beğenin, paylaşın ve kaydedin!