۸۰٪ شکست‌های سامانه‌های چندعاملی ریشه در نقصِ فرآیندها دارند، نه مدل‌ها

اگر منتظرید تا نسخه‌ی بعدی مدل‌های پیشرو توهمات یا حلقه‌های تکرار را در سامانه‌هایتان حل کند، احتمالاً در اشتباهید. شکست واقعی در سامانه‌های چندعاملی (Multi-agent system) نه در قلب مدل، بلکه در درزهای بین عامل‌ها رخ می‌دهد؛ جایی که زمینه (Context) گم می‌شود و دستورالعمل‌ها با هم تداخل می‌کنند. سیستم شما احتمالاً نه به دلیل ضعف مدل زبانی بزرگ (LLM)، بلکه به دلیل نبود یک مشخصات فرآیندی (Process Specification) دقیق در حال شکست است.

بسیاری از تیم‌ها داستانی مشابه دارند: دمو با پنج عامل در نقش‌های تفکیک‌شده — پژوهشگر، برنامه‌ریز، کدنویس، بازبین و خلاصه‌ساز — در یک مسیر ایده‌آل (Happy Path) عالی کار می‌کرد و شبیه به آینده به نظر می‌رسید. اما به محض مواجهه با ورودی‌های واقعی، سیستم یا شروع به تولید پاسخ‌های متقاعدکننده اما غلط کرد، یا در حلقه‌های تکرار گیر افتاد و بخشی از تسک را به‌طور خاموش حذف کرد.

این شکست سیستمی توضیح می‌دهد چرا اکثریت قریب به اتفاق پروژه‌های آزمایشی عامل‌محور هرگز به مرحله‌ی تولید پایدار نمی‌رسند. گارتنر (Gartner) پیش‌بینی می‌کند سهم بزرگی از پروژه‌های عامل‌محور تا سال ۲۰۲۷ لغو شوند. اگر علت شکست، توانمندی مدل‌ها بود، هر نسخه‌ی جدید مدل‌های پیشرو این پروژه‌ها را نجات می‌داد؛ اما چنین نشد. تنها در هفته‌ی اول سپتامبر ۲۰۲۴، چهار مدل پیشرو عرضه شدند، اما هیچ‌کدام گره‌های کور پروژه‌های متوقف‌شده را باز نکردند. این تضاد میان عملکرد در محیط آزمایشگاهی و واقعیت، دلیل اصلی شکست بسیاری از عامل‌های هوش مصنوعی در محیط عملیاتی است که پیش‌تر به آن پرداخته‌ایم. همان‌طور که در تحلیل قبلی ما درباره‌ی جلوگیری از رانش مدل‌ها در استقرار Llama اشاره کردیم، صنعت اکنون با مشکلی مشابه در سطح معماری روبروست: سیستم‌هایی که وضعیت «200 OK» برمی‌گردانند اما به‌طور خاموش در اجرای منطق واقعی کسب‌وکار شکست می‌خورند.

کالبدشکافی شکست

به نقل از مطالعه‌ای توسط سِمری و همکاران (Cemri et al.) در پژوهش MAST، محققان بیش از ۱۶۰۰ ردپای اجرا (Execution traces) را در هفت چارچوب محبوب چندعاملی بررسی کردند. این یک مطالعه‌ی برچسب‌گذاری دقیق با شش ارزیاب و ضریب کاپای کوهن (Cohen's kappa) ۰.۸۸ بود، نه یک گزارش بر اساس «حس کلی». یافته‌ها شکست‌ها را به سه دسته‌ی اصلی تقسیم می‌کند:

• طراحی سیستم و مشخصات (~۴۱.۸٪): این دسته شامل تفسیر غلط تسک، تعریف مبهم نقش‌ها، تجزیه نادرست وظایف (Task Decomposition)، وجود دو عامل با دستورالعمل‌های متداخل و نبود شرایط توقف (Termination Conditions) مشخص است.
• عدم همراستاسازی بین‌عاملی (~۳۶.۹٪): شکست‌هایی مانند گم شدن زمینه در لحظه‌ی دست‌ورود (Handoff)، عدم تطابق فرمت‌ها، تضاد بین پاسخ عامل‌ها و انحراف گفتگوها از مسیر اصلی تسک.
• تأیید تسک و توقف (~۲۱.۳٪): این بخش مربوط به سیستم‌هایی است که خیلی زود متوقف می‌شوند، فرآیند تأیید را به‌طور ناقص انجام می‌دهند یا تأییدات را به‌صورت غلط صادر می‌کنند.

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

تله‌ی خطای ضرب‌شونده

برخلاف سامانه‌های تک‌عاملی که خطای آن‌ها خطی است — جایی که شما یک خروجی بد می‌بینید و آن را اصلاح می‌کنید — معماری‌های چندعاملی از «تقویت ضرب‌شونده‌ی خطا» رنج می‌برند. وقتی عامل B خروجی عامل A را به‌عنوان حقیقت مطلق (Ground Truth) می‌پذیرد و عامل C نیز خروجی B را می‌پذیرد، یک خطای کوچک اولیه تکثیر و «سفیدشویی» می‌شود.

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

بر اساس مستندات این پژوهش، ضریب تقویت خطا در توپولوژی‌های بدون هماهنگی می‌تواند به ۱۷ برابر برسد، در حالی که در سیستم‌های دارای گلوگاه اعتبارسنجی متمرکز، این عدد حدود ۴.۴ برابر است. اگرچه این ضرایب به توپولوژی و نوع تسک بستگی دارند و باید به عنوان جهت‌نما دیده شوند نه قانون مطلق، اما روند کلی آن‌ها غیرقابل انکار است. پیامد عملی این است که هر دست‌ورود باید حامل «میزان اطمینان» و «منبع» باشد. اگر عامل A نتواند بگوید «۶۰٪ مطمئنم و منبعم این است»، عامل B راهی برای تردید مناسب ندارد و معماری شما به یک «ماشین شایعه» تبدیل می‌شود.

مهندسی راهکار

برای عبور از توسعه‌ی مبتنی بر «حس کلی»، شرکت SyncSoft.AI توصیه می‌کند با ارکستراسیون عامل‌ها مانند طراحی فرآیند با یک کارگر احتمالی (Stochastic worker) برخورد کنید. این همان چارچوبی است که ما هنگام مواجهه با مسائل اتوماسیون گردش‌کار و عملیات دیجیتال به کار می‌بریم: ابتدا فرآیند را ترسیم کنید، استثناها را نام‌گذاری کنید، قرارداد دست‌ورود را تعریف کنید و سپس تصمیم بگیرید کدام گام‌ها باید توسط یک عامل مدیریت شوند. برای پایداری سیستم، پنج انضباط زیر ضروری است:

۱. نوشتن مشخصات فرآیند پیش از پرامپت‌ها: تعریف نقش در یک جمله‌ی کوتاه در پرامپت سیستمی (System Prompt)، مشخصات فنی نیست. آن را با یک دستورالعمل استاندارد عملیاتی (SOP) جایگزین کنید. یک مشخصات واقعی باید تعریف کند: چه چیزی عامل را فعال می‌کند، چه ورودی می‌گیرد، چه خروجی باید بدهد، طرحواره (Schema) مورد نیاز چیست، مسئولیت‌های صریحش کدام‌اند (چه کارهایی را نباید انجام دهد)، چگونه با ورودی‌های بدشکل برخورد کند و دقیقاً چه شرطی به معنای پایان کار است. در این راستا باید به یاد داشت که سخت‌گیرانه‌تر کردن دستورات لزوماً به پاسخ‌های بهتر منجر نمی‌شود و کلید موفقیت در طراحی ساختار فرآیند است، نه فقط بهینه‌سازی پرامپت‌ها. صنعت برون‌سپاری فرآیندهای تجاری (BPO) سی سال است یاد گرفته است که ابهام در مشخصات دست‌ورود، جایی است که کیفیت می‌میرد.

۲. دست‌ورودهای تایپ‌شده (Typed Handoffs): از دست‌ورودهای متن-آزاد فاصله بگیرید، زیرا این مورد بیشترین بازدهی را برای اصلاح دارد. از بسته‌های ساختاریافته‌ای استفاده کنید که شامل ادعا، سطح اطمینان، منبع و فهرستی از سؤالات باز باشد. اجبار کنید عامل فرستنده صراحتاً اعلام کند چه چیزی را تأیید نکرده است. یک عدم تطابق در طرحواره (Schema) که در مرز بین دو عامل شناسایی شود، یک باگ شناسایی‌شده است؛ اما عدم تطابقی که توسط «خوش‌رویی» و انعطاف مدل LLM پوشانده شود، یک باگ خاموش است.

۳. تأیید قطعی (Deterministic Verification): از به‌کارگیری عامل‌های «منتقد» به‌عنوان تنها لایه‌ی تأیید دست بردارید. دسته‌ی ۲۱.۳ درصدی تأییدات، بخشی است که تیم‌ها بدترین عملکرد را در آن دارند. یک منتقد بدون مرجع، فقط نظر دومی از همان توزیع احتمالی است و با خوشحالی کارهای غلط اما متقاعدکننده را تأیید می‌کند. تأیید واقعی نیازمند چک‌های قطعی است (مثلاً: آیا کد کامپایل می‌شود؟ آیا اعداد با هم همخوانی دارند؟ آیا ارجاعات وجود دارند؟) یا استفاده از مجموعه‌های مرجع برچسب‌گذاری شده توسط انسان. شما به مجموعه‌ای از ردپاهای گردش‌کار خود نیاز دارید که توسط یک متخصص دامنه امتیازدهی شده باشد تا بتوانید «کارکرد سیستم» را از «تولید خروجی توسط سیستم» تشخیص دهید.

۴. توپولوژی متمرکز: با یک معماری تحت نظارت (Supervisor-led) شروع کنید که دارای گیت اعتبارسنجی باشد تا شعاع تخریب خطا محدود شود. این روش شاید خسته‌کننده به نظر برسد، اما عیب‌یابی آن بسیار ساده‌تر است. توپولوژی مش (Mesh) که در آن هر عامل با هر عاملی حرف می‌زند در نمودارها زیباست، اما محل رشد خطاهای ضرب‌شونده است. ابتدا پایداری را به دست آورید و سپس به سراغ مدل مش بروید.

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

شکاف مشاهده‌پذیری

سخت‌ترین بخش این گذار این است که این شکست‌ها در پشته‌های استاندارد مشاهده‌پذیری (Observability) نامرئی هستند. داشبورد شما بازه‌ها (Spans)، تأخیر و تعداد توکن‌ها را نشان می‌دهد، اما نمی‌گوید که عامل B به‌طور خاموش شرط سوم دستورات عامل A را نادیده گرفته است، چون هر دو فراخوانی وضعیت ۲۰-۲۰۰ برگردانده‌اند و تمام بازه‌ها سبز هستند. سیستم فقط به‌طور خاموش کار اشتباهی را انجام داده است.

تنها راهکار، کار کند و خسته‌کننده‌ی خواندن ردپاهای سرتاسری (End-to-end traces) و برچسب‌گذاری نقاطی است که استدلال یا دست‌ورود از مسیر خارج شده است. این دقیقاً همان کاری است که نویسندگان MAST انجام دادند و دلیل اهمیت متدولوژی آن‌هاست. پیش از آنکه درباره‌ی شکست‌ها تئوری بسازید، آن‌ها را برچسب‌گذاری کنید.

بسیاری از تیم‌ها از این کار دوری می‌کنند چون زمان‌بر است، اما این کاری است که بیشترین نرخ بازگشت سرمایه (ROI) را دارد. صد ردپای شکست‌خورده که با دقت برچسب‌گذاری شده باشند، بیش از هر بنچمارک عمومی، به شما می‌گویند چه چیزی را باید اصلاح کنید. علاوه بر این، این ردپاها می‌توانند به عنوان داده‌های اولیه برای اصلاح مسیر (Trajectory Correction) و داده‌های ترجیحی (Preference Data) استفاده شوند، اگر بعداً بخواهید رفتار ارکستراسیون را به‌جای پرامپت‌نویسی، از طریق Fine-tune اصلاح کنید.

این تغییر دیدگاه، توسعه‌ی هوش مصنوعی را از قلمرو مهندسی پرامپت (Prompt Engineering) به قلمرو طراحی سازمانی منتقل می‌کند. سامانه‌های چندعاملی در واقع یک مسئله‌ی طراحی سازمانی هستند که با پایتون پیاده شده‌اند. توزیع شکست‌ها ثابت می‌کند که ۷۹٪ مشکلات مربوط به مشخصات، تجزیه، دست‌ورود و تأیید است — دقیقاً همان چیزهایی که وقتی یک پروژه را بدون دستورالعمل مکتوب بین دو تیم انسانی جابه‌جا می‌کنید، خراب می‌شود.

باگ تقریباً همیشه در «دستورالعمل» است، نه در «مغز» مدل. برای شروع ممیزی سیستم‌های خود، ۱۰ ردپای شکست‌خورده را از لاگ‌های تولید استخراج کنید و قرارداد دست‌ورود هر گام را به‌صورت دستی ترسیم کنید.

من در SyncSoft.AI فعالیت می‌کنم، جایی که به تیم‌های هوش مصنوعی کمک می‌کنیم تا مجموعه‌داده‌های برچسب‌گذاری، ارزیابی و بازخورد انسانی را برای سیستم‌هایی از این دست بسازند. اگر با ارزیابی ردپای عامل‌ها یا تجزیه گردش‌کار دست‌وپنجه نرم می‌کنید، خوشحال می‌شوم تجربیاتمان را به اشتراک بگذاریم — با من در تماس باشید یا همین‌جا پاسخ دهید.

گام بعدی شما

• استخراج ۱۰ مورد از شکست‌های اخیر سیستم خود و تحلیل دستی نقاط گسست در دست‌ورودها.
• جایگزینی تعریف نقش‌های متنی با SOPهای ساختاریافته برای هر عامل.
• پیاده‌سازی یک لایه‌ی تأیید قطعی (Deterministic) به‌جای تکیه بر عامل‌های منتقد.

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