«بدون نیاز به تحلیل چیدمان»؛ رویکرد جدید بایدو برای پردازش اسناد

تصور کنید یک گزارش فنی ۱۰۰ صفحه‌ای دارید که جداولش در چندین صفحه پخش شده‌اند؛ در حالت عادی، استخراج دقیق این داده‌ها یک کابوس برنامه‌نویسی است. Baidu's Unlimited-OCR این جریان کاری را تغییر داده و پردازش اسناد را به یک تکلیف تولیدی بلندمدت تبدیل می‌کند. طبق راهنمای کاربردی منتشر شده در Marktechpost، این مدل می‌تواند بدون نیاز به هیچ مرحله‌ای برای تحلیل چیدمان (Layout Analysis)، خروجی‌های ساختاریافته به فرمت Markdown یا JSON را مستقیماً از تصاویر با وضوح بالا تولید کند.

سیستم‌های سنتی نویسه‌خوانی نوری (OCR) — شبیه کسی است که اول باید کادرهای یک فرم را خط‌کشی کند و بعد کلمات را بخواند — معمولاً وقتی جداول بین صفحات تقسیم می‌شوند یا تراکم متن در سراسر سند تغییر می‌کند، شکست می‌خورند. اکثر توسعه‌دهندگان به یک رویکرد «خط لوله‌ای» (Pipeline) متکی هستند: ابتدا شناسایی جعک‌های متن (Bounding Boxes)، سپس برش تصاویر و در نهایت اجرای یک مدل متنی روی هر جعک. این فرآیند باعث ایجاد خطاهای تجمعی می‌شود؛ جایی که یک اشتباه کوچک در شناسایی مرزها، کل ساختار داده‌ای سند را نابود می‌کند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدل‌های چندوجهی اشاره کردیم، حذف لایه‌های میانی در پردازش تصویر، نرخ خطای تجمعی را به‌شدت کاهش می‌دهد. Unlimited-OCR این مشکل را با به‌کارگیری یک مدل بینایی-زبانی (VLM) با ۳ میلیارد پارامتر حل کرده است. این مدل تمام صفحه — شامل تیترها، پاراگراف‌ها و جداول تو در تو — را در یک مرحله‌ی رمزگشایی (Decoding Pass) پردازش می‌کند. این تغییر رویکرد از «تشخیص سپس شناسایی» به «تولید سرتاسری» (End-to-End Generation)، به مدل اجازه می‌دهد بستر بصری کل میدان دید را به‌طور یکپارچه حفظ کند.

زیرساخت سخت‌افزاری و لایه‌ی بارگذاری

برای استقرار این خط لوله، شما به یک واحد پردازش گرافیکی (GPU) با پشتیبانی CUDA نیاز دارید. در محیط‌هایی مثل گوگل کولب، این امر مستلزم پیکربندی Runtime برای استفاده از GPU است. این مدل برای بهره‌وری حداکثری طراحی شده و بسته به پشتیبانی سخت‌افزاری، به‌طور خودکار بین دقت bfloat16 یا float16 انتخاب می‌کند.

فرآیند بارگذاری شامل چندین وابستگی کلیدی و مشخصات فنی است:

• اندازه مدل: مدل baidu/Unlimited-OCR دارای ۳ میلیارد پارامتر است و در حالت BF16 حدود ۶ گیگابایت از حافظه ویدیویی (VRAM) را اشغال می‌کند.
• کتابخانه‌های مورد نیاز: این محیط به transformers==4.57.1، accelerate، einops، addict، easydict، psutil، Pillow و matplotlib نیاز دارد.
• منطق دقت: سیستم با استفاده از تابع torch.cuda.is_bf16_supported() نوع داده (DTYPE) را تعیین می‌کند. اگر پشتیبانی شود، مقدار پیش‌فرض روی torch.bfloat16 قرار می‌گیرد؛ در غیر این صورت، از torch.float16 استفاده می‌شود.
• مقداردهی اولیه: وزن‌ها از Hugging Face با تنظیم trust_remote_code=True و use_safetensors=True بارگذاری شده، سپس از طریق متد .cuda() به پردازنده گرافیکی منتقل شده و در حالت .eval() قرار می‌گیرند.

تولید داده‌های مصنوعی برای تست

برای اعتبارسنجی خط لوله، این جریان کاری از یک سیستم تولید نمونه با استفاده از کتابخانه PIL (Python Imaging Library) بهره می‌برد تا اسناد با وفاداری بالا (High-fidelity) ایجاد کند که پیچیدگی‌های دنیای واقعی را شبیه‌سازی می‌کنند. این صفحات تست با ابعاد ۱۲۴۰ در ۱۷۵۴ پیکسل طراحی شده‌اند و برای رندرینگ حرفه‌ای از فونت‌هایی مانند DejaVuSans-Bold.ttf و DejaVuSans.ttf استفاده می‌کنند.

این صفحات نمونه شامل عناصر ساختاری خاصی هستند تا مدل را تحت فشار قرار دهند (Stress-test):

• متون سلسله‌مراتبی: استفاده از تیترها (۴۸ پوینت)، زیرتیترها (۳۴ پوینت) و متن بدنه (۲۶ پوینت) برای تست واکنش مدل به تغییرات اندازه فونت.
• داده‌های جدولی: ایجاد جداولی با ستون‌های مشخص برای «Region»، «Q1»، «Q2» و «Q3» حاوی داده‌های عددی (مثلاً North با مقدار ۱۲.۴ و South با مقدار ۹.۸) برای تست ترازبندی دقیق شبکه‌ای.
• چیدمان‌های پیچیده: ترکیبی از عناوین، خطوط جداکننده افقی، پاراگراف‌های متنی پیچیده (Wrapped) و یادداشت‌های پایین صفحه (Footer notes) برای اطمینان از اینکه مدل جریان عمودی متن را به‌درستی ردیابی می‌کند.

دو حالت استنتاج: گاندام در برابر بیس

سیستم بسته به پیچیدگی بصری تصویر، دو روش متمایز برای پردازش ارائه می‌دهد. هر دو حالت از max_length معادل ۳۲,۷۶۸ توکن و no_repeat_ngram_size معادل ۳۵ استفاده می‌کنند تا از تخریب یا تکرار بی‌معنی متن جلوگیری کنند.

• حالت گاندام (Gundam): این تنظیمات مربوط به جزئیات بالا است. در این حالت crop_mode=True فعال شده و image_size روی ۶۴۰ پیکسل تنظیم می‌شود. با ترکیب یک نمای کلی از سند و برش‌های کاشی‌وار (Tiled crops) کوچک‌تر، حالت گاندام به‌طور ویژه برای چیدمان‌های متراکم یا متون بسیار ریز طراحی شده است، زیرا در این شرایط، یک تغییر اندازه کلی (Global Resize) باعث تار شدن کاراکترها می‌شد.
• حالت بیس (Base): این تنظیماتی متمرکز بر سرعت است. از یک نمای تک‌تصویری ۱۰۲۴ پیکسلی (image_size=1024) با crop_mode=False استفاده می‌کند. این روش پیچیدگی کاشی‌بندی را حذف کرده و برای صفحاتی با چاپ تمیز و واضح که در آن‌ها سرعت استنتاج (Inference) بر جزئیات ذره‌بینی اولویت دارد، ایده‌آل است.

خط لوله PDFهای چندصفحه‌ای

برای اسناد چندصفحه‌ای، این جریان کاری از PyMuPDF (fitz) برای پر کردن شکاف بین ساختارهای PDF و مدل‌های بینایی-زبانی استفاده می‌کند. خط لوله ابتدا صفحات PDF را به توالی‌ای از تصاویر تبدیل می‌کند. این کار از طریق رستر کردن هر صفحه به PNG با کیفیت ۳۰۰ DPI و با استفاده از یک ماتریس مقیاس‌بندی بر اساس رزولوشن استاندارد ۷۲ DPI انجام می‌شود.

این تصاویر سپس به تابع infer_multi() ارسال می‌شوند. این عملیات در محدودیت‌های تولید خود تفاوت‌های چشم‌گیری با OCR تک‌صفحه‌ای دارد:

• پنجره N-Gram: در حالی که حالت‌های تک‌صفحه‌ای از پنجره ۱۲۸ استفاده می‌کنند، در حالت چندصفحه‌ای مقدار ngram_window به ۱۰۲۴ افزایش می‌یابد. این کار مانع از آن می‌شود که مدل در طول رمزگشایی‌های طولانی در صفحات متعدد، در حلقه‌های تکراری گرفتار شود.
• حفظ زمینه: با برخورد با توالی تصاویر به عنوان یک جریان واحد، مدل می‌تواند ارجاعات بین‌صفحه‌ای (Cross-page references) را مدیریت کند و ساختاری منسجم در کل سند حفظ نماید.
• مدیریت ورودی: این جریان کاری می‌تواند یک PDF تولید شده (عن طريق چسباندن تصاویر PIL) را بگیرد و مجدداً از طریق یک دایرکتوری موقت، آن را به PNGهای آماده برای مدل تبدیل کند.

خروجی و ساختاردهی داده‌ها

خروجی این سیستم صرفاً متن خام نیست، بلکه مصنوعات ساختاریافته‌ای را تولید می‌کند که در دایرکتوری‌های مشخص (مانند outputs/single_gundam یا outputs/multi_page) ذخیره می‌شوند. سیستم فایل‌هایی با پسوندهای .txt ،.md ،.mmd و .json را ردیابی می‌کند.

مصنوعات تولید شده عبارتند از:

• Markdown (.md): برای حفظ قالب‌بندی، شامل تیترهای ضخیم (Bold) و ساختارهای جدولی.
• نمودارهای Mermaid (.mmd): برای بازنمایی روابط بصری یا فلوچارت‌های موجود در سند.
• JSON ساختاریافته: برای تجزیه و تحلیل برنامه‌نویسی و ادغام مستقیم در پایگاه‌های داده.
• متن استاندارد (.txt): برای بازیابی ساده محتوا.

برای جلوگیری از تخریب تولید در اسناد طولانی، جریان کاری max_length را روی ۳۲,۷۶۸ توکن نگه می‌دارد. این موضوع برای مدیریت جداول متراکم و محتواهای بین‌صفحه‌ای بسیار حیاتی است تا خروجی در میانه‌ی یک جمله قطع نشود.

این معماری به معنای آن است که شما دیگر نیازی به ساخت یک لایه منطقی سفارشی برای «چسباندن» ردیف‌های جداول ندارید که توسط ابزارهای OCR سنتی تکه-تکه شده‌اند. نگاشت داخلی بینایی-زبانی مدل، رابطه فضایی بین سرتیتر یک جدول در صفحه اول و داده‌های مرتبط با آن در صفحه دوم را به‌طور خودکار مدیریت می‌کند.

برای یک توسعه‌دهنده، این امر به معنای کاهش شدید بدهی فنی (Technical Debt) است. به‌جای مدیریت پنج کتابخانه مختلف برای تقسیم PDF، تشخیص چیدمان و استخراج متن، شما تنها یک مدل و یک اسکریپت رستر کردن را مدیریت می‌کنید. بار «درک» چیدمان صفحه از کد توسعه‌دهنده به وزن‌های مدل منتقل شده است.

در نهایت، این رویکرد روی «OCR شناختی» تمرکز دارد؛ جایی که مدل می‌فهمد یک خط متن بر اساس موقعیت بصری‌اش، یک پاورقی است یا یک سلول از جدول، نه اینکه فقط حروف (Glyphs) را تشخیص دهد. این قابلیت به‌ویژه برای اسکن گزارش‌ها، فرم‌های پیچیده و دفترچه‌های راهنمای فنی بسیار ارزشمند است.

گام بعدی شما

• برای شروع، این خط لوله را در یک نوت‌بوک کولب با استفاده از کتابخانه transformers و مخزن baidu/Unlimited-OCR در Hugging Face پیاده‌سازی کنید.
• روی کالیبره کردن crop_mode و image_size بر اساس تراکم سند خود تمرکز کنید. برای متن‌های متراکم از تنظیمات Gundam (640 + crop)، برای چاپ‌های تمیز از Base (1024, no crop) و برای PDFها از infer_multi() با پنجره n-gram گسترش‌یافته استفاده کنید.

اما چالش واقعی در اینجا، هزینه پردازشی این مدل‌های بزرگ برای حجم بالای اسناد است — در تحلیل ما درباره بهینه‌سازی هزینه استنتاج بیشتر بخوانید.