اگر امروز برای توکن‌های طولانی در APIهای هوش مصنوعی هزینه می‌دهید، احتمالاً نیمی از بودجه‌ی شما صرف کلماتی می‌شود که مدل برای فهمیدن آن‌ها نیازی به خواندن ندارد. کاهش حجم این ورودی‌ها تا ۲ تا ۵ برابر، بدون افت کیفیت پاسخ، می‌تواند هزینه‌های عملیاتی شما را به‌شدت پایین بیاورد.
طبق یک راهنمای فنی که در ۹ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، کلید این کار شناسایی توکن‌های «پرکننده» است؛ کلماتی که مقدار اطلاعاتی نزدیک به صفر دارند. اکثر پرامپت‌های سیستمی طولانی و تکه‌های بازیابی‌شده در تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — مملو از حروف تعریف، کلمات ربط و عبارات کلیشه‌ای (Boilerplate) هستند. این کلمات برای انسان ضروری‌اند تا متن خواندنی باشد، اما مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — می‌تواند آن‌ها را از روی متن پیش‌بینی کند.
این وضعیت باعث اتلاف توان پردازشی و هزینه در هر فراخوانی API می‌شود، زیرا همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، تأخیر در مرحله‌ی پیش‌پُرکردن (Prefill) به‌صورت خطی با طول پرامپت افزایش می‌یابد. این یعنی هر توکن اضافی، مستقیماً روی سرعت پاسخ‌دهی و کیف پول شما اثر می‌گذارد. در همین راستا، برخی استارتاپ‌ها مانند Oxlo.ai با مدل‌های قیمت‌گذاری مبتنی بر درخواست سعی دارند هزینه‌های پردازش زمینه‌های طولانی را به شکل رادیکال‌تری کاهش دهند.
سازوکار غافلگیری (Surprisal)
خانواده‌ی مدل‌های LLMLingua متعلق به مایکروسافت، توکن‌ها را بر اساس «غافلگیری» رتبه‌بندی می‌کنند. غافلگیری در واقع معکوسِ ریاضیِ پیش‌بینی‌پذیری است. به نقل از مستندات این ابزار، ارزش یک توکن بر اساس خود-اطلاعات (Self-information) محاسبه می‌شود که فرمول آن به صورت $\log_2 p(\text{token})-$ است.
یک توکن نادر، مثل یک کد خطای خاص یا یک نام منحصر‌به‌فرد، غافلگیری بالایی دارد چون مدل نمی‌تواند آن را حدس بزند. در مقابل، کلمات توقف (Stopwords) مثل «از» یا «که» تقریباً کاملاً پیش‌بینی‌پذیرند و ارزش اطلاعاتی آن‌ها نزدیک به صفر است؛ بنابراین حذف آن‌ها آسیبی به معنا نمی‌زند و «ارزان» هستند. این رویکرد حذف داده‌های کم‌ارزش، مشابه راهکارهای جدید برای حذف نویز از لاگ‌های سیستمی است که حجم داده‌های ورودی به LLM را برای تحلیل‌های صنعتی به شدت کاهش می‌دهد.
در پیاده‌سازی‌های قطعی، این مقدار با استفاده از فرکانس معکوس و perplexity (پراکندگی) یک مدل زبانی کوچک (SLM) اندازه‌گیری می‌شود. کلمات پرکننده حتی جریمه بیشتری می‌گیرند؛ برای مثال، مقدار غافلگیری آن‌ها در عدد ۰.۱۲ ضرب می‌شود تا به عنوان کلماتی که به راحتی قابل حدس هستند علامت‌گذاری شوند و سریع‌تر از لیست حذف شوند.
نرده‌های ایمنی برای جلوگیری از شکست
هرس کردن ساده‌ی توکن‌ها خطرناک است چون برخی کلمات کم‌ارزش، در واقع «ستون‌های نگهدارنده‌ی» معنا هستند. برای مثال، کلمه‌ی «نه» تکرار زیاد و غافلگیری کمی دارد، اما حذف آن دستور «وجهه را بازنگشت نکن» را به «وجهه را بازنگشت کن» تبدیل می‌کند و معنا را کاملاً برعکس می‌کند.
برای جلوگیری از این شکست‌های خاموش، مکانیزم فشرده‌سازی سه دسته‌ی خاص را بدون توجه به امتیازشان «پین» یا تثبیت می‌کند تا حتماً باقی بمانند:
- اعداد: هر توکنی که شامل رقم باشد، مانند ۲۵۰ دلار یا کد شناسه‌ای مثل INV-4471.
- منفی‌سازها: کلمات حیاتی شامل «نه»، «هرگز»، «بدون»، «هیچ»، «نه این و نه آن» و «نمی‌تواند».
- موجودیت‌های نام‌دار: توکن‌هایی که با حروف بزرگ شروع می‌شوند و صرفاً شروع‌کننده‌ی استاندارد یک جمله نیستند.
مدیریت بودجه‌ی توکن‌ها
در این سیستم، نسبت فشرده‌سازی (r) به جای یک آستانه‌ی ثابت، به عنوان یک «بودجه» عمل می‌کند. توکن‌های محافظت‌شده مقدار بی‌نهایت می‌گیرند تا تضمین شود که همیشه زنده می‌مانند. سپس سیستم تعداد $\text{round}(r \cdot N)$ از کم‌ارزش‌ترین توکن‌های غیرمحافظت‌شده را حذف می‌کند.
از آنجایی که ترتیب اصلی کلمات حفظ می‌شود، خروجی یک زیرمجموعه خوانا است و نه یک بازآرایی از کلمات. برای تضمین ایمنی، سیستم مجموعه‌ی توکن‌های محافظت‌شده را با بازماندگان مقایسه (Diff) می‌کند؛ اگر حتی یک توکن محافظت‌شده حذف شده باشد، فشرده‌سازی به عنوان «ناامن» علامت‌گذاری می‌شود و کاربر باید نسبت فشرده‌سازی را کاهش داده یا بودجه را افزایش دهد.
تفاوت فشرده‌سازی با خلاصه‌سازی
این رویکرد با خلاصه‌سازی سنتی بنیاداً متفاوت است. خلاصه‌سازی یک فرآیند انتزاعی (Abstractive) است که نیاز به یک فراخوانی مجدد از LLM دارد؛ این کار باعث افزایش تأخیر شده و ریسک توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — را افزایش می‌دهد.
اما فشرده‌سازی استخراجی (Extractive) است؛ یعنی فقط توکن‌های موجود را حذف می‌کند و چیزی نمی‌سازد. این کار را قطعی و ارزان می‌کند. متن حاصل شبیه به یک تلگراف است که مدل‌های زبانی به‌طور بهینه با آن برخورد می‌کنند.
برخلاف «بریدن» (Truncation) که کورکورانه انتهای متن را می‌برد — و اغلب مهم‌ترین محدودیت‌ها مثل «طبق قوانین GDPR...» یا «هرگز شماره کارت را به اشتراک نگذار» را حذف می‌کند — هرس کردن بر اساس اهمیت (Salience Pruning)، نویز را از سراسر متن می‌گیرد. این امر تضمین می‌کند که نرده‌های ایمنی و دستورات حیاتی باقی بمانند. در مقابل، برخی ابزارهای یکپارچه‌ساز مانند پروتکل MCP در محیط Claude ممکن است به دلیل ساختار خود، باعث افزایش ناخواسته توکن‌های ورودی شوند و چالش‌های مشابهی در مدیریت پنجره زمینه ایجاد کنند.
توسعه‌دهندگان در محیط‌های عملیاتی معمولاً از PromptCompressor در LLMLingua-2 استفاده می‌کنند. این ابزار با استفاده از یک مدل زبانی کوچک، توکن‌ها را رتبه‌بندی کرده و نسبت فشرده‌سازی هدف را رعایت می‌کند، در حالی که توکن‌های تعریف‌شده توسط کاربر را به‌اجبار حفظ می‌کند.
با فشرده‌سازی یک‌باره‌ی زمینه‌های بزرگ و ذخیره‌سازی (Caching) نتیجه، تیم‌ها می‌توانند خروجی‌های باکیفیت را حفظ کنند و در عین حال بار توکنی روی مدل‌های پیشرو (Frontier Models) را به‌شدت کاهش دهند. این فرآیند دقیقاً بعد از مرحله‌ی بازیابی و در کنار مدیریت زمینه‌های طولانی قرار می‌گیرد.
برای مشاهده‌ی این سازوکار در عمل، می‌توانید لغزنده‌ی نسبت فشرده‌سازی را در سایت دموی رسمی تست کنید و ببینید در چه نقطه‌ای منفی‌سازهای حیاتی حذف می‌شوند: https://dev48v.infy.uk/ai/days/day58-prompt-compression.html
گام بعدی شما
- اگر از RAG استفاده می‌کنید، ابزار LLMLingua-2 را برای فشرده‌سازی تکه‌های بازیابی‌شده پیش از ارسال به مدل اصلی تست کنید.
- توکن‌های حساس کسب‌وکار خود را در لیست «محافظت‌شده» (Force-keep) قرار دهید تا از تغییر معنای دستورات جلوگیری شود.
- نرخ تأخیر (Latency) را قبل و بعد از فشرده‌سازی اندازه بگیرید تا نقطه بهینه بین هزینه و دقت را پیدا کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو