حجم التضمين: 768، 1536 أو 3072 الأبعاد؟

من الواضح أن الاختيار بين تضمين النص 3 صغير ونص تضمين 3 كبير في البداية يعني الاختيار بين 1536 و3072 بُعدًا أصليًا، حتى قبل الحديث عن الاقتطاع. يلخص الجدول أدناه الحقائق التي يمكن التحقق منها على المستويات الثلاثة التي يتعرف عليها pgvector أصلاً على جانب الفهرسة، ومسار Aurabase.

المصادر: OpenAI، المدونة الرسمية "نماذج التضمين الجديدة وتحديثات واجهة برمجة التطبيقات"، 25 يناير 2024 (نتائج MTEB وأسعار الإطلاق، تحقق من صفحة التسعير الحالية قبل الاستخدام)؛ aura-ai/src/embeddings/mod.rs، Aurabase (دعم الأعمدة والفهرس، تم التحقق منه في 24 أغسطس 2026).

يتم تخزين التضمين مثل مجموعة من أرقام الفاصلة العائمة. في pgvector، يقوم النوع vector الكلاسيكي بتشفير كل بُعد على 4 بايت (float32): وبالتالي، فإن 768 بُعدًا تزن حوالي 3 كيلو بايت من البيانات الأولية لكل متجه، و1536 بُعدًا حوالي 6 كيلو بايت، و3072 بُعدًا حوالي 12 كيلو بايت، حتى قبل حساب رأس pgvector والحمل الزائد لصفحة Postgres.

هذا هو المكان الذي يأتي فيه نوع halfvec من pgvector، الذي يشفر كل بُعد في 2 بايت (float16) بدلاً من 4. يزن المتجه ذو 3072 بُعدًا المخزن في halfvec حوالي 6 كيلوبايت: بالضبط وزن المتجه ذي 1536 بُعدًا المخزن في vectorالكلاسيكي.

نتيجة مباشرة وغير بديهية: في Aurabase، الانتقال من 1536 إلى 3072 أبعاد لا يضاعف مساحة التخزين الفعلية على القرص، حيث يتم الاستعلام عن عمود embedding_3072 عبر قالب halfvec. وبالتالي فإن التكلفة الإضافية الحقيقية لأبعاد 3072 لا تتمثل في القرص بشكل أساسي: إنها سعر نموذج OpenAI المرتبط، ومخرجات دعم الفهرس الأصلي من النوع vector، المفصلة في القسم التالي.

لا يسمح نوع vector من pgvector ببناء فهرس HNSW أو IVFFlat يتجاوز 2000 بُعد. وبالتالي فإن أبعاد 3072 تتجاوز هذا الحد: لا يمكن لاستعلام بحث متجه في عمود vector(3072) أن يعتمد على فهرس تقريبي، فهو يتراجع إلى فحص تسلسلي كامل، وهو غير قابل للاستخدام على مقياس مجموعة RAG في الإنتاج.

يتعامل رمز Aurabase مع هذه الحالة بشكل صريح: يتم تحويل العمود embedding_3072 إلى halfvec(3072) في كل إدراج واستعلام بحث، وهو نوع يمكن لـ pgvector فهرسته لما يصل إلى 4000 بُعد. يظل العمودان 768 و1536 أصليين vector، غير ملقيين، لأنهما لا يقتربان من الحد الأقصى.

// بالنسبة إلى 3072 (>2000)، لا تقوم HNSW بفهرسة النوع `المتجه` → cast halfvec
fn vec_query_parts(dims: usize) -> AuraResult<(&'static str, &'static str, &'static str)> {
    match dims {
        768  => Ok(("embedding_768",  "", "::vector")),
        1536 => Ok(("embedding_1536", "", "::vector")),
        3072 => Ok(("embedding_3072", "::halfvec(3072)", "::halfvec(3072)")),
        other => Err(...), // البعد غير معتمد
    }
}

تشرح هذه التفاصيل أيضًا سبب فشل بُعد التضمين غير المُدرج في [768, 1536, 3072] بشكل صريح على جانب Aurabase، بدلاً من قبوله ومن ثم فهرسته بشكل سيئ: يأتي اسم العمود دائمًا من قائمة مسموح بها ثابتة، وليس من قيمة مجانية يرسلها العميل أبدًا. للتعمق أكثر في إنشاء فهرس HNSW على Postgres بما يتجاوز هذه الحالة المحددة، راجع مقالتنا فهرس HNSW وبحث متجهات Postgres.

اعتبارًا من يناير 2024، تقبل واجهة برمجة التطبيقات Embeddings API الخاصة بـ OpenAI معلمة dimensions التي تعمل على تقصير المتجه الذي تم إرجاعه دون إعادة استدعاء نموذج مختلف. يُطلق على هذه التقنية اسم تعلم تمثيل ماتريوشكا: حيث يتم تدريب النموذج على تركيز المعلومات المفيدة في الأبعاد الأولى للمتجه، بحيث يفقد الاقتطاع الدقة تدريجيًا وليس بشكل مفاجئ.

توضح OpenAI فعالية هذه التقنية بمثال محدد في إعلانها: text-embedding-3-large، الذي تم اقتطاعه إلى 256 بُعدًا فقط، ولا يزال يتجاوز درجة MTEB الخاصة بـ text-embedding-ada-002 القديم المستخدم بحجمه الكامل البالغ 1536 بُعدًا (المصدر: OpenAI، المدونة الرسمية، 25 يناير 2024). ناقل أصغر بـ 12 مرة والذي يؤدي أداءً أفضل من المتجه الكامل، وفقًا لهذا المعيار المحدد.

let body = json!({
    "model": self.embed_model,       // على سبيل المثال "تضمين النص-3-كبير"
    "input": text,
    "dimensions": self.embed_dimensions, // يقتطع 3072 → القيمة التي تم تكوينها
});

نقطة مهمة، وغالبًا ما يُساء فهمها: الاقتطاع لا يقلل من السعر الذي يتم تحصيله. تتقاضى OpenAI رسومًا بناءً على النموذج الذي تم الاستعلام عنه، وليس حجم المتجه الذي يتم إرجاعه، نظرًا لأن التكلفة الفعلية هي الحساب الذي يتم إجراؤه على النص المُدخل. وبالتالي فإن طلب 1536 بُعدًا من text-embedding-3-large يكلف نفس سعر أبعاده الأصلية 3072 (المصدر: OpenAI، المدونة الرسمية، 25 يناير 2024)؛ فقط تتغير سرعة التخزين والبحث.

هذا هو بالضبط الاختيار الافتراضي لـ Aurabase، الذي تم التحقق منه في config/mod.rs: النموذج الذي تم تكوينه افتراضيًا هو text-embedding-3-large، لكن بُعد الإخراج الذي تم تكوينه افتراضيًا هو 1536، وليس 3072. وبالتالي تدفع الخدمة مقابل تمثيل النموذج الواسع، الذي يتم اقتطاعه ليظل في عمود vector قابل للفهرسة في HNSW الأصلي، دون الحاجة إلى قالب halfvec 3072.

تظل أبعاد 1536 هي نقطة البداية المعقولة لغالبية RAG أو مشاريع البحث الدلالي: تظل درجة MTEB الخاصة بدمج النص 3-صغير (62.3%) قريبة من درجة النموذج الكبير، ويظل التخزين خفيفًا، والنوع الكلاسيكي vector من فهارس pgvector في HNSW دون أي تكوين معين.

يتم تبرير أبعاد 3072 عندما تكون المجموعة غامضة أو تقنية، حيث تترجم فجوة الجودة بين 62.3% و64.6% إلى نتائج بحث أفضل بشكل واضح على استعلاماتك الخاصة، وليس على معيار OpenAI العام. تشير العديد من تعليقات الفريق المسجلة في مناقشات مجتمع مطوري OpenAI إلى هذا الاتجاه: يتم قياس كسب 3072 بُعدًا على أساس كل حالة على حدة، ولا يمكن افتراض ذلك.

تعد أبعاد 768 مناسبة بشكل خاص عندما يكون للحجم الأسبقية على الفروق الدقيقة: مجموعة كبيرة حيث تكون ميزانية التخزين أو الحساب هي القيد الحقيقي، أو استخدام نموذج تضمين قديم بالفعل في 768 بُعدًا أصليًا.

يعد اختيار البعد هذا جزءًا من مكدس RAG أكبر، والتضمينات، وفهرس HNSW، والبحث المختلط، الذي توثقه صفحتنا Native AI.

الأبعاد 768 و1536 و3072 غير مقسمة على محور واحد. 3072 مكاسب في درجة MTEB التي نشرتها OpenAI، لكنها تترك دعم HNSW الأصلي لـ pgvector وتدفع ثمن النموذج الكبير، مهما كان البعد المطلوب في النهاية. يظل 1536 هو الرصيد الافتراضي الأكثر شيوعًا، بما في ذلك في Aurabase. يخدم 768 الحالات التي يكون فيها للحجم الأسبقية على الفروق الدقيقة.

تعمل معلمة dimensions الخاصة بـ OpenAI على تغيير السؤال الذي يجب طرحه: لم يعد السؤال "أي نموذج يجب اختياره"، ولكن "أي اقتطاع يجب قبوله، وما الربح الذي تم قياسه في مجموعتي". قبل الانتهاء من الاختيار في الإنتاج، اختبر جودة البحث على عينة حقيقية، وليس فقط على معيار عام. يقدم دليلنا خط أنابيب RAG المزود بـ pgvector تفاصيل الإعداد الكامل، بدءًا من الاستيعاب وحتى البحث المختلط.