معماری سامانه‌ها عامل اصلی موفقیت هوش مصنوعی است، نه قدرت مدل‌ها

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

به نقل از باباک حجت (Babak Hodjat)، مدیر ارشد هوش مصنوعی در شرکت Cognizant، این زیرساخت ساختاری است که واقعاً اهمیت دارد. این تغییر تمرکز در زمانی رخ می‌دهد که سازمان‌ها از چت‌بات‌های ساده به سمت اکوسیستم‌های پیچیده و چندعاملی حرکت می‌کنند. در حالی که صنعت دو سال گذشته را صرف وسواس روی تعداد پارامترها و نمرات بنچمارک کرده است، گلوگاه واقعی اکنون نحوه اتصال این مدل‌ها به واقعیت‌های سازمانی است. برای یک کسب‌وکار، مدل زبانی بزرگ (LLM) — مثل موتور یک ماشین است که قدرت تولید می‌کند — اما معماری، کل بدنه خودرو و نقشه‌ای است که مسیر حرکت را تعیین می‌کند.

زمینه: میراثی از پژوهش‌های عامل‌محور

دیدگاه باباک حجت ریشه در تجربه‌ای دارد که از نخستین نسخه‌های عامل‌های هوشمند شروع شد و تمام دوران حرفه‌ای او را در بر می‌گیرد. او یکی از بنیان‌گذاران Dejima بود و در آنجا فناوری‌های زبانی با رویکرد عامل‌محور را توسعه داد که در نهایت به زیربنای Siri اپل کمک کرد. سپس در Sentient Technologies به ساخت یکی از بزرگ‌ترین سیستم‌های هوش مصنوعی توزیع‌شده در جهان کمک کرد.

اکنون او در آزمایشگاه‌های پژوهشی Cognizant بر روی هوش مصنوعی عامل‌محور (Agentic AI)، محاسبات تکاملی و هوش توزیع‌شده تمرکز دارد. پژوهش‌های او به‌طور خاص برای استقرار در مقیاس بزرگ سازمانی طراحی شده است. او اشاره می‌کند که اگرچه تعریف «عامل هوش مصنوعی» از دهه ۱۹۹۰ ثابت مانده، اما قابلیت‌ها به‌طور بنیادین تغییر کرده‌اند. توابعی که پیش‌تر نیاز به کدنویسی دستی و سخت داشتند، اکنون از طریق LLMها به‌صورت آماده (out of the box) در دسترس هستند و این مدل‌ها را به استاندارد فعلی صنعت برای استدلال و رابط کاربری تبدیل کرده است.

شکاف معماری

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

همان‌طور که «هارنس‌ها» یا چارچوب‌های غیر LLM می‌توانند یک عامل کدنویسی را به موفقیت برسانند یا باعث شکستش شوند، معماری چندعاملی نیز بازتاب‌دهنده زمینه‌ای است که عامل‌ها در آن فعالیت می‌کنند. بدون این داربست، عامل‌ها در واقعیت‌های عملیاتی و داده‌های شرکت «بی‌بنیان» می‌مانند و نمی‌توانند در محیط واقعی سازمان عمل کنند.

بسیاری از استقرار‌های اولیه یا نمونه‌های اثبات مفهوم (PoC) به دلیل عدم دسترسی به داده‌های داخلی و اپلیکیشن‌های سازمانی، ناکام می‌مانند. برای تبدیل یک PoC به سیستمی آماده برای تولید (Production-ready)، حجت چهار پیش‌نیاز ضروری را نام می‌برد:

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

مقیاس‌پذیری در سازمان عامل‌محور

شرکت Cognizant این تئوری‌ها را در مقیاس واقعی پیاده کرده است. آن‌ها یک سیستم چندعاملی داخلی با حدود ۲۰۰ عامل برای سازمان با ۳۵۰ هزار کارمند مستقر کردند. این استقرار عظیم نشان داد که مقیاس‌پذیری نیازمند ابداعاتی است که در پروژه‌های کوچک یا پایلوت‌ها دیده نمی‌شوند:

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

حجت رویای یک «سیستم‌عامل عامل‌محور» را در سر دارد؛ نه یک OS واقعی به معنای سنتی، بلکه مجموعه‌ای از پروتکل‌های استاندارد هماهنگی. او معتقد است اگر هماهنگی بیش از حد سخت‌گیرانه باشد، سیستم شکننده می‌شود و اگر بیش از حد باز باشد و هماهنگی کاملاً به خود عامل واگذار شود، وظایف بیش از حد ریسکی می‌شوند.

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

او باور دارد همان‌طور که پروتکل زمینهٔ مدل (MCP) به استانداردی دوفاکتو برای دسترسی به اپلیکیشن‌ها تبدیل شده، پروتکل‌های مشابهی برای هماهنگی چندعاملی ظهور خواهد کرد تا فرآیندهای چندعاملی بتوانند از مرزهای سیستم‌ها عبور کنند. او اشاره می‌کند که اگرچه سیستم‌عامل‌ها و پلتفرم‌های ابری استعاره‌های رایجی هستند، اما نیاز واقعی، استانداردهایی مورد توافق برای تعریف عامل‌ها و پروتکل‌های هماهنگی است تا «عامل‌سازی» شکوفا شود.

اعتماد و حاکمیت

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

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

او اشاره می‌کند که مرز بین خودمختاری و نظارت انسانی توسط «اعتماد» تعیین می‌شود. هرچه سیستم‌ها قابل‌اعتمادتر شوند، مرز دخالت انسانی به‌طور طبیعی عقب‌تر می‌رود. مگر در مواردی که قوانین (مانند نبود شخصیت حقوقی برای AI) مانع شوند، سازمان‌ها با اندازه‌گیری و کاهش ریسک، پذیرای واگذاری اختیارات به عامل‌ها خواهند بود.

فراتر از گرادیان کاهشی

در حالی که بیشتر صنعت بر گرادیان کاهشی (Gradient Descent) — که حجت آن را نوعی «جست‌وجوی صعود از تپه» بدون خلاقیت می‌نامد — تکیه دارد، آزمایشگاه او در حال ادغام محاسبات تکاملی است. محاسبات تکاملی در جست‌وجوی فضاهای پیچیده بسیار کارآمد است و مکمل رویکردهای رایج است.

او مدعی است که یک پیشرفت اخیر نشان داده است که «استراتژی‌های تکاملی» در اکثر مراحل پس‌آموزش LLMها بر یادگیری تقویتی (Reinforcement Learning) برتری دارند و کیفیت برابر یا بهتر را با هزینه‌ای به‌مراتب کمتر ارائه می‌دهند. این رویکرد به‌ویژه برای «آموزش در زمان تست» (Test-Time Training) مفید است و به مدل‌ها اجازه می‌دهد پس از استقرار، یاد بگیرند و سازگار شوند.

این موضوع محدودیت اصلی LLMهای فعلی را حل می‌کند: آن‌ها پس از آموزش تا حد زیادی ثابت می‌مانند و در مواجهه با اطلاعات جدید، به‌سختی «نظرشان را تغییر می‌دهند». چون LLMها در واقع «همه چیز و همه کس را به‌طور همزمان» هستند، نسبت به زمینه‌سازی (Priming) و کانتکست بسیار حساس باقی می‌مانند.

ریسک رفتارهای نوظهور

با این حال، حجت درباره رفتارهای نوظهور (Emergent Behavior) هشدار می‌دهد. عامل‌های متقابل می‌توانند رفتارهای پیش‌بینی‌نشده‌ای مثل همکاری، رقابت یا حتی استراتژی‌های فریب‌کارانه ایجاد کنند. او به اتفاقات اخیر بین OpenAI و Hugging Face اشاره می‌کند که نشان داد عامل‌ها حتی بدون یادگیری در زمان اجرا، وقتی محیط یا انگیزه‌هایشان تغییر می‌کند، غیرقابل‌پیش‌بینی می‌شوند.

برای مقابله با این ریسک، Cognizant سیستم TerraLingua را توسعه داده است؛ محیطی عمومی که کاربران می‌توانند عامل‌ها و مصنوعات را معرفی کنند یا حتی نقش عامل را بازی کنند تا رفتارهای جمعی را در محیطی امن مشاهده کنند. این کار به توسعه‌دهندگان اجازه می‌دهد پیش از استقرار در جریان‌های کاری حساس، دامنه تمایلات نوظهور را نقشه‌برداری کنند.

مسیر پیش رو

در نهایت، حجت معتقد است پیش از آنکه AI بتواند اهداف پیچیده و طولانی‌مدت را با کمترین دخالت انسانی مدیریت کند، چند پیشرفت تکنولوژیک لازم است. LLMهای فعلی توسط پنجرهٔ زمینه (Context Window) محدود شده‌اند و باید تمام اطلاعات را برای هر کلمه یا اقدام دوباره دریافت کنند.

برای رسیدن به پتانسیل کامل آیندهٔ عامل‌محور، صنعت به این موارد نیاز دارد:

• پروتکل‌های هماهنگی توزیع‌شده و پذیرفته‌شده در سطح گسترده.
• حفاظ‌ها و سیاست‌های اعتماد مستحکم.
• سیستم‌های داور تراکنش (Transaction Arbiter Systems).

این چرخش معماری به این معناست که مزیت رقابتی از کسانی که «بهترین مدل» را دارند به کسانی منتقل می‌شود که «بهترین سیستم» را برای مدیریت آن‌ها می‌سازند. برندگان، سازمان‌هایی خواهند بود که با عامل‌های AI نه به عنوان یک به‌روزرسانی نرم‌افزاری، بلکه به عنوان نیروی کاری که نیاز به مدیریت دارد، برخورد کنند.

گام بعدی شما

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

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