تلخیص توکن‌محور در برابر بافرهای تاریخچه کامل برای بهینه‌سازی هزینه

تصور کنید هر پیام جدید در یک چت طولانی، صورت‌حساب پرداختی شما را به صورت تصاعدی بالا ببرد. اگر امروز از مدل‌های زبانی برای برنامه‌های چندمرحله‌ای استفاده می‌کنید، باید بدانید که یک تابع ساده به نام remember() می‌تواند هزینه ورودی در یک مکالمه ۵۰ مرحله‌ای را تقریباً ۲۵ برابر کاهش دهد.

بر اساس مستندات فنی منتشر شده در Google Colab، توسعه‌دهندگان می‌توانند بدون نیاز به پایگاه‌داده‌های برداری یا ابزارهای پیچیده مثل LangChain، انسجام گفتگو را حفظ کنند. شما حتی برای درک این مکانیسم به یک API Key نیاز ندارید؛ تنها یک محیط پایتون و حدود ۱۵ دقیقه زمان لازم است. این رویکرد از رشد نمایی هزینه‌های مرتبط با پنجرهٔ زمینه (Context Window) — که شبیه میز کاری است که جا برای چند ورق دارد، نه برای کل کتابخانه — جلوگیری می‌کند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی استراتژی‌های RAG و مدیریت داده‌ها اشاره کردیم، در آنجا بر جنبه‌های بازیابی شامل قطعه‌بندی (Chunking)، جاسازی‌ها (Embeddings) و شباهت کسینوسی (Cosine Similarity) تمرکز داشتیم. اما مدیریت حافظه در جلسات زنده، روی حالتی تمرکز دارد که در طول یک نشست فعال حفظ می‌شود. این دقیقاً همان نقطه‌ای است که در مصاحبه‌های مهندسی هوش مصنوعی پرسیده می‌شود: «چگونه در مکالمات طولانی، حافظه را بدون نابودی بودجه مدیریت می‌کنید؟»

چالش پنجرهٔ زمینه و تورم توکن‌ها

مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — حافظه ذاتی ندارند. هر فراخوانی مدل، فقط آنچه را می‌بیند که شما ارسال می‌کنید. اگر تاریخچه کامل گفتگو در هر مرحله ارسال شود، هزینه به صورت خطی رشد می‌کند. در این سناریو، توسعه‌دهنده هر بار کل تاریخچه را ارسال می‌کند: مرحله ۱ به مرحله ۲ منجر می‌شود و این روند تا مرحله ۵۰ ادامه می‌یابد.

طبق گزارشی که در ۱۵ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، استراتژی «بافر در زمینه» منجر به انفجار تعداد توکن‌ها (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک — می‌شود. برای اندازه‌گیری این موضوع، می‌توان ۵۰ مرحله چت را با یک حلقه ساده پایتون شبیه‌سازی کرد. با فرض اینکه توکن‌ها تقریباً ۳/۴ یک کلمه هستند (len(text.split()) / 0.75)، تفاوت هزینه‌ها آشکار می‌شود: در یک مکالمه شبیه‌سازی شده ۵۰ مرحله‌ای، هزینه مرحله پنجاهم تقریباً ۲۵ برابر بیشتر از مرحله دوم است؛ چون سیستم تمام تعاملات قبلی را دوباره به‌عنوان ورودی می‌فرستد. این یک مسئله اقتصاد واحد (Unit-economics) است، پیش از آنکه یک مشکل تجربه کاربری (UX) باشد.

مکانیسم فشرده‌سازی حافظه

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

• شمارش توکن‌ها: استفاده از یک روش اکتشافی (Heuristic) که در آن هر توکن تقریباً ۷۵ درصد یک کلمه است تا حجم تاریخچه فعلی نظارت شود.
• محرک آستانه: تعیین یک حد مشخص به نام SUMMARY_THRESHOLD. در حالی که در دنیای واقعی این آستانه بالاتر است، اما استفاده از یک مقدار کوچک (مثلاً ۴۰ توکن) در محیط Colab به توسعه‌دهندگان اجازه می‌دهد تا در یک بازه ۵۰ مرحله‌ای، چندین بار رویداد فشرده‌سازی را فعال کرده و تأثیر آن را مشاهده کنند.
• تلخیص گزینشی: به‌جای حذف ساده کلمات (Truncation)، تابع summarize() هدف اصلی کاربر و حقایق کلیدی را استخراج می‌کند. یک نسخه ابتدایی ممکن است از تطبیق رشته‌ای برای کلمات کلیدی مثل «برنامه» (plan) جهت استخراج واقعیت‌ها استفاده کند، در حالی که نسخه عملیاتی از یک فراخوانی واقعی LLM برای تلخیص بهره می‌برد.
• حلقه remember(): این تابع ابتدا پیام جدید کاربر را به گفتگو اضافه می‌کند. سپس بررسی می‌کند که آیا مجموع توکن‌ها (خلاصه + مکالمات جاری) از آستانه تعیین شده فراتر رفته است یا خیر. در صورت عبور از حد، تاریخچه مکالمه را به دو مرحله آخر کاهش داده و بقیه موارد را در قالب یک خلاصه ادغام (Fold) می‌کند.

حل مشکل «گم‌شدن در میانه»

نگهداری صرفِ N کلمه آخر کافی نیست. مدل‌ها از پدیده‌ای رنج می‌برند که به آن «گم‌شدن در میانه» (Lost in the Middle) می‌گویند؛ وضعیتی که در آن مدل‌ها ابتدا و انتهای یک پرامپت را بسیار قابل‌اعتمادتر از بخش مرکزی آن به خاطر می‌آورند. یک تلخیص ناقص (Lossy Summary) این مشکل را تشدید می‌کند و باعث می‌شود دستیار تصمیماتی که در میانه گفتگو گرفته شده را فراموش کند یا سوالاتی را که قبلاً پاسخ داده، دوباره بپرسد.

برای جلوگیری از این مورد و حفظ اثربخشی، یک خلاصه استوار باید صراحتاً چهار عنصر زیر را حفظ کند:
۱. هدف کلی کاربر: قصد اولیه و overarching goal از شروع چت.
۲. تصمیمات کلیدی: هر آنچه در طول تعامل تا کنون بر سر آن توافق یا تصمیم گرفته شده است.
۳. موارد باز: نکاتی که هنوز نیاز به حل یا پاسخ دارند و باز مانده‌اند.
۴. حقایق پایدار: اطلاعاتی مثل نام کاربر، ترجیحات اعلام شده یا سطح اشتراک (مثلاً «من روی طرح Enterprise هستم»).

نتایج عملکرد و هزینه

وقتی این منطق تلخیص روی آزمون ۵۰ مرحله‌ای اعمال شد، منحنی هزینه‌ها تخت شد. در آزمایش dev.to، هزینه مرحله پنجاهم از ۶۶۶ توکن (در حالت بافر خام) به تنها ۲۸ توکن با تابع remember() رسید.

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

حافظه رویدادی در برابر حافظه معنایی

پیاده‌سازی این سیستم، تفاوت دو نوع حافظه در هوش مصنوعی را آشکار می‌کند:

• حافظه رویدادی (Episodic Memory): این حافظه مربوط به وقایعی است که در طول مکالمه جاری رخ داده است. این داده‌ها در متغیرهای convo و summary ذخیره شده و معمولاً با پایان جلسه ریست می‌شوند.
• حافظه معنایی (Semantic Memory): این‌ها حقایق پایداری درباره کاربر هستند که بین جلسات مختلف باقی می‌مانند. در آزمایش Colab، این مورد را می‌توان با یک فایل user_memory.json شبیه‌سازی کرد. این حقایق در شروع هر اجرای جدید در یک جفت مکالمه تازه بارگذاری می‌شوند تا تجربه کاربر در بازدیدهای مکرر بی‌سینه و یکپارچه باشد.

چالش‌های محیط عملیاتی (Production)

با اینکه تابع remember() تنها حدود ۱۵ خط کد است، اما یک لایه حافظه در سطح صنعتی باید چندین مورد پیچیده را مدیریت کند:

• مسموم‌سازی زمینه (Context Poisoning): یک دستور غلط یا حقیقت اشتباه در مرحله اول می‌تواند از طریق هر تلخیص ترکیبی بعدی زنده بماند و کل جلسه را مسموم کند.
• سیگنال بازیابی (Retrieval Signal): هنگام استفاده از حافظه برداری خارجی، پرسش‌های تکمیلی مثل «یکی دیگر نشان بده» هیچ سیگنال بازیابی مستقلی ندارند. برای حل این مشکل، پرس‌وجو (Query) باید با خلاصه فعلی به‌علاوه چند مرحله آخر مکالمه تقویت شود.
• اعتبارسنجی قوانین (Rule Validation): اطمینان از اینکه تلخیص‌ها هرگز به‌طور تصادفی قوانین سیستمی را با محتوای تولید شده در نوبت‌های کاربر جایگزین نمی‌کنند.
• منطق ارتقا (Graduation Logic): تشخیص زمان تغییر استراتژی. توسعه‌دهندگان باید برای جلسات کوتاه از «بافر»، پس از عبور از چند هزار توکن از «تلخیص» و تنها برای جلساتی که ساعت‌ها یا روزها ادامه دارند از «بازیابی خارجی» استفاده کنند.

برای کسانی که برای مصاحبه‌های مهندسی AI آماده می‌شوند، درک این موازنه بین هزینه، توجه (Attention) و نوع حافظه، بسیار ارزشمندتر از حفظ کردن تعاریف است. توانایی توضیح نحوه به‌روزرسانی خلاصه (به این صورت که خلاصه قدیمی در جدید ادغام شود، نه اینکه جایگزین گردد)، ثابت می‌کند که توسعه‌دهنده تجربه مدیریت سیستم‌ها در مقیاس بالا را دارد.

گام بعدی شما

• در محیط Colab، آستانه تلخیص را تغییر دهید (مثلاً ۱۰۰ در برابر ۱۰۰۰) تا اثر آن بر تعداد فراخوانی‌های مدل در مقابل دقت بازخوانی حقایق را بسنجید.
• برای پیاده‌سازی حافظه معنایی، از یک فایل JSON ساده برای ذخیره ترجیحات کاربر بین جلسات استفاده کنید.
• ساختار تلخیص خود را با چهار ضلع «هدف، تصمیم، موارد باز و حقایق» بازبینی کنید.

اما بهینه‌سازی این فرآیند در لایه‌های سخت‌افزاری حتی پیچیده‌تر است — به تحلیل ما درباره مدیریت KV Cache در مدل‌های زبانی مراجعه کنید که در آن روش‌های پیشرفته‌ای برای کاهش ۸ برابری حافظه KV Cache از طریق کوانتش و مدیریت اپیزودیک بررسی شده است.