چرا ارجاع دستیار به جای دیگری از سند اشاره می‌کند؟

متن درست همیشه به شاهد درست اشاره نمی‌کند. پیش از نمایش کادر استناد، نسخه سند، شماره صفحه، واحد مختصات و مسیر برش و چرخش تصویر را بررسی کنید.

چرا ارجاع دستیار به جای دیگری از سند اشاره می‌کند؟
نویسنده
تیم ژرف
انتشار
۱۵ مهر ۱۴۰۵
زمان مطالعه
۱۳ دقیقه

بازبین روی منبعِ تاریخ تحویل کلیک می‌کند. دستیار تاریخ را درست نوشته، ولی کادر رنگی روی بند دیگری از سند افتاده است. سرویس استخراج، تصویر بریده و کوچک‌شده را خوانده؛ نمایشگر همان مختصات را روی اسکن اصلی رسم کرده است. از روی جمله روان دستیار نمی‌توان این جابه‌جایی را فهمید.

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

اول مشخص کنید شاهد متعلق به کدام نسخه است

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

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

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

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

درست خواندن با درست اشاره‌کردن فرق دارد

سه پرسش را جدا نگه دارید: آیا سامانه حروف را درست خوانده؟ آیا محل همان حروف را نشان می‌دهد؟ آیا آن عبارت واقعاً از پاسخ پشتیبانی می‌کند؟ تاریخ درست با کادر جابه‌جا، در پرسش دوم شکست خورده است. تاریخِ دقیقاً مشخص‌شده در یک الحاقیه منقضی، ممکن است به پرسش سوم پاسخ ندهد.

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

این تفکیک برای بازبین هم مهم است. وقتی محل شاهد معلوم نیست، نباید از او بخواهیم با دیدن کادر ظاهراً دقیق، حدس بزند سامانه واقعاً به کجا اشاره داشته است. محدودیت را آشکار بنویسید و امکان دیدن زمینه اطراف عبارت را حفظ کنید. کادر فقط راه رسیدن به شاهد است، نه مهر تأیید معنای پاسخ.

چهار عدد بدون واحد و مرجع، نشانی کامل نیست

مقادیر 0.25, 0.50, 0.20, 0.10 به‌تنهایی روشن نمی‌کنند که با نسبت طرفیم، واحد فیزیکی یا بخشی از یک چندضلعی. رکورد مختصات باید مرجع، ابعاد، واحد، مبدأ، جهت محور‌ها و نوع شکل را مشخص کند. نسخه رابط برنامه‌نویسیِ تولیدکننده را نیز ثبت کنید تا تفسیر خروجی بعداً قابل بازسازی باشد.

طبق مرجع BoundingBox در Amazon Textract، فاصله از چپ و بالا و نیز عرض و ارتفاع، نسبت‌هایی از ابعاد صفحه‌اند؛ مبدأ در گوشه بالا و چپ قرار دارد. این نسبت‌ها را باید با ابعاد همان صفحه‌ای گسترش داد که خروجی توصیفش می‌کند، نه با اندازه هر تصویر کوچکی که در دسترس است.

راهنمای پاسخ Azure Document Intelligence برای ناحیه‌ها، شماره صفحه از یک و نقاط چندضلعی در واحد اعلام‌شده صفحه را شرح می‌دهد. این واحد معمولاً برای تصویر پیکسل و برای PDF اینچ است. واحد خروجی را بخوانید؛ فرمول سرویس دیگر را بی‌بررسی کپی نکنید.

لایه تبدیل هر ارائه‌دهنده باید قرارداد خودش را بشناسد. شکل اصلی را برای عیب‌یابی نگه دارید و سپس آن را به دستگاه مختصات داخلی تبدیل کنید. چهار عدد اول یک فهرست نقاط را عرض و ارتفاع فرض نکنید. نبودن واحد یا هویت صفحه، نقص ورودی است؛ اندازه ظاهری اعداد دلیل کافی برای حدس‌زدن آن‌ها نیست.

چرخش را یک بار اعمال کنید و رد آن را نگه دارید

عکس تلفن همراه ممکن است علاوه بر پیکسل‌های ذخیره‌شده، دستور جهت نمایش هم داشته باشد. دو مرحله پردازش شاید با این فراداده رفتار یکسانی نکنند. مستندات exif_transpose در Pillow توضیح می‌دهد که تابع، جهت غیرپیش‌فرض EXIF را روی تصویر اعمال و سپس اطلاعات جهت را حذف می‌کند. در این حالت، دستور چرخش به تغییر پیکسل‌ها تبدیل شده است.

یک روش روشن برای ورود تصویر انتخاب کنید. اگر ابتدا جهت را اصلاح می‌کنید، همان تصویر اصلاح‌شده را به سرویس بدهید و هویتش را در نتیجه استخراج ثبت کنید. اصل مجاز سند و راه تبدیل به آن را حفظ کنید. صرف اینکه بارگذاری اولیه برچسب جهت داشته، دلیل نمی‌شود مختصات خروجی را دوباره بچرخانید.

مسیر را با نام‌های مشخص ثبت کنید: تصویر اصلی، تصویر با جهت اصلاح‌شده، برش، تصویر کوچک‌شده برای تحلیل و سطح نمایش. پس از هر مرحله ابعاد واقعی را بخوانید. چرخش قائمه ممکن است جای عرض و ارتفاع را عوض کند؛ صاف‌کردن کجی ممکن است حاشیه اضافه کند. ابعاد قبلی، شرح قابل اتکایی از تصویر تازه نیستند.

سرویس استخراج هم شاید درون خود تصویر را آماده‌سازی کند. از روی حدس درباره این فرایند، مرجع مختصات پاسخ را تعیین نکنید. قرارداد مستند همان پردازنده و نسخه را بررسی و آزمایش کنید. عملیاتی که برنامه شما انجام داده باید از تبدیل‌هایی که ارائه‌دهنده گزارش کرده متمایز باشد.

لازم نیست همیشه تمام تصویرهای میانی را برای همیشه ذخیره کنید. بعضی کارها با اصل سند و دستور تبدیل بازتولیدپذیر قابل پیگیری‌اند؛ بعضی به همان تصویر دقیق ارسالی نیاز دارند. انتخاب را با توجه به محرمانگی، هزینه ذخیره، قابلیت بازسازی و پیامدِ از دست رفتن وابستگی‌ها انجام دهید. نتیجه تازه استخراج را هم به‌صورت نسخه جدید نگه دارید، نه جایگزین خاموشِ نتیجه قبلی.

یک برش و تغییر اندازه را قدم‌به‌قدم برگردانیم

فرض کنید اسکن اصلی پس از اصلاح جهت، ۲۴۰۰ پیکسل عرض و ۳۲۰۰ پیکسل ارتفاع دارد. برنامه از نقطه‌ای در فاصله ۴۰۰ پیکسل از چپ و ۶۰۰ پیکسل از بالا، ناحیه‌ای به عرض ۱۲۰۰ و ارتفاع ۱۶۰۰ می‌بُرد. سپس برش را برای تحلیل به ۶۰۰ در ۸۰۰ پیکسل کاهش می‌دهد. در این مثال چرخش، حاشیه اضافه یا اصلاح پرسپکتیو نداریم.

فرض دیگر این است که قرارداد پاسخ، مستطیل نسبی را نسبت به همین تصویر تحلیلی می‌دهد: فاصله چپ 0.25، فاصله بالا 0.50، عرض 0.20 و ارتفاع 0.10. نخست نسبت‌ها را در ابعاد تصویر تحلیلی ضرب می‌کنیم. بعد کاهش اندازه را برمی‌گردانیم و در پایان جابه‌جایی ناشی از برش را اضافه می‌کنیم. اگر جابه‌جاییِ تصویر اصلی را زودتر اضافه کنیم، آن هم به‌اشتباه تغییر مقیاس می‌دهد.

مرجع مختصاتفاصله از چپفاصله از بالاعرضارتفاع
تصویر تحلیلی، پیکسل۱۵۰۴۰۰۱۲۰۸۰
برش پیش از کوچک‌سازی، پیکسل۳۰۰۸۰۰۲۴۰۱۶۰
اسکن اصلی، پیکسل۷۰۰۱۴۰۰۲۴۰۱۶۰

پس مستطیل روی منبع اصلی از (700, 1400) تا (940, 1560) امتداد دارد. اگر نسبت‌ها را مستقیم روی کل اسکن اصلی اعمال کنیم، چپ ۶۰۰، بالا ۱۶۰۰، عرض ۴۸۰ و ارتفاع ۳۲۰ به دست می‌آید. این کادر همچنان روی صفحه جا می‌شود و ظاهری معقول دارد؛ ولی شاهد دیگری را نشان می‌دهد.

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

const crop = { x: 400, y: 600, width: 1200, height: 1600 };
const analysis = { width: 600, height: 800 };
const relative = { left: 0.25, top: 0.50, width: 0.20, height: 0.10 };
const scaleX = analysis.width / crop.width;
const scaleY = analysis.height / crop.height;
const source = {
  left: crop.x + relative.left * analysis.width / scaleX,
  top: crop.y + relative.top * analysis.height / scaleY,
  width: relative.width * analysis.width / scaleX,
  height: relative.height * analysis.height / scaleY,
};
// { left: 700, top: 1400, width: 240, height: 160 }

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

برای چرخش و PDF، همه نقاط را تبدیل کنید

در چرخش، جابه‌جاکردن گوشه بالا و چپ و ثابت نگه‌داشتن عرض و ارتفاع کافی نیست. تک‌تک رأس‌های چندضلعی را تبدیل کنید. اگر برای انتخاب با اشاره‌گر به مستطیل هم‌راستا با محور‌ها نیاز دارید، آن را جدا از شکل اصلی بسازید. چنین مستطیلی ممکن است اطراف ناحیه چرخیده فضای بیشتری بگیرد و دقت کمتری داشته باشد.

پیوست مختصات PyMuPDF تفاوت دستگاه‌های PDF و MuPDF، واحد نقطه برابر یک هفتادودوم اینچ و نقش ماتریس تبدیل و معکوس آن را شرح می‌دهد. بنابراین عبارت «مختصات PDF» برای نوشتن یک مبدل کافی نیست. از تبدیل مستند صفحه و کتابخانه رسم استفاده کنید؛ وارونه‌کردن عمومی محور عمودی را نسخه همیشگی حل مسئله ندانید.

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

جزئیات خواندن خروجی نیز مهم‌اند. راهنمای پاسخ Document AI گوگل درباره رأس‌های نرمال‌شده و حذف فیلدهای مختصاتِ صفر از JSON هشدار می‌دهد. در همین قرارداد مشخص، فیلد حذف‌شده ممکن است معنای صفر داشته باشد. این قاعده را در مبدل همان سرویس پیاده کنید؛ همه هندسه‌های غایب را در کل برنامه صفر نکنید. شرطی هم که صفر را مانند «مقدار ناموجود» رد می‌کند، گوشه معتبر را حذف خواهد کرد.

نمایشگر هم مختصات خودش را دارد

رسیدن به مختصات اسکن اصلی پایان کار نیست. نمایشگر باید آن‌ها را به تصویر روی صفحه نگاشت کند. تصویر هم‌اندازه عرض پنل، صفحه وسط‌چین با حاشیه، بوم بزرگ‌نمایی‌شده و تصویر بندانگشتیِ بریده‌شده یک تبدیل مشترک ندارند. پیکسل تصویر، پیکسل ذخیره‌شده بوم و پیکسل چیدمان را از هم جدا کنید. تصویر سند و کادرهای روی آن باید از یک تبدیل نمایش استفاده کنند.

اگر عرض ۲۴۰۰ پیکسلی منبع بدون برش در عرض ۶۰۰ پیکسل چیدمان نمایش داده شود، ضریب افقی یک‌چهارم است. در مثال ما فاصله چپ کادر از لبه خودِ تصویر نمایشی ۱۷۵ پیکسل می‌شود، نه از لبه بیرونی پنل. اگر تصویر وسط‌چین است، جابه‌جایی پنل را یک بار در نمایش اضافه کنید؛ آن را وارد مختصات ذخیره‌شده منبع نکنید.

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

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

چه وقت کادر، چه وقت صفحه و چه وقت توقف؟

وضعیت استخراج، بررسی محل و تفسیر را جدا ثبت کنید. جدول زیر پیشنهاد ژرف برای اتصال اجزای سامانه است، نه قابلیتی تضمین‌شده از سوی ارائه‌دهندگان.

وضعیت شاهدرفتار مناسب سامانه
نسخه منبع، صفحه و نگاشت سازگارند و بررسی هندسه و محتوا قبول شدهناحیه دقیق را همراه امکان دیدن زمینه نشان دهد
منبع و صفحه معلوم‌اند، ولی نگاشت دقیق در دسترس نیستاگر کار اجازه می‌دهد، فقط ارجاع صفحه با توضیح محدودیت بدهد؛ بدون کادر حدسی
هویت منبع یا صفحه ناسازگار است یا تبدیل معتبر نیستادعای متکی به این شاهد را نگه دارد و مسیر را اصلاح یا دوباره پردازش کند
محل درست است، ولی معنای شاهد چندپهلو ماندهتفسیر را به بازبین مجاز بسپارد

ارجاع صفحه جایگزین هم‌ارزِ شاهد دقیق نیست، اگر اقدام بعدی به محل دقیق یک فیلد وابسته باشد. مالک فرایند باید این مرز را تعیین کند. راهنمای طراحی تأیید انسانی به تصمیم پُرپیامد بعدی مربوط است؛ درست‌بودن نمایش شاهد، خودبه‌خود اجازه انجام آن اقدام را نمی‌دهد.

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

خطای محل را جدا از دقت متن اندازه بگیرید

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

در مثال عددی، چهار مقدار خروجی و دو گوشه مقابل را بررسی کنید. آزمون رفت‌وبرگشت مختصات را نیز با دامنه خطای عددیِ مشخص اضافه کنید. با این حال، دو تبدیل غلطِ سازگار می‌توانند خطای هم را خنثی کنند؛ رفت‌وبرگشت موفق به‌تنهایی کافی نیست. محل نشانه‌ها را مستقل از همان تابع‌ها معلوم کنید و پیش از سنجش هندسه، هویت سند و صفحه را بسنجید.

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

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

یادداشت منابع — بازبینی ۷ اکتبر ۲۰۲۶

پنج مرجع اصلی زیر رفتار مختصات و کتابخانه‌ها را شرح می‌دهند، نه برتری عملکرد مدل‌ها را. مثال عددی ساختگی است و معماری، آزمون‌ها و جدول تصمیم، تحلیل ژرف‌اند. برای این مقاله محصولات نام‌برده را روی اسناد مشتری ارزیابی نکرده‌ایم.

#هوش مصنوعی اسناد#بازشناسی متن#استناد به منبع#تبدیل مختصات#کیفیت داده

مطالب مرتبط

این ابزار را در تیم خودتان راه بیندازید

اگر می‌خواهید ایجنت‌های هوش مصنوعی و اتوماسیون این راهنما را در تیم نرم‌افزار یا فرایندهای سازمانتان به کار بگیرید، از یک آزمایش کوچک شروع کنید که بتوانید نتیجه‌اش را بسنجید.

تماس تلفنی ۰۹۰۱ ۵۵۵ ۵۶۵۱پیام در واتس‌اپمشاوره و پیاده‌سازی هوش مصنوعی