- "अगर टेक्स्ट को इमेज के रूप में व्यक्त किया जाए, तो बहुत कम tokens में वही जानकारी समाहित की जा सकती है" — इसी अंतर्दृष्टि से शुरुआत
- यह मॉडल टेक्स्ट जानकारी को 2D दृश्य अभिव्यक्ति में संपीड़ित करने वाला एक नया दृष्टिकोण प्रस्तावित करता है, और लंबे संदर्भ को कुशलतापूर्वक संभालने के लिए vision-आधारित compression (Optical Compression) की अवधारणा को प्रयोगात्मक रूप से सत्यापित करता है
- मॉडल DeepEncoder (encoder) और DeepSeek3B-MoE-A570M (decoder) से बना है, और high-resolution input में भी कम active memory के साथ 10~20x token compression ratio हासिल करता है
- 10x compression पर 97% OCR precision और 20x compression पर भी 60% से अधिक accuracy बनाए रखता है, जो long-context compression और memory forgetting mechanism research के लिए व्यावहारिक संभावनाएँ दिखाता है
- OmniDocBench में GOT-OCR2.0 (256 tokens/page) की तुलना में सिर्फ 100 vision tokens से बेहतर प्रदर्शन, और MinerU2.0 (औसतन 6000+ tokens/page) की तुलना में 800 tokens से कम पर बेहतर प्रदर्शन दर्ज किया गया
- एकल A100-40G GPU पर प्रतिदिन 2 लाख से अधिक pages डेटा निर्माण संभव है, इसलिए LLM/VLM बड़े पैमाने के training data engine के रूप में इसका व्यावहारिक मूल्य ऊँचा है
1. शोध पृष्ठभूमि
- मौजूदा LLM में sequence length बढ़ने पर computation quadratic रूप से बढ़ती है, यह एक संरचनात्मक सीमा है
- पेपर की शुरुआत इस अंतर्दृष्टि से होती है कि "अगर टेक्स्ट को इमेज के रूप में व्यक्त किया जाए, तो बहुत कम tokens में वही जानकारी समाहित की जा सकती है"
- इसे visual token-आधारित long-context compression (Context Optical Compression) के रूप में परिभाषित किया गया है, और OCR को इसके प्रयोगात्मक मंच के रूप में चुना गया है
- परिणामस्वरूप यह दिखाता है कि visual representation, LLM की context processing efficiency सुधारने का एक नया रास्ता हो सकती है
2. मॉडल संरचना
- DeepSeek-OCR = DeepEncoder + DeepSeek3B-MoE decoder
- DeepEncoder: SAM(Window Attention) + CLIP(Global Attention) + 16x token compressor
- DeepSeek3B-MoE: 64 experts में से 6 सक्रिय, कुल 570M active parameters
- multi-resolution mode का समर्थन (Tiny~Gundam)
- 512~1280 resolution input का समर्थन, और अधिकतम 9 tiles को मिलाकर प्रोसेस कर सकता है
- Gundam mode ultra-high-resolution documents (जैसे अख़बार) के लिए है, और अधिकतम 800 vision tokens का उपयोग करता है
3. डेटा इंजन
- कुल 3 प्रकार के डेटा संयोजन:
- OCR 1.0 डेटा: 30M pages (100 भाषाएँ) document-आधारित डेटा, जिसमें विस्तृत layout और text annotations शामिल हैं
- OCR 2.0 डेटा: charts, chemical formulas (SMILES), geometric shapes आदि जैसे complex recognition के लिए 16M डेटा
- सामान्य vision डेटा: CLIP-आधारित visual understanding बनाए रखने के लिए, कुल का 20%
- text-only डेटा: language ability को पूरक करने के लिए 10% अनुपात
- कुल training data composition ratio
- OCR 70% / vision 20% / text 10%
4. training pipeline
- DeepEncoder → DeepSeek-OCR, दो चरणों में training
- कुल 20 nodes (8×A100 GPU) पर data parallelism DP=40, global batch 640
- training speed: text data 90B tokens/दिन, multimodal data 70B tokens/दिन
5. मूल्यांकन परिणाम
(1) compression experiment (Fox benchmark)
- 10x compression पर 97% accuracy, और 20x compression पर भी 60% से अधिक कायम
- document जितना लंबा या जटिल होता है, प्रदर्शन में गिरावट आती है, लेकिन इसे "forgetting mechanism" simulation की संभावना के रूप में व्याख्यायित किया गया है
- 10x या उससे कम compression ratio पर लगभग lossless context restoration संभव है
(2) वास्तविक document recognition (OmniDocBench)
- Tiny (64 tokens)~Gundam (800 tokens) mode तुलना
- GOT-OCR2.0 (256 tokens) की तुलना में Small (100 tokens) mode बेहतर
- MinerU2.0 (7,000 tokens) की तुलना में Gundam (800 tokens) mode बेहतर प्रदर्शन करता है
- अलग-अलग document types के लिए आवश्यक token count अलग है
- slides, reports: 64~100 tokens पर्याप्त
- newspapers, papers: 400~800 tokens आवश्यक
6. गुणात्मक विश्लेषण (Qualitative Study)
- Deep Parsing mode
- charts, shapes, chemical formulas, natural images तक को single prompt से structured extraction किया जा सकता है
- बहुभाषी recognition
- लगभग 100 भाषाओं के PDF का समर्थन, जिनमें Arabic और Sinhala जैसी कम-प्रयुक्त भाषाएँ भी शामिल हैं
- सामान्य visual understanding
- image description, object detection, grounding तक कर सकता है
- LLM के साथ जोड़ने पर इसे vision-language complex reasoning के foundational model के रूप में उपयोग किया जा सकता है
7. चर्चा और निहितार्थ
- DeepSeek-OCR, vision token-आधारित long-context compression की सीमाओं का अन्वेषण करने वाला पहला प्रयोग है,
जो "एक इमेज हज़ार शब्दों के बराबर है" जैसी अवधारणा को मात्रात्मक रूप देता है
- 10x compression पर भी लगभग lossless restoration संभव → conversation history compression, long-term memory optimization आदि तक विस्तार संभव
- "समय के साथ इमेज resolution घटाने की विधि" के माध्यम से biological forgetting curve जैसी token attenuation simulation का प्रस्ताव
8. निष्कर्ष
- DeepSeek-OCR, text-visual के बीच 10~20x compression mapping का एक प्रमाणित मॉडल है,
और LLM की long-context processing limits को पार करने के लिए एक नया paradigm प्रस्तुत करता है
- OCR से आगे बढ़कर, भविष्य में इसका विस्तार digital-optical mixed pretraining तथा
'Optical Context Memory' आधारित ultra-long-context models तक होने की संभावना है
- code सार्वजनिक है, और इसे research तथा commercial data engine दोनों के रूप में उपयोग किया जा सकता है
- DeepSeek-OCR, मौजूदा OCR open source की तुलना में visual information को प्रभावी ढंग से encode करने वाली large language model (LLM)-आधारित संरचना के कारण ध्यान आकर्षित करता है
- विविध resolution support (512×512~1280×1280) और dynamic resolution के लिए Gundam mode शामिल होने से यह विभिन्न परिस्थितियों में बेहतर अनुकूलन देता है
- स्पष्ट prompt design के साथ general image description, Markdown conversion, layout-ignored OCR, chart parsing जैसे अनेक task modes का समर्थन करता है
- Fox, OminiDocBench जैसे industry benchmarks के साथ इंटरऑपरेबिलिटी प्रदर्शन की पुष्टि की गई है, और वास्तविक document processing experiments के आधार पर सत्यापन किया गया है
- GOT-OCR2.0, PaddleOCR जैसे अन्य लोकप्रिय projects के strengths और ideas को अपनाकर इसे लागू किया गया है
- समर्थित resolution
- Tiny: 512×512 (64 vision tokens)
- Small: 640×640 (100 vision tokens)
- Base: 1024×1024 (256 vision tokens)
- Large: 1280×1280 (400 vision tokens)
- Dynamic mode(=Gundam): मुक्त resolution (n×640×640 + 1×1024×1024)
- PDF और images के लिए parallel inference तथा तेज processing speed
- A100 GPU आधार पर PDF processing ~2,500 tokens/second संभव
- तकनीकी पृष्ठभूमि और ecosystem integration
- Python 100% में implemented
- vLLM और Transformers, दोनों प्रमुख inference environments का समर्थन
- OpenChart, Fox, OminiDocBench जैसे प्रमुख benchmarks और evaluation frameworks का उपयोग
- GOT-OCR2.0, PaddleOCR, Vary जैसे पूर्ववर्ती models के साथ integration, idea borrowing, performance enhancement
1 टिप्पणियां
Hacker News टिप्पणियाँ
यह पेपर सिर्फ OCR के लिए एक और VLM भर नहीं है, बल्कि compression जैसे और भी दिलचस्प विषयों की ओर बढ़ता है
उदाहरण के लिए, इसमें यह उद्धरण है: "हम vision-text compression की सीमाओं का अध्ययन करने वाला शुरुआती शोध कर रहे हैं, ताकि यह समझ सकें कि text tokens को decode करने के लिए कितने vision tokens की आवश्यकता होती है. शुरुआती परिणामों में DeepSeek-OCR ने लगभग lossless OCR compression को करीब 10x ratio पर हासिल किया, और 20x compression पर भी 60% accuracy बनाए रखी"
सहज रूप से देखें तो एक vision token में लगभग 10 text tokens जितनी जानकारी समा रही है
कोई अगर information theory के नज़रिए से समझा सके कि ऐसा क्यों होता है, और वह भी ऐसे कि शुरुआती लोग समझ सकें, तो अच्छा होगा
क्या इसकी वजह यह है कि text tokens अभी भी बहुत ज़्यादा बारीक (या redundant) हैं और entropy coding जितने efficient नहीं हैं, या फिर vision token वाले तरीके में जाने से हम 'शब्द-स्तर' की सीमाओं से बाहर निकलकर entropy के ज़्यादा करीब पहुँच पाते हैं (जैसे arithmetic encoding और Huffman code के फर्क में होता है)?
और पेपर में बड़े context को संभालते समय इमेज को वास्तव में downscale भी किया जाता है, इसलिए text domain और image domain में information loss के बीच संबंध पर भी चर्चा होती है
text token quantized subunits (subwords) होते हैं, जबकि vision tokens सिर्फ embedding space में मौजूद होते हैं
LLM में text tokenization का तरीका (छोटे) token IDs और (बड़े) vector embeddings की lookup table संरचना पर आधारित होता है
जब text को LLM में दिया जाता है, तो string को token boundaries पर काटा जाता है, token IDs में बदला जाता है, फिर lookup table से vectors लाकर एक matrix (context matrix) बनाया जाता है
असली text token sequence को भेजना efficient होता है, क्योंकि इसमें सिर्फ numbers की array (IDs) भेजनी होती है, आमतौर पर ~100k unique token IDs के दायरे में
इसके उलट embedding matrix को सीधे भेजना inefficient है, क्योंकि embeddings हज़ारों floating-point numbers से बनी होती हैं
images को अलग तरह से encode किया जाता है. image data को preprocess करके सीधे neural network-आधारित image encoder में डाला जाता है, जो उसे vectors में बदलकर context में जोड़ देता है
यानी image tokens के पास न token IDs होते हैं, न lookup table; वे सीधे data से embedding में बदलते हैं
नतीजतन image tokens को भेजने के लिए embedding खुद भेजनी पड़ती है, जो inefficient है
भले images कम tokens में encode हो जाएँ, लेकिन हर token की capacity काफ़ी बड़ी होती है
सार यह है कि text tokens integers (0~n) होते हैं जिनकी vector mapping स्पष्ट होती है, इसलिए वहाँ सिर्फ ‘n’ विकल्प होते हैं
जबकि image tokens m-dimensional float arrays (vectors) होते हैं, इसलिए उनका token space बहुत बड़ा होता है
pattern के हिसाब से भी text tokens लगातार UTF-8 bytes से सीधे जुड़े रहते हैं, और ज़्यादातर शब्द की सीमाओं से आगे नहीं जाते, इसलिए global patterns (जैसे “यह संवाद Hamlet का है”, “यह हिस्सा Spanish में है”) को एक ही token में व्यक्त नहीं किया जा सकता
multimodal LLM में image input को ठीक किस तरह embed किया जाता है, यह मुझे पक्का नहीं पता, लेकिन मोटे तौर पर समझ यह है कि image को grid में काटकर हर region को encode किया जाता है
DeepSeek के experiment में शायद information-theoretic गुणों से ज़्यादा अहम बात यह है कि resolution कितना घटाया जा सकता है, या grid (patch) size कितना कम/ज़्यादा किया जा सकता है, और फिर भी enough detail बची रहे ताकि OCR सही हो सके
अच्छा होगा अगर Karpathy NanoChat को multimodal तक बढ़ाकर ऐसे encoding process का अनुभव साझा करें
उपयुक्त compression ratio आखिरकार किसी character के resolution और हर vision token patch के relative size पर निर्भर करेगा
तभी जाकर OCR से निकले text tokens की संख्या image resolution से स्वतंत्र बनी रह सकती है
हर text token आमतौर पर subword स्तर का होता है, लेकिन VLM के vision tokens semantic space में होते हैं
semantic space subword splitting की तुलना में जानकारी को कहीं अधिक मज़बूती से compress कर सकता है
संदर्भ: मैं विशेषज्ञ नहीं हूँ, बस तुरंत सोचा हुआ विचार है
LLM में token count के साथ computation quadratic रूप से बढ़ती है
इसलिए VLM में text tokens को vision tokens में compress करने की कोशिश की जाती है
शायद वे text को पहले image के रूप में render करके फिर tokenize कर रहे हैं ताकि computation cost घटे
NVIDIA Spark(ARM64) पर PyTorch थोड़ा पेचीदा है, लेकिन Claude Code को root privileges के साथ एक नए Docker container में चलाकर मैं इसे काम करवाने में सफल रहा
विस्तृत notes यहाँ देखे जा सकते हैं
असली output इस लिंक पर उपलब्ध है, और टेस्ट के लिए OCR image source (यहाँ) का उपयोग किया गया
OCR output कुल मिलाकर काफ़ी ठोस है
लेकिन quote के ठीक नीचे वाले paragraph में इसने गैरज़रूरी सामग्री जोड़कर hallucination किया, और उसे अगले column से जोड़ दिया
जल्दी परीक्षण करने के लिए धन्यवाद
text की शुरुआत का "A" छूट जाना समझ में आता है (शायद dataset में news articles का हिस्सा कम रहा होगा)
लेकिन "Hallucination is a risk and..." पूरा हिस्सा, लेखक के पास वाला topic ("theme") और आख़िरी email भाग का पूरी तरह गायब हो जाना मुझे ज़्यादा दिलचस्प लगा
यह experiment अपने आप में ही एक अलग पोस्ट के लायक है
"Claude Code को एक नए Docker container में root के रूप में चलाया"
इसे root privileges के साथ चलाने की setup details जानने की उत्सुकता है
(अगर कहीं समझाया गया है, तो मैं मुख्य लेख में देख लूँगा)
पेपर में Anna’s Archive का कोई उल्लेख नहीं है
मुझे लगता है DeepSeek ने OCR researchers को 7.5 million किताबों (350TB) के Chinese nonfiction collection तक access देने के Anna के प्रस्ताव का वास्तव में उपयोग किया हो सकता है
यह Library Genesis से भी बड़ा संग्रह है
संदर्भ ब्लॉग
DeepSeek के पिछले पेपर में Anna’s Archive का सीधा उल्लेख था
"Anna’s Archive से 860K English और 180K Chinese ebooks तथा K-12 शिक्षा से जुड़े लाखों exam questions को curate किया गया"
DeepSeek-VL पेपर देखें
सिर्फ इसलिए कि कोई औरों की किताबें store कर रहा है, क्या access permission लेना वाकई ज़रूरी है, इस पर संदेह है
मेरे दिमाग में भी तुरंत Anna’s Archive आया, और मैं सोच रहा हूँ कि OCR-processed dataset कब सार्वजनिक होगा
इसका मतलब यह भी हो सकता है कि dataset कभी सार्वजनिक नहीं किया जाएगा
ऐसी स्थिति में चिंता होती है कि Anna’s Archive भी आखिरकार LLM कंपनियों के दुरुपयोग से गायब न हो जाए
META द्वारा library genesis से 70TB torrent से खींच लेने के बाद भी मानो मामला रुका नहीं है
यह मौजूदा benchmark और वास्तविक स्थिति के बीच अंतर पर आधारित अनुभव-साझा है
OmniAI benchmark अच्छा नहीं है
इसकी जगह OmniDocBench की सिफारिश है
Mistral OCR open-source OCR models और Gemini की तुलना में काफ़ी कमजोर है
E2E OCR अब भी बहुत कठिन है
pipeline approach (layout detection → reading order तय करना → हर element पर OCR) बेहतर काम करती है
complex table parsing अब भी एक बड़ी चुनौती है
यह भी जानने की जिज्ञासा है कि Apple Vision Framework की इन मॉडलों से benchmark तुलना किसी ने की है या नहीं
यह लगभग सभी Apple devices में built-in है, और व्यवहार में high-quality, fast OCR देता है (खासकर PDF conversion के लिए), लेकिन लगता है लोग इसके बारे में कम जानते हैं
benchmark में यह कहाँ ठहरता है, यह जानना बहुत रोचक होगा
OmniAI benchmark के मुताबिक Omni OCR सबसे अच्छा प्रदर्शन दिखाता है
लगता है बहुत से लोग ऐसे नतीजों पर बिना सवाल किए भरोसा कर लेंगे
यह जानने की उत्सुकता है कि LLM-आधारित OCR की तुलना Azure AI Document Intelligence(लिंक) और Google Vision API(लिंक) जैसी सेवाओं से करने पर उसके फायदे और अंतर क्या हैं
OmniAI अपने ही LLM और cloud OCR को benchmark करता है
OmniAI ब्लॉग benchmark (फ़रवरी 2025 तक)
उसके बाद LLM बहुत तेज़ी से आगे बढ़े हैं
हाल में Qwen3-VL श्रृंखला, खासकर Qwen3-VL-235B-A22B-Instruct, के नतीजे सबसे अच्छे दिखे हैं
मेरा अनुमान है कि commercial/proprietary OCR models वास्तविक documents पर अभी भी बेहतर रहेंगे
वजह है private high-quality training datasets की बड़ी मात्रा
public LLMs को arxiv, ebooks वगैरह जैसे paper-centric data पर train किया गया है, इसलिए वास्तविक business documents पर उनका कमजोर होना स्वाभाविक है
LLM approach character substitution errors (typos, variants) घटाती है, लेकिन पूरे page स्तर की consistency उलटे कम हो सकती है
और non-OCR LLM की तरह यह पूरी तरह ग़लत output भी दे सकता है
CJK characters में पारंपरिक OCR अब भी बहुत सारे अनुचित substitutions कर देता है
बहुत से characters इतने मिलते-जुलते होते हैं कि उन्हें microscope या binary level पर ही अलग किया जा सकता है
LLM संभावित character sequences पर ज़्यादा constraints लगाता है, इसलिए अधिक accurate results की उम्मीद की जा सकती है
कम से कम इस तरह की चिंता LLM-आधारित OCR अपनाने की प्रेरणा तो देती ही है
बाकी models के बारे में नहीं कह सकता, लेकिन हमारी कंपनी Azure AI Document Intelligence पर resume parsing system चला रही है और हम काफ़ी संतुष्ट हैं
शुरुआत में थोड़ा tuning करना पड़ा, और पिछले एक साल में लगभग कुछ छेड़ना नहीं पड़ा
मैंने कई VLMs (Granite, Qwen आदि, छोटे models से लेकर बड़े models तक) आज़माए हैं, और निष्कर्ष यही है कि ये पारंपरिक OCR का पूर्ण विकल्प बनने के मामले में निराश करते हैं
हमारे सिस्टम में हम ग्राहक documents लेते हैं और अनुरोध के मुताबिक markup किए हुए standard documents (raster-based multi-page bitmaps) वापस देते हैं
हमारे लिए data से individual characters या words के स्तर तक coordinates निकालने की precision महत्वपूर्ण है, लेकिन व्यवहार में VLM की positional information बहुत अस्थिर, पूरी तरह hallucinated, या बहुत अस्पष्ट होती है, इसलिए हमारी ज़रूरी accuracy/granularity नहीं मिल पाती
अभी तक हम Tesseract-आधारित setup और output clean-up routines का उपयोग करते हैं, और सिर्फ तब VLM text output को सहायक रूप से लेते हैं जब structured dataset उपलब्ध न हो
हमारा use case काफ़ी niche हो सकता है, और अधिकांश लोगों के लिए शायद सिर्फ text dump या Markdown/HTML conversion मिल जाना ही पर्याप्त होगा
लेकिन इन मॉडलों ने 'OCR को पूरी तरह solve कर दिया' है—इस दावे और वास्तविक अनुभव के बीच मुझे काफ़ी बड़ा अंतर लगता है
क्या आपने moondream 3 preview model आज़माया है?
ब्लॉग पोस्ट के अनुसार यह कई VLMs से बेहतर प्रदर्शन करता है, और एक हल्का model है
मुख्य पेज, मॉडल, ब्लॉग देखें
क्या ग्राहक documents में handwritten text नहीं होता?
पहले CNN से text bounding boxes निकालकर, फिर हर box पर VLM चलाने का तरीका भी संभव है
व्यक्तिगत रूप से मुझे OCR कुछ हद तक हल की गई समस्या जैसा लगता था
OmniAI benchmark भी हाल के models के साथ update नहीं हुआ है, और मुझे लगता है वजह यह है कि general-purpose LLMs उस benchmark के dedicated OCR से बेहतर हो गए हैं
वास्तव में जब हर page image को Gemini 2.5 Flash Lite में देकर Markdown format में extract करवाया, तो लगभग हर 1000 pages पर 20 cents का खर्च आया और output भी बहुत अच्छा था
आजकल OCR में मुश्किल बात आखिर बची क्या है, यह जानने की उत्सुकता है
ज़्यादातर OCR/LLMs (खासकर Gemini Pro 2.5 भी) complex tables को Markdown/HTML में बदलने में अब भी संघर्ष करते हैं
multiple headers, merged cells, checkbox वाले columns जैसी समस्याएँ बार-बार आती हैं, और multi-page tables को भी वे ठीक से नहीं समझते
Llamaindex भी इसी तरह बुरी तरह विफल होता है
कौन-सा OCR/LLM इन मामलों में बेहतर है, यह जानने की जिज्ञासा है
complex table example,
पूरा ICAO checklist उदाहरण
वास्तव में OCR नहीं बल्कि HTR (handwritten text recognition/transcription) अभी भी मुश्किल है
LLM की वजह से accuracy बहुत सुधरी है, लेकिन गलतियाँ इंसानों के लिए ढूँढ़ना और कठिन हो गया है (जो पढ़ नहीं पाता, उसे यह मनगढ़ंत बना देता है)
अगर आप यह स्वीकार कर सकते हैं कि जो हिस्सा पहचाना नहीं गया, वहाँ मॉडल "मुझे नहीं पता" कहने के बजाय मनमाना भर देगा, तो फिर हाँ, समस्या हल मानी जा सकती है
(यह व्यंग्य नहीं है; कुछ परिस्थितियों में यह वास्तव में स्वीकार्य भी हो सकता है)
मैं OmniAI benchmark का लेखक हूँ
नवीनतम models का update न होने की वजह यह है कि हमने product में OCR API पर कम ज़ोर दिया है
हम अंदरूनी तौर पर अब भी इसका उपयोग कर रहे हैं, बस benchmark को update करने में आलस हो गया
Gemini OCR में सबसे बेहतर है
लेकिन जब output training data के बहुत करीब हो जाता है, तो लगभग 10% मामलों में 'recitation' error आता है, जिसमें output अचानक कट जाता है
PDF mix में खाली page आ जाए तो यह कभी-कभी मज़ेदार hallucination भी कर देता है और नई सामग्री बना देता है
OpenAI भी बुरा नहीं है, लेकिन GPT5 का प्रदर्शन GPT-4o या 4.1 से अलग नहीं है
headers/footers जैसी कुछ चीज़ें अक्सर गायब हो जाती हैं, और page sideways हो तो मॉडल गड़बड़ा जाता है
IDs, medical documents, और PII risk वाले content पर यह खुद से refusal भी काफ़ी करता है
मुझे बिल्कुल नहीं लगता कि यह solved problem है
किसी अनोखे layout वाली magazine का OCR करने की कोशिश कीजिए—लगभग असंभव है
मैं vintage magazines इकट्ठा करता हूँ और हमेशा नवीनतम तकनीक से OCR आज़माता हूँ, लेकिन आखिर में बहुत ज़्यादा manual work करना ही पड़ता है
क्या कोई छोटा 'OCR model' है?
मुझे factory floor की तस्वीरों से सिर्फ serial numbers निकालने हैं, पूरा document parsing नहीं चाहिए
3B parameter model से इतना छोटा काम करना बहुत overkill लगता है
DeepSeek-OCR, Tesseract(लिंक) की तुलना में कैसा है, यह जानने की उत्सुकता है
मैं ocrmypdf(लिंक) का बड़ा प्रशंसक हूँ और local पर यह मेरे लिए बहुत अच्छा काम करता है
लेकिन अगर व्यवहार में tesseract 80% तक पहुँचता हो और नए models 95% तक जाते हों,
और उसके बदले आपको 100x storage, Kubernetes/Docker, GPU 16GB VRAM जैसी infra requirements झेलनी पड़ें, तो यह tradeoff गंभीरता से सोचने लायक है
मैं नवीनतम research के साथ नहीं चल पा रहा, इसलिए कोई ELI5 अंदाज़ में समझा सके कि यह है क्या और क्यों महत्वपूर्ण है?
GitHub और पेपर का शीर्षक OCR की बात करता है, लेकिन summary और readme.md में LLM context compression की चर्चा है, इसलिए भ्रम हो रहा है
ये दोनों कैसे जुड़े हैं, इसे बड़े संदर्भ में कोई समझा सके तो अच्छा होगा
तो image में ‘1000 tokens’ जितनी जानकारी है
व्यवहार में image को features/embeddings में decode करना पड़ता है
अगर वही image 100 ‘image tokens’ के रूप में process हो जाए, और वे image tokens आगे 1000 ‘text tokens’ में convert हो जाएँ,
तो शुद्ध decoding दृष्टिकोण से आपने output information को 10x compress करके भेजा
LLM के नज़रिए से इसका मतलब यह है कि अगर किसी चीज़ को पहले से 10x छोटे latent representation में compress किया जा सके, तो 1000 tokens/embeddings के बिना भी उतना या उससे अधिक output बनाया जा सकता है