تبدیل PDF به Markdown؛ راهکار Nutrient برای رفع خطاهای بازیابی در RAG

اگر امروز یک سیستم پاسخ‌گویی به اسناد داخلی می‌سازید، احتمالاً متوجه شده‌اید که مدل شما با وجود دسترسی به فایل‌ها، هنوز پاسخ‌های ناقص یا اشتباه می‌دهد. مشکل اصلی معمولاً در مدل بازیابی نیست، بلکه در لحظه‌ای است که متن خام PDF را بدون درک ساختاری به خورد یک تکه‌بندی ساده می‌دهید. یک PDF به‌ظاهر ساده اما نامنظم می‌تواند به‌سادگی کل یک خط لوله RAG در محیط عملیاتی را با تبدیل داده‌های ساختاریافته به نویز، از کار بیندازد.

بسیاری از توسعه‌دهندگان تصور می‌کنند کیفیت بازیابی (Retrieval) مشکل اصلی است، اما شکست واقعی در مرحله ورود داده (Ingestion) رخ می‌دهد، جایی که متن خام PDF در یک تکه‌بند ساده (Naive Text Splitter) رها می‌شود. همان‌طور که در تحلیل قبلی ما درباره‌ی استخراج دقیق داده‌ها در غربال‌گران رزومه AI اشاره کردیم، جایی که استخراج دقیق داده‌ها کلید موفقیت است، چالش اصلی با PDFها این است که آن‌ها برای مصرف مدل‌های زبانی بزرگ (LLM) طراحی نشده‌اند. در حالی که یک دموی ساده با سه فایل تمیز ممکن است درست کار کند، اما در مقیاس تولید، سند شماره ۴۷ معمولاً فاش می‌کند که جداول تخت شده‌اند و تیترها از محتوایشان جدا شده‌اند. وقتی متن خام PDF را به یک تکه‌بند می‌دهید، اینجاست که اکثر خط لوله‌های RAG به‌آرامی می‌شکنند: جداول در وسط ردیف‌ها تکه تکه می‌شوند، تیترها ناپدید می‌شوند و تکه‌ها بافت و زمینه خود را گم می‌کنند.

در ۲۴ ژوئیه ۲۰۲۶، یک راهنمای فنی توضیح داد که چگونه SDK پایتون nutrient_dws این گردش کار را تغییر می‌دهد. این ابزار با تبدیل مرحله ورود داده به یک مرحله ساختاری اختصاصی به‌جای یک دستور تک‌خطی، رویکرد را دگرگون می‌کند. طبق گزارش وب‌سایت dev.to، راهکار این مشکل یک الگوریتم تکه‌بندی بهتر نیست، بلکه تبدیل PDF به مارک‌داون (Markdown) — شبیه تبدیل یک نامه دست‌نویس به یک فایل متنی منظم با تیتر و لیست — پیش از هرگونه تکه‌بندی است تا سلسله‌مراتب ذاتی سند حفظ شود.

مکانیزم شکست در ورود داده

خط لوله‌های ساده معمولاً متن خام را با یک کتابخانه عمومی PDF استخراج کرده و آن را هر N کاراکتر جدا می‌کنند. این روش برای فایل‌های متنی ساده خوب است، اما در PDFهای واقعی به دلیل سه شکست مشخص، ناکارآمد است:

• تخت شدن جداول: یک جدول به صورت یک خط تکه‌ای از اعداد تبدیل می‌شود که هیچ مرز ستونی ندارد. در نتیجه، تکه بازیابی‌شده برای مدل غیرقابل خواندن است.
• قطع شدن بافت: یک تیتر در انتهای یک تکه به‌تنهایی قرار می‌گیرد، در حالی که محتوای واقعی آن در تکه بعدی شروع می‌شود. سیستم بازیابی محتوا را پیدا می‌کند، اما مدل هرگز نمی‌بیند که این محتوا به کدام بخش یا تیتر تعلق دارد.
• ادغام چیدمان: چیدمان‌های چندستونی به‌صورت نامنظم با هم ادغام می‌شوند. این منجر به ایجاد تکه‌ای می‌شود که شامل نیمی از یک پاراگراف و نیمی از یک پاراگراف کاملاً بی‌ربط دیگر است.

پیاده‌سازی با SDK Nutrient

برای حل این مشکل، SDK شرکت Nutrient از فراخوانی parse() با حالت mode="text" و فرمت خروجی output_format="markdown" برای PDFهای دیجیتال (Born-digital) استفاده می‌کند. بر اساس مستندات این ابزار، این فرآیند برای هر صفحه ۱ اعتبار هزینه دارد و PDF را به ساختاری تبدیل می‌کند که در آن تیترها، لیست‌ها و جداول به‌جای یک توده متنی تخت، با سینتکس واقعی مارک‌داون حفظ شوند.

برای مثال، این SDK داده‌های PDF را به فرمت‌های ساختاریافته‌ای تبدیل می‌کند، مانند:
# Employee Handbook
## Time Off Policy
Full-time employees accrue 1.5 days of PTO per month...
| Tenure | Annual PTO |
|--------|-----------|
| 0–2 years | 15 days |
| 3–5 years | 20 days |

در این ساختار، مدل به‌راحتی مرزهای داده را تشخیص می‌دهد. برای اسناد اسکن‌شده، توسعه‌دهنده باید حالت را به mode="structure" تغییر دهد. این کار یک مرحله نویسه‌خوانی نوری (OCR) یکپارچه را قبل از تبدیل به مارک‌داون فعال می‌کند. این قابلیت نیاز به نگهداری و مدیریت یک خط لوله OCR جداگانه برای PDFهای تصویر-محور را کاملاً از بین می‌برد.

استراتژی تکه‌بندی ساختاری

پس از تولید مارک‌داون، سیستم از یک تکه‌بند آگاه از تیترها (Heading-aware chunker) استفاده می‌کند. این بخشی است که اکثر آموزش‌ها نادیده می‌گیرند، اما تعیین می‌کند که تکه‌های بازیابی‌شده معنادار باشند یا قطعاتی گسسته و بی‌معنی.

منطق تکه‌بندی:

• تقسیم اولیه: سیستم سند را بر اساس تیترهای مارک‌داون (با استفاده از regex برای سطوح #، ## و ###) می‌شکند. این کار تضمین می‌کند هیچ تکه‌ای هرگز از مرز یک بخش عبور نکند و محتوا با تیترش همراه بماند.
• تقسیم ثانویه: اگر یک بخش برای بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که همسایگانش را مشخص می‌کند — بیش از حد طولانی باشد (مثلاً در صورتی که از حد max_chars یا ۱۵۰۰ کاراکتر فراتر رود)، سیستم روی شکست‌های پاراگراف (\n\n) تقسیم می‌کند.
• مدیریت بافر: تکه‌بند از یک بافر برای جمع‌آوری پاراگراف‌ها استفاده می‌کند. این یعنی سیستم تنها زمانی که محدودیت کاراکتر تکمیل شود تقسیم را انجام می‌دهد تا یکپارچگی پاراگراف‌ها حفظ گردد.

این روش تضمین می‌کند هر تکه بازیابی‌شده به یک بخش منسجم از سند منبع اشاره دارد — مانند یک جدول کامل با تمام ردیف‌های دست‌نخورده یا یک بخش خاص از سیاست‌های شرکت — به‌جای اینکه فقط یک پنجره کاراکتری تصادفی باشد.

مدیریت چیدمان‌های پیچیده

تکه‌بندی مارک‌داون اکثر نیازهای تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را پوشش می‌دهد. اما برخی اسناد نیاز به پاسخ‌هایی دارند که به ساختار دقیق جدول وابسته است؛ مثلاً سوالاتی مثل «عدد مربوط به سه ماهه سوم در ردیف سوم چه بود؟». در چنین مواردی، حتی تبدیل جدول به متن مارک‌داون ممکن است باعث از دست رفتن دقت شود.

در این موارد، SDK دو جایگزین پیشرفته ارائه می‌دهد:

• JSON مکانی (Spatial JSON): کاربر می‌تواند به‌جای مارک‌داون، این خروجی را از همان فراخوانی parse() درخواست کند. این مدل، سلول‌های جدول را با ایندکس ردیف/ستون، به همراه کادرهای محدودکننده (Bounding boxes) و نمرات اطمینان (Confidence scores) ارائه می‌دهد. این قابلیت زمانی حیاتی است که نیاز به اعتبارسنجی یا ارجاع دقیق به مکان منبع در سند دارید.
• حالت understand: این حالت برای اسناد با چیدمان‌های بسیار پیچیده، نواحی کلید-مقدار (Key-Value) یا متون دست‌نویس بهینه شده است.

موازنه و محدودیت‌ها

اگرچه این SDK با جایگزینی پارسرهای عمومی و منطق‌های پیچیده بازیابی، پشته تکنولوژی (Tech Stack) را ساده می‌کند، اما محدودیت‌های خاص خود را دارد.

مزایا:

• یک فراخوانی SDK جایگزین پارسرهای PDF عمومی و منطق‌های سفارشی برای بازیابی جداول و تیترها می‌شود.
• خروجی مارک‌داون به‌طور پیش‌فرض با تکه‌بندها سازگار و دوستانه است.
• حالت mode="structure" اسناد اسکن‌شده را بدون نیاز به OCR خارجی مدیریت می‌کند.
• امکان دریافت Spatial JSON توسط همان کلاینت برای نیازهای ساختاری دقیق وجود دارد.

معایای:

• خروجی‌های مارک‌داون و JSON مکانی جدا از هم هستند؛ شما باید از ابتدا تصمیم بگیرید سند به کدام‌یک نیاز دارد یا دو درخواست جداگانه ارسال کنید.
• حالت mode="text" مخصوص PDFهای دیجیتال است؛ اسناد اسکن‌شده به mode="structure" نیاز دارند که کندتر است و هزینه بیشتری دارد.
• تکه‌بندهای ساده‌ی آگاه از تیتر ممکن است در مواجهه با اسنادی که تیترهای بسیار تو در تو (Deeply nested) دارند، دچار مشکل شوند.

برای توسعه‌دهندگان، این تغییر به معنای گذار از «حدس زدن تعداد کاراکترها» به «تقسیم بر اساس ساختار» است. این تغییر بنیادی در معماری ورود داده، از شکست‌های رایج در محیط عملیاتی جلوگیری می‌کند؛ جایی که مدل تکه‌های گسسته و بی‌ربط را دریافت کرده و در نتیجه دچار توهم (Hallucination) — مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — می‌شود.

اگر در حال ساخت یک پایگاه دانش داخلی، سند سیاست‌های organizacyj یا دفترچه راهنمای فنی هستید، بزرگ‌ترین اهرم کیفیت شما دیگر مدل بردار (Embedding Model) نیست، بلکه تمیزی تبدیل به مارک‌داون است. پیشنهاد می‌شود خط لوله فعلی خود را با یک PDF چندستونی آزمایش کنید تا ببینید تکه‌های شما واقعاً منسجم هستند یا خیر.

برای بهینه‌سازی بیشتر، اثر جست‌وجوی ترکیبی (Hybrid Search) شامل جست‌وجوی برداری و کلیدواژه‌ای را روی این تکه‌های ساختاریافته بررسی کنید تا ببینید آیا تیترهای مارک‌داون باعث بهبود بازخوانی کلیدواژه‌ها می‌شوند یا خیر.

گام بعدی شما

• خط لوله فعلی خود را با یک PDF دارای جداول پیچیده و ستون‌های متعدد تست کنید تا نرخ شکست تکه‌بندی را بسنجید.
• اگر نیاز به ارجاع دقیق (Citation) دارید، خروجی Spatial JSON را جایگزین مارک‌داون کنید.
• برای بهینه‌سازی بیشتر، اثر جست‌وجوی ترکیبی (برداری + کلیدواژه‌ای) را روی تکه‌های ساختاریافته مارک‌داون بررسی کنید تا بازخوانی تیترها را بسنجید.

این تنها آغاز ماجراست؛ اثر موج‌گونه‌ی این تصمیم بر اکوسیستم متن‌باز را در گزارش بعدی بررسی خواهیم کرد.