- जटिल दस्तावेज़ों से जानकारी निकालने के लिए पारंपरिक OCR और parsing तरीक़े अक्सर अर्थ को ठीक से सुरक्षित नहीं रख पाते
- Morphik ने ColPali मॉडल-आधारित visual document embedding तरीके के ज़रिए tables, charts और layout context को सीधे समझने का तरीका लागू किया है
- मौजूदा pipelines की तुलना में यह तरीका accuracy और information preservation के मामले में काफ़ी बेहतर है, और benchmark tests में अधिकतम 95.56% accuracy हासिल की गई
- अतिरिक्त रूप से, MUVERA और Turbopuffer को अपनाकर बड़े पैमाने के document search में speed improvement हासिल किया गया
- आगे का लक्ष्य multi-document reasoning, workflow integration, expert-grade interpretation जैसी व्यावहारिक document automation क्षमताएँ बनाना है
जटिल दस्तावेज़ parsing की सीमाएँ और RAG की कठिनाइयाँ
- charts, diagrams और tables मिले हुए जटिल PDF दस्तावेज़ों से जानकारी निकालने की कोशिश में OCR और parsing pipelines अक्सर ज़रूरी जानकारी खो देते हैं
- nested tables, महत्वपूर्ण diagrams, annotation-भरे technical documents, यहाँ तक कि text-रहित manuals जैसी वास्तविक परिस्थितियों में मौजूदा pipelines की सीमाएँ साफ़ दिखती हैं
- पारंपरिक pipeline के चरण:
- PDF पर OCR लागू करना (जहाँ numbers या characters ग़लत पढ़े जा सकते हैं)
- layout detection model से table/diagram अलग करने की कोशिश (अक्सर असफल)
- reading order reconstruction (जिसमें visual flow छूट सकता है)
- diagram caption recognition (जहाँ nuance अक्सर गुम हो जाता है)
- text chunking (जिससे संबंधित जानकारी अलग हो सकती है)
- vector embedding बनाना और vector DB में स्टोर करना (जिससे positional information और context खो जाता है)
- उदाहरण: एक साधारण table में भी "1,000" को "l,0O0" पढ़ लिया जाता है, या table और header अलग हो जाने से total calculation विफल हो जाती है
- diagram की legend को मुख्य text समझ लेना, percentage values का ग़लत जगह बिखर जाना जैसी वास्तविक information loss की समस्याएँ बार-बार सामने आती हैं
नया दृष्टिकोण: visual-based document understanding की ओर बदलाव
- Morphik टीम को मोड़ तब मिला जब उन्होंने सवाल उठाया: "अगर दस्तावेज़ों को इंसानों की तरह visual objects के रूप में समझा जाए तो?"
- हालिया research (ColPali) और Vision Language Model(VLM) की प्रगति की बदौलत, images को सीधे embed करके parsing या OCR के बिना पूरे document context और visual information को सुरक्षित रखा जा सकता है
- हर document page को high-resolution image के रूप में प्रोसेस किया जाता है, और patch level पर विभाजित करके ऐसे embeddings बनाए जाते हैं जो visual और textual दोनों जानकारी को दर्शाते हैं
- SigLIP-So400m Vision Transformer visual patch embeddings बनाता है, और PaliGemma-3B language model document structure को समझता है
- query (जैसे "Q3 revenue trend") के लिए text, chart, table, color जैसी कई visual clues को शामिल करने वाले late interaction search तरीके से संबंधित जानकारी को सटीक रूप से निकाला जाता है
- document के भीतर position, layout, color, graph changes जैसी सारी visual information बनी रहती है—कुछ वैसा ही जैसे कोई इंसान दस्तावेज़ को एक नज़र में देखता है
पारंपरिक parsing और ColPali तरीके की तुलना
- मौजूदा parsing-आधारित pipelines में हर चरण पर information loss होता है, और text व image embeddings अलग-अलग होने से document के भीतर spatial relationships को समझना संभव नहीं होता
- इसके उलट, ColPali तरीका एक ही visual embedding space में सारी जानकारी को एकीकृत करके पूरे document का अर्थ और context सुरक्षित रखता है
- वास्तविक benchmarks (मुख्यतः financial documents, public datasets) में Morphik (ColPali-आधारित) ने अधिकतम 95.56% accuracy दर्ज की (जबकि पारंपरिक LangChain+OpenAI text-embedding 72% और OpenAI file search सिर्फ़ 13.33% तक रहा)
- ViDoRe benchmark में visual-based तरीके ने पारंपरिक parsing तरीके की तुलना में nDCG@5 पर 14%p से अधिक बेहतर प्रदर्शन किया
performance optimization और वास्तविक उपयोग
- शुरुआती तरीके की कमी computational load के कारण speed slowdown थी, क्योंकि इसकी संरचना में हर patch पर vector search चाहिए होता था, इसलिए प्रति सेकंड करोड़ों queries वाले उपयोग के लिए यह उपयुक्त नहीं था
- MUVERA paper से प्रेरित होकर multi-vector search को single-vector search में बदलने वाला तरीका (fixed-dimension encoding) अपनाया गया
- Turbopuffer विशेष vector DB के साथ मिलाकर query speed को 3-4 seconds से घटाकर लगभग 30ms तक लाया गया
- इससे अब पारंपरिक text parsing की तुलना में कहीं तेज़ गति से millions of documents पर search संभव हो गया
उपयोग के क्षेत्र और आसान API
- अलग-अलग प्रकार के दस्तावेज़ों में visual structure और information loss के बिना high-accuracy search को support किया जाता है
- जटिल tables और charts वाले financial documents
- diagrams-केंद्रित technical manuals
- invoices, receipts से layout-आधारित information extraction
- research papers में visual materials और numerical data की समझ
- medical records में layout-आधारित संबंध पहचान
- API की संरचना बहुत सरल है: document upload करें और natural language में query करें; जैसे "10,000 डॉलर से अधिक जुर्माना शर्त वाले सभी contracts दिखाओ" जैसी requests को support किया जाता है
भविष्य की दिशा: multi-document intelligence और गहरी समझ
- multi-document intelligence: कई documents के बीच cross-reference और information tracking क्षमताएँ विकसित की जा रही हैं
- single-document search से आगे बढ़कर, कई documents के बीच संबंधों का tracking और reasoning (जैसे contract clause → regulatory document → execution manual तक linking) support किया जाएगा
- agentic understanding framework: document के भीतर साधारण Q&A से आगे बढ़कर clause extraction → दूसरे document से verification → details cross-check जैसे chunks के बीच logical reasoning का automation
- workflow integration: कई contracts के बीच terms comparison, technical decisions की history tracking जैसी व्यावहारिक प्रक्रियाओं के अनुरूप document automation intelligence को उन्नत करना
सीमाएँ और आगे के लक्ष्य
- मौजूदा तरीका अभी expert-level interpretation और contextual judgment तक नहीं पहुँचा है
- financial experts जैसी गहरी व्याख्या अभी तकनीकी रूप से सीमित है, और reliability, uncertainty quantification जैसी enterprise ज़रूरतों के लिए आगे और विकास चाहिए
- visual understanding और domain knowledge graph का संयोजन, causal reasoning, और reliability metrics प्रदान करना आगे की प्रमुख चुनौतियाँ हैं
निष्कर्ष
- documents को visual knowledge objects की तरह संभाला जाना चाहिए, और parsing की सीमाओं से आगे बढ़ते हुए image-based document understanding, RAG वातावरण में बेहतर समाधान है
- Morphik document information extraction के लिए एक नया मानक पेश करना चाहता है, और जटिल document workflows के automation तथा वास्तविक कामकाजी उपयोग को लक्ष्य बना रहा है
- विस्तृत फीचर्स का अनुभव morphik.ai पर किया जा सकता है
1 टिप्पणियां
Hacker News की राय
कुछ बुनियादी समस्याएँ हैं जिन्हें लोगों को ज़रूर समझना चाहिए
LLM आम तौर पर पहले 4k text tokens पर pretrain किए जाते हैं, और उसके बाद उन्हें लंबे context window तक बढ़ाया जाता है (4000 से 4001 तक जाना आसान है, लेकिन images में tokenization का तरीका अलग होता है, इसलिए यह संभव नहीं होता)
नतीजतन यह distribution से बाहर चला जाता है, और दो-तीन images से ज़्यादा संभालने पर hallucination की समस्या गंभीर हो जाती है
1536×2048 resolution वाले PDF, text की तुलना में 3~5 गुना ज़्यादा tokens इस्तेमाल करते हैं, इसलिए inference cost बढ़ती है और जवाब धीमे आते हैं
resolution कम करने पर image धुंधली हो जाती है
images अपने मूल आकार में ही भारी होती हैं, इसलिए सिर्फ ज़रूरी images डाउनलोड करने में भी हर request पर latency जुड़ जाती है
छोटे benchmarks में charts और tables से भरे financial documents पर यह बुनियादी text chunking तरीकों से स्वाभाविक रूप से बेहतर काम करता है
व्यक्तिगत रूप से, मैं Gemini की तरह OCR से image annotation कराकर परिणामों की तुलना करना चाहूँगा
end-to-end image approach खास मामलों (patents, architectural diagrams आदि) में समझ में आती है, लेकिन यह वास्तव में आख़िरी विकल्प है
LLM में यह समस्या होती है कि जो हिस्सा वह पढ़ नहीं पाता, वहाँ वह plausible text बना देता है, जिससे परिणाम और बिगड़ सकते हैं
उदाहरण के लिए, GPT4.1 ने 1296×179 आकार के screenshot पर बिल्कुल सही काम किया, लेकिन उसे 50% छोटा करके 650×84 देने पर उसने "Pdf's at 1536 × 2048 use 3 to 5X more tokens" को "A PNG at 512x 2048 is 3.5k more tokens" में बदलकर लौटा दिया
ज़्यादातर चीज़ें वह सही कर देता है, लेकिन इस तरह के subtle details बदल जाना ध्यान देने लायक है
gemma3 family की एक दिलचस्प विशेषता यह है कि input image size बढ़ाने पर processing memory requirement नहीं बढ़ती
क्योंकि second-stage encoder उसे fixed-size tokens में compress कर देता है
व्यवहार में यह काफ़ी उपयोगी है
लेकिन ऐसा करने पर पूरे document set को बड़े VLM से होकर गुजरना पड़ेगा
यह बहुत महंगा और धीमा हो सकता है
यहाँ स्पष्ट रूप से trade-off है
अधिकांश मामलों में मौजूदा तरीका सबसे प्रभावी रहा
लोग हर चीज़ LLM में डाल देते हैं, लेकिन हर स्थिति में यह सही नहीं होता
हर चीज़ को ज़रूरी नहीं कि LLM से ही process किया जाए
लगता है यह RAG pipeline बदलने वाले विचार तक फैल सकता है
हर RAG result के लिए model processing stage पर image से user query से सीधे जुड़ी जानकारी निकाली जाए, और उन (text) results को इकट्ठा करके final generation के input के रूप में इस्तेमाल किया जाए
इससे कई images की token limits को bypass किया जा सकता है, और image understanding process को parallelize भी किया जा सकता है
मैंने और मेरे सहकर्मियों ने 6 महीने पहले एक फ़्रांसीसी सरकारी एजेंसी के लिए ऐसा implementation बनाया था
इसे open source के रूप में यहाँ उपलब्ध कराया है: https://github.com/jolibrain/colette
यह हमारा मुख्य व्यवसाय नहीं है और अभी बस पड़ा हुआ है, लेकिन थोड़ी tuning के साथ काफ़ी कुशलता से काम करता है
असली ख़ासियत यह है कि पूरे pipeline को पूरी तरह differentiable बनाया जा सकता है, ताकि किसी खास dataset के लिए viz rag को fine-tune किया जा सके
layout model को भी customize करके सटीक document understanding संभव है
आम तौर पर सबसे बड़ी बाधा high-quality evaluation set की ज़रूरत होती है (और यही हमेशा बाधा रहती है)
मैंने OCR बनाम image + general-purpose LLM पर कई benchmarking studies की हैं: https://getomni.ai/blog/ocr-benchmark
image से सीधे extraction करने का सबसे बड़ा मुद्दा multi-page documents हैं
single page पर (OCR=>LLM vs Image=LLM) में direct image थोड़ा बेहतर था, लेकिन 5 या उससे ज़्यादा images पार करते ही accuracy, OCR-first तरीके की तुलना में तेज़ी से गिर गई
सच तो यह है कि text में long-context recall भी कठिन समस्या है, लेकिन LLM उसके लिए optimized हैं, जबकि image long-context recall अभी भी काफ़ी कमज़ोर है
image पर सीधे एक छोटा LLM transformation layer रखना भी काफ़ी प्रभावी है (यानी सीधे OCR करने की बजाय, 5 images को एक साथ छोटे vision model में भेजकर document के सबसे महत्वपूर्ण points ही निकालना)
अभी हम LLM के cache या attention maps को modify करके बड़े image batches को बेहतर चलाने पर शोध कर रहे हैं
sliding window या infinite retrieval जैसी approaches आशाजनक लगती हैं
यह मेरा निजी अंदाज़ा है, लेकिन multimodal models की प्रगति जिस रफ़्तार से हो रही है, उससे लगता है कि image long-context भी जल्द बड़ी समस्या नहीं रहेगा
यह blog post retrieval के लिए vision models इस्तेमाल करने पर अच्छे points उठाता है, लेकिन मैं कुछ समस्याएँ बताना चाहता हूँ
document parsing का मतलब है document को markdown/JSON (या extraction के समय schema के अनुरूप output) जैसे structured text में बदलना
RAG उसका सिर्फ एक उपयोग है, इसके अलावा और भी कई उपयोग हैं
ColPali retrieval के लिए शानदार है, लेकिन (कम से कम native रूप में) pure document parsing के लिए इस्तेमाल नहीं किया जा सकता
लेखक ज़्यादातर visual retrieval benchmark की ही बात करता है
कई बार यह standard OCR से बेहतर काम करता है, लेकिन
a. long-tail accuracy की समस्या अभी भी रहती है
b. confidence score, bounding box जैसी metadata नहीं मिलती
c. screenshot pipeline को production-grade बनाने में भी मेहनत लगती है
image tokens कहीं ज़्यादा ताकतवर हैं, लेकिन text tokens की storage cost बहुत कम होती है, इसलिए retrieval के समय पूरे document पर query की जा सकती है (सिर्फ chunk स्तर पर नहीं)
(संदर्भ के लिए: मैं llamaindex का CEO हूँ और LlamaCloud में parsing/retrieval दोनों किया है, यह बस एक सामान्य दृष्टिकोण है)
पिछले साल मैंने patent document analysis system बनाने में काफ़ी समय लगाया
patents में abstract diagrams, chemical formulas, equations जैसी तरह-तरह की content होती है, इसलिए LLM के लिए data तैयार करना बेहद मुश्किल होता है
मुझे जो सबसे सरल तरीका मिला, वह यह था कि हर page को “फ़ोटो लेने” जैसा convert किया जाए और फिर LLM से उस content का JSON और metadata (page number, visual elements की संख्या आदि) बनवाया जाए
complex images के लिए model से उनका description बनवाया जा सकता है
इससे उस JSON को अपनी पसंद के vector store आदि में आसानी से embed किया जा सकता है
cost-effectiveness मापना मुश्किल है, लेकिन यह तरीका लेखक के सुझाए तरीके से ज़्यादा सरल और प्रभावी लगा
उदाहरण के लिए, chart से x, y pairs model ज़्यादातर सही निकाल दे, फिर भी अगर user किसी खास x/y के बारे में पूछे तो वह चूक सकता है
अगर model inference stage पर image सीधे देख सके, तो user जो पूछे उसका सटीक जवाब दे सकता है, इसलिए यह approach ज़्यादा प्रभावी है
यहाँ एकमात्र असली बाधा retrieval quality है, और यह तुलनात्मक रूप से छोटी समस्या है
यानी अगर सही context delivery हो जाए, तो बाकी काम LLM संभाल लेगा
वरना OCR, parsing, image description जैसी समस्याएँ अचानक बहुत बढ़ जाती हैं
लेकिन यह भी दिखाता है कि LLM का अवसर ज़्यादातर मौजूदा मूल्यवान चीज़ों (जैसे patent documents) की reclassification/reprocessing में है
90-00 के दशक में software कंपनियाँ पुराने paper records को DB में बदलकर सफल हुई थीं
बिल्कुल नया और मूल्यवान dataset शुरू से बनाना आज भी बहुत निवेश और मेहनत माँगता है
मेरे अनुभव में, यह तरीका बहुत अच्छा नहीं है
font पर निर्भर करता है कि o (ओ) और 0 (शून्य) में फ़र्क करना मुश्किल हो सकता है
document (doc/xls/pdf/html) को image में बदलने पर यह अलगाव वाली जानकारी खो जाती है
serial numbers जैसी चीज़ें कभी-कभी इंसान भी देखकर अलग नहीं कर पाते
इसलिए PDF को image की तरह render करके extract करना काफ़ी तार्किक है
बाकी formats में document को सीधे parse करना बेहतर है
लेकिन व्यावहारिक तौर पर page design करते समय, model को असली image दिखाना सिर्फ code देने से कहीं ज़्यादा प्रभावी debugging तरीका होता है
1 vs I, 0 vs O जैसी समस्याएँ वास्तव में मौजूद हैं, लेकिन जिन documents में diagrams/charts बहुत होते हैं, उनमें सिर्फ images से काम करना अक्सर कहीं आसान लगा है
(हो सकता है इसमें selection bias हो)
मैंने Gemini में schedule copy करके query करने की कई मिनट कोशिश की, लेकिन HTML होने पर भी वह ठीक से काम नहीं कर पाया
आख़िर में मैंने screenshot लिया, गैर-ज़रूरी हिस्सों को काले boxes से ढक दिया, और image दे दी—तब उसने बहुत अच्छा काम किया
जिज्ञासा है, क्या multimodal RAG से यह समस्या पहले ही हल नहीं हो रही?
Flash 2.5, Sonnet 3.7 आदि के साथ मुझे image analysis के काफ़ी संतोषजनक नतीजे मिले हैं
बल्कि text की तुलना में image देने पर बेहतर response मिलता है, ऐसा महसूस होता है
https://www.youtube.com/watch?v=p7yRLIj9IyQ
लेकिन शुरुआती रूप का multi-vector (जो multimodal RAG की नींव है) संभालना बहुत कठिन है और similarity computation बहुत महँगी पड़ती है, इसलिए scale-up मुश्किल है
quantization, single-vector conversion (fixed-dimension encoding), indexing optimization जैसी चीज़ें चाहिए
Morphik में हम यही काम कर रहे हैं
मैंने भी अपनी सारी invoices एक साथ scan करने की कोशिश की—mailbox से attachments निकालकर, उन्हें एक-एक करके upload करने वाला script चलाया, और “invoice: yes/no” के साथ हर item/vendor name/date/invoice number आदि extract करवाया
कुल मिलाकर readability काफ़ी अच्छी रही, और 3 घंटे से ज़्यादा LLM calls चले, लेकिन automation था इसलिए मैंने परवाह नहीं की
बाद में मैंने bank statements से matching भी LLM से करवाई, और सिर्फ वे invoices छूटे जो attachment के रूप में आए ही नहीं थे
हालांकि invoice-statement matching LLM ने काफ़ी ख़राब की (कुछ dollars का भी फ़र्क हो तो भी वह बस कह देता है कि यही statement है)
इसलिए अभी कुछ समय तक accountant की ज़रूरत लगती है
cost का मैंने ठीक अनुमान नहीं लगाया, और Claude 3.7 जैसा सस्ता model इस्तेमाल किया
मैं समझता हूँ कि ColPali intuitive और powerful है, लेकिन फिर भी document-processing approaches के अपने फ़ायदे हैं