كل تمثيل متجهي (embedding) قائمة من الأرقام، وتخزّن قاعدة بيانات المتجهات الملايين منها مع فهرس للبحث فيها بسرعة. وقبل اختيار خطة قاعدة البيانات أو حجم الخادم، عليك أن تعرف إلى أي حجم ستصل. تقدّر هذه الحاسبة حجم المتجهات الخام والحمل الإضافي للفهرس والبيانات الوصفية والنسخ المتماثلة، وتُظهر كم يمكن أن يوفّره التكميم.
كيف تعمل
حجم المتجهات الخام = عدد المتجهات × الأبعاد × البايتات لكل بُعد. فالمتجه من 1,536 بعدًا بصيغة float32 حجمه 1,536 × 4 = 6,144 بايت، وعليه تبلغ 10 ملايين منها نحو 61 GB قبل أي فهرس.
يخزّن فهرس HNSW رسمًا بيانيًا للجيران من أجل بحث تقريبي سريع. وتحتفظ طبقته السفلى بما يصل إلى 2 × M رابطًا لكل متجه، تُخزَّن معرّفاتٍ من 4 بايت، فعند M = 16 يكون ذلك نحو 128 بايت لكل متجه، مع قليل إضافي للطبقات العليا. أما فهارس IVF فتضيف أقل بكثير لكنها تحتاج عادةً إلى ضبط لبلوغ استرجاع جيد. ولا يضيف الفهرس flat شيئًا ويبحث بدقة تامة، لكنه بطيء على النطاق الكبير.
يقلّص التكميم حجم المتجهات. فـ float16 يخفض الحجم إلى النصف، و int8 إلى الربع، والتكميم الثنائي إلى 1/32. وينخفض الاسترجاع قليلًا مع كل خطوة، لذا تُبقي أنظمة كثيرة المتجهات المضغوطة في الذاكرة وتعيد ترتيب أفضل النتائج باستخدام نسخ كاملة الدقة على القرص.
البيانات الوصفية والنسخ المتماثلة تضاعف كل شيء. فتخزين نص المقطع الأصلي إلى جانب كل متجه قد يفوق بسهولة حجم المتجهات نفسها. وتخزّن كل نسخة متماثلة نسخة كاملة. كما تضيف قواعد البيانات الفعلية حملًا إضافيًا خاصًا بها، فاعتبر هذه النتائج تقديرًا للتخطيط واترك هامشًا يتراوح بين 20% و50%.
مثال محلول
10 ملايين تضمين بحجم OpenAI (1,536 بعدًا، float32) تشغل 61.44 GB كمتجهات خام. ويضيف فهرس HNSW عند M = 16 نحو 1.34 GB، وتضيف 200 بايت من البيانات الوصفية لكل متجه 2 GB، فتصبح 64.78 GB للنسخة الواحدة. ومع نسختين متماثلتين تحتاج إلى نحو 129.57 GB. والتحويل إلى int8 يخفض المتجهات الخام إلى 15.36 GB.
أمثلة إضافية
التحويل من float32 إلى تكميم int8 لـ 10 ملايين متجه من 1,536 بعدًا يخفض إجمالي التخزين من 129.57 GB إلى 37.41 GB مع نسختين متماثلتين.
استخدام تضمينات من 768 بعدًا بدل 1,536 يخفض تخزين المتجهات إلى نحو النصف: 68.13 GB في المجموع.
أخطاء شائعة
- نسيان النسخ المتماثلة التي تضاعف التخزين.
- إغفال الفهرس والبيانات الوصفية.
- اختيار تضمينات عالية الأبعاد بينما يؤدي نموذج أصغر الأداء نفسه.
- عدم اختبار جودة الاسترجاع بعد التكميم.
أسئلة يطرحها الناس
كم تحتاج التضمينات من مساحة تخزين؟
اضرب عدد المتجهات في عدد الأبعاد وفي 4 بايت لصيغة float32. فمليون متجه من 768 بعدًا يحتاج نحو 3.07 GB، ومليون متجه من 3,072 بعدًا يحتاج نحو 12.29 GB، قبل الفهرس والبيانات الوصفية.
كم تستهلك فهارس HNSW من الذاكرة؟
تقريبًا M × 2 × 4 بايت لكل متجه لروابط الرسم البياني، إضافةً إلى المتجهات نفسها إذا حُفظت في الذاكرة، وهذا ما تفعله معظم تطبيقات HNSW من أجل السرعة. والمتجهات هي التي تهيمن عادةً: فالرسم البياني صغير بالمقارنة ما لم تكن قيمة M كبيرة.
هل يضر التكميم بجودة البحث؟
قليلًا. فـ int8 يُبقي الاسترجاع قريبًا من الدقة الكاملة في العادة. أما التكميم الثنائي فيخسر أكثر، لذا يُستخدم غالبًا لمرحلة أولى سريعة، ثم يُعاد تقييم أفضل المرشحين بالمتجهات الكاملة. اختبر على استعلاماتك أنت قبل التحويل.
هل أختار أبعادًا أقل لتوفير المساحة؟
قد يفيد كثيرًا. فبعض نماذج التضمين تتيح تقصير المتجهات بخسارة صغيرة في الجودة. وتخفيض الأبعاد إلى النصف يخفض تخزين المتجهات إلى النصف ويسرّع البحث. قارن جودة الاسترجاع على بياناتك أنت أولًا.
لماذا قاعدة بياناتي أكبر من هذا التقدير؟
لأن قواعد البيانات تضيف حملها الخاص: سجلات الكتابة المسبقة (write-ahead logs)، والسجلات المحذوفة التي تنتظر التنظيف، وملفات الشرائح (segments)، وفهارس الحمولة على حقول البيانات الوصفية. خصّص هامشًا إضافيًا فوق هذا التقدير.