آقا این مقاله یه Position Paperئه، یعنی اومده یه دیدگاه رو مطرح کنه و بگه آینده این شکلیه. خلاصه حرفش اینه که آینده‌ی ایجنت‌ها دست مدل‌های کوچیک (SLMs) هست، نه این LLMهای غول‌پیکر. استدلالش هم اینه که اکثر کارهایی که یه ایجنت می‌کنه، تکراری و تخصصیه. پس چرا برای یه کار ساده، یه مدل ۱۷۵ میلیاردی رو صدا بزنیم؟ به جاش بیایم برای هر تسک یه SLM متخصص و fine-tune شده بذاریم که هم سریع‌تره، هم ارزون‌تر. برای اون بخش‌هایی هم که نیاز به فکر کردن و استدلال عمیق داره، یه LLM رو به عنوان مغز متفکر یا orchestrator می‌ذاریم که کارها رو به SLMهای کارگر پاس بده. یه معماری heterogeneous.

دمشون گرم برای این نکته‌ها:

اقتصاد Inference رو درست فهمیدن: اینکه هزینه سرو کردن یه مدل ۷ میلیاردی ۱۰ تا ۳۰ برابر ارزون‌تر از یه مدل ۷۰ میلیاردیه، یه فکت کاملاً تجربه‌شده‌ست. وقتی نیاز به parallel کردن مدل روی کلی GPU نداری، هزینه‌های نگهداری و عملیات (operational cost) به شدت میاد پایین. اینو هرکی یه مدل رو production برده باشه با گوشت و پوستش حس کرده.

زدن تو خال با Behavioral Alignment: این یکی از بهترین نکته‌های فنی مقاله‌ست. توی سیستم‌های ایجنتیک، مدل باید یه خروجی با فرمت دقیق (مثلاً JSON) بده تا tool بعدی کار کنه. هرکی ایجنت واقعی نوشته باشه می‌دونه LLMهای بزرگ گاهی زیادی خلاق می‌شن و فرمت رو یه جوری می‌دن که کل پایپ‌لاین می‌خوابه. یه SLM که فقط برای تولید یه فرمت خاص fine-tune شده، خروجی به شدت قابل اعتمادتر و deterministicتری می‌ده. این یه درد واقعی تو مهندسی ایجنته.

ایده‌ی Data Flywheel درسته: اینکه تعاملات ایجنت بهترین منبع برای جمع‌آوری دیتا و بهبود مدل‌های آینده‌ست، یه استراتژی MLOps کلاسیک و درسته. لاگ‌هایی که از ایجنت جمع می‌شه، بهترین و تمیزترین دیتاست دنیاست برای fine-tune کردن یه SLM متخصص و این یه نکته‌ی کاملاً فنی و قابل دفاعه.

ولی خب، بریم سراغ جاهایی که مقاله زیادی خوش‌بین بوده:

الگوریتم مهاجرتشون یه شوخیه: الگوریتمی که تو بخش ۶ داده، روی کاغذ قشنگه ولی تو دنیای واقعی کابوسه. مرحله Data Curation که میگه داده‌های حساس (PII) رو با "ابزارهای اتوماتیک" پاک کنیم؟ تو محیط enterprise، این کار به شدت پرریسک و گرونه. یه اشتباه کوچیک تو این مرحله کل مدل fine-tune شده رو سمی می‌کنه و می‌تونه یه فاجعه امنیتی به بار بیاره.

پیدا کردن تسک با کلاسترینگ؟ جدی؟ اینکه بشینی با الگوریتم‌های unsupervised کلاسترینگ روی promptها، تسک‌های بیزینس رو پیدا کنی بیشتر شبیه یه پروژه‌ی دانشگاهیه تا کار واقعی. تو دنیای واقعی، تسک رو بیزینس و مدیر محصول تعریف می‌کنه، نه k-means. این بخش از مقاله خیلی از واقعیت دوره.

هزینه کل مالکیت (TCO) رو ندیدن: مقاله فقط روی هزینه‌ی inference زوم کرده، ولی هزینه‌ی کل مالکیت یه معماری با صدها SLM رو کلاً فراموش کرده. مدیریت، مانیتورینگ، آپدیت و ارزیابی این "باغ‌وحش مدل" (model zoo) یه جهنم عملیاتیه. واسه همین خیلی از شرکت‌ها ترجیح می‌دن پول API یه مدل خفن مثل GPT-4o رو بدن ولی سردرد نگهداری صدتا مدل ریز و درشت رو نداشته باشن.

ریسک Edge Caseها رو دست‌کم گرفتن: مهم‌ترین ریسک فنی که مقاله بهش وزن نداده، همین edge caseهاست. اون قدرت استدلال عمومی (general reasoning) توی یه LLM بزرگ، مثل یه safety net عمل می‌کنه. وقتی یه سناریوی پیش‌بینی‌نشده پیش میاد، LLM یه شانس برای هندل کردنش داره. ولی یه SLM که فقط روی تسک خودش ترین شده، وقتی با یه ورودی عجیب و خارج از توزیع (out-of-distribution) روبه‌رو بشه، یه شکست فاجعه‌بار می‌خوره که توی یه سیستم بیزینسی یعنی فاجعه.

به نظر من، جهت‌گیری کلی مقاله درسته؛ آینده‌ی سیستم‌های AI به سمت معماری‌های ترکیبی (heterogeneous) میره. اما این مسیر رو خیلی صاف و ساده و بدون چالش نشون داده. واقعیت اینه که پیاده‌سازی این چشم‌انداز تو مقیاس enterprise پر از چالش‌های مهندسی، MLOps و مدیریتیه که مقاله خیلی راحت از کنارشون گذشته.

🛠 Join @LLMEngineers Community