اگر امروز برای استخراج داده از هزاران فاکتور یا سند اداری زمان میگذارید، باید بدانید که تفاوت میان یک سیستم آماتور و یک خط لوله صنعتی در مدیریت هندسه و چیدمان صفحه است. docTR، کتابخانه متنباز شرکت Mindee، دقیقاً برای پر کردن این شکاف طراحی شده تا تشخیص و بازشناسی متن را در یک جریان قابل تنظیم ادغام کند.
ساخت یک سیستم هوشمند اسناد در سطح تولیدی، چیزی فراتر از تشخیص ساده متن است؛ این کار نیازمند هماهنگی دقیق بین هندسه، چیدمان و استخراج معنایی است. docTR چارچوبی را فراهم میکند که تشخیص (Detection) و بازشناسی (Recognition) را در یک خط لوله واحد و قابل تنظیم ترکیب میکند.
درک اسناد از نویسهخوانی نوری (OCR) — که شبیه به تبدیل عکس یک صفحه کتاب به متن تایپی است — به سمت هوش مصنوعی اسناد (Document AI) تکامل یافته است. همانطور که در تحلیل قبلی ما دربارهی مدلهای پردازش PDF (مانند Unlimited-OCR شرکت Baidu) اشاره کردیم که بر تجزیه PDFهای چندصفحهای بدون تحلیل چیدمان تمرکز داشت، رویکرد docTR دقیقاً برعکس است: استفاده از آگاهی از چیدمان برای هدایت استخراج ساختاریافته. برای اکثر کسبوکارها، یک سند صرفاً رشتهای از کلمات نیست، بلکه نقشهای فضایی است که در آن موقعیت یک عبارت (مثلاً «مبلغ قابل پرداخت») معنای آن را تعریف میکند.
موتور اصلی OCR
طبق مستندات docTR، این خط لوله با یک فرآیند دو مرحلهای آغاز میشود: تشخیص (Detection) و بازشناسی (Recognition). ابتدا تشخیصدهنده کادرهای محیطی (Bounding Boxes) متن را پیدا میکند و سپس بازشناسنده، این برشهای تصویری را به نویسه تبدیل میکند.
کاربران میتوانند ترکیبات مختلف معماری را برای موازنه میان سرعت و دقت بسنجند. برای مثال، ترکیب db_mobilenet_v3_large با crnn_mobilenet_v3_small میتواند ۵ تا ۱۰ برابر ارزانتر از مدلهای سنگین باشد و برای پردازشهای انبوه ایدهآل است. گزینههای دیگر شامل fast_base با crnn_vgg16_bn یا مدل بسیار دقیق db_resnet50 در کنار parseq است.
برای اسنادی با متنهای دستنویس یا نویزی، بازشناسنده PARSeq دقت بالاتری دارد، هرچند هزینه محاسباتی آن بیشتر است. این کتابخانه اجازه میدهد استراتژی «دو مرحلهای» اجرا شود: استفاده از یک مدل سریع برای بخشهای ساده صفحه و فعال کردن مدل قدرتمند تنها برای کلماتی که امتیاز اطمینان آنها پایین (مثلاً زیر ۰.۸۵) است. این کار باعث میشود تنها درصد کمی از تصاویر — یعنی مواردی که واقعاً دشوار هستند — منابع گرانقیمت GPU (واحد پردازش گرافیکی) را مصرف کنند.
بارگذاری و پیشپردازش اسناد
بارگذاری اسناد در docTR از طریق کلاس DocumentFile انجام میشود که از تصاویر، PDFها و URLها پشتیبانی میکند. یک پارامتر حیاتی در اینجا scale است. از آنجا که مدلهای بازشناسی معمولاً نیاز دارند متن بدنه حداقل ۱۰ پیکسل ارتفاع داشته باشد تا بهینهترین عملکرد را داشته باشند، مقدار پیشفرض scale=2 برای اسکنهای ۱۵۰ تا ۳۰۰ DPI مناسب است. اما برای متون ریز ۸ پوینت، توسعهدهندگان باید این مقدار را به ۳ یا ۴ افزایش دهند.
برای شبیهسازی شرایط واقعی، اسناد را میتوان «اسکنگونه» (Scanified) کرد. این کار شامل اعمال تخریبهای واقعگرایانه است تا مدل در برابر خطاهای دنیای واقعی مقاوم شود:
- چرخش: ایجاد انحرافهای جزئی (مثلاً ۰.۴ یا -۰.۳ درجه).
- نویز: افزودن نویز گاوسی برای شبیهسازی دانههای سنسور دوربین.
- فشردهسازی JPEG: کاهش کیفیت (مثلاً تا ۷۲) برای ایجاد آرتیفکتهای فشردهسازی.
- سایهاندازی: اعمال سایههای گرادینتی برای شبیهسازی نور نامساوی در عکسهای موبایل یا اسکنرهای تخت.
تنظیم هندسه و دقت
دقت در docTR به نحوه مدیریت هندسه وابسته است. مختصات بهصورت نسبی (۰ تا ۱) هستند تا خط لوله در رزولوشنهای مختلف مقیاسپذیر باشد. وقتی assume_straight_pages=True باشد، سیستم کادرهای ساده برمیگرداند ((xmin, ymin), (xmax, ymax)). اما در حالت مخالف، یک چندضلعی ۴ نقطهای را بهصورت ساعتگرد خروجی میدهد.
برای بهینهسازی نتایج، توسعهدهندگان میتوانند از قلابهای (Hooks) سفارشی استفاده کنند:
- PadBoxesHook: افزودن حاشیه (مثلاً
dx=0.004وdy=0.006) به کادرهای محیطی، زیرا مدلهای بازشناسی وقتی نویسهها کاملاً برش نخورده و فضای کافی داشته باشند، بهتر عمل میکنند. - DropTinyBoxesHook: حذف کادرهای بسیار کوچک (نویز یا لکهها) بر اساس آستانه ارتفاع و عرض (مثلاً
min_h=0.006وmin_w=0.004) پیش از آنکه باعث اتلاف منابع GPU در مرحله بازشناسی شوند.
مدیریت صفحات غیرصاف یکی دیگر از چالشهای تولیدی است. docTR سه استراتژی ارائه میدهد:
۱. فرض بر صاف بودن: سریعترین روش است اما در انحرافات بیش از ۵ درجه شکست میخورد.
۲. چندضلعیها: بازگرداندن چندضلعیهای ۴ نقطهای برای پوشش متون کج.
۳. صاف کردن اولیه: استفاده از مرحله پیشپردازش straighten_pages برای حذف انحراف و تشخیص جهت سند پیش از انجام OCR.
آستانههای تشخیص و پسپردازش
تنظیم دقیق پسپردازشگر تشخیصدهنده برای کیفیتهای مختلف سند ضروری است. توسعهدهندگان دو آستانه اصلی را تنظیم میکنند:
- bin_thresh: کنترل دوتایی کردن (Binarization) نقشه تشخیص.
- box_thresh: کنترل سطح اطمینان لازم برای نگه داشتن یک کادر تشخیص داده شده.
در عمل، برای مهرهای کمرنگ، چاپهای ماتریس-نقطهای یا نسخههای کاربنی، آستانههای پایین لازم است، هرچند ریسک ایجاد کادرهای نویزی افزایش مییابد. برای اسکنهای دیجیتال شفاف، آستانههای بالا ترجیح داده میشوند. توصیه میشود این مقادیر را روی یک مجموعه داده برچسبدار کوچک بسنجید تا امتیاز F1 (F1 Score) بهینه شود، بهجای آنکه صرفاً به بازبینی بصری تکیه کنید.
فراتر از متن: چیدمان و KIE
هوشمندسازی واقعی سند نیازمند درک «نوع» ناحیه پردازش شده است. با فعال کردن detect_layout در docTR، نواحی به دستههای خاصی تقسیم میشوند:
- عنوان: سرتیترهای اصلی سند.
- متن: محتوای استاندارد پاراگرافها.
- جدول: نواحی دادههای جدولی.
- سربرگ/پابرگ: متون اداری تکراری.
این قابلیت اجازه میدهد نواحی جدولی به تجزیهکنندههای تخصصی فرستاده شوند یا سربرگها پیش از ورود متن به یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — حذف شوند.
استخراج اطلاعات کلیدی (KIE) با اختصاص برچسبهای معنایی به متن، یک گام فراتر میرود. بهجای تکیه بر عبارتهای منظم (Regex) شکننده، یک مدل KIE آموزشدیده میتواند مستقیماً فیلدهایی مثل «شماره فاکتور» یا «مبلغ کل» را بر اساس نشانههای بصری و متنی شناسایی کند. این رویکرد در نهایت به تبدیل دادههای خام به گزارشهای ساختاریافته منجر میشود، مشابه آنچه در سیستم Evidence Graph Studio برای تبدیل پژوهشهای AI به گزارشهای قابلراستیآزمایی مشاهده میکنیم. برای محیط تولید، این کار شامل آموزش یک مدل تشخیص با برچسبهای چندکلاسه (با استفاده از references/detection/train_pytorch.py) است تا فیلدها را بدون نیاز به لایه Regex بازگرداند.
استخراج ساختاریافته و ترتیب خواندن
خروجی خام OCR اغلب لیستی پراکنده از کلمات است. برای بازسازی معنای سند، docTR امکان بازسازی ترتیب خواندن را فراهم میکند. با گروهبندی کلمات در ردیفها بر اساس مرکز عمودی (cy) و یک ضریب تلورانس (مثلاً ۰.۶)، توسعهدهندگان میتوانند لیستی از کادرها را به یک جریان متنی منسجم تبدیل کنند.
برای دادههای جدولی، از روش خوشهبندی یکبعدی روی لبههای چپ (x0) کلمات در یک باند عمودی خاص استفاده میشود. این کار مرز ستونها را شناسایی کرده و اجازه میدهد کلمات در قالب یک جدول ساختاریافته سازماندهی شوند. این منطق فضایی برای استخراج داده از فاکتورهایی که «مبلغ» بصری زیر یک سرتیتر خاص است اما در متن خام لزوماً مجاور آن نیست، حیاتی است.
خروجی تولیدی و قابلیت جستوجو
تبدیل دادههای خام OCR به فرمتهای کاربردی گام نهایی است. docTR از خروجیهای JSON، متن ساده و hOCR (فرمت مبتنی بر XML) پشتیبانی میکند. همچنین متد synthesize() متن بازشناسی شده را دوباره در کادرهای تشخیص داده شده رندر میکند تا صحت هندسه و بازنویسی بصری چک شود.
یکی از کاربردیترین خروجیها، PDF قابل جستوجو است. با قرار دادن یک لایه متنی نامرئی که دقیقاً با هندسه تصویر اصلی همراستا است، سندی ایجاد میشود که ظاهر اسکن دارد اما کاربر میتواند با Ctrl+F کلمات خاص (مانند شناسه فاکتور) را بیابد. این کار با محاسبه اندازه فونت (Point-size) و مقیاس افقی متن برای تطبیق دقیق با ابعاد کادر انجام میشود.
عملکرد و استقرار
در مرحله استقرار، مدیریت حافظه GPU اهرم اصلی است. تشخیص بهدلیل نقشههای ویژگی بزرگ ۱۰۲۴x۱۰۲۴، محدود به حافظه است و نیاز به اندازه دستههای (Batch Size) کوچک دارد (مثلاً det_bs=2 روی GPU T4). در مقابل، برشهای بازشناسی بسیار کوچک (۳۲x۱۲۸) هستند و اجازه میدهند اندازه دستههای بسیار بزرگ (مثلاً reco_bs=1024) برای حداکثر کردن توان عملیاتی استفاده شوند.
سایر بهینهسازیها عبارتند از:
- تعویض مدل: استفاده از نسخههای MobileNet برای افزایش سرعت ۵ تا ۱۰ برابری.
- دستهبندی: ارسال تمام صفحات در یک فراخوانی واحد به پیشبین برای بهرهبرداری از دستهبندی داخلی.
- دقت ترکیبی: استفاده از
predictor.half()برای کاهش اشغال حافظه، به شرطی که پسپردازشگرها از float16 پشتیبانی کنند. - کنترل جهت: غیرفعال کردن طبقهبندیکنندههای جهت (
disable_page_orientation=Trueیاdisable_crop_orientation=True) در صورتی که دادهها از قبل صاف باشند.
توسعهدهندگان میتوانند این خط لولهها را از طریق قالبهای FastAPI یا تصاویر داکر آماده (ghcr.io/mindee/doctr) مستقر کنند. برای حوزههای تخصصی، این کتابخانه از تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست میدهیم تا روی یک حوزه دقیق شود — روی الفباهای سفارشی یا فونتهای خاص پشتیبانی میکند. این کار بهویژه زمانی لازم است که واژگان پیشفرض فرانسوی/لاتین نتوانند نویسههای موجود در اسناد هدف را تولید کنند.
پیکربندی پیشرفته و تنظیمات
برای تبدیل یک مثال ساده به خط لوله تولیدی، تسلط بر تنظیمات DocumentBuilder ضروری است. تنظیمات ساختاری کلیدی عبارتند از:
- resolve_lines: گروهبندی کلمات تکتک در خطوط (پیشفرض: فعال).
- resolve_blocks: گروهبندی خطوط در بلوکهای بزرگتر (پیشفرض: غیرفعال).
- paragraph_break: فاصله نسبی (مثلاً ۰.۰۳۵) که نقطه جداسازی پاراگرافها را تعیین میکند.
docTR اسکریپتهای آموزشی مشخصی در مخزن خود ارائه میدهد: references/detection/train_pytorch.py برای کادرهای محیطی، references/recognition/train_pytorch.py برای بازشناسی نویسهها و references/classification/train_pytorch.py برای طبقهبندی جهت. مدلهای بازشناسی به برشهای کلمات و فایل labels.json نیاز دارند، در حالی که مدلهای تشخیص به صفحات کامل با برچسبهای چندضلعی متکی هستند.
پس از آموزش وزنها، میتوان آنها را در یک پیشبین سفارشی با مقدار pretrained=False و استفاده از load_state_dict بارگذاری کرد. همچنین، docTR با Hugging Face Hub ادغام شده است و اجازه میدهد نقاط بازرسی (Checkpoints) را از طریق doctr.models.factory و دستورات push_to_hf_hub و from_hub مدیریت کنید.
این چرخش به سمت هوشمندسازی یکپارچه اسناد به این معناست که «مسئله OCR» دیگر درباره خواندن نویسهها نیست، بلکه درباره بازسازی قصد اصلی از چیدمان سند است. با ترکیب آگاهی فضایی و قدرت انتخابی مدلها، docTR اتوماسیون جریانهای کاری پیچیده مالی و اداری را ممکن میسازد.
گام بعدی شما
- بررسی مدلهای موجود در Hugging Face Spaces برای تست انواع اسناد خود.
- پیادهسازی استراتژی «دو مرحلهای» (مدل سریع + مدل دقیق) برای کاهش هزینه استنتاج.
- آزمایش متد
synthesize()برای اعتبارسنجی بصری خروجیهای هندسی.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی بهینهسازی استنتاج روی تراشههای لبه مراجعه کنید.
گفتگو