آیا می‌توان حافظهٔ ایندکس‌های برداری را بدون افت کیفیت کاهش داد؟

تصور کنید می‌خواهید ۴۱ میلیون متن را در حافظه‌ای کمتر از ۶ گیگابایت جای دهید؛ عددی که در حالت عادی به ۲۰۰ گیگابایت حافظه رم و ۲۰۰ گیگابایت فضای دیسک نیاز داشت. طبق راهنمای فنی منتشر شده در ۱۵ اوت ۲۰۲۶ در وب‌سایت dev.to، این جهش با استفاده از کوانتش باینری (Binary Quantization) ممکن شده است که حافظه مورد نیاز برای ذخیره امبدینگ‌ها را ۳۲ برابر کم می‌کند اما تا ۹۶٪ از دقت بازیابی را حفظ می‌کند.

بسیاری از مهندسان دو عملیات کاملاً متفاوت را با نام کلی «کوانتش» می‌شناسند و آن‌ها را با هم اشتباه می‌گیرند. یکی روی پارامترهای داخلی مدل اثر می‌گذارد تا سرعت گذر پیشرو (Forward Pass) بالا برود و دیگری بردارهای خروجی را فشرده می‌کند تا حجم ایندکس جست‌وجو کم شود. همان‌طور که در تحلیل قبلی ما درباره‌ی تبدیل مفاهیم به هندسه اشاره کردیم، درک این تفاوت برای مقیاس‌بندی هر سیستم تولید بازیابی‌افزا (RAG) — که مثل دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — حیاتی است. این چالش‌های مقیاس‌بندی در واقع پاسخی به هزینه‌های پنهان ذخیره‌سازی در مدل‌های برداری است که پیش‌تر بررسی کرده بودیم.

مدل بردار معنایی را مثل یک کارخانه در نظر بگیرید. کوانتش وزن‌ها (Weight Quantization) شبیه ارتقای ماشین‌آلات برای سرعت بیشتر است؛ اما کوانتش بردار (Vector Quantization) مثل فشرده کردن محصولات نهایی است تا در انبار کوچکتری جای بگیرند. شما می‌توانید هر دو را هم‌زمان داشته باشید — مثلاً از یک مدل int8 استفاده کنید و بردارهای باینری ذخیره کنید — اما هر کدام گلوگاه متفاوتی را حل می‌کنند.

کوانتش بردار: کوچک کردن ایندکس

کوانتش بردار مدل را دست‌نخورده باقی می‌گذارد و بردارهای خروجی را پس از تولید فشرده می‌کند. در این حالت، اعداد اعشاری ۳۲ بیتی (fp32) به اعداد ۸ بیتی (int8) یا حتی تک‌بیتی (Binary) در هر بُعد تبدیل می‌شوند. صرفه‌جویی در حافظه در اینجا صرفاً یک محاسبه ریاضی ساده است: یک بردار ۷۶۸ بعدی در حالت fp32 به ۳۰۷۲ بایت فضا نیاز دارد، اما در حالت باینری به تنها ۹۶ بایت می‌رسد. کوانتش اسکالر int8 نیز کاهش ۴ برابری ایجاد می‌کند و حجم را از ۳۰۷۲ بایت به ۷۶۸ بایت می‌رساند.

مستندات Sentence Transformers تأکید می‌کند که کوانتش باینری علاوه بر کاهش ۳۲ برابری فضای ذخیره‌سازی، سرعت بازیابی را نیز تا ۳۲ برابر افزایش می‌دهد. با این حال، برای حفظ ۹۶٪ از کیفیت و عملکرد، دو شرط اجباری و غیرقابل چشم‌پوشی وجود دارد:

• بازرتبه‌بندی (Rescoring): سیستم باید ابتدا مجموعه‌ای بزرگ از کاندیدها را با استفاده از مقایسه‌های ارزانِ باینری بازیابی کند و سپس چند صد مورد اول را با استفاده از بردارهای با دقت کامل (fp32) یا int8 دوباره رتبه‌بندی کند. بازیابی باینری بدون این مرحله، منجر به افت شدید کیفیت می‌شود.
• کالیبراسیون (Calibration): برای کوانتش اسکالر int8، کتابخانه به نمونه‌هایی از امبدینگ‌های واقعیِ موجود در مجموعه داده‌های شما نیاز دارد تا حداقل و حداکثر هر بُعد را تعیین کند و «سطل‌های» (Buckets) مقداردهی را تعریف نماید. مستندات هشدار می‌دهند که مجموعه داده‌های کالیبراسیون تأثیر زیادی بر عملکرد دارند؛ بنابراین کالیبره کردن روی نمونه‌ای از داده‌های واقعی خودتان، بخش اصلی این متد است.

کوانتش وزن‌ها: افزایش سرعت استنتاج

در کوانتش وزن‌ها (Weight Quantization) — که مثل وقتی است به یک پزشک عمومی تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — پارامترهای مدل با دقت کمتری ذخیره می‌شوند (مثلاً int8 به جای fp32). این کار باعث کوچک شدن فایل مدل و کاهش حجم بایت‌های خوانده شده در هر بار استنتاج (Inference) — یعنی همان لحظه آشپزی و تولید جواب — می‌شود. این مکانیزم زمانی حیاتی است که نرخ خروجی (Throughput) یا فضای اشغال شده توسط مدل، محدودیت اصلی ما باشد. این همان روشی است که در خروجی‌های int8 ONNX یا فایل‌های q8_0 GGUF استفاده می‌شود. این رویکرد در واقع بخشی از ترند گسترده‌تری است که در آن مدل‌های کوچک‌تر در محاسبات محلی به دلیل بهینگی در مصرف منابع، در حال پیشی گرفتن از مدل‌های حجیم هستند.

برخلاف کوانتش بردار، در اینجا هیچ «عدد کیفی» جهانی وجود ندارد. میزان رانش (Drift) یا خطا بسته به مدل خاص، طرح کوانتش، داده‌های کالیبراسیون و حتی خودِ متن متفاوت است. برای مثال، مدلی که روی متون عمومی وب کالیبره شده است، ممکن است هنگام پردازش اصطلاحات تخصصی شیمی شکست بخورد؛ زیرا خطای کوانتش در وزن‌هایی که دامنه تغییرات (Dynamic Range) وسیعی دارند، متمرکز می‌شود.

مکانیزم رانش وزن‌ها

کوانتش وزن‌ها، بازه‌ای از مقادیر اعشاری را با استفاده از یک مقیاس (Scale) به‌ازای هر تنسور یا هر کانال، روی ۲۵۶ سطح نگاشت می‌کند. در بخش‌هایی که توزیع مقادیر در یک تنسور فشرده است، سطوح به هم نزدیک هستند و خطا بسیار ناچیز است.

اما مدل‌های ترنسفورمر (Transformer) به داشتن «ویژگی‌های پرت» (Outlier Features) در ابعاد خاصی معروف هستند. وقتی تعداد کمی از فعال‌سازها (Activations) چندین مرتبه بزرگتر از بقیه باشند، مقیاس کلی باید برای پوشش دادن آن‌ها کش بیاید. این اتفاق باعث می‌شود تمام مقادیر عادی در تنها چند سطح از دقت جمع شوند و جزئیات را از دست بدهند. به همین دلیل است که کیفیت کوانتش تابعی نرم از عرض بیت نیست و استفاده از طرح‌های «به‌ازای هر کانال» (per-channel) ضروری است. این تفاوت در حفظ جزئیات، مشابه چالش‌هایی است که در کوانتش یکپارچه در برابر ترکیبی برای مدل‌های بینایی-زبانی مشاهده می‌شود.

اندازه‌گیری واقعی tổnزل کیفیت

برای اینکه توسعه‌دهندگان بفهمند آیا کوانتش وزن‌ها برای پروژه آن‌ها مناسب است یا خیر، نباید به میانگین رانش کسینوسی (Mean Cosine Drift) تکیه کنند. یک میانگین ۰.۹۹۹ می‌تواند این حقیقت را پنهان کند که تعداد کمی از اسناد تغییر مکان زیادی داشته‌اند در حالی که اکثر اسناد تقریباً ثابت مانده‌اند؛ این یعنی چند سند حیاتی کاملاً از محله معنایی خود خارج شده‌اند و دیگر یافت نمی‌شوند.

به جای آن، راهنمای dev.to اسکریپتی را توصیه می‌کند که یک مجموعه داده را دو بار امبد می‌کند (یک بار با دقت کامل و یک بار کوانتیده) تا سه معیار خاص را ردیابی کند:

۱. صدک اول رانش کسینوسی: به جای میانگین، صدک اول و مقدار مینیمم را گزارش کنید. میانگین توسط اسنادی که جابجا نشده‌اند تحت تأثیر می‌گیرد، اما داستان واقعی در «دم» (Tail) توزیع است.
۲. همبستگی اسپیرمن: این معیار ساختار جفت‌به‌جفت هندسه را می‌سنجد. این معیار مواردی را شناسایی می‌کند که در آن تمام بردارها به یک اندازه کوچک چرخانده شده‌اند؛ در چنین حالتی، بردارهای فردی جابجا شده‌اند اما ترتیب نسبی آن‌ها ثابت مانده و بازیابی آسیب نمی‌بیند.
۳. هم‌پوشانی Top-k: این تنها معیاری است که کاربر نهایی واقعاً تجربه می‌کند. این معیار می‌سنجد که آیا مدل کوانتیده همان ۱۰ سند اول مدل fp32 را برمی‌گرداند یا خیر. یک میانگین کسینوسی ۰.۹۹۷ که جایگاه‌های ۳ تا ۸ را جابجا کرده باشد، خروجی سیستم را تغییر داده است، در حالی که یک میانگین ۰.۹۵ با ۹۹٪ هم‌پوشانی در Top-10، هیچ هزینه‌ای برای کاربر نداشته است.

قانون عملیاتی

تطابق بین یک مدل کوانتیده و مدل والد fp32 همیشه به معنای کیفیت نیست. مدل fp32 لزوماً حقیقت مطلق (Ground Truth) نیست؛ ممکن است نسخه کوانتیده با مدل والدش اختلاف داشته باشد اما همچنان در یک مجموعه ارزیابی برچسب‌دار، عملکردی برابر داشته باشد. اگر داده‌های ارزیابی مربوط به مرتبط بودن (Relevance Data) را در اختیار دارید، هر دو مدل را روی آن تست کنید؛ در غیر این صورت، میزان تطابق (Agreement) جایگزین مناسبی است.

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

گام بعدی شما

• اگر حجم ایندکس‌های RAG شما در حال انفجار است، ابتدا کوانتش باینری را روی یک زیرمجموعه از داده‌ها تست کنید.
• برای ارزیابی کیفیت، به جای میانگین، روی هم‌پوشانی Top-10 تمرکز کنید.
• حتماً از داده‌های واقعی محیط تولید (Production) برای کالیبراسیون مدل‌های int8 استفاده کنید.

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