آنتروپیک راهکاری آزموده‌شده برای حل مشکل سهمیه مصرف کیمی معرفی کرد
پس از انتشار مدل K3.1 Pro، کاربران متعددی گزارش دادند که سهمیه مصرف آن با سرعتی غیرعادی تمام می‌شود. در واکنش به این گزارش‌ها، شرکت مون‌شات ای‌آی (Moonshot AI) با انتشار اطلاعیه‌ای فوری اعلام کرد: «مشکل از ماست و باید خیلی زودتر آن را برطرف می‌کردیم.» این شرکت ضمن جبران بخشی از مصرف کاربران با اختصاص سهمیه اضافی، وعده داد «فراخوانی‌های غیرضروری زیرعامل‌ها و طول خروجی‌ها را کاهش دهد».
تنها دو روز پیش از عرضه این مدل، شرکت آنتروپیک مقاله‌ای با عنوان ساخت عامل‌ها: چه زمانی باید زیرعامل‌ها را در حلقه اصلی عامل ادغام کرد؟ منتشر کرده بود که دقیقاً به موضوع زیرعامل‌ها می‌پردازد.
آنتروپیک در این مقاله توضیح می‌دهد که با مقایسه نمونه‌های استقرار کلود در چندین شرکت، به این نتیجه رسیده است که عاملی مجهز به مهارت‌های تخصصی، در مقایسه با تقسیم وظایف میان گروهی از زیرعامل‌ها، عملکرد بهتری دارد و معمولاً هر کار را با هزینه و تأخیر کمتری انجام می‌دهد. مهم‌تر از همه، مصرف توکن در این روش به‌مراتب پایین‌تر از سامانه‌ای متشکل از چند زیرعامل است.
مفهوم زیرعامل را می‌توان در اصل نوعی «راه‌حل موقت» دانست که شرکت‌های سازنده در دوره محدود بودن توانایی مدل‌ها به کار گرفتند تا بتوانند وظایف بیشتری را به کمک آن‌ها انجام دهند.
در آن زمان، از نظر نرخ تکمیل وظایف، عملکرد چند زیرعامل به‌مراتب بهتر از یک عامل واحد بود. اما این مزیت هزینه‌ای داشت: مصرف توکن به‌شدت افزایش پیدا می‌کرد و اجرای مدل بسیار گران‌تر می‌شد.
به گفته آنتروپیک، با قدرتمندتر شدن مدل‌ها و افزایش طول پنجره زمینه آن‌ها، این راه‌حل موقت دیگر توانایی مدل را بهبود نمی‌دهد و در عوض به باری اضافی تبدیل شده است.
مقاله آنتروپیک چه می‌گوید؟
آنتروپیک معتقد است برای بیشتر وظایف، اصلاً به این تعداد زیرعامل نیازی نیست؛ یک عامل، یک مدل، یک سابقه مکالمه و یک حلقه اجرایی کافی است.
در این روش، مدل در یک حلقه واحد بارها اجرا می‌شود و در هر دور می‌تواند چند فراخوانی ابزار را به‌صورت دسته‌ای انجام دهد. نتایج مستقیماً به همان مدل بازمی‌گردند و مدل بر اساس آن‌ها تصمیم می‌گیرد که در مرحله بعد چه کاری انجام دهد.
برای درک بهتر تفاوت این دو رویکرد، آشپزی در یک رستوران را تصور کنید. برای آماده کردن یک غذا باید مراحل مختلفی را پشت سر گذاشت: آماده‌سازی مواد اولیه، شستن سبزیجات، خرد کردن آن‌ها، پخت غذا و در نهایت تزئین و سرو آن.
در الگوی سنتی تقسیم کار، افراد مختلفی را برای شستن سبزیجات، خرد کردن آن‌ها، پخت غذا و چیدن آن در ظرف تعیین می‌کنید و هر فرد فهرست وظایف خودش را دارد. مشکل اینجاست که وظایف هر نفر از مرحله قبلی به او منتقل می‌شود؛ برای مثال، فردی که سبزیجات را خرد می‌کند، دستور کارش را از کسی می‌گیرد که آن‌ها را شسته است.
اگر غذا هنگام سرو بیش از حد شور باشد، تشخیص اینکه مشکل دقیقاً در کدام مرحله رخ داده دشوار خواهد بود. ممکن است آشپز نمک زیادی ریخته باشد یا سبزیجات به‌درستی شسته نشده باشند.
مزیت عامل واحد این است که در آغاز هر مرحله لازم نیست برای فرد دیگری توضیح دهد «چه طعمی مدنظرم است». این عامل تمام فرایند آماده‌سازی غذا را خودش مدیریت می‌کند، طعم آن را می‌چشد و میزان نمک را بر اساس نتیجه تنظیم می‌کند.
این مقاله سه نقطه‌ضعف اصلی برای زیرعامل‌ها برمی‌شمارد.
نخستین مشکل، انباشته شدن مصرف توکن است.
هر زیرعامل اضافی در یک وظیفه، لایه دیگری از شاخه‌های پردازش ایجاد می‌کند و هزینه کل را افزایش می‌دهد. مصرف توکن در یک سامانه چندعاملی تقریباً ۱۵ برابر یک مکالمه معمولی است.
نکته مهم این است که این افزایش ۱۵ برابری صرف «فکر کردن» نمی‌شود، بلکه بخش عمده آن صرف «به خاطر سپردن» اطلاعات است.
هر زیرعامل باید هویت، قواعد، فهرست ابزارها و زمینه مرتبط با وظیفه خود را دوباره مشخص کند. سپس باید تمام خروجی‌هایش را در قالب خلاصه‌ای فشرده کند و به عامل اصلی تحویل دهد. در نتیجه، عامل اصلی ناچار می‌شود بارها و بارها همان مجموعه اطلاعات را بخواند.
دومین مشکل، کاهش تدریجی دقت اطلاعات هنگام انتقال است.
هر بار که اطلاعات میان زیرعامل‌های مختلف جابه‌جا می‌شود، بخشی از دقت و جزئیات آن از بین می‌رود. در مراحل بعدی، ممکن است اطلاعاتی که زیرعامل‌ها دریافت می‌کنند دیگر با خواسته‌های اولیه مطابقت نداشته باشد.
شرکت Cognition در مقاله سال ۲۰۲۵ خود با عنوان عامل‌های چندگانه نسازید، نمونه‌ای از این مشکل را شرح داده است. در این سناریو، دو زیرعامل مأمور شدند بازی Flappy Bird را به‌طور جداگانه بازسازی کنند؛ یکی مسئول ساخت پس‌زمینه بود و دیگری باید شخصیت پرنده را طراحی می‌کرد. نتیجه این شد که پس‌زمینه ساخته‌شده به بازی سوپر ماریو شباهت داشت و پرنده طراحی‌شده نیز اصلاً شبیه یک عنصر گرافیکی مناسب برای بازی نبود.
سومین مشکل، چندپارگی شخصیت و لحن خروجی است.
اگرچه زیرعامل‌های مختلف درون سامانه با یکدیگر ارتباط برقرار می‌کنند، به دلیل تفاوت در دستورالعمل‌هایشان، سبک نگارش و خروجی آن‌ها می‌تواند به‌شدت متفاوت باشد؛ این در حالی است که کاربر فقط از یک نقطه ورودی با سامانه تعامل می‌کند.
آنتروپیک در مقاله خود مثالی از شرکتی می‌آورد که بیش از دوازده زیرعامل تخصصی در محصولش داشت. این شرکت گزارش کرده بود که وجود این زیرعامل‌ها، «حفظ یکپارچگی پیام برند را به‌شدت دشوار کرده است». افزون بر این، کاربران همیشه باید منتظر می‌ماندند تا کندترین زیرعامل کارش را تمام کند و پاسخ نهایی آماده شود.
البته آنتروپیک نمی‌گوید که باید زیرعامل‌ها را به‌طور کامل کنار گذاشت. پیشنهاد این شرکت آن است که قابلیت‌های آن‌ها در قالب مهارت‌هایی با عنوان Skills و فقط هنگام نیاز بارگذاری شوند.
هر زیرعامل مجموعه‌ای از دانش‌ها و مهارت‌های تخصصی با خود دارد؛ درست مانند مهارت چاقو به دست گرفتن برای خرد کردن سبزیجات یا کنترل حرارت هنگام پخت غذا. هر زمان که یکی از این مهارت‌ها لازم باشد، آن را فعال می‌کنیم و پس از پایان مرحله مربوط، کنار می‌گذاریم.
تأثیر این رویکرد را می‌توان اندازه‌گیری کرد.
آنتروپیک در مقاله خود می‌گوید که با استفاده از ابزارهای پشتیبان، تبدیل زیرعامل‌ها به مهارت می‌تواند بیش از ۸۰ درصد از دستورالعمل‌های سیستمی را حذف کند.
این کار دستورالعمل‌های حجیم و پراکنده‌ای را که پیش‌تر در تصمیم‌گیری مدل اختلال ایجاد می‌کردند، به‌سرعت کاهش می‌دهد و فضای زیادی از پنجره زمینه را برای انجام خود وظیفه آزاد می‌کند.
آیا هنوز به زیرعامل‌ها نیاز داریم؟
زیرعامل‌ها در اصل نوعی مصالحه مهندسی بودند که برای رفع محدودیت‌های مدل‌ها در زمان پیدایش این مفهوم به وجود آمدند.
آندری کارپاتی که آن زمان هنوز در OpenAI کار می‌کرد، در پستی در شبکه‌های اجتماعی تقریباً چنین توضیح داده بود که GPT از محدودیت پنجره زمینه خود آگاه نیست. هنگام اجرای وظایف، به‌راحتی تمام ظرفیت این پنجره را پر می‌کند و در نتیجه، کار با شکست مواجه می‌شود.
بنابراین لازم بود روشی طراحی شود که وظایف به بخش‌های کوچک‌تر تقسیم شوند تا مدل بتواند آن‌ها را مرحله‌به‌مرحله انجام دهد.
در اواخر مارس ۲۰۲۳، دو پروژه آزمایشی AutoGPT و BabyAGI معرفی شدند. سازوکار اصلی هر دو پروژه بر این اساس بود که یک عامل، هدف‌های بزرگ را به چند فهرست از کارهای کوچک‌تر تقسیم کند، وظایف را به خودش بسپارد و آن‌ها را به‌صورت مستقل اجرا کند.
این پروژه‌ها نشان دادند که اگر مدل بتواند خودش مرحله بعدی را انتخاب کند، حلقه اجرایی می‌تواند کار کند. اما در عین حال، یک ضعف اساسی را نیز آشکار کردند: اگر در این حلقه مرحله‌ای قابل‌اعتماد برای بررسی و تأیید نتایج وجود نداشته باشد، خطاها به‌تدریج تشدید می‌شوند.
برای مثال، ممکن است یک عامل بگوید «می‌خواهم گزارش مالی این شرکت را پیدا کنم». اگر گزارش اشتباهی را بازیابی کند، همچنان بر اساس همان اطلاعات نادرست استدلال خواهد کرد و در نهایت نتیجه‌ای ظاهراً مفصل، اما کاملاً بی‌معنا ارائه می‌دهد. سپس ممکن است بارها همان مسیر اشتباه را تکرار کند و هر بار بر تعداد خطاهایش بیفزاید.
از نیمه دوم سال ۲۰۲۳ تا سال ۲۰۲۴، راه‌حل رایج در صنعت این بود که تقسیم کاری مشابه ساختار یک شرکت واقعی طراحی شود.
برای نمونه، MetaGPT مدل را به چهار نقش تقسیم می‌کند: مدیر محصول، معمار سیستم، مهندس و آزمایشگر.
اگر از این سامانه بخواهید «یک بازی مار با جدول رتبه‌بندی بساز»، کار به‌ترتیب و بر اساس نقش‌ها پیش می‌رود. ابتدا مدیر محصول سند نیازمندی‌ها را می‌نویسد؛ سپس معمار سیستم آن را به طرح‌های سامانه و رابط‌ها تبدیل می‌کند؛ پس از آن مهندس مطابق رابط‌های تعریف‌شده کد می‌نویسد و در نهایت آزمایشگر باگ‌ها را پیدا می‌کند. برنامه نهایی از طریق همین فرایند تولید می‌شود.
ایده اصلی این روش در آن زمان ساده بود: اگر یک مدل به‌تنهایی مستعد منحرف شدن از مسیر درست باشد، نظارت چند مدل بر کار یکدیگر می‌تواند از این مشکل جلوگیری کند. این رویکرد را می‌توان نمونه اولیه سامانه‌های مبتنی بر زیرعامل دانست.
در واقع، زیرعامل‌ها تلاشی برای «شبیه‌سازی ماشینی گسترده‌تر و باثبات‌تر با حافظه بیشتر از طریق معماری سامانه» هستند.
آنتروپیک در مقاله خود به محدودیت پنجره زمینه اشاره می‌کند، اما می‌گوید قابلیت اطمینان مدل‌ها نیز محدود است: هرچه زنجیره استدلال طولانی‌تر شود، احتمال از کار افتادن آن بیشتر می‌شود. افزون بر این، مدل‌ها فقط می‌توانند در یک رشته پردازشی کار کنند و امکان تفکر موازی ندارند.
به گفته آنتروپیک، این شرکت در سال ۲۰۲۴ زیرعامل‌ها را با هدف حل سه مشکل طراحی کرد: نخست، جداسازی زمینه تا خروجی‌های میانی حجیم، زمینه اصلی را اشغال نکنند و عملاً ظرفیت قابل‌استفاده پنجره زمینه افزایش یابد؛ دوم، اختصاص ابزارهای متفاوت به وظایف مختلف تا بروز خطا در یک بخش، کل فرایند را مختل نکند؛ و سوم، پردازش موازی که امکان پیشبرد هم‌زمان چند رشته مستقل را فراهم می‌کند.
آنتروپیک زیرعامل‌ها را نوعی راه‌حل موقت برای جبران محدودیت‌های مدل‌ها می‌داند. با این حال، تمام این راه‌حل‌ها هزینه توکنی دارند.
در دو سال گذشته، بیشتر این هزینه‌ها را توسعه‌دهندگان و شرکت‌هایی پرداخته‌اند که از رابط‌های برنامه‌نویسی کاربردی (API) استفاده می‌کنند. قیمت‌گذاری در این مدل شفاف و قابل محاسبه است: اگر ۱۰ سنت بیشتر برای توکن‌ها هزینه کنید، صورت‌حساب شما دقیقاً ۱۰ سنت افزایش پیدا می‌کند.
آنتروپیک می‌گوید با فراگیر شدن اشتراک‌های مصرف‌کنندگان، زمان تغییر این رویکرد فرا رسیده است.
سهمیه ماهانه مانند جعبه‌ای سیاه است. کاربران فقط می‌دانند در این ماه چه مقدار سهمیه برایشان باقی مانده، اما نمی‌دانند زیرعامل‌ها در یک مکالمه مشخص چه مقدار از آن را مصرف کرده‌اند.
کاربران اشتراکی میزان مصرف خود را بر اساس تعداد وظایفی که انجام داده‌اند ارزیابی می‌کنند؛ در مقابل، سامانه مصرف را بر اساس تعداد فراخوانی‌های مدل، شاخه‌های پردازشی ایجادشده و دفعات خواندن فایل‌ها محاسبه می‌کند.
از این رو، آنتروپیک استدلال می‌کند که با افزایش تدریجی توانایی مدل‌ها و قدرت محاسباتی، این راه‌حل‌های موقت فقط در وظایف بسیار پیچیده ارزش افزوده دارند. در بیشتر وظایف، زیرعامل‌ها بسیار بیشتر از میزان ضروری توکن مصرف می‌کنند.
نتیجه‌گیری آنتروپیک این است که مزایای زیرعامل‌ها دیگر از هزینه‌های ذاتی آن‌ها بیشتر نیست.
این شرکت حتی ابزاری متن‌باز به نام single-agent-loop-kit منتشر کرده است که مشخصاً برای اجرای وظایف در حالت تک‌عاملی طراحی شده و به مدل اجازه نمی‌دهد هیچ زیرعاملی را فراخوانی کند.
صورت‌حساب K3.1 Pro
مون‌شات ای‌آی تازه‌ترین شرکتی است که به دلیل استفاده بیش از حد از زیرعامل‌ها با مشکل مواجه شده است.
مون‌شات ای‌آی در ۲۴ اکتبر مدل K3.1 Pro را عرضه کرد؛ مدلی که عملکرد قدرتمندی از خود نشان می‌دهد. این مدل در آزمون Terminal-Bench 4.0 امتیاز ۶۵٫۷ درصد را کسب کرد؛ بالاتر از امتیاز ۵۸٫۲ درصدی GPT-6 Astra و تنها ۰٫۷ واحد درصد پایین‌تر از امتیاز ۶۶٫۴ درصدی Claude Opus 5.5 قرار گرفت.
با این حال، کاربران متعددی در انجمن‌های آنلاین گزارش دادند که سهمیه مصرف مدل بیش از حد سریع تمام می‌شود و انجام تنها یک یا دو وظیفه کوچک می‌تواند سهمیه پنج‌ساعته آن‌ها را مصرف کند.
مون‌شات ای‌آی بامداد ۲۶ اکتبر رسماً اعلام کرد که فراخوانی‌های غیرضروری زیرعامل‌ها و طول خروجی‌ها را کاهش خواهد داد.
برای کسانی که در شرکت‌های اینترنتی کار کرده‌اند، این وضعیت آشناست.
وقتی نیازمندی جدیدی مطرح می‌شود، یک مدیر محصول، یک طراح، یک توسعه‌دهنده فرانت‌اند، یک توسعه‌دهنده بک‌اند، یک آزمایشگر و یک متخصص عملیات را به پروژه اختصاص می‌دهید. همه باید در سند پروژه نظر ثبت کنند؛ وگرنه ممکن است به نظر برسد که در کار مشارکت ندارند. در نهایت، کاری که یک نفر می‌توانست در نیم‌روز انجام دهد، از مرحله تعریف نیازمندی‌ها تا برنامه‌ریزی، آزمایش و عرضه، بیش از شش ماه طول می‌کشد.
در یک شرکت، این وضعیت را قابلیت سازمانی می‌نامند. اما وقتی همین الگو در مدل‌ها به کار گرفته می‌شود، چیزی جز مصرف توکن نیست.
کاربران مدل فقط می‌توانند شدت استدلال آن را انتخاب کنند و کنترلی بر تعداد زیرعامل‌هایی که فعال می‌شوند ندارند. آن‌ها می‌خواهند هزینه انجام وظیفه را بپردازند، نه هزینه تعداد زیادی زیرعامل که مشغول «هماهنگی، جلسه گذاشتن و تهیه پاورپوینت» هستند.
علاوه بر این، کاربران حتی فرصتی برای متوقف کردن این فرایند ندارند. این مسئله به مفهومی به نام «هزینه شکست از پیش» مربوط می‌شود.
در یک معامله معمولی، پس از تکمیل کار پول پرداخت می‌کنید. اما در سامانه‌های مبتنی بر زیرعامل، به‌محض فعال شدن هر زیرعامل، سهمیه مصرف می‌شود؛ حتی اگر نقش آن زیرعامل در نتیجه نهایی تقریباً ناچیز باشد.
البته منصفانه نیست که این مشکل را مختص K3.1 Pro بدانیم.
کاربران کلود نیز شکایت کرده‌اند که در طرح اشتراکی ۲۰ دلاری، گاهی تنها یک دستور می‌تواند سهمیه پنج‌ساعته آن‌ها را تمام کند. همچنین، هنگام استفاده از Opus 5.5 برای کار روی یک پایگاه کد موجود، محدودیت مصرف ممکن است پس از حدود ۳۰ دقیقه فعال شود. هر دو مشکل به فعال کردن تعداد بیش از حد زیرعامل‌ها از سوی آنتروپیک نسبت داده شده‌اند.
آنتروپیک معتقد است این مسئله تناقضی ساختاری در محصولات مبتنی بر عامل‌های بلندمدت است.
وقتی وظیفه‌ای به چنین عاملی می‌سپارید، باید اطلاعات را جست‌وجو کند، فایل‌ها را بخواند، بنویسد، اصلاح کند و در نهایت نتیجه را خودش بررسی کند. این فرایند ممکن است ده‌ها مرحله داشته باشد و مدل در هر مرحله ناچار شود تمام زمینه را دوباره بخواند؛ به همین دلیل، طول کشیدن فرایند تا نیم ساعت اتفاقی غیرمعمول نیست.
هرچه مدل قدرتمندتر باشد، جست‌وجوی بیشتری انجام می‌دهد، ابزارهای بیشتری را فراخوانی می‌کند و دورهای بیشتری را به بررسی و تأیید کار خودش اختصاص می‌دهد.
راهکار پیشنهادی آنتروپیک این است که در سطح محصول مشخص شود کدام فراخوانی‌های زیرعامل غیرضروری‌اند و این فراخوانی‌ها کاهش یابند. در نتیجه، تا حد امکان باید از یک عامل واحد برای حل مسئله استفاده کرد، نه اینکه زیرعامل‌های متعدد را فعال کنیم.
همچنین، باید به کاربران اجازه داده شود حداکثر تعداد مراحل اجرا را تعیین کنند و پیش از شروع هر وظیفه، برآوردی از بازه هزینه احتمالی آن در اختیارشان قرار گیرد.
آنتروپیک که به عرضه عمومی سهام خود نزدیک می‌شود، با کاهش استفاده از زیرعامل‌ها و پایین آوردن مصرف توکن، در پی جلب رضایت کاربران عادی نیز هست.
این مقاله نوشته میائو ژنگ است و نخستین بار در حساب عمومی وی‌چت «Letter AI» (Letter AI) منتشر شده است. بازنشر آن در 36Kr با اجازه ناشر اصلی انجام شده است.