Unlimited OCR — Baidu’nun tek seferlik uzun belge ayrıştırma modeli

 (github.com/baidu)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • DeepSeek OCR temel alınarak dekoderdeki tüm attention katmanları değiştirilmiş, onlarca sayfalık belgeyi tek bir ileri geçişte (forward pass) metne döken uçtan uca bir OCR modeli
  • Temel fikir referans kayan pencere attention’ı (R-SWA); böylece çözümleme uzunluğu artsa da KV cache sabit tutuluyor ve bellek/hesaplama maliyetindeki artış engelleniyor
  • Kitap kopyalayan insanın çalışma belleğini (working memory) taklit ederek, uzaktaki çıktıları yumuşak biçimde unutup yalnızca yakın bağlama başvuran bir yaklaşım benimsiyor
  • OmniDocBench v1.5’te %93 ile DeepSeek OCR’a göre %6 üstünlük sağlıyor, v1.6’da %93,92 ile uçtan uca SOTA seviyesine ulaşıyor
  • R-SWA, OCR’ın ötesinde ASR ve çeviri gibi referans tabanlı uzun bağlam görevlerine de uygulanabilecek genel amaçlı bir ayrıştırma attention mekanizması

Arka plan ve problem tanımı

  • İnsanlar yüzlerce sayfalık transkripsiyon ya da saatler süren ses çevirisi gibi uzun görevleri verim düşmeden yapabilirken, mevcut OCR modelleri tek bir ileri geçişte 10 sayfayı bile ayrıştıramıyor
    • Güncel modeller sayfa başına işleme (for-loop) yöntemi kullanıyor ve her adımda belleği sıfırlıyor
    • Bu yaklaşım, tutarlı uzun bir süreci birbirinden kopuk kısa görevler hâline bölen bir mühendislik geçici çözümü; AGI yönelimli zekâ açısından gerçek bir ilerleme değil
  • Dekoder olarak LLM kullanıldığında dilin ön dağılımından yararlanıldığı için performans artıyor, ancak çıktı uzadıkça biriken KV cache bellek tüketimini büyütüyor ve üretim hızını kademeli olarak düşürüyor
  • İnsanın transkripsiyon davranışı ne standart full attention ne de linear attention ile örtüşüyor
    • Daha önce yazılmış tüm metni yeniden taramak yerine, yönünü korumak için yalnızca yakın bağlama başvuruyor
    • Görsel/referans token’ları döngüsel durum güncellemesi almaz; güncellenirse görsel özellikler giderek bulanıklaşır ve tanıma doğruluğu düşer

Reference Sliding Window Attention (R-SWA)

  • Her token tüm referans token’larına (görsel token’lar + prompt) erişirken, çıktı attention’ı yalnızca önceki n token ile sınırlandırılıyor (varsayılan 128)
    • Bu sayede her token tüm görüntünün farkında olurken, nedensel kayan pencere içindeki durum geçişiyle OCR ilerlemesini kendi kendine takip ediyor
    • Çıkarım sırasında KV cache sabit tutularak bellek baskısı azaltılıyor ve hesaplama maliyeti düşürülüyor
  • Attention, boyutu m+n olan iki bölmeli bir pencereyle sınırlandırılıyor
    • m, görsel token’lar ve prompt’u içeren prefix penceresi; tek bir çıkarım boyunca sabit kalıyor ve yalnızca sayfa sayısı ile çözünürlüğe bağlı, çözümleme uzunluğundan bağımsız
    • n ise çözümleme bölgesindeki pencere; boyutu sabit kalırken nedensel olarak kayıyor

  • KV cache yönetimi

    • DeepSeek OCR taban çizgisi standart MHA kullandığı için KV cache boyutu Lm + T olarak sınırsız büyüyor
    • R-SWA, tüm prefix cache’i Lm olarak korurken üretilen kısımda yalnızca son n token’ı saklıyor; cache boyutu Lm + min(n,T) ≤ Lm + n ile sabit üst sınıra sahip oluyor
    • Çıktı uzunluğu yeterince arttığında cache oranı ρ(T) sıfıra yaklaşıyor → doğrusal artış sabit bir değere indirgeniyor

  • Çekirdek analizi

    • Flash Attention v3 çekirdek ölçümlerinde DeepSeek OCR’ın standart MHA’sinde çözümleme adımı başına gecikme artarken, Unlimited OCR R-SWA sayesinde süreyi sabit tutuyor
    • DeepSeek OCR’da KV cache uzunluğu belirli hizalama sınırlarını geçtiğinde veri aktarım verimliliği keskin biçimde düşerek sıçramalar oluşuyor; R-SWA’da bu görülmüyor
    • Çıkarım sırasında GPU belleği de orijinal modelde doğrusal artarken, Unlimited OCR’da sabit kalıyor — hesaplama ve bellekteki bu eşzamanlı istikrar uzun belge ayrıştırmayı mümkün kılıyor

Model mimarisi

  • Temel olarak DeepSeek OCR alınmış; DeepEncoder ile MoE dekoderi (toplam 3B, etkin 500M parametre) birleştirilmiş
    • Mevcut MHA, R-SWA ile değiştirilmiş; referans KV cache’i m’ye sabit kapasiteli çıktı KV tamponu n eklenerek uzun belge ayrıştırma sağlanmış
    • KV cache, m+n kapasiteli bir kuyruk olarak uygulanıyor; her yeni token üretiminde (m+1). token’ın KV’si dışarı atılarak maliyet ve belleğin artmaması garanti ediliyor

  • DeepEncoder

    • SAM-ViT ile CLIP-ViT art arda kullanılıyor; köprü bölümünde 16 kat token sıkıştırması uygulanıyor — ilk bölüm pencere attention’ı ile ham görüntü token’larını işlerken, global attention yalnızca sıkıştırılmış token’lara ayrılıyor
    • Yüksek çözünürlüklü görüntü kodlamasında aktivasyonları düşük tutarak GPU belleğinden tasarruf ediyor; 1024×1024 PDF görüntüsünü yalnızca 256 token’a sıkıştırıyor
    • Çok sayfalı kullanım için "Base" (1024×1024) ve tek sayfa için "Gundam" (dinamik çözünürlük) olmak üzere iki mod benimsenmiş
    • Görsel token’lar çıktıyla birlikte durum geçişi yaşamıyor; bir kez kodlanıyor ve tüm süreç boyunca statik kalıyor

Eğitim ayarları

  • Yaklaşık 2 milyon belge OCR verisiyle eğitilmiş; tek sayfa/çok sayfa oranı 9:1
    • Tek sayfalık PDF’ler Paddle OCR ile etiketlenmiş, her bloğun koordinatı ve içeriği birleştirilerek ground truth oluşturulmuş; koordinatlar 0–1000 aralığında normalize edilmiş
    • Çok sayfalı veri, tek sayfaların birleştirilmesiyle sentezlenmiş; yaklaşık 200 bin örnekte (2–50 sayfa) <page> ayıracı kullanılmış ve tüm veri 32K token dizilerine paketlenmiş
  • DeepSeek OCR checkpoint’inden başlayarak 4.000 adım ek eğitim yapılmış; global batch 256, azami dizi 32K, 8×16 A800 GPU kullanılmış
    • Eğitim sırasında DeepEncoder dondurulmuş ve yalnızca LLM parametreleri eğitilmiş
    • AdamW optimizer, cosine annealing scheduler, başlangıç öğrenme oranı 1e-4, DeepEP (EP=4) ve Megatron-LM çatısı kullanılmış
    • Çıkarım tarafında Transformers kütüphanesine R-SWA için KV cache yönetimi eklenmiş, SGLang motoruna da optimizasyon desteği verilmiş — her iki çatı da sabit TPS ve GPU belleğiyle çalışıyor

Değerlendirme sonuçları

  • Ana benchmark OmniDocBench(v1.5/v1.6); metin, formül, tablo yapısı ve okuma sırası gibi çok boyutlu ayrıştırma yeteneğini değerlendiriyor
    • v1.6, v1.5’e göre 296 ek test görseli içeren en güncel sürüm; v1.5 ise DeepSeek OCR dâhil klasik modellerle karşılaştırma sağlıyor
    • Uzun belge OCR değerlendirmesi için roman, belge ve makaleleri 2/5/10/20/40+ sayfa olarak ayıran özel bir test kümesi kurulmuş (her kategoride 10’dan fazla eser)

  • Başlıca performans

    • Yalnızca 2M ek veri eğitimiyle uçtan uca SOTA elde edilmiş; v1.5’te metin düzenleme uzaklığı 0.035 azalmış, tablo TEDS %5,96 iyileşmiş
    • v1.6 genel göstergede %93,92 ile uçtan uca SOTA — genişliği 128 olan R-SWA ile standart attention’ın tamamen değiştirilmesinin etkili ve kayıpsız olduğu gösterilmiş
    • MoE’de etkin 0.5B parametre ile yüksek verimli çıkarım sağlanmış; "Base" modunda 5580 TPS (DeepSeek OCR’ın 4951 TPS değerine göre %12,7 hız artışı)

  • Alt kategori analizi

    • DeepSeek OCR’a kıyasla tüm metriklerde tutarlı iyileşme görülerek adeta bir "bedava öğle yemeği (free lunch)" düzeyinde kazanım sergilenmiş
    • DeepSeek OCR 2’ye karşı metin düzenleme uzaklığı ve okuma sırası ölçütlerinde 9 ölçümün 7’sinde üstünlük sağlanmış
    • PPT, gazete, dergi ve not gibi karmaşık düzenlerde de geri kalmıyor

  • Uzun belge ayrıştırma

    • R-SWA sayesinde onlarca ila yüzlerce sayfa tek geçişte prefill edilebiliyor; ilk sayfadan son sayfaya kadar kesintisiz ayrıştırma yapılırken KV cache sabit kaldığı için çıktı gecikmesi de sabit kalıyor
    • 20 sayfanın aynı anda girildiği durumda da sağlam sonuçlar veriyor; 40+ sayfada düzenleme uzaklığı 0.11’in altında, Distinct-35 %97 olarak korunuyor
    • Tekrarlama hataları, çok sayfalı "Base" modunda (1024×1024) küçük yazıların ayırt edilmesindeki zorluktan kaynaklanıyor; R-SWA’nın yön kaybetmesinden değil

Verimlilik analizi

  • İdeal eşzamanlılık koşullarında çıktı TPS karşılaştırması (prefill uzunluğu 10’a sabitlenmiş)
    • 256 token’da iki modelin çıkarım hızı neredeyse aynı
    • Çıktı uzunluğu arttıkça DeepSeek OCR’ın TPS değeri düzenli biçimde düşüyor; 6.000 token’da Unlimited OCR’un %35 gerisine düşüyor
    • Tutarlı üretim hızının uzun belge OCR görevleri için temel gereksinim olduğu yeniden doğrulanıyor

Sınırlamalar ve sonraki adımlar

  • Sonlu bağlam uzunluğu (ör. 32K) nedeniyle prefill uzunluğu kısıtı altında gerçek anlamda sınırsız ayrıştırma henüz mümkün değil — DeepEncoder’ın yüksek sıkıştırma oranına rağmen sayfalar biriktikçe prefill uzuyor
  • Kısa vadede 128K gibi daha uzun bağlamlı modeller eğitilerek daha fazla sayfanın prefill edilmesi planlanıyor
  • Uzun vadede prefill pool oluşturulup modelin prefill KV parçalarını otomatik fetch etmesi öğretilerek, insanın sayfa çevirme etkisi taklit edilip gerçek sınırsız OCR’a ulaşılması hedefleniyor
  • R-SWA’nın ASR ve çeviri gibi referans tabanlı görevlere aktarılması da planlanıyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Oldukça ilginç. Anladığım kadarıyla araştırmacılar, yapay zekanın uzun belgeleri okurken belleği durmadan biriktirmesini engelleyen bir mimari hilesi bulmuş gibi görünüyor
    Normalde yapay zeka 100 sayfalık bir PDF'yi yazıya dökerken daha önce okuduğu tüm kelimeleri hatırlamaya çalışıyor ve bu kısa süreli bellek olan KV cache O(N) olarak doğrusal biçimde büyüyerek VRAM'in tükenmesine ya da sınırlara takılmasına yol açıyor. Bu yüzden geliştiriciler PDF'yi sayfalara bölüp işledikten sonra yeniden birleştiren kaba kodlar yazmak zorunda kalıyor
    Unlimited OCR, odağı Reference Sliding Window Attention (R-SWA) ile iki yola ayırıyor. Biri, özgün belge görüntüsünü bütünüyle gören küresel referans; diğeri ise modelin doğrudan ürettiği metin belleğini son 128 kelime gibi dar bir kayan pencereyle sınırlayan yerel üretim. Yerel yapay zeka için epey ilginç olabilir; topluluğun bununla neler inşa edip nasıl genişleteceğini merak ediyorum

    • Bunun konuşmalar için de tam oturan bir yanı var gibi. Uzun süredir uzun konuşmaları kapsülleme fikrini deniyorum; çok değişmeyen üst düzey bağlam ve gerçekler var, katılımcı adları ya da arka plan gibi bilgiler buna giriyor
      Buna karşılık bugün sabah ne yendiği gibi çok ince ayrıntılı gerçekler şu anda faydalı olabilir ama uzun vadede genel eğilimler dışında pek anlam taşımıyor. Konuşmayı yeniden kurmak için şimdiye kadar tartışılan her şeyi geri çağırmadan doğru dengeyi bulmak gerekiyor; bu yüzden bu yaklaşım daha yakından incelenmeye değer görünüyor
    • Makalenin tamamını henüz okumadım ama yerel üretim penceresi biraz küçük görünüyor. Özellikle görüntü girdileri çok token tükettiği için, yerel attention katmanının nerede olduğuna bağlı olarak en az 4096 kelime kadar daha büyük olması iyi olurdu
    • Görüntü OCR'ı yaparken tam olarak bunu yapıyorum. Büyük bir görseli birkaç küçük görsele bölüp LLM'e gönderdiğimde her seferinde kusursuzdu, ama tüm görseli tek parça verdiğimde sonuçlar berbattı
    • Başlıca LLM araçlarının zaten sliding window attention desteği sunduğunu sanıyordum
    • LeetCode'un işe yaramasının nedeni bu. Sürekli LeetCode çözdükçe bu tür tekniklerin neden var olduğunu ve pratikte nasıl kullanıldığını görmeye başlıyorsun. İlginç çok şey var

  • Kısa süre önce nota için bir tablet aldım; asıl amacım jam session’larda caz Real Book ciltlerinin yerini almasıydı. Telefon kamerasıyla tarananlar idare eder ama boyut sabit ve üzerinde çok fazla kusur var
    Bb ya da Eb enstrümanlar için anında transpoze edebilse güzel olurdu, ama tarama olduğu için doğal olarak bu mümkün değil. Optik nota tanıma durumunu biraz kurcalayınca, müziğin AI açısından neredeyse tamamen keşfedilmemiş bir alan olduğu sonucuna vardım. Optik nota tanıma epey kötü, AI’ın müzik teorisini anlama düzeyi de gerçek notaya bakma alanında oldukça zayıf. LLM’ler, muhtemelen internetteki metinlerden eğitime girmiş teorik kavramların metinsel açıklamalarını ise fena olmayan bir şekilde yapıyor
    Sorun galiba müzisyenlerin kağıt üzerindeki noktaları okuduğu biçimi doğru kodlayacak dijital formatın hâlâ yetersiz olmasında. Nota yazımı oldukça zengin. MIDI esas olarak çalma ya da performans için gereken yönleri taşımak üzere tasarlandığından, simgesel kavrayış için gereken her şeyi içermiyor. MusicXML, müzisyenlerin istediği bilgiyi taşıyan dijital formata en yakın görünen şey, ama MusicXML gösterimiyle nota görüntüsü ya da sesi arasında bağ kuran iyi bir eğitim korpusu eksik. Muhtemelen bunun sebebi, MusicXML’in tek başına nota dizgisi için gereken bilgiyi yeterince taşımaması
    MuseScore gibi araçların, MusicXML ile ifade edilemeyen çok sayıda yerleşim bilgisini takip etmesi gerekiyor. LilyPond formatı MusicXML’den daha az ayrıntılı yazılıyor ve nota hazırlayanlar için faydalı biraz daha fazla bilgi taşıyor, ama çoğu kişi notayı LilyPond ile oluşturmuyor. Ek olarak, caz fontlarının durumu yüzünden LilyPond biraz hayal kırıklığı yaratıyor. Caz bağlamında “klasik usulü” nota görmek istemiyorum. OCR’da hoş görünen kademeli iyileştirmeleri her gördüğümde OMR’nin içler acısı hâli aklıma geliyor

    • Müzikologlar ve müzik araştırmacılarının kullandığı format MEI: https://music-encoding.org/ ve fiili dizgi aracı verovio: https://www.verovio.org/index.xhtml
      verovio, özgün MEI notalarının bilgisini mümkün olduğunca koruyarak SVG formatında dizgi yapabildiği için, derin öğrenme modelleri için gerçek tespit veri setleri oluşturacak kadar metadata çıkarabiliyor. verovio ile dizilmiş nota setlerinden COCO veri seti üretmek için kabaca hacklenmiş bir script de var: https://github.com/kwon-young/music/blob/main/svg2pl.py
      Burada oluşturulan sentetik nota veri seti de yayımlandı: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... Bunun üzerinde dedektör eğitmek isteyenler buyursun. OMR’nin bu kadar ihmal edilmesinin nedeni, çoğu kişinin bu işin zorluğunu ciddi biçimde hafife alması. Son derece çeşitli biçimlerle çok karmaşık bir grafik dilbilgisinin birleştiği özel bir iş
    • “Müzik, AI’ın baktığında neredeyse her yerde keşfedilmemiş bir alan” sözü gerçekten doğru. Kız arkadaşım müzikoloji okuyor; fiziksel engeli nedeniyle bazen not almak zor geliyor, ben de yardımcı olmak için AI tabanlı TTS/OCR gibi ufak uygulamalar yapıyorum
      Bunu yaparken, müziğin herhangi bir AI eğitim veri setinde hiç önemli bir parça olarak görülmediği acı verecek kadar açık hâle geliyor. Bugünlerde Opus 4.8’in müzik teorisini anlayıp açıklama becerisi oldukça etkileyici, ama nota transkripsiyonu ya da OCR/OMR istediğinizde büyük bir özgüvenle MusicXML/LilyPond sürümünde “2 + 2 = armut” düzeyinde sonuç veriyor. Umarım bu ihmal edilmiş alan da büyüyen AI dalgasına kapılır, ama şimdilik haksız denecek kadar değersiz görülüyor
    • Yalnızca akor analizi gerekiyorsa, notaları belirsizliğe yer bırakmadan ifade etmeye çalışan Harte notasyonu var: https://ismir2005.ismir.net/proceedings/1080.pdf
      Elbette dizgi ya da müziğin bütünüyle temsili için gereken tüm ek bilgileri vermez, ama https://github.com/smashub/choco gibi araştırma veri setleri mevcut. Analiz işleri için https://github.com/MarkGotham/When-in-Rome veri setini de kullandım, ama bu da aradığım şeyle %100 örtüşmüyor. Tablet üzerinde caz standardı ikamesi ve transpozisyon amacıyla “iReal Pro” uygulaması hoşunuza gidebilir. Bu kullanım senaryosunda kamera taramasından oldukça daha iyi
    • https://abcnotation.com/ gibi bir nota dizgi formatı nasıl olur?
    • Müzik OCR alanını takip edince, şimdiye kadar gerçekten düzgün tek çözümün soundslice olduğu hissine kapılıyorum. Taradıktan sonra sadece bazı edge case’leri gözden geçirmek yetiyor ve sonuçlar çok iyi oluyor. Küçük bir şirketin ücretli hizmeti ama desteklenmeyi fazlasıyla hak ediyor

  • “Deepseek-OCR, Deepseek-OCR-2, PaddleOCR’nin değerli modelleri ve fikirleri için teşekkür ederiz” diye yazmaları zarif bir tavır

    • Neden bununla dalga geçildiğini anlamıyorum

  • Bu arada “Unlimited OCR Works”, Fate/stay night’taki Unlimited Blade Works parodisidir. Unlimited Blade Works’ün asıl kurgusunda, başkalarının yaptığı silahları kopyalayan bir büyü söz konusu

  • Makale https://arxiv.org/abs/2606.23050 adresinde
    Bu arada, kitaplarda okuduğum alıntılar için küçük bir RAG kullanımında yerel OCR yapıyorum; ben de RAM tasarrufu için girdiyi parçalara ayırıyorum, bu kadar doğal bir yaklaşımın streaming modellerde de işe yaraması ilginç

  • Mistral’ın az önce çıkardığı şeyden daha umut verici görünüyor. Tesadüf mü? Pek sanmıyorum
    Bu yaklaşımın görüntü üretiminde de bir kombinasyonla kullanılabileceğini düşünüyorum. Görseli okuyup ya da görüp sonra Illustrator/Inkscape gibi araçlarda veya SVG olarak çizmeye başlayıp, eksik parçaları sonradan doldurmak mümkün görünüyor

  • Bunun, diğer OCR araçlarını ezip geçmiş gibi görünen infinty parser 2 ile karşılaştırması nasıl olur merak ediyorum: https://huggingface.co/datasets/allenai/olmOCR-bench
    Adil olmak gerekirse tek bir kazanan çıkaran OCR benchmark’ı yok ve bu araç da henüz hiçbir yerde yer almıyor

  • Dünyadan habersiz biri gibi geliyor olabilirim ama şirketlerin gerçekten iyi yazılımları neden gerçekten açık kaynak olarak yayımladığının asıl nedeni ne?
    Baidu ya da Google ise, rakiplerin kopyalayamaması için bunu kendilerine saklayıp değerini çıkarmaları gerekmiyor mu?

    • Büyük şirketlerin içinde de açık kaynağın ideallerine inanan ve işverenini ikna edip projeyi yayımlama izni alan insanlar var
      Şirket itibar kazanır ve bu da işe alım hunisine yardımcı olur. Bazen de Meta'nın Ollama'yı yayımlamasında olduğu gibi rakipleri stratejik olarak sarsabilir
    • Açık kaynak modellerin yayımlanması, ABD'deki yapay zeka araştırma laboratuvarlarının gelirini elinden alabilir. Bu laboratuvarların uzun vadeli rekabette kazanmak için yeniden yatırıma ayıracağı parayı azaltmak Çin'in işine yarayabilir

  • OCR'ı yapay zekayla deneme girişimleri hep uydurulmuş çıktılarla karışıyordu, bu yüzden prodüksiyonda kullanmak zordu. Bunun da böyle bir sorunu olup olmadığını merak ediyorum
    Basit bir örnek olarak, başka dilde kalması gereken kelimelerin otomatik olarak İngilizceye çevrilip etkiyi bozduğu durumlar olabiliyor

    • Neredeyse kelimeden daha büyük ölçekte makine öğrenmesini, yani kelime çiftleri, ifadeler, cümleler, belgeler ve korpus düzeyini istemez hale geliyorsunuz
      Transkripsiyonda neredeyse kesin sonuç ya da kesin olarak okunamadığını belirten bir işaret istenir. Bağlamdan tahmin edilebilir ama bazı OCR'larda bunun, harflerin sırayla birleşip bir kelime oluşturması dışında hangi temele dayanılarak tahmin edildiğini bilmek gerekir
      Örneğin familysearch.com'daki nüfus sayımı belgelerinde bir transkripsiyoncu adı Joseph olarak “düzeltmişti”, ama el yazısı belgedeki gerçek harfler Josepth idi ve bu gerçekten o bölgeye özgü bir yazım varyantıydı. Başka belgelerde ise yazan kişi “Joh” kısaltmasını kullanmıştı ve muhtemelen insan transkripsiyoncu bunu John diye aktardı; en olası seçenek buydu ama gerçekte yanlıştı. Bazen bunun bir tahmin olduğu gerçeği önemlidir, bazen de sadece eldeki en iyi tahmin gerekir
    • %100 tanıma sonucu istiyorsam, bu yöntemi orijinal belgeyi yeniden oluşturan bir görüntü modeliyle birleştirirdim. Yani transkripsiyon metniyle düzeni eşleştirip orijinal belgeyi yeniden üretmek
      Test etmek istediğiniz sayfa ya da paragraf dışındaki belgenin geri kalanını kullanırsanız, görüntü artefaktlarından test edilen ifadeyi aynen yeniden üretmenin önüne geçebilirsiniz. Yeniden oluşturmadan sonra, kaymış karakterleri saptayıp eşleştiren optik bir karşılaştırma yaparak hataları bulup yineleyebilirsiniz. Pahalı olurdu ama %100 tanımayı garanti edebilirdi
    • 4090 üzerinde bu modelle Japonca dilbilgisi PDF'lerini transkribe etmeyi deniyorum. İngilizce yazılmış ve Japonca örnek cümleleri çok olan bir belge; benim karşılaştırabildiğim kısımda oldukça iyi çalışıyor
      Çıktı, gerektiği yerde kanji/hiragana ile İngilizceyi uygun şekilde koruyor ve çevirmeye çalışmıyor. Saatte yaklaşık 200 sayfa dönüştürdü
    • Hangi model ya da aracı kullandığınızı merak ediyorum

  • Reducto'ya ne olduğunu bilmiyorum. 12-15 ay önce oldukça umut verici görünüyordu