صورت‌حساب API شما هر بار که کاربر وارد بحث‌های حاشیه‌ای می‌شود یا یک باگ را تکرار می‌کند، به‌صورت خطی رشد می‌کند. در ۱۵ اکتبر ۲۰۲۶، یک راهنمای فنی افشا کرد که نسخه ۱۰.۱۰ کتابخانه Microsoft.Extensions.AI (با پرچم آزمایشی MEAI001) از طریق رابط IChatReducer جلوی تورم پنجرهٔ زمینه (Context Window) — که شبیه میز کاری است که فقط جای چند ورق دارد، نه کل کتابخانه — را می‌گیرد تا تمرکز مدل از دست نرود.
همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه نتایج ابزارها می‌توانند ۹۵٪ از پنجره زمینه را هدر دهند اشاره کردیم، این رویکرد فراتر از یک برش ساده است. تصور کنید تاریخچهٔ چت شما یک دفتر کل فیزیکی است؛ به‌جای اینکه صرفاً ۱۰ صفحه آخر را پاره کنید، یک Reducer به‌طور هوشمند صفحات قدیمی را خلاصه می‌کند اما قوانین اصلی خانه را دست‌نخورده باقی می‌گذارد.
سازوکار کاهش حجم
به نقل از گزارش dev.to، کلاس ReducingChatClient پیام‌های ورودی را رهگیری کرده و پیش از ارسال به کلاینت اصلی، یک سیاست کاهش (Reduction Policy) را اعمال می‌کند. این کار مانع از «فراموشی» مدل می‌شود؛ وضعیتی که در آن بات‌ها شناسه‌های حساب کاربری را که در ابتدای گفتگو ذکر شده بود، فراموش می‌کنند. این چالش در مدیریت حافظه بلندمدت، مشابه موانعی است که در بررسی شکاف‌های فنی LangGraph برای عامل‌های چندروزه تحلیل کردیم.
این سازوکار بر متد ReduceAsync متکی است که به صورت زیر تعریف شده است:Task<IEnumerable<ChatMessage>> ReduceAsync(IEnumerable<ChatMessage> messages, CancellationToken cancellationToken)
پیاده‌سازی آن از الگوی Builder پیروی می‌کند:IChatClient client = new ChatClientBuilder(inner).UseChatReducer(reducer).Build();
چهار تله در پیاده‌سازی Reducer
بر اساس مستندات، توسعه‌دهندگان هنگام طراحی Reducer باید از این چهار خطای رایج دوری کنند:
- جفت‌های یتیم ابزار: برش‌های ساده و ابتدایی اغلب یک
FunctionCallContent(فراخوانی تابع) را ازFunctionResultContent(نتیجه تابع) جدا می‌کنند. این اتفاق باعث خطاهای ۴۰۰ در سمت ارائه‌دهنده می‌شود که شبیه به ناپایداری مدل به نظر می‌رسد. Reducerهای داخلی برای حفظ پایداری، این جفت‌ها را از نمای کاهش‌یافته حذف نمی‌کنند تا پیوستگی حفظ شود. اگر یک Reducer سفارشی می‌نویسید، باید از تست‌های واحد (Unit Tests) با تاریخچه‌های ترکیبی استفاده کنید تا مطمئن شوید هیچ‌کدام از این دو نوع محتوا به‌تنهایی باقی نمی‌مانند. - تعداد پیام در برابر تعداد توکن: مدل
MessageCountingChatReducer(targetCount)پیام سیستمی اول و نوبت‌های اخیر غیرسیستمی را نگه می‌دارد. این روش برای سوالات متداول (FAQ) پیش‌بینی‌پذیر و عالی است اما وقتی کاربر یک Stack Trace حجیم را کپی می‌کند، شکست می‌خورد. در اینجا بهTokenAwareChatReducerنیاز است تا هزینه واقعی را تخمین بزند. این Reducer از یک گاردریل (تعداد کاراکترها تقسیم بر ۴) استفاده می‌کند و از جدیدترین پیام به قدیمی‌ترین پیام حرکت می‌کند تا زمانی که بودجه توکن پر شود. - خلاصه‌سازی گران‌قیمت: استفاده از یک مدل پرچم‌دار برای خلاصه کردن تاریخچه، منجر به ایجاد یک صورت‌حساب دوم می‌شود. کلاس
SummarizingChatReducer(summarizer, targetCount, threshold)زمانی فعال می‌شود که پیام‌های خلاصه‌نشده از حد آستانه (threshold) فراتر روند. راهنما توصیه می‌کند که Summarizer را به یک کلاینت کوچک، ارزان یا آفلاین متصل کنید. توجه داشته باشید که خلاصه‌سازی ممکن است مقدار__summary__را درAdditionalPropertiesثبت کند؛ بنابراین نقاط انتهایی پیش‌نمایش (Preview Endpoints) باید پیام‌ها را کلون کنند تا ذخیره‌ساز زنده نشست (Session Store) تغییر نکند. این تلاش برای حفظ معنای گفتگو در عین کاهش حجم، یادآور رویکرد پروژه Coders Talk در انتقال حافظه شناختی برنامه‌نویسان به عامل‌های هوش مصنوعی است. - فرسایش پرامپت سیستمی: حذف پرامپت سیستمی (System Prompt) برای صرفه‌جویی در توکن، ماهیت محصول را به‌طور بنیادی تغییر می‌دهد. تمام Reducerهای معتبر باید با پرامپت سیستمی مانند یک امر مقدس برخورد کنند. اگر خودِ پرامپت سیستمی بیش از حد بزرگ است، باید خودِ پرامپت در محیط تولید اصلاح شود، نه اینکه حذف گردد.
معماری نشست (Session)
برای یک پیاده‌سازی حرفه‌ای، این راهنما یک سطح دسترسی مینیمال با مسیرهای API مشخص را پیشنهاد می‌دهد:
POST /api/sessions: ایجاد یک نشست جدید.POST /api/sessions/{id}/messages: مدیریت چت و بازگرداندن تعداد توکن‌های قبل و بعد از کاهش.GET /api/sessions/{id}/history: بازیابی متن خام و کامل تاریخچه.GET /api/sessions/{id}/reduced: پیش‌نمایش نمای شمارشی، خلاصه‌شده یا توکن-آگاه.
این تغییر در پیاده‌سازی یعنی توسعه‌دهندگان دیگر مجبور نیستند بین یک «پنجره لغزان» (Sliding Window) ساده و یک Payload گران‌قیمت از کل تاریخچه یکی را انتخاب کنند. با جداسازی ذخیره نشست (متن کامل تاریخچه) از داده‌های ارسالی روی شبکه (نسخه کاهش‌یافته)، شما یک ردپای حسابرسی (Audit Trail) کامل دارید بدون اینکه در هر نوبت هزینه آن را بپردازید.
برای کیف پول توسعه‌دهنده، این یعنی تغییر رشد هزینه‌ها از حالت خطی به یک بودجه سقف‌دار برای هر درخواست. این موضوع این فرض را که «زمینه بیشتر همیشه بهتر است» به چالش می‌کشد و ثابت می‌کند که زمینهٔ گلچین‌شده (Curated Context) است که در واقع پایداری عامل (Agent) را تضمین می‌کند. این پایداری در لایه مدیریت نشست، مکمل مکانیزم‌هایی است که در سیستم Critic برای جلوگیری از قطع ارتباط عامل‌ها به کار گرفته شده است.
برای پیاده‌سازی این قابلیت، پروژه خود را به نسخه ۱۰.۱۰ کتابخانه Microsoft.Extensions.AI متصل (Pin) کنید و پرچم آزمایشی MEAI001 را به عنوان سیگنالی در نظر بگیرید که شاید نام‌ها تغییر کنند، اما منطق آن برای محیط تولید آماده است. اکنون می‌توانید کلاینت‌های داخلی آفلاین را با OpenAI یا Azure جایگزین کنید بدون اینکه نیاز باشد لایه کاهش حجم خود را از ابتدا بازنویسی کنید.
گام بعدی شما
- پروژه خود را به نسخه ۱۰.۱۰ کتابخانه Microsoft.Extensions.AI ارتقا دهید.
- برای کاهش هزینه‌ها، یک
TokenAwareChatReducerرا جایگزین شمارش ساده پیام‌ها کنید. - از مدل‌های کوچک (SLM) برای لایه خلاصه‌سازی استفاده کنید تا هزینه استنتاج نهایی افزایش نیابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو