Drop a 300 page legal brief or a bound annual report into most OCR pipelines, and the software will quietly break it int

यदि आप अधिकांश OCR पाइपलाइनों में 300 पन्नों का कोई कानूनी ब्रीफ या एक बाउंड वार्षिक रिपोर्ट डाल दें, तो सॉफ़्टवेयर चुपचाप उसे टुकड़ों में तोड़ देगा। पहला पन्ना, प्रोसेस करें, मेमोरी खाली करें। दूसरा पन्ना, प्रोसेस करें, मेमोरी खाली करें। जब तक सिस्टम पीछे दिए गए संलग्नकों (exhibits) तक पहुँचता है, तब तक परिचय से प्राप्त किया गया कोई भी संदर्भ (context) गायब हो चुका होता है। फुटनोट्स बेसहारा हो जाते हैं। पन्नों के बीच बँटी हुई टेबल अपनी संरचना खो देती हैं। पन्नों पर जारी रहने वाले हेडर गलत लेबल हो जाते हैं। परिणाम एक ऐसा सिला हुआ टेक्स्ट फ़ाइल होता है जिसे एक इंसान को फिर से जोड़ना पड़ता है।

Baidu को लगता है कि यह वर्कफ़्लो मौलिक रूप से त्रुटिपूर्ण है। उनका समाधान Unlimited OCR है, जो एक ऐसा आर्किटेक्चर है जिसे आमतौर पर होने वाले GPU मेमोरी विस्फोट के बिना, एक ही सिंगल फॉरवर्ड पास में विशाल, बहु-पृष्ठीय दस्तावेज़ों को ग्रहण करने के लिए डिज़ाइन किया गया है। इसका रहस्य एक नया attention mechanism है जो मेमोरी को हार्ड ड्राइव की तरह नहीं, बल्कि मानव वर्किंग मेमोरी की तरह मानता है: स्रोत सामग्री को अपने सामने रखें, जो आपने अभी लिखा है उसे याद रखें, और बीते हुए समय को धुंधला होने दें।

लंबे दस्तावेज़ स्टैंडर्ड OCR को क्यों विफल कर देते हैं

समाधान को समझने के लिए, यह देखना मददगार है कि पारंपरिक एंड-टू-एंड OCR सिस्टम कहाँ विफल हो जाते हैं।

अधिकांश आधुनिक OCR पाइपलाइन अपने डिकोडर के रूप में एक लार्ज लैंग्वेज मॉडल का उपयोग करती हैं। जैसे-जैसे मॉडल एक पन्ना पढ़ता है और टेक्स्ट जेनरेट करता है, यह KV cache नामक आंतरिक प्रतिनिधित्व (internal representations) को स्टोर करता है—जो अनिवार्य रूप से कीज़ (keys) और वैल्यूज़ (values) की एक चलती-फिरती डायरी है जो मॉडल को यह ट्रैक रखने में मदद करती है कि उसने पहले क्या कहा है। समस्या यह है कि यह डायरी आउटपुट की हर नई लाइन के साथ रैखिक रूप से बढ़ती जाती है। दस पन्ने प्रोसेस करें, तो कैश दस पन्नों गहरा हो जाता है। सौ पन्ने प्रोसेस करें, तो यह लाखों टोकन तक फूल जाता है, जिससे VRAM खत्म होने लगती है और जनरेशन की गति धीमी हो जाती है।

इंजीनियरों ने इस समस्या से निपटने के लिए इसे नज़रअंदाज़ करना ही बेहतर समझा है। वे दस्तावेज़ों को एकल पृष्ठों में काट देते हैं, प्रत्येक पृष्ठ को स्वतंत्र रूप से मॉडल के माध्यम से चलाते हैं, और हर चरण के बीच KV cache को रीसेट कर देते हैं। यह काम तो चला लेता है, लेकिन यह मॉडल से किसी भी निरंतरता (continuous thread) को छीन लेता है। एक पैराग्राफ जो तीसरे पन्ने पर शुरू होता है और चौथे पन्ने पर समाप्त होता है, वह बीच से कट जाता है। पन्नों के बीच टेबल का फॉर्मेट बिगड़ जाता है। पिछले सेक्शन के संदर्भ टूटे हुए लिंक में बदल जाते हैं क्योंकि डिकोडर को इस बात की कोई स्थायी याददाश्त नहीं होती कि पहले क्या आया था। मॉडल वास्तव में दस्तावेज़ को पढ़ नहीं रहा है; वह केवल अलग-अलग फ्लैशकार्ड्स का एक क्रम कर रहा है।

मानवीय तकनीक: Reference Sliding Window Attention

Baidu के शोधकर्ताओं ने मानव संज्ञान (human cognition) से प्रेरणा लेकर इस समस्या का समाधान निकाला। किसी किताब से किसी अंश को मैन्युअल रूप से कॉपी करने के बारे में सोचें। आप अपने दिमाग में पहले से कॉपी किए गए हर वाक्य को लोड करके नहीं रखते। आप स्रोत पर एक नज़र डालते हैं, जो आखिरी कुछ शब्द आपने लिखे हैं उन्हें देखते हैं, और आगे बढ़ते हैं। आपकी वर्किंग मेमोरी बहुत छोटी होती है, लेकिन क्योंकि स्रोत टेक्स्ट आपके सामने खुला रहता है, इसलिए यह कार्य सहज हो जाता है।

Reference Sliding Window Attention, या R-SWA, ठीक इसी अंतर्ज्ञान (intuition) को औपचारिक रूप देता है।

आंतरिक रूप से, KV cache एक निश्चित लंबाई वाली कतार (fixed-length queue) बन जाता है। जब मॉडल एक नया टोकन जेनरेट करता है, तो यह "reference tokens"—मूल विज़ुअल इमेज एम्बेडिंग्स और प्रारंभिक प्रॉम्प्ट—की पूरी दृश्यता बनाए रखता है, लेकिन यह केवल पिछले 128 टोकन को देखता है जिन्हें इसने व्यक्तिगत रूप से जेनरेट किया है। बस इतना ही। चाहे मॉडल पहले पन्ने पर हो या पचासवें पन्ने पर, उसके अपने आउटपुट इतिहास का मेमोरी फुटप्रिंट एक ही जगह स्थिर रहता है। कैश बढ़ता नहीं है। यह रीसायकल (recycle) होता है।

यह एक