Unlimited OCR — Baidu का one-shot long-document parsing मॉडल

 (github.com/baidu)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DeepSeek OCR पर आधारित यह E2E OCR मॉडल डिकोडर की सभी attention को बदलकर, एक ही forward pass में दर्जनों पन्नों के दस्तावेज़ ट्रांसक्राइब करता है
  • इसकी कुंजी Reference Sliding Window Attention (R-SWA) है, जो डिकोडिंग लंबाई बढ़ने पर भी KV cache को constant रखकर memory और compute cost बढ़ने से रोकती है
  • यह किताब नकल करके लिखने वाले इंसान की working memory की नकल करता है, जिसमें दूर के output को धीरे-धीरे भुलाकर केवल पास के context को refer किया जाता है
  • OmniDocBench v1.5 में 93% के साथ DeepSeek OCR पर 6% बढ़त, और v1.6 में 93.92% के साथ end-to-end SOTA हासिल
  • R-SWA, OCR से आगे बढ़कर ASR·translation जैसे reference-based long-context tasks में भी लागू होने वाला एक general parsing attention mechanism है

पृष्ठभूमि और समस्या की परिभाषा

  • इंसान सैकड़ों पन्नों का transcription या कई घंटों की speech translation जैसे long-form tasks बिना दक्षता घटे कर सकता है, लेकिन मौजूदा OCR मॉडल एक ही forward pass में 10 पन्ने भी parse नहीं कर पाते
    • मौजूदा मॉडल page-by-page processing (for-loop) तरीके का उपयोग करते हैं, जिसमें हर step पर memory reset हो जाती है
    • यह तरीका एक consistent long-form process को अलग-अलग short-term tasks में तोड़ने वाला सिर्फ़ एक engineering workaround है, AGI-उन्मुख intelligence की दिशा में प्रगति नहीं
  • डिकोडर के रूप में LLM इस्तेमाल करने पर language prior का लाभ मिलकर performance सुधरती है, लेकिन output लंबा होने पर जमा हुआ KV cache memory usage बढ़ाता है और generation speed धीरे-धीरे कम करता है
  • इंसानी transcription व्यवहार न तो standard full attention है और न linear attention
    • पहले से लिखे पूरे text को दोबारा नहीं देखा जाता, बल्कि दिशा बनाए रखने के लिए केवल आस-पास के context को refer किया जाता है
    • visual/reference tokens पर recurrent state update नहीं किया जाता — ऐसा करने पर visual features धीरे-धीरे धुंधले होकर recognition accuracy घटा देते हैं

Reference Sliding Window Attention (R-SWA)

  • हर token सभी reference tokens (visual tokens + prompt) तक पहुँच सकता है, जबकि output attention को केवल पिछले n tokens (default 128) तक सीमित रखा जाता है
    • इससे हर token पूरे image को समझते हुए causal sliding window के भीतर state transition के माध्यम से OCR की प्रगति को खुद track कर सकता है
    • inference के दौरान KV cache constant रहने से memory pressure घटता है और compute cost कम होती है
  • attention को m+n आकार की 2-सेगमेंट विंडो तक सीमित किया जाता है
    • m, visual tokens और prompt वाला prefix window है, जो एक inference के दौरान स्थिर रहता है और केवल page count तथा resolution पर निर्भर करता है, decoding length पर नहीं
    • n, decode region की window है, जो स्थिर आकार में causal तरीके से slide करती है

  • KV cache प्रबंधन

    • DeepSeek OCR baseline standard MHA का उपयोग करता है, इसलिए KV cache आकार Lm + T तक लगातार बढ़ता है
    • R-SWA पूरे prefix cache Lm को बनाए रखता है, लेकिन generated हिस्से में केवल हाल के n tokens रखता है, इसलिए cache size Lm + min(n,T) ≤ Lm + n की constant upper bound में रहता है
    • output length पर्याप्त लंबी होने पर cache ratio ρ(T) शून्य की ओर जाता है → linear growth को constant में बदल देता है

  • kernel विश्लेषण

    • Flash Attention v3 kernel माप में DeepSeek OCR का standard MHA हर decoding step के साथ latency बढ़ाता है, जबकि Unlimited OCR, R-SWA की वजह से duration को स्थिर रखता है
    • DeepSeek OCR में KV cache length कुछ alignment boundaries पार करने पर data transfer efficiency अचानक गिरने से spike आता है, R-SWA में ऐसा नहीं होता
    • inference के दौरान GPU memory भी मूल मॉडल में linear बढ़ती है, जबकि Unlimited OCR में स्थिर रहती है — compute और memory, दोनों की स्थिरता long-document parsing को संभव बनाती है

मॉडल आर्किटेक्चर

  • DeepSeek OCR को baseline मानकर, DeepEncoder और MoE decoder (कुल 3B, active 500M parameters) को जोड़ा गया है
    • मौजूदा MHA को R-SWA से बदलकर, reference KV cache m में fixed-capacity output KV buffer n जोड़कर long-document parsing लागू की गई
    • KV cache को m+n capacity वाली queue के रूप में लागू किया गया है; हर नए token generation पर (m+1)वें token का KV बाहर कर दिया जाता है, जिससे cost और memory न बढ़ने की गारंटी मिलती है

  • DeepEncoder

    • SAM-ViT और CLIP-ViT को cascade किया गया है, और bridge में 16x token compression लागू है — शुरुआती भाग window attention से मूल image tokens को प्रोसेस करता है, जबकि global attention केवल compressed tokens के लिए है
    • high-resolution image encoding के दौरान activations कम रखकर GPU memory बचाई जाती है, और 1024×1024 PDF image को सिर्फ़ 256 tokens में compress किया जाता है
    • multi-page के लिए "Base" (1024×1024) और single-page के लिए "Gundam" (dynamic resolution) — ये दो modes अपनाए गए हैं
    • visual tokens output के साथ state transition से नहीं गुजरते; उन्हें एक बार encode करके पूरी प्रक्रिया में static रखा जाता है

प्रशिक्षण सेटअप

  • लगभग 20 लाख document OCR data पर training की गई, जिसमें single-page बनाम multi-page अनुपात 9:1 है
    • single-page PDF को Paddle OCR से annotate किया गया, और हर block के coordinates व content को जोड़कर ground truth बनाया गया; coordinates को 0–1000 range में normalize किया गया
    • multi-page data को single-page samples जोड़कर synthesize किया गया, लगभग 2 लाख samples (2~50 pages) में <page> separator का उपयोग हुआ, और पूरे data को 32K token sequence में pack किया गया
  • DeepSeek OCR checkpoint से 4,000 steps की अतिरिक्त training, global batch 256, max sequence 32K, और 8×16 A800 GPU का उपयोग
    • training के दौरान DeepEncoder को freeze रखा गया और केवल LLM parameters को train किया गया
    • AdamW optimizer, cosine annealing scheduler, initial learning rate 1e-4, DeepEP (EP=4), और Megatron-LM framework का उपयोग किया गया
    • inference के लिए Transformers library में R-SWA हेतु KV cache management लागू किया गया, और SGLang engine में optimization support जोड़ा गया — दोनों frameworks में constant TPS और GPU memory के साथ काम करता है

मूल्यांकन परिणाम

  • मुख्य benchmark OmniDocBench(v1.5/v1.6) है, जो text, formula, table structure, reading order आदि के multi-dimensional parsing capabilities को मापता है
    • v1.6, v1.5 की तुलना में 296 अतिरिक्त test images वाला नया version है, जबकि v1.5 में DeepSeek OCR सहित पुराने मॉडलों के साथ तुलना उपलब्ध है
    • long-document OCR evaluation के लिए अलग test set बनाया गया, जिसमें novels, documents और papers को 2/5/10/20/40+ pages में बाँटा गया (हर category में 10 से अधिक किताबें)

  • मुख्य प्रदर्शन

    • केवल 2M अतिरिक्त training data से end-to-end SOTA हासिल, v1.5 में text edit distance 0.035 कम, और table TEDS 5.96% बेहतर
    • v1.6 के aggregate metric में 93.92% के साथ end-to-end SOTA — width 128 R-SWA से standard attention को पूरी तरह बदलने पर भी यह प्रभावी और lossless साबित हुआ
    • MoE active 0.5B parameters के साथ high-efficiency inference, "Base" mode में 5580 TPS (DeepSeek OCR के 4951 TPS की तुलना में 12.7% तेज़)

  • उप-श्रेणी विश्लेषण

    • DeepSeek OCR की तुलना में सभी metrics पर consistent improvement, यानी लगभग "free lunch" स्तर का सुधार
    • DeepSeek OCR 2 की तुलना में text edit distance और reading order — दोनों में 9 में से 7 metrics पर बढ़त
    • PPT, newspaper, magazine, notes जैसे complex layouts में भी कोई कमजोरी नहीं

  • long-document parsing

    • R-SWA की मदद से दर्जनों से सैकड़ों पन्नों को single pass में prefill किया जा सकता है, और पहले पन्ने से आख़िरी तक continuous parsing करते हुए KV cache fixed रहने से output latency स्थिर रहती है
    • 20-page simultaneous input पर भी robust results, और 40+ pages पर edit distance 0.11 से कम, Distinct-35 97% बना रहता है
    • repetition errors multi-page "Base" mode (1024×1024) में छोटे अक्षरों की पहचान की कठिनाई से आते हैं, R-SWA के दिशा खोने से नहीं

दक्षता विश्लेषण

  • ideal concurrency condition में output TPS तुलना (prefill length 10 fixed)
    • 256 tokens पर दोनों मॉडलों की inference speed लगभग समान
    • output length बढ़ने पर DeepSeek OCR का TPS लगातार गिरता है, और 6,000 tokens पर Unlimited OCR से 35% पीछे रह जाता है
    • यह फिर साबित करता है कि consistent generation speed, long-document OCR tasks की मुख्य आवश्यकता है

सीमाएँ और आगे के काम

  • सीमित context length (जैसे 32K) के कारण prefill length की पाबंदी रहती है, इसलिए वास्तविक रूप से unlimited parsing अभी संभव नहीं — DeepEncoder की high compression rate के बावजूद pages बढ़ने पर prefill लंबा होता जाता है
  • अल्पकाल में 128K जैसे लंबे context वाले models train करके अधिक pages के prefill को support करने की योजना है
  • दीर्घकाल में prefill pool बनाकर, model को prefill KV chunks अपने-आप fetch करना सिखाने की योजना है, ताकि इंसान द्वारा page पलटने जैसा प्रभाव मॉडल में लाकर वास्तविक unlimited OCR हासिल किया जा सके
  • R-SWA को ASR·translation जैसे reference-based tasks में भी ले जाने की योजना है
  • मॉडल Hugging Face और ModelScope पर उपलब्ध है, और पेपर arXiv पर प्रकाशित है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News प्रतिक्रियाएँ

  • काफ़ी दिलचस्प है। मेरी समझ से शोधकर्ताओं ने लंबा दस्तावेज़ पढ़ते समय AI को मेमोरी लगातार जमा न करने देने वाली एक architecture hack ढूँढ ली है
    आम तौर पर जब AI 100-पेज की PDF को ट्रांसक्राइब करता है, तो वह पहले पढ़े गए हर शब्द को याद रखने की कोशिश करता है, और यह शॉर्ट-टर्म मेमोरी यानी KV cache O(N) के हिसाब से रैखिक रूप से बढ़ती जाती है, जिससे VRAM खत्म हो जाता है या लिमिट लग जाती है। इसलिए डेवलपर्स को PDF को पेज-दर-पेज तोड़कर प्रोसेस करने और फिर वापस जोड़ने वाला भद्दा कोड लिखना पड़ता है
    Unlimited OCR, Reference Sliding Window Attention(R-SWA) के जरिए फोकस को दो रास्तों में बाँटता है। एक है पूरा मूल दस्तावेज़ इमेज देखने वाला global reference, और दूसरा है मॉडल द्वारा खुद जनरेट की गई टेक्स्ट मेमोरी को हाल के 128 शब्दों जैसी संकरी sliding window तक सीमित रखने वाला local generation। यह local AI के लिए काफ़ी दिलचस्प हो सकता है, और कम्युनिटी इससे क्या बनाएगी और कैसे आगे बढ़ाएगी, यह देखने की उत्सुकता है

    • लगता है इसका एकदम सही इस्तेमाल बातचीत में भी हो सकता है। मैं काफ़ी समय से लंबी बातचीत का encapsulation एक्सपेरिमेंट कर रहा हूँ, जहाँ कुछ higher-level context और facts होते हैं जो ज़्यादा नहीं बदलते, जैसे प्रतिभागियों के नाम या बैकग्राउंड जैसी जानकारी
      दूसरी ओर, आज सुबह किसने क्या खाया जैसे बहुत बारीक facts अभी काम के हो सकते हैं, लेकिन लंबे समय में सामान्य रुझानों से आगे उनका ख़ास मतलब नहीं रहता। बातचीत को फिर से बनाने के लिए अब तक हुई हर बात को खींच लाए बिना सही संतुलन ढूँढना पड़ता है, इसलिए यह तरीका और देखने लायक लगता है
    • मैंने अभी पूरा पेपर नहीं पढ़ा है, लेकिन local generation window थोड़ी छोटी लगती है। खासकर image input बहुत सारे tokens इस्तेमाल करता है, इसलिए local attention layers कहाँ हैं उसके हिसाब से कम-से-कम 4096 शब्द जितनी बड़ी होना बेहतर लगेगा
    • इमेज OCR करते समय मैं बिल्कुल यही करता हूँ। एक बड़ी इमेज को कई छोटी इमेज में काटकर LLM को भेजने पर हर बार परफेक्ट नतीजे मिले, लेकिन पूरी इमेज एक साथ डालने पर रिज़ल्ट बहुत खराब थे
    • मुझे लगा था कि प्रमुख LLM टूल्स पहले से ही sliding window attention सपोर्ट करते हैं
    • इसी वजह से LeetCode काम का है। LeetCode लगातार हल करते-करते समझ आता है कि ऐसी तकनीकें क्यों मौजूद हैं और असल में कैसे इस्तेमाल होती हैं। इसमें काफ़ी दिलचस्प चीज़ें हैं

  • मैंने हाल ही में sheet music के लिए एक टैबलेट खरीदा, मुख्य मकसद jam session में jazz Real Book के बंडल की जगह लेना था। फ़ोन कैमरे से स्कैन किए हुए पन्ने जैसे-तैसे ठीक लगते हैं, लेकिन उनका आकार स्थिर रहता है और उनमें काफी दाग-धब्बे होते हैं
    अगर Bb या Eb instruments के लिए तुरंत transpose किया जा सकता तो अच्छा होता, लेकिन स्कैन होने की वजह से यह स्वाभाविक रूप से संभव नहीं है। optical music recognition की स्थिति देखने पर निष्कर्ष यही निकला कि AI के नज़रिए से संगीत लगभग पूरी तरह अनछुआ क्षेत्र है। optical music recognition काफ़ी खराब है, और AI की संगीत सिद्धांत की समझ भी वास्तविक sheet music को देखने वाले क्षेत्र में बहुत कमजोर है। LLMs ऑनलाइन टेक्स्ट से सीखे गए लगने वाले theory concepts की text explanation तो जैसे-तैसे ठीक दे देते हैं
    समस्या शायद इस बात में है कि कागज़ पर बने उन चिन्हों को, जिन्हें संगीतकार पढ़ते हैं, सही तरह encode करने वाला digital format अभी भी पर्याप्त नहीं है। musical notation काफ़ी समृद्ध है। MIDI मुख्यतः playback या performance के लिए ज़रूरी पहलुओं को समेटने के लिए बनाया गया था, इसलिए वह symbolic understanding के लिए ज़रूरी हर चीज़ नहीं रखता। MusicXML उस digital format के सबसे क़रीब लगता है जो संगीतकारों की चाही गई जानकारी रख सके, लेकिन MusicXML representation को score images या audio से जोड़ने वाला अच्छा training corpus कम है। शायद इसलिए कि MusicXML अपने आप में score typesetting के लिए ज़रूरी जानकारी पर्याप्त मात्रा में नहीं रखता
    MuseScore जैसे tools को बहुत-सी layout information track करनी पड़ती है जिसे MusicXML में व्यक्त नहीं किया जा सकता। LilyPond format, MusicXML की तुलना में कम verbose है और score creators के लिए थोड़ा ज़्यादा उपयोगी information रखता है, लेकिन ज़्यादातर लोग LilyPond में score नहीं बनाते। ऊपर से jazz fonts की स्थिति के कारण LilyPond निराश करता है। jazz context में “classical-style” notation देखना अच्छा नहीं लगता। OCR में जब भी कोई काफ़ी अच्छा दिखने वाला incremental सुधार दिखता है, तो OMR की दयनीय हालत याद आ जाती है

    • संगीतशास्त्रियों और music researchers द्वारा इस्तेमाल किया जाने वाला format MEI है: https://music-encoding.org/ और मानक typesetter verovio है: https://www.verovio.org/index.xhtml
      verovio, मूल MEI score की जानकारी को जितना संभव हो उतना बचाए रखते हुए उसे SVG format में typeset कर सकता है, इसलिए deep learning models के लिए वास्तविक detection dataset बनाने लायक metadata निकाला जा सकता है। verovio से typeset किए गए score set से COCO dataset बनाने के लिए एक मोटा-सा hacked script भी है: https://github.com/kwon-young/music/blob/main/svg2pl.py
      यहाँ बनाया गया synthetic score dataset भी सार्वजनिक किया गया है: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... जो लोग इसके ऊपर detector train करना चाहते हैं, उनका स्वागत है। OMR इस तरह उपेक्षित इसलिए है क्योंकि ज़्यादातर लोग इस काम की कठिनाई को बहुत कम आँकते हैं। यह अत्यंत विविध रूपों और बेहद जटिल graphic grammar के मिश्रण वाला एक विशिष्ट काम है
    • “AI की नज़र में संगीत लगभग हर जगह अनछुआ क्षेत्र है” यह बात सचमुच सही है। मेरी girlfriend musicology पढ़ती है, और शारीरिक विकलांगता की वजह से उसे कभी-कभी नोट्स लिखने में कठिनाई होती है, इसलिए मैं उसकी मदद के लिए AI-आधारित TTS/OCR जैसी छोटी-छोटी apps बनाता रहता हूँ
      ऐसा करते-करते यह बात तकलीफ़देह रूप से साफ़ हो जाती है कि किसी भी AI training dataset में संगीत को कभी महत्वपूर्ण हिस्से के रूप में नहीं माना गया। आजकल Opus 4.8 का music theory को समझने और समझाने का कौशल काफ़ी चौंकाने वाला है, लेकिन जब उससे score transcribe करने या OCR/OMR करने को कहो, तो वह पूरे आत्मविश्वास से MusicXML/LilyPond version में “2 + 2 = घोड़ा” जैसी चीज़ें निकाल देता है। उम्मीद है कि यह अनदेखा क्षेत्र भी बढ़ती AI लहर में बह जाएगा, लेकिन फिलहाल इसे नाइंसाफ़ी की हद तक कम आंका गया है
    • अगर सिर्फ chord analysis चाहिए, तो सुरों को बिना ambiguity के व्यक्त करने के लिए Harte notation है: https://ismir2005.ismir.net/proceedings/1080.pdf
      बेशक यह typesetting या संगीत की पूर्ण अभिव्यक्ति के लिए ज़रूरी सारी अतिरिक्त जानकारी नहीं देता, लेकिन https://github.com/smashub/choco जैसे research datasets मौजूद हैं। analysis tasks के लिए मैंने https://github.com/MarkGotham/When-in-Rome dataset भी इस्तेमाल किया है, लेकिन वह भी मेरी तलाश से 100% मेल नहीं खाता। अगर टैबलेट पर jazz standards के विकल्प और transposition आपका उपयोग-मामला है, तो “iReal Pro” app पसंद आ सकता है। कैमरा स्कैन की तुलना में उस use case के लिए यह काफ़ी बेहतर है
    • https://abcnotation.com/ जैसे score typesetting formats के बारे में क्या ख़याल है?
    • music OCR क्षेत्र को देखते हुए, अब तक वास्तव में ठीक-ठाक समाधान सिर्फ soundslice ही लगता है। स्कैन करने के बाद बस कुछ edge cases की समीक्षा करनी पड़ती है और परिणाम बहुत अच्छे आते हैं। यह एक छोटी कंपनी की paid service है, लेकिन समर्थन करने लायक है

  • “Deepseek-OCR, Deepseek-OCR-2, PaddleOCR के मूल्यवान models और ideas के लिए धन्यवाद” लिखना शालीन रवैया है

    • समझ नहीं आता लोग इसका मज़ाक क्यों उड़ा रहे हैं

  • जानकारी के लिए, “Unlimited OCR Works” Fate/stay night के Unlimited Blade Works की parody है। मूल Unlimited Blade Works में सेटिंग यह है कि यह किसी और द्वारा बनाए गए हथियारों की नकल करने वाला जादू है

  • पेपर https://arxiv.org/abs/2606.23050 पर है
    वैसे, मैं किताबों में पढ़े गए उद्धरणों के लिए छोटे RAG उपयोग-मामले में local OCR कर रहा हूँ, और RAM बचाने के लिए मैं भी input को chunks में बाँटता हूँ, इसलिए यह दिलचस्प है कि ऐसा स्वाभाविक तरीका streaming models में भी काम करता है

  • यह Mistral द्वारा अभी जारी किए गए मॉडल से ज़्यादा promising लगता है। संयोग? मुझे नहीं लगता
    यह approach image generation में भी किसी संयोजन के साथ इस्तेमाल हो सकती है। ऐसा लगता है कि पहले image को पढ़कर या देखकर Illustrator/Inkscape जैसे tools या SVG में draw करना शुरू किया जाए, और बाद में छूटे हुए हिस्से भरे जाएँ

  • जानना दिलचस्प होगा कि यह infinty parser 2 से कैसे तुलना करता है, जो दूसरे OCR tools पर हावी लगता था: https://huggingface.co/datasets/allenai/olmOCR-bench
    निष्पक्ष रूप से कहें तो कोई एकल विजेता OCR benchmark नहीं है, और यह tool अभी तक कहीं भी शामिल नहीं है

  • मैं शायद दुनिया-जहान से अनजान आदमी जैसा लगूं, लेकिन कंपनियां सच में अच्छा सॉफ़्टवेयर open source के रूप में जारी क्यों करती हैं?
    अगर Baidu या Google जैसी कंपनी है, तो क्या उन्हें उसका मूल्य निकालने के लिए उसे अपने पास ही नहीं रखना चाहिए ताकि प्रतिस्पर्धी उसकी नकल न कर सकें?

    • बड़ी कंपनियों के अंदर भी ऐसे लोग होते हैं जो open source के आदर्श पर विश्वास करते हैं और अपने नियोक्ता को मनाकर प्रोजेक्ट सार्वजनिक करने की अनुमति लेते हैं
      कंपनी को प्रतिष्ठा मिलती है, और इससे hiring funnel में मदद मिलती है। कभी-कभी Meta द्वारा Ollama को जारी करने की तरह रणनीतिक रूप से प्रतिस्पर्धियों को अस्थिर भी किया जा सकता है
    • open source मॉडल जारी करना अमेरिकी AI research labs की revenue छीन सकता है। अगर इससे उन लैब्स के पास लंबे मुकाबले में जीतने के लिए reinvest करने का पैसा कम रह जाए, तो यह चीन के लिए फायदेमंद हो सकता है

  • AI से OCR करने की कोशिशों में मैंने हमेशा गढ़े हुए नतीजे मिले-जुले देखे हैं, इसलिए उन्हें production में इस्तेमाल करना मुश्किल रहा है। यह भी वैसी ही समस्या रखता है या नहीं, यह जानना चाहूंगा
    एक आसान उदाहरण यह है कि जिन शब्दों को दूसरी भाषा में ही रहना चाहिए, वे अपने-आप अंग्रेज़ी में अनुवाद हो जाते हैं और इससे असर खराब हो जाता है

    • अब मैं लगभग शब्द से बड़े स्तर की machine learning नहीं चाहता, यानी word pair, phrase, sentence, document, corpus स्तर की चीज़ें
      transcription में मैं या तो लगभग निश्चित परिणाम चाहता हूं, या फिर साफ संकेत कि इसे निश्चित रूप से पढ़ा नहीं जा सका। context से अनुमान लगाया जा सकता है, लेकिन मुझे यह जानना होता है कि किसी OCR ने सिर्फ इस आधार से अनुमान लगाया कि अक्षर क्रम में जुड़कर एक शब्द बनाते हैं, या उसके पास और भी कोई आधार था
      उदाहरण के लिए familysearch.com के census document में किसी transcriber ने नाम को Joseph के रूप में “सुधार” दिया, जबकि हस्तलिखित दस्तावेज़ में असल अक्षर Josepth थे, और वह वास्तव में उस इलाके की एक variant spelling थी। दूसरे दस्तावेज़ों में लेखक ने “Joh” को संक्षेप में लिखा था, और शायद किसी human transcriber ने उसे John के रूप में उतारा, जो सबसे संभावित था लेकिन वास्तव में गलत था। कभी-कभी यह तथ्य कि वह एक अनुमान है, महत्वपूर्ण होता है, और कभी-कभी बस सबसे अच्छा अनुमान ही चाहिए होता है
    • अगर मुझे 100% recognition result चाहिए हो, तो मैं इस विधि को original document reconstruction image model के साथ जोड़ूंगा। यानी transcription text और layout को मिलाकर मूल दस्तावेज़ फिर से बनवाना
      अगर जिस page या paragraph को test करना है उसे छोड़कर बाकी दस्तावेज़ का उपयोग किया जाए, तो image artifact से परीक्षण वाले वाक्यांश को ज्यों का त्यों दोबारा बना देने से बचा जा सकता है। reconstruction के बाद misaligned characters को पहचानकर optical comparison से मिलान किया जा सकता है, फिर errors ढूंढकर iterate किया जा सकता है। महंगा होगा, लेकिन 100% recognition की गारंटी दी जा सकती है
    • मैं 4090 पर इस मॉडल से एक Japanese grammar PDF की transcription कर रहा हूं। दस्तावेज़ अंग्रेज़ी में लिखा है और उसमें Japanese examples बहुत हैं, और जितना मैंने कुछ हिस्सों को मिलाकर देखा है, यह काफ़ी अच्छा काम कर रहा है
      output जहां ज़रूरी है वहां kanji/hiragana और English को ठीक से बनाए रखता है, और अनुवाद करने की कोशिश नहीं करता। इसने लगभग एक घंटे में 200 pages convert किए
    • जानना चाहूंगा कि आप कौन-से model या tool इस्तेमाल करते रहे हैं

  • पता नहीं Reducto का क्या हुआ। 12~15 महीने पहले वह काफ़ी promising लग रहा था