آینده APIM با احتمال خیلی بد بودن (The Potentially Awful Future of APIM)
یک روند بسیار جالب که به نظر میرسد هیچکس درباره آن صحبت نمیکند این است که وقتی مدلهای زبانی بزرگ (LLMها) وارد صحنه شدند، افراد شروع کردند از آنها برای تلاش جهت تولید کد استفاده کنند. با روشنتر شدن این موضوع که LLMها در این کار واقعاً خوب هستند، فروشندگان LLM شروع به بهینهسازی و بنچمارک کردن آنها برای این هدف کردند و مهندسی نرمافزار را بهعنوان یک مورد استفاده مهم برای این فناوری در نظر گرفتند تا بتوانند بخشی از بازگشت سرمایه عظیم انجامشده را محقق کنند.
این موضوع، البته، باعث شد هشداردهندگان فریاد بزنند که هوش مصنوعی «شغلهای ما را میگیرد»، که برای هر کسی که بهطور جدی با هوش مصنوعی کدنویسی کرده باشد، کاملاً بیمعنی است (حداقل در کوتاهمدت).
استفاده از ابزار و انفجار عاملهای هوش مصنوعی
موضوع دیگری که رخ داده، معرفی «استفاده از ابزار» برای LLMها است که امکان یک انفجار در توسعه عاملهای هوش مصنوعی را فراهم کرده است. این یک قابلیت فوقالعاده است که دامنه کارهایی را که یک عامل خودمختار میتواند برای تعامل با محیط خود انجام دهد، بهشدت گسترش میدهد (من درباره این موضوع نوشتهام که چگونه یک فرایند کالاییسازی وجود دارد که شاید بخواهیم آن را با چیزهایی مانند Model Context Protocol شرکت Anthropic تشویق کنیم).
تنها افرادی که تا به امروز این روند را جدی گرفتهاند و بیشترین بهره را از آن بردهاند (به نظر من – لطفاً من را منشن نکنید) تیم Hugging Face هستند، زمانی که فریمورک عاملمحور خود به نام smolagents را منتشر کردند.
Smolagents و کدنویسی بهعنوان ابزار نهایی
Smolagents خود را درگیر استفاده از ابزار نمیکند، یا حداقل نه به شکلی که سایر فریمورکها و ابزارها این کار را انجام میدهند. Smolagents به چیزی مثل MCP نیاز ندارد تا در زمان اجرا به ابزارها دسترسی پیدا کند. در عوض، فقط یک ابزار دارد که بر همه ابزارها حکومت میکند، یک ابزار با بیان تقریباً نامحدود: کدنویسی با پایتون.
این فریمورک با پذیرفتن یک حقیقت ناخوشایند که حتی توسعهدهندگان انسانی را هم تحت تأثیر قرار میدهد (از گفتنش حس بدی دارم، اما خودم هم به آن مبتلا هستم)، بهطور کامل فرایند کالاییسازی ابزارسازی را دور میزند: کد چسبی. بله، کد چسبی اشکالی ندارد، به شرطی که موقتی باشد (درست است چت؟ درست است؟).
سیستمهای عاملمحور و FaaS
در طول سخنرانی من در LEAP 2.0، برخی از پیشبینیهای متواضعانهام درباره آینده را ارائه دادم (کاری که وقتی TechBro-CEO-Founder-Man™ هستید انجام میدهید) – بهطور مشخص درباره این صحبت کردم که سیستمهای عاملمحور چگونه تکامل پیدا خواهند کرد و چرا برخی از ابزارهای توسعهدهندهای که امروز وجود دارند، کاملاً ایدهآل برای موارد استفاده هوش مصنوعی هستند: پلتفرمهای Functions-as-a-Service.
اجازه دهید یک تیم عاملمحور ایدهآل (و سادهشده) را معرفی کنم؛ این تیم حداقل ۴ عضو دارد:
The Overseer (یا مدیر پروژه): این عامل توضیح وظیفه و نتایج مطلوب را دریافت میکند، سپس یک تیم (از مجموعهای از پروفایلهای از پیش تعیینشده) و یک برنامه پروژه طراحی میکند
The Librarian: این عامل به یک ابزار واحد دسترسی دارد: SearchForTools(); میتواند توضیح یک زیروظیفه را دریافت کرده و بررسی کند چه ابزارهایی از قبل وجود دارند که یک عامل اجرایی برای انجام وظایف به آنها نیاز دارد
The Toolmaker: این عامل فقط ابزارهایی ایجاد میکند که یک وظیفه را انجام میدهند و آنها را به بکاند FaaS ارسال میکند، سپس این ابزارها را نزد Librarian (یا ابزاری به نام RegisterTool()) ثبت میکند
Actor(s): این عاملها زیروظایف و مجموعه ابزارها را بهعنوان ورودی دریافت میکنند تا یک زیروظیفه مشخص را انجام دهند
این تیم عاملمحور بهصورت پویا مقیاسپذیر است: با ورود وظایف جدید، ابزارهای کاربردی بسیار متمرکز در صورت نیاز ایجاد میشوند، ثبت میگردند و سپس توسط عاملها برای تکمیل وظیفه جاری – و همچنین وظایف آینده – استفاده میشوند.
این ساختار قابل تطبیق است؛ تنها با داشتن اطلاعات پایهای درباره محیط خود، این عاملها میتوانند خودشان را به مجموعهای ایدهآل از ابزارها برای نوع وظایفی که باید انجام دهند، بوتاسترپ کنند. نوعی تکامل دیجیتال به سمت یک جایگاه مبتنی بر وظیفه.
حالا مشکل این موضوع برای APIM چیست؟
اگر این عاملها رفتاری شبیه عاملهای متمرکز بر توسعهدهنده فعلی مانند CLine یا Roocode داشته باشند، آنگاه حجم عظیمی از این توابع FaaS تولید خواهند کرد که هر کدام یک سرویس جدید در میان مجموعهای از سرویسهای مشابه هستند. سیستم عاملمحور واقعاً به استفاده مجدد اهمیتی نمیدهد، اما ما این زبالهها را نگه میداریم، زیرا از هر ۱۰۰ قطعه کد کاربردی زباله، ممکن است ۳ ابزار در وظایف آینده دوباره استفاده شوند، و با توجه به ارزان بودن ذخیرهسازی و محاسبات، چرا که نه؟
امنیت، پایش و نظارت
شما باید این چیزها را ایمن کنید – و باید آنها را پایش هم بکنید. این عاملها کدی خواهند نوشت که فراخوانیهای API را دستکاری میکند، آنها به توکنهای API کوتاهمدت برای سرویسهای داخلی نیاز خواهند داشت، باید محدودیتهای نرخ را رعایت کنند، باید پایش شوند تا مشخص شود به چه چیزی و در چه زمانی دسترسی دارند، و اگر با APIهای شرکای تجاری کار کنند، حتی ممکن است یک بودجه مشخص هم به آنها اختصاص داده شود.
فقط آیندهای مقیاسیافته از عاملهای هوش مصنوعی را تصور کنید – هزاران تیم کوچک که در حال اجرا هستند، کد ارسال میکنند، سرویس تولید میکنند و به APIها دسترسی دارند – هیچکس قرار نیست آن لاگ چت را بخواند. نه، معیارهای مشاهدهپذیری برای پایش این عاملها سر به فلک خواهد کشید – بسیار بالاتر از چیزی که هر Service Mesh معمولی یا راهبرد APIM متمرکز در حال حاضر برای آن آماده باشد.
علاوه بر این، آن توابع کاربردی در FaaS شما هم نیاز به ایمنسازی دارند – شاید زمین بازی ربات باشد، اما هر کدام از آنها یک نقطه دسترسی به زیرساخت شما از طریق یک LLM را نمایندگی میکنند و اگر فروشنده LLM دقت کافی نداشته باشد، آن حفره میتواند انواع دادهها را نشت دهد.
چرا این یک آینده پرچالش برای APIM است؟
زیرا همه چیز به استانداردسازی و خودکارسازی متکی است – خودکارسازی سنگین اعتبارنامههای امنیتی وابسته به سیستم و رشد لگاریتمی APIهای داخلی با مستندسازی ضعیف.
اگر یک راهبرد مدیریت API قوی در جای خود نداشته باشید و درک روشنی از این نداشته باشید که این گردشکارهای عاملمحور چگونه از APIها و دادههای شما استفاده خواهند کرد، در نهایت به وضعیتی میرسید که هیچ نظارتی بر کدهای بالقوه مخرب که در شبکه شما بهطور گسترده در حال اجرا هستند، ندارید.
بله، عاملهای هوش مصنوعی معمولاً تحت نظارت هستند، اما با گردشکارهای عاملمحور، جایی که عاملها مانند یک جعبه سیاه جادویی برای کاربر کار انجام میدهند، داستان متفاوت است. این عاملها نرمافزار هستند، آنها کد چسبی هستند، اما اگر از قبل با دقت برنامهریزی نکنید، نمیتوانید ببینید چه کاری انجام میدهند. درست مانند کد بد، اگر بدون پایش باقی بماند، غیرقابل مدیریت میشود.
جمعبندی و گام بعدی
با در نظر گرفتن همه اینها، چرا با یکی از معماران راهکار ما تماس نگیرید و بررسی نکنید که چگونه میتوانید آینده عاملمحور سازمان خود را با حاکمیت API قوی و نظارت دقیق به بهترین شکل مدیریت کنید.
