اگر امروز از مدل‌هایی با پنجرهٔ متنی ۱۲۸ هزار توکنی مانند GPT-4 Turbo استفاده می‌کنید، احتمالاً متوجه شده‌اید که دستیار شما دستورات حیاتی را حتی پس از چند دقیقه فراموش می‌کند. این اتفاق به این دلیل رخ می‌دهد که سقف تبلیغاتی توکن‌ها، هرگز تضمین‌کنندهٔ بازیابی کامل اطلاعات نیست و بیشتر یک سقف تئوریک است تا یک ضمانت برای یادآوری بی‌نقص. این تضاد میان ظرفیت اعلام‌شده و کیفیت واقعی خروجی، ریشه در شکافی دارد که در تحلیل‌های پیشین ما دربارهٔ دروغ‌های پنجره‌های متنی بررسی شد.
در پوشش پیشین ما از چالش‌های اجرای عامل‌های هوش مصنوعی، دیدیم که زیرساخت‌های زمان‌بندی (Runtime) اغلب از خودِ مدل مهم‌تر هستند؛ درک سازوکار پنجرهٔ زمینه دقیقاً توضیح می‌دهد چرا این عامل‌ها در مقیاس واقعی شکست می‌خورند. تصور کنید دستور پخت غذایی را روی یک صفحهٔ نمایش بسیار کوچک می‌خوانید؛ شما در هر لحظه فقط چند خط را می‌بینید و برای دیدن بقیه باید اسکرول کنید، اما هرگز نمی‌توانید کل سند را یک‌باره در ذهن داشته باشید. این ناحیهٔ قابل مشاهده، دقیقاً همان نحوهٔ عملکرد حافظهٔ کاری یک مدل زبانی است.
سازوکار حافظهٔ کاری
مدل‌های زبانی متن را به قطعاتی به نام توکن (Token) پردازش می‌کنند که معمولاً تکه‌هایی از یک کلمه هستند. یک توکن لزوماً یک کلمه کامل نیست، بلکه قطعه‌ای کوچک از متن است. طبق مستندات فنی، در زبان انگلیسی به‌طور متوسط هر کلمه معادل ۱.۳ توکن است.
پنجرهٔ زمینه (Context Window) حداکثر تعداد توکن‌هایی است که مدل می‌تواند در یک لحظه «ببیند». این ظرفیت شامل پرامپت سیستمی، تاریخچهٔ چت و خروجی‌های خودِ مدل است. هر پیام شما و هر کلمه‌ای که مدل تولید می‌کند، توکن‌هایی را از این پنجرهٔ محدود مصرف می‌کند.
وقتی این پنجره پر شود، مدل از روش «برش» (Truncation) استفاده می‌کند؛ یعنی قدیمی‌ترین اطلاعات را حذف می‌کند تا برای توکن‌های جدید جا باز کند. برای مثال، اگر یک دستور پخت ۱۰ هزار توکن باشد اما پنجرهٔ مدل تنها ۴ هزار توکن باشد، مدل فقط ۴ هزار توکن اول (یا ۴ هزار توکن آخر، بسته به نوع برش) را می‌خواند. در نتیجه، هرگونه جزئیات حیاتی مانند دمای پخت که در انتهای متن قرار دارد، به‌سادگی نادیده گرفته می‌شود.
برای جلوگیری از بازخوانی کل گفتگو در هر بار تولید یک کلمهٔ جدید، مدل‌ها از KV Cache (حافظهٔ کلید-مقدار) استفاده می‌کنند. این حافظه مانند یک یادداشت‌بردار دیجیتال است که در مرحلهٔ پیش‌پُرکردن (Prefill)، نکات کلیدی هر جمله را ثبت می‌کند.
در طول این مرحلهٔ پیش‌پُرکردن، مدل هر توکن را پردازش کرده و برای هر توکن در هر لایه، دو بردار ذخیره می‌کند: یک «کلید» (Key) و یک «مقدار» (Value). این بردارها ثبت می‌کنند که توکن چه معنایی دارد و چگونه با سایر توکن‌ها در ارتباط است. پس از اتمام پیش‌پُرکردن، مدل مجموعه‌ای کامل از یادداشت‌ها برای کل ورودی در اختیار دارد.
پس از اتمام پیش‌پُرکردن، مدل برای تولید کلمهٔ بعدی فقط نیاز دارد به این یادداشت‌های ذخیره‌شده و آخرین توکن ارجاع دهد. مدل دیگر کل تاریخچه را دوباره پردازش نمی‌کند. همین سازوکار است که باعث می‌شود اولین توکن پاسخ معمولاً دیرتر از کلمات بعدی ظاهر شود.
حافظهٔ KV Cache با هر توکن جدید رشد می‌کند و در حافظهٔ واحد پردازش گرافیکی (GPU) جای می‌گیرد. در مدل‌هایی با لایه‌ها و سرهای (Heads) زیاد، حجم این حافظه می‌تواند به‌راحتی از حجم خودِ وزن‌های مدل بیشتر شود.
دیوار هزینه‌های درجه‌دوم
محدودیت فیزیکی سخت‌گیرانه‌ای برای این پنجره‌ها وجود دارد که ریشه در مکانیزم توجه (Attention) دارد. مکانیزم توجه به هر توکن اجازه می‌دهد تا به تمام توکن‌های دیگر نگاه کند تا تصمیم بگیرد چه چیزی مهم است. این یعنی هر توکن باید با تک‌تک توکن‌های دیگر مقایسه شود تا میزان ارتباط آن‌ها تعیین گردد.
بر اساس پژوهش بنیادین «Attention Is All You Need»، این فرآیند منجر به رشد درجه‌دوم (Quadratic) محاسبات می‌شود. هزینهٔ مکانیزم توجه به‌صورت درجه‌دوم با طول توالی مقیاس می‌شود. برای یک پنجرهٔ ۴ هزار توکنی، مدل در هر لایه ۱۶ میلیون مقایسه جفتی انجام می‌دهد که حدود ۰.۵ گیگابایت حافظه می‌طلبد و اجازه می‌دهد پیش‌پُرکردن سریع انجام شود.
اما اگر این پنجره را دو برابر کرده و به ۸ هزار توکن برسانیم، تعداد مقایسه‌ها چهار برابر شده و به ۶۴ میلیون می‌رسد. در مقیاس ۱۲۸ هزار توکن، بار محاسباتی به ۱۶ میلیارد مقایسه در هر لایه می‌رسد. این حجم از محاسبات نیازمند صدها گیگابایت حافظهٔ GPU تنها برای نگهداری KV Cache است که اغلب از اندازهٔ وزن‌های خودِ مدل فراتر می‌رود و منجر به کند شدن شدید مرحلهٔ پیش‌پُرکردن می‌شود.
در مثال دستور پخت، اگر مجبور بودید هر مادهٔ اولیه را با تمام مواد دیگر مقایسه کنید تا دستور را بفهمید، یک دستور پخت طولانی به‌شدت کند و غیرممکن می‌شد. پنجرهٔ زمینه در واقع راه مدل برای گفتن این است که: «من فقط می‌توانم این تعداد مقایسه را به‌طور هم‌زمان مدیریت کنم.»
چرا گفتگوهای طولانی «عجیب» می‌شوند؟
حتی زمانی که حافظهٔ کافی در دسترس باشد، دو پدیدهٔ اصلی باعث تخریب عملکرد مدل می‌شوند. نخست، اثر «گم‌شدن در میانه» (Lost in the Middle) است. پژوهش‌ها نشان می‌دهند مدل‌ها دچار سوگیری ابتدا (Primacy Bias) و سوگیری انتها (Recency Bias) هستند:
- سوگیری ابتدا: مدل توجه زیادی به ابتدای زمینه دارد (حدود ۴۰٪).
- سوگیری انتها: مدل توجه زیادی به انتهای زمینه دارد (حدود ۴۰٪).
- شکاف میانی: ناحیهٔ میانی به‌طور قابل‌توجهی وزن کمتری دریافت می‌کند (حدود ۲۰٪).
اگر یک جزئیات حیاتی در وسط یک پرامپت طولانی دفن شود، مدل اغلب آن را نادیده می‌گیرد. در یک گفتگوی ۵۰ مرحله‌ای، اگر سوالی بپرسید که به چیزی در ۲۰ مرحلهٔ قبل (که اکنون در وسط پنجره قرار دارد) وابسته باشد، احتمالاً پاسخ اشتباهی دریافت می‌کنید چون مدل به آن ناحیه وزن کافی نمی‌دهد.
دومین مشکل، شکاف میان داده‌های آموزش و محدودیت‌های API است. برای مثال، مدل Llama 3 روی توالی‌های ۸,۱۹۲ توکنی آموزش دیده است. وقتی از طریق API آن را به ۳۲,۰۰۰ توکن فشار می‌دهیم، رمزگذاری‌های موقعیتی (Positional Encodings) — که ترتیب کلمات را به مدل می‌گویند — غیرقابل‌اعتماد می‌شوند.
از آنجا که مدل هرگز یاد نگرفته است موقعیت‌هایی به این دوری را مدیریت کند، پیش‌بینی‌هایش افت می‌کند. این اتفاق حتی اگر GPU حافظهٔ زیادی داشته باشد، رخ می‌دهد. در اپلیکیشن‌های چندمرحله‌ای حالت‌دار (Stateful) که KV Cache را بین مراحل بازیافت می‌کنند، حافظه به‌طور یکنواخت رشد می‌کند. به محض اینکه از طول زمینهٔ آموزشی فراتر رود، کیفیت به‌شدت افت می‌کند.
در این حالت، دستیار ممکن است شروع به تکرار خود کند، با گفته‌های قبلی‌اش تناقض ایجاد کند یا واقعیت‌ها را ابداع کند. به همین دلیل است که گفتگوهای طولانی بسیار زودتر از رسیدن به سقف توکن‌های تبلیغاتی، «عجیب» می‌شوند.
مدیریت شکاف حافظه
توسعه‌دهندگان برای مبارزه با این محدودیت‌ها از استراتژی‌های مختلفی استفاده می‌کنند. ساده‌ترین روش، برش (Truncation) است که فقط N توکن اخیر را نگه می‌دارد، هرچند این کار تمام زمینهٔ اولیه را پاک می‌کند. این دقیقاً مانند اسکرول کردن صفحهٔ گوشی است تا همیشه فقط چند خط آخر را ببینید.
روش پیشرفته‌تر، تولید بازیابی‌افزا (RAG) است. به‌جای ریختن کل یک پایگاه دانش در پنجرهٔ متنی، سیستم فقط مرتبط‌ترین اسناد را جست‌وجو کرده و آن‌ها را در پرامپت درج می‌کند. این کار پنجرهٔ متنی را کوچک و متمرکز نگه داشته و نویز و هزینهٔ محاسباتی را کاهش می‌دهد.
برخی سیستم‌ها سعی می‌کنند با استفاده از ماژول‌های یادگیرنده که حافظه‌های طولانی را به خلاصه‌هایی با اندازهٔ ثابت تبدیل می‌کنند، KV Cache را فشرده کنند. این کار شبیه نوشتن یک خلاصهٔ یک پاراگرافی از یک دستور پخت به‌جای نگه داشتن تمام خطوط است. با این حال، این روش‌ها اغلب شکست می‌خورند زیرا حذف توکن‌ها از وسط متن، حس مدل از ترتیب کلمات را به‌هم می‌زند.
بسیاری از استراتژی‌های فشرده‌سازی شکست می‌خورند چون موقعیت‌های نسبی را که مدل‌هایی مانند Llama 3 به آن‌ها متکی هستند، به‌هم می‌ریزند. مستحکم‌ترین استراتژی فعلی، حفظ یک بلوک متصل از تاریخچهٔ اخیر و در عین حال خلاصه‌سازی یا حذف گذشتهٔ دور است. این کار یکپارچگی موقعیتی لازم برای حفظ انسجام پاسخ‌ها را فراهم می‌کند. برای مقابله با این فراموشی‌های ساختاری، رویکردهایی مانند دسته‌بندی داده‌ها در سیستم Favur برای حفظ اطلاعات حیاتی پیشنهاد شده است.
خلاصه ویژگی‌های زمینه
برای درک بهتر موازنات، این بنچمارک‌های فنی را بررسی کنید:
- طول‌های رایج زمینه: ۴ هزار (GPT-3.5)، ۱۲۸ هزار (GPT-4 Turbo)، ۱ میلیون (Gemini 1.5 Pro).
- پیچیدگی توجه: O(n²) برای توجه کامل.
- حافظه KV Cache (در حالت FP16): محاسبه می‌شود به صورت: ۲ × تعداد لایه‌ها × تعداد سرها × ابعاد هر سر × ۲ بایت به ازای هر توکن.
- محدودیت مؤثر در برابر معماری: محدودیت معماری، حداکثر فیزیکی است؛ اما محدودیت مؤثر جایی است که کیفیت پاسخ‌ها همچنان قابل قبول باقی بماند. محدودیت مؤثر اغلب بسیار کمتر از سقف معماری است.
این تغییر در درک ما به این معناست که «بزرگ‌تر» همیشه «بهتر» نیست. یک پنجرهٔ زمینهٔ عظیم می‌تواند توجه مدل را پراکنده کرده و تأخیر (Latency) را افزایش دهد، بدون اینکه واقعاً توانایی مدل در استدلال روی داده‌ها را بهبود ببخشد.
برای توسعه‌دهندگان، این بدان معناست که حد زمینهٔ «مؤثر» تقریباً همیشه کمتر از حد «معماری» تبلیغ‌شده توسط ارائه‌دهنده است. برای عیب‌یابی یک بات شکست‌خورده، تعداد کل توکن‌ها را بررسی کنید. اگر کیفیت پس از یک آستانهٔ خاص افت می‌کند، سعی کنید دستورات حیاتی را به انتهای پرامپت منتقل کنید تا از سوگیری انتها بهره ببرید.
اگر مشکل همچنان باقی بود، یک مرحلهٔ خلاصه‌سازی پیاده کنید که گفتگوهای قدیمی‌تر را پیش از رشد بیش از حد حافظه، به یک چکیدهٔ کوتاه تبدیل کند. همچنین منتظر ظهور معماری‌های «توجه خطی» (Linear Attention) یا ماژول‌های حافظهٔ خارجی باشید، زیرا این‌ها تنها راه‌های واقعی برای شکستن دیوار هزینه‌های درجه‌دوم در طراحی فعلی ترنسفورمرها هستند. در این راستا، نبرد میان ذخیره‌سازهای معنایی و حافظه‌های خطی به یکی از محورهای اصلی برای حل مشکل حفظ دستورات اولیه تبدیل شده است.
گام بعدی شما
- اگر بات شما در گفتگوهای طولانی دچار توهم می‌شود، دستورات حیاتی را به انتهای پرامپت منتقل کنید تا از سوگیری انتها بهره ببرید.
- برای کاهش هزینه و افزایش دقت، به‌جای افزایش پنجرهٔ متنی، پیاده‌سازی RAG را جایگزین کنید.
- در اپلیکیشن‌های چندمرحله‌ای، یک لایه خلاصه‌سازی (Summarization) اضافه کنید تا تاریخچهٔ قدیمی پیش از رشد بیش از حد حافظه، فشرده شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو