اگر مدرک اشتباه خوانده شود، پاسخ مستند هم میتواند غلط باشد
یک دستیار ممکن است به صفحهٔ درست قرارداد استناد کند، اما مبلغ را از متنی بخواند که OCR یک رقمش را اشتباه تشخیص داده است. در این وضعیت، وجود شمارهٔ صفحه بهتنهایی صحت عدد را ثابت نمیکند. مشکل پیش از مرحلهٔ پاسخ شروع شده و باید در مسیر ورود دانش دیده شود.
در سناریوی آموزشی این مقاله، مجموعهای از نامهها و جدولهای خرید با دادهٔ ساختگی بررسی میشوند. برای هر ادعا میپرسیم آیا متن و ساختارِ استخراجشده همان چیزی است که بازبین در تصویر میبیند. این رویکرد، مقایسهٔ مدلها را از مشاهدهٔ چند صفحهٔ تمیز به ارزیابی خطاهای مؤثر بر تصمیم سازمانی تبدیل میکند.
نمونهٔ مرجع نمایندهٔ اسناد واقعی باشد
صفحههای تمیز، کج، کمرنگ و چندستونه را از گروههای مختلف سند انتخاب کنید. جدول چندصفحهای، مهر روی متن، سربرگ، پاورقی و ترکیب فارسی با شناسهٔ لاتین را جدا برچسب بزنید. اگر بیشتر حجم واقعی نامههای قدیمی است، نمونهای که تقریباً همهاش PDF دیجیتال است نمایندهٔ کاربرد نیست.
برای هر نمونه، متن مرجع، ترتیب خواندن و فیلدهای حیاتی را با بازبین حوزه تهیه کنید. دادهٔ حساس را فقط در محدودهٔ مجاز بررسی کنید؛ برای نمایش عمومی از نمونهٔ ساختگی یا نمونهٔ دارای مجوز استفاده شود. بخشی از اسناد را تا پایان مقایسه کنار نگه دارید تا تنظیمات به همان چند تصویر نمونه وابسته نشود.
پشتیبانی از فارسی را برای همان مدل و همان ویژگی بررسی کنید
فهرست زبان Microsoft، پشتیبانی Read و Layout را بر حسب مدل و ویژگی تفکیک میکند. از وجود نام فارسی در یک جدول، پشتیبانی یکسان از دستخط، جدول، فرم و همهٔ مدلهای آماده را نتیجه نگیرید. نسخهٔ سرویس و مسیر انتخابشده باید در گزارش آزمون مشخص باشد.
در سناریوی خرید، متن چاپی، یادداشت دستنویس و تشخیص محل امضا سه مسئلهٔ متفاوتاند. حتی اگر متن چاپی درست استخراج شود، نباید از آن نتیجه گرفت که اصالت امضا تأیید شده است. پذیرش هر قابلیت باید شاهد مستقل داشته باشد و نتیجهٔ نامطمئن به مسیر بازبینی مناسب برود؛ افزودن یک برچسب «هوشمند» این تفاوتها را از بین نمیبرد.
اصلاح نوشتار را از تغییر مدرک جدا کنید
تفاوت ی و ک عربی و فارسی، فاصله و نیمفاصله و شکل ارقام میتواند بر جستوجو اثر بگذارد. استاندارد Unicode برای همارزیهای مشخص، صورتهای نرمالسازی تعریف میکند؛ اما هر نگاشت دلخواه سازمانی، از جمله تبدیل شکل اعداد یا حروف، صرفاً با انتخاب یک فرم Unicode انجام نمیشود. آن قواعد را جدا و صریح بنویسید.
نسخهٔ اصلی متن و تصویر را نگه دارید و متن مناسب جستوجو را به آن پیوند دهید. در نمونهٔ پیشنهادی، یکسانسازی برای یافتن واژه مجاز است، اما اصلاح خودکار شمارهٔ قرارداد یا تاریخ بدون شاهد پذیرفته نیست. نشان دهید هر عبارت بازیابیشده از کدام محدودهٔ صفحه آمده تا بازبین بتواند عدد مهم را با مدرک تطبیق دهد.
صحت جدول فقط مجموع واژههای درست نیست
اگر مقدار ستون «مالیات» زیر عنوان «مبلغ کل» قرار بگیرد، ممکن است تمام رقمها درست خوانده شده باشند اما گزارش نهایی غلط شود. برای جدول، اتصال ردیف و ستون، عنوانهای چندسطحی، ادامهٔ صفحه و واحد اندازهگیری را بسنجید. ترتیب خواندن پاراگراف و جدول هم میتواند معنی جملهٔ بعدی را تغییر دهد.
برای آزمون آموزشی، یک جدول با دو ردیف مشابه و واحدهای متفاوت بسازید. مقدار را همراه با عنوان ردیف، ستون، واحد و شماره صفحه مقایسه کنید. بازسازی ظاهری یک جدول زیبا بدون این روابط، معیار موفقیت نیست. در موارد مبهم، نمایش تصویرِ محدودهٔ جدول به بازبین میتواند از حدسزدن رابطهها مناسبتر باشد.
سه سطح کیفیت را جدا گزارش کنید
در سطح متن، نرخ خطای نویسه و واژه کمک میکنند کیفیت رونویسی را بسنجیم؛ در سطح فیلد، صحت مبلغ، تاریخ و شناسه را جدا بررسی کنید؛ در سطح کاربرد، ببینید آیا سؤال کارمند با مدرک درست پاسخ میگیرد. میانگین خوب متن میتواند خطای بدی را در چند فیلد حیاتی پنهان کند.
تعداد نمونه و روش محاسبه را گزارش کنید. برای مقایسهٔ فارسی، مشخص کنید فاصله، نیمفاصله و شکل اعداد پیش از امتیازدهی چگونه در نظر گرفته شدهاند. دو ابزار را یک بار با قواعد سختگیرانه و یک بار با نگاشتهای از پیش تعریفشده مقایسه کنید؛ تفاوت دو گزارش نشان میدهد چه میزانِ خطا ظاهری و چه میزان برای کاربرد معنادار است.
امتیاز کیفیت، تضمین صحت تمام فیلدها نیست
Google Cloud برای کیفیت تصویر و عیبهایی مانند تاری و بریدگی، شاخص و محدودیتهای مشخص توضیح میدهد. امتیاز کیفیت تصویر را با احتمال درستبودن مبلغ یا همهٔ واژهها برابر نگیرید. یک صفحهٔ خوانا هم ممکن است جدول دشوار داشته باشد و یک ناحیهٔ کمکیفیت میتواند تنها فیلد حیاتی را بپوشاند.
پیشنهاد این مقاله مسیریابی بر اساس ترکیب نوع عیب و اهمیت فیلد است. نامهٔ کماهمیت ممکن است دوباره پردازش شود، اما اختلاف در مبلغِ سند خرید به بازبین میرود. آستانهها را با نمونههای برچسبخوردهٔ خود سازمان تنظیم کنید و اثر آنها بر کار انسانی و تأخیر را نشان دهید؛ عدد ثابت جهانی برای همهٔ اسناد انتخاب نکنید.
آزمون نهایی را از تصویر تا پاسخ ادامه دهید
پس از انتخاب تنظیمات، همان اسناد را وارد مسیر قطعهبندی و جستوجو کنید. پرسشهایی طراحی کنید که به جدول، استثنای یک بند یا عدد مشخص وابستهاند. بررسی کنید متنِ درست بازیابی شده، استناد به صفحهٔ درست میرسد و پاسخ از مقدار استخراجشدهٔ نامعتبر استفاده نمیکند. این مرحله نشان میدهد بهبود OCR واقعاً به تجربهٔ کاربر رسیده است یا نه.
تحویل نهایی شامل دستهبندی اسناد، نسخهٔ ابزار، مجموعهٔ مرجع، خطاهای فیلدی و سیاست بازبینی باشد. نمونههای دشوار را حفظ کنید تا تغییر ابزار یا پیشپردازش در آینده با همان معیار سنجیده شود. محتوای حاضر راهنمای ارزیابی است، نه ادعای دقت معین برای OCR فارسی یا وعدهٔ قابلیت مستقر در محصولی خاص.
برای ادامهٔ این بحث، مقالهٔ «چطور پاسخ هوش مصنوعی را به اسناد سازمان متصل کنیم؟» را در دانشنامهٔ لیان بخوانید.
پرسشهای متداول
آیا PDF دیجیتال هم به OCR نیاز دارد؟
ابتدا امکان استخراج متن و ساختار موجود را بررسی کنید. بازشناسی تصویریِ بیدلیل میتواند هزینه و خطای اضافه ایجاد کند؛ مسیر درست به کیفیت فایل بستگی دارد.
آیا Confidence بالا یعنی مبلغ حتماً درست است؟
خیر. امتیاز کیفیت یا اطمینان را با صحت تأییدشدهٔ فیلد یکی نگیرید. مبلغ، واحد و ارتباط آن با ردیف و ستون باید ارزیابی شوند.
آیا تشخیص محل امضا، اصالت آن را ثابت میکند؟
خیر. یافتن متن یا ناحیهٔ امضا با احراز اصالت یا اختیار امضاکننده تفاوت دارد و به فرایند مستقل نیاز دارد.
منابع و مطالعهٔ پژوهشی
- Google CloudEnterprise Document OCROfficial documentation · image-quality analysis and limitations
- MicrosoftLanguage and locale support for Read and LayoutOfficial documentation · model-specific language support
- Unicode ConsortiumUnicode Normalization FormsUnicode Standard Annex #15
مطالعهٔ بیشتر در دانشنامهٔ لیان
- لیان داتا پارسچطور پاسخ هوش مصنوعی را به اسناد سازمان متصل کنیم؟برای ادامهٔ بحث پاسخ مستند، آمادهسازی اسناد و سنجش جداگانهٔ کیفیت بازیابی و صحت پاسخ را در دانشنامهٔ لیان بخوانید.