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

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

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

مشکل گره خورده همکاری عامل

چرا سیستم های چند عامل ارکستر چنین چالشی هستند؟ خوب ، برای مبتدیان:

1. آنها مستقل هستند: بر خلاف توابع که در یک برنامه خوانده می شوند ، نمایندگان اغلب حلقه های داخلی ، اهداف و ایالت های خود را دارند. آنها فقط با صبر و حوصله منتظر دستورالعمل نیستند.
2. ارتباطات پیچیده می شود: این فقط نماینده صحبت با نماینده B. نماینده A نیست که ممکن است اطلاعات اطلاعات C و D را از آن مراقبت کند ، در حالی که نماینده B قبل از گفتن به F ، منتظر سیگنال از E است.
3. آنها باید یک مغز مشترک (حالت) داشته باشند: چگونه همه آنها در مورد “حقیقت” آنچه اتفاق می افتد موافق هستند؟ اگر نماینده یک رکورد را به روز کند ، چگونه نماینده B در مورد آن می داند قابل اعتماد وت سریع؟ اطلاعات قدیمی یا متناقض یک قاتل است.
4. شکست اجتناب ناپذیر است: یک عامل سقوط می کند. یک پیام گم می شود یک تماس خدمات خارجی از زمان خارج می شود. وقتی یک قسمت از سیستم به پایان رسید ، شما نمی خواهید که همه چیز به حالت متوقف یا بدتر از آن ، انجام کار اشتباه را انجام دهد.
5. قوام می تواند دشوار باشد: چگونه اطمینان می دهید که یک فرآیند پیچیده و چند مرحله ای که شامل چندین عامل در واقع به یک وضعیت نهایی معتبر می رسد؟ این کار هنگام توزیع و ناهمزمان کار ساده ای نیست.

به عبارت ساده تر ، پیچیدگی ترکیبی با اضافه کردن عوامل و تعامل بیشتر منفجر می شود. بدون برنامه جامد ، اشکال زدایی به یک کابوس تبدیل می شود و سیستم احساس شکننده می کند.

انتخاب دفترچه بازی ارکستراسیون خود

نحوه تصمیم گیری نمایندگان با هماهنگی کار آنها شاید اساسی ترین انتخاب معماری باشد. در اینجا چند چارچوب وجود دارد:

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

بسیاری از سیستم های چند عامل در دنیای واقعی (MAS) به یک هیبرید تبدیل می شوند-شاید یک ارکستر سطح بالا صحنه را تنظیم کند. سپس گروه های عوامل درون آن ساختار به طور متقاطع هماهنگ می شوند.

مدیریت مغز جمعی (حالت مشترک) عوامل هوش مصنوعی

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

الگوهای معماری ما به آن تکیه می دهیم:

• کتابخانه مرکزی (پایگاه دانش متمرکز): یک مکان تک و معتبر (مانند یک بانک اطلاعاتی یا یک سرویس دانش اختصاصی) که در آن همه اطلاعات مشترک زندگی می کنند. نمایندگان کتاب ها را بررسی می کنند (بخوانید) و آنها را برگردانید (بنویسید).
  • طرفدار: منبع واحد حقیقت ، اجرای سازگاری آسان تر است.
  • CON: می تواند با درخواست ها چکش شود ، به طور بالقوه همه چیز را کاهش می دهد یا به یک نقطه خفگی تبدیل می شود. باید به طور جدی قوی و مقیاس پذیر باشد.
• یادداشت های توزیع شده (حافظه نهان توزیع شده): مأمورین نسخه های محلی از اطلاعات مورد نیاز را برای سرعت نگه می دارند ، که توسط کتابخانه مرکزی پشتیبانی می شود.
  • PRO: سریعتر می خواند.
  • CON: چگونه می دانید نسخه شما به روز است؟ بی اعتبار بودن حافظه پنهان و قوام به معماهای مهم معماری تبدیل می شوند.
• به روزرسانی های فریاد (ارسال پیام): به جای اینکه نمایندگان دائماً از کتابخانه بخواهند ، کتابخانه (یا سایر نمایندگان) فریاد می زند “سلام ، این اطلاعات تغییر کرده است!” از طریق پیام ها نمایندگان به روزرسانی هایی که به آنها اهمیت می دهند گوش می دهند و یادداشت های خود را به روز می کنند.
  • PRO: نمایندگان جدا شده اند که برای الگوهای رویداد محور مفید است.
  • CON: اطمینان از اینکه همه پیام را دریافت می کنند و به درستی از آن برخورد می کنند ، پیچیدگی را اضافه می کند. اگر پیام گم شود چه می شود؟

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

ساختمان برای وقتی که کارها اشتباه می شود (رسیدگی به خطا و بازیابی)

این در صورت عدم موفقیت یک عامل نیست ، چه زمانی است. معماری شما باید این را پیش بینی کند.

به این فکر کنید:

• دیده بان (نظارت): این به معنای داشتن مؤلفه هایی است که شغل آنها به سادگی تماشای عوامل دیگر است. اگر یک عامل ساکت شود یا بازیگری عجیب و غریب را شروع کند ، نگهبان می تواند دوباره شروع به راه اندازی مجدد آن یا هشدار دادن به سیستم کند.
• دوباره امتحان کنید ، اما هوشمند باشید (احیا و idempotency): اگر عمل یک عامل انجام نشود ، اغلب باید دوباره دوباره امتحان کنید. اما ، این تنها در صورتی کار می کند که این عمل idempotent باشد. این بدان معناست که انجام این کار پنج بار دقیقاً همان نتیجه را دارد که یک بار آن را انجام می دهد (مانند تعیین یک مقدار ، نه افزایش آن). اگر اقدامات غیرمذهبی نباشد ، ترمیم ها می توانند باعث ایجاد هرج و مرج شوند.
• تمیز کردن ظروف (جبران خسارت): اگر نماینده A با موفقیت کاری انجام داد ، اما عامل B (یک مرحله بعدی در روند) شکست خورد ، ممکن است نیاز به “خنثی کردن” کار Agent A داشته باشید. الگوهای مانند ساگاس به هماهنگی این گردش کار چند مرحله ای و قابل جبران کمک می کند.
• دانستن اینکه کجا هستید (وضعیت گردش کار): نگه داشتن یک گزارش مداوم از روند کلی کمک می کند. اگر سیستم از اواسط کار پایین بیاید ، می تواند از آخرین مرحله خوب شناخته شده به جای شروع کار ، انتخاب کند.
• ساخت فایروال (قطع کننده های مدار و قسمتهای اصلی): این الگوهای مانع از خرابی در یک عامل یا سرویس از اضافه بار یا خرابی دیگران ، حاوی آسیب می شوند.

اطمینان از انجام کار به درستی (اجرای کار ثابت)

حتی با قابلیت اطمینان نماینده فردی ، شما به این اطمینان نیاز دارید که کل کار مشترک به درستی تمام شود.

در نظر بگیرید:

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

بهترین معماری به پایه و اساس درست نیاز دارد.

• اداره پست (صف پیام/کارگزاران مانند Kafka یا RabbitMQ): این برای تجزیه و تحلیل عوامل کاملاً ضروری است. آنها پیام را به صف ارسال می کنند. نمایندگان علاقه مند به این پیام ها آنها را انتخاب می کنند. این امر ارتباطات ناهمزمان را امکان پذیر می کند ، سنبله های ترافیکی را کنترل می کند و برای سیستم های توزیع شده انعطاف پذیر مهم است.
• کابینت تشکیل پرونده مشترک (فروشگاه های دانش/پایگاه داده): اینجاست که دولت مشترک شما زندگی می کند. بر اساس ساختار داده و الگوهای دسترسی خود ، نوع سمت راست (رابطه ، NOSQL ، GRAPH) را انتخاب کنید. این باید اجرا و بسیار در دسترس باشد.
• دستگاه اشعه ایکس (سیستم عامل های مشاهده): سیاهههای مربوط ، معیارها ، ردیابی – شما به اینها نیاز دارید. اشکال زدایی سیستم های توزیع شده بسیار سخت است. قادر به دیدن دقیقاً هر نماینده ای که انجام می داد ، چه موقع و چگونه آنها در تعامل بودند ، غیر قابل مذاکره است.
• دایرکتوری (رجیستری عامل): چگونه مأمورین یکدیگر را پیدا می کنند یا خدمات مورد نیاز خود را کشف می کنند؟ یک رجیستری مرکزی به مدیریت این پیچیدگی کمک می کند.
• زمین بازی (کانتینر و ارکستراسیون مانند Kubernetes): اینگونه است که شما در واقع تمام آن نمونه های عامل فردی را با اطمینان مستقر ، مدیریت و مقیاس می کنید.

مأمورین چگونه گپ می زنند؟ (انتخاب پروتکل ارتباطات)

نحوه صحبت کردن نمایندگان بر همه چیز از عملکرد تا چقدر محکم همراه است.

• تماس تلفنی استاندارد شما (استراحت/http): این ساده است ، در همه جا کار می کند و برای درخواست/پاسخ اساسی خوب است. اما می تواند کمی احساس چرب کند و برای ساختارهای داده با حجم بالا یا پیچیده کمتر کارآمدتر باشد.
• تماس کنفرانس ساختاری (GRPC): با استفاده از قالب های داده کارآمد ، از انواع مختلف تماس از جمله جریان پشتیبانی می کند و از نوع ایمن است. این برای عملکرد بسیار عالی است اما نیاز به تعریف قراردادهای خدماتی دارد.
• صفحه بولتن (صف پیام – پروتکل هایی مانند AMQP ، MQTT): نمایندگان پیام را به موضوعات ارسال می کنند. سایر نمایندگان در موضوعاتی که به آنها اهمیت می دهند مشترک هستند. این فرستنده های ناهمزمان ، بسیار مقیاس پذیر و کاملاً جدا شده از گیرنده ها است.
• خط مستقیم (RPC – کمتر متداول): نمایندگان توابع را مستقیماً در مورد سایر عوامل فراخوانی می کنند. این سریع است ، اما اتصال بسیار تنگ ایجاد می کند – عامل باید دقیقاً بداند که آنها چه کسی تماس می گیرند و کجا هستند.

پروتکل متناسب با الگوی تعامل را انتخاب کنید. آیا این یک درخواست مستقیم است؟ یک رویداد پخش؟ جریانی از داده ها؟

قرار دادن همه اینها

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

این پیچیده است ، بله ، اما با تمرکز بر این طرح های معماری – تعامل ارکستر ، مدیریت دانش مشترک ، برنامه ریزی برای شکست ، اطمینان از قوام و ایجاد یک بنیاد زیرساخت محکم – شما می توانید پیچیدگی و ساخت سیستم های هوشمندانه و هوشمند را ایجاد کنید که موج بعدی Enterprise AI را هدایت می کند.

نیکیل گوپتا مدیر مدیریت محصول AI/مدیر محصول کارکنان Atlassian استبشر