مالیات ارکستراسیون: تو همون تکترد سیستمی
هوش مصنوعیخلاصهٔ کاملتر
ایدهی مرکزی مقالهی ادی عثمانی اینه: راهاندازی ایجنتهای هوش مصنوعی خیلی ارزون شده، ولی این به معنی بیشتر شدن ظرفیت تو نیست. میتونی ۲۰ تا ایجنت بدوونی و کاملاً سرت شلوغ باشه، ولی این ۲۰ برابر کارِ تحویلشده نیست. تمام قضاوتی که برای هدایت اونها و ادغام کدشون توی پروژه لازمه، باید از دقیقاً یه پردازندهی سریال رد شه: خودت. اون اسم این موضوع رو «مالیات ارکستراسیون» (orchestration tax) میذاره.
نویسنده میگه این یه مشکل انضباط نیست، یه مشکل معماریه. یه عدمتقارن پنهان توی این جریانهای کاری هست: شروع کردن یه ایجنت با یه جمله یا یه کلید خیلی ارزونه، ولی بستن حلقهش اصلاً ارزون نیست. یکی باید چک کنه چیزی که برگشته درسته و با کاری که بقیهی ایجنتها دست زدن آشتیش بده. اون یکی تویی، و فقط یه نفری.
بهترین قیاسش از دنیای برنامهنویسی همروند (concurrent) میاد. پایتون یه قفل به اسم GIL داره که اجازه میده هر لحظه فقط یه ترد بایتکد اجرا کنه. عثمانی میگه تو همون GIL ایجنتهاتی: همه میتونن همزمان بدوون، ولی هر وقت کارشون به فهم واقعی معماری یا حل تعارض merge برسه، باید قفل رو بگیرن و فقط یه قفل هست که دست توئه. قانون امدال هم اینو دقیق میکنه: شتابی که از موازیسازی میگیری محدود به بخشیه که سریال میمونه. توی توسعه با ایجنت، اون بخش سریال همون قضاوته؛ ۸ تا ایجنت زمان قضاوت تو رو سریعتر نمیکنه، فقط صف کارهای منتظر قضاوت رو عمیقتر میکنه.
همینجاست که فرق شلوغ بودن و مولد بودن خودش رو نشون میده. بهینه کردن بخشی که گلوگاه نیست throughput رو بالا نمیبره، فقط تلِ کارهای ناتمام جلوی گلوگاه رو بزرگتر میکنه. خستگیای هم که نویسنده ازش حرف میزنه علت مشخصی داره: هزینهی context switch. هر بار که به یه ایجنت سر میزنی مغزت رو خالی میکنی و یه زمینهی دیگه رو از صفر لود میکنی؛ CPU این کارو توی میکروثانیه میکنه و تو توی چند دقیقه و هیچوقت هم کامل بازسازی نمیشه.
برای همین میگه باید توجهت رو مثل یه منبع سریال کمیاب معماری کنی. چند تا توصیهی عملی میده. اول، تعداد ایجنتها رو به نرخ بازبینیت مقیاس بده نه به چیزی که UI اجازه میده — مثل backpressure توی سیستمهای همروند، تولیدکننده باید خودش رو با مصرفکننده هماهنگ کنه، و عدد درست برای بیشتر ما تکرقمی پایینه. دوم، کارها رو دستهبندی کن: کارهای ایزوله رو به ایجنتهای پسزمینه بسپار، ولی کارهای پیچیدهای که خودِ قضاوت کارن رو موازی نکن. سوم، بازبینیها رو batch کن تا هزینهی context switch کم شه. چهارم، قفل رو فقط خرج قضاوت کن و کارهای قابلتأیید توسط ماشین (مثل نوشتن تست یا گرفتن اسکرینشات) رو به خودش بسپار. و پنجم، زمان سریالت رو محافظت کن و بهترین ساعتهات رو بهش بده.
نویسنده هشدار میده که حالت شکست این ماجرا نامرئیه. ۲۰ ایجنت در حال اجرا حس بهرهوری عظیم میده ولی این حس از shipping واقعی کد خوب جداست. مالیات ارکستراسیونِ پرداختنشده، هم بدهی فنی و هم بدهی شناختی رو همزمان جمع میکنه: کدی رو merge میکنی که خوب نخوندی و مدل ذهنیت از کدبیس کهنه میشه. جمعبندیش اینه: مهارت واقعی راهانداختن ایجنت نیست، طراحی سیستم حول اون تنها منبع سریالیه که نه میشه کلونش کرد نه موازیش کرد — یعنی توجه تو.
نکات کلیدی:
- شروع ایجنت ارزونه ولی بستن حلقهش (بررسی و ادغام) گرون و سریاله
- تو مثل GIL پایتونی؛ همهی کارهای نیازمند قضاوت باید از یه قفل رد شن
- قانون امدال: موازیسازی محدود به بخش سریاله که همون قضاوته
- تعداد ایجنت رو به نرخ بازبینی مقیاس بده، کارهای پیچیده رو موازی نکن
- شلوغ بودن با مولد بودن فرق داره و حالت شکستش نامرئیه
