ناوبری اصلی

راهکارهایی برای طراحی سامانه‌های عاملی

راهکارهای عملی به تیم‌ها کمک می‌کنند تعیین کنند کدام رفتارهای عامل به مدل زبانی و کدام‌یک به نرم‌افزار صریح تعلق دارند.

خلاصه مدیریتی

  • باید به‌دقت بررسی کنید که تصمیم‌ها در کجا و چگونه در سامانه عاملی شما گرفته می‌شوند.

  • واگذاری تصمیم‌های بیشتر به الگوهای زبانی بزرگ (LLM) می‌تواند سامانه را برای تعمیم به وظایف بیشتر توانمند کند، اما ممکن است سرعت، قابلیت اطمینان و استحکام آن را کاهش دهد.

  • تا حد امکان، بخش بیشتری از فرایند تصمیم‌گیری را از الگوهای زبانی بزرگ (LLM) خارج و به کد صریح نرم‌افزار منتقل کنید. این موضوع به‌ویژه درباره گردش‌کارهای پرخطر و/یا عملیاتی صدق می‌کند.

مقدمه

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

برای درک بهتر، می‌توان این انتخاب را طیفی میان رویکردهای زیر دانست:

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

  • عامل‌های هماهنگ‌کننده به الگوهای زبانی بزرگ (LLM) متکی‌اند تا جریان وظایف را با استفاده از پرامپت‌های زبان طبیعی به‌صورت پویا تعیین کنند؛ رویکردی مناسب برای تعاملات باز که منطق ازپیش‌تعریف‌شده در آن‌ها کافی یا ممکن نیست.

نموداری برای توضیح مقدمه.

برای گردش‌کارهای پرخطر و عملیاتی، معمولاً توصیه می‌کنیم بیشتر از قابلیت‌های مبتنی بر مسیریاب استفاده کنید و هماهنگ‌کننده‌ها را برای کاربردهایی نگه دارید که به گفت‌وگوهای انعطاف‌پذیر و همه‌منظوره نیاز دارند.

مسیریاب در برابر هماهنگ‌کننده: شناخت تفاوت‌ها

معماری‌های مبتنی بر مسیریاب

سامانه‌های عاملی مسیریاب:

  • جریان تصمیم‌گیری را به‌صراحت از طریق کد یا نرم‌افزار تعریف می‌کنند و برای تعیین مسیری که نرم‌افزار باید طی کند، از الگوهای زبانی بزرگ (LLM) بهره می‌گیرند.

  • به سامانه‌های نرم‌افزاری سنتی نزدیک‌ترند، زیرا مسیرهایی روشن و پیش‌بینی‌پذیر دارند که نتایج سازگارتری ایجاد می‌کنند.

  • برای وظایفی که می‌توان آن‌ها را دقیقاً تعریف کرد، ایدئال‌اند.

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

نموداری برای توضیح تفاوت مسیریاب و هماهنگ‌کننده.

معماری‌های هماهنگ‌کننده

برخلاف سامانه مسیریاب، سامانه‌های عاملی هماهنگ‌کننده:

  • جریان‌های منطقی را به‌جای نرم‌افزار، با پرامپت‌های زبان طبیعی تعریف می‌کنند. توجه: زبان طبیعی در مقایسه با زبان برنامه‌نویسی، ذاتاً مبهم و انعطاف‌پذیر است؛ ویژگی‌ای که همان‌طور که بعداً توضیح می‌دهیم، هم مزیت است و هم عیب. ما این رویکرد را «بیان مقصود به‌جای دستور» می‌نامیم.

  • می‌توانند چندین گزینه پردازشی ارائه دهند و تعیین ترتیب و روش اجرا را به الگوهای زبانی بزرگ (LLM) بسپارند.

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

  • این ابهام می‌تواند به خروجی‌های ناسازگار منجر شود، اما وقتی درست کار کند، ممکن است «جادویی» به نظر برسد.

مثال زیر رویکرد هماهنگ‌کننده را برای همان مسئله ساده شرکت هواپیمایی به کار می‌گیرد. به‌جای آنکه نرم‌افزار پاسخ مناسب را تعیین کند، تصمیم‌گیری به لایه الگوهای زبانی بزرگ (LLM) واگذار می‌شود. در اینجا سامانه‌ای چندعاملی داریم که در آن یک عامل هماهنگ‌کننده «مرکزی»، درخواست کاربر را ارزیابی و آن را به عاملی ویژه تغییر پرواز ارجاع می‌دهد؛ آن عامل نیز در نهایت پاسخ را به کاربر ارائه می‌کند.

در این مثال، لایه الگوهای زبانی بزرگ (LLM) هم‌زمان نقش دسته‌بندی‌کننده، مسیریاب و نویسنده پاسخ را بر عهده دارد. در مثال مسیریاب، این لایه فقط نقش دسته‌بندی‌کننده را داشت و بقیه کارها را نرم‌افزار انجام می‌داد.

نموداری برای توضیح تفاوت مسیریاب و هماهنگ‌کننده.

نقاط قوت و چالش‌های معماری مسیریاب

توصیه می‌کنیم هرجا ممکن است از رویکردهای مبتنی بر مسیریاب استفاده کنید، زیرا مزایای زیر را دارند:

  • سرعت و کارایی: محاسبات محلی در مقایسه با هماهنگ‌کننده‌های وابسته به APIهای خارجی، سرعت بسیار بیشتری دارند. همچنین پردازش منطق «IF/ELSE» در پایتون بسیار ارزان‌تر از پرداخت هزینه به ارائه‌دهنده الگوهای زبانی بزرگ (LLM) برای پردازش آن با مدل ۴۰۰ میلیاردپارامتری است.

  • آزمون‌پذیری و پیش‌بینی‌پذیری: اشکال‌زدایی، آزمون و نگهداری با استفاده از رویه‌های جاافتاده نرم‌افزاری به‌مراتب آسان‌تر است.

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

عیب رویکردهای مسیریاب این است که ممکن است خشک و انعطاف‌ناپذیر باشند و در مسائل بازتر با مشکل مواجه شوند. کاربران ممکن است چت‌باتی را که همیشه پاسخ‌هایی کاملاً یکسان می‌دهد، کسل‌کننده یا ایستا بدانند.

نقاط قوت و چالش‌های معماری هماهنگ‌کننده

طراحی‌های هماهنگ‌کننده قابلیت‌های قدرتمندی دارند:

  1. برنامه‌ریزی: می‌توانند پاسخ‌ها را به‌صورت پویا برنامه‌ریزی کنند.

  2. انتخاب ابزار/ارجاع به عامل: ابزار مناسب را انتخاب می‌کنند یا وظایف را به عامل‌ها می‌سپارند.

  3. ترکیب تکرارشونده خروجی‌ها: خروجی‌ها را طی چند مرحله و به‌شیوه‌ای خلاقانه بازترکیب می‌کنند.

  4. تشخیص تکمیل کار: تعیین می‌کنند چه زمانی اطلاعات کافی برای نهایی‌کردن پاسخ جمع‌آوری شده است.

چارچوب‌هایی مانند Pydantic-AI یا Agents SDK شرکت OpenAI، پیاده‌سازی هماهنگ‌سازی را ساده و سریع می‌کنند. بنابراین این رویکرد برای نسخه‌های نمایشی یا اثبات مفهوم بسیار مناسب است.

معایب این رویکرد عبارت‌اند از:

  • هیچ تضمینی وجود ندارد که مراحل برنامه‌ریزی الگوهای زبانی بزرگ (LLM) و اقدامات پس از آن درست یا مناسب باشند. سامانه مسیریاب نیز همین مشکل را دارد، اما چون محدودتر است، رفتارش پیش‌بینی‌پذیرتر خواهد بود.

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

  • از آنجا که منطق بیشتری در الگوهای زبانی بزرگ (LLM) جای می‌گیرد، سامانه در برابر دور زدن محدودیت‌ها یا سوءاستفاده عاملان مخرب بسیار آسیب‌پذیرتر می‌شود.

  • این رویکرد تصمیم‌گیری را در الگوهای زبانی بزرگ (LLM) انتزاع می‌کند و در نتیجه درک سامانه را دشوارتر می‌سازد؛ هرچند ابزارهای پایشی مانند Langfuse یا Braintrust ممکن است تا حدی کمک کنند.

راهکارهای پیشنهادی ما برای طراحی سامانه‌های عاملی

یادداشت برای خواننده: با اینکه توانمندی مدل‌ها به‌سرعت تغییر می‌کند، بعید است نکات زیر در آینده نزدیک تغییر کنند.

تصمیم‌های موردنیاز برنامه خود را بشناسید

دامنه مسئله خود را مشخص کنید.

  • آیا می‌توانید منطق تصمیم‌گیری مطلوب خود را به‌آسانی در یک نمودار تعریف کنید؟

  • آیا بروز خطا یا رفتار غیرمنتظره در برنامه شما پذیرفتنی نیست؟

پاسخ «بله» به هر یک از پرسش‌های بالا نشان می‌دهد قابلیت‌های مسیریاب گزینه بهتری هستند.

ابتدا مسیریاب، سپس رویکردهای ترکیبی

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

وقتی این رویکردها به محدودیت خود می‌رسند، می‌توان برخی از مزایای بازِ هماهنگ‌کننده را به‌شکلی کنترل‌شده بازآفرینی کرد. برای مثال:

  1. انتخاب ابزار/ارجاع به عامل: به‌آسانی با انشعاب‌های شرطی یا دسته‌بندی‌کننده‌های الگوهای زبانی بزرگ (LLM) پیاده‌سازی می‌شود.

  2. تشخیص تکمیل کار: دسته‌بندی‌کننده‌های ساده الگوهای زبانی بزرگ (LLM) می‌توانند پیش از ارائه پاسخ به کاربر، کامل‌بودن آن را بررسی کنند.

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

جمع‌بندی و چشم‌انداز آینده

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

با ادامه پیشرفت الگوهای زبانی بزرگ (LLM)، ممکن است توازن میان این رویکردها تغییر کند. برای بارهای کاری عملیاتی، معماری‌های مبتنی بر مسیریاب یا ترکیبی را ترجیح می‌دهیم و هماهنگ‌کننده‌ها را برای مسائل بازی نگه می‌داریم که به تعاملی پویا و انسان‌مانند نیاز دارند.

نویسنده

Andrew Liubinas