لا تستطيع النماذج اللغوية الكبيرة (LLM) «رؤية» سوى قدر محدود من النص دفعة واحدة، وهو نطاق السياق. ينجح ذلك في المهام الصغيرة، لكنه لا يجدي عندما تمتد قاعدة المعرفة عبر آلاف الصفحات. حتى عندما يكون نطاق السياق كافيًا، قد يتراجع الأداء بسبب مشكلة «البحث عن إبرة في كومة قش».
برز نمط RAG («التوليد المعزز بالاسترجاع») بوصفه نمطًا شائعًا جدًا؛ إذ تحتفظ بقاعدة معرفة (مستندات، ومواقع ويكي، وسياسات، ونصوص مفرغة، وغيرها)، وتجري بحثًا دلاليًا عن استعلام المستخدم لاسترجاع المقاطع الأكثر صلة باستخدام التضمينات، ثم تمرر تلك المقاطع إلى النماذج اللغوية الكبيرة (LLM) مع السؤال. يحد ذلك من سياق النموذج، ويمكنه عند تنفيذه بطريقة صحيحة تحسين جودة الإجابات وتقليل الهلوسة.
pgai امتداد مفتوح المصدر لـPostgres، مع أدوات مرافقة، يساعدك على إنشاء مسارات عمل «الاسترجاع بالذكاء الاصطناعي» فوق قاعدة البيانات الموثوقة والمفتوحة المصدر PostgreSQL.
تتمثل الفكرة الأساسية في نقل أجزاء أكبر من مسار RAG القياسي إلى طبقة قاعدة البيانات (الإدخال ← التقسيم ← التضمين ← إبقاء التضمينات متزامنة)، بدلًا من اعتبار قاعدة البيانات «مجرد مساحة تخزين» للتضمينات.
تشير انطباعاتنا الأولية إلى أنه واعد، لكنه يصبح غير مناسب ما إن يزداد مسار RAG تعقيدًا ولو قليلًا، ولا سيما في أساليب التقسيم. ومع ذلك، سنواصل متابعة هذا المشروع عن كثب.
هناك طرق كثيرة لإنشاء RAG. وللاطلاع على شرح أطول لمختلف الأساليب، اقرأ أمثلة عملية لحلول RAG المخصصة. يتسع نطاق خيارات التصميم على نحو مدهش عندما تصبح الجودة أولوية، ويبدو الأسلوب «الافتراضي» الشائع عادةً كما يلي:
اجمع مجموعة من المستندات.
قسّمها إلى مقاطع. توجد طرق عديدة لذلك، مثل الفقرات والتجميعات الدلالية.
حوّل كل مقطع إلى تضمين.
خزّن التضمينات في قاعدة بيانات متجهية (مثل Pinecone وMilvus) أو في Postgres باستخدام pgvector.
عند ورود الاستعلام، ابحث عن أقرب المقاطع `ومررها إلى النماذج اللغوية الكبيرة (LLM) (ومجددًا... توجد طرق عديدة لفعل ذلك أيضًا).
في كثير من البنى التقنية، تُنفّذ الخطوات (1)–(3) خارج قاعدة البيانات، ضمن كود التطبيق أو مسار بيانات، وتُستخدم قاعدة البيانات أساسًا في:
تخزين التضمينات
البحث في التضمينات
pgai امتداد لـPostgres مفتوح المصدر، طوّرته Timescale)، ويسعى إلى طمس ذلك الحد الفاصل.
بدلًا من التعامل مع التضمينات كشيء يديره تطبيقك يدويًا، يجعلها pgai إحدى ميزات قاعدة البيانات:
تحدد الجدول أو المستندات التي تريد إنشاء تضمينات لها.
تحدد نموذج التضمين واستراتيجية التقسيم.
يتولى pgai بقية المهام، بما فيها تحديث التضمينات باستمرار مع تغيّر بيانات المصدر.
وهذا الوعد جذاب:
قدر أقل من الكود المخصص للربط الذي يحتاج إلى صيانة.
يُفترض أن يصبح إبقاء التضمينات «محدّثة» أسهل مع تغيّر مستندات المصدر الأساسية.
يتولى Postgres/pgai إدارة إعادة المحاولات وحدود المعدل والمهام الفاشلة وغيرها.
ملاحظة للقارئ: تتضمن حزمة pgai امتداد pgvector، وهو امتداد آخر شائع جدًا لـRAG في Postgres. يضيف pgvector تخزين المتجهات والبحث بالتشابه إلى Postgres، بينما يعتمد pgai عليه لأتمتة خطوات مسار RAG، مثل التقسيم والتضمين وإبقاء التضمينات محدّثة.
1) تشغيله سهل ومباشر.
مسار الإعداد المثالي بسيط إلى حد معقول:
اسحب صور Docker من Timescale (قاعدة البيانات + العامل).
أدخل مفتاح API لموفر التضمين.
نفّذ قدرًا بسيطًا من SQL لتعريف أداة التحويل إلى متجهات (أي ما تريد تضمينه، وكيفية تقسيمه، والنموذج المستخدم).
بعد ذلك، يرتب pgai لتشغيل عامل التحويل إلى متجهات كعملية منفصلة وإنشاء التضمينات بصورة غير متزامنة، مثلًا كل 5 دقائق أو وفق أي وتيرة تريدها.
2) من المفيد تنفيذ المسار كاملًا «بالقرب» من قاعدة البيانات.
يستطيع pgai إدخال المحتوى من الجداول، كما يمكنه تحميل المستندات من مواقع مثل S3، ثم تحليلها وتقسيمها وإنشاء تضمينات لها. ويمكنه أيضًا التعامل مع صيغ مختلفة للمستندات النصية، مثل PDF وMarkdown وغيرها.
1) تفقد قدرًا كبيرًا من التحكم (وأحيانًا يحتاج RAG إلى هذا التحكم).
غالبًا ما تتطلب أنظمة RAG العالية الأداء، عند قياسها بجودة الإجابات، مسارات مخصصة، مثل:
قواعد تقسيم مخصصة (حسب العناوين أو الصفحات أو أدوار المتحدثين وغيرها)
تقسيم يراعي البيانات الوصفية (الاحتفاظ بعناوين الأقسام والطوابع الزمنية والمؤلفين ونوع المستند)
استراتيجيات تضمين مختلفة لكل نوع من المستندات
يوفر pgai مرونة أقل في الجوانب المذكورة أعلاه.
توجد حاليًا استراتيجيتان أساسيتان للتقسيم: مقسّم النص حسب المحارف، ومقسّم النص التكراري حسب المحارف، إضافة إلى خيار عدم التقسيم. قد يكفي ذلك لبعض حالات الاستخدام، لكن كثيرًا من أنظمة RAG الإنتاجية تتطلب تخصيصًا أكبر.
سيكون رائعًا أن تدمج Timescale بعض استراتيجيات التقسيم الأكثر تطورًا التي نراها في مكتبات مثل Chonkie، وأن تدعم بالمثل تصميمات متقدمة مثل الاسترجاع السياقي من Anthropic.
2) يركز على النص أولًا، وليس على الوسائط المتعددة.
لم تعد كثير من مشكلات RAG المثيرة للاهتمام نصية بحتة:
ملفات PDF تتضمن مخططات
لقطات شاشة / صور
تسجيلات صوتية
مقاطع فيديو
حتى إن أمكنك «استخراج النص» من هذه المصادر، فلا يعادل ذلك مسار تضمين حقيقيًا متعدد الوسائط.
إذا دعم pgai مستقبلًا النماذج متعددة الوسائط من البداية إلى النهاية (تحميل ← تقسيم ← تضمين للصور أو الملفات الصوتية أو مقاطع الفيديو الكبيرة المخزنة في S3، مع مزامنة موثوقة)، فسيكون ذلك مقنعًا؛ لكنه اليوم مجرد مسار عمل لتضمين النصوص.
3) إذا كنت تحتاج إلى التضمينات فقط، فقد لا تحتاج إلى pgai.
إذا كان مسار إدخال البيانات لديك مخصصًا بالفعل، أو يجب أن يكون كذلك، فإن «إنشاء تضمينات لمقاطع النص» ليس أصعب جزء في RAG. في هذه الحالة، يحل pgai أسهل جزء من المشكلة.
كذلك، إذا كانت قاعدة معرفتك نادرًا ما تُحدّث، فلن تكون قيمة المزامنة التلقائية للتضمينات كبيرة بالقدر نفسه.
من الاستخدامات المفيدة جدًا لـpgai نشر واجهة لتحويل النص إلى SQL فوق قواعد بياناتك. يمكن تحقيق ذلك بسهولة بالغة باستخدام الوحدة semantic_catalog التي يوفرها pgai. ما عليك سوى إعدادها هكذا:
Bash
ثم اجعل الكتالوج الدلالي يستخرج قواميس بياناتك باستخدام pgai semantic-catalog create. يؤدي ذلك إلى إنشاء سياق من مخزن بياناتك يبدو على النحو التالي:
Plain Text
أصبح هذا السياق متاحًا الآن لـpgai بطرق متنوعة؛
عبر البحث الدلالي:
سيُرجع هذا الاستعلام الجداول والدوال والكائنات الأخرى التي قد تكون ذات صلة باستعلامك المكتوب بلغة طبيعية:
Bash
الحصول على السياق الخام:
سيعرض ذلك سياق YAML الخام المرتبط باستعلامك المكتوب بلغة طبيعية:
Bash
إنشاء SQL:
أو يمكنك إنشاء SQL الخام المطلوب للإجابة عن استعلامك مباشرةً. يُرسل سياق الخطوة السابقة إلى أحد النماذج اللغوية الكبيرة (LLM)، ثم تُنشأ الاستجابة:
Bash
إذا كنت تنشئ نظام RAG بسيطًا نسبيًا، فإن pgai يستحق التجربة إن كنت تريد:
استخدام Postgres بوصفه نظام السجل الأساسي،
أقل قدر من كود الربط،
تضمينات تظل متزامنة تلقائيًا،
طريقة سريعة لتطبيق تحويل النص إلى SQL على قواعد بياناتك،
تجربة أدوات RAG وامتدادات Postgres الجديدة.
ربما يجدر بك الانتظار قبل استخدام pgai إذا كان مسار RAG لديك يحتاج إلى أي مما يلي:
منطق مخصص ومعقد لإدخال البيانات أو تقسيمها
أنواع كثيرة من المستندات ذات متطلبات تحليل مختلفة
تضمينات متعددة الوسائط
أخيرًا، رغم وضوح الانتشار الواسع لـpgvector، لا يزال من غير الواضح ما إذا كان pgai سيحظى بالمستوى نفسه من الاهتمام، وبالتالي الدعم، مع الأخذ في الاعتبار أنه لم يظهر إلا قبل نحو 18 شهرًا.
يقدم pgai نهجًا مثيرًا للاهتمام في RAG، يتيح لقواعد البيانات تولي مزيد من الأعمال التشغيلية الروتينية، ما يجعل كود تطبيقك أبسط.
في الوقت الحالي، هو:
قابل للاستخدام وممتع فعلًا في إعدادات RAG البسيطة
غير مرن بما يكفي للمسارات الأكثر تخصيصًا، ولا سيما متعددة الوسائط
إنه واعد ويستحق بالتأكيد متابعة تطوره.