کاهش ۵۷ درصدی فراخوانی مدل‌ها با پیاده‌سازی حافظهٔ معنایی

اگر برای مدیریت هزینه‌های استنتاج و تأخیر در چت‌بات‌های خود به دنبال راهی هستید، کاهش ۵۷ درصدی فراخوانی‌های مدل می‌تواند بازی را عوض کند. این عدد نتیجهٔ پیاده‌سازی یک سیستم حافظهٔ معنایی (Semantic Caching) در یک محیط تست پشتیبانی است که در ۲۱ اوت ۲۰۲۶ منتشر شد. در حالی که سیستم‌های سنتی مبتنی بر هش محتوایی (Content Hashing) نیازمند تطابق دقیق رشته‌های متنی هستند، این سیستم جدید تشخیص می‌دهد که چه زمانی عبارت‌های متفاوت، قصد و هدف یکسانی را دنبال می‌کنند.

بسیاری از چت‌بات‌ها با پرسش‌های تکراری دست‌وپنجه نرم می‌کنند؛ مثلاً «سفارش من کجاست؟»، «بسته‌ام چی شد؟» و «محموله من را ردیابی کن؟». این سه عبارت در واقع یک قصد واحد هستند اما در سیستم‌های سنتی که بر اساس تطابق دقیق متن کار می‌کنند، هر کدام یک فراخوانی مجزا و هزینه‌بر برای مدل ایجاد می‌کنند. در این حالت، چون رشته‌های متنی متفاوت‌اند، هش محتوایی در هر سه مورد شکست می‌خورد. اما با تبدیل گفتگوها به بردار معنایی (Embedding) — که شبیه به یک کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — توسعه‌دهندگان می‌توانند پاسخ‌های قبلی را برای هر پرسشی که در یک محدودهٔ عددی مشخص قرار می‌گیرد، بازیافت کنند. برای درک عمیق‌تر این مفهوم، می‌توانید به بررسی نحوه تبدیل مفاهیم به هندسه در جست‌وجوی هوشمند مراجعه کنید.

زمینه و ساختار

طبق گزارش وب‌سایت dev.to، این سیستم بر سه رکن اصلی استوار است: یک تابع بردارساز، یک ذخیره‌ساز برداری و یک آستانهٔ فاصله. برای بخش بردارساز، از مدل محلی all-MiniLM-L6-v2 استفاده شده تا فرآیند به‌صورت آفلاین و رایگان باقی بماند و نیازی به پرداخت هزینه برای APIهای خارجی نباشد. این رویکرد یادآور راهکارهای مشابهی است که در پروژه Artwaste.land برای حذف کامل هزینه‌های API از طریق جست‌وجوی معنایی در مرورگر به کار گرفته شد.

در بخش بک‌اند، نویسنده برای به حداقل رساندن هزینه‌های آزمایش، از نقاط انتهایی (Endpoint) رایگان MonkeyCode استفاده کرده است. در توضیحات این گزارش ذکر شده که مقاله به عنوان بخشی از فعالیت‌های ترویجی محصولات MonkeyCode تهیه شده است، به همین دلیل استفاده از این سرویس رایگان برای آزمایش‌های ارزان‌قیمت، انتخابی ایده‌آل بوده است.

جزئیات فنی پیاده‌سازی

جزئیات فنی این پیاده‌سازی به شرح زیر است:

• معیار فاصله: سیستم از شباهت کسینوسی (Cosine Distance) برای مقایسه بردارهای پرسش استفاده می‌کند. فرمول مورد استفاده، ۱ منهای حاصل‌ضرب داخلی دو بردار تقسیم بر حاصل‌ضرب اندازه (Magnitude) آن‌ها است.
• آستانه (Threshold): عدد ۰.۳۵ برای تعیین این‌که آیا پاسخ ذخیره‌شده «به اندازه کافی نزدیک» به سؤال جدید هست یا خیر، انتخاب شده است. این مقدار باید بر اساس داده‌های واقعی کاربران تنظیم (Tune) شود.
• ذخیره‌سازی: برای سادگی در مقیاس کوچک و اجتناب از نیاز به پایگاه‌های داده پیچیده، از یک فایل JSON ساده به نام cache.json به عنوان ذخیره‌ساز برداری استفاده شده است.
• شناسایی: هر ورودی با یک هش SHA-256 از متن سؤال که به ۱۲ کاراکتر کوتاه شده است، شناسایی می‌شود.

برای جلوگیری از رشد بی‌رویه حافظه، نویسنده سقف ۱۰۰۰ ورودی (MAX_ENTRIES) را تعیین کرده است و سیستم قدیمی‌ترین رکوردها را در اولویت حذف قرار می‌دهد. بهینه‌سازی دیگر، ردیابی شمارنده برخوردها (Hit Counters) است؛ سیستم تنها زمانی یک پاسخ را به‌صورت دائمی ذخیره می‌کند که قصد مشابه برای بار دوم شناسایی شود. این مکانیسم تضمین می‌کند که سؤالات تک‌باره و نادر، حافظه را آلوده نکنند، در حالی که قصدهای تکرار شونده ذخیره شوند. این چالش‌های مدیریت حافظه در مقیاس کوچک، بازتابی از بحران حافظه در معماری مدل‌های پیشرو است که اولویت اصلی سال ۲۰۲۶ شده است.

در آزمونی با ۵۰۰ سؤال مصنوعی که ۴۰٪ آن‌ها بازنویسیِ ۲۰ قصد اصلی بودند، نتایج خیره‌کننده بود. تعداد فراخوانی‌های مدل از ۵۰۰ به ۲۱۴ کاهش یافت. مهم‌تر از آن، تأخیر در سطح p95 از ۴.۲ ثانیه به ۰.۸ ثانیه سقوط کرد.

این تغییر، ارزش اصلی کشینگ را از «کاهش هزینه» به «بهبود تجربه کاربری» منتقل می‌کند. در حالی که در مدل‌های رایگان، صرفه‌جویی دلاری ناچیز است، اما کاهش ۳.۴ ثانیه‌ای تأخیر، بردی ملموس برای حفظ کاربر نهایی است. علاوه بر این، کاهش تعداد درخواست‌ها، قابلیت اطمینان سیستم را با به حداقل رساندن محدودیت‌های نرخ فراخوانی (Rate Limits) و تلاش‌های مجدد (Retries) بهبود می‌بخشد.

با این حال، حافظه معنایی یک راهکار جهانی نیست. این روش در گفتگوهای چندمرحله‌ای (Multi-turn) شکست می‌خورد؛ جایی که سؤالی مانند «آن یکی قرمز چطور؟» به‌تنهایی معنا ندارد و به متن قبلی وابسته است. تلاش برای ذخیره‌سازی کل وضعیت گفتگو در کش، باعث انفجار فضای برداری می‌شود. همچنین این سیستم با داده‌های پویا و مختص هر حساب کاربری که سریعاً قدیمی می‌شوند، مشکل دارد؛ بنابراین فقط برای حقایق ایستا (Static) مناسب است.

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

گام بعدی شما

• نرخ برخورد (Hit Rate) فعلی سیستم خود را با یک مدل بردارساز محلی و یک لیست ساده تست کنید.
• آستانه فاصله را بر اساس داده‌های واقعی کاربران خود تنظیم کنید تا تعادل میان دقت و سرعت برقرار شود.
• این سیستم را فقط برای بخش‌های FAQ و پاسخ‌های عمومی استقرار دهید و از به‌کارگیری آن در گفتگوهای شخصی بپرهیزید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.