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

مشکل واقعی، اندازه مدل نیست

این محاسباتی است که افسران ریسک را بی‌خواب نگه می‌دارد. یک خط لوله (pipeline) با شش مرحله متمایز را تصور کنید: استخراج داده، اعتبارسنجی، امتیازدهی ریسک، بررسی انطباق، تولید اسناد و تأیید نهایی. هر مرحله در انزوا به زیبایی عمل می‌کند و به دقت ۹۷ درصد می‌رسد. غریزه حکم به جشن گرفتن می‌دهد، اما احتمالات از شهود پیروی نمی‌کنند. اگر این مراحل را به هم زنجیر کنید، قابلیت اطمینان سرتاسری (end-to-end) به حدود ۸۳ درصد سقوط می‌کند.

آن شکاف بین کمال محلی و شکست جهانی، «شکاف هماهنگی هوش مصنوعی» (AI Coordination Gap) است. این همان اصطکاکی است که در زمان تحویل کار (handoff) بین عامل‌ها (agents)، ابزارهای نرم‌افزاری و بازبین‌های انسانی از دست می‌دهید. نهادهای نظارتی از همین حالا در جستجوی این نقطه ضعف دقیق هستند. آن‌ها پیش از آنکه تیم مهندسی شما بررسی‌های پس از حادثه (post-mortem) خود را تمام کند، آن را شناسایی خواهند کرد.

تا سال ۲۰۲۶، بحث تغییر کرده است. دیگر سوال این نیست که کدام مدل در صدر جدول رده‌بندی تحقیقاتی قرار دارد؛ بلکه بحث بر سر انضباط بودجه، حاکمیت داده و کنترل به‌روزرسانی است. شما بین یک مدل زبانی کوچک (SLM) سفارشی که می‌توانید در زیرساخت خود محدود کنید، یا یک مدل زبانی بزرگ (LLM) آماده که بر اساس تعداد توکن اجاره می‌کنید، یکی را انتخاب می‌کنید.

SLM در مقابل LLM: در سال ۲۰۲۶ واقعاً چه چیزی تغییر می‌کند؟

مدل‌های پیشرو آماده — مانند GPT-4o، Claude و همتایان آن‌ها — برای استدلال باز و وظایف تحلیلی با حجم کم، همچنان بی‌رقیب هستند. آن‌ها معنای کلمات را درک می‌کنند و ظرافت‌ها را مدیریت می‌کنند. اما این راحتی، هزینه‌ای دارد. شما مالک وزن‌های مدل (weights) نیستید و برنامه انتشار به‌روزرسانی‌ها را کنترل نمی‌کنید. یک به‌روزرسانی بی‌صدای آخر هفته از سوی فروشنده می‌تواند نحوه تفسیر برنامه شما از آستانه‌های نسبت بدهی به درآمد یا علامت‌گذاری تراکنش‌های مشکوک را تغییر دهد، و شما ممکن است سندی از اینکه دقیقاً چه چیزی تغییر کرده است نداشته باشید. در صنعتی که هر تصمیم نیازمند ردپای حسابرسی (audit trail) است، این عدم شفافیت بسیار گران تمام می‌شود.

SLMهای سفارشی که بر پایه وزن‌های باز مانند Llama یا Mistral ساخته شده‌اند، معادله را تغییر می‌دهند. آن‌ها برای کارهای سنگین و پرحجم ساخته شده‌اند: استخراج فیلدها از فایل‌های PDF وام مسکن، طبقه‌بندی اسناد KYC یا تجزیه یادداشت‌های تراکنش. از آنجایی که شما میزبان آن‌ها هستید، می‌توانید یک نسخه را ثابت نگه دارید، تست‌های تفاضلی انجام دهید و به حسابرس ثابت کنید که مدلی که در ماه مارس رفتار کرده، با مدلی که در ماه ژوئن رفتار می‌کند، یکسان است. آن‌ها همچنین به طرز بی‌رحمانه‌ای ارزان هستند و هزینه هر توکن آن‌ها تقریباً ده تا سی برابر کمتر از همتایان ابری‌شان است. معامله (tradeoff) این است که قابلیت‌های محدودتری دارند. یک SLM درباره روندهای بازار فلسفه‌بافی نمی‌کند، اما می‌تواند در ساعت ده هزار فاکتور را بدون ارسال داده‌های اختصاصی به خارج از دیوار آتش (firewall) شما مهر بزند.

مسیریابی ناهمگون: تقسیم ۸۰/۲۰

بانک‌هایی که در حال پیشروی هستند، دیگر به این موضوع به عنوان یک انتخاب «یا این یا آن» نگاه نمی‌کنند. معماری آن‌ها ناهمگون است. یک SLM ارزان و تنظیم‌شده (fine-tuned) مرحله اول کارهای پیش‌بینی‌پذیر و ساختاریافته — مانند استخراج اسناد، برچسب‌گذاری موجودیت‌ها یا بررسی‌های روتین صلاحیت — را مدیریت می‌کند و حدود هشتاد درصد از کل حجم کار را از میان می‌برد. بیست درصد باقی‌مانده، یعنی موارد خاص (edge cases) که نیاز به استدلال قیاسی یا تفسیر پیچیده سیاست‌ها دارند، به یک LLM پیشرو ارجاع داده می‌شوند.

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

یک چارچوب پنج‌لایه برای پر کردن این شکاف

پر کردن شکاف هماهنگی، چیزی فراتر از مسیریابی هوشمند می‌طلبد. این کار به یک پشته (stack) صریح نیاز دارد. در اینجا یک چارچوب پنج‌لایه وجود دارد که تیم‌ها می‌توانند همین حالا مستقر کنند.

  1. انتخاب مدل. با استنتاج (inference) مانند یک پرستار تریاژ برخورد کنید. وظایف را بر اساس حجم و حساسیت مسیریابی کنید. عملیات‌های با فرکانس بالا و ریسک پایین به SLM شما می‌روند. مواردی که شامل قضاوت، ابهام یا حل شکایت مشتری هستند به LLM ارجاع داده می‌شوند. قوانین مسیریابی را در کد بنویسید، نه در یک پرامپت (prompt).

  2. استناد (Grounding). هر پاسخی که با مشتری در ارتباط است باید به یک سند مرجع ارجاع دهد. از تولید تقویت‌شده با بازیابی (RAG) استفاده کنید تا خروجی‌ها را بر اساس دفترچه‌های راهنمای سیاست‌ها، جداول نرخ و اطلاعیه‌های نظارتی واقعی خود تثبیت کنید. هرگز برای نرخ‌های بهره فعلی یا جداول کارمزد، به حافظه پارامتریک مدل اعتماد نکنید. حافظه دچار انحراف می‌شود، اما یک فایل PDF دارای شماره نسخه، خیر.

  3. هماهنگ‌سازی (Orchestration). جریان‌های کاری‌ای بسازید که مسیر آن‌ها قابل مشاهده باشد. ابزارهایی مانند LangGraph به شما اجازه می‌دهند ماشین‌های حالت صریح و قابل حسابرسی تعریف کنید. یک تصمیم باید از مراحل تعریف‌شده‌ای عبور کند: استخراج، تأیید، تصمیم‌گیری، ثبت (log). اجازه ندهید عامل‌ها (agents) در یک حلقه گفتگوی باز، صرفاً با «چت کردن» به نتیجه برسند. اگر نمی‌توانید نمودار جریان (flowchart) آن را رسم کنید، نمی‌توانید آن را برای یک نهاد ناظر توضیح دهید.

  4. دسترسی به ابزار. عامل‌ها نیاز دارند سیستم‌های بانکی اصلی را فراخوانی کنند، اما هر یکپارچه‌سازی یک نقطه شکست بالقوه است. از پروتکل بافت مدل (Model Context Protocol) استفاده کنید تا نحوه احراز هویت و پرس‌وجوی عامل‌ها از دفاتر کل، سوابق CRM و پایگاه‌های داده انطباق را استانداردسازی کنید. رابط‌های کاربری یکسان، سطح آسیب‌پذیری برای خرابی‌های بی‌صدا را کاهش می‌دهند.

  5. تأیید (Verification). یک مسیر مشخص و قطعی را برای قضاوت انسانی رزرو کنید. تصمیمات پرخطر — مانند حواله‌های بانکی بزرگ، تغییر محدودیت‌های اعتباری و گزارش‌های فعالیت مشکوک (SAR) — را به یک بازبین انسانی یا به عامل تأیید دوم که روی یک مدل ایزوله اجرا می‌شود، ارجاع دهید. افزونگی در لبه، از مرکز محافظت می‌کند.

معیار درست را اندازه‌گیری کنید

از پاداش دادن به تیم‌ها بر اساس دقت در هر مرحله دست بردارید. یک خط لوله (pipeline) که در آن هر ماژول در یک مجموعه آزمایشی ادعای دقت ۹۹ درصدی دارد، همچنان می‌تواند در هنگام تعامل مراحل، از هر پنج مشتری واقعی، یک نفر را با شکست مواجه کند. اندازه‌گیری قابلیت اطمینان سرتاسری (end-to-end) را شروع کنید. موارد شکست مصنوعی را تزریق کنید. تحویل مراحل (handoffs) را همان‌طور که مهاجمان درزها را تست می‌کنند، آزمایش کنید.

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