پنجرهٔ متن از ۴ هزار به یک میلیون رسید — این یعنی چه؟

چند سال پیش، بزرگ‌ترین متنی که می‌شد یک‌جا به یک مدل زبانی داد حدود چهار هزار توکن بود — تقریباً به اندازهٔ یک مقالهٔ کوتاه. امروز مدل‌هایی هستند که بیش از یک میلیون توکن را در یک درخواست می‌پذیرند.

این تغییر در مقیاس، از آن دست تغییرهایی است که فقط یک عدد روی برگهٔ مشخصات به نظر می‌رسد ولی عملاً تعیین می‌کند چه کارهایی با این ابزارها ممکن است. و چون عدد بزرگ است، بیشتر از چیزی که واقعاً می‌گوید برداشت می‌شود.

این نوشته توضیح می‌دهد پنجرهٔ متن دقیقاً چیست، چرا با حافظه اشتباه گرفته می‌شود، و بزرگ‌شدنش چه چیزی را حل کرده و چه چیزی را نه.

پنجرهٔ متن چیست

پنجرهٔ متن، بیشترین مقدار متنی است که مدل می‌تواند در یک درخواست هم‌زمان ببیند. همه‌چیز در همین یک سقف جا می‌شود:

• دستورالعمل سیستمی
• تاریخچهٔ گفتگو تا این لحظه
• سند یا کدی که پیوست کرده‌اید
• و جایی برای خودِ پاسخ

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

تشبیه نزدیک، میز کار است نه کتابخانه: هرچه روی میز باشد در دسترس فوری است، ولی میز اندازه‌ای دارد و هر بار که سر کار می‌نشینید، خالی است.

چرا حافظه نیست

این رایج‌ترین سوءتفاهم است، و منشأ بیشتر رفتارهای «عجیب» مدل‌هاست.

مدل بین دو درخواست چیزی به یاد نمی‌آورد. اگر در گفتگویی طولانی احساس می‌کنید مدل حرف‌های قبلی را «یادش هست»، به این دلیل است که برنامه‌ای که با آن کار می‌کنید، تمام تاریخچه را دوباره در هر درخواست می‌فرستد.

پنجرهٔ بزرگ‌تر یعنی می‌توانید تاریخچهٔ بلندتری را دوباره بفرستید. یعنی مدل بیشتر یادش می‌ماند، نه.

دو نتیجهٔ عملی از این حرف درمی‌آید. اول اینکه در یک گفتگوی طولانی، هزینهٔ هر پیام از پیام قبلی بیشتر است، چون هر بار متن بیشتری فرستاده می‌شود. دوم اینکه وقتی گفتگو از سقف پنجره رد شود، چیزی باید حذف شود — و معمولاً قدیمی‌ترین پیام‌ها حذف می‌شوند. اگر مدل ناگهان چیزی را که اول گفتگو گفته بودید «فراموش کرد»، احتمالاً دقیقاً همین اتفاق افتاده است.

چرا این‌قدر بزرگ شد

مانع اصلی هزینهٔ محاسبات بود. در معماری‌های رایج، کار لازم برای پردازش متن با طول آن به‌صورت خطی رشد نمی‌کند؛ سریع‌تر رشد می‌کند. دو برابر کردن طول متن، بیشتر از دو برابر کار می‌برد.

چیزی که در چند سال گذشته عوض شد، عمدتاً مهندسی بود: روش‌های کارآمدتر برای همان محاسبه، بهتر استفاده‌کردن از حافظهٔ کارت گرافیک، و تغییراتی در نحوهٔ نگهداری وضعیت میانی. نتیجه این شد که پنجره‌هایی که زمانی غیراقتصادی بودند، عملی شدند.

چه چیزی را واقعاً حل کرد

پنجره‌های بزرگ چند کار را که قبلاً دردسر داشتند، ساده کردند:

• کار روی یک سند بلند به‌صورت یکپارچه. یک قرارداد، یک گزارش، یک پایان‌نامه — بدون اینکه لازم باشد تکه‌تکه شود و بعد تکه‌ها به هم دوخته شوند.
• دیدن یک پروژهٔ کد در کل. به‌جای پرسیدن دربارهٔ یک فایل، می‌شود دربارهٔ رابطهٔ چند فایل با هم پرسید.
• گفتگوهای طولانی بدون خلاصه‌سازی مداوم. قبلاً باید هر چند پیام یک بار تاریخچه را خلاصه می‌کردید و در همان خلاصه‌سازی چیزهایی از دست می‌رفت.

این‌ها دستاوردهای واقعی‌اند. اشتباه وقتی پیش می‌آید که از این نتیجه بگیریم مسئلهٔ «متن بلند» به‌طور کامل حل شده است.

---

سه چیزی که حل نکرد

۱. هرچه در پنجره باشد، به یک اندازه دیده نمی‌شود

یافته‌ای که در پژوهش‌های متعدد تکرار شده این است که مدل‌ها اطلاعات ابتدای متن و انتهای متن را بهتر از میانهٔ آن بازیابی می‌کنند. اصطلاح رایجش «گم‌شدن در میانه» است.

یعنی گذاشتن یک سند پانصد صفحه‌ای در پنجره تضمین نمی‌کند که جمله‌ای در صفحهٔ ۲۴۰ به‌درستی پیدا شود. متن آنجا هست؛ اینکه با همان دقتِ ابتدای متن استفاده شود، چیز دیگری است.

نتیجهٔ عملی ساده است: مهم‌ترین بخش را نزدیک ابتدا یا انتها بگذارید، نه وسط. و اگر پاسخ درست برایتان حیاتی است، به بزرگی پنجره تکیه نکنید.

۲. متنی که می‌فرستید، هزینه دارد — هر بار

پنجرهٔ یک میلیونی به این معنا نیست که پر کردنش رایگان است. توکن ورودی هم قیمت دارد، و در هر درخواست از نو حساب می‌شود.

برنامه‌ای که در هر تماس یک سند بزرگ را کامل می‌فرستد، دارد بابت همان سند بارها و بارها پول می‌دهد. این یکی از آن جاهایی است که تفاوت بین «ممکن است» و «عاقلانه است» زیاد می‌شود.

۳. متن بلندتر، پاسخ کندتر

پیش از آنکه اولین کلمهٔ پاسخ برسد، مدل باید کل ورودی را پردازش کند. هرچه ورودی بلندتر باشد، این مکث ابتدایی طولانی‌تر است.

برای یک کار پس‌زمینه‌ای مهم نیست. برای چیزی که کاربر پشتش منتظر نشسته، کاملاً مهم است.

پس بازیابی مُرد؟

وقتی پنجره‌ها بزرگ شدند، این پیش‌بینی زیاد شنیده شد که دیگر لازم نیست دنبال تکه‌های مرتبط بگردیم — کل مخزن را می‌فرستیم و تمام.

در عمل این‌طور نشد، و دلیلش هر سه مورد بالاست. فرستادن ده هزار صفحه در هر درخواست هم گران است، هم کند، هم لزوماً دقیق‌تر از فرستادن ده صفحهٔ درست نیست.

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

یک نکته که مخصوص فارسی است

عدد پنجره همیشه بر حسب توکن اعلام می‌شود، نه کلمه و نه صفحه. و متن فارسی به‌ازای هر کلمه معمولاً به توکن‌های بیشتری شکسته می‌شود تا متن انگلیسی.

نتیجهٔ مستقیمش این است که یک پنجرهٔ مشخص، متن فارسی کمتری از متن انگلیسی جا می‌دهد. اگر برآوردتان را از روی تجربهٔ متن انگلیسی ساخته‌اید، برای فارسی محتاطانه‌تر حساب کنید.

این تفاوت بین خانواده‌های مدل هم یکسان نیست، چون هر کدام توکنایزر خودش را دارد. اگر متن بلند فارسی کار اصلی شماست، همین یک عامل می‌تواند در انتخاب مدل تعیین‌کننده باشد — بیشتر از عددی که روی برگهٔ مشخصات نوشته شده.

جمع‌بندی

پنجرهٔ متن سقف یک درخواست است، نه حافظهٔ مدل. بزرگ‌شدنش کارهای واقعی را ممکن کرده، ولی سه چیز را عوض نکرده: اطلاعات وسط متن هنوز کمتر قابل اتکاست، هر توکن ورودی هنوز هزینه دارد، و ورودی بلندتر هنوز کندتر است.

پس عدد بزرگ را به‌عنوان «سقف چیزی که ممکن است» بخوانید، نه «مقداری که باید پر شود».

اندازهٔ پنجرهٔ هر مدل، همراه با قیمت ورودی و خروجی‌اش، در صفحهٔ «مدل‌ها» به‌روز نگه داشته می‌شود.