‏Context Pruning: کاهش توکن‌های LLM بدون افت کیفیت

وقتی یه اپلیکیشن مبتنی بر LLM (مدل زبانی بزرگ) می‌سازی، احتمالاً بخش بزرگی از توکن‌هایی که به مدل می‌فرستی اصلاً کار مفیدی نمی‌کنن. متن‌های بازیابی‌شده‌ی اضافه، تاریخچه‌ی مکالمه‌ای که دیگه مرتبط نیست، boilerplate های تکراری — اینا همه هزینه دارن، تأخیر ایجاد می‌کنن و می‌تونن کیفیت خروجی مدل رو هم پایین بیارن. Context Pruning روشی‌ه که این توکن‌های کم‌ارزش رو قبل یا حین اجرای مدل حذف می‌کنه — نه با بازنویسی متن، نه با تغییر وزن‌های مدل.

این روش با چند چیز اشتباه گرفته می‌شه: Prompt Engineering که دستی پرامپت رو بهتر می‌کنه ولی توکن‌ها رو کم نمی‌کنه؛ Model Pruning که وزن‌های خود مدل رو حذف می‌کنه؛ و Abstractive Summarization که متن جدید تولید می‌کنه. Context Pruning هیچ‌کدام از اینا نیست — فقط روی ورودی عمل می‌کنه و محتوای اصلی رو انتخاب یا حذف می‌کنه.

چهار رویکرد اصلی وجود داره. Token-level pruning ریزدانه‌ترینه: یه مدل کوچیک‌تر هر توکن رو بررسی می‌کنه و کم‌ارزش‌ها رو حذف می‌کنه. ابزاری مثل LLMLingua-2 این کار رو با مدل‌های encoder کوچیک مثل XLM-RoBERTa انجام می‌ده و تا ۶ برابر سرعت رو بالا می‌بره. Sentence/chunk-level pruning واحدهای بزرگ‌تر رو ارزیابی می‌کنه و برای pipeline های RAG (بازیابی-تولید) خوب جواب می‌ده. Attention-based pruning از الگوهای توجه خود مدل استفاده می‌کنه تا بفهمه کدوم توکن‌ها مهمن — بدون نیاز به مدل کمکی اضافه. Dynamic layer-progressive pruning هم حین اجرا عمل می‌کنه و در لایه‌های عمیق‌تر تبدیل‌گر (Transformer) که سیگنال مهم گسترش پیدا کرده، بیشتر حذف می‌کنه.

یه باور رایج اینه که پنجره‌های context بزرگ‌تر این مشکل رو حل می‌کنن — ولی اینطور نیست. تحقیقات نشون داده LLMها با محتوایی که وسط یه context طولانی گیر کرده ضعیف عمل می‌کنن (پدیده‌ای به اسم "lost in the middle"). یه مطالعه‌ی ۲۰۲۵ نشون داد یه مدل با ۳۰ هزار توکن padding، ۶۷.۶ امتیاز از دست داد. حتی مدل‌هایی با پنجره‌ی ۱ میلیون توکن در بنچمارک‌های واقعی خیلی زودتر افت کیفیت نشون می‌دن.

اعداد واقعی هم جذابن. LLMLingua تا ۲۰ برابر فشرده‌سازی گزارش داده با افت کیفیت اندک. روش‌های مبتنی بر KV cache (که حالت‌های میانی attention رو ذخیره می‌کنه) نتایج بهتری دارن؛ MUSTAFAR حافظه‌ی KV cache رو ۵۵٪ کم کرد و throughput رو ۲.۲۳ برابر بالا برد. یه مطالعه‌ی تجربی هم تأیید کرد که فشرده‌سازی متوسط حتی می‌تونه کیفیت خروجی LLM رو بهبود بده، نه فقط حفظ کنه.

البته محدودیت‌هایی هم هست. روی کد و داده‌های ساختاریافته، token-level pruning می‌تونه syntax رو خراب کنه. در بنچمارک SWE-Bench ابزار تخصصی SWE-Pruner به ۶۴٪ موفقیت رسید، در حالی که LLMLingua-2 به ۵۴٪ افتاد. برای مکالمات چندمرحله‌ای هم حذف تاریخچه می‌تونه پیوستگی منطقی مکالمه رو بشکنه — راه‌حل، یه حافظه‌ی دو لایه‌ست: حافظه‌ی کاری برای session جاری و حافظه‌ی بلندمدت برای واقعیت‌های استخراج‌شده.

Semantic Caching بهترین همراه Context Pruning‌ه. Semantic caching وکتور embedding سوال جدید رو با سوال‌های قبلی مقایسه می‌کنه و اگه شبیه باشن، جواب کش‌شده رو برمی‌گردونه — بدون retrieval، pruning، یا اجرای مدل. Pruning فقط روی cache miss ها اجرا می‌شه. Redis این دو لایه رو روی یه زیرساخت یکپارچه می‌کنه؛ Redis LangCache تا ۱۵ برابر پاسخ سریع‌تر و ۷۳٪ هزینه‌ی کمتر در بنچمارک‌های Redis گزارش داده.

نکات کلیدی:

• Context Pruning توکن‌های کم‌ارزش رو از ورودی مدل حذف می‌کنه — نه مدل رو تغییر می‌ده، نه متن جدید می‌نویسه
• پنجره‌های context بزرگ‌تر جایگزین pruning نمی‌شن؛ توکن‌های اضافه اغلب کیفیت رو پایین می‌ارن
• فشرده‌سازی متوسط گاهی کیفیت خروجی رو بهتر می‌کنه، نه فقط هزینه رو کم
• برای کد از chunk-level pruning استفاده کن، نه token-level
• ترکیب semantic caching با pruning بهترین نتیجه رو می‌ده: caching تعداد دفعاتی که pruning لازمه رو کم می‌کنه