انتخاب را از خروجی قابل استفاده شروع کنید
برای انتخاب میان نرم‌افزار آماده پردازش اسناد و توسعه سفارشی، ابتدا مشخص کنید خروجی مورد نیاز دقیقاً چیست. استخراج متن از یک فایل با ثبت اطلاعات تأییدشده در سامانه سازمانی یکسان نیست. راهکار آماده زمانی گزینه مناسبی است که نوع سند، فیلدها و مسیر بازبینی آن با نیاز شما سازگار باشد؛ توسعه سفارشی زمانی ارزش بیشتری پیدا می‌کند که قواعد، استثناها یا اتصال به فرایند کاری بخش اصلی مسئله باشند. در بسیاری از پروژه‌ها، ترکیب یک موتور آماده با لایه اختصاصی بهترین گزینه برای بررسی است، نه لزوماً ساخت همه اجزا از صفر.
این مقاله برای تیمی نوشته شده که در آستانه انتخاب تأمین‌کننده یا تصویب بودجه پردازش اسناد قرار دارد. هدف، مقایسه منصفانه دامنه کار و مسئولیت‌هاست؛ نه معرفی یک برند به‌عنوان برنده همیشگی. قیمت روز، درصد دقت عمومی یا نمایش چند فایل تمیز نمی‌تواند به‌تنهایی تصمیم را تعیین کند. باید ببینید هر پیشنهاد چه مقدار از مسیر واقعی شما را پوشش می‌دهد و کدام کارها بعد از خرید همچنان بر عهده کارکنان باقی می‌ماند.
سه گزینه را به‌جای یک دوگانه ساده مقایسه کنید
گزینه نخست، محصول آماده‌ای است که امکاناتی مانند ورود فایل، استخراج، بازبینی و خروجی دارد. گزینه دوم، راهکار اختصاصی است که بر اساس فرایند سازمان ساخته می‌شود؛ این راهکار هم ممکن است از موتورهای آماده استفاده کند. گزینه سوم، ترکیبی است: استخراج با یک سرویس موجود انجام می‌شود و قواعد اعتبارسنجی، صفحه بازبینی یا اتصال مقصد اختصاصی هستند. «سفارشی» الزاماً به معنی آموزش مدل جدید نیست و «آماده» هم الزاماً به معنی بی‌نیازی از پیاده‌سازی نیست.
این تفکیک هنگام دریافت پیشنهاد اهمیت دارد. ممکن است یک فروشنده فقط API استخراج عرضه کند و دیگری کل گردش کار را قیمت‌گذاری کرده باشد. مقایسه مستقیم مبلغ این دو پیشنهاد نتیجه قابل اتکایی ندارد. برای شناخت مراحل دریافت، استخراج، کنترل و ثبت، راهنمای پردازش هوشمند اسناد را مبنا قرار دهید و در هر پیشنهاد مشخص کنید کدام مرحله واقعاً تحویل می‌شود.
دامنه اسناد را پیش از فهرست قابلیت‌ها بنویسید
عبارت «پشتیبانی از فاکتور» بسیار کلی است. فاکتور چاپی خوانا، تصویر موبایلی کج، سند چندصفحه‌ای، جدول دارای ردیف شکسته و فایل دوزبانه مسائل متفاوتی ایجاد می‌کنند. یک فهرست نمونه بسازید که تنوع واقعی ورودی‌ها را نشان دهد: قالب، زبان، کیفیت تصویر، تعداد صفحات و فیلدهای حیاتی. سند کم‌کیفیت را فقط به این دلیل که برای نمایش مناسب نیست از نمونه‌ها حذف نکنید؛ همین موارد می‌توانند هزینه بازبینی را تعیین کنند.
به‌جای ارسال بی‌ضابطه اطلاعات واقعی، نمونه‌های مجاز و در صورت نیاز بی‌نام‌شده آماده کنید. بی‌نام‌سازی نباید ساختار مهم سند را از بین ببرد و آزمون را غیرواقعی کند. برای مثال، اگر چیدمان جدول مسئله اصلی است، جایگزین کردن همه ردیف‌ها با یک خط ساده نتیجه را تغییر می‌دهد. مالک داده باید بداند نمونه‌ها به کجا منتقل می‌شوند، چه کسی آن‌ها را می‌بیند و پس از پایان ارزیابی چه اتفاقی برایشان می‌افتد.
توان استخراج را از تکمیل فرایند جدا کنید
موتور استخراج می‌تواند شماره سند یا مبلغ را پیدا کند، اما تشخیص اینکه شماره متعلق به کدام شرکت است یا سند قبلاً ثبت شده، معمولاً به اطلاعات سازمان نیاز دارد. مدل از پیش آماده ممکن است فیلدهای متداول را ارائه دهد؛ نیاز شما شاید شامل یک کد داخلی یا ارتباط خاص میان ردیف‌ها باشد. در مرور رسمی مدل‌های Document Intelligence، مدل‌های آماده و مدل‌های سفارشی از هم تفکیک شده‌اند. این نمونه نشان می‌دهد انتخاب مدل با انتخاب کل نرم‌افزار یک تصمیم واحد نیست.
در جلسه ارزیابی، خروجی ساختاریافته را ببینید و فقط به تصویر نمایشی اکتفا نکنید. فیلدی که پیدا نشده باید وضعیت روشن داشته باشد. مقدار تخمینی یا تکمیل‌شده از منبع دیگر باید از مقدار خوانده‌شده از سند متمایز شود. اگر سامانه عددی را اصلاح می‌کند، مشخص باشد بر اساس چه قاعده‌ای و با چه مجوزی این کار انجام شده است. توان ساخت متن روان یا توضیح قانع‌کننده، جای داده قابل ردگیری را نمی‌گیرد.
راهکار آماده چه زمانی انتخاب منطقی‌تری است؟
اگر اسناد نسبتاً هم‌ساختارند، فیلدهای مورد نیاز متداول‌اند و خروجی استاندارد برای فرایند بعدی کافی است، محصول آماده می‌تواند دامنه پیاده‌سازی را کوچک کند. وجود پنل بازبینی مناسب، مدیریت کاربران و امکان خروجی گرفتن، کارهای اولیه را کاهش می‌دهد؛ البته باید آن‌ها را در همان نسخه و طرحی که خریداری می‌کنید بررسی کنید. قابلیت موجود در یک نمایش فروش، الزاماً در همه قراردادها و محیط‌های استقرار ارائه نمی‌شود.
مزیت اصلی را با میزان کار باقی‌مانده بسنجید. اگر کارکنان پس از استخراج هنوز مجبورند فایل را در چند سامانه کپی کنند، ممکن است صرفه‌جویی کمتر از انتظار باشد. از طرف دیگر، اگر خروجی فایل برای حجم کم کار کافی است، ساخت اتصال پیچیده شاید ضرورتی نداشته باشد. انتخاب آماده زمانی ضعیف می‌شود که برای سازگار کردن فرایند، کاربران به دور زدن کنترل‌ها یا نگهداری فایل‌های جانبی وابسته شوند.
توسعه سفارشی چه زمانی توجیه دارد؟
وقتی تفاوت اصلی در قواعد سازمانی است، سفارشی‌سازی می‌تواند ارزش داشته باشد: مثلاً هر نوع سند مسیر تأیید متفاوت دارد، داده باید با چند مرجع داخلی تطبیق یابد یا مسئول بازبینی بر اساس پروژه تعیین می‌شود. در این حالت، ساخت صفحه و گردش کار مناسب ممکن است مهم‌تر از تغییر موتور استخراج باشد. قبل از سفارش، نیازها را به رفتار قابل آزمون تبدیل کنید تا توسعه صرفاً مجموعه‌ای از فرم‌های جدید نباشد.
سفارشی بودن، مسئولیت نگهداری را حذف نمی‌کند. باید مشخص شود چه کسی تغییر قالب سند، نسخه موتور، خرابی اتصال و اصلاح قواعد را مدیریت می‌کند. مالکیت کد به‌تنهایی تضمین نمی‌کند تیم شما بتواند سامانه را اداره کند؛ مستندات، آزمون‌ها، روش استقرار و دانش عملیاتی هم لازم‌اند. اگر هیچ مسئول داخلی برای داده و فرایند وجود ندارد، توسعه اختصاصی ممکن است وابستگی را به شکل دیگری بازتولید کند.
راهکار ترکیبی را جدی بگیرید
در الگوی ترکیبی، بخش عمومی را می‌خرید و بخشی را می‌سازید که واقعاً مختص کسب‌وکار شماست. برای مثال، استخراج از یک موتور آماده می‌آید، اما تطبیق کد مشتری و ثبت درخواست بازبینی در نرم‌افزار داخلی انجام می‌شود. این روش می‌تواند دامنه ساخت را محدود کند، به شرط آنکه مرزها و مسئولیت خطا روشن باشند. اگر هر طرف خطا را به طرف دیگر ارجاع دهد، ترکیب دو ابزار به‌تنهایی مسئله را حل نمی‌کند.
یک قرارداد خروجی پایدار میان اجزا تعریف کنید: نام و نوع فیلدها، وضعیت نامعلوم، مرجع صفحه و نسخه پردازش باید معلوم باشد. تغییر سرویس استخراج نباید بی‌هشدار معنای داده در مقصد را عوض کند. برای جایگزینی موتور نیز حداقل یک مسیر خروج قابل بررسی داشته باشید؛ مثلاً امکان صدور داده تأییدشده و نگهداری ارتباط آن با سند اصلی. هدف، استقلال کامل از همه تأمین‌کنندگان نیست، بلکه شناخت هزینه و محدودیت تغییر است.
هزینه را به ازای کار تکمیل‌شده مقایسه کنید
هزینه صفحه یا فراخوانی فقط یک بخش از هزینه مالکیت است. آماده‌سازی فایل، پردازش مجدد، زمان بازبین، اتصال به مقصد، نگهداری، پایش و رسیدگی به خطا را هم در نظر بگیرید. دو پیشنهاد با نرخ استخراج متفاوت ممکن است پس از محاسبه بازبینی نتیجه معکوس داشته باشند. برای تصمیم، هزینه را به یک واحد کاری روشن مثل «سند تأییدشده و ثبت‌شده» نسبت دهید، نه فقط تعداد فایل‌هایی که به سرویس ارسال شده‌اند.
یک برآورد ساده می‌تواند شامل هزینه ثابت دوره، مصرف پردازش، زمان بازبینی و پشتیبانی باشد که بر تعداد اسناد تکمیل‌شده تقسیم می‌شود. این محاسبه را با داده واقعی پایلوت انجام دهید و فرض‌های آن را کنار نتیجه بنویسید. اگر تعداد استثناها در ماه بعد بیشتر شد، نتیجه قبلی را بدون بازبینی تعمیم ندهید. هزینه خطاهای پرریسک نیز نباید فقط در میانگین پنهان شود؛ ممکن است یک کنترل اجباری مستقل لازم داشته باشند.
بازبینی انسانی و اتصال مقصد را در پیشنهاد ببینید
پرسش مهم این است که کاربر چگونه مقدار مشکوک را اصلاح می‌کند، سند اصلی را کنار داده می‌بیند و تغییرش ثبت می‌شود. اگر پنل فقط یک خروجی طولانی نشان دهد، بازبینی می‌تواند به کاری کند و خطاپذیر تبدیل شود. دسترسی‌ها، صف مسئولان و امکان بازگرداندن مورد ناقص باید با فرایند واقعی تطابق داشته باشند. مسئول تأیید داده را از کسی که تنظیمات مدل را تغییر می‌دهد تفکیک کنید.
در اتصال مقصد، ثبت تکراری و شکست نیمه‌کاره را بررسی کنید. اگر پاسخ شبکه قطع شد، سامانه باید بتواند بفهمد ثبت انجام شده یا نه؛ ارسال دوباره کورکورانه می‌تواند رکورد تکراری بسازد. همچنین روشن کنید چه چیزی به‌صورت پیشنهاد ذخیره می‌شود و چه چیزی بدون تأیید اجرا می‌شود. یک پیشنهاد خرید خوب، مسیر خطا و اصلاح را به همان اندازه مسیر موفق توضیح می‌دهد.
الزامات استقرار را قبل از امتیازدهی تعیین کنید
محل پردازش، دسترسی کارکنان پشتیبانی، مدت نگهداری و امکان حذف داده باید پیش از مقایسه قابلیت‌ها روشن باشد. اگر یک گزینه الزام قطعی سازمان را برآورده نمی‌کند، امتیاز بالای استخراج نباید آن را جبران کند. استقرار داخلی نیز به‌خودی‌خود تضمین امنیت یا کیفیت نیست؛ مسئول به‌روزرسانی، پشتیبان‌گیری و مدیریت دسترسی همچنان لازم است. ادعای سازگاری با سیاست داده را با شرایط واقعی قرارداد و محیط فنی تطبیق دهید.
برای هر الزام، مدرک مورد انتظار بنویسید؛ مثلاً نمایش تنظیم نگهداری، نمونه خروجی قابل انتقال یا آزمون محدودیت دسترسی. محدودیت زبان فارسی، جدول راست‌به‌چپ، تقویم و واحد پول را جدا آزمایش کنید. پشتیبانی از یک زبان در OCR الزاماً به معنی استخراج درست همه فیلدهای تخصصی آن زبان نیست. قابلیت‌های وابسته به نسخه را در زمان خرید دوباره کنترل کنید.
یک مثال فرضی برای انتخاب مرحله‌ای
فرض کنید شرکتی اسناد تحویل از چند تأمین‌کننده می‌گیرد. بعضی قالب‌ها ثابت‌اند، اما کد کالا باید با مرجع داخلی تطبیق داده شود و موارد نامشخص به مسئول پروژه بروند. این مثال، نتیجه یک پروژه واقعی یا تضمین عملکرد نیست. گزینه آماده ممکن است استخراج را پوشش دهد، ولی برای تطبیق و ارجاع نیاز به کار تکمیلی داشته باشد. توسعه کامل نیز ممکن است بخش‌هایی را دوباره بسازد که قبلاً قابل خرید هستند.
تیم می‌تواند ابتدا یک موتور آماده را روی نمونه‌های مجاز آزمایش کند، سپس هزینه یک لایه محدود تطبیق و بازبینی را برآورد کند. اگر کیفیت استخراج برای گروهی از اسناد کافی نبود، همان گروه جدا بررسی شود؛ لازم نیست تصمیم درباره کل پروژه به یک مدل وابسته باشد. خروجی جلسه باید یک انتخاب مشروط با دامنه، شواهد و مسئولیت مشخص باشد، نه یک برچسب کلی «آماده بهتر است» یا «اختصاصی حرفه‌ای‌تر است».
تصمیم نهایی را به شواهد پایلوت گره بزنید
از همه گزینه‌ها بخواهید روی مجموعه مشترک، خروجی قابل بررسی تولید کنند و استثناها را حذف نکنند. روش نمونه‌گیری و پذیرش را در راهنمای آزمون پایلوت پردازش اسناد دنبال کنید؛ در تصمیم خرید، علاوه بر نتیجه فنی، کار باقی‌مانده، مسئول نگهداری و امکان خروج را هم مقایسه کنید. اگر شواهد کافی نیست، مرحله بعد را محدود و قابل توقف تعریف کنید، نه اینکه کل قرارداد را بر پایه حدس ببندید.
برای شروع، یک بسته تصمیم شامل نمونه اسناد مجاز، فیلدهای حیاتی، مقصد خروجی، الزامات داده و محدودیت زمان تهیه کنید. این بسته امکان مقایسه پیشنهادهای هم‌دامنه را فراهم می‌کند. برای بررسی اینکه کدام بخش از فرایند شما آماده، سفارشی یا ترکیبی اجرا شود، از خدمات هوش مصنوعی ایزی‌ساز کمک بگیرید.