شبیه‌سازی حافظه در چت‌بات‌ها؛ واقعیت بی‌حافظه در مدل‌های زبانی بزرگ

هنگامی که یک توسعه‌دهنده سؤالی تکمیلی را به اندپوینت Chat Completions شرکت OpenAI ارسال می‌کند، سیستم به سراغ یک نشست ذخیره‌شده نمی‌رود تا ببیند چند لحظه پیش چه گفته شده است. مدل‌های زبانی بزرگِ زیربنایی، کاملاً بدون حالت (Stateless) هستند؛ یعنی به محض تولید یک پاسخ، حتی یک بایت حافظه درباره درخواست‌های قبلی کاربر نگه نمی‌دارند.[1]

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

این سازوکار در مستندات رابط برنامه‌نویسی کاربردی (API) ارائه‌دهندگان بزرگ هوش مصنوعی کاملاً مشهود است. مستندات رسمی شرکت Anthropic برای Messages API این قاعده را صریحاً توضیح می‌دهد: «Messages API بدون حالت است، یعنی شما باید همواره کل تاریخچه مکالمه را به API بفرستید.» سرور هیچ سابقه‌ای از تبادل اطلاعات را برای دور بعدی نگه نمی‌دارد.

به جای ذخیره داده در سرور، برنامه یک آرایه ساختاریافته شامل تاریخچه زمانی گفتگو را ارسال می‌کند که بر اساس گوینده مرتب شده است. این سیستم با تزریق خروجی‌های قبلی خودِ مدل در کنار ورودی‌های گذشته کاربر، زمینه و بافت لازم را مهیا می‌سازد تا مدل بتواند درست مثل یک انسان به سؤالات بعدی پاسخ دهد.[1]

این آرایه دارای فرمت‌بندی دقیقی است تا منبع هر بلوک متنی به تفکیک مشخص شود. یک بسته داده‌ای معمولاً با یک «پیام سیستم» (system message) شروع می‌شود که قوانین بنیادین و شخصیت هوش مصنوعی را تعیین می‌کند. سپس پیام‌های متناوب کاربر شامل درخواست‌های فرد، و پیام‌های دستیار شامل پاسخ‌های قبلی مدل در ادامه قرار می‌گیرند.[1]

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

معماری فراموشی

این ماهیت بدون حالت بودن یک باگ نرم‌افزاری نیست، بلکه ویژگی ذاتی معماری ترنسفورمر (Transformer) به شمار می‌رود. ترنسفورمر که در مقاله جریان‌ساز سال ۲۰۱۷ پژوهشگران گوگل با عنوان «تنها توجه نیاز است» (Attention Is All You Need) معرفی شد، برای رفع گلوگاه‌های طراحی‌های قبلی هوش مصنوعی شکل گرفت و آگاهانه مفهوم حافظه درونی را کنار گذاشت.[2]

پیش از سال ۲۰۱۷، وظایف پردازش توالی مانند ترجمه به شبکه‌های عصبی بازگشتی (RNN) یا شبکه‌های حافظه کوتاه‌مدت طولانی (LSTM) متکی بودند. این معماری‌های قدیمی‌تر، متن را کلمه به کلمه پردازش می‌کردند و با به‌روزرسانی بردار وضعیت پنهان، نوعی حافظه متحرک می‌ساختند؛ اما از آنجا که گام دوم به گام اول وابسته بود، پردازش موازی روی سخت‌افزارهای مدرن ناممکن می‌شد.[2]

تیم گوگل برین (Google Brain) آن حافظه ترتیبی را با سازوکار خودتوجهی (Self-Attention) جایگزین کرد. همان‌طور که آشیش واسوانی و همکارانش نوشتند، ترنسفورمر «منحصراً بر مکانیسم‌های توجه تکیه می‌کند و نیاز به بازگشت و کانولوشن را به‌طور کامل از بین می‌برد». این جهش به مدل امکان داد تمام کلمات یک توالی را هم‌زمان پردازش کند و سرعت آموزش مدل‌ها را به شکلی باورنکردنی ارتقا دهد.[2]

اما کنار گذاشتن خاصیت بازگشتی به معنای چشم‌پوشی از نگهداری وضعیت پنهان بود. ترنسفورمر یک بلوک متنی را در قالب یک تصویر ایستا و منفرد ارزیابی می‌کند؛ هیچ مکانیسمی برای انتقال وضعیت پنهان از یک فراخوانی API به فراخوانی بعدی وجود ندارد و هر درخواست استنتاج، یک رویداد ریاضیاتی کاملاً مجزا و مستقل محسوب می‌شود.[2]

افزون بر این، وزن‌های عصبی یک مدل زبانیِ مستقر کاملاً ثابت (منجمد) هستند. وقتی کاربر نام خود را به یک چت‌بات می‌گوید، مدل میلیاردها پارامتر خود را برای یادگیری این داده جدید تغییر نمی‌دهد. تنها راهی که مدل می‌تواند در نوبت بعدی نام کاربر را به یاد آورد این است که برنامه واسط صراحتاً آن را در درخواست تازه بگنجاند.[3]

هزینه پنهان گفتگو

این مکانیسم الصاق رونوشت گفتگو، حقیقتی پنهان در محاسبات استنتاج هوش مصنوعی پدید می‌آورد: هزینه محاسباتی گفتگوهای خطی با نرخ درجه دوم (توان دو) رشد می‌کند. از آنجا که کل تاریخچه هر بار مجدداً ارسال می‌شود، تعداد توکن‌هایی که مدل باید پردازش کند در هر تبادل بیشتر می‌شود؛ یعنی درحالی‌که کاربر متنی با حجم ثابت می‌نویسد، سرور کار سنگین‌تری انجام می‌دهد.[3]

یک چت‌بات معمول خدمات پشتیبانی را در نظر بگیرید که در آن کاربر و هوش مصنوعی در هر نوبت دقیقاً ۵۰ توکن متن رد و بدل می‌کنند. در دور اول، کاربر ۵۰ توکن ارسال می‌کند و مدل آن‌ها را پردازش کرده و پاسخی می‌سازد؛ هزینه ورودی اندک است و تاخیر پاسخگویی تقریباً به صفر میل می‌کند.[3]

اما در بیستمین دور همان گفتگو، محاسبات به شدت دگرگون می‌شود. برنامه باید ۱۹ تبادل قبلی را که شامل ۱۹۰۰ توکن است، همراه با پیام جدیدِ ۵۰ توکنی کاربر بفرستد. اکنون مدل باید ۱۹۵۰ توکن ورودی را بخواند و پردازش کند، پیش از آنکه حتی بتواند یک کلمه پاسخ تولید کند.[3]

این یعنی دور بیستم به تقریباً ۲۰ برابر قدرت پردازشی ورودیِ بیشتری نسبت به دور اول نیاز دارد. اگر این گفتگو تا ۱۰۰ دور ادامه یابد، مدل در هر بار درخواست نزدیک به ۱۰ هزار توکن را بازخوانی می‌کند؛ بنابراین برای توسعه‌دهندگانی که بر اساس تعداد توکن‌ها هزینه می‌پردازند، حفظ یک گفتگوی طولانی هزینه‌های سرسام‌آوری به بار می‌آورد.[3]

مدیریت سهمیه توکن‌ها

همین مقیاس‌پذیری درجه دوم مشخص می‌کند که چرا ارائه‌دهندگان API صورت‌حساب توکن‌های ورودی و خروجی را جدا می‌کنند. OpenAI برای مدل GPT-4o-mini خود در حال حاضر ۰٫۱۵ دلار به ازای هر میلیون توکن ورودی دریافت می‌کند، در حالی که قیمت توکن‌های خروجی ۰٫۶۰ دلار به ازای هر میلیون است. قیمت ورودی تعمداً پایین نگه داشته شده زیرا توسعه‌دهندگان ناچارند برای توکن‌های تاریخی بارها و بارها پول بپردازند.[1]

این ساختار قیمت‌گذاری، طراحان نرم‌افزار را وادار می‌کند تا میان آگاهی از بافتار گفتگو و هزینه‌های عملیاتی دست به مصالحه‌های سختی بزنند. یک دستیار کدنویسی که کل مخزن کد پروژه را در پیام سیستم جا می‌دهد، پاسخ‌های بسیار دقیقی ارائه خواهد داد؛ اما در ازای هر سؤالی که کاربر بپرسد، هزینه سرسام‌آوری روی دست توسعه‌دهنده می‌گذارد.[3]

توسعه‌دهندگان برای کنترل این مخارج معمولاً از بازیابی افزوده تولید (RAG) استفاده می‌کنند. در این روش، به جای چسباندن یک سند طولانی و ایستا به هر دور، برنامه یک پایگاه‌داده برداری را جستجو می‌کند تا فقط مرتبط‌ترین پاراگراف‌ها را بیابد؛ سپس صرفاً همان چند بخش منتخب را به آرایه ورودی تزریق می‌کند تا با حفظ توکن‌ها در سطحی پایین، زمینه لازم تأمین شود.[3]

برخورد با سقف پنجره بافت

این انباشت پیوسته توکن‌ها در نهایت به سد پنجره بافت (Context Window) برخورد می‌کند. پنجره بافت همان سقف سخت‌افزاری و معماری است که حداکثر حجم متن قابل پردازش در یک گذر توسط ترنسفورمر را تعیین می‌کند؛ اگرچه مدل‌های نخستین به ۱۰۲۴ توکن محدود بودند، اما غول‌های پیشتاز امروزی از ظرفیت‌های بسیار بزرگی بهره می‌برند.[3]

مدل Gemini 1.5 Pro گوگل از پنجره بافتی تا سقف ۲ میلیون توکن پشتیبانی می‌کند و Claude 3.5 Sonnet شرکت آنتروپیک ظرفیتی معادل ۲۰۰ هزار توکن دارد. با این حال، حتی این پنجره‌های فراخ نیز پایان‌پذیرند؛ وقتی رونوشت یک گفتگو از حد معین فراتر رود، برنامه باید پیش از آنکه API با پیام خطا روبرو شود، وارد عمل شود.[3]

توسعه‌دهندگان برای جلوگیری از وقوع خطا از راهبردهای کوتاه‌سازی استفاده می‌کنند. رایج‌ترین روش «پنجره لغزان» است که در آن، به محض نزدیک شدن تعداد توکن‌ها به سقف تعیین‌شده، برنامه قدیمی‌ترین پیام‌ها را از ابتدای آرایه حذف می‌کند. مدل همچنان پیام‌های اخیر را دریافت می‌کند، اما نقطه آغازین گفتگو برای همیشه از دسترس آن پاک می‌شود.[3]

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

برنامه‌های پیشرفته‌تر برای حفظ پیوستگی متن، از خلاصه‌سازی بهره می‌گیرند. در این شیوه، به جای حذف کامل نوبت‌های ابتدایی، یک فرآیند پس‌زمینه ۵۰ پیام اول را به مدلی کوچک‌تر می‌فرستد تا خلاصه کوتاهی از آن‌ها آماده کند. سپس این چکیده در پیام سیستم تزریق می‌شود تا هزاران توکن در قالب یک بلوک فشرده نگهداری شوند.[3]

گلوگاه کش KV

در لایه‌های عمیق‌تر، بازخوانی پیاپی یک متن تکراری از نظر بار پردازشی بسیار ناکارآمد است. هنگامی که یک ترنسفورمر توالی توکن‌ها را تحلیل می‌کند، ماتریس‌های کلید (Key) و مقدار (Value) را برای هر کلمه حساب می‌نماید تا نسبت آن با سایر واژه‌ها مشخص شود؛ این محاسبات واسط که در حافظه سرور ذخیره می‌شوند، کش KV نام دارند.[3]

در یک API بدون حالت، سرور درست در همان لحظه‌ای که پاسخ تولید شد، کش KV را دور می‌اندازد. در نتیجه، وقتی کاربر پیام بعدی خود را ارسال می‌کند، سرور باید عین همان محاسبات را برای تاریخچه مکالمات از ابتدا تکرار کند؛ اقدامی که بخش بزرگی از توان پردازشی را برای متنی که ثانیه‌هایی قبل ارزیابی شده بود، تلف می‌کند.[3]

برای رفع این اتلاف منابع، تأمین‌کنندگان زیرساخت هوش مصنوعی اخیراً قابلیت کَش کردن پرامپت (Prompt Caching) را معرفی کرده‌اند. با نگهداری کش KV مکالمات اخیر در حافظه فعال سرور به مدت چند دقیقه، سیستم دیگر نیازی به محاسبه دوباره کل تاریخچه ندارد؛ اگر درخواست جدید با توکن‌های یکسانی شروع شود، سرور از محاسبات زائد صرف‌نظر می‌کند.[3]

شرکت Anthropic در اواسط سال ۲۰۲۶ امکان کَش پرامپت را برای مدل‌های Claude عرضه کرد و تخفیف‌های قابل‌توجهی برای توکن‌های ورودیِ خوانده‌شده از کش قائل شد. OpenAI نیز رویه‌ای مشابه در پیش گرفت و تخفیف‌های خودکاری برای پرامپت‌های طولانی در مدل‌های اخیر خود اعمال کرد تا جریمه مالی ناشی از چسباندن متن‌های تکراری کاهش یابد.[3]

با وجود این بهینه‌سازی‌ها در سمت سرور، قرارداد بنیادین API همچنان کاملاً بدون حالت است. توسعه‌دهنده نرم‌افزار ناچار است کل زنجیره زمانی را از بستر شبکه انتقال دهد و سرور تنها چک می‌کند که آیا اخیراً این توالی متن را خوانده است یا خیر؛ بار مدیریت تاریخچه همچنان بر دوش سیستم کاربری (کلاینت) باقی می‌ماند.[3]

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