Baidu مدل Unlimited OCR 2 را به‌صورت متن‌باز منتشر کرد. این مدل بینایی-زبانی با ۳٫۳۴ میلیارد پارامتر، اسنادی با صدها صفحه را در یک درخواست پردازش می‌کند. مجوز انتشار MIT است و وزن‌ها و کد روی GitHub قرار دارند.

مکانیزم SR-SWA چگونه کار می‌کند؟#

هزینه توجه کامل با طول دنباله به‌صورت درجه دوم رشد می‌کند. در حالت چندصفحه‌ای، هر صفحه ۲۷۳ توکن تصویری مصرف می‌کند؛ یعنی ۱۰۰ صفحه پیش از هر خروجی ۲۷٬۳۰۰ توکن ورودی اضافه می‌کند. SR-SWA با نام کامل Sparse Reference Sliding Window Attention، توجه متن-تصویری را در یک مجموعه مرجع ثابت ۵۱۲ توکنی فشرده می‌کند. این مجموعه از یک پنجره محلی ۱۲۸ توکنی و انتخاب top-16 روی بلوک‌های ۳۲ توکنی تشکیل شده — یعنی ۱۶ بلوک ۳۲ توکنی که دقیقاً ۵۱۲ توکن را پوشش می‌دهد.

نتیجه این است که تأخیر و حافظه در هر گام رمزگشایی تقریباً ثابت می‌ماند، هرچند کدگذاری تصویر و زمان کلی اجرا همچنان با تعداد صفحات افزایش می‌یابد.

عملکرد در بنچمارک‌ها#

Baidu مدل را روی دو بنچمارک چندصفحه‌ای آزمون کرده. در MPDocBench-Parse (۴۳۳ سند، ۳٬۲۴۶ صفحه) نمره ۸۴٫۶ گرفته و در MarathonDocBench (چندصدصفحه‌ای) نمره ۷۷٫۱. نزدیک‌ترین رقیب در MarathonDocBench، Kimi-K3، نمره ۳۳٫۷ کسب کرده است. نمره سلف این مدل، Unlimited-OCR (منتشرشده ژوئن ۲۰۲۶)، در MarathonDocBench صفر است.

نکته قابل توجه، افت نمره بین دو بنچمارک است: Qwen3.8-Max از ۷۸٫۳ به ۲۲٫۹ سقوط می‌کند، اما Unlimited OCR 2 تنها ۷٫۵ واحد افت دارد. ضعیف‌ترین زیرنمره آن سلسله‌مراتب تیترهاست: ۴۸٫۲ در اسناد بلند.

اجرا و محدودیت‌ها#

مدل روی یک GPU با CUDA و دقت BF16 اجرا می‌شود. Baidu روی NVIDIA A800-80GB آزمون کرده و وزن‌ها حدود ۶٫۷ گیگابایت هستند. بارگذاری با Transformers نیازمند trust_remote_code=True است که کد پایتون مخزن را اجرا می‌کند. سروینگ با SGLang از یک wheel سفارشی Baidu استفاده می‌کند، نه نسخه upstream. Baidu هشدار داده که تنظیم پیش‌فرض bias می‌تواند تخصیص حافظه ۴۶۲ MiB ایجاد کند و منجر به OOM شود.

خوانش تحریریه#

این خبر برای کسی که همین حالا ایجنت سندپرداز می‌سازد، یک تغییر عملی دارد: اگر قبلاً مجبور بودید سند را به تکه‌های چندصفحه‌ای بشکنید و هر بخش را جداگانه بفرستید، حالا یک مدل ۳ میلیارد پارامتری با مجوز MIT هست که صدها صفحه را در یک درخواست می‌گیرد. اما دو احتیاط لازم است. اول، همه اعداد خودگزارشی Baidu هستند و MarathonDocBench به‌صورت عمومی در دسترس نیست. دوم، سلسله‌مراتب تیترها در اسناد بلند همچنان نقطه ضعف است (۴۸٫۲ از ۱۰۰)؛ یعنی اگر خروجی شما به ساختار درختی تیترها وابسته است، هنوز قابل اعتماد نیست. برای استخراج متن و جدول و فرمول، این مدل گزینه جدی‌ای است؛ برای بازسازی دقیق ساختار سلسله‌مراتبی سند، نه.

منبع: MarkTechPost