تصور کنید یک دستیار هوشمند را با هزاران یادداشت قدیمی بمباران کنید؛ لزوماً باهوش‌تر نمی‌شود و احتمالاً در انبوه اطلاعات گم می‌شود. طبق گزارش ۱۸ اوت ۲۰۲۶ از وب‌سایت huggingface.co، حافظه در عامل‌های هوش مصنوعی مانند یک «دوز» دارویی است که باید دقیقاً با توانمندی مدل تنظیم شود تا از افت عملکرد جلوگیری شود. این یافته نشان می‌دهد که دادن حافظه بیشتر به یک عامل هوش مصنوعی، همیشه به معنای هوشمندتر شدن آن نیست.
بسیاری از توسعه‌دهندگان تصور می‌کنند استخراج درس‌هایی از کارهای گذشته و تزریق آن‌ها به پنجرهٔ زمینه (Context Window) — که شبیه میز کاری است که جا برای چند ورق دارد، نه برای کل کتابخانه — مسیری خطی برای بهبود است. اما آزمایش روی هشت مدل مختلف، از مدل‌های متراکم ۳۰ میلیارد پارامتری تا سیستم‌های تجاری پیشرو، نشان داد که حجم زیاد اطلاعات می‌تواند توانایی استدلال سیستم‌های کوچک‌تر را مختل کند و در واقع آن‌ها را در داده‌ها غرق کند. این چالش‌ها تایید می‌کند که دستیابی به حافظه‌ای کاملاً بدون خطا برای عامل‌ها یک هدف دست‌نیافتنی است و هر سیستم با محدودیت‌های فنی خاص خود روبروست.
این یافته در حالی منتشر می‌شود که صنعت به سمت عامل‌های خودمختاری می‌رود که می‌توانند از مسیرهای طی‌شده خود یاد بگیرند، بدون اینکه به نظارت مداوم انسان یا به‌روزرسانی‌های گران‌قیمت وزن‌ها (Weights) نیاز داشته باشند. هدف، ایجاد حلقه‌ای است که در آن عامل تسکی را اجرا کند، یک دستورالعمل رفتاری از نتیجه استخراج کند و آن را در تلاش بعدی به کار ببندد.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی استنتاج در مدل‌های بازمتن اشاره کردیم، تعادل میان هزینه و دقت همواره کلیدی‌ترین چالش است. در اینجا نیز، مقدار حافظه تزریق‌شده مستقیماً بر این تعادل اثر می‌گذارد.
سه الگوی مدیریت حافظه
بر اساس گزارش huggingface.co، مدل‌ها بسته به نحوه برخورد با دستورالعمل‌های استخراج‌شده به سه دسته تقسیم می‌شوند. پژوهشگران دریافتند که عامل تعیین‌کننده این الگو، صرفاً تعداد پارامترها نیست، بلکه ترکیبی از فضای رشد در بنچمارک‌ها، معماری، اندازه پنجره متنی، کیفیت دستورالعمل‌ها و توزیع تسک‌ها است:
- مدل‌های قدرتمند با فضای رشد: این سیستم‌ها ظرفیت جذب تمام درس‌ها، حتی موارد نادر (Edge Cases) را دارند. آن‌ها از مجموعه کامل دستورالعمل‌ها سود می‌برند. برای مثال، مدل DeepSeek-V3.2 با معماری ترکیب خبره‌ها (MoE) و ۶۷۱ میلیارد پارامتر، با دریافت مجموعه کامل دستورالعمل‌های استخراج‌شده از خودش، ۹.۵ درصد افزایش در تکمیل تسک‌ها داشت.
- مدل‌های ضعیف یا گزینشی: این مدل‌ها با داده‌های حجیم دچار سردرگمی می‌شوند. آن‌ها با یک هسته فشرده از دستورالعمل‌های با اطمینان بالا و چند مورد بازیابی‌شده برای هر تسک، بهترین عملکرد را دارند. مدل gpt-oss-120b با معماری MoE و ۱۱۷ میلیارد پارامتر، با این رویکرد گزینشی ۱۶.۱ درصد پیشرفت کرد، در حالی که استفاده از مجموعه کامل حافظه، سود کمتری داشت و تقریباً ۵۰٪ توکن بیشتری مصرف کرد.
- مدل‌های اشباع‌شده: برخی مدل‌ها فارغ از مقدار حافظه، هیچ پیشرفتی نشان نمی‌دهند. مدل GLM-5 با ۷۴۵ میلیارد پارامتر (MoE) در این دسته قرار گرفت. این «الگوی اشباع» نشان می‌دهد که مدل احتمالاً پیش از این به سقف توانایی خود در آن تسک‌ها رسیده بود یا دستورالعمل‌ها نتوانستند نقاط ضعف باقی‌مانده را پوشش دهند.
محک AppWorld و معیارهای سنجش
پژوهشگران این الگوها را با استفاده از AppWorld، یک محک سخت‌گیرانه شامل ۵۸۵ تسک چندمرحله‌ای، اعتبارسنجی کردند. این محیط شامل ۱۶۸ تسک در دسته "test_normal" و ۴۱۷ تسک در دسته "test_challenge" بود که در ۹ اپلیکیشن شبیه‌سازی‌شده مانند تقویم، پیام‌رسان‌ها و سیستم‌های پرداخت اجرا شدند.
موفقیت با دو معیار متمایز سنجیده شد:
- تکمیل هدف تسک (TGC): سهم تسک‌هایی که به‌طور کامل و درست انجام شده‌اند. این معیار اصلی برای پاسخ به این سوال است که «آیا کار انجام شد یا خیر».
- تکمیل هدف سناریو (SGC): معیاری سخت‌گیرانه‌تر و صفر-و-یک. هر سناریو شامل چندین نسخه از یک تسک (با داده‌ها یا لحن متفاوت) است. SGC تنها در صورتی مثبت است که عامل در تمام نسخه‌های مختلف یک تسک موفق شود و این معیار، قابلیت اطمینان واقعی سیستم را می‌سنجد.
داده‌ها نشان می‌دهد حافظه به‌ویژه برای معیار سخت‌گیرانه SGC موثر است. برای مثال، SGC مدل DeepSeek-V3.2 حدود ۱۶.۱ درصد جهش کرد که به‌طور قابل‌توجهی بالاتر از افزایش ۹.۵ درصدی در TGC بود. حتی مدل‌های نزدیک به سقف مانند GPT-5.5 و Claude Opus 4.6 نیز پیشرفتی به ترتیب ۷.۲ و ۷.۱ درصد در SGC داشتند. این ثابت می‌کند که حافظه به عامل‌ها کمک می‌کند سخت‌ترین موارد خاص را حل کنند، حتی وقتی میانگین عملکردشان از قبل بالا بوده است.
جزئیات تفکیکی عملکرد
برای درک تأثیر دوز حافظه، پژوهشگران سه پیکربندی خاص را مقایسه کردند: خط پایه (بدون حافظه)، مجموعه کامل دستورالعمل‌ها (تزریق تمام موارد در هر گام ReAct) و بازیابی گزینشی (یک هسته ثابت با اطمینان بالا به‌علاوه دستورالعمل‌های مرتبط با تسک).
- gpt-oss-120b (ضعیف/گزینشی): مقدار TGC/SGC در حالت خط پایه ۳۹.۹/۲۱.۴ بود که با استفاده از بازیابی گزینشی به ۵۶.۰/۳۷.۵ رسید. این یک جهش عظیم ۱۶.۱ درصدی در هر دو معیار است.
- DeepSeek-V3.2 (قدرتمند با فضای رشد): مقدار TGC/SGC در حالت خط پایه ۷۹.۸/۶۴.۳ بود که با مجموعه کامل به ۸۹.۳/۸۰.۴ رسید. این منجر به افزایش ۹.۵ درصدی در TGC و ۱۶.۱ درصدی در SGC شد.
- Claude Opus 4.6 (قدرتمند با فضای رشد): مقدار TGC/SGC از ۹۰.۵/۸۷.۵ به ۹۴.۶/۹۴.۶ رسید که ۴.۱ درصد به TGC و ۷.۱ درصد به SGC افزود.
- GPT-5.5 (قدرتمند/نزدیک به سقف): مقدار TGC/SGC از ۹۲.۳/۸۲.۱ به ۹۵.۲/۸۹.۳ رسید که ۲.۹ درصد به TGC و ۷.۲ درصد به SGC افزود.
- GLM-5 (اشباع‌شده): مقدار TGC/SGC در حالت خط پایه ۸۷.۵/۸۰.۴ بود و حتی با مجموعه کامل دقیقاً همان ۸۷.۵/۸۰.۴ باقی ماند و هیچ پیشرفتی (۰.۰) نشان نداد.
تحلیل هزینه و توکن‌ها
تزریق مجموعه کامل دستورالعمل‌ها، تعداد توکن‌ها را در هر مرحله از حلقه ری‌اکت (ReAct) — شبیه به فرآیندی که مدل در آن هم فکر می‌کند و هم اقدام می‌کند — افزایش می‌دهد، زیرا دستورالعمل‌ها در هر نوبت دوباره ارسال می‌شوند. جالب است که حافظه تعداد گام‌های استدلال را زیاد نمی‌کند؛ برای مثال، DeepSeek با یا بدون حافظه، تقریباً تعداد گام‌های یکسانی (میانگین ۱۸ تا ۱۹ گام) را اجرا کرد. هزینه را تورم توکن‌های ورودی بالا می‌برد.
مقایسه سربار توکن‌ها نشان می‌دهد:
- DeepSeek-V3.2 (مجموعه کامل): از ۱۴۸ هزار توکن به ۲۶۳ هزار توکن در هر تسک رسید (۷۸٪ افزایش).
- gpt-oss-120b (مجموعه کامل): از ۱۱۰ هزار به ۱۶۶ هزار توکن در هر تسک رسید (۵۱٪ افزایش).
- gpt-oss-120b (بازیابی گزینشی): از ۱۱۰ هزار به ۱۱۶ هزار توکن در هر تسک رسید (تنها ۵٪ افزایش).
این یعنی برای برخی مدل‌ها، دقیق‌ترین پیکربندی، ارزان‌ترین گزینه نیز هست. در مورد gpt-oss-120b، رویکرد حافظه گزینشی توانست پیشرفت ۱۶.۱ درصدی را تنها با ۵٪ افزایش در مصرف توکن به دست آورد.
مهندسی برای محیط عملیاتی
برای کاهش هزینه‌ها در مدل‌های قدرتمند، گزارش بر کش کردن پرامپت (Prompt Caching) تأکید می‌کند. چون بخش استاتیک دستورالعمل‌ها در تمام گام‌ها یکسان است، ثابت نگه داشتن پیشوند (Prefix) اجازه می‌دهد توکن‌ها کش شوند و هزینه‌های موثر به‌شدت کاهش یابد. طراحی پرامپت با آگاهی از کش (Cache-aware) به عنوان یک گام مهندسی حیاتی توصیه شده است.
پژوهشگران همچنین فرض می‌کنند که اندازه پنجره متنی بر این الگوها اثر می‌گذارد. مدل‌هایی با پنجره‌های بزرگ‌تر ممکن است مجموعه‌های کامل را موثرتر جذب کنند، در حالی که مدل‌های با پنجره کوچک‌تر برای حفظ کیفیت استدلال به فشردگی حاصل از بازیابی نیاز دارند. آزمایش‌های کنترل‌شده برای جداسازی این عامل در حال انجام است.
سازوکار ALTK-Evolve
حلقه یادگیری در این تست‌ها که توسط کتابخانه ALTK-Evolve مدیریت می‌شود، با حافظه به عنوان مجموعه‌ای از دستورالعمل‌ها — استراتژی‌های موفق و اشتباهاتی که باید از آن‌ها اجتناب کرد — برخورد می‌کند، نه صرفاً بازپخش تاریخچه گفتگوها. این فرآیند شامل چهار مرحله است:
۱. تولید مسیر: عامل تسک‌ها را اجرا کرده و مسیرهای طی‌شده (Trajectories) را تولید می‌کند.
۲. استخراج: سیستم دستورالعمل‌های رفتاری را از هر دو اجرای موفق و شکست‌خورده استخراج می‌کند.
۳. تثبیت: این دستورالعمل‌ها در یک مجموعه قابل استفاده تجمیع و تثبیت می‌شوند.
۴. تزریق در استنتاج: در لحظه استنتاج (Inference) — همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند — یا مجموعه کامل یا زیرمجموعه‌ای گزینشی (یک هسته ثابت با اطمینان بالا به‌علاوه بخش متغیری از دستورالعمل‌های مرتبط با تسک) به مدل داده می‌شود.
نکته کلیدی این است که هیچ‌کدام از وزن‌های مدل به‌روزرسانی نمی‌شوند. یادگیری «در اطراف» مدل اتفاق می‌افتد، نه «درون» آن، که باعث می‌شود حافظه قابل انتقال و ارزان باشد و بتوان آن را روی معماری‌های مختلف مستقر کرد.
تحلیل: تغییر پارادایم حافظه
این تحقیق فرض بنیادی «داده بیشتر برابر با عملکرد بهتر» را برای حافظه عامل‌ها تغییر می‌دهد. این نتایج نشان می‌دهد که گلوگاه صرفاً مقدار حافظه در دسترس نیست، بلکه «ظرفیت جذب» مدل است.
برای توسعه‌دهندگان، این بدان معناست که دوران پرامپت‌های یکسان برای همه به پایان رسیده است. شما نمی‌توانید یک مجموعه حافظه با عملکرد بالا را از یک مدل پیشرو (Frontier) به یک مدل کوچک‌تر و محلی منتقل کنید و انتظار نتایج مشابه داشته باشید. در واقع، این کار ممکن است با وارد کردن نویز، فعالانه به عملکرد مدل کوچک‌تر آسیب بزند.
این موضوع یک نیاز مهندسی جدید ایجاد می‌کند: کالیبراسیون حافظه. تیم‌ها اکنون باید سطح مدل خود را بنچمارک کنند تا تعیین کنند برای ایجاد تعادل بین دقت و هزینه توکن، باید از استراتژی «تزریق کامل» استفاده کنند یا «بازیابی گزینشی».
گام‌های بعدی
پژوهشگران اکنون بر چندین حوزه کلیدی برای تکامل سیستم تمرکز کرده‌اند:
- انتخاب‌گرهای یادگیرنده: بازیابی فعلی بر اساس شباهت کسینوسی (Cosine Similarity) است که لزوماً دستورالعمل‌های مفید را پیش‌بینی نمی‌کند. گام بعدی، ساخت انتخاب‌گری است که بر اساس سیگنال‌های نتیجه آموزش دیده باشد. برای بهینه‌سازی این فرآیند، استفاده از پایگاه‌داده‌های برداری برای بازیابی سریع تاریخچه راهکاری کلیدی برای کاهش تأخیر در سیستم‌های عملیاتی است.
- پشتیبانی از مدل‌های بسیار ضعیف: در زیر یک سطح خاص از توانمندی، استخراج خودکار (Self-distillation) سیگنال کافی ندارد. تیم در حال بررسی حافظه استخراج‌شده توسط مدل‌های معلم (Teacher-distilled) برای این مدل‌ها است.
- گسترش بنچمارک‌ها: در حالی که سیستم روی AppWorld تایید شده، تیم به سمت بنچمارک‌های گسترده‌تر و استقرار در دنیای واقعی حرکت می‌کند.
- جداسازی پنجره متنی: انجام آزمایش‌های کنترل‌شده برای تفکیک تأثیر اندازه پنجره متنی از توانایی خام مدل.
شما می‌توانید کتابخانه ALTK-Evolve را برای پیاده‌سازی این خط لوله استخراج و تثبیت در جریان‌های کاری عامل‌های خود بررسی کنید یا گزارش فنی کامل را برای مشاهده تمام تحلیل‌های تفکیکی (Ablations) بخوانید.
گام بعدی شما
- اگر از مدل‌های کوچک‌تر (زیر ۱۰۰ میلیارد پارامتر) استفاده می‌کنید، به‌جای تزریق تمام تاریخچه، روی پیاده‌سازی تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب را باز می‌کند و از آن نقل می‌آورد — برای حافظه عامل تمرکز کنید.
- برای مدل‌های Frontier، حتماً از استراتژی Prompt Caching استفاده کنید تا هزینه توکن‌های تکراری در حلقه‌های ReAct را حذف کنید.
- کتابخانه ALTK-Evolve را برای استخراج خودکار دستورالعمل‌ها از لاگ‌های اجرای عامل‌هایتان بررسی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو