شکاف بین نمایش و استقرار؛ چرا عامل‌های هوش مصنوعی در مقیاس تجاری شکست می‌خورند؟

یک عدد اشتباه که درست به‌نظر برسد، خطرناک‌ترین شکست در دنیای تنظیم‌شده‌ی خدمات مالی است. دیویا ناگاسوبرامانیان (Dhivya Nagasubramanian)، معاون تحول و نوآوری هوش مصنوعی در یکی از مؤسسات مالی بزرگ ایالات متحده و نویسنده‌ی کتاب «هوش مصنوعی عامل‌محور برای مهندسان» (Agentic AI for Engineers)، هشدار می‌دهد که سامانه‌های عامل‌محور (Agentic) در حال تکرار الگوهای شکست نرم‌افزارهای سنتی هستند، اما با ریسک‌هایی به‌مراتب بالاتر. او پیشینه‌ای طولانی در ساخت سامانه‌های حسابداری پرتفوی و اندازه‌گیری عملکرد برای پلتفرم‌های بانکی دارد که از سال ۲۰۰۸ آغاز شده است. کتاب او از زمان انتشار، بیش از ۶۰۰۰ بار در SpringerLink مورد دسترسی نهادی قرار گرفته و در بیش از ۲۶۰ کتابخانه در سراسر جهان، از جمله در دانشگاه‌های مختلف، پذیرفته شده است.

منظر ناگاسوبرامانیان از دقت، ریشه در پروژه‌هایی با ریسک بالا دارد. یکی از پروژه‌های اولیه او ساخت یک موتور منطبق با استانداردهای GIPS برای محاسبه بازده‌های موزون‌شده زمانی بود که در نهایت توسط مؤسسات مالی در بیش از ۸۰ کشور جهان پذیرفته شد. او بعدها متوجه یک شکاف ساختاری در مدل مارکوفِ یک مدل تخصیص بازاریابی (Marketing Attribution) بسیار رایج شد. با وجود اینکه صدها هزار کاربر از این مدل استفاده می‌کردند، این خطا سال‌ها باقی ماند چون خروجی‌ها «منطقی» به نظر می‌رسیدند. در دنیای عامل‌های هوش مصنوعی (AI Agents) — که شبیه کارمندی هستند که نه تنها پیشنهاد می‌دهد، بلکه اجازه دارد دکمه‌ی اجرا را هم بزند — این مشکل تشدید می‌شود؛ زیرا عامل فقط نتیجه را اشتباه تولید نمی‌کند، بلکه بر اساس آن نتیجه، اقدام می‌کند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شکاف بین محیط‌های آزمایشگاهی و دنیای واقعی عمیق است. در حالی که آزمایشگاه‌های پژوهشی قابلیت‌ها را با محک‌های ایستا (Static Benchmarks) اندازه می‌گیرند، سازمان‌ها در محیطی با ابهامات، داده‌های متغیر و فشارهای متخاصم فعالیت می‌کنند. اکثر نوشته‌ها درباره‌ی عامل‌ها در مرحله‌ی «دمو» متوقف می‌شوند. اما برای مهندسی که باید نامش پای سیستمی برود که با نظارت محدود در یک نهاد تنظیم‌شده اجرا می‌شود، انتقال از یک دموی خیره‌کننده به یک سیستم آماده‌ی تولید، نیازمند عبور از اتوماسیون ساده به سمت خودمختاری حقیقی است. این تمایز مربوط به مدل مورد استفاده نیست، بلکه به این مربوط است که قدرت تصمیم‌گیری در کجا قرار دارد. در همین راستا، برخی شرکت‌ها مانند AGI Inc با تمرکز بر استقرار عامل‌های محلی برای کنترل مستقیم دستگاه‌ها، سعی دارند مرزهای این خودمختاری در محیط‌های واقعی را جابجا کنند.

آزمون خودمختاری

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

• اتوماسیون: اگر پاسخ بله است، شما با یک اتوماسیون روبرو هستید. این ممکن است یک اتوماسیون پیچیده با یک مدل زبانی در دل آن باشد، اما در نهایت یک گردش‌کار اسکریپتی (Scripted Workflow) است.
• خودمختاری: خودمختاری زمانی رخ می‌دهد که سیستم اهداف را تجزیه کرده، ابزارها را انتخاب می‌کند و ترتیب اقدامات را در لحظه‌ی اجرا بر اساس بستری (Context) تصمیم می‌گیرد که شما برای آن اسکریپت ننوشته‌اید.

طبق اعلام ناگاسوبرامانیان، سازمان‌ها اغلب این دو را اشتباه می‌گیرند. نامیدن یک گردش‌کار اسکریپتی به عنوان «عامل‌محور»، بیشتر یک مشکل بازاریابی است. اما برخورد با یک عامل خودمختار به عنوان یک اتوماسیون قطعی (Deterministic)، یک شکست عملیاتی پرهزینه است. در حالت دوم، تیم‌ها فرض می‌کنند که تکرارپذیری و الگوهای شکست شناخته‌شده‌ای وجود دارد، در حالی که برای عامل‌های خودمختار چنین چیزی وجود ندارد. ردپاهای بازرسی (Audit Trails) آن‌ها بر اساس یک قاعده ردیابی‌پذیر پشت هر اقدام است، اما این قاعده برای یک عامل خودمختار صادق نیست. این امر نیازمند یک تغییر نگرش است: مهندسان به‌جای پرسیدن «آیا سیستم درست اجرا شد؟»، باید بپرسند «آیا سیستم درست تصمیم گرفت؟»

معماری اجباری برای محیط تولید

محیط‌های تولیدی، کنترل‌های موجود در نمایش‌ها را از بین می‌برند. ناگاسوبرامانیان در مصاحبه با unite.ai اشاره می‌کند که دموها چون محیطشان توسط کسی کنترل شده است جواب می‌دهند، اما محیط تولید این کنترل را می‌گیرد. او در کتابش یک معماری مرجع هفت‌لایه را توصیف می‌کند، اما پنج مؤلفه را برای هر عامل آماده‌ی تولید «اجباری» می‌داند:

• قراردادهای ابزار (Tool Contracts): ورودی‌های تایپ‌شده و مجوزهای صریح برای محدود کردن دسترسی عامل از طریق طراحی، نه از طریق امیدواری.
• مدیریت وضعیت (State Management): سامانه‌هایی که در برابر قطعی‌ها و شکست‌های سیستمی دوام می‌آورند تا تداوم عملیات حفظ شود.
• مدیریت شکست ساختاریافته: تعریف صریح مسیرهای ارجاع (Escalation) و وضعیت‌های شکست تایپ‌شده، به‌جای اجازه دادن به هوش مصنوعی برای بداههپردازی.
• سیستم ارزیابی مستمر: تست‌هایی که در تمام چرخه در CI (یکپارچه‌سازی مستمر) اجرا شوند تا هر تغییر در پرامپت‌ها، ابزارها و مدل‌ها فیلتر شده و به عنوان دروازه‌ای برای تغییرات عمل کنند، نه اینکه فقط یک بازبینی تک‌باره پیش از لانچ صورت گیرد.
• ردپای بازرسی استدلالی: ثبت «چرایی» و منطق پشت هر تصمیم (Reasoning)، نه فقط ثبت اقدام نهایی صورت گرفته.

نقش تأیید در لحظه‌ی اجرا

یکی از بخش‌های فراموش‌شده در استقرار AI، تأیید در لحظه‌ی اجرا (Runtime Verification) است. زیرساخت‌های استاندارد بررسی می‌کنند که آیا یک فراخوانی از طریق کدهای وضعیت (Status Codes)، طرح‌ها (Schemas)، تأخیر (Latency) و نرخ خطا موفق بوده یا خیر، اما تأییدِ معنایی می‌پرسد: «آیا این فراخوانی اصلاً باید انجام می‌شد؟» این اولین چیزی است که تیم‌ها بعد از استقرار در تولید آرزوی داشتن آن را می‌کنند، زیرا در دموها که هیچ چیز نیاز به مهار شدن ندارد، هرگز ارزش خود را ثابت نمی‌کند.

این رویکرد نیازمند «مانیتورینگ معنایی» است تا اقدامات را با اهداف اعلام‌شده و سیاست‌های خاص بسنجد. ناگاسوبرامانیان این کار را تعریف «ناپایدارهای معنایی» (Semantic Invariants) می‌نامد؛ ویژگی‌هایی که باید فارغ از مسیر انتخاب‌شده توسط عامل، برقرار باشند. به عنوان مثال:

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

اگر عاملی یک فراخوانی API را از نظر فنی درست انجام دهد اما داده‌های غلط را بخواند، لاگ‌های معمولی «موفقیت» نشان می‌دهند، اما مانیتورینگ معنایی تخلف را شناس می‌کند. این تنها راه شناسایی «انحراف از هدف» (Goal Drift) است؛ جایی که عامل طبق لاگ‌ها هر مرحله را درست طی می‌کند، اما بی‌صدا به سمت هدف اشتباهی می‌رود. چون هیچ چیز در معنای سنتی «شکست» نمی‌خورد، انحراف از هدف هرگز در لاگ‌های استاندارد ظاهر نمی‌شود. مانیتورینگ معنایی با «قصد» (Intent) به عنوان چیزی که مستقیماً اندازه‌گیری می‌شود برخورد می‌کند، و دقیقاً در همین نقطه است که عامل‌ها دچار خطا می‌شوند.

فرآیند تضمین مستمر

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

تضمین مستمر (Continuous Assurance) از طریق این مکانیسم‌ها محقق می‌شود:

• یکپارچه‌سازی CI: ارزیابی‌های رفتاری مانند Unit Testها در یکپارچه‌سازی مستمر اجرا شوند تا هر تغییر در پرامپت، ابزار یا مدل فیلتر شود.
• بازخورد تولید: ردهای اجرای واقعی (Production Traces) به مجموعه‌های ارزیابی بازگردانده شوند.
• تست تکرارشونده: هر حادثه باید منجر به یک بررسی جدید شود، مشابه اینکه هر باگ منجر به یک تست رگرسیونی شود.
• تست‌های خصمانه زمان‌بندی‌شده: انجام تست‌های Red Teaming در بازه‌های زمانی منظم، نه فقط به عنوان یک اتفاق یک‌باره پیش از لانچ.

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

طراحی برای شکست و ایمنی

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

او برای مقابله با این موضوع، «وضعیت‌های شکست تایپ‌شده» (Typed Failure States) را پیشنهاد می‌کند:
۱. دستور مبهم: فعال کردن پرسش برای شفاف‌سازی.
۲. سیاست متضاد: ارجاع به انسان با ارائه کامل زمینه.
۳. ابزار در دسترس نبودن: بازگشت به حالت «فقط خواندنی» یا تلاش مجدد با محدودیت‌های سخت‌گیرانه‌تر.
۴. اعتماد پایین: توقف برای بازبینی.

او تأکید می‌کند که آستانه اعتماد باید با ریسک اقدام همخوان باشد؛ استاندارد نوشتن یک خلاصه داخلی نباید با استاندارد دست‌زدن به حساب مشتری (Touching a customer account) یکی باشد. همچنین، مسیرهای ارجاع باید پیش از «مسیر موفق» (Happy Path) طراحی شوند. اگر قرار است یک انسان تحویل بگیرد، توسعه‌دهندگان باید پیش از نوشتن اولین پرامپت، تصمیم بگیرند که آن انسان چه زمینه‌ای در اختیار داشته باشد و چه اختیاراتی داشته باشد. تیم‌های مهندسی باید شکست را با تزریق دستورات مبهم و غیرفعال کردن ابزارها در محیط Staging تست کنند، زیرا سیستمی که هرگز تمرین شکست نکرده باشد، در محیط تولید بدون راهنما عمل خواهد کرد.

حاکمیت و نظارت انسانی

در خدمات مالی، تعادل بین تجربه و رعایت قوانین (Regulatory Compliance) حیاتی است. ناگاسوبرامانیان استدلال می‌کند که تأیید انسانی برای اقدامات زیر اجباری است:

• اقدامات غیرقابل بازگشت.
• جابجایی پول یا تأثیر بر نتایج درمانی.
• ارتباطات با مشتری که بار قانونی و تنظیم‌گرایانه دارد.
• خوراک‌های مربوط به گزارش‌های نظارتی.
• تغییر در ابزارها، سیاست‌ها یا مجوزهای خودِ عامل.

در مقابل، عامل‌ها می‌توانند کارهایی مثل تحقیق، بازیابی، تحلیل سند، تریاژ، پیش‌نویس و تطبیق داده‌هایی (Reconciliations) که تضادها را برای بازبینی انسانی علامت می‌زنند، به‌طور ایمن مدیریت کنند.

الزام به تأیید انسانی در هر مرحله معمولاً به «مهر زدن ماشینی» (Rubber Stamping) منجر می‌شود که بدون افزودن ایمنی، فقط ناکارآمدی دستی را بازتولید می‌کند. تأییدات باید برای نقاط تصمیم‌گیری واقعی و توسط افرادی با صلاحیت واقعی برای «نه گفتن» رزرو شوند. خودمختاری باید «به‌دست بیاید، نه اینکه اعطا شود»؛ یعنی از دایره‌ای محدود شروع شده و با اثبات کارایی زیر نظارت، گسترش یابد. این یک محیط کنترلی ایجاد می‌کند که به شرکت اجازه می‌دهد به رگولاتور ثابت کند نه تنها عامل چه کرده است، بلکه چرا این سطح از استقلال توجیه‌پذیر بوده است. این رکورد، مجوز واقعی برای فعالیت (License to operate) است.

ایمنی چندفرهنگی و استواری خصمانه

محک‌های غربی-محور اغلب شکست‌ها در زبان‌ها، گویش‌ها یا بسترهای فرهنگی خاص را نمی‌بینند. یک مدل ممکن است نمره ایمنی میانگین بالایی داشته باشد اما در یک زبان کم-منبع (Low-resource language) به‌طور فاجعه‌باری شکست بخورد؛ این‌ها «برش‌های ضعیفی» (Weak Slices) هستند که مهاجمان مکرراً آن‌ها را هدف قرار می‌دهند. این نقاط کور شامل آسیب‌های فرهنگی خاص، اصطلاحات، حرکات یا زمینه‌های مذهبی و منطقه‌ای است که در یک فرهنگ بی‌ضرر و در فرهنگ دیگر تخریبی است. ارزیابی‌ها اغلب نایوان‌بودن در مواجهه با تغییر کد (Code-switching)، نویسه‌گردانی (Transliteration) و نام‌ها و موجودیت‌های غیرغربی را نادیده می‌گیرند.

برای حل این مشکل، ناگاسوبرامانیان در پژوهش‌های مربوط به محک‌های ایمنی AI چندفرهنگی مشارکت می‌کند و تأکید دارد که قضاوت درباره ایمنی در فرهنگ‌های مختلف نیازمند داده‌های ارزیابی و قضاوت انسانی از همان فرهنگ‌های خاص است. او سه قانون برای سازمان‌ها پیشنهاد می‌دهد:
۱. ارزیابی هر بخشِ هدف: هرگز میانگین جهانی را به عنوان مدرک ایمنی نپذیرید.
۲. مجموعه‌های ارزیابی محلی: ساخت مجموعه‌های داده از جمعیت‌های واقعی مشتریان.
۳. تست خصمانه چندزبانه: تست‌ها را به هر زبانی که مشتریان استفاده می‌کنند اجرا کنید. اگر شرکتی در چهل کشور مشتری دارد اما فقط به انگلیسی ارزیابی می‌کند، سیستم را برای استقرار در جای دیگری اندازه گرفته است.

استانداردها و آینده هوش مصنوعی عامل‌محور

ناگاسوبرامانیان بین حفاظ‌های ساختاری که امروز قابل استانداردسازی‌اند و تنظیمات وابسته به زمینه تفکیک قائل است. استانداردهای ساختاری شامل موارد زیر است:

• مستندسازی مرزهای قابلیت‌ها و مجوزها.
• تعریف مکانیسم‌های نظارت انسانی و ارجاع.
• تعهدات مربوط به تشخیص و گزارش حوادث.
• متدهای ارزیابی و الزامات شواهدی.
• پاسخگویی صریح در تمام چرخه سیستم تا پاسخ به سؤال «چه کسی مسئول است» هرگز فقط «هوش مصنوعی» نباشد.

با این حال، آستانه‌های اعتماد، تاکسونومی‌های آسیب و سطوح مناسب خودمختاری باید وابسته به زمینه باشند. تحمل شکست برای یک عامل تولید محتوای بازاریابی با سیستمی که تصمیمات بالینی یا مالی می‌گیرد، در رژیم‌های متفاوتی قرار دارند که توسط حوزه، حوزه قضایی و کسی که متحمل آسیب شکست می‌شود، شکل می‌گیرند. کنترل‌های مالی مدل مفیدی در اینجا هستند: الزامات حسابرسی به‌طور جهانی استاندارد شده‌اند، اما «مهمیت» (Materiality) همیشه در زمینه سنجیده می‌شود.

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

در نگاه به آینده، حیاتی‌ترین چالش حل‌نشده، تأیید در لحظه‌ی اجرا برای سامانه‌های چندعاملی (Multi-agent systems) است. در حالی که ناپایدارهای معنایی برای یک عامل قابل مدیریت است، وقتی عامل‌ها کار را به عامل‌های دیگر می‌سپارند، رفتارها «نوظهور» (Emergent) می‌شوند. ریسک به «لحظه تحویل» (Handoffs) منتقل می‌شود، جایی که دستورات ممکن است در هر مرحله کمی بازتفسیر شوند یا سیاست‌هایی برای یک عامل اجرا شود اما برای عاملی که استخدام کرده است، اجرا نشود. تأیید تعامل بین عامل‌ها، و نه فقط اقدامات هر عامل به تنهایی، مرز بعدی در جلوگیری از شکست‌های خاموش است.

با سپاس از این مصاحبه عالی، خوانندگان همچنین می‌توانند کتاب Agentic AI for Engineers را سفارش دهند.

گام بعدی شما

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

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