تفاوت میان یک پرامپت ساده و یک سامانه صنعتی هوش مصنوعی اسناد، در دقتِ سازماندهی تحلیل چیدمان و استخراج متن نهفته است. deepDoctection این شکاف را با ارائه چارچوبی پر میکند که مراحل پراکنده را در یک خط لوله (Pipeline) قابلتنظیم متحد کرده و پیکسلهای خام را به دادههای ساختاریافته تبدیل میکند.
بسیاری از توسعهدهندگان با «شکاف اسنادی» دستوپنجه نرم میکنند؛ یعنی از دست رفتن معنای ساختاری هنگام تبدیل یک PDF به متن ساده. این موضوع بهویژه برای گزارشهای مالی یا مقالات علمی که جداول و شرح تصاویر در آنها ارزش اصلی را دارند، حیاتی است. با تبدیل سند به مجموعهای از اشیاء مرتبط — بهجای رشتهای از کاراکترها — توسعهدهندگان میتوانند قصد اصلی نویسنده را حفظ کنند.
همانطور که در تحلیلهای پیشین ما دربارهی بهینهسازی بازیابی دادهها اشاره کردیم، کیفیت خروجی مدلها مستقیماً به کیفیت دادههای ورودی وابسته است. در این راستا، deepDoctection از یک موتور تحلیل هسته استفاده میکند تا این نظم را برقرار کند.
موتور تحلیل هسته
به نقل از آموزش منتشر شده در Marktechpost در سال ۲۰۲۴، این خط لوله با پیکربندی یک تحلیلگر با وزنهای مدل مشخص آغاز میشود. سامانه برای تشخیص چیدمان از DocLayNet استفاده میکند تا جایگاه متن، تصاویر و جداول را در صفحه شناسایی کند. بهطور مشخص، این پیادهسازی از پروفایل Aryn/deformable-detr-DocLayNet/model.safetensors برای دستهبندی عناصر سند بهره میبرد.
برای دادههای ساختاریافته، این سامانه Table Transformer (TATR) را برای شناسایی ساختار ادغام میکند و از مدل deepdoctection/tatr_tab_struct_v2/model.safetensors استفاده مینماید. این قابلیت به سیستم اجازه میدهد نه تنها یک جدول را پیدا کند، بلکه ردیفها، ستونها و بازههای سلولی (Cell Spans) را درک کند. سامانه میتواند این جداول را در قالبهای متعددی از جمله HTML و CSV خروجی دهد، در حالی که شماره دقیق ردیف و ستون هر سلول را ردیابی میکند.
نویسهخوانی نوری یا OCR (Optical Character Recognition) — شبیه به چشم انسان که حروف را میبیند و آنها را به کلمات تبدیل میکند — توسط DocTR مدیریت میشود. این ابزار در واقع هستهی پردازشی است که نحوه ساخت خط لولههای آماده برای هوش مصنوعی اسناد در کتابخانه docTR را تعریف کرده است. در این پیکربندی، از مدل doctr/db_resnet50/db_resnet50-ac60cadc.pt برای تشخیص کلمات و از doctr/crnn_vgg16_bn/crnn_vgg16_bn-0417f351.pt برای شناسایی کاراکترها استفاده میشود. سپس چارچوب از قوانین تطبیق کلمات (با استفاده از قانون ioa و آستانه ۰.۳) بهره میبرد تا این کاراکترها به بلوکهای چیدمان شناسایی شده در مرحله اول متصل کند.
جزئیات پیکربندی فنی
برای دستیابی به استخراج با دقت بالا، تحلیلگر با چندین پارامتر صریح تنظیم میشود که نحوه تفسیر سند را کنترل میکنند:
- چیدمان و قطعهبندی: فعالسازی
USE_LAYOUT=TrueوUSE_LAYOUT_NMS=Trueباعث میشود تشخیصهای همپوشان پاکسازی شوند. قطعهبندی جداول از طریقUSE_TABLE_SEGMENTATION=Trueبا آستانه ۰.۴ برای ردیف و ستون فعال شده است. همچنین برای پوشش جامع، تنظیمSEGMENTATION.FULL_TABLE_TILING=Trueبه کار گرفته شده است. - ترتیب متن: سامانه از پارامترهای
TEXT_ORDERING.PARAGRAPH_BREAK=0.035وTEXT_ORDERING.BROKEN_LINE_TOLERANCE=0.003استفاده میکند تا جریان طبیعی خواندن سند را بازسازی کند. علاوه بر این،TEXT_ORDERING.INCLUDE_RESIDUAL_TEXT_CONTAINER=Trueتضمین میکند که هیچ متنی جا نماند. - اتصال چیدمان: خط لوله روابط بین اشیاء را برقرار میکند. برای مثال،
LAYOUT_LINK.PARENTAL_CATEGORIESشامل تصاویر و جداول است، در حالی کهLAYOUT_LINK.CHILD_CATEGORIESروی شرحها (Captions) هدفگذاری شده است؛ این امر اجازه میدهد سیستم بهصورت برنامهنویسی شده، هر تصویر را به توضیح مربوط به آن پیوند دهد. - تنظیمات محیطی: برای تعادل بین وضوح تصویر و سرعت پردازش، مقدار DPI روی ۲۰۰ تنظیم شده و از
DD_USE_TORCH=Trueو سطح لاگLOG_LEVEL="INFO"برای بهینهسازی زمان اجرا استفاده میشود. همچنین برای پایداری، تنظیمENABLE_DYNAMIC_OBJECT_TYPESرویFalseقرار گرفته است.
سفارشیسازی گردش کار
یکی از قدرتمندترین ویژگیهای deepDoctection، امکان ثبت انواع اشیاء سفارشی است. توسعهدهندگان میتوانند با استفاده از عبارات منظم (Regex) در یک مؤلفه سفارشی به نام EntityAndFlavourService برای استخراج موجودیتهای خاص مثل مبالغ پولی یا تاریخها، چارچوب را گسترش دهند.
- ثبت کلیدهای سفارشی (CustomKey): این قابلیت اجازه ایجاد کلیدهای خلاصه جدید مانند
money_mentionsیاdate_mentionsیاdoc_flavourرا میدهد. این کلیدها باید درobject_types_registryثبت شوند تا قابل سریالسازی باشند. کلاسFlavourLabelدستهها را به صورتTABULAR(جدولی)،NARRATIVE(روایتی) یاMIXED(ترکیبی) تعریف میکند. - طبقهبندی سند: سامانه میتواند بر اساس نسبت مساحت جدول به کل مساحت صفحه، صفحه را به عنوان «جدولی»، «روایتی» یا «ترکیبی» طبقهبندی کند. آستانه ۰.۲۵ برای این تشخیص استفاده میشود. مساحت با جمع زدن ابعاد جعبههای محصورکننده
(b[2] - b[0]) * (b[3] - b[1])برای تمام جداول شناسایی شده محاسبه میشود. - استخراج موجودیت: خط لوله با استفاده از Regex، نمادهای ارز ($, €, £) و فرمتهای تاریخ (مانند YYYY-MM-DD یا Month DD, YYYY) را مستقیماً از ویژگی
text_no_line_breakصفحه استخراج میکند. برای مثال، الگوهایی مانندUSD،EUR،GBP،millionیاbnرا شکار میکند. - ServiceFactory: این ابزار اجازه میدهد توسعهدهندگان قطعات خط لوله را بهصورت دستی مونتاژ و ترتیب دهند؛ شروع با یک تشخیصدهنده چیدمان، سپس NMS، سرویسهای زیر-تصویر برای جداول، تشخیصدهندههای کلمات DocTR و در نهایت سرویسهای ترتیب متن و موجودیتهای سفارشی.
کنترل پیشرفته خط لوله
این چارچوب کنترل دقیقی بر جریان دادهها فراهم میکند. توسعهدهندگان میتوانند فیلترهای ورودی پیاده کنند تا از اجرای برخی سرویسها صرفنظر کنند؛ مثلاً فیلتر skip_if_no_table مانع از اجرای سرویس قطعهبندی جداول میشود اگر مدل چیدمان هیچ برچسب جدولی در صفحه شناسایی نکرده باشد.
همچنین یک مکانیزم «بازگشت» یا Undo وجود دارد. اگر یک سرویس OCR نتایج نویزی تولید کند، تابع undo میتواند آن برچسبهای خاص را حذف کند بدون اینکه نیاز باشد کل خط لوله از ابتدا اجرا شود. برای مثال، توسعهدهنده میتواند یک image_doctr با شناسه خاص را هدف قرار دهد و تغییرات آن را به base_image برگرداند تا مجموعه برچسبها پاکسازی شود. این کار با عبور دادن base_image از متد undo در مؤلفه هدف خط لوله انجام میشود.
آمادهسازی دادهها برای RAG
مرحله نهایی بر سریالسازی متمرکز است. صفحات پردازش شده با دستور p.save(image_to_json=False) به صورت فایلهای JSON ذخیره میشوند. این کار برچسبهای ساختاری — مانند جعبههای محصورکننده و برچسبهای دستهبندی — را بدون نیاز به جاسازی دادههای سنگین تصویر اصلی حفظ میکند و خروجی را سبک و قابل انتقال میسازد. یک تست رفتوبرگشت (Round-trip) تأیید میکند که تعداد برچسبهای بازیابی شده از فایل با تعداد اصلی مطابقت دارد.
این دادهها سپس به تکههای JSONL تبدیل میشوند. هر رکورد یک دیکشنری شامل موارد زیر است:
document_idو شماره صفحه (page)order(توالی خواندن بازسازی شده)category(مثلاً متن روایتی یاtable_html)annotation_idو متن واقعی یا محتوای HTML
برای جداول، سامانه بهطور خاص محتوای t.html را با ترتیب -۱ در رکورد JSONL تزریق میکند تا ساختار جدول به عنوان یک واحد واحد حفظ شود. این فرمت دقیقاً برای سیستمهای تولید بازیابیافزا (RAG) — شبیه به دانشآموزی که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — طراحی شده است تا مدل زبانی (LLM) متن را با ترتیب درست و جداول را در قالب HTML ساختاریافته که روابط ستونی را حفظ میکند، دریافت کند.
تحلیل تحریریه
این رویکرد پارادایم هوش مصنوعی اسناد را از «ابتدا OCR سپس LLM» به «ابتدا ساختار سپس LLM» تغییر میدهد. با استخراج جداول به صورت HTML و متن روایتی به صورت تکههای مرتب شده، سامانه توهمات رایجی را که در آن LLMها ستونهای جدول را اشتباه میخوانند یا بهطور نادرست بین ستونهای صفحه میپرند، حذف میکند.
برای یک توسعهدهنده، این بدان معناست که کارهای دشوار تجزیه سند به یک خط لوله قطعی (Deterministic) منتقل شده است. این امر بار توکنهای LLM را با فیلتر کردن نویزها کاهش داده و دقت بازیابی در برنامههای جستجوی سازمانی را با ارائه منشأ (Provenance) با دقت بالا برای هر تکه متن افزایش میدهد. قابلیت ردیابی service_id و model_id برای هر کلمه، سطحی از قابلیت حسابرسی را فراهم میکند که بهندرت در پوشکهای ساده OCR یافت میشود.
گام بعدی شما
- بررسی پیادهسازی کامل کد در گیتهاب برای درک نحوه اتصال مؤلفهها.
- آزمایش مجموعه داده DocLayNet برای تنظیم دقیق تشخیص چیدمان متناسب با اسناد تخصصی سازمانتان.
- استفاده از
ServiceFactoryبرای ساخت یک خط لوله سفارشی که فقط موجودیتهای مالی را استخراج کند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو