TGViewer
AI Engineers AI Engineers @llmengineers · 2.62K subscribers
Post #531 559
توی یکی از پروژه‌هام با یه مشکل نسبتاً جدی روبه‌رو شدم: استخراج دقیق متن از PDFهای فارسی برای استفاده توی RAG. چیزی که در ظاهر ساده‌ست، ولی وقتی پای اسناد واقعی، جدول‌ها، متن‌های راست‌به‌چپ و اعداد وسط باشه، داستان خیلی پیچیده‌تر می‌شه.

مشکل اینه که حتی اگه متن 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
  • 👍 15
  • ❤ 5
More from @llmengineers
  1. Oct 8, 2026از نظر کاربرد Decision Modelها , قضیه دیگه فقط چند Demo نیست و چند الگوی مشخص واقعاً وارد…
  2. Oct 8, 2026کمتر از یک ماه از معرفی Jev گذشته و چیزی که اول شبیه یه مدل خاص برای «تصمیم‌گیری بدون تولی…
  3. Oct 7, 2026جدا از موج Decision Modelها، چند خبر فنی این هفته هست که برای AI Engineerها واقعاً ارزش دن…
  4. Oct 7, 2026photo post
  5. Oct 7, 2026چند روز اخیر پر از خبر AI بود، ولی وقتی تکراری‌ها، لیک‌ها و تغییرات کم‌اهمیت رو کنار بذاری…
  6. Sep 30, 2026جمنای ۴ معرفی شد !
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →