این بلاگ‌پست از Vivek Haldar رو می‌خوندم که یک مثالِ عملی و ملموس از مفهومِ «کامپایل کردن» agentها ارائه می‌داد، یعنی چطور یک فرآیندِ خودکار مبتنی بر LLM رو بهینه کرد و مصرف توکن و latency رو به شدت پایین آورد. این‌جا چند نکته‌ی جالبش رو می‌نویسم.
🔻 اصلا داستان چیه؟ Vivek یک skill داره که هر روز تو آرشیوِ بلاگ‌پست‌های قدیمی‌ش می‌گرده، یک مطلبِ ارزشمند برای بازنشر پیدا می‌کنه، چک می‌کنه که اخیرا بهش اشاره نکرده باشه، و یک پستِ کوتاهِ لینکدین به‌عنوان draft می‌نویسه. این draft هیچ‌وقت خودکار پست نمی‌شه؛ گاهی اصلا استفاده‌ش نمی‌کنه، ولی به‌عنوان یک نکته‌ی یادآوری کارش راه می‌افته.
نسخه‌ی اولیه کاملا با دستوراتِ natural language تو یک Agent Skill نوشته شده بود. منابعِ جستجو، چک کردنِ تاریخچه، معیارهای انتخاب و شکلِ نهاییِ draft. تو هر اجرا، agent (که الان Codex هست) باید این دستورات رو تفسیر می‌کرد، نقشه می‌کشید، ابزارها رو صدا می‌زد و state رو دنبال می‌کرد. این روشِ خوبی برای ساختِ نسخه‌ی اول بود، چون زبان طبیعی تغییر دادن فرآیند رو راحت می‌کرد.
🗂 وقتی فرآیند تثبیت شد
نکته اینه که بعد از این‌که یک skill بارها اجرا می‌شه و مدام همون مسیر رو طی می‌کنه، بیشترِ رفتارش دیگه اکتشافی نیست. این skill همیشه تو همون جاهای ثابت می‌گرده، همون content inventory رو می‌سازه، همون فیلترها رو اعمال می‌کنه و همون state رو ذخیره می‌کنه. هیچ‌کدوم ازینا لازم نیست هر صبح از صفر بازاندیشی بشه، خیلی‌هاش اصلا به LLM نیاز نداره.
در واقع فقط دو مرحله واقعا به LLM نیاز داره:
۱. انتخابِ یک کاندیدای خوب از بینِ inventoryِ فیلترشده
۲. نوشتنِ draftِ لینکدین بقیه‌ی همه‌چی می‌تونه کدِ معمولی و قطعی باشه.
💬 پس skill رو «کامپایل» کرده، و سپس Vivek اون skill رو به یک specialized harness تبدیل کرد. skill جدید عملا دیگه skill نیست، تبدیل شده به یک bootloader نازک که یک برنامه‌ی پایتون رو اجرا می‌کنه. اون برنامه منابع رو می‌گیره، inventory رو می‌سازه، پست‌های اخیر رو چک می‌کنه، فیلترها رو اعمال می‌کنه و کلِ فرآیند رو مدیریت می‌کنه، و فقط برای انتخاب و تولیدِ متن، LLM رو صدا می‌زنه.
نتیجه‌ش هم بهبودِ چشمگیر بود: ۹۴٪ کاهش در مصرف توکن ۸۷٪ کاهش در latency تقریبا همون کیفیتِ خروجی
نکته اینه که این صرفه‌جویی از عوض کردنِ مدل با یک مدلِ ارزون‌تر به دست نیومده، مراحل انتخاب و تولید هنوز همون مدل قبلی رو استفاده می‌کنن. صرفه‌جویی از حذفِ اون تماس‌هایی با مدل میاد که کارشون رو کدِ معمولی می‌تونست مستقیم‌تر انجام بده.
📑 حالا «کامپایل کردن» این‌جا یعنی چی؟
اون traceهای تاریخیِ اجرای قبلیِ skill رو داشت که نشون می‌داد agent واقعا چی کار کرده (planning، tool callها، انشعاب‌ها و stateها). این traceها، skill اصلی و نوشته‌های خودش درباره‌ی specialized harnessها رو به یک مدلِ قدرتمند داد و ازش خواست مشخص کنه کدوم مرحله‌ها واقعا به LLM نیاز دارن و کدوم‌ها اون‌قدر پایدار شدن که بشه کدشون کرد، و بعد harness رو بسازه.
به عبارتی، skill زبان طبیعی نقشِ یک specification سطح‌بالا رو داشت، در حالی که traceها جزئیاتِ عملیاتی رو تامین می‌کردن. به همین خاطره که Vivek میگه قیاسِ «کامپایلر» این‌جا مفیده: از یک نمایشِ منعطف و سطح‌بالا از هدف شروع می‌کنیم، و بعد از این‌که فرآیند به اندازه‌ی کافی اجرا شد و شکلِ واقعی‌ش مشخص شد، بخش‌های پایدارش رو به یک نمایشِ کارآمدتر «پایین می‌آریم».
نکته‌ی جالبِ آخرش این بود که چرا این تکنیک‌ها احتمالا از خودِ شرکت‌های بزرگِ مدل‌سازی نمیان: چون کارِ اون‌ها فروشِ توکنه، ترجیحا حجمِ زیادی توکن از گران‌ترین مدل‌هاشون. یک جمله‌ی قدیمی هست که میگه «خیلی سخته کسی رو به چیزی قانع کنی وقتی حقوقش به نفهمیدنِ اون بستگی داره.» تکنیکی که کیفیتِ خروجی رو حفظ می‌کنه ولی مصرف توکن رو ۹۴٪ کم می‌کنه، مستقیما در تضاد با اقتصادِ شرکتیه که درآمدش با مصرف توکن بالا می‌ره.
البته Vivek نمیگه هیچ‌کس داخلِ این شرکت‌ها به کارایی اهمیت نمی‌ده؛ ولی بین «ارزون‌تر کردنِ هر توکن» و «کمک به مشتری برای فهمیدن این‌که اصلا بیشترِ فرآیندش به توکن نیاز نداره» یک تفاوتِ مهم هست. پس این کار به کاربرها و سازنده‌های مستقل می‌رسه، و همین‌جا هم یک فرصتِ بزرگ برای founderهایی هست که ابزار و کامپایلر برای انتقال بخش‌های قطعیِ فرآیندها به کد می‌سازن.
✈️ @Mirage_Notes