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

অধিকাংশ OCR পাইপলাইনে একটি ৩০০ পৃষ্ঠার আইনি নথি বা একটি বাঁধাই করা বার্ষিক রিপোর্ট দিলে, সফটওয়্যারটি নিঃশব্দে এটিকে ছোট ছোট অংশে ভাগ করে ফেলে। পৃষ্ঠা এক, প্রসেস, মেমরি খালি। পৃষ্ঠা দুই, প্রসেস, মেমরি খালি। সিস্টেমটি যখন শেষের প্রদর্শনীগুলোতে (exhibits) পৌঁছায়, তখন ভূমিকার থেকে পাওয়া কোনো প্রেক্ষাপট বা কনটেক্সট আর থাকে না। ফুটনোটগুলো বিচ্ছিন্ন হয়ে পড়ে। পৃষ্ঠা জুড়ে থাকা টেবিলগুলো তাদের গঠন হারায়। পৃষ্ঠা জুড়ে থাকা হেডারগুলো ভুলভাবে লেবেল করা হয়। ফলাফল হলো একটি জোড়া লাগানো টেক্সট ফাইল যা একজন মানুষকে পুনরায় সাজাতে হয়।

Baidu মনে করে এই কাজের ধারাটি মৌলিকভাবে ত্রুটিপূর্ণ। তাদের সমাধান হলো Unlimited OCR, এমন একটি আর্কিটেকচার যা সাধারণত ঘটে যাওয়া GPU মেমরি বিস্ফোরণ ছাড়াই একটি মাত্র ফরওয়ার্ড পাসে বিশাল, বহু-পৃষ্ঠার নথি গ্রহণ করার জন্য ডিজাইন করা হয়েছে। এর কৌশলটি হলো একটি নতুন attention mechanism যা মেমরিকে হার্ড ড্রাইভের মতো নয় বরং মানুষের working memory-র মতো বিবেচনা করে: মূল উৎসটি আপনার সামনে রাখুন, আপনি যা লিখেছেন তা মনে রাখুন এবং অতীতকে ফিকে হতে দিন।

কেন দীর্ঘ নথিগুলো স্ট্যান্ডার্ড OCR-কে অকেজো করে দেয়

সমাধানটি বোঝার জন্য, প্রচলিত end-to-end OCR সিস্টেমগুলো কোথায় ব্যর্থ হয় তা দেখা প্রয়োজন।

বেশিরভাগ আধুনিক OCR পাইপলাইন তাদের decoder হিসেবে একটি large language model ব্যবহার করে। মডেলটি যখন একটি পৃষ্ঠা পড়ে এবং টেক্সট তৈরি করে, তখন এটি KV cache নামক অভ্যন্তরীণ রিপ্রেজেন্টেশনগুলো সংরক্ষণ করে—যা মূলত কী (keys) এবং ভ্যালু (values)-র একটি চলমান ডায়েরি যা মডেলটিকে সে আগে কী বলেছে তা ট্র্যাক করতে সাহায্য করে। সমস্যা হলো, আউটপুটের প্রতিটি নতুন লাইনের সাথে এই ডায়েরিটি রৈখিকভাবে (linearly) বাড়তে থাকে। দশটি পৃষ্ঠা প্রসেস করলে ক্যাশ দশ পৃষ্ঠা গভীর হয়। একশটি প্রসেস করলে এটি লক্ষ লক্ষ টোকেনে ফুলে ওঠে, যা VRAM খরচ করে ফেলে এবং জেনারেশন স্পিডকে অত্যন্ত ধীর করে দেয়।

ইঞ্জিনিয়াররা এই সমস্যাটি সমাধান না করেই এটি মোকাবিলা করেছেন। তারা নথিগুলোকে একক পৃষ্ঠায় ভাগ করেন, প্রতিটি পৃষ্ঠা মডেলের মাধ্যমে স্বাধীনভাবে চালান এবং প্রতিটি ধাপের মাঝে KV cache রিসেট করেন। এটি কাজ চালিয়ে নিতে সাহায্য করে ঠিকই, কিন্তু এটি মডেলের ধারাবাহিকতাকেও নষ্ট করে দেয়। পৃষ্ঠা তিন থেকে শুরু হওয়া এবং পৃষ্ঠা চার-এ শেষ হওয়া একটি অনুচ্ছেদ মাঝখান থেকে ভেঙে যায়। পৃষ্ঠা জুড়ে থাকা টেবিল ফরম্যাটিং নষ্ট হয়ে যায়। আগের সেকশনগুলোর রেফারেন্সগুলো বিচ্ছিন্ন লিঙ্কে পরিণত হয় কারণ decoder-এর কাছে আগে কী এসেছিল তার কোনো স্থায়ী মেমরি থাকে না। মডেলটি আসলে নথিটি পড়ছে না; এটি কেবল কতগুলো বিচ্ছিন্ন ফ্ল্যাশকার্ডের মতো কাজ করছে।

মানুষের কৌশল: Reference Sliding Window Attention

Baidu-র গবেষকরা মানুষের জ্ঞানীয় ক্ষমতা (human cognition) থেকে ধারণা নিয়ে এই সমস্যার সমাধান করেছেন। একটি বই থেকে কোনো অনুচ্ছেদ হাতে লিখে কপি করার কথা ভাবুন। আপনি আগে কপি করা প্রতিটি বাক্য আপনার মনে গেঁথে রাখেন না। আপনি উৎসের দিকে এক পলক তাকান, আপনি শেষ যে কয়েকটি শব্দ লিখেছেন সেদিকে দেখেন এবং লেখা চালিয়ে যান। আপনার working memory খুব সামান্য, কিন্তু যেহেতু মূল টেক্সটটি আপনার সামনে খোলা থাকে, তাই কাজটি খুব সহজ হয়ে যায়।

Reference Sliding Window Attention, বা R-SWA, ঠিক এই ধারণাটিকেই আনুষ্ঠানিকভাবে রূপ দেয়।

এর অভ্যন্তরীণ কার্যপদ্ধতিতে, KV cache একটি নির্দিষ্ট দৈর্ঘ্যের queue হয়ে ওঠে। যখন মডেলটি একটি নতুন টোকেন তৈরি করে, তখন এটি "reference tokens"—মূল ভিজ্যুয়াল ইমেজ এমবেডিং এবং প্রাথমিক প্রম্পট—এর পূর্ণ দৃশ্যমানতা বজায় রাখে, কিন্তু এটি কেবল তার নিজের তৈরি করা শেষ ১২৮টি টোকেনের দিকে ফিরে তাকায়। ব্যাস, এটুকুই। মডেলটি পৃষ্ঠা এক-এ থাকুক বা পৃষ্ঠা পঞ্চাশ-এ, তার নিজস্ব আউটপুট হিস্ট্রির memory footprint একই থাকে। ক্যাশ বাড়ে না; এটি রিসাইকেল হয়।

এটি একটি