مشکل اینه که حتی اگه متن PDF قابل انتخاب باشه، لزوماً درست استخراج نمیشه. ممکنه ترتیب کلمات برعکس بشه، ستونهای جدول قاطی بشن یا عددی به سطر اشتباه نسبت داده بشه. برای RAG این خطاها خطرناکن، چون مدل ممکنه با اعتمادبهنفس کامل روی اطلاعات اشتباه جواب بده!
برای حل این مسئله سراغ یه معماری *Adaptive PDF Extraction** رفتم. ایده اینه که بهجای استفاده از یه OCR یا مدل برای همه اسناد، براساس وضعیت هر صفحه تصمیم بگیریم چه روشی مناسبتره.
معماری کلی به این شکله:
۱. استخراج اولیه با PyMuPDF
اول با PyMuPDF متن و ساختار اولیه هر صفحه رو استخراج میکنیم. بعد بررسی میکنیم آیا Text Layer واقعاً معتبره یا نه. صرفاً وجود متن کافی نیست؛ ترتیب RTL، کاراکترهای خراب و اعداد هم مهمن.
اگه متن سالم باشه، دلیلی نداره دوباره هزینه OCR یا LLM بدیم. ضمن اینکه Bounding Box کلمات و شماره صفحات رو هم حفظ میکنیم تا بعداً توی RAG بتونیم به منبع اصلی ارجاع بدیم.
۲. بازسازی ساختار با Docling
برای صفحاتی که جدول، چند ستون یا Layout پیچیده دارن، Docling وارد میشه. مزیتش اینه که فقط متن خام نمیده و سعی میکنه ساختار سند رو هم بازسازی کنه.
البته Docling هم برای فارسی بینقص نیست. مخصوصاً Reading Order و RTL ممکنه مشکل داشته باشن و خروجی باید اعتبارسنجی بشه.
۳. استفاده از Gemini بهعنوان Fallback
وقتی Text Layer خراب باشه یا صفحه اسکنشده باشه، میتونیم از قابلیت Native PDF Understanding در Gemini استفاده کنیم.
تفاوتش با OCR سنتی اینه که Gemini علاوه بر متن، چیدمان بصری صفحه رو هم درک میکنه. برای متنهای فارسی پیچیده و جدولها قابلیت مفیدیه، اما یه ریسک جدید اضافه میکنه: مدل ممکنه بهجای رونویسی دقیق، متن رو اصلاح کنه یا حتی چیزی از خودش اضافه کنه.
برای همین Prompt باید صریحاً از مدل بخواد متن رو بدون ترجمه، خلاصهسازی یا اصلاح بازنویسی کنه و بخشهای ناخوانا رو مشخص کنه.
۴. اعتبارسنجی و Normalization
این قسمت بهاندازه خود استخراج مهمه. دو نسخه از متن نگه میداریم:
- Raw Text:
متن اصلی برای بررسی و ارجاع.
- Normalized Text:
نسخه استانداردشده برای Search و Embedding، مثلاً یکسانسازی
ي/ی و ك/ک و مدیریت نیمفاصله.برای اطلاعات حساس مثل مبلغ، تاریخ و شمارهها هم نباید صرفاً به خروجی LLM اعتماد کرد. این فیلدها نیاز به بررسی مستقل دارن.
از نظر من، برای Production بهتره اول روشهای سادهتر رو تست کنیم و فقط وقتی واقعاً نیاز شد سراغ Pipeline پیچیدهتر بریم.
برای ارزیابی هم فقط CER و WER کافی نیستن. باید دقت اعداد، ترتیب RTL، ساختار جدولها، ارجاع به صفحات، هزینه و Latency رو جداگانه اندازه بگیریم.
درس اصلی این تجربه برای من این بود: PDF Extraction فقط OCR نیست؛ یه مسئله Document Understanding و Data Quality هم هست.
توی سیستمهای RAG، کیفیت خروجی هیچوقت نمیتونه مستقل از کیفیت اطلاعات ورودی باشه. گاهی اصلاح Pipeline استخراج سند، از عوضکردن Embedding Model یا LLM تأثیر مهمتری روی قابلاعتمادبودن پاسخها داره.
🛠 Join @LLMEngineers Community