مقیاس بندی هوشمند: توسعه دهندگان LLM چگونه گلوگاه های ارکستراسیون چند عاملی را حل می کنند

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

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

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

محدودیت های متمرکز ارکستراتور

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

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

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

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

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

نفخ نشانه

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

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

پیچیدگی هماهنگی

حرکت از 1 به 5 عامل سطح بالایی از پیچیدگی هماهنگی را معرفی می کند. به خطاهای احتمالی حالت، شرایط مسابقه و نقاط شکست برای یک مدل هوش مصنوعی فکر کنید و آن را در تعداد مدل‌های افزایش‌یافته تا توان 2 ضرب کنید. این چیزی است که توسعه‌دهندگان با آن مواجه هستند. به عنوان مثال، انتقال به 3 عامل پیچیدگی را 9 افزایش می دهد و حرکت به 5 عامل آن را 25 افزایش می دهد. تحقیقات نشان می دهد که 36.9٪ از خرابی های سیستم چند عاملی به دلیل عدم همسویی هماهنگی است.

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

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

(اعتبار تصویر: مایکروسافت) برای هماهنگی مقرون‌به‌صرفه‌تر، ماشین‌های حالت مبتنی بر کد را نسبت به زمان‌های اجرا مدل‌محور با پایان باز انتخاب کنید که در آن عوامل آزادانه انتخاب می‌کنند که کدام یک از آنها صحبت بعدی را انجام دهند. مانند گفتن "اگر X، عامل A صحبت می کند" و "اگر Y، پس عامل B صحبت می کند" فکر کنید. اجبار ماشین‌های حالت قطعی و کد محور، سیستم‌های چند عاملی را از مصرف توکن‌ها برای تصمیم‌گیری در مورد اینکه چه کسی صحبت می‌کند، جلوگیری می‌کند و این باعث صرفه‌جویی قابل توجهی می‌شود.

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

خطاهای آبشاری و توهمات

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

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

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

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

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

وضعیت مشترک و باطل کردن حافظه پنهان

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

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

هنگام ساخت عوامل هوش مصنوعی، توسعه دهندگان معمولا برای کنترل هزینه ها و افزایش عملکرد، حافظه پنهان را پیاده سازی می کنند. ذخیره سازی شامل ذخیره پیشوندهای سریع است (به عنوان مثال، تعاریف ساده و پاسخ به سؤالات معمولی مانند "چگونه می توانم بازپرداخت سفارش خود را پردازش کنم؟"). در صورت ذخیره، نمایندگان مجبور نیستند توکن‌ها را دوباره پردازش کنند تا به هر سؤال معمولی پاسخ دهند. بلکه با داده های ذخیره شده پاسخ می دهد.

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

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

نظارت انسانی بیش از حد

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

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

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

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

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

استراتژی های کلی کاهش

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

حداقل نگه داشتن تعداد نماینده

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

جداسازی وظایف و دسترسی به فایل

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

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

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