حافظه نهان معنایی؛ پاسخ سریعتر و هزینه کمتر با گدارAI
نگاهی فنی به معماری حافظه نهان معنایی گدارAI و راهی عملی برای کاهش فراخوانیهای تکراری مدل، تأخیر پاسخ و هزینه استنتاج.
تیم محتوای گدارAI
تحریریه فنی و زیرساخت هوش مصنوعی
آخرین بهروزرسانی:۷ مرداد ۱۴۰۵
حافظه نهان معنایی؛ چرا یک پاسخ را دوباره از مدل بخریم؟
- مخاطب: رهبران فنی، مدیران محصول و تیمهای زیرساخت هوش مصنوعی
- زمان مطالعه: ۱۰ دقیقه
کاربری میپرسد «چطور رمز عبورم را بازیابی کنم؟» و کاربر دیگری چند دقیقه بعد مینویسد «رمزم را فراموش کردهام؛ راه بازنشانی چیست؟». برای انسان روشن است که این دو پرسش یک هدف دارند؛ اما در معماری معمول، هر دو به مدل زبانی فرستاده میشوند، هر دو توکن مصرف میکنند و برای هر دو باید منتظر استنتاج مدل ماند.
حافظه نهان معنایی (Semantic Cache) این تکرار پنهان را پیدا میکند. بهجای مقایسه عین متن، معنی درخواست تازه با درخواستهای قبلی سنجیده میشود. اگر شباهت از حد تعیینشده بیشتر باشد، سامانه پاسخ معتبر قبلی را برمیگرداند و دیگر لازم نیست مدل مولد همان کار را دوباره انجام دهد.
این ایده ساده، وقتی در مسیر واقعی یک محصول قرار میگیرد، به چند مسئله مهندسی جدی میرسد: چه چیزی را باید مقایسه کرد؟ پاسخهای کدام کاربران میتوانند با هم به اشتراک گذاشته شوند؟ چه زمانی یک پاسخ قدیمی است؟ اگر مدل یا پرامپت عوض شد چه میشود؟ و تیم فنی چطور اثر واقعی کش بر هزینه و کیفیت را میسنجد؟
گدارAI حافظه نهان معنایی را در خود درگاه مدلهای زبانی پیاده میکند تا این تصمیمها در یک لایه مرکزی، قابلکنترل و قابلمشاهده باشند.
نتیجهای که AWS اندازهگیری کرد
AWS در یک آزمایش منتشرشده درباره حافظه نهان معنایی از ۶۳٬۷۹۶ پرسش واقعی و بازنویسیهای آنها استفاده کرد. زیرساخت آزمایش شامل Amazon Titan Text Embeddings V2، مدل Claude 3 Haiku و ElastiCache for Valkey بود.
در آستانه شباهت 0.75، این آزمایش به نرخ برخورد ۹۰٫۳٪، صحت ۹۱٫۲٪ برای پاسخهای کششده، ۸۶٫۳٪ صرفهجویی هزینه روزانه و ۸۸٫۳٪ کاهش میانگین تأخیر رسید. در نمونههای منفرد نیز پاسخ از کش تا ۵۹ برابر سریعتر از مسیر فراخوانی مدل بود.
جدول زیر بخشی از نتایج همان آزمایش را نشان میدهد:
| آستانه شباهت | نرخ برخورد کش | صحت پاسخهای کششده | صرفهجویی هزینه | کاهش میانگین تأخیر |
|---|---|---|---|---|
0.99 |
۲۳٫۵٪ | ۹۲٫۱٪ | ۱۵٫۸٪ | ۱۷٫۱٪ |
0.95 |
۵۶٫۰٪ | ۹۲٫۶٪ | ۵۱٫۹٪ | ۵۷٫۷٪ |
0.90 |
۷۴٫۵٪ | ۹۲٫۳٪ | ۷۲٫۵٪ | ۷۲٫۲٪ |
0.80 |
۸۷٫۶٪ | ۹۱٫۸٪ | ۸۴٫۶٪ | ۸۶٫۱٪ |
0.75 |
۹۰٫۳٪ | ۹۱٫۲٪ | ۸۶٫۳٪ | ۸۸٫۳٪ |
این اعداد وعده عملکرد گدارAI یا هر محصول دیگری نیستند. نتیجه واقعی به الگوی ترافیک، مدل تعبیهسازی، مدل مولد، آستانه شباهت، مدت نگهداری و میزان پویایی پاسخها بستگی دارد. ارزش این بنچمارک در نشاندادن یک رابطه مهم است: پایینآوردن آستانه، نرخ برخورد و صرفهجویی را بیشتر میکند، اما احتمال تطبیق نادرست را نیز بالا میبرد.
حافظه نهان معنایی چگونه کار میکند؟
کش سنتی از یک کلید دقیق استفاده میکند. اگر حتی یک واژه یا پارامتر تغییر کند، درخواست تازه یک «عدم تطبیق» است. حافظه نهان معنایی یک مرحله دیگر اضافه میکند:
- متن به یک بردار عددی یا تعبیه (Embedding) تبدیل میشود.
- بردار درخواست تازه با بردار درخواستهای قبلی مقایسه میشود.
- یک سنجه مانند شباهت کسینوسی نشان میدهد دو بردار چقدر به هم نزدیکاند.
- اگر امتیاز از آستانه تعیینشده بالاتر باشد، پاسخ قبلی برگردانده میشود.
- در غیر این صورت، درخواست به مدل مولد میرود و پاسخ تازه برای استفاده بعدی ذخیره میشود.
در نتیجه، این دو پرسش میتوانند یک پاسخ مشترک داشته باشند:
چطور رمز عبورم را بازیابی کنم؟
برای بازنشانی رمز فراموششده چه کار کنم؟
اما «چطور ایمیل حسابم را تغییر دهم؟» نباید فقط بهدلیل داشتن واژههای مشترک با آنها تطبیق داده شود. نقش مدل تعبیهسازی، آستانه شباهت و محدوده جستوجو همینجا مشخص میشود.
معماری حافظه نهان معنایی در گدارAI
حافظه نهان پاسخ در گدارAI در مسیر chat/completions و پیش از فراخوانی ارائهدهنده مدل قرار دارد. این جایگاه باعث میشود قابلیت کش به یک مدل یا ارائهدهنده خاص وابسته نباشد و سیاست آن در خود درگاه اجرا شود.
هر درخواست یکی از دو حالت را انتخاب میکند:
| حالت | روش تطبیق | کاربرد مناسب |
|---|---|---|
simple |
اثرانگشت دقیق درخواست و پارامترهای مؤثر | پرامپتهای ثابت و مسیرهای حساس به دقت |
smart |
تطبیق دقیق، سپس مقایسه معنایی آخرین پیام کاربر | پرسشهای پرتکرار با عبارتهای متفاوت |
مسیر یک درخواست در حالت smart به این شکل است:
۱. تطبیق دقیق همیشه اول است
گدارAI ابتدا از محتوای درخواست و پارامترهای مؤثر آن یک اثرانگشت میسازد. اگر همان درخواست قبلاً پاسخ گرفته باشد، نتیجه بدون ساخت بردار تازه برمیگردد. بنابراین حالت هوشمند، مزیت کش دقیق را از دست نمیدهد.
فرادادهای که به ارائهدهنده ارسال نمیشود و روی پاسخ مدل اثری ندارد، در هویت کش دخالت داده نمیشود. این کار از شکستن بیدلیل کش با شناسههای اجرایی متفاوت جلوگیری میکند.
۲. فقط بخش قابلتغییر بهصورت معنایی مقایسه میشود
اگر تطبیق دقیق پیدا نشود، گدارAI متن آخرین پیام کاربر را به بردار تبدیل میکند. در عین حال، بقیه زمینه درخواست ثابت میماند: پیام سیستمی، تاریخچه مرتبط، مدل و پارامترهای تولید باید با ورودی ذخیرهشده سازگار باشند.
این تصمیم معماری مهم است. گدارAI هر دو جمله شبیه را بدون توجه به زمینه یکسان فرض نمیکند؛ فقط وقتی بخشهای مؤثر دیگر درخواست همخوان باشند، سراغ مقایسه معنایی متن کاربر میرود.
۳. شباهت کسینوسی با آستانه قابلتنظیم سنجیده میشود
بردار تازه با نامزدهای همان محدوده کش مقایسه میشود. گدارAI شباهت کسینوسی را بدون فرض نرمالبودن بردارها محاسبه میکند و بهترین نتیجه را با similarity_threshold میسنجد.
مقدار پیشفرض 0.9 است و مقدار مجاز بین 0.8 تا 1.0 قرار دارد. آستانه بالاتر محافظهکارانهتر است؛ آستانه پایینتر برخورد بیشتری ایجاد میکند، اما به ارزیابی دقیقتر کیفیت نیاز دارد.
۴. در برخورد کش، فراخوانی مدل مولد حذف میشود
اگر نتیجه معتبر پیدا شود، گدارAI پاسخ ذخیرهشده را برمیگرداند. شناسه رد درخواست اصلی و امتیاز شباهت نیز در سرآیند پاسخ قرار میگیرند. این مسیر هزینه تازه استنتاج مدل مولد ندارد و معمولاً تأخیر بسیار کمتری ایجاد میکند.
اگر تطبیقی پیدا نشود، درخواست از مسیر عادی مسیریابی و فراخوانی مدل عبور میکند. سپس پاسخ، بردار، زمان انقضا، مدل ارائهدهنده و یک تصویر ثابت از هزینه پاسخ اصلی در کش ثبت میشوند.
تکنیکهایی که کش را برای محیط عملیاتی امنتر میکنند
تبدیل یک نمونه آزمایشی به قابلیت زیرساختی فقط با محاسبه شباهت تمام نمیشود. معماری گدارAI چند مرز و سازوکار مکمل دارد.
ایزولهسازی چندلایه
دامنه هر ورودی کش با این مؤلفهها ساخته میشود:
- محیط اختصاصی سازمان
- کلید دسترسی
- فضای نام
- مدل درخواستی
- نسخه مدل مجازی
این ترکیب مانع میشود پاسخ یک سازمان، کلید، جریان کاری یا نسخه دیگر مدل بهاشتباه وارد نتیجه شود. namespace نیز به تیم محصول اجازه میدهد کش بخشهایی مانند support، onboarding و mobile-app را از هم جدا کند.
جداسازی نسخه و هویت تعبیهساز
بردارهای ساختهشده با مدلها یا نسخههای متفاوت الزاماً قابلمقایسه نیستند. گدارAI شناسه ارائهدهنده تعبیه، نام مدل، نسخه، و تعداد ابعاد بردار را در هویت کش وارد میکند. با تغییر این مشخصات، بردارهای ناسازگار با هم مخلوط نمیشوند.
نسخه مدل مجازی نیز بخشی از محدوده کش است. بنابراین تغییر پیکربندی مدل یا مسیر آن، پاسخهای نسخه قبلی را به شکل ناخواسته وارد مسیر تازه نمیکند.
زمان انقضا و فضای نام
هر درخواست میتواند ttl خود را بر حسب ثانیه تعیین کند. زمان کوتاهتر تازگی را بیشتر و نرخ برخورد را کمتر میکند؛ زمان بلندتر صرفهجویی را بالا میبرد، اما ریسک پاسخ قدیمی را افزایش میدهد.
فضای نام یک ابزار تکمیلی برای باطلسازی منطقی است. برای نمونه، بعد از انتشار نسخه تازه مرکز راهنما میتوان از helpdesk-v2 استفاده کرد تا ترافیک تازه با پاسخهای نسخه قبلی مخلوط نشود.
ذخیرهسازی دو لایه و هماهنگی توزیعشده
ورودیهای پاسخ در لایه حافظه محلی و Redis نگهداری میشوند تا خواندنهای پرتکرار سریع باشند و نمونههای مختلف درگاه به داده مشترک دسترسی داشته باشند. شاخص نامزدهای معنایی از مسیر توزیعشده Redis خوانده و نوشته میشود تا میان نمونههای درگاه هماهنگ بماند.
در معماری فعلی، بردارسازی از طریق یک نقطه پایانی سازگار با OpenAI برای مدل BGE-M3 در مسیر زیرساخت ایران انجام میشود. این جزء پشت یک رابط مستقل قرار دارد؛ هویت مدل و ابعاد بردار نیز صریح ثبت میشود تا تغییر نسخه کنترلشده باشد.
مهار هجوم همزمان به مدل
گاهی چند درخواست یکسان همزمان میرسند، در حالی که کش هنوز خالی است. اگر همه آنها جداگانه به مدل بروند، «هجوم در زمان عدم تطبیق» یا Cache Stampede رخ میدهد.
گدارAI کار مربوط به یک کلید دقیق را در هر نمونه درگاه همگرا میکند. درخواست اول پاسخ را تولید میکند و درخواستهای همزمان منتظر میمانند؛ پس از ذخیره نتیجه، آنها دوباره کش را بررسی میکنند. این روش تعداد فراخوانیهای تکراری در لحظههای اوج را کم میکند.
عبور کنترلشده برای درخواستهای نامناسب
کش هوشمند برای همه درخواستها فعال نمیشود. درخواستهای جریانی، فراخوانی ابزار، پیام غیرمتنی و وضعیتی که آخرین پیام از کاربر نیست، از مسیر معنایی عبور میکنند. درخواستهای دارای تفکر توسعهیافته نیز وارد کش پاسخ نمیشوند.
اگر تعبیهساز یا جستوجوی معنایی خطا بدهد، گدارAI وضعیت را ثبت میکند و درخواست را از مسیر عادی ارائهدهنده ادامه میدهد. در نتیجه، اختلال کش نباید بهتنهایی دسترسی به مدل را متوقف کند.
مشاهدهپذیری؛ صرفهجویی باید قابلاندازهگیری باشد
بدون سنجه، تیم فقط میداند کش «روشن» است؛ نه اینکه چقدر ارزش ایجاد کرده یا کجا کیفیت را تهدید میکند.
گدارAI برای هر درخواست یکی از وضعیتهای hit، miss، bypass یا error را ثبت میکند. در برخورد کش هوشمند، نوع تطبیق، امتیاز شباهت و شناسه درخواست منبع نیز قابلردیابی است.
پاسخ اصلی همراه با یک تصویر تغییرناپذیر از این دادهها ذخیره میشود:
- تعداد توکن ورودی و خروجی
- هزینه دلاری و ریالی محاسبهشده
- نرخ تبدیل استفادهشده
- نسخه قیمتگذاری
- زمان محاسبه
وقتی همان پاسخ دوباره استفاده میشود، گدارAI هزینه واقعی درخواست تازه را صفر ثبت میکند و هزینه پاسخ اصلی را بهعنوان «هزینه برآوردی صرفهجوییشده» در سنجهها میآورد. به این ترتیب، داشبورد میتواند تطبیق دقیق و معنایی، نرخ برخورد، هزینه واقعی و صرفهجویی برآوردی را جداگانه نشان دهد.
فعالسازی با یک سرآیند
برای استفاده از حافظه نهان معنایی لازم نیست منطق کش را در هر سرویس محصول دوباره بسازید. در یک درخواست سازگار با Chat Completions، سرآیند زیر را اضافه کنید:
x-godarai-cache-config: {"type":"smart","ttl":900,"similarity_threshold":0.9,"namespace":"helpdesk"}
این تنظیم به گدارAI میگوید:
- حالت هوشمند را فعال کند؛
- پاسخ را ۹۰۰ ثانیه نگه دارد؛
- فقط تطبیقهای با شباهت دستکم
0.9را بپذیرد؛ - داده را در فضای نام
helpdeskجدا کند.
در پاسخ نیز این سرآیندها برای بررسی نتیجه در دسترساند:
| سرآیند | کاربرد |
|---|---|
x-godarai-cache-status |
وضعیت hit، miss، bypass یا error |
x-godarai-cached-trace-id |
شناسه رد درخواست اصلی |
x-godarai-cache-similarity-score |
امتیاز شباهت در تطبیق معنایی |
جزئیات قرارداد، نمونههای چندزبانه و راهنمای عیبیابی در مستندات کش پاسخ گدارAI آمده است.
چه چیزهایی را کش کنیم؟
بهترین نامزدها، درخواستهای پرتکراری هستند که پاسخ آنها در بازه TTL ثابت میماند:
- پرسشهای مرکز راهنما و پشتیبانی سطح اول
- توضیح قابلیتها و فرایندهای ثابت محصول
- راهنمای نصب، فعالسازی و رفع خطاهای شناختهشده
- خلاصهسازی ورودیهای شناختهشده و تکراری
- پاسخهای عمومی یک دستیار مبتنی بر بازیابی سند، وقتی منبع بهندرت تغییر میکند
در مقابل، این موارد به سیاست محافظهکارانهتر نیاز دارند:
- قیمت، موجودی و وضعیت لحظهای سفارش
- پاسخ شخصیسازیشده با داده خصوصی کاربر
- محاسبات مالی یا تصمیمهای حساس
- گفتوگوهایی که پاسخ هر نوبت به زمینه متغیر قبلی وابسته است
- خروجی ابزارها و عاملهایی که وضعیت بیرونی را تغییر میدهند
برای دادههای پویا، یا کش را غیرفعال کنید یا فضای نام دقیق و TTL کوتاه در نظر بگیرید. اگر پاسخ برای هر کاربر متفاوت است، دامنه کش باید آن تفاوت را منعکس کند؛ شباهت زبانی بهتنهایی مجوز استفاده دوباره از پاسخ نیست.
یک مسیر کمریسک برای شروع
۱. یک جریان پرتکرار و پایدار انتخاب کنید
از مرکز راهنما یا پرسشهای عمومی پشتیبانی شروع کنید، نه از وضعیت سفارش یا داده مالی.
۲. ابتدا خط پایه بسازید
حجم درخواست، هزینه، تأخیر صدکی و الگوهای تکرار را بدون کش اندازه بگیرید. بدون خط پایه، اثر تغییر قابلاثبات نیست.
۳. با کش ساده یا آستانه محافظهکارانه آغاز کنید
حالت simple کمریسکترین نقطه شروع است. برای حالت smart، مقدار 0.9 یا بالاتر را انتخاب کنید و نمونههای واقعی را بازبینی کنید.
۴. TTL و فضای نام را با چرخه تغییر داده هماهنگ کنید
اگر محتوای راهنما روزانه منتشر میشود، TTL چندروزه انتخاب مناسبی نیست. فضای نام را نیز به محصول، محیط و نسخه محتوا گره بزنید.
۵. هزینه و کیفیت را همزمان بسنجید
نرخ برخورد بالا بهتنهایی موفقیت نیست. در کنار آن، درستی پاسخهای کششده، نرخ ارجاع به پشتیبان انسانی، رضایت کاربر، تأخیر و هزینه برآوردی صرفهجوییشده را ببینید.
۶. آستانه را با داده واقعی تنظیم کنید
نمونهای از برخوردهای معنایی را در چند بازه امتیاز بررسی کنید. اگر تطبیق نادرست زیاد است، آستانه را بالا ببرید یا فضای نام را محدودتر کنید. اگر همه پاسخها درستاند اما نرخ برخورد پایین است، میتوانید کاهش کنترلشده آستانه را آزمایش کنید.
حافظه نهان معنایی، بخشی از معماری است نه یک افزونه
صرفهجویی واقعی زمانی ایجاد میشود که کش در نقطه مشترک همه فراخوانیهای مدل قرار بگیرد، با مرزهای سازمانی و نسخهای هماهنگ باشد و اثر آن در همان سامانه مشاهدهپذیری دیده شود.
گدارAI این قابلیت را در کنار مسیریابی مدل، مسیر جایگزین، محدودیت نرخ، کنترل بودجه و گزارش رخداد قرار میدهد. نتیجه این است که تیم محصول برای هر قابلیت میتواند یک سیاست روشن داشته باشد: کدام درخواست قابلاستفاده دوباره است، تا چه زمانی معتبر میماند، چه شباهتی قابلقبول است و چقدر هزینه حذف شده است.
اگر محصول شما برای پرسشهای مشابه بارها به مدل پول میدهد، نقطه شروع یک پروژه پیچیده تازه نیست. یک جریان پرتکرار را انتخاب کنید، x-godarai-cache-config را روی بخشی از ترافیک فعال کنید و نرخ برخورد، کیفیت و صرفهجویی را در گدارAI کنار هم بسنجید.
منابع
درباره نویسنده
این مقاله با تمرکز بر معماری عملیاتی مدلهای زبانی، کنترل هزینه و کاهش تأخیر در محصولات مبتنی بر هوش مصنوعی تدوین شده است.
پرسشهای پرتکرار
حافظه نهان معنایی چه تفاوتی با کش ساده دارد؟
کش ساده فقط درخواستهای یکسان را تطبیق میدهد؛ حافظه نهان معنایی میتواند دو پرسش با عبارت متفاوت اما مفهوم نزدیک را تشخیص دهد و پاسخ معتبر قبلی را برگرداند.
آیا حافظه نهان معنایی همان حافظه نهان پرامپت ارائهدهنده است؟
خیر. حافظه نهان پرامپت بخشی از پردازش ورودی را در سمت ارائهدهنده سبکتر میکند، اما حافظه نهان پاسخ گدارAI در صورت تطبیق میتواند فراخوانی مدل مولد را بهطور کامل حذف کند.
آیا عدد ۸۶ درصد صرفهجویی برای همه محصولات تکرار میشود؟
خیر. این عدد متعلق به آزمایش AWS با مجموعهداده، مدلها و تنظیمات مشخص است. نتیجه واقعی به نرخ تکرار درخواست، آستانه شباهت، مدت نگهداری، مدل و پویایی داده محصول بستگی دارد.
از چه آستانه شباهتی شروع کنیم؟
مقدار ۰٫۹ نقطه شروع متعادلی است. برای پاسخهای حساستر آستانه را افزایش دهید و تصمیم نهایی را بر اساس نمونههای واقعی، نرخ تطبیق و ارزیابی صحت پاسخ بگیرید.
چطور حافظه نهان معنایی را در گدارAI فعال کنیم؟
در درخواست سازگار با Chat Completions، سرآیند x-godarai-cache-config را با نوع smart، مدت نگهداری، فضای نام و آستانه شباهت ارسال کنید.