طبق تحلیل Red Hat از ۲۱۹ جلسه واقعی، Claude Code سه چهارم بودجه توکن خود را صرف خواندن پایگاه کد (codebase) میکند. این یافته فرض معمول مبنی بر اینکه عوامل کدنویسی مبتنی بر هوش مصنوعی وقت خود را با تولید کد تلف میکنند را تغییر میدهد و نشان میدهد که توسعهدهندگان باید به جای سرعت مدل، بر مسئله مدیریت کانتکست (context-management) تمرکز کنند.
دادههای پشت این ادعا
Red Hat تعداد ۲۱۹ تعامل با Claude Code از Anthropic را بررسی کرد و میزان استفاده از توکن را در هر مرحله محاسبه نمود. در میان نمونهها، میانه هر مرحله ۷۵٪ از توکنها را به دریافت و پردازش کد و مستندات اطراف اختصاص داده بود، در حالی که تنها ۲۵٪ صرف تولید خطوط جدید میشد. از آنجایی که اکثر ارائهدهندگان هوش مصنوعی، توکنهای ورودی و خروجی را با نرخ یکسانی محاسبه میکنند، بخش «خواندن» تراکنش، بخش عمده هزینهها را شامل میشود.
چرا هزینه خواندن اهمیت دارد
استراتژی بهینهسازی
بسیاری از تیمها منابع خود را صرف مدلهای سریعتر یا بزرگتر میکنند، با این امید که افزایش سرعت، چند ثانیه از زمان هر مرحله تولید را کاهش دهد. اگر سه چهارم کار صرفاً فراخوانی کانتکست باشد، یک مدل سریعتر تنها بخش کوچکی از زمان کل را ذخیره میکند. اهرم واقعی، میزان کانتکستی است که مدل باید در هر مرحله پردازش کند.
کنترل هزینه
وقتی یک دستیار هوش مصنوعی در هر درخواست، دوباره وضعیت همان مخزن (repository) را میخواند، توکنهای ورودی به شدت افزایش مییابند. پروژههایی با پنجرههای کانتکست بزرگ میتوانند شاهد افزایش چشمگیر صورتحسابهای خود باشند، حتی اگر مقدار کد تولید شده اندک باشد.
تمرکز مهندسی
سازندگان ابزار اغلب به دنبال کیفیت بالاتر مدل هستند، در حالی که نحوه ساخت پرامپتها را نادیده میگیرند. این تحلیل نشان میدهد که «مهندسی کانتکست» – یعنی هرس کردن، کش کردن (caching) و خلاصهسازی کدی که به مدل داده میشود – نرخ بازگشت سرمایه (ROI) بیشتری نسبت به ارتقای تدریجی مدلها دارد.
گامهای عملی برای کاهش هزینههای اضافی خواندن
- هرس کردن فایلهای نامرتبط – فایلهایی را که وظیفه فعلی به آنها نیاز ندارد از پرامپت حذف کنید. پرامپتهای کوچکتر به معنای توکنهای ورودی کمتر است.
- کش کردن خواندنهای تکراری – تفسیر مدل از بخشهای پایدار پایگاه کد را ذخیره کنید و به جای ارسال مجدد همان متن، از آن در مراحل بعدی استفاده کنید.
- فشردهسازی خروجی ابزارها – وقتی ابزارهای خارجی حجم زیادی از داده را برمیگردانند (مثلاً گزارشهای lint)، قبل از ارسال آنها به Claude، آنها را خلاصه کنید.
- استفاده از دیفهای افزایشی (incremental diffs) – به جای ارسال کل محتوای فایل، فقط تغییرات ایجاد شده از مرحله قبل را ارسال کنید.
هدف این تاکتیکها جلوگیری از بازخوانی مکرر یک وضعیت ثابت از مخزن در هر تعامل است که هم تأخیر (latency) و هم هزینه را کاهش میدهد.
استدلال متقابل: سرعت همچنان مهم است
برخی از توسعهدهندگان استدلال میکنند که مدل سریعتر همچنان اهمیت دارد، زیرا تأخیر مربوط به آن ۲۵٪ توکنی را که واقعاً تولید میشوند، کاهش میدهد. در محیطهای حساس به تأخیر – مانند پلاگینهای IDE که باید فوراً پاسخ دهند – هر میلیثانیه مهم است. پروفایلِ «خواندن-محور» مزیت یک مدل سریعتر را از بین نمیبرد؛ بلکه صرفاً تأثیر نسبی آن را کاهش میدهد.
آنچه باید در آینده زیر نظر داشت
مطالعه Red Hat بر اساس مجموعه محدودی از جلسات است، بنابراین نمونهبرداری گستردهتر میتواند توزیع توکنهای متفاوتی را برای سایر زبانها یا اندازههای پروژه نشان دهد. اگر دادههای آینده عدد ۷۵٪ خواندن را تأیید کنند، ممکن است شاهد تغییر به سمت ابزارهایی باشیم که به طور خودکار کانتکست را هرس و کش میکنند، یا حتی معماریهای مدلی که برای دریافت سریع کانتکست تنظیم شدهاند.
نکته کلیدی: برای کدنویسی با کمک هوش مصنوعی، ارزانترین راه برای بهبود عملکرد، دادن اطلاعات کمتر به مدل است، نه سریعتر نوشتن آن. اعداد Red Hat استدلال روشنی دارند: پرامپتهای خود را هرس، کش و خلاصه کنید تا شاهد صرفهجویی ملموس در زمان و هزینه باشید.