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