نماذج ومنصات الذكاء الاصطناعي

Databricks يضيف البحث النصي الكامل والبحث المتجه إلى Lakebase Postgres

mm
أضف Unite.AI إلى مصادرك المفضلة على Google

Databricks في 28 سبتمبر 2026، قدمت Lakebase Search، محرك بحث مدمج لقاعدة بيانات Lakebase Postgres الخاصة بها يُقدَّم عبر امتدادين: lakebasevector للبحث عن أقرب الجيران التقريبي و lakebasetext للبحث النصي BM25. كلا الامتدادين متاحان بشكل عام على AWS و Azure.

تسمح الامتدادات للمطورين بإجراء بحث دلالي، وبحث بالكلمات المفتاحية، وبحث هجين مباشرة داخل Postgres إلى جانب البيانات التشغيلية. صرّح Databricks أن أنظمة OLTP التقليدية لم تُصمم لتلبية متطلبات البحث لوكلاء الذكاء الاصطناعي، الذين يحتاجون إلى استرجاع منخفض الكمون وعالي الدقة وغالبًا ما ينفّذون عمليات بحث موازية ضخمة، وأن حل هذه المشكلة حتى الآن كان يعني ربط محرك بحث مستقل بقاعدة البيانات الأساسية عبر خط أنابيب ETL. وقالت الشركة إنها بنت Lakebase Search استنادًا إلى ملاحظات مئات العملاء في النسخة التجريبية.

نتائج القياس وتطبيق Conexiom

قال Databricks إن lakebase_متجه يقدم ضعف معدل النقل مقارنة بأفضل نظام آخر في اختبار VectorDBBench 100M، الذي يستخدم مجموعة بيانات LAION، وأنه أرخص بأربع مرات من مزود Postgres سحابي يستخدم pgvector، قبل توفير إضافي من التحجيم التلقائي. وأفاد الشركة بأن زمن الاستجابة P99 كان 71 مللي ثانية عند استدعاء 97% من النتائج، مما يعني أن المحرك استرجع الجيران الأقرب الحقيقي بنسبة 97% من الوقت، وأشار إلى أن pgvector و DiskANN تم اختبارهما فقط على نسخة واحدة كبيرة.

كما أفاد Databricks بنتيجة عميل من Conexiom، الذي يُجري بحثًا هجينًا BM25 على أكثر من 100 مليون صف بنصف البصمة الحوسبية لإعداد pgvector السابق. وقالت الشركة إن تكاليف بنية Conexiom التحتية انخفضت ثلاثة أضعاف وزادت معدل النقل خمسة أضعاف مقارنةً بـ pgvector.

“Lakebase Search يمنحنا مستوى جديدًا تمامًا من القابلية للتوسع مقارنةً بـ pgvector، ويفتح إمكانات BM25 في نفس قاعدة البيانات الخالية من الخوادم،” قال Jordan Voves، مهندس AI/ML في Conexiom. “نستخدم Lakebase لربط البيانات بوكلائنا على نطاق واسع.”

حدود Pgvector وراء التصميم

قال Databricks إن pgvector هو الامتداد الأكثر تثبيتًا في Lakebase Postgres، ووصف ثلاث نقاط ألم متكررة لاحظها العملاء عند تشغيله على نطاق واسع.

الأول هو التكلفة التي تتصاعد مع حجم البيانات بدلاً من الاستخدام. يحتفظ pgvector بفهرس HNSW في ذاكرة قاعدة البيانات، وبما أن بحث HNSW يعتمد على تجوال عشوائي في الرسم البياني، فإن الأداء ينخفض بمقدار 10 إلى 50 مرة بمجرد أن ينسكب الفهرس إلى القرص وتتحول الاستعلامات إلى سلاسل من القراءات العشوائية. يأخذ متجه float32 ذو 768 بُعدًا حوالي 3.3 كيلوبايت من الذاكرة بمجرد تضمين روابط الرسم البياني وحمولة Postgres، لذا فإن فهرسًا يضم 100 مليون صف يتطلب تقريبًا 330 جيجابايت من RAM للبقاء مقيمًا، مُوفرًا بالكامل سواءً تم استدعاؤه في الاستعلامات أم لا.

الثاني هو صيانة الفهرس. عندما ينسكب بناء إلى القرص، استغرق فهرس pgvector ما يقرب من 50 ساعة لإنشائه على نسخة سحابية قياسية، وفقًا لـ Databricks، وتواجه عمليات الكتابة نفس الاختناق لأن إدراج متجه يتطلب تجوالًا عشوائيًا وتعديل عدة طبقات من الرسم البياني. وبما أن HNSW لا يمتلك موازنة عالمية، فإن استعادة جودة البحث يعني تشغيل REINDEX كامل، وهي عملية تقفل الجدول وتوقف عمليات الكتابة الإنتاجية.

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

كيف يتم بناء Lakebase_vector

يفصل Lakebase Postgres بين التخزين والحوسبة: البيانات الدائمة تُخزن في تخزين كائنات سحابي منخفض التكلفة، بينما تُستخدم الذاكرة RAM وNVMe المحلي كذاكرات مؤقتة قصيرة الأمد تحتفظ بمجموعة العمل النشطة. وعلى هذا الأساس، دمج Databricks تقنيتين.

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

نظرًا لأن التصميم لا يحتفظ بحالة، فإنه يتدرج إلى الصفر، وعند السكون يدفع المستخدمون فقط مقابل التخزين. أفاد Databricks بأن قياس P90 كان 1.13 ثانية للاستعلام الأول بعد التدرج إلى الصفر على مجموعة بيانات مكوّنة من 100 مليون متجه، كل منها 768 بُعدًا، وقال إن 100 مليون متجه يمكن خدمتها على وحدة حوسبة واحدة من Lakebase Compute Unit.

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

بحث النص BM25 والاستعلامات المختلطة

قال Databricks إن بحث tsvector القياسي في Postgres يفتقر إلى سياق الصلة على مستوى المجموعة. يستخدم lakebase_text حساب تردد المستند العكسي العالمي لتقييم المصطلحات، مما يمنح وزنًا أكبر للمصطلحات النادرة ذات النية العالية وأقل للمصطلحات الشائعة المملوءة. كما يتحقق من حدود الدرجات العليا أثناء عبور الفهرس، متخلصًا من كتل النشر الكاملة التي لا يمكن أن تؤثر على نتيجة أعلى K، وهو ما قالت الشركة إن ذلك يجعل الأداء أسرع من tsvector مع فهارس GIN.

يتيح الجمع بين الامتدادين البحث المختلط الأصلي داخل Postgres: يمكن لاستعلام واحد تطبيق شروط تصفية SQL عادية، وربط جداول تشغيلية حية، ودمج تقييم المتجه الدلالي مع صلة الكلمات المفتاحية BM25. صرّح Databricks أن النظام يتوسع من صف واحد إلى مليار متجه، ومن استعلام واحد في الثانية إلى آلاف دون الحاجة لإعادة تخصيص يدوية، موصفًا التصميم على أنه مخصص لوكلاء الذكاء الاصطناعي الذين يمكن لسير عملهم أن يطلق آلاف طلبات الاسترجاع المتزامنة خلال ثوانٍ.

يُصوّر Databricks Lakebase Search للمستخدمين الذين يرغبون في دمج البيانات التشغيلية وبيانات البحث في قاعدة بيانات واحدة، بينما يظل Databricks AI Search محركه المُدار للاسترجاع الذي يعمل مباشرةً دون إعداد إضافي. يتوفر Lakebase Search بشكل عام على AWS وAzure؛ يمكن للمستخدمين الحاليين لـ Lakebase تمكين الامتدادات، ويمكن للمستخدمين الجدد الاشتراك في Lakebase.

Theo Nash هو متخصص مولَّد بالذكاء الاصطناعي في Unite.AI، يغطي بنية تحتية للذكاء الاصطناعي، الحوسبة، والأنظمة المادية التي تشغّل الذكاء الاصطناعي الحديث. يتركّز عمله على الأسس التقنية وراء أحمال العمل الضخمة للذكاء الاصطناعي، بما في ذلك مراكز البيانات، المعجّلات، الشبكات، ومجموعات البرمجيات التي تربط بينها.

مع منظور تحليلي ومُستند إلى الهندسة، يفحص Theo كيف تُتيح التقدّمات في وحدات معالجة الرسوميات (GPUs)، السيليكون المخصَّص، بنى الذاكرة، والأنظمة الموزَّعة أجيالًا جديدةً من نماذج الذكاء الاصطناعي. يولي اهتمامًا خاصًا للمقايضات في الأداء، كفاءة الطاقة، القابلية للتوسع، والقيود العملية التي تُشكّل نشر البنية التحتية للذكاء الاصطناعي في الواقع.

المقالات التي يكتبها Theo Nash مُولَّدة بالذكاء الاصطناعي وتُراجَع من قِبل فريق التحرير في Unite.AI لضمان الدقة التقنية، الوضوح، وتغطية مسؤولة للمشهد المتطور سريعًا في حوسبة الذكاء الاصطناعي.