10 مقاربات RAG تعمل فعلًا في بيئة الإنتاج: من الأساسي إلى GraphRAG

جمع مطوّر على موقع Habr قائمة عملية بمقاربات RAG المستخدمة فعلًا في بيئة الإنتاج، استنادًا إلى تجربته الشخصية وإلى تحليل حالات استخدام لدى آخرين خلال العام الماضي الذي شهد نموًا نشطًا في منظومة LLM.

من أين يبدأ الجميع

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

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

البحث الهجين وإعادة الترتيب (reranking)

البحث الهجين هو أول ترقية تعوّض كلفتها في الغالب. فالجمع بين المتجهات الكثيفة (dense) للبحث الدلالي وBM25 للبحث بالكلمات المفتاحية يحقق زيادة ثابتة في الدقة تتراوح بين 15 و30% مقارنة بالبحث بالتضمينات وحدها. تلتقط المتجهات الكثيفة التشابه في المعنى، بينما تلتقط المتجهات المتناثرة (sparse) التطابقات الدقيقة في المصطلحات والاختصارات والأسماء.

وتؤدي إضافة cross-encoder reranker فوق أفضل 20 نتيجة إلى رفع الجودة بما يتراوح بين 10 و15% إضافية. صحيح أن الـreranker نموذج أثقل، لكنه لا يعمل إلا على المجموعة النهائية من المرشحين، ولذلك يبقى زمن الاستجابة مقبولًا في بيئة الإنتاج.

تقنيات على مستوى الاستعلام

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

• HyDE: يولّد LLM مستندًا افتراضيًا يمثّل الإجابة، ثم يُستخدم متجهه في البحث. يفيد بوجه خاص عندما يختلف أسلوب السؤال كثيرًا عن أسلوب المستندات.
• Multi-query: يُولَّد من سؤال واحد من 3 إلى 5 صيغ بديلة، ويجري البحث بها جميعًا بالتوازي. يقلّل ذلك الاعتماد على الصياغة الدقيقة للمستخدم.
• Step-back prompting: قبل البحث، يعمّم LLM الاستعلام إلى مستوى أعلى من التجريد. يفيد عندما يكون السؤال المحدد شديد التخصص بحيث لا يتيح استرجاعًا جيدًا (retrieval).
• Parent Document Retriever: تُفهرَس أجزاء صغيرة (لدقة عالية)، بينما يُمرَّر إلى السياق المستند الأصلي بأكمله. يحقق توازنًا جيدًا بين الدقة (precision) والتغطية (coverage).
• Contextual compression: يستخلص LLM من الجزء المسترجع الجزء ذا الصلة فقط. يوفّر ذلك الرموز (tokens) ويقلّل الضجيج في السياق.

المدفعية الثقيلة

عندما لا تكفي التقنيات البسيطة، يُلجأ إلى مقاربات أكثر تعقيدًا من الناحية المعمارية.

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

GraphRAG من Microsoft يبني رسمًا معرفيًا: يستخرج الكيانات والعلاقات من النص، وينشئ ملخصات مجتمعية (community summaries) لمختلف العناقيد الموضوعية. يتفوق بثبات على RAG القياسي في الأسئلة التحليلية والمقارنة، مثل «كيف يرتبط X بـY» و«ما الذي تغيّر منذ اللحظة A»، وفي المهام التي تتطلب تركيب المعلومات على مستوى المجموعة النصية بأكملها.

Self-RAG وCorrective RAG ينقلان النظام إلى نمط وكيلي (agentic): يقرر النموذج بنفسه هل البحث ضروري، ويقيّم صلة ما عثر عليه، ويعيد صياغة الاستعلام عند الحاجة. يضيف ذلك زمن استجابة (latency) وتعقيدًا، لكنه يرفع الجودة بشكل ملحوظ في المهام متعددة الخطوات وغامضة الصياغة.

ماذا يعني ذلك

المسار العملي هو البدء بالبحث الهجين مع reranking، فهذا يعالج معظم المشكلات بأقل كلفة. ثم تُضاف تقنية multi-query أو HyDE للتعامل مع تنوّع الاستعلامات. أما GraphRAG وSelf-RAG فلا ينبغي اعتمادهما إلا عندما تعجز التقنيات الأبسط، لأنهما يتطلبان تكاليف كبيرة في التطوير والصيانة. وفي معظم منتجات B2B تكفي الخطوتان الأوليان.