مشتری روبه‌روی کارشناس نشسته است. می‌خواهد بداند برای رسیدگی به درخواستش چه مدارکی لازم دارد. کارشناس سؤال را در دستیار داخلی بانک وارد می‌کند.
چند ثانیه بعد، پاسخ روی صفحه می‌آید: فهرست مدارک، مراحل رسیدگی و پیوند بخشنامه. کارشناس سند را باز می‌کند و به مشتری توضیح می‌دهد از کجا شروع کند.
در این روایت فرضی، دستیار در زیرساخت داخلی بانک اجرا می‌شود. بخشنامه‌ها نیز در مخزن داخلی ذخیره شده‌اند و از یک منبع بیرونی به‌روزرسانی می‌شوند. این سناریو را برای بررسی تصمیم‌های طراحی دنبال می‌کنیم؛ عملکرد بانک یا محصول مشخصی را گزارش نمی‌کند. منظور از قطعی در این روایت، قطع دسترسی به سرویس‌های بیرونی است؛ شبکه داخلی و زیرساخت بانک همچنان کار می‌کنند.
کمی بعد، دسترسی به منبع بیرونی قطع می‌شود. شبکه داخلی و سامانه‌های اصلی بانک برقرارند. دستیار هم به کارش ادامه می‌دهد.
مشتری بعدی درباره همان خدمت سؤال می‌کند. پاسخ مثل قبل مرتب است و به بخشنامه ارجاع دارد. کارشناس تغییری در صفحه نمی‌بیند.
اما در فاصله میان این دو مراجعه، اصلاحیه‌ای در منبع بیرونی منتشر شده و در این سناریو، زمان اجرای آن نیز فرا رسیده است. یکی از شرایط رسیدگی تغییر کرده و نسخه تازه هنوز به مخزن داخلی نرسیده است.
دستیار از این تغییر خبر ندارد. پاسخ را از همان سند قبلی می‌سازد و با همان لحن قطعی نمایش می‌دهد. دستیار همچنان پاسخ‌گوست، اما دیگر نمی‌تواند تأیید کند که پاسخ آن با آخرین مقررات مطابقت دارد.
آنچه در صفحه دیده نمی‌شود
کارشناس سؤال می‌پرسد و پاسخ می‌گیرد. پشت این تعامل ساده، چند جزء کار می‌کنند: سامانه ورود و کنترل دسترسی، مخزن اسناد، موتور جست‌وجو، مدل زبانی و، در بعضی کاربردها، ابزار استعلام یا ثبت درخواست.
هرکدام از این اجزا ممکن است وضعیت متفاوتی داشته باشند. مدل کار می‌کند، اما اسناد به‌روز نمی‌شوند. سند پیدا می‌شود، اما استعلام لازم انجام نمی‌شود. درخواست ارسال می‌شود، اما تأیید ثبت آن برنمی‌گردد.
اگر پایش سامانه فقط زمان پاسخ و روشن‌بودن سرویس را نشان دهد، این تفاوت‌ها ممکن است پنهان بمانند. بانک باید بتواند جداگانه بررسی کند که دستیار پاسخ تولید می‌کند، به منبع معتبر دسترسی دارد و پیش‌شرط‌های اقدام را در اختیار دارد.
«اصول تاب‌آوری عملیاتی» کمیته بال، منتشرشده در مارس ۲۰۲۱، بر شناسایی عملیات حیاتی و وابستگی‌های داخلی و خارجی لازم برای ارائه آن‌ها تأکید دارد. در خدمات هوش مصنوعی نیز می‌توان این وابستگی‌ها را تا نتیجه‌ای که به کاربر می‌رسد دنبال کرد. این سند در این مقاله مرجع تحلیلی است؛ از آن، الزام خاصی برای بانک‌های ایران استنباط نمی‌کنیم. اصول تاب‌آوری عملیاتی کمیته بال
در شعبه، نتیجه مورد انتظار «راهنمایی معتبر درباره مدارک لازم» است. برای ارزیابی آن، باید هم پاسخ و هم نسخه سند و وضعیت به‌روزرسانی را بررسی کرد.
پاسخ بعدی باید چه تفاوتی داشته باشد؟
همان لحظه را دوباره تصور کنیم: مشتری سؤال کرده و کارشناس منتظر پاسخ دستیار است. این بار، سامانه برای قطع ارتباط آماده شده است.
کنار پاسخ، زمان آخرین همگام‌سازی مخزن و تاریخ نسخه سند مشخص است. دستیار اعلام می‌کند که اکنون امکان تأیید آخرین نسخه را ندارد. کارشناس می‌فهمد اطلاعات از کجا آمده و چه چیزی هنوز قابل تأیید نیست.
این اطلاع‌رسانی نقطه شروع است. قطع به‌روزرسانی به‌تنهایی به معنای نامعتبرشدن همه اسناد موجود نیست. بانک باید برای هر کاربرد مشخص کند اطلاعات تا چه مدت و با چه شرایطی قابل استفاده‌اند. تاریخ انتشار، زمان شروع اجرا و جایگزین‌شدن یک سند نیز باید در این تصمیم در نظر گرفته شوند.
اگر کارشناس معنای یک اصطلاح را در نسخه موجود بخشنامه بخواهد، دستیار می‌تواند متن را با ذکر منبع و تاریخ نمایش دهد. اگر بپرسد «این مشتری اکنون مشمول این شرایط است؟»، پاسخ ممکن است مبنای رسیدگی به پرونده شود و به تأیید شرایط جاری نیاز داشته باشد.
برای این دو پرسش، می‌توان سطح متفاوتی از خدمت تعریف کرد:
| درخواست کارشناس | رفتار پیشنهادی هنگام نامشخص‌بودن تازگی منبع |
|---|---|
| یافتن متن یا تعریف در سند موجود | نمایش متن، منبع و تاریخ نسخه |
| توضیح شرایط جاری یک خدمت | اعلام محدودیت تأیید و هدایت به مسیر تعیین‌شده بانک |
| آماده‌کردن فهرست اولیه مدارک | ارائه پیش‌نویس با مشخص‌کردن نیاز به تأیید |
| ثبت یا اجرای اقدام بر اساس شرایط جاری | توقف تا فراهم‌شدن تأیید لازم |
این جدول، پیشنهاد طراحی است. مرز هر ردیف باید با توجه به حساسیت خدمت و فرایند بانک تعیین شود.
قواعد این رفتار نیز باید از پیش در سامانه تعریف شوند. زمان همگام‌سازی و وضعیت اتصال را باید زیرساخت ثبت کند و در اختیار دستیار بگذارد. همچنین اجازه ثبت یا اجرای درخواست باید در سامانه عملیاتی کنترل شود. توصیه OWASP درباره اختیار بیش‌ازحد در سامانه‌های مبتنی بر مدل زبانی نیز بر کنترل مجوزها در سامانه مقصد تأکید دارد؛ تصمیم مجازبودن اقدام نباید صرفاً به مدل واگذار شود. راهنمای OWASP درباره حدود اختیار دستیارهای هوشمند
وقتی دستیار اجازه اقدام دارد
پرونده مشتری جلو می‌رود. فرض کنیم دستیار می‌تواند اطلاعات را در فرم اولیه وارد کند و درخواست را برای ثبت به سامانه عملیاتی بفرستد.
در روز عادی، کارشناس مجبور نیست اطلاعات را دوباره وارد کند. در زمان اختلال، باید بداند دستیار تا کجای کار اجازه پیش‌رفتن دارد.
یکی از استعلام‌های لازم در دسترس نیست. فرم روی صفحه کامل به نظر می‌رسد، اما یکی از پیش‌شرط‌های ثبت هنوز بررسی نشده است. حفظ اجازه ثبت در این وضعیت، ممکن است پرونده را با شرایط نامشخص وارد مرحله بعد کند.
اختیار دستیار باید با اطلاعات و ابزارهای در دسترس هماهنگ شود. در این مثال، می‌تواند پیش‌نویس را آماده کند، استعلام انجام‌نشده را مشخص کند و پرونده را تا دریافت تأیید نگه دارد. درباره این مرز تصمیم و اقدام، در مقاله هوش مصنوعی در صنعت مالی نیز بحث شده است.
کارشناس نیز باید دقیقاً بداند چه چیزی را بررسی کند و تأیید را از کجا بگیرد. پیام عمومی «پاسخ را بررسی کنید» این مسیر را روشن نمی‌کند. ارجاع به نیروی انسانی باید با مشخص‌کردن اطلاعات غایب، تصمیم معلق و مرجع رسیدگی همراه باشد.
اگر بانک به مدل جایگزین تکیه کند
تا اینجا، مدل داخل بانک اجرا می‌شد و مشکل اصلی، دسترسی به اطلاعات و ابزارها بود. در معماری دیگری، خود مدل نیز بیرون از بانک اجرا می‌شود. بانک ممکن است برای زمان قطعی، یک مدل داخلی جایگزین داشته باشد.
در این حالت، پس از قطع اتصال، پرسش کارشناس به مدل داخلی منتقل می‌شود. پاسخ دوباره روی صفحه می‌آید و زمان انتظار هم قابل قبول است. اکنون باید کیفیت همین پاسخ را بررسی کرد.
در سؤال مربوط به مدارک، تفاوت میان «مدرک الزامی»، «مدرک قابل جایگزینی» و «مدرک لازم در شرایط خاص» اهمیت دارد. مدل جایگزین باید این تفاوت‌ها را حفظ کند و ادعاهایش به بخش مرتبط سند متکی باشند.
ممکن است مدل اصلی برای پاسخ‌های تفصیلی ارزیابی شده باشد و مدل جایگزین فقط در یافتن و نمایش بخش مرتبط سند کیفیت قابل قبول داشته باشد. دامنه خدمت جایگزین باید بر اساس همین ارزیابی تعیین شود.
برای سنجش آن، بانک می‌تواند مجموعه‌ای از پرونده‌های آزمون بسازد: سؤال‌های دارای پاسخ روشن، اسناد دارای استثنا، بخشنامه‌های جایگزین‌شده و پرسش‌هایی که مخزن برای آن‌ها اطلاعات کافی ندارد. هر دو مدل باید روی همین مجموعه بررسی شوند.
در کنار زمان پاسخ و ظرفیت پردازش، وفاداری به سند، حفظ استثناها و تشخیص نبود اطلاعات نیز معیار ادامه خدمت‌اند. کنترل دسترسی به پرونده‌ها و اسناد هم باید در مسیر جایگزین برقرار بماند.
اتصال برگشته؛ پرونده هنوز تمام نشده است
به شعبه بازگردیم. ارتباط برقرار شده و اصلاحیه تازه وارد مخزن می‌شود. دستیار دوباره به اطلاعات به‌روز دسترسی دارد.
اما کارهای دوره قطعی باقی مانده‌اند. به مشتری‌ای که در زمان قطعی مراجعه کرده، فهرست مدارک بر اساس نسخه قبلی داده شده است. برای مشتری دیگری پیش‌نویس آماده شده و منتظر تأیید است. درخواست سومی درست پیش از قطع ارتباط ارسال شده، اما نتیجه ثبت آن به سامانه نرسیده است.
بانک باید برای هرکدام تصمیم بگیرد.
آیا اصلاحیه، راهنمایی ارائه‌شده به مشتری اول را تغییر می‌دهد؟ پیش‌نویس دوم با شرایط تازه سازگار است؟ درخواست سوم قبلاً ثبت شده یا باید دوباره ارسال شود؟
ارسال دوباره درخواست سوم، اگر سامانه مقصد سازوکاری برای جلوگیری از اجرای تکراری نداشته باشد، می‌تواند خطر ثبت دوباره ایجاد کند. برای نمونه، مستندات Stripe استفاده از شناسه یکتای درخواست را توضیح می‌دهد تا تکرار درخواست پس از خطای ارتباطی، همان عملیات را دوباره انجام ندهد. این مثال، یک الگوی فنی را نشان می‌دهد؛ وجود چنین کنترلی در سامانه بانک باید جداگانه بررسی شود. مستندات Stripe درباره جلوگیری از اجرای تکراری درخواست
از سوی دیگر، پیش‌نویسی که بر اساس شرایط قبلی آماده شده، باید پیش از ادامه بررسی شود.
رسیدگی به این پرونده‌ها به اطلاعاتی بستگی دارد که سامانه در زمان اختلال ثبت کرده است: نسخه سند، محدودیت فعال، استعلام انجام‌نشده و آخرین مرحله درخواست.
این اطلاعات کمک می‌کنند دامنه بازبینی مشخص شود. اگر اصلاحیه فقط یک شرط را تغییر داده باشد، می‌توان پرونده‌هایی را پیدا کرد که به همان شرط وابسته بوده‌اند و بررسی را روی آن‌ها متمرکز کرد.
آزمونی که روایت شعبه را بازسازی می‌کند
همین روایت می‌تواند مبنای آزمون آمادگی باشد. در محیط کنترل‌شده، کارشناس درخواست مشابهی وارد می‌کند. دسترسی به منبع بیرونی قطع می‌شود، سندی تغییر می‌کند، مسیر جایگزین زیر بار قرار می‌گیرد و سپس ارتباط بازمی‌گردد.
در هر مرحله باید رفتار سامانه را با انتظار بانک مقایسه کرد:
- آیا محدودیت دسترسی به اطلاعات تازه را به کارشناس نشان داده است؟
- آیا پاسخ‌ها و اقدامات را مطابق قواعد حالت محدود تنظیم کرده است؟
- آیا مدل جایگزین، استثناها و نبود اطلاعات کافی را درست تشخیص داده است؟
- آیا کارشناسان توانسته‌اند درخواست‌های ارجاع‌شده را رسیدگی کنند؟
- آیا پس از اتصال، پرونده‌های نیازمند بازبینی و درخواست‌های با وضعیت نامشخص قابل شناسایی بوده‌اند؟
راه‌اندازی دوباره نیز باید آزمایش شود. مدلی که برای ادامه خدمت بدون اینترنت انتخاب شده، باید پس از توقف بتواند بدون دریافت فایل ضروری از بیرون شروع به کار کند. مستندات Hugging Face Hub، برای نمونه، نشان می‌دهد که در حالت آفلاین این ابزار، فقط فایل‌های ذخیره‌شده محلی در دسترس‌اند و نبود فایل لازم به خطا منجر می‌شود. مستندات حالت آفلاین Hugging Face
نتیجه آزمون باید تعهد بانک را روشن کند: کدام درخواست‌ها، برای چه مدت و با چه کیفیت و ظرفیتی پاسخ می‌گیرند و کدام اقدامات تا رفع اختلال معلق می‌مانند.
پیش از سؤال بعدی مشتری
مشتری از محل اجرای مدل و مسیر ارتباطی استعلام‌ها خبر ندارد. او انتظار دارد توضیحی که می‌گیرد معتبر باشد و درخواستش درست رسیدگی شود.
کارشناس برای برآورده‌کردن این انتظار، باید بداند دستیار چه اطلاعاتی در اختیار دارد و کدام بخش از پاسخ هنوز نیازمند تأیید است. ادامه پاسخ‌گویی بدون نشان‌دادن این وضعیت، می‌تواند اطمینانی ایجاد کند که پشتوانه کافی ندارد.
بانک می‌تواند از یک کاربرد مشخص شروع کند: مسیر ارائه خدمت را دنبال کند، رفتار آن را در زمان اختلال تعیین کند و پرونده‌های مشابه را تا بازگشت اتصال بیازماید. این رویکرد با تأکید بر آغاز استقرار هوش مصنوعی از مسئله کسب‌وکار هم‌راستاست.
پیش از سؤال بعدی مشتری، پاسخ این پرسش باید روشن باشد: اگر اطلاعات لازم در دسترس نباشد، دستیار چه می‌گوید، چه کاری اجازه دارد انجام دهد و کارشناس چگونه ادامه می‌دهد؟
