Graph RAG واعٍ بالبنية باستخدام PostgreSQL وpgvector

ما الذي يغطيه هذا الشرح العملي لـ Graph RAG باستخدام PostgreSQL وpgvector؟

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

يقدم البحث الموثق post-graph-rag نهجاً أصيلاً في PostgreSQL لمعالجة هذه التحديات. فالفكرة المعمارية الأساسية مباشرة: تخزين المقاطع النصية مع التضمينات، ورسم بياني معياري للكيانات، وملخصات المجتمعات في قاعدة PostgreSQL واحدة. يُستخدم pgvector للبحث الدلالي، وتُستخدم جداول الحواف العلائقية لاجتياز الرسم البياني. وبدلاً من صيانة أنظمة منفصلة للمتجهات والرسوم البيانية والمستندات، يضع هذا التصميم الأدلة القابلة للاسترجاع وتمثيل الرسم البياني في منصة بيانات واحدة.

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

والنتيجة هي إطار أكثر فائدة لفهم Graph RAG. فالرسم البياني ليس مجرد قاعدة بيانات إضافية أو طبقة عرض مرئي، بل هو في هذا النهج أدلة منظمة مرتبطة بالنص المصدر، وتحكمها بوابات جودة، وتراعي ما إذا كانت العبارة حالية أو تم تجاوزها أو كانت منفية.

لماذا لا يكفي الاسترجاع المتجهي المسطح؟

يُعد الاسترجاع المتجهي قيماً لأن التضمينات تستطيع تحديد النصوص المرتبطة دلالياً حتى عندما لا تتطابق صياغة المستخدم تماماً مع صياغة المصدر. لكن نتيجة المتجه تكون عادةً مطابقة على مستوى المقطع. وقد لا توضح كيف يرتبط ذلك المقطع بكيان آخر أو مستند آخر أو إصدار سابق ولاحق للحقيقة نفسها.

تخيل سؤالاً تتوزع إجابته عبر عدة عبارات. قد يعرّف مقطعٌ ما مؤسسةً، ويذكر آخر علاقةً، ويحدد ثالث متى انتهت تلك العلاقة. لا يصرح أي مقطع منفرد بالإجابة الكاملة. يمكن لاجتياز الرسم البياني ربط هذه الحقائق، بينما يوفر استرجاع المقاطع الأدلة النصية الأساسية.

يحدد المصدر الموثق ثلاث تكاليف متكررة في عمليات نشر Graph RAG التقليدية. الأولى هي تكلفة البنية التحتية: إذ قد يتطلب مخزن المتجهات وقاعدة بيانات الرسم البياني ومخزن المستندات أنظمة مستقلة يجب أن تبقى متسقة. والثانية هي تكلفة جودة الرسم البياني: إذ يمكن لعملية استخراج تقبل كل علاقة مولدة أن تملأ الرسم بحواف لا تؤكد إلا القليل أو لا تؤكد شيئاً. والثالثة هي التكلفة الزمنية: إذ يمكن لرسم بياني يراكم الحقائق فقط أن يعامل العبارات المتجاوزة والحالية على أنها متساوية الصلاحية.

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

الخطوة ١: تحديد طبقات الأدلة الثلاث المتكاملة

ابدأ بتحديد طبقات الأدلة المتميزة التي تجتمع في PostgreSQL. تضم المعمارية الموثقة مقاطع نصية مع تضمينات، ورسماً بيانياً معيارياً للكيانات، وملخصات للمجتمعات. تؤدي كل طبقة غرضاً مختلفاً في الاسترجاع، ولا ينبغي اعتبار أي منها بديلاً عن الأخرى.

المقاطع النصية والتضمينات

تحتفظ المقاطع النصية بالمادة المصدرية التي تدعم الإجابة. وتتيح تضميناتها البحث الدلالي عبر pgvector. يجب أن يبقى المقطع المسترجع قابلاً للعزو إلى النص المصدر الذي اشتُق منه. وهذا يحافظ على مسار العودة إلى الأدلة بدلاً من عرض ادعاءات مستمدة من الرسم البياني من دون سياق.

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

الرسم البياني المعياري للكيانات

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

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

ملخصات المجتمعات

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

حافظ على وضوح دور كل طبقة. تدعم المقاطع الأدلة المرتكزة إلى المصدر. ويدعم رسم الكيانات استرجاع الحقائق المترابطة. وتدعم ملخصات المجتمعات سياقاً أوسع على مستوى الرسم البياني. ويمكن لسياسة استرجاع مصممة جيداً أن تحدد أي طبقة، أو أي مزيج من الطبقات، يلائم سؤالاً بعينه.

الخطوة ٢: وضع بوابات الجودة قبل الكتابة إلى الرسم البياني

أهم درس في المصدر الموثق هو أنه لا ينبغي افتراض صحة الاستخراج لمجرد أن نموذجاً أنتج مخرجات. يشغّل تصميم post-graph-rag ثوابت وقت الاستخراج قبل كتابة البيانات. وهذا يحول الرسم البياني من وجهة سلبية للعلاقات المولدة إلى طبقة معرفة مضبوطة ذات معايير قبول صريحة.

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

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

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

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

الخطوة ٣: الحفاظ على النفي بدلاً من إسقاط العلاقات المنفية

تركز كثير من مسارات استخراج المعرفة على العبارات الإيجابية فقط، وهذا يفقد معنى مهماً. فقد ينفي مصدر ما علاقةً صراحة، ويحتاج نظام Graph RAG واعٍ بالأدلة إلى طريقة لتمثيل هذا النفي من دون تحويله إلى حافة إيجابية أو إسقاطه بصمت.

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

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

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

الخطوة ٤: نمذجة الصلاحية والتجاوز عبر الزمن

غالباً ما يكون الزمن هو الفارق بين إجابة صحيحة وإجابة قديمة. فالرسم البياني الذي يضيف الحقائق فقط قد يحتفظ بعبارات متناقضة من دون طريقة منهجية لتحديد أيها يحكم سؤالاً بصيغة الحاضر. يعالج المصدر الموثق ذلك عبر طبقة زمنية.

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

هذا التمييز جوهري. فالمستند اللاحق لا يبطل بالضرورة كل عبارة سابقة. ينطبق التجاوز عندما يكون المستند اللاحق غير متوافق مع الادعاء الأسبق. لذا ينبغي لعملية الاسترجاع أن تراعي العلاقة نفسها وحالتها الزمنية. في سؤال عن الحالة الحالية، أعط الأولوية للأدلة التي ما زالت صالحة وخذ في الحسبان المعلومات اللاحقة غير المتوافقة. وفي سؤال تاريخي، استرجع الأدلة وفق الفترة الزمنية المطلوبة بدلاً من إرجاع أحدث المواد فقط تلقائياً.

يجب أن يظل الاستخراج الزمني مرتبطاً بالنص. لا تخترع تواريخ سريان أو فترات صلاحية لأن العلاقة تبدو مرجحاً أنها تغيرت. إذا عبّر النص عن فترة صلاحية، فخزن هذا المعنى المنظم. وإذا لم يفعل، فاحفظ هذا القيد. يكون نظام Graph RAG أكثر موثوقية عندما يستطيع التمييز بين «الأدلة تقدم نطاقاً زمنياً»، و«مصدر لاحق يتجاوز هذه العلاقة»، و«المصدر المتاح لا يثبت حداً زمنياً».

الخطوة ٥: دمج البحث الدلالي مع اجتياز الرسم البياني

بعد تجهيز الطبقات الثلاث وضوابط الجودة، يمكن للاسترجاع استخدام PostgreSQL بطريقتين متكاملتين. يدعم pgvector البحث عبر المقاطع النصية المضمّنة، وتدعم جداول الحواف الاجتياز عبر العلاقات بين الكيانات المعيارية. وتوفر ملخصات المجتمعات تمثيلاً أوسع لبنية الرسم البياني.

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

لا تعامل اجتياز الرسم البياني كترخيص للإجابة بما يتجاوز الأدلة. يكون المسار متعدد القفزات مفيداً فقط عندما تكون العلاقات المكونة له قد اجتازت بوابات الاستخراج، وكانت حالاتها الزمنية وحالات النفي فيها متوافقة مع السؤال. ينبغي أن يتمكن النظام من تحديد المقاطع التي تدعم العلاقات المستخدمة في الاستجابة.

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

الخطوة ٦: تقييم جودة الأدلة، لا طلاقة الإجابة فقط

ينبغي لتقييم Graph RAG أن يفحص مدى وفاء الرسم البياني للمصدر، واحترام الدلالات الزمنية، ومدى دعم الأدلة المسترجعة للاستجابة فعلياً. فاللغة الطليقة وحدها ليست مؤشراً موثوقاً للجودة.

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

في تقييم الاستخراج، افحص المرشحين المرفوضين إلى جانب العلاقات المقبولة. تحقق من عدم قبول المسندات الغامضة والأسماء الضميرية والكميات المجردة كسجلات رسم بياني تبدو موثوقة. راجع المسندات الموحّدة عند استخدام مفردات اختيارية. وتأكد من تقارب الأسماء المستعارة إلى الرأس المعياري المقصود، ومن بقاء التعبير الأصلي للمصدر قابلاً للفحص.

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

حدود التنفيذ والخطوات التالية المسؤولة

يدعم السياق الموثق محرك Graph RAG أصيلاً في PostgreSQL يستخدم pgvector للبحث وجداول الحواف للاجتياز. لكنه لا يثبت وجود إطار تطبيق إلزامي أو مزود API أو نموذج تضمين أو صياغة Schema أو إعداد فهرس أو رقم معياري أو بنية نشر محددة. ولا ينبغي للفرق عرض هذه الخيارات بوصفها خصائص لـ post-graph-rag ما لم تكن موثقة ومتحققاً منها بشكل مستقل.

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

الدرس الأساسي ليس أن كل تطبيق RAG يحتاج إلى رسم بياني كبير. بل إن البنية وجودة الأدلة والنفي والزمن تؤثر في صحة الإجابة. ويوفر PostgreSQL مع pgvector وجداول الحواف العلائقية أساساً موحداً للفرق التي تحتاج إلى استرجاع دلالي واستدلال واعٍ بالرسم البياني، من دون تقسيم بياناتها تلقائياً بين منصات منفصلة للمتجهات والرسوم البيانية والمستندات.

أهم النقاط

• خزّن المقاطع النصية المضمّنة، ورسماً بيانياً معيارياً للكيانات، وملخصات المجتمعات معاً في PostgreSQL.
• استخدم pgvector للبحث الدلالي وجداول الحواف لاجتياز الرسم البياني.
• ارفض المسندات الغامضة والأسماء الضميرية والكميات المجردة قبل الكتابة إلى الرسم البياني.
• حلّ الأسماء المستعارة إلى رأس كيان معياري واحد مع الاحتفاظ بالأدلة المرتكزة إلى المصدر.
• مثّل العلاقات المنفية بعلامة نفي بدلاً من تحويلها إلى حقائق إيجابية أو تجاهلها.
• نمذج فترات صلاحية العلاقات، ودع المستندات اللاحقة غير المتوافقة تتجاوز الادعاءات السابقة.
• قيّم دعم المصدر وجودة الرسم البياني والصحة الزمنية وسلوك الامتناع عن الإجابة إلى جانب جودة الإجابة.

المصدر

تعتمد المعمارية والمصطلحات الواردة في هذا الشرح العملي على post-graph-rag: محرك Graph RAG أصيل في PostgreSQL مع بوابات جودة وقت الاستخراج ونموذج للعلاقات الزمنية، arXiv.