تصور کنید یک سیستم حقوقی مبتنی بر تولید بازیابی‌افزا (RAG) — شبیه دستیاری که برای پاسخ به سوالات شما، ابتدا کتاب‌های مرجع را ورق می‌زند و سپس جواب می‌دهد — در یک آزمون حیاتی شکست می‌خورد: یک مدل زبانی بزرگ (LLM) با اطمینان به پاراگراف ۳ در صفحه ۸ ارجاع می‌دهد و ادعا می‌کند: «بر اساس محتوایی که ارائه کردید، پاراگراف ۳ در صفحه ۸ می‌گوید...»، اما کاربر متوجه می‌شود که نقل‌قول مورد نظر در هیچ کجای آن بخش از صفحه وجود ندارد.
این شکست نه یک اتفاق تصادفی، بلکه نتیجه‌ی یک شکاف مهندسی رایج است؛ بسیاری از ابزارهای استخراج متن (Parsing) مبتنی بر SaaS، داده‌های مختصاتی (Coordinate data) را دور می‌اندازند و مدل را مجبور می‌کنند مکان نقل‌قول‌ها را بر اساس حدس‌های معنایی تخمین بزند. بر اساس بررسی منابع متعدد در گیت‌هاب (GitHub)، ردیت (Reddit) و ژیهو (Zhihu)، این خطاهای نامحسوس در سیستم‌های سازمانی به‌شدت شایع هستند و به صورت گسترده توسط توسعه‌دهندگان گزارش شده‌اند.
مشکلات رایج شامل به‌هم‌ریختگی جداول پس از استخراج، جابه‌جایی ستون‌ها که دیگر با هم تراز نیستند و نتایج OCR است که در آن‌ها شماره صفحات ارجاع‌شده توسط مدل با مکان واقعی متن تطابق ندارد. این موضوع یادآور چالش‌های جدی‌تری است که تبدیل نادرست فرمول‌ها و جداول در RAG می‌تواند منجر به تخریب پنهان داده‌ها شود و کیفیت پاسخ‌های مدل را به‌کل تغییر دهد. در برخی موارد، اصلاحات دست‌نویس روی یک بند قرارداد به‌طور کامل حذف می‌شوند چون نتیجه‌ی پارس‌شده، این تغییرات بصری را منعکس نمی‌کند. همچنین توسعه‌دهندگان متوجه می‌شوند که به‌دلیل نبود مختصات لازم، امکان های‌لایت کردن متن اصلی در رابط کاربری (Frontend) وجود ندارد. چالش اصلی این است که صفحه‌ای که در واقع «ترسیم» شده، باید به متنی ساختاریافته و قابل جست‌جو با مختصات دقیق تبدیل شود.
پارسینگ PDF چیست؟
فرمت PDF (Portable Document Format) در واقع یک «زبان توصیف صفحه» است. این فرمت سند را به شکل جریانی از پاراگراف‌ها ثبت نمی‌کند، بلکه توصیف می‌کند که هر المان در هر لحظه و در کدام نقطه از صفحه قرار دارد. ساختار داخلی آن شامل موارد زیر است:
- سربرگ (Header): مشخص‌کننده نسخه PDF است.
- بدنه (Body): مجموعه‌ای از اشیاء شامل متن، فونت، تصویر و اشیاء گرافیکی است.
- جدول مرجع متقاطع (Xref): اندیسی از آفست‌های تمام اشیاء موجود در فایل است.
- تریلر (Trailer): علامت پایان فایل است و به خواننده (Reader) می‌گوید که از کدام شیء شروع به خواندن کند.
به‌دلیل اینکه PDF «ترسیم» شده است، وظیفه پارسینگ این است که این فرآیند ترسیم را به صورت معکوس به یک جریان متنی ساختاریافته تبدیل کند و در عین حال اطلاعات معنایی و موقعیتی را حفظ نماید. همین دشواری است که باعث شده در این حوزه رویکردهای فنی بسیار متفاوتی شکل بگیرد. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی زیرساخت‌های داده‌ای برای هوش مصنوعی اشاره کردیم، دقت در لایه استخراج داده، تعیین‌کننده کیفیت نهایی پاسخ مدل است.
چالش‌های کلیدی استخراج
به نقل از تحلیل‌های فنی، توسعه‌دهندگان هنگام پارسینگ با چهار نقطه اصطکاک اصلی روبرو هستند:
۱. پیچیدگی چیدمان (Layout Complexity): صفحاتی با دو ستون، جداولی که چندین صفحه را در بر می‌گیرند، پاورقی‌ها، سربرگ‌ها، پابرگ‌ها و نمودارهای جاسازی شده نیازمند تحلیل پیچیده چیدمان هستند تا ترتیب طبیعی خواندن متن بازگردانده شود.
۲. محتوای ترکیبی (Mixed Content): یک فایل ممکن است هم‌زمان شامل متن دیجیتال، تصاویر رستر (Raster)، صفحات اسکن‌شده، گرافیک‌های برداری و یادداشت‌های دست‌نویس باشد. هر یک از این منابع نیازمند یک مسیر پردازشی متفاوت هستند.
۳. مشکلات کدگذاری (Encoding Issues): مشکلاتی ناشی از زیرمجموعه‌های فونت جاسازی شده (Embedded font subsets)، نقشه‌های سفارشی CMap و جداول خصوصی ToUnicode بروز می‌کند. اگر این موارد به درستی مدیریت نشوند، منجر به تولید متن‌های به‌هم‌ریخته شده یا باعث می‌شوند یک کاراکتر واحد به چندین شکل مختلف ظاهر شود.
۴. از دست رفتن مختصات (Coordinate Loss): بسیاری از ابزارها تنها یک جریان متنی ساده (Plain text) خروجی می‌دهند. این امر منجر به خطاهای نامحسوس مدل، عدم امکان های‌لایت متن در رابط کاربری و عدم توانایی در استفاده از خروجی برای آموزش‌های SFT چندوجهی (Multimodal SFT) می‌شود.
سه رویکرد فنی جریان اصلی
در حال حاضر استانداردهای صنعتی به سه متدولوژی تقسیم می‌شوند که هر کدام موازنه (Trade-off) خاص خود را دارند:
رویکرد اول: استخراج مستقیم جریان PDF (Native PDF Stream Extraction)
این روش با PDF مانند یک جریان متنی برخورد می‌کند. در این حالت، جریان محتوا مستقیماً موقعیت (x, y)، فونت و اندازه هر شیء متنی را ثبت می‌کند.
- سازوکار: استفاده از یک مفسر PDF (مانند PDFium، Poppler یا qpdf) برای رمزگشایی جریان محتوا. این ابزارها عملگرهایی مانند BT/ET، Tj، TJ و cm را به قطعات متنی همراه با مختصات ترجمه می‌کنند. سپس تحلیل چیدمان از طریق قوانین (Rules) یا یادگیری ماشین برای بازسازی ترتیب خواندن انجام می‌شود.
- مزایا: سرعت بسیار بالا (پردازش در حد چند ثانیه)، اجرا بر روی CPU، ارائه مختصات در سطح کاراکتر با کمترین میزان لرزش (Jitter) و مصرف حافظه پایین.
- معایب: کاملاً ناکارآمد برای PDFهای اسکن‌شده یا تصویر-محور، زیرا هیچ شیء متنی در جریان وجود ندارد. همچنین چیدمان‌های دو ستونه و جداول بین‌صفحه‌ای نیازمند مراحل بازسازی اضافی هستند.
- ابزارهای شاخص: pdfplumber، PyMuPDF (fitz) و Apache PDFBox.
رویکرد دوم: OCR دو مرحله‌ای و تحلیل چیدمان (Two-Stage OCR + Layout Analysis)
این اصل بر تبدیل صفحه PDF به یک تصویر (رستری‌سازی)، معمولاً با رزولوشن ۳۰۰ DPI، و سپس برخورد با آن به عنوان یک مسئله تشخیص بصری استوار است.
- سازوکار: صفحات به فرمت PNG یا JPG تبدیل می‌شوند. مدل‌های تشخیص متن (مانند DBNet، CTPN یا CRAFT) کادرهای محصورکننده (Bounding boxes) را پیدا می‌کنند. سپس موتورهای OCR مانند PaddleOCR، Tesseract یا Surya متن را می‌خوانند. در نهایت، ابزارهای تحلیل چیدمان مانند Layout-Parser یا DocLayNet پاراگراف‌ها، جداول و اشکال را بازسازی می‌کنند.
- مزایا: برخورد یکسان با PDFهای دیجیتال و اسکن‌شده؛ مدیریت بهینه فرمت‌های پیچیده از طریق مدل‌های چیدمان.
- معایب: رنج بردن از «لرزش مختصات» (Coordinate Jitter) که در آن کادرهای تشخیص و شناسایی با هم تراز نیستند. سرعت پایین است (یک سند ۱۰۰ صفحه‌ای ممکن است چندین دقیقه زمان ببرد) و وابستگی شدیدی به GPU دارد.
- ابزارهای شاخص: PaddleOCR، ترکیب Surya OCR با Layout-Parser و Tesseract.
رویکرد سوم: مدل‌های چندوجهی سرتاسری (VLM-Based End-to-End)
این روش از یک مدل بینایی-زبانی (VLM) استفاده می‌کند تا تصویر یک صفحه PDF را بگیرد و در یک مرحله استنتاج (Inference)، داده‌های ساختاریافته (مانند Markdown، JSON یا HTML) را به همراه مختصات خروجی دهد.
- سازوکار: تصویر صفحه رندر شده و به VLMهایی مانند GPT-4o، Qwen2-VL، InternVL یا مدل‌های متمرکز بر سند مانند Nougat ارسال می‌شود. مدل نتایج ساختاریافته را تولید کرده و Bboxها را در دل خروجی جاسازی می‌کند. در این زمینه، ابزارهای تخصصی متعددی ظهور کرده‌اند، برای مثال مدل Lift با استفاده از راهنمای طرح‌واره توانسته است PDFهای پژوهشی را به داده‌های ساختاریافته JSON تبدیل کند تا دسترسی به داده‌های متنی تسهیل شود.
- مزایا: پردازش یکپارچه (One-stop) برای فرمول‌ها، نمودارها، صفحات اسکن‌شده و چیدمان‌های پیچیده. دقت Bboxها بیشتر است زیرا مدل در حین تولید متن، «به تصویر نگاه می‌کند» و از عدم تطابق موجود در OCR دو مرحله‌ای جلوگیری می‌کند.
- معایب: کندترین روش با بیشترین میزان مصرف حافظه. استقرار محلی (Local deployment) به دلیل اندازه مدل دشوار است و اسناد طولانی ممکن است توسط پنجره متنی (Context Window) مدل قطع شوند.
- ابزارهای شاخص: GPT-4o، Qwen2-VL، InternVL، Nougat و Marker.
راهکار ترکیبی: DocSlight
طبق گزارش‌های فنی و ارزیابی‌های داخلی، موثرترین راهکار این نیست که تنها یک روش را انتخاب کنیم، بلکه باید آن‌ها را به صورت تطبیقی از طریق یک «زنجیره تصمیم‌گیرنده» ترکیب کنیم. برای هر صفحه، سیستم ابتدا تعیین می‌کند که آیا PDF «دیجیتال» است یا خیر. اگر جریان محتوا دارای اشیاء متنی باشد، از رویکرد اول برای دریافت مختصات سطح کاراکتر در چند ثانیه استفاده می‌کند. اگر صفحه اسکن شده باشد، به صورت تطبیقی بین رویکرد دوم یا سوم تصمیم می‌گیرد. چنانچه چیدمان بسیار پیچیده باشد (ستون‌های متعدد، فرمول‌های ترکیبی و جداول)، مستقیماً به سراغ رویکرد سوم (VLM) می‌رود.
بر این اساس، موتور متن‌باز DocSlight برای بسته‌بندی این خط لوله «تصمیم‌گیری + زمان‌بندی تطبیقی» ساخته شد. این ابزار سه تمایز کلیدی دارد:
- حالت دوگانه (محلی + ابری): یک حالت محلی رایگان، آفلاین و قابل اجرا روی CPU که تضمین می‌کند داده‌ها در سرور کاربر باقی بمانند، در حالی که حالت ابری مبتنی بر VLM دقت بالاتری ارائه می‌دهد. این ویژگی برای مشتریان بخش مالی، حقوقی و بهداشت و درمان که نیازهای سختگیرانه‌ای در زمینه انطباق داده‌ها (Compliance) دارند، حیاتی است.
- ردیابی مختصات در سطح Bbox: استخراج میدان‌های ساختاریافته شامل مختصات دقیق Bbox برای خروجی‌های Markdown، JSON و متن ساده است. این امر ریسک از دست رفتن مختصات را حل کرده و به رابط‌های کاربری اجازه می‌دهد متن را های‌لایت کنند و مدل‌ها را قادر می‌سازد منابع را به دقت ردیابی نمایند.
- پشتیبانی از فرمت‌های متعدد و OCR بیش از ۸۰ زبان: این ابزار PDFها، اسناد اسکن‌شده، تصاویر و فایل‌های Office (Word, PPT, Excel) را به صورت یکپارچه مدیریت کرده و تشخیص خودکار بیش از ۸۰ زبان را پشتیبانی می‌کند.
DocSlight در بنچ‌مارک OmniDocBench امتیاز ۹۶.۴۵ را کسب کرده و از مدل‌هایی مانند MinerU2.5-Pro، GLM-OCR و PaddleOCR-VL پیشی گرفته است. در مقایسه با سایر مدل‌های پیشرو، رقابت میان olmOCR و GPT-4o نشان‌دهنده برتری در دقت استخراج داده‌های پیچیده و کاهش شدید هزینه‌هاست. این ابزار همچنین توسط ComPDF Self-Hosted تکمیل می‌شود که یک پلتفرم ویرایش و تبدیل PDF با قابلیت نصب یک‌کلیکی در Docker است. با خودکارسازی زمان‌بندی ابزارهای مختلف پارسینگ، DocSlight از اینکه توسعه‌دهندگان مجبور باشند به صورت دستی کتابخانه‌های پراکنده را برای مدیریت مشکلاتی نظیر اصلاحات دست‌نویس یا عدم تطابق ارجاعات صفحات سرهم کنند، جلوگیری می‌کند.
برای توسعه‌دهندگان، این تغییر به این معناست که معیار «پارسینگ موفق» از استخراج ساده متن به «بازسازی دقیق مختصاتی» تغییر یافته است. توانایی همگام‌سازی پاسخ معنایی یک LLM با یک های‌لایت بصری روی صفحه PDF، اکنون خط پایه برای سیستم‌های RAG در سطح تجاری (Production-grade) است.
اگر در حال ساخت یک خط لوله پردازش سند هستید، گام بعدی این است که ارزیابی کنید آیا پارسر فعلی شما داده‌های کادر محصورکننده (Bbox) را حفظ می‌کند یا اینکه مدل شما صرفاً در حال حدس زدن شماره صفحات است.
گام بعدی شما
- بررسی کنید آیا پارسر فعلی شما داده‌های Bbox را حفظ می‌کند یا مدل شما صرفاً در حال حدس زدن شماره صفحات است.
- اگر با اسناد حقوقی یا مالی حساس سروکار دارید، مدل‌های VLM محلی را برای جلوگیری از نشت داده‌ها تست کنید.
- خروجی‌های Markdown خود را با مختصات متناظر در فایل اصلی تطبیق دهید تا نرخ توهم ارجاعات را اندازه‌گیری کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو