ما بعد قواعد البيانات الشعاعية: هندسة بحث دلالي عالي الأداء على الأجهزة باستخدام Expo وPGlite

خلال العام الماضي، كان هوس الصناعة واضحاً: معماريات RAG (Retrieval-Augmented Generation) المستضافة على قواعد بيانات شعاعية (vector databases) سحابية ضخمة مثل Pinecone أو Weaviate. وبينما تعد هذه الحلول رائعة لتطبيقات الويب على مستوى الشركات، إلا أنها تسبب احتكاكاً كبيراً لمطوري تطبيقات الجوال: زمن الوصول (latency)، التكاليف، والمتطلب الحتمي للاتصال بالبيانات.

لقد كنت أختبر نقل الذكاء ليكون أقرب إلى المستخدم. كان هدفي بناء محرك بحث دلالي عالي الأداء ويعمل بالكامل بدون اتصال (offline) داخل تطبيق Expo (React Native). جاءت الانطلاقة عندما قمت بدمج PGlite — وهو بناء لـ Postgres يعتمد على WASM — مع دعمه الأصلي للـ vector.

إليكم كيف تجاوزت السحابة ولماذا تعد هذه المعمارية نقطة تحول للذكاء الاصطناعي المحلي (local-first AI).

المشكلة في نهج الـ Vector "السحابي أولاً"

عندما نبني تطبيقات الجوال، غالباً ما نعاملها كعملاء "نحيفين" (thin clients). بالنسبة للبحث الدلالي، التدفق التقليدي هو:

1. توليد embedding على خادم (أو استدعاء OpenAI).
2. الاستعلام من قاعدة بيانات شعاعية بعيدة.
3. استرجاع الـ IDs وجلب البيانات من API منفصل.

على جهاز الجوال، يبدو هذا المسار بطيئاً. إذا كان المستخدم على اتصال 5G غير مستقر، تنهار التجربة. والأهم من ذلك، أن العديد من حالات الاستخدام التي أهتم بها — مثل البحث في المذكرات الشخصية أو المستندات الخاصة — لا ينبغي أبداً أن تغادر الجهاز من منظور الخصوصية.

دخول PGlite: الـ Postgres في المتصفح (والجوال)

تعد PGlite من فريق ElectricSQL ثورة في هذا المجال. إنها نسخة من Postgres تم تجميعها إلى WASM، ومعبأة كمكتبة خفيفة الوزن. تتيح لك تشغيل نسخة كاملة من Postgres في الذاكرة (in-memory) أو حفظها في نظام الملفات (مثل IndexedDB أو OpFS).

ما يجعلها "التطبيق القاتل" (killer app) للذكاء الاصطناعي المحلي هو دعمها للإضافات — وتحديداً pgvector. هذا يعني أنه يمكننا تشغيل عمليات بحث تشابه الجيب تمام (cosine similarity) باستخدام صيغة SQL القياسية مباشرة على جهاز الجوال.

المعمارية

في تنفيذي، استخدمت "كدسة" (stack) محلية من ثلاث طبقات:

1. Expo (React Native): البيئة المضيفة.
2. Transformers.js: لتوليد الـ embeddings على العميل (باستخدام نموذج quantized مثل all-MiniLM-L6-v2).
3. PGlite + pgvector: لتخزين تلك الـ embeddings والاستعلام عنها.

إعداد قاعدة البيانات

أولاً، كان عليّ تهيئة PGlite للتعامل مع إضافة vector. إليك منطق التهيئة الأساسي الذي استخدمته:

import { PGlite } from "@electric-sql/pglite";
import { vector } from "@electric-sql/pglite/vector";

let db: PGlite | null = null;

export const getDb = async () => {
  if (db) return db;

  db = await PGlite.create({
    dataDir: 'idb://my-local-db', // Or filesystem for native Expo
    extensions: {
      vector,
    },
  });

  // Initialize the vector extension and create the table
  await db.exec(`
    CREATE EXTENSION IF NOT EXISTS vector;
    CREATE TABLE IF NOT EXISTS documents (
      id SERIAL PRIMARY KEY,
      content TEXT,
      embedding vector(384) -- Dimension for all-MiniLM-L6-v2
    );
    CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
  `);

  return db;
};

الانطلاقة: الأداء مع التوسع

كان أحد أكبر مخاوفي هو أداء الفهرسة (indexing). تشغيل فهرس Hierarchical Navigable Small World (HNSW) في بيئة WASM بدا وكأنه وصفة لتجميد واجهة المستخدم.

ومع ذلك، وجدت أنه بالنسبة لمجموعات البيانات التي تقل عن 10,000 vector (وهو ما يغطي معظم حالات استخدام الجوال الشخصية)، كان زمن وصول البحث أقل من 15ms. فهرس HNSW في pgvector محسن للغاية، وحتى مع عبء (overhead) WASM، فإنه يتفوق على أي تنفيذ مخصص للجيران الأقرب (nearest-neighbor) يعتمد على JavaScript قمت بتجربته.

تنفيذ بحث دلالي

بمجرد توليد embedding للاستعلام محلياً، يصبح استعلام SQL مألوفاً للغاية:

async function semanticSearch(queryVector: number[]) {
  const db = await getDb();
  const results = await db.query(`
    SELECT content, embedding <=> $1 AS distance
    FROM documents
    ORDER BY distance ASC
    LIMIT 5;
  `, [JSON.stringify(queryVector)]);
  
  return results.rows;
}

العقبات الهندسية والحلول البديلة

لم يكن الأمر سهلاً تماماً. هناك بعض الأشياء التي يجب أن تكون على دراية بها عند تنفيذ ذلك:

1. حدود ذاكرة WASM: في بيئة الجوال، تكون إدارة الذاكرة صارمة. كان عليّ التأكد من عدم تضخم نسخة PGlite من خلال إدارة حجم الـ vectors بعناية وتجنب تخزين الكتل الكبيرة (large-blob) غير الضرورية في نفس الجدول.
2. Native Threading: محرك JS في Expo (Hermes) سريع، لكن تنفيذ WASM قد يظل يحظر الخيط الرئيسي (main thread) إذا كنت تقوم بعمل ثقيل. قمت بنقل توليد الـ embedding واستعلامات PGlite إلى Web Worker (في الويب) أو استخدمت expo-standard-web-crypto لإبقاء العمليات الحسابية بعيدة عن الحلقة الرئيسية قدر الإمكان.
3. تحميل النموذج: تحميل ملف نموذج بحجم 90 ميجابايت على الهاتف هو تكلفة تدفع لمرة واحدة، ولكنك تحتاج إلى تخزينه مؤقتاً (cache) بقوة باستخدام expo-file-system لتجنب إعادة التحميل في كل مرة يعمل فيها التطبيق.

لماذا يهم هذا؟

نحن ننتقل نحو عصر "الذكاء الاصطناعي المحلي أولاً" (Local-First AI). من خلال نقل البحث الشعاعي إلى الجهاز، نحقق:

• زمن وصول صفر: لا رحلات ذهاب وإياب إلى خادم في فرجينيا.
• الخصوصية افتراضياً: بيانات المستخدم لا تغادر الجهاز أبداً. إذا كان الهاتف مشفراً، فقاعدة البيانات مشفرة.
• كفاءة التكلفة: لا فواتير بقيمة 50 دولاراً شهرياً لقاعدة بيانات شعاعية مستضافة تكون خاملة في معظم الأوقات.

أثبت بناء هذا المشروع باستخدام Expo وPGlite أن Postgres لم يعد مخصصاً للخوادم فقط. إنه قاعدة بيانات جوال هائلة، مع pgvector تحول تطبيق React Native القياسي إلى أداة ذكاء اصطناعي متطورة.

إذا كنت لا تزال ترسل جميع الـ embeddings الخاصة بك إلى السحابة، فإنني أوصي بشدة بتجربة PGlite. مستقبل الذكاء الاصطناعي ليس فقط في مراكز البيانات — إنه في جيبك.