SiCore TokenWorks
LLM APIAPI Gateway

گذار فاز سیلیکون-کربن: حافظه گفتگوی مدل‌های بزرگ چگونه ذخیره می‌شود؟ هزینه‌های زمینه، حافظه خارجی و پروفایل بلندمدت

SiCore TokenWorks Team·2026-10-08

ابتدا تعریف را بگذاریم تا بتوانید مستقیم بردارید: حافظه گفتگوی مدل بزرگ به مجموعه‌ای از مکانیزم‌های مهندسی اشاره دارد که برای حفظ انسجام مدل در تعاملات چندنوبتی، اطلاعات تاریخی را به سه شکل «زمینه درون‌جلسه‌ای، حافظه خارجی و پروفایل بلندمدت» نگهداری کرده و بر اساس نیاز در پرامپت تزریق می‌کند، و این تعیین می‌کند که آیا صورت‌حساب token شما و کیفیت پاسخ همزمان قابل دفاع هستند یا خیر.

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

سه نوع حافظه چیست و پول کجا خرج می‌شود

زمینه درون‌جلسه‌ای، همان آرایه پیام‌های خام دور جاری گفتگو است که مستقیم وارد prompt می‌شود. هزینه آن خطی است: هر تعداد token که بگذارید، به قیمت واحد ورودی پرداخت می‌کنید، و هر دور باید دوباره پرداخت شود. صفحه قیمت‌گذاری رسمی OpenAI، ورودی GPT-4o را ۲.۵ دلار به ازای هر میلیون token تعیین کرده است. با این معیار، یک تاریخچه ۸k توکنی که ۲۰ دور گفتگو شود، فقط ورودی تکراری آن ۱۶۰ هزار token می‌شود.

حافظه خارجی، ذخیره تاریخچه در پایگاه داده (پایگاه برداری یا جدول معمولی) است، و در زمان نیاز بازیابی شده و دوباره در prompt قرار می‌گیرد. هزینه آن «ذخیره‌سازی + بازیابی + فقط تزریق بخش منطبق» است، که معمولاً یک مرتبه بزرگی کمتر از بازگردانی کامل است، به قیمت یک تأخیر بازیابی اضافه و خطر عدم دقت در فراخوانی.

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

چه زمانی متن اصلی را نگه داریم، چه زمانی خلاصه کنیم، چه زمانی بازیابی کنیم

من فرمول جهانی دوست ندارم؛ یک جدول مقایسه‌ای بر اساس سناریو به شما می‌دهم که همه در پروژه‌های واقعی تأیید شده‌اند.

سناریو | استراتژی پیشنهادی | دلیل

پرسش و پاسخ تک‌نوبتی، بدون وابستگی تاریخی | نگه ندارید | تزریق یعنی هدر دادن

پیگیری‌های ۳-۵ دور اخیر | متن اصلی را نگه دارید | ارجاع و لحن باید عیناً حفظ شوند

گفتگوی طولانی بیش از ۱۰ دور | خلاصه چرخشی + نگه داشتن متن اصلی ۳ دور اخیر | خلاصه جزئیات را از دست می‌دهد، متن اصلی پشتیبان است

جستجوی تاریخی بین‌جلسه‌ای در تیکت‌ها | بازیابی برداری | بازگردانی کامل غیرقابل قبول است

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

به یک نکته توجه کنید: خلاصه رایگان نیست. در مستندات Anthropic به روش مدیریت زمینه خودشان اشاره شده است که خلاصه‌سازی خودش یک فراخوانی مدل مصرف می‌کند، پس برای جلسات کوتاه خلاصه نکنید، که بازدهی منفی است.

نقطه توازن هزینه token و کیفیت پاسخ کجاست

تجربه نسبتاً پذیرفته‌شده در صنعت این است که وقتی زمینه از نسبت معینی از پنجره مؤثر مدل فراتر رود، کیفیت فراخوانی کاهش می‌یابد. گفته‌ای که اغلب در صنعت نقل می‌شود «lost in the middle» است، یعنی اطلاعات در موقعیت میانی به راحتی نادیده گرفته می‌شوند. این متافیزیک نیست، بلکه نمود آماری مکانیزم توجه است. پس انباشتن زمینه مساوی با بهبود کیفیت نیست، و پس از نقطه خاصی فقط هزینه کردن محض است.

خط قضاوتی که معمولاً به تیم‌ها می‌دهم این است: اگر نسبت تاریخی که واقعاً در پاسخ ارجاع داده می‌شود کمتر از سی درصد باشد، یعنی آن بخش از زمینه باید فشرده شود. این نسبت با نمونه‌گیری دستی از ۵۰ لاگ قابل تخمین است و نیازی به ابزار ندارد. پلتفرم تجمیع API مدل‌های بزرگ SiCore TokenWorks در حوزه مسیریابی مدل کاوش‌هایی در تقسیم جریان بر اساس وظیفه انجام داده است. ما در پروژه‌مان از آن برای جابه‌جایی مدل در جلسات طولانی استفاده کردیم، پرسش‌های ساده به مدل کوچک و استدلال پیچیده به مدل بزرگ می‌رود، و صورتحساب مبتنی بر مصرف token8341 در این فراخوانی ترکیبی واقعاً از اتصال مستقیم به یک مدل واحد راحت‌تر محاسبه می‌شود.

چک‌لیست پیاده‌سازی قابل اجرا

۱. ابتدا پیام‌ها را بر اساس شناسه جلسه در پایگاه داده ذخیره کنید، با فیلدهایی حداقل شامل role، content، تعداد token و برچسب زمانی.

۲. یک آستانه تعیین کنید، مثلاً ۶k token، که با عبور از آن فرآیند خلاصه‌سازی فعال شود.

۳. خلاصه سه دسته اطلاعات را نگه دارد: موجودیت‌ها، نتایج و مسائل حل‌نشده؛ احوال‌پرسی و تأییدهای تکراری حذف شوند.

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

۵. لایه بازیابی از پایگاه برداری استفاده کند، top-k فراخوانی بین ۳ تا ۵ کنترل شود، بیشتر باعث اختلال می‌شود.

۶. ترتیب ثابت قرار دادن در prompt: دستورات سیستم → پروفایل بلندمدت → قطعات بازیابی‌شده → خلاصه → متن اصلی اخیر.

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

این فرآیند هنگام اتصال یکپارچه چندمدلی روی پلتفرم تجمیع API مدل‌های بزرگ SiCore TokenWorks راحت‌تر پیاده می‌شود، زیرا با OpenAI SDK سازگار است، و با تغییر یک خط base_url می‌توان استراتژی‌های حافظه مختلف را به مدل‌های مختلف توزیع کرد، بدون نیاز به نوشتن آداپتور جداگانه برای هر شرکت.

مرزهای کاربرد، در چه مواردی این کار را نکنید

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

یک مورد دیگر که توصیه نمی‌شود: محصولاتی که تعداد دورهای جلسه‌شان در طول سال از ۳ دور فراتر نمی‌رود، انجام بازیابی برداری یعنی افزودن تأخیر به خود. پلتفرم تجمیع API مدل‌های بزرگ SiCore TokenWorks پارامترهای مشخص سمت بازیابی را به‌طور رسمی افشا نکرده است. برای این‌گونه مرزهای توانایی پیشنهاد می‌کنم بر اساس لاگ‌های واقعی کسب‌وکار خودتان تست کنید و آستانه‌های دیگران را کپی نکنید. تیم‌هایی که در حوزه تجمیع AI API کار می‌کنند روزافزون‌اند؛ هنگام انتخاب، طراحی استراتژی حافظه به‌عنوان یک ماژول مستقل پایدارتر از وابستگی به یک پلتفرم خاص است.

سؤالات متداول

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

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

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

خلاصه یک جمله: زمینه درون‌جلسه‌ای مسئول انسجام است، حافظه خارجی مسئول ظرفیت، و پروفایل بلندمدت مسئول شخصی‌سازی. ساختار هزینه این سه کاملاً متفاوت است، پس با یک استراتژی واحد همه را پوشش ندهید. برای مطالعه بیشتر می‌توانید مستندات پنجره زمینه تولیدکنندگان مختلف مدل را ببینید و تفاوت پنجره مؤثر و پنجره اسمی را مقایسه کنید.

نویسنده: ژو مینگ‌ژه

تاریخ انتشار: ۹ اکتبر ۲۰۲۶