عامل هوشمند مبتنی بر LLM شما ممکن است در یک دمو بهخوبی کار کند، اما پس از چند مرحله از سرعت افت کرده و هزینههای آن به شدت بالا برود. مقصر پنهان یک مدل بیثبات نیست؛ بلکه «رانش توکن» (token drift) است؛ یعنی تورم تدریجی پرامپتی که مدل باید در هر بار پردازش، آن را بررسی کند.
رانش توکن زمانی رخ میدهد که هر تعامل، متن بیشتری را به بافت ورودی (input context) مدل اضافه میکند. تاریخچه گفتگو، طرحوارههای ابزار (tool schemas)، پاسخهای API و اسناد بازیابیشده همگی روی هم انباشته میشوند، بنابراین هر فراخوانی بعدی بار (payload) بزرگتری را با خود حمل میکند. از آنجایی که زمان پردازش و قیمتگذاری مدل با تعداد توکنهای ورودی افزایش مییابد، هزینه بهجای رشد خطی، بهصورت درجه دوم (quadratically) بالا میرود.
چرا این مشکل در محیط عملیاتی (production) ظاهر میشود و نه در دموها
استقرار واقعی همه چیز را حفظ میکند: هر گفته کاربر، هر خروجی ابزار و هر تکه از دانش بازیابیشده. این انباشتگی تا زمانی که تأخیر (latency) ناگهان بالا برود و صورتحساب از راه برسد، پنهان میماند.
منابع رایج رانش توکن
- متنهای تکراری – نگه داشتن تمام پیامهای قدیمی در پرامپت بهجای خلاصهسازی یا حذف آنها.
- طرحوارههای سنگین ابزار – ارسال تعاریف JSON بزرگ از قابلیتهای ابزار در هر مرحله.
- نتایج حجیم ابزار – گنجاندن پاسخهای کامل API یا ردیفهای پایگاه داده که حاوی دادههای بیش از نیاز واقعی عامل هستند.
- تورم RAG – تولید تقویتشده با بازیابی (RAG) که تکههای زیادی از اسناد را اضافه میکند که برخی از آنها قدیمی یا نامرتبط هستند.
- حافظه تکراری – قرار دادن همزمان یک خلاصه، یک شیء وضعیت (state object) و متن خام، که باعث تکرار یک اطلاعات به سه صورت مختلف میشود.
هر یک از این موارد توکنهایی را اضافه میکنند که قدرت استدلال جدیدی به مدل نمیافزایند، اما اندازه پرامپت را حجیم میکنند.
چگونه بودجه توکن را کنترل کنیم
۱. از طراحی بافت لایهبندیشده استفاده کنید
- دستورالعملهای ثابت – پرامپتهای سیستم و قوانین ایمنی را در بالا نگه دارید و بهجای ارسال مجدد آنها در هر مرحله، به آنها ارجاع دهید.
- وضعیت ساختاریافته – نمایش فشردهای از اهداف، تصمیمات و شناسهها را ذخیره کنید که عامل بتواند بهسرعت آنها را بخواند.
- تاریخچه فشردهشده – مراحل قدیمیتر را در یک پاراگراف کوتاه و قابل خواندن برای انسان خلاصه کنید و تنها زمانی که به یک حد مشخص رسیدید، آن را بهروزرسانی کنید.
- مراحل اخیر – چند پیام آخر را عیناً (verbatim) بگنجانید تا تداوم گفتگو حفظ شود.
جدا کردن متنهای ثابت از محتوای قابل خلاصهسازی، مانع از ارسال مکرر کلمات یکسان میشود.
۲. خروجیهای ابزار را هرس کنید
- تنها فیلدهایی را که عامل واقعاً استفاده میکند استخراج کنید؛ توضیحات طولانی را حذف کنید.
- نتایج بزرگ را با یک خلاصه مختصر یا یک شناسه مرجع (reference ID) جایگزین کنید و بار کامل را در یک پایگاه داده، کش (cache) یا blob store ذخیره کنید.
- وقتی یک ابزار لیستی را برمیگرداند، فقط N مورد اول را که برای تصمیمگیری فعلی مهم هستند ارسال کنید.
۳. خلاصهسازی هوشمند را اعمال کنید
- از خلاصهسازی بعد از هر مرحله صرفنظر کنید؛ پردازش اضافی باعث ایجاد بار اضافی (overhead) میشود.
- خلاصه را تنها زمانی بهروزرسانی کنید که تعداد توکنهای انباشتهشده در مراحل قدیمیتر از یک حد مشخص فراتر رود.
- حقایق حیاتی (مانند شناسهها، مبالغ و برچسبهای زمانی) را بهجای گنجاندن در متن، در یک ذخیرهساز ساختاریافته نگه دارید تا خلاصه کوتاه باقی بماند.
۴. معیارهای درست را ردیابی کنید
- میزان استفاده از توکن را به ازای هر فراخوانی مدل ثبت کنید، نه فقط به ازای هر درخواست کاربر. این کار رشد پنهان در سمت ورودی را آشکار میکند.
- تعداد توکنهای ورودی اضافه شده در هر مرحله را زیر نظر بگیرید؛ یک جهش ناگهانی نشاندهنده منبع رانش است.
- توکنهای کششده (استفاده مجدد از فراخوانیهای قبلی) را از توکنهای جدیداً تولیدشده جدا کنید؛ تنها مورد اول عامل رانش است.
با پرامپت مانند یک منبع محدود برخورد کنید، نه یک متن بیانتها. با اندازهگیری، خلاصهسازی و هرس کردن آگاهانه، عامل LLM خود را سریع، مقرونبهصرفه و آماده برای مقیاس عملیاتی نگه میدارید.
نکته کلیدی: رانش توکن بهصورت بیصدا هزینهها را بالا برده و سرعت عاملها را کاهش میدهد. بخشهای در حال رشد پرامپت خود را شناسایی کنید، آنها را فشرده یا خارجی (externalize) کنید و میزان استفاده از توکن در هر فراخوانی را زیر نظر بگیرید. یک رویکرد منضبط، شوکهای ناگهانی در صورتحساب را به یک عملیات قابل مدیریت و اقتصادی تبدیل میکند.