پنجره‌ی زمینه (context window) چیست و چرا مهم است

وقتی مدل «فراموش می‌کند»

یک دستیار پشتیبانی می‌سازید. خوب کار می‌کند، تا اینکه بعد از چهل پیام ناگهان قاعده‌ی اولیه را نادیده می‌گیرد، یا سرور خطای context length exceeded برمی‌گرداند. علت هیچ‌کدام «فراموشی» مدل نیست. مدل زبانی بین دو درخواست هیچ حافظه‌ای ندارد؛ هرچه در یک لحظه می‌داند، در همان یک درخواست به آن داده شده. آن ظرف محدود، پنجره‌ی زمینه یا context window است.

پنجره‌ی زمینه سقف تعداد توکن‌هایی است که مدل در یک فراخوانی می‌تواند ببیند — ورودی و خروجی روی هم. در مدل‌های امروزی کلاد این عدد یک میلیون توکن است و در claude-haiku-4-5 دویست هزار توکن. عدد بزرگی است، و همین بزرگی باعث می‌شود تیم‌ها فکر کنند مسئله حل شده. نشده؛ فقط شکل مسئله عوض شده: از «جا نمی‌شود» به «جا می‌شود ولی گران و بی‌کیفیت است».

داخل پنجره دقیقاً چه چیزهایی هست

بیشتر مهندس‌ها فقط پیام کاربر را ورودی حساب می‌کنند. در عمل همه‌ی این‌ها از همان بودجه مصرف می‌کنند:

• system prompt — قواعد، لحن، محدودیت‌ها، سیاست‌ها. معمولاً ثابت است ولی می‌تواند بزرگ باشد.
• تعریف ابزارها — نام، توضیح و JSON schema هر ابزار. با بیست ابزار، این به‌راحتی چند هزار توکن می‌شود، حتی اگر در آن درخواست هیچ‌کدام صدا زده نشوند.
• تاریخچه‌ی گفت‌وگو — تمام پیام‌های قبلی کاربر و مدل، شامل فراخوانی‌های ابزار.
• خروجی ابزارها — پاسخ خام API، نتیجه‌ی query، محتوای فایل. معمولاً بزرگ‌ترین و کنترل‌نشده‌ترین بخش است.
• اسناد بازیابی‌شده در سیستم‌های RAG.
• جای خالی برای خروجی — max_tokens هم از همین بودجه کم می‌شود. اگر پنجره را تا ته پر کنید، جایی برای جواب نمی‌ماند.

اولین کار عملی این است که این شش قلم را برای یک درخواست واقعی بشمارید. تقریباً همیشه یکی از آن‌ها چند برابر تصور تیم است.

پر کردن پنجره رایگان نیست

سه هزینه‌ی جدا دارد و معمولاً فقط به یکی‌شان توجه می‌شود.

پول. هر توکن ورودی در هر نوبت دوباره پردازش و دوباره حساب می‌شود. یک گفت‌وگوی چهل‌نوبتی یعنی system prompt چهل بار پرداخت شده. رشد هزینه‌ی گفت‌وگو خطی نیست، درجه‌دو است. فرض کنید system prompt و تعریف ابزارها روی هم ۵٬۰۰۰ توکن باشد و هر نوبت ۱٬۰۰۰ توکن به تاریخچه اضافه کند. در نوبت چهلم، ورودی همان یک درخواست حدود ۴۵٬۰۰۰ توکن است و مجموع ورودی پردازش‌شده در کل گفت‌وگو حدود یک میلیون توکن؛ با claude-sonnet-5 و نرخ ۲ دلار به‌ازای هر میلیون توکن ورودی، حدود ۲ دلار برای یک گفت‌وگو. همین گفت‌وگو با claude-opus-5 (ورودی ۵ دلار) حدود ۵ دلار درمی‌آید.

تأخیر. زمینه‌ی بزرگ‌تر یعنی زمان بیشتر تا اولین توکن خروجی. برای مسیری که کاربر پشت آن منتظر است، این مستقیماً کیفیت تجربه است.

کیفیت. این یکی کمتر دیده می‌شود و بیشتر آسیب می‌زند.

ظرفیت با استفاده‌ی مؤثر یکی نیست

اینکه مدل یک میلیون توکن را می‌پذیرد به این معنا نیست که با یک میلیون توکن همان‌قدر خوب کار می‌کند که با ده هزار توکن. توجه مدل روی متن یکنواخت پخش نمی‌شود؛ در عمل چیزی که ابتدا و انتهای زمینه است پررنگ‌تر دیده می‌شود تا چیزی که وسط یک توده‌ی بی‌ساختار دفن شده. نتیجه‌های عملی:

• مرتبط‌بودن مهم‌تر از کامل‌بودن است. ده سند مرتبط بهتر از دویست سندی است که ده تای آن مرتبط است. اضافه‌کردن سند غیرمرتبط فقط بی‌اثر نیست؛ فعالانه حواس مدل را پرت می‌کند.
• به زمینه ساختار بدهید. عنوان، جداکننده‌ی روشن، و ذکر منبع برای هر تکه. متن یکپارچه‌ی ۵۰ هزار توکنی بدترین حالت است.
• دستور حیاتی را نزدیک انتها هم تکرار کنید. وقتی بین system prompt و پیام کاربر ده‌ها هزار توکن فاصله افتاده، تکرار یک‌خطی قید اصلی کمک می‌کند.
• تناقض را حذف کنید. اگر سند قدیمی و سند جدید هر دو در زمینه باشند و حرف متضاد بزنند، مدل ناچار است یکی را حدس بزند.

وقتی کار از پنجره بزرگ‌تر است

استراتژی‌ها را به ترتیب هزینه‌ی پیاده‌سازی امتحان کنید:

1. برش و پاک‌سازی. خروجی ابزارها را قبل از افزودن به زمینه ببرید. یک لاگ ۵۰ هزار توکنی را خام نریزید؛ فیلدهای لازم را استخراج کنید. این ارزان‌ترین و مؤثرترین کار است و اغلب نادیده گرفته می‌شود.
2. خلاصه‌سازی رونده. هر n نوبت، بخش قدیمی تاریخچه را با یک خلاصه‌ی ساختاریافته جایگزین کنید — تصمیم‌های گرفته‌شده، حقایق تثبیت‌شده، کارهای باقی‌مانده. نه هر نوبت؛ خلاصه‌سازی خودش یک فراخوانی مدل است.
3. بازیابی به‌جای بارگذاری. به‌جای ریختن کل مستندات در هر درخواست، فقط تکه‌های مرتبط با پرسش جاری را بیاورید. برای متن فارسی نکته‌های خاصی دارد که در RAG روی متن فارسی آمده.
4. تقسیم کار. برای پردازش یک سند بزرگ، آن را تکه کنید، روی هر تکه جدا کار کنید و نتیجه‌ها را ترکیب کنید. کندتر است ولی از سقف پنجره مستقل می‌شود.
5. زیرایجنت‌ها. هر زیرایجنت پنجره‌ی مستقل خودش را دارد و فقط نتیجه‌ی فشرده را به ایجنت اصلی برمی‌گرداند. زمینه‌ی کثیف جست‌وجو در پنجره‌ی اصلی جمع نمی‌شود.
6. حافظه‌ی بیرونی. هرچه باید بین جلسه‌ها باقی بماند در پایگاه‌داده بنویسید و در هر درخواست فقط بخش لازمش را بخوانید. این تفاوت زمینه با حافظه است؛ در حافظه‌ی ایجنت مفصل‌تر آمده.

اشتباه‌های رایج

• بریدن کور از ابتدای تاریخچه. اگر system prompt یا جفت tool_use و tool_result را وسط ببرید، درخواست از نظر ساختاری نامعتبر می‌شود یا مدل بی‌دلیل گیج می‌شود. برش باید ساختار پیام‌ها را بشناسد.
• شمردن کاراکتر به‌جای توکن. قاعده‌ی سرانگشتی «هر چهار کاراکتر یک توکن» برای انگلیسی است. متن فارسی به‌ازای همان معنا توکن بیشتری مصرف می‌کند؛ حتماً با ابزار شمارش توکن اندازه بگیرید. جزئیات در نوشته‌ی مربوط به هزینه و توکن آمده.
• فراموش‌کردن max_tokens در بودجه. پنجره سقف ورودی نیست، سقف ورودی به‌علاوه‌ی خروجی است.
• ریختن کل schema پایگاه‌داده یا کل فهرست ابزارها در هر درخواست. ابزارها را بر اساس مرحله‌ی کار فیلتر کنید.
• عوض‌کردن ابتدای زمینه در هر درخواست. گذاشتن timestamp یا شناسه‌ی نشست در ابتدای system prompt باعث می‌شود prompt caching هرگز کار نکند.

زمینه را بودجه‌بندی کنید

مثل حافظه در یک سیستم embedded با آن رفتار کنید: هر بخش سقف مشخص و مکتوب داشته باشد.

اعداد بالا نمونه‌اند، نه نسخه؛ عددهای خودتان را از داده‌ی واقعی دربیاورید. قاعده این است که هر بخش وقتی از سقفش رد شد، خودش کوچک شود — نه اینکه بخش‌های دیگر را بیرون بیندازد. و در لاگ هر درخواست، مصرف واقعی هر بخش را ثبت کنید. تقریباً همیشه معلوم می‌شود یک منبع مشخص — معمولاً خروجی یک ابزار پرحرف — مسئول بیشتر رشد است. حل همان یک مورد از هر تغییر مدلی مؤثرتر است.