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

دستیار عملیات از روی گزارش موجودی می‌نویسد: «در انبار شرق ۱۶۰ عدد قابل‌استفاده داریم.» همه رقم‌هایی که به کار برده روی صفحه هستند. اما مسئول انبار سه سؤال دارد: این ستون واقعاً زیر عنوان «شرق» بود؟ موجودی رزروشده را قبلاً کم کرده بودند؟ هر جعبه چند عدد داشت؟ درست‌خواندن رقم‌ها به این سؤال‌ها جواب نمی‌دهد.

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

پاسخ ۱۶۰ از کدام رابطه‌ها به دست می‌آید؟

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

برای قطعه «ب» در شرق، ابتدا چهار جعبه را از بیست جعبه کم می‌کنیم؛ شانزده جعبه می‌ماند. هر جعبه ده عدد است، پس پاسخ ۱۶۰ عدد می‌شود. اگر ابزار ستون غرب را انتخاب کرده باشد، همان محاسبه با هشت و یک، عدد ۷۰ را می‌دهد. پاسخ ۱۶، تبدیل جعبه به عدد را جا انداخته و پاسخ ۲۰۰، رزرو را ندیده است. برای ساختن هر چهار پاسخ، رقم‌های درست روی صفحه کافی‌اند؛ رابطه درست است که یکی را معتبر می‌کند.

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

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

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

جدول روی صفحه الزاماً یک جدول داده نیست

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

پس سه کار جدا داریم: تشخیص نویسه، پیدا‌کردن خانه‌ها و رابطه‌های جدول، و تعبیر آن‌ها برای یک سؤال کاری. عدد «۲۰» ممکن است در مرحله اول درست باشد و در دو مرحله بعد معنای اشتباهی پیدا کند. اگر مشکل، نسبت‌دادن ستون به انبار باشد، بالابردن کیفیت تصویر لزوماً کمکی نمی‌کند. ابتدا باید محل خرابی را شناخت.

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

عنوان کامل هر خانه را نگه دارید

اگر «عملکرد» هم زیر سال ۲۰۲۵ باشد و هم زیر سال ۲۰۲۶، این واژه به‌تنهایی ستون را مشخص نمی‌کند. در گزارش انبار هم «موجود» ممکن است دو بار تکرار شود. برای هر مقدار، شناسه جدول، هویت ردیف و زنجیره عنوان‌ها را نگه دارید؛ مثلاً «انبار شرق ← موجود». نام اصلی روی سند را کنار نام استانداردشده کسب‌وکار حفظ کنید تا تغییر تعبیر پنهان نشود.

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

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

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

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

برش دقیق شبکه جدول، الزاماً همه شاهد لازم را برنمی‌دارد. عنوان بالا شاید دوره گزارش را بگوید؛ زیرنویس، واحد را مشخص کند؛ پاورقی، دامنه یک جمع را محدود کند. مستندات چیدمان Azure Document Intelligence علاوه بر ردیف، ستون و گستره خانه، تصریح می‌کند که در رابط ۲۰۲۴-۱۱-۳۰ محدوده جدول و شکل فقط بخش اصلی را می‌پوشاند و زیرنویس و پاورقی همراه را کنار می‌گذارد. بنابراین خروجی درستِ ابزار هم ممکن است برای سؤال ما ناقص باشد.

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

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

آنچه ابزار برگردانده، پیش از تبدیل دور نریزید

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

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

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

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

بازیابی نباید عدد را دوباره از زمینه‌اش جدا کند

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

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

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

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

آزمون جدول را به شباهت متن محدود نکنید

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

پژوهش GriTS جدول را به‌صورت شبکه می‌سنجد و میان ساختار ارتباطی، جایگاه و محتوای خانه‌ها فرق می‌گذارد. این نگاه از مقایسه صرف متن دقیق‌تر است، ولی برنامه ما یک سؤال اضافی دارد: مقدار به موجودیت، سنجه، دوره و واحد درست نسبت داده شده و قید مربوط به آن هم همراهش هست؟ امتیاز ساختاری بالا، مجوز استفاده از هر پاسخ مشتق‌شده نیست.

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

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

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

نتیجه بررسی باید تکلیف عدد را روشن کند

«استخراج شد»، «برای گزارش پذیرفته شد» و «اجازه جابه‌جایی موجودی دارد» سه وضعیت متفاوت‌اند. بخش بعدی برنامه باید بداند چه استفاده‌ای مجاز است. تفسیر درست سند به‌تنهایی اجازه انجام عملیات نمی‌دهد.

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

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

یادداشت منابع — بررسی‌شده در ۲۴ سپتامبر ۲۰۲۶

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

• راهنمای متن PyMuPDF — مستندات نسخه ۱٫۲۸٫۲، به‌روزرسانی ۳ سپتامبر ۲۰۲۶؛ ترتیب خواندن و استخراج جدول.
• جدول‌های چندسطحی W3C — به‌روزرسانی ۲۷ ژوئیه ۲۰۱۹؛ رابطه صریح سرستون‌ها در جدول دسترس‌پذیر.
• چیدمان اسناد Azure — به‌روزرسانی ۱ مه ۲۰۲۶؛ رفتار مورد استناد مربوط به نسخه ۴ و رابط ۲۰۲۴-۱۱-۳۰ است.
• جدول‌ها در Amazon Textract — راهنمای جاری بدون تاریخ انتشار ثابت؛ خانه‌ها، ناحیه ادغام‌شده، عنوان و توضیح انتهایی.
• پژوهش PubTables-1M — ارسال نخست در ۳۰ سپتامبر ۲۰۲۱؛ نسخه سوم ۱۸ نوامبر ۲۰۲۱؛ پژوهش کنفرانس CVPR ۲۰۲۲.
• پژوهش GriTS — ارسال نخست در ۲۳ مارس ۲۰۲۲؛ نسخه سوم ۲۳ مه ۲۰۲۳؛ ارزیابی جدول بر مبنای شبکه خانه‌ها.