یک جدول PDF ممکن است برای انسان روشن باشد و پس از استخراج متن به چند خط نامرتب تبدیل شود. اگر عنوان ستون، واحد اندازه‌گیری یا پاورقی از مقدار جدا شود، سامانهٔ هوش مصنوعی می‌تواند پاسخ روانی بسازد که رابطهٔ داده‌ها را درست حفظ نکرده است. این راهنما یک مسیر پیشنهادی برای آماده‌سازی جدول‌های PDF جهت جست‌وجو و پاسخ‌گویی ارائه می‌کند. مثال جدول خدمات فرضی است و نتیجهٔ پردازش محصول یا سند مشتری نیست.
مستندات استخراج متن PyMuPDF دربارهٔ ترتیب خواندن و شناسایی جدول توضیح می‌دهد؛ راهنمای OCR همان ابزار نیز برای شناخت مسیر تبدیل تصویر به متن مفید است. امکانات کتابخانه را باید روی نمونهٔ واقعی سند آزمود. این مقاله روش پیشنهادی کنترل کیفیت داده را شرح می‌دهد، نه تضمین استخراج صحیح همهٔ جدول‌ها.
۱. نوع صفحه و هدف استخراج را تشخیص دهید
بررسی را از چند صفحهٔ نماینده آغاز کنید. بعضی PDFها متن قابل انتخاب دارند، بعضی عمدتاً تصویر اسکن‌شده‌اند و بعضی هر دو را در صفحات مختلف ترکیب می‌کنند. یک نتیجهٔ خالی از استخراج متن، به‌تنهایی نوع همهٔ صفحات را ثابت نمی‌کند. صفحهٔ چرخیده، متن با ساختار نامعمول یا محتوای محدود نیز باید بررسی شود. پیشنهاد ما ثبت تصمیم در سطح صفحه است، نه یک برچسب عجولانه برای کل فایل.
هدف استفاده را نیز بنویسید. جست‌وجوی نام خدمت با پاسخ به سؤال دربارهٔ شرط ارائهٔ همان خدمت نیاز یکسانی ندارد. در مثال فرضی، جدول نام خدمت، مهلت و توضیح محدودیت دارد. اگر فقط نام‌ها استخراج شوند، جست‌وجو شاید نتیجه پیدا کند، اما پاسخ دربارهٔ مهلت می‌تواند اطلاعات ناکافی داشته باشد. دادهٔ لازم باید از پرسش‌های واقعیِ مورد انتظار مشخص شود.
فایل اصلی و نسخهٔ آن را در مسیر بررسی نگه دارید. عنوان سند، شمارهٔ صفحه و شناسهٔ نسخه به بازبین کمک می‌کند مقدار استخراج‌شده را به منبع برگرداند. مسیر فایل روی رایانهٔ توسعه‌دهنده، شناسهٔ پایدار منبع نیست. در پیشنهاد طراحی، هر نتیجهٔ جدول به سند و صفحهٔ معلوم وابسته است تا پس از تغییر فایل، دادهٔ قدیمی با نسخهٔ تازه اشتباه نشود.
۲. ساختار جدول را از ترتیب سادهٔ متن جدا کنید
در PDF، ظاهر جدولی الزاماً یک شیء صفحه‌گستردهٔ آماده نیست. مستندات PyMuPDF توضیح می‌دهد که شناسایی محدوده و ستون‌های جدول بخشی از کار استخراج است. همچنین ترتیب متن ذخیره‌شده همیشه با ترتیب خواندن بصری یکسان نیست. بنابراین خروجی چند خط متن را پیش از استفاده در پاسخ‌گویی با صفحهٔ اصلی مقایسه کنید؛ خوانا بودن جمله‌ها کافی نیست.
در روش پیشنهادی، ابتدا محدودهٔ جدول و عنوان‌های ستون مشخص می‌شوند و سپس رابطهٔ هر سلول با سطر و ستون ثبت می‌شود. جدول‌های بدون خط مرزی یا دارای سلول ادغام‌شده به بازبینی دقیق‌تری نیاز دارند. برای مثال، یک عنوان بالای دو ستون نباید فقط به ستون سمت راست نسبت داده شود. نتیجهٔ ماشینی می‌تواند پیشنهاد ساختار بدهد، اما انتخاب روش باید با نمونه‌های مسئله‌دار همان سند سنجیده شود.
ردیف عنوان تکرارشده در صفحهٔ بعد را نیز بررسی کنید. ممکن است جدول ادامه داشته باشد و عنوان دوباره به عنوان یک ردیف داده وارد خروجی شود. در طراحی پیشنهادی، ادامهٔ جدول با عنوان ستون و موقعیت صفحه شناخته می‌شود و تصمیم ادغام قابل بازبینی است. ادغام صرفاً بر اساس مشابهت چند واژه می‌تواند دو جدول متفاوت را به اشتباه یکی کند.
۳. OCR را هدفمند و با بازبینی مقدارهای حساس به کار ببرید
اگر دادهٔ لازم در تصویر قرار دارد، مسیر OCR می‌تواند مطرح شود. راهنمای PyMuPDF امکان OCR صفحه یا ناحیه‌های تصویری و استفادهٔ دوباره از نتیجهٔ آماده‌شده را توضیح می‌دهد. این انتخاب به ابزار و پیش‌نیازهای نصب وابسته است. OCR را برای همهٔ صفحات صرفاً از روی عادت اجرا نکنید؛ هزینه و کیفیت آن باید با نیاز و وجود متن قابل استفاده سنجیده شود.
رقم، واحد و علامت منفی را جدا کنترل کنید. در جدول فرضی مهلت خدمت، اشتباه شدن یک رقم می‌تواند معنی پاسخ را عوض کند. متن فارسی و لاتین، جداکنندهٔ اعشار و ترتیب خواندن نیز باید در نمونه‌های بازبینی وجود داشته باشند. پیشنهاد مقاله، فهرست فیلدهای حساس و قاعدهٔ کنترل انسانی برای موارد مبهم است؛ روان بودن خروجی OCR دلیل صحت مقدارها نیست.
تغییر وضوح یا پاک‌سازی تصویر را با نسخهٔ اولیه مقایسه کنید. بهبود ظاهر ممکن است بخشی از علامت ریز یا پاورقی را حذف کند. در مسیر پیشنهادی، نسخهٔ تبدیل‌شده برای استخراج و نسخهٔ منبع برای بازبینی جدا باقی می‌مانند. اگر کیفیت کافی نیست، نتیجه را نامعلوم علامت‌گذاری کنید و آن را به عدد قطعی تبدیل نکنید. مدل زبانی نباید مقدار ناخوانا را از روی الگوی جدول حدس بزند.
۴. عنوان، واحد و پاورقی را همراه داده نگه دارید
یک سلول بدون زمینه می‌تواند معنی ناقصی داشته باشد. مقدار «۵» شاید روز، درصد یا شمارهٔ دسته باشد. در طرح پیشنهادی، هر رکورد قابل جست‌وجو نام ستون، عنوان جدول و واحد مرتبط را همراه دارد. این زمینه را با مقدار اصلی اشتباه نگیرید؛ بهتر است فیلدهای جدا باشند تا برنامه و بازبین بتوانند رابطه را ببینند و در صورت نیاز اصلاح کنند.
پاورقی را به ردیف‌های مرتبط وصل کنید. اگر مهلت جدول فقط در شرایط مشخصی معتبر است، حذف این قید می‌تواند پاسخ را تغییر دهد. پیشنهاد عملی این است که ابتدا رابطهٔ علامت پاورقی با سطرها مشخص شود و سپس متن شرط در رکورد مرتبط قرار گیرد. افزودن همهٔ پاورقی‌ها به همهٔ ردیف‌ها نیز می‌تواند شرط نادرست بسازد؛ رابطهٔ واقعی در صفحه باید مبنای تصمیم باشد.
برای ورود به پایگاه دانش، بخش‌بندی را با رابطهٔ داده طراحی کنید. شکستن جدول صرفاً پس از تعداد ثابت نویسه‌ها ممکن است عنوان را از مقدار جدا کند. یک رکورد ساختگیِ مناسب می‌تواند نام خدمت، مهلت، واحد، شرط و ارجاع صفحه را در کنار هم داشته باشد. این شکل پیشنهادی است و باید با سؤال‌های مقصد بررسی شود؛ بزرگ کردن بخش‌ها نیز همیشه مشکل رابطه را حل نمی‌کند.
۵. کیفیت را با سؤال و ارجاع به صفحهٔ اصلی بسنجید
مجموعهٔ آزمون را از سؤال‌های مشخص بسازید: مهلت یک خدمت، شرط یک ردیف و تفاوت دو گزینه. برای هر سؤال، پاسخ مرجع را از سند اصلی بازبینی کنید و شمارهٔ صفحه را ثبت کنید. سپس بررسی کنید که بازیابی رکورد درست را انتخاب کرده و پاسخ، واحد و شرط را حفظ کرده باشد. خطای استخراج، خطای بازیابی و خطای نگارش پاسخ سه مسئلهٔ جدا هستند.
یک نمونهٔ مبهم یا ناخوانا نیز در آزمون داشته باشید. انتظار می‌رود سامانه در نبود دادهٔ قابل اتکا، محدودیت را بیان کند یا به مسیر بررسی ارجاع دهد. اگر همهٔ نمونه‌ها جدول تمیز تک‌صفحه‌ای باشند، نتیجه چیزی دربارهٔ جدول چندصفحه‌ای و پاورقی پیچیده نمی‌گوید. گزارش باید دامنهٔ اسناد و نوع ساختارهای بررسی‌شده را توضیح دهد.
پس از تغییر سند یا ابزار استخراج، نمونه‌های مرزی را دوباره اجرا کنید. یک گزارش کوتاه از نسخهٔ فایل، روش استخراج، موارد بازبینی‌شده و محدودیت باقی‌مانده آماده کنید. جدول آمادهٔ پاسخ‌گویی فقط مجموعه‌ای از واژه‌ها نیست؛ رابطهٔ عنوان، مقدار، واحد و شرط باید قابل پیگیری بماند تا مخاطب بتواند پاسخ را به منبع اصلی برگرداند.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۲ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
