تُصدر Pinecone إضافة pg_pinecone مفتوحة المصدر للبحث في Postgres

Pinecone أصدرت في 27 أكتوبر 2026 إضافة pg_pinecone مفتوحة المصدر لـPostgres، مرخّصة بموجب Apache 2.0، وتنقل إلى أعمدة pgvector التي تخزّنها التطبيقات بالفعل محرك البحث المتجهي الذي تقول الشركة إنها تشغّله على نطاق واسع. وفي المعايير التي أعلنتها الشركة، بلغ حجم الفهرس الأصلي للإضافة 136 ميغابايت لمليون متجه ذي 768 بُعدًا، مقابل 2.0 غيغابايت لفهرس HNSW باستخدام halfvec و4.1 غيغابايت للمتجهات كاملة الحجم.

عُرض الإصدار في منشور إعلان كتبته هارشيتا دادالا وأنتوني ماهانا. ووفقًا للمنشور، تتمثل الطريقة الشائعة لإجراء البحث المتجهي في Postgres في استخدام فهرس بياني مثل HNSW، الذي يتطلب ذاكرة متزايدة للحفاظ على الأداء، ويستغرق وقتًا طويلًا في إنشائه، وتتراجع دقته عند البحث باستخدام المرشحات؛ فعندما يقتصر الاستعلام على مستخدم واحد أو مستأجر واحد، قد يعيد الفهرس البياني عددًا من الصفوف أقل مما يحدده LIMIT في الاستعلام. أما pg_pinecone، فيطبّق المرشح أثناء البحث، ما يتيح، بحسب Pinecone، إعادة مجموعة كاملة من النتائج حتى عند تضييق نطاق البحث، كما تبقى البيانات داخل Postgres عند استخدام المحرك الافتراضي.

ثلاثة محركات لفهرس واحد

يعمل pg_pinecone مع أعمدة المتجهات المخزّنة بالفعل في pgvector. ويتصل التطبيق بـPostgres بالطريقة نفسها ويرسل تعليمات SQL نفسها، مثل ORDER BY embedding <=> $1 LIMIT 10، فيما تبقى الجداول، بما فيها المتجهات كاملة الحجم، في مواقعها، وتظل Postgres النظام المرجعي للبيانات.

يستخدم كل جدول محركًا واحدًا من ثلاثة محركات. ينشئ المحرك الأصلي، وهو الخيار الافتراضي، فهرسه ويبحث فيه بالكامل داخل Postgres، من دون الحاجة إلى حساب لدى Pinecone أو مفتاح API أو اتصالات بالشبكة. ويبحث محرك pgvector في فهرس pgvector موجود، سواء أكان HNSW أم IVFFlat، ويصفه مستودع المشروع على GitHub بأنه مناسب للجداول التي لديها بالفعل فهرس pgvector ولا تستخدم المرشحات. أما المحرك البعيد، فيوجّه البحث إلى فهرس بلا خوادم ضمن الخدمة المُدارة من Pinecone، وهو مخصص للجداول التي تجاوز حجمها قدرة خادم Postgres واحد. ولا يتطلب التبديل بين المحركات لجدول ما سوى استدعاء واحد لـpinecone.set_engine()، ولا تتغير الاستعلامات، ويمكن التراجع عن كل تبديل.

آلية البحث في المحرك الأصلي

مثل HNSW في pgvector، يستخدم المحرك الأصلي خوارزمية تقريبية للعثور على أقرب الجيران، لكنه يستبدل الرسم البياني بفهرس ملفات معكوسة يجمع المتجهات المتشابهة في عناقيد. ويُخزَّن كل متجه على هيئة رمز RaBitQ مكمَّم، يتألف من نحو بت واحد لكل بُعد، إضافة إلى بضعة أعداد للتصحيح، باستخدام طريقة يعزو المنشور الفضل فيها إلى Gao وLong في SIGMOD 2024. وتُرصّ رموز كل عنقود معًا، بحيث يقرأ البحث بضع صفحات متجاورة بدلًا من التنقل بين أجزاء الرسم البياني.

تُجرى عملية البحث في ثلاث خطوات: أولًا، تُحدَّد العناقيد الأقرب بمقارنة متجه الاستعلام بمركز كل عنقود؛ ثم تُحسب مسافة تقديرية لكل صف استنادًا إلى رمز RaBitQ الخاص به، وتُحتفظ بأفضل النتائج المرشحة؛ وأخيرًا، يُعاد ترتيب هذه النتائج المرشحة باستخدام متجهاتها كاملة الحجم من الجدول.

يُطبَّق الترشيح ضمن عملية البحث نفسها. وقالت Pinecone إن HNSW في pgvector يطبّق المرشحات بعد البحث، إذ يعثر أولًا على أقرب الجيران ثم يطبّق شرط WHERE، ولذلك يستبعد المرشح الضيق معظم النتائج المرشحة، وتُعيد عمليات المسح التكرارية ملء القائمة على حساب الوقت، وكذلك الدقة عند استخدام relaxed_order. ويخزّن المحرك الأصلي قيمة عمود المرشح بجوار رمز كل صف، ويحصي عدد الصفوف لكل قيمة عند إنشاء الفهرس. وعند استخدام مرشحات ضيقة، أي افتراضيًا عندما تشمل 3% من الصفوف أو أقل، يطبّق المحرك المرشح مسبقًا، فيفحص كل صف مطابق عبر جميع العناقيد ويقيّمه باستخدام متجهه كاملًا، لتكون النتائج دقيقة تمامًا. أما مع المرشحات الأوسع، فيستخدم الترشيح على مرحلة واحدة، فيبحث في ما يصل إلى نصف أقرب العناقيد ويفحص المرشح داخل كل عنقود قبل التقييم.

تُضاف السجلات الجديدة إلى أقرب عنقود وتصبح قابلة للبحث فورًا. وبما أن مراكز العناقيد تظل في المواقع التي حُددت لها عند إنشاء الفهرس، يوصي المنشور بتشغيل REINDEX أو تفعيل الصيانة التلقائية بعد تغييرات كبيرة، مثل تحميل دفعة كبيرة تضاعف حجم الجدول، لإعادة موازنة العناقيد.

المعايير التي أبلغت عنها Pinecone

قارنت Pinecone المحرك الأصلي بفهرس HNSW في pgvector، باستخدام متجهات كاملة الحجم وhalfvec، على مليون متجه من wiki_dpr بأبعاد تبلغ 768. وأُجريت الاختبارات على مثيل AWS r6id.4xlarge يضم 16 وحدة معالجة مركزية افتراضية و128 غيغابايت من ذاكرة الوصول العشوائي؛ وقيس زمن الاستجابة غير المقيّد بمرشحات، ووقت إنشاء الفهرس، وحجمه في جلسة واحدة على PostgreSQL 17، فيما اختُبر البحث المقيّد بمرشحات في جلسة أخرى على PostgreSQL 18، وأُجري الاختبار بإعداد يحدّ الذاكرة في جلسة ثالثة. ويُعرض زمن الاستجابة بوصفه الوسيط p50 عند k=10 وباستخدام عميل واحد، وقالت الشركة إن الإعداد الكامل والأوامر اللازمة لإعادة تشغيل الاختبارات متاحة في ملف README الخاص بإطار الاختبار المعياري في المستودع.

بالنسبة إلى مليون متجه، أفادت Pinecone بأن حجم الفهرس الأصلي بلغ 136 ميغابايت، مقارنةً بـ2.0 غيغابايت لفهرس HNSW باستخدام halfvec و4.1 غيغابايت للمتجهات كاملة الحجم. وفي البحث غير المقيّد بمرشحات، أبلغت الشركة عن زمن استجابة قدره 1.3 مللي ثانية عند استرجاع قدره 0.95، مقابل 1.7 مللي ثانية لفهرس HNSW باستخدام halfvec و2.7 مللي ثانية للمتجهات كاملة الحجم؛ كما بلغ زمن الاستجابة 2.3 مللي ثانية عند استرجاع قدره 0.99، مقابل 4.7 و6.7 مللي ثانية. وعند استخدام مرشح يطابق 10% من الصفوف، أفادت Pinecone بأن المحرك الأصلي حقق استرجاعًا قدره 1.000 في 12.3 مللي ثانية باستخدام الترشيح على مرحلة واحدة، بينما حقق HNSW مع عمليات المسح التكرارية استرجاعًا بلغ 0.920 كحد أقصى في 5.9 مللي ثانية؛ ومع مرشح يشمل 1% من الصفوف، بلغ الاسترجاع 0.981 في 8.3 مللي ثانية. وبلغ وقت إنشاء الفهرس، وفقًا لما أُعلن، 45 ثانية للمحرك الأصلي، مقابل 62 ثانية لفهرس HNSW باستخدام halfvec و79 ثانية للمتجهات كاملة الحجم.

التوافر وميزات Pinecone الاختيارية

يتطلب pg_pinecone استخدام PostgreSQL 17 أو 18، وصلاحيات المستخدم المتميز، وتثبيت pgvector على الخادم. ويمكن تثبيته من الإصدارات المُعدّة مسبقًا على GitHub، أو باستخدام صورة pineconeteam/pg_pinecone على Docker Hub، التي يصفها ملف README بأنها صورة pgvector/pgvector مضافًا إليها pg_pinecone، وتُنشر بوسم واحد لكل إصدار رئيسي من Postgres، مثل 0.11.0-pg17. ويتطلب تشغيل المحرك البعيد أيضًا تحميل الامتداد عبر shared_preload_libraries. ينشئ الإعداد امتدادي vector وpg_pinecone، ويبني فهرسًا باستدعاء pinecone.create_index()، كما يمكن بناء المشروع من المصدر باستخدام مجموعة أدوات Rust وcargo-pgrx 0.19.2.

باستخدام مفتاح Pinecone API اختياري، يزامن المحرك البعيد التضمينات مع فهرس Pinecone في الخلفية، بينما يستمر تنفيذ عمليات البحث في Postgres إلى أن يكتمل النسخ. ويذكر المنشور ثلاث ميزات اختيارية أخرى: تستدعي embed() خدمة الاستدلال من Pinecone لتحويل النصوص إلى تضمينات عبر SQL، وتعمل مع المحركين الأصلي والبعيد، كما تغطيها الخطة المجانية من Pinecone عند إنشاء أول تضمين؛ وتتيح ميزة البحث النصي الكامل BM25 إجراء عمليات البحث بالتوازي مع البحث المتجهي على الجدول نفسه، مع إمكانية تنفيذ استعلامات BM25 أو الاستعلامات المتجهية أو الهجينة عبر SQL؛ أما rerank() فتعيد ترتيب النتائج الأعلى باستخدام نماذج إعادة الترتيب من Pinecone.

تتناول الوثائق على docs.pinecone.io التثبيت ومحركات التخزين والتبديل بين المحركات والبحث النصي الكامل، فيما يضيف المستودع مرجعًا لـSQL ودليلًا إجرائيًا للمشغّلين ودليلًا للتعافي من الكوارث. ووصفت Pinecone هذا الإصدار بأنه الأول للمشروع، وقالت إنها تتولى صيانة pg_pinecone ومراجعة كل طلب سحب، وإنها ستضع خارطة الطريق العامة للمشروع بالاستناد إلى الملاحظات الواردة عبر بلاغات GitHub ومجتمع Discord والساعات المكتبية الشهرية.