«فراتر از کیفیت مدل»؛ ضرورت معماری‌های مقاوم برای سرویس‌های بانکی

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

به گزارش GeekyAnts در راهنمای مفصلی که در ۱۴ اکتبر ۲۰۲۶ درباره معماری هوش مصنوعی فین‌تک منتشر شد، شکست‌های یکپارچه‌سازی و مسیرهای بازیابی، بیش از کیفیتِ صرفِ مدل، به شکل‌گیری یک سیستم اثر می‌گذارند. در محیط‌های حساس مالی، تاب‌آوری سیستم بسیار مهم‌تر از دقت محض مدل است. بسیاری از مؤسسات مالی با هوش مصنوعی مانند یک جعبه سیاه برخورد می‌کنند که صرفاً نتیجه‌ای را برمی‌گرداند. اما در دنیای واقعی، زمانی که یک نتیجه نامشخص رخ می‌دهد — مانند گم شدن پاسخ پس از یک پرداخت موفق از راه دور — این وضعیت می‌تواند منجر به تلاش‌های مجدد ناایمن و اقدامات مالی تکراری شود. این چالش‌ها دقیقاً همان نقاط ضعفی هستند که شرکت‌هایی مانند Dusyn با به‌کارگیری معماری ماشین حالت (State Machine) برای حذف خطاهای پرداخت در عامل‌های هوشمند سعی در حل آن‌ها دارند.

این تغییر تمرکز از «دقت» به «تاب‌آوری»، کلید انتقال هوش مصنوعی از محیط‌های آزمایشی (Pilot) به محیط عملیاتی (Production) است. یک بررسی مهندسی باید این پرسش‌ها را مطرح کند: وقتی یک وابستگی (Dependency) با تأخیر مواجه می‌شود چه اتفاقی می‌افتد؟ آیا یک عامل (Agent) — شبیه به کارمندی که دسترسی‌های محدودی دارد و باید برای هر کار مجوز بگیرد — اجازه انجام عملیاتی را دارد که توصیه می‌کند؟ این پرسش‌ها هم معماری سیستم و هم توانمندی شرکتی که آن را پیاده‌سازی می‌کند، ارزیابی می‌کنند. در همین راستا، تلاش‌هایی برای تخصصی کردن ChatGPT جهت ارائه خدمات به بانکداران سطح جونیور در جریان است تا دقت مدل‌ها در وظایف خاص مالی افزایش یابد.

پنج الگوی کلیدی معماری

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

• تشخیص آنی کلاهبرداری: تمرکز بر امتیازدهی به تراکنش‌ها برای شناسایی فعالیت‌های مشکوک، در حالی که باید در بازه زمانی بسیار کوتاهی (Latency Budget) و در جریان پرداخت پاسخ دهد.
• ضد پول‌شویی (AML) و شناسایی مشتری (KYC): پشتیبانی از غربالگری و بازرسی‌ها از طریق حفظ شواهد و ارجاع موارد نامشخص به بازبینی انسانی.
• تصمیم‌گیری اعتباری: ارزیابی ریسک و صلاحیت، با جداسازی کامل توصیه‌های مدل از سیاست‌های سخت‌گیرانه و قطعی وام‌دهی.
• مسیریابی و تطبیق پرداخت‌ها: انتخاب پردازشگرهای مجاز و شناسایی عدم تطابق‌ها، در حالی که تعداد تلاش‌های مجدد (Retries) برای حفظ ثبات تراکنش‌ها به دقت کنترل می‌شود.
• عملیات بانکی عامل‌محور (Agentic): بازیابی اطلاعات و فراخوانی ابزارها، که نیازمند اجرای سخت‌گیرانه مرزهای تایید و مجوزهای دسترسی است.

تست فراتر از نمودارها

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

ارزیابان باید دموهایی را برای موارد زیر مطالبه کنند:

• عملیات اصلی چگونه شناسایی می‌شود؟
• وضعیت تراکنش چگونه بازیابی می‌شود؟
• آیا تلاش مجدد، هویت همان عملیات قبلی را حفظ می‌کند یا تراکنش جدیدی می‌سازد؟
• نتایج حل‌نشده چگونه به یک صف عملیاتی (Operational Queue) منتقل می‌شوند؟
• کاربر در زمانی که نتیجه تراکنش نامشخص است، چه پیامی را مشاهده می‌کند؟

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

لیست کوتاه برای پیاده‌سازی

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

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

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

۳. Accenture: تأکید بر تحول سازمانی گسترده و استفاده مسئولانه از هوش مصنوعی زاینده (Generative AI) در چندین دپارتمان مختلف. آن‌ها زمانی مرتبط هستند که یک ابتکار عمل، چندین بخش سازمان را درگیر کند نه فقط یک ویژگی خاص. مدرکی که باید درخواست شود: یک نسخه انتشار اول با محدوده کوچک، دارای مالکان فنی مشخص و معیارهای پذیرش قابل اندازه‌گیری.

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

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

چارچوب ارزیابی

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

این فرآیند باید منجر به تولید پنج خروجی (Artifact) ملموس شود:

• قراردادهای رابط (Interface Contracts): تعریف دقیق ورودی‌ها، خروجی‌ها، خطاها و مرزهای مالکیت.
• تست‌های شکست اجرایی: اثبات رفتار سیستم در زمان خرابی وابستگی‌ها.
• برنامه‌های استقرار و بازگشت (Rollback): جزئیات نحوه رسیدن تغییرات به محیط عملیاتی و نحوه بازگرداندن آن‌ها در صورت بروز مشکل.
• تخمین‌های مبتنی بر حجم کاری: تعیین مفروضات پشت ظرفیت سیستم و قیمت‌گذاری.
• نقشه مسئولیت پشتیبانی: شناسایی دقیق اینکه چه کسی حوادث را در مرزهای سیستمی مدیریت می‌کند.

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

گام بعدی شما

• پایلوت فعلی هوش مصنوعی خود را با از دسترس خارج کردن یک منبع داده تست کنید و نحوه بازیابی سیستم را بدون دخالت انسان مستند کنید.
• قراردادهای رابط (Interface Contracts) را برای هر ابزاری که عامل‌های شما فراخوانی می‌کنند، بازنویسی کنید.
• یک سناریوی «نتیجه مبهم» (Ambiguous Outcome) را در جریان پرداخت‌های خود شبیه‌سازی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.