اگر تصور می‌کنید تا آخرین توکنِ مجاز در یک مدل زبانی، دقت استدلال ثابت می‌ماند، در اشتباهید. واقعیت این است که توانایی تحلیل مدل‌ها مدت‌ها پیش از رسیدن به سقف سخت‌افزاری، از درون شروع به پوسیدن می‌کند. در حالی که شرکت‌ها پنجره‌های عظیم را تبلیغ می‌کنند، استدلال هوش مصنوعی شما فقط در نقطه محدودیت توکن متوقف نمی‌شود، بلکه بسیار زودتر از رسیدن به آن دیوار، دچار زوال می‌شود. کاربرد واقعی این توکن‌ها یک مقیاس لغزنده از تخریب است که می‌تواند منجر به نادیده گرفتن محدودیت‌ها و تولید کدهای متناقض شود.
بسیاری از توسعه‌دهندگان به پنجرهٔ زمینه (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — به‌صورت یک کلید روشن/خاموش نگاه می‌کنند؛ یعنی یا مدل داده را می‌بیند یا نمی‌بیند. اما در واقعیت، این پنجره میدانی با وزن‌های متفاوت است که تمرکز مدل در آن بر اساس موقعیت توکن‌ها تغییر می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی نحوه مدیریت مدل‌های محلی توسط اولاما (Ollama) اشاره کردیم، درک مکانیسم‌های داخلی توجه، گام بعدی در بهینه‌سازی پرامپت‌های عملیاتی است.
پنجرهٔ زمینه را شبیه به یک نورافکن تصور کنید. جدیدترین توکن‌ها زیر شدیدترین نور هستند، در حالی که دستورالعمل‌های ابتدایی با رشد گفتگو، به‌آرامی در سایه‌ها محو می‌شوند. این یک نقص معماری نیست، بلکه انتخابی طراحی‌شده به نام «سوگیری استقرایی» (Inductive Bias) است تا مدل اولویت را به گفتگوهای جاری بدهد، نه به دستوری که ۱۰ هزار توکن پیش ارسال شده است. این چالش با یافته‌های اخیر همسو است که نشان می‌دهد بسیاری از دستورات کاربران در فرآیندهای فشرده‌سازی حافظه توسط سیستم‌های هوش مصنوعی حذف می‌شوند.
محتویات واقعی پنجرهٔ زمینه
این یک باور غلط است که مدل‌ها پیام‌های قبلی را «به خاطر می‌آورند». در واقع، هر بار که پیامی می‌فرستید، کل تاریخچه گفتگو به‌عنوان یک توکی ورودی واحد دوباره ارسال می‌شود. این توالی ترکیبی از چندین عنصر است:
- پرامپت سیستمی و دستورالعمل‌های اولیه.
- تمام پیام‌های کاربر و پاسخ‌های مدل در آن رشته.
- هرگونه سند، قطعه‌کد یا فایل پیوست‌شده.
- نتایج حاصل از استفاده از ابزار (Tool Use) در صورت فراخوانی توابع توسط مدل.
این عناصر به‌عنوان یک توالی از توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — پردازش می‌شوند. با وجود اعداد خیره‌کننده، مثل ظرفیت ۲۰۰ هزار توکنی کلود سونت ۴ (Claude Sonnet 4)، ۱۲۸ هزار توکنی GPT-4o یا یک میلیون توکنی جمینای ۱.۵ پرو (Gemini 1.5 Pro)، این فضا به‌سرعت پر می‌شود. یک جلسه عیب‌یابی مفصل و پرحاشیه می‌تواند به‌راحتی ۳۰ تا ۵۰ هزار توکن مصرف کند. برای مدیریت بهینه این حجم از داده، استانداردهایی مانند پروتکل MCP برای کاهش نیاز به APIهای مجزا معرفی شده‌اند تا تبادل اطلاعات با مدل‌ها ساختاریافته‌تر شود.
مکانیسم‌های توجه
به نقل از تحلیل فنی منتشر شده در ۲۱ اوت ۲۰۲۶ در وب‌سایت dev.to، پنجرهٔ زمینه بر پایه خودتوجهی (Self-Attention) در معماری ترنسفورمر (Transformer) استوار است. هنگام پردازش ورودی، هر توکن به تمام توکن‌های دیگر «توجه» می‌کند. امتیاز توجه تعیین می‌کند که نمایش توکن A چقدر تحت تأثیر توکن B قرار بگیرد.
این امتیاز از طریق فرمول attention_score(query_A, key_B) = dot_product(Q_A, K_B) / sqrt(d_k) محاسبه می‌شود. در اینجا Q_A بردار پرس‌وجو (Query) برای توکن A و K_B بردار کلید (Key) برای توکن B است. امتیازات بالاتر نشان‌دهنده تأثیر بیشتر است. چون مدل‌ها روی داده‌های متوالی آموزش دیده‌اند، توکن‌های اخیر به‌طور طبیعی امتیازات بالاتری می‌گیرند. به همین دلیل، «زمینهٔ مؤثر» همیشه کوچک‌تر از «زمینهٔ تبلیغاتی» است.
مقیاس تخریب کیفیت
طبق گزارش مذکور، کیفیت استدلال به‌صورت ناگهانی سقوط نمی‌کند، بلکه در مراحل پیش‌بینی‌پذیری بر اساس ظرفیت فرسوده می‌شود:
- ظرفیت ۰ تا ۴۰٪: کیفیت کامل. مدل به همه بخش‌ها به‌طور مؤثر توجه می‌کند. محدودیت‌های تعیین‌شده در ابتدا رعایت می‌شوند و تصمیمات اولیه به خاطر سپرده می‌شوند.
- ظرفیت ۴۰ تا ۶۰٪: تخریب جزئی. مدل ممکن است گاهی یک محدودیت را از ابتدای گفتگو نادیده بگیرد. تصمیمات معماری اولیه وزن کمتری دریافت می‌کنند.
- ظرفیت ۶۰ تا ۸۰٪: تخریب محسوس. محدودیت‌های ابتدای گفتگوهای طولانی نادیده گرفته می‌شوند. مدل ممکن است با تصمیمات قبلی خود تناقض ایجاد کند و کیفیت کدنویسی تمایل به کاهش دارد.
- ظرفیت ۸۰ تا ۱۰۰٪: تخریب شدید. مدل عملاً روی زمینه‌ای مؤثر بسیار کوچک‌تر از پنجرهٔ واقعی عمل می‌کند. محتوای ابتدایی حضور دارد اما به‌طور معنا‌داری مورد توجه قرار نمی‌گیرد.
پدیده «گم‌شدن در میانه»
پژوهش‌ها یک حالت شکست خاص را برجسته می‌کنند که در آن مدل‌ها در پردازش دقیقاً ابتدای پرامپت و دقیقاً انتهای آن عالی هستند، اما در مرکز دچار مشکل می‌شوند. این وضعیت یک منحنی توجه U-شکل ایجاد می‌کند.
برای مقابله با این موضوع، توسعه‌دهندگان باید از دفن کردن زمینه‌های حیاتی در وسط پرامپت خودداری کنند. این دو ساختار را مقایسه کنید:
- کم‌اثر: [دستورات سیستمی - ابتدا] $ \rightarrow $ [زمینه طولانی - وسط] $ \rightarrow $ [پرسش مشخص - انتها]
- بسیار مؤثر: [دستورات سیستمی - ابتدا] $ \rightarrow $ [پرسش مشخص - نزدیک به ابتدا] $ \rightarrow $ [زمینه مرتبط - انتها]
اطلاعاتی که می‌خواهید مدل بیشترین توجه را به آن‌ها داشته باشد، باید در دو نقطه انتهایی (شروع و پایان) پنجرهٔ زمینه قرار گیرند.
استراتژی‌های مدیریت عملیاتی
برای حفظ کیفیت خروجی‌ها، گزارش dev.to پیشنهاد می‌کند ظرفیت ۶۰٪ را به‌عنوان سقف سخت برای کارهای پیچیده در نظر بگیرید. با رسیدن به این حد، توسعه‌دهندگان باید گردش‌کار «خلاصه‌سازی و بازراه‌اندازی» را اجرا کنند.
از مدل بخواهید: «تصمیمات کلیدی، محدودیت‌ها، وضعیت فعلی و هرگونه الگوی مهم کد که در این گفتگو ایجاد شده است را خلاصه کن. متن را زیر ۳۰۰ کلمه نگه دار.» با شروع یک گفتگوی جدید با این خلاصه، شما ۳۰ تا ۵۰ هزار توکن نویز را به ۱ تا ۲ هزار توکن سیگنالِ متراکم تبدیل می‌کنید. در همین راستا، پیاده‌سازی‌های پیشرفته‌ای مانند معماری CHROMATIC-MCP برای بهینه‌سازی سربار زمینه تلاش می‌کنند تا بهره‌وری در تعامل با ابزارهای هوش مصنوعی را افزایش دهند.
سایر تاکتیک‌های بهره‌وری عبارت‌اند از:
- بارگذاری پیشرو محدودیت‌ها: قوانین حیاتی (مثلاً «تمام توابع باید async باشند» یا «این کد روی Node 18 اجرا می‌شود») را هم در ابتدای پرامپت سیستمی و هم در انتهای آخرین پیام خود تکرار کنید. این کار تضمین می‌کند که محدودیت در دو نقطه با توجه بالا ظاهر شود.
- جداسازی مسائل: برای کارهای غیرمرتبط از گفتگوهای جداگانه استفاده کنید. اگر سه تابع مجزا را در یک رشته عیب‌یابی کنید، تبادلات مربوط به تابع A، زمینهٔ مؤثر در دسترس برای تابع C را کاهش می‌دهد.
- پایش لحظه‌ای: استفاده از ابزارهایی مثل TokenPulse برای رصد درصد اشغال پنجره در مدل‌هایی مثل Gemini 1.5 Pro، DeepSeek یا Grok از طریق یک نوار زنده بالای جعبه ورودی.
توهمِ یک میلیون توکن
اینکه جمینای ۱.۵ پرو پنجره‌ای یک میلیون توکنی دارد، به معنای افزایش خطی ۵ برابری در استدلال مؤثر نسبت به یک پنجره ۲۰۰ هزار توکنی نیست. مشکل تخریب توجه با افزایش طول متن مقیاس‌پذیر است. پنجره‌های عظیم برای جست‌وجو در کدهای حجیم یا مجموعه‌های سندی بسیار ارزشمند هستند، اما فرسایش بنیادی استدلال در کارهای توسعه فعال را حل نمی‌کنند.
برای اکثر مهندسان، گلوگاه اندازه پنجره‌ای که توسط آزمایشگاه‌ها ارائه شده نیست، بلکه مدیریت تاریخچه گفتگو است. اگر مدل شروع به توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — یا نادیده گرفتن قوانین کرد، راه حل به‌ندرت یک مدل بزرگ‌تر است، بلکه یک جلسه تازه است.
برای بهینه‌سازی گردش‌کار فعلی خود، سعی کنید طولانی‌ترین رشته‌های فعال خود را ممیزی کنید و دقیقاً نقطه‌ای را شناسایی کنید که مدل شروع به نادیده گرفتن محدودیت‌های اولیه شما کرد.
گام بعدی شما
- طولانی‌ترین رشته‌های گفتگوی فعال خود را بررسی کنید و نقطه‌ای که مدل شروع به نادیده گرفتن دستورات اولیه کرد را شناسایی کنید.
- برای تسک‌های پیچیده، هرگاه حجم متن به ۶۰٪ ظرفیت مدل رسید، از تکنیک خلاصه‌سازی و شروع جلسه جدید استفاده کنید.
- دستورات حیاتی را در هر دو نقطه ابتدا و انتهای پرامپت تکرار کنید تا در نقاط اوج منحنی توجه قرار گیرند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو