deepDoctection ساختار اسناد پیچیده را برای سیستم‌های RAG قابل‌فهم کرد

تفاوت میان یک پرامپت ساده و یک سامانه صنعتی هوش مصنوعی اسناد، در دقتِ سازمان‌دهی تحلیل چیدمان و استخراج متن نهفته است. 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 مراجعه کنید.