اگر برای مدیریت پروژه‌های نرم‌افزاری از عامل‌های هوش مصنوعی استفاده می‌کنید، احتمالاً با لحظه‌ای مواجه شده‌اید که مدل ناگهان دستورالعمل‌های ابتدایی جلسه را فراموش کرده است. این «فراموشی» دیگر یک محدودیت تئوریک نیست، بلکه یک چالش مهندسی است که اکنون راهکاری برای آن پیدا شده است.
Baize — یک محیط اجرای دستیار هوش مصنوعی برای تیم‌ها که با زبان Go 1.25+ توسعه یافته و تحت لایسنس MIT است — در نسخه ۰.۳.x خود به سراغ حل مشکل «رقیق‌شدن توجه» (Attention Dilution) رفته است. این اتفاق زمانی رخ می‌دهد که تنظیمات حیاتی یک پروژه، زیر هزاران خط تاریخچهٔ چت دفن می‌شوند.
بن‌بست مدیریت زمینه
اکثر عامل‌ها با زمینه (Context) — شبیه به میز کاری که مدل در هر لحظه فقط چند ورق کاغذ روی آن جا دارد — مانند یک دفترچه یادداشت عمل می‌کنند که فقط می‌توان به انتهای آن نوشت. هر پیام جدید، نتیجهٔ اجرای یک ابزار و یا ردپای استدلال مدل (Reasoning Trace)، صرفاً به ته لیست اضافه می‌شود. وقتی گفتگوها رشد می‌کنند، توسعه‌دهندگان معمولاً برای گنجاندن متن در پنجرهٔ زمینه (Context Window)، به روش‌های «برش دادن» (Truncation) یا خلاصه‌سازی‌های تقریبی تکیه می‌کنند.
به نقل از مستندات فنی Baize، این روش‌ها بازگشت‌ناپذیر هستند؛ یعنی وقتی جزئیاتی خلاصه یا حذف می‌شوند، مدل دیگر نمی‌تواند ظرافت‌های نسخه اصلی را بازیابی کند. این موضوع برای تیم‌های حرفه‌ای که به یک آرشیو تغییرناپذیر برای بازرسی (Auditing) و اعتماد نیاز دارند، یک شکاف اعتباری ایجاد می‌کند. در چارچوب‌های سنتی، این سیستم‌ها هستند که اکشن‌ها را تعریف می‌کنند و مدل فقط می‌تواند یکی را انتخاب کند؛ این یعنی مدل در مدیریت حافظه خودش، تنها یک شرکت‌کننده غیرفعال است. این چالش‌ها در ابزارهای دیگر نیز دیده شده است، به‌طوری که نقص‌های فنی در مدیریت تاریخچهٔ عامل‌های OpenAI نشان داد که پاک‌سازی ناقص حافظه می‌تواند منجر به رفتارهای پیش‌بینی‌ناپذیر شود.
چرا گفتگوهای طولانی شکست می‌خورند؟
طبق گزارش‌های فنی، وقتی تاریخچهٔ یک عامل به هزاران خط می‌رسد، سه حالت شکست یا Failure Mode رخ می‌دهد:
- رقیق‌شدن توجه: موارد حیاتی و تنظیمات کلیدی در میان نویزها گم می‌شوند و مدل دیگر نمی‌تواند آن‌ها را به‌طور قابل‌اطمینانی استخراج یا به آن‌ها ارجاع دهد.
- برش بازگشت‌ناپذیر: حذف پیام‌های قدیمی باعث می‌شود توافقات اولیه و زمینه‌هایی که در ابتدای گفتگو شکل گرفته بود، به‌طور خاموش از بین بروند، بدون اینکه کاربر متوجه شود تا زمانی که خیلی دیر شده است.
- فشرده‌سازی با اتلاف: خلاصه‌های متوالی (Rolling Summaries) فضا را ذخیره می‌کنند، اما این‌ها تبدیل‌های یک‌طرفه‌ای هستند که در آن جزئیات کلیدی به‌سادگی ناپدید می‌شوند.
پیشرفت مدل‌های CLM
برای حل این بحران، Baize از یافته‌های یک مقاله در سپتامبر ۲۰۲۶ دربارهٔ «مدل‌های زبانی زمینه» (Context Language Models یا CLM) استفاده کرده است که توسط دانشگاه واشینگتن، آزمایشگاه‌های Meta Superintelligence و MIT (با شناسه arXiv:2609.37725) منتشر شد. این پژوهش پیشنهاد می‌کند که با زمینه مانند فایلی برخورد شود که مدل اجازه نوشتن (Write Permission) روی آن را دارد؛ یعنی مدل بتواند محتوا را اضافه، ویرایش، حذف یا بازنویسی کند و هر تغییر در نوبت بعدی گفتگو با زمینه همگام (Sync) شود.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدیریت حافظه در مدل‌های استدلالی اشاره کردیم، این رویکرد به مدل اجازه می‌دهد خودش یاد بگیرد چه چیزی ارزش نگه داشتن دارد. در عمل، این منجر به رفتارهای نوظهوری می‌شود که در چارچوب‌های قبلی وجود نداشت؛ مثلاً مدل می‌تواند جداول ردیابی (Tracker Tables) برای همکاری‌های چندعاملی بسازد یا توابع مدیریت زمینهٔ قابل استفاده مجدد تعریف کند. چون مدیریت زمینه تبدیل به یک «رفتار مدل» می‌شود (نه یک سیاست خارجی تحمیل شده توسط سیستم)، استراتژی آن می‌تواند از طریق یادگیری تقویتی (Reinforcement Learning) بهبود یابد. این رویکرد در تضاد با فلسفه پروژه Lossless-Memory است که تلخیص هوش مصنوعی را به دلیل عدم امکان بازیابی دقیق خاطرات رد کرد.
بر اساس داده‌های این پژوهش، دستاوردهای عملکردی قابل‌توجهی حاصل شده است:
- صحت: در محک BrowseComp-Plus برای پژوهش‌های عمیق، مدل‌های CLM حدود ۱۱.۴٪ بهتر از قوی‌ترین مدل‌های پایه (Baseline) عمل کردند.
- بهره‌وری: این پیشرفت در حالی رخ داد که ۲۱.۵٪ عملیات اعشاری در ثانیه (FLOPs) کمتری در مرحله استنتاج (Inference) — همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند و شبیه به خودِ آشپزی است، نه دوره آموزش آشپز — مصرف شد.
- سرعت: در یک تسک ۲۴ ساعته با مجموعه‌ای از عامل‌ها (Agent-Swarm) روی چندین مخزن کد (Multi-repo)، سرعت نهایی ۶۵٪ افزایش یافت، در حالی که سطح محاسبات مصرفی یکسان باقی مانده بود.
پیاده‌سازی مهارشده در Baize
در حالی که CLM ویرایش بومی و رادیکال را پیشنهاد می‌دهد، Baize نسخه‌ای عمل‌گرایانه و محدودشده به نام «لایهٔ تصویرسازی» (Projection Layer) را پیاده کرده است. از آنجایی که Baize با APIهای سازگار با OpenAI ارتباط برقرار می‌کند، نمی‌تواند مستقیماً به لاجیت‌ها (Logits) دسترسی داشته باشد یا ویرایش بومی در سمت مدل انجام دهد. بنابراین، Baize به جای اینکه اجازه دهد مدل در محیطی کنترل‌نشده تاریخچه را بازنویسی کند، ویرایش را به یک لایه سیستمی منتقل کرده است تا مقداری از آزادی را فدای پایداری و قابلیت اطمینان کند.
این لایه سه وظیفه مشخص دارد:
- سنجاق کردن (Pinning): حقایق ضروری را به‌طور دائمی برای مدل قابل مشاهده نگه می‌دارد تا در اثر طولانی شدن چت گم نشوند.
- خلاصه‌های غلتان: اطلاعات ثانویه را برای ذخیره فضا فشرده می‌کند. در این راستا، گزارش‌های فنی نشان داده‌اند که لایه‌های خلاصه‌ساز می‌توانند هزینه‌های API را تا ۸۰٪ کاهش دهند، هرچند Baize بر حفظ دقت متمرکز است.
- فیلتر کردن: نتایج حجیم ابزارها که باعث شلوغی زمینه می‌شوند و ارزش اطلاعاتی کمی دارند را حذف می‌کند.
حفاظ‌های محیط تولید
برای اینکه سیستم در محیط‌های عملیاتی قابل اعتماد باشد، Baize سه محدودیت حیاتی اضافه کرده است:
- آرشیو تغییرناپذیر: لایه تصویرسازی فقط در سمت ورودی مدل (Model Input Side) اثر می‌گذارد. چت‌های ذخیره شده هرگز بازنویسی نمی‌شوند. چت‌هایی که کاربر می‌بیند دست‌نخورده باقی می‌مانند تا تیم‌ها بتوانند هر زمان تاریخچه را بازبینی، فورک (Fork) یا به حالت قبل برگردانند. این آرشیو، مبنای بازرسی و اعتماد است.
- منطق باز-در-صورت-خطا (Fail-Open): اگر لایه تصویرسازی با خطا مواجه شود، دستیار به‌طور خودکار به منطق فشرده‌سازی قدیمی برمی‌گردد. مدیریت زمینه هرگز نباید به یک گلوگاه برای در دسترس بودن سیستم تبدیل شود. این با فلسفه کلی Baize مطابقت دارد: بهینه‌سازی نباید بر کارکرد ابزارها اثر بگذارد.
- شفافیت توکن: مستندات صراحتاً ذکر می‌کنند که هیچ وعده‌ای برای کاهش مصرف توکن‌های ابری داده نمی‌شود. خودِ فرآیند تصویرسازی توکن مصرف می‌کند؛ هدف اینجا حفظ حقایق کلیدی و کاربردپذیری است، نه کاهش صورت‌حساب مالی.
این تغییر، فرض بنیادی حافظه عامل را از یک «مجموعه قوانین سخت‌افزاری» به یک «خروجی قابل مدیریت» تبدیل می‌کند. با انتقال منطق ویرایش به لایه تصویرسازی سیستمی، Baize از ریسک‌های بازنویسی کنترل‌نشده تاریخچه اجتناب می‌کند. در واقع CLM مسیر رادیکال ویرایش بومی مدل است و لایه تصویرسازی Baize، مسیر عمل‌گرایانه ویرایش در سطح چارچوب (Framework).
برای توسعه‌دهندگان، این قابلیت اختیاری است (به‌صورت پیش‌فرض خاموش است) و می‌توان آن را بدون توقف سیستم (Hot-reload) فعال کرد. این رویکرد از یک فلسفه طراحی ثابت پیروی می‌کند: اولویت دادن به اختیاری بودن نسبت به پیش‌فرض‌ها، و اولویت دادن به منطق Fail-open. اگر در حال ساخت عامل‌هایی برای کارهای پژوهشی طولانی‌مدت یا تسک‌های چند-مخزنی هستید، اکنون می‌توانید این سبک‌های تصویرسازی را در مخزن عمومی Baize در گیت‌هاب (https://github.com/rebornace/baize) تست کنید. مستندات مربوطه در مسیر docs/developers به هر دو زبان انگلیسی و چینی در دسترس است.
گام بعدی شما
- اگر در حال ساخت عامل‌هایی برای کارهای پژوهشی طولانی‌مدت هستید، مخزن عمومی Baize در گیت‌هاب را بررسی کنید.
- لایه تصویرسازی را روی یک پروژه با تاریخچه بالای ۱۰۰ پیام تست کنید تا تفاوت در بازیابی حقایق اولیه را بسنجید.
- مستندات بخش
docs/developersرا برای تنظیمات Pinning مطالعه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو