لا تزال مشكلات RAG قائمة؛ إليك خمس طرق لمعالجتها.

حان الوقت لمواجهة الحقيقة بشأن التوليد المعزز بالاسترجاع (RAG): فهو حل يحتاج هو نفسه إلى حل.

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

قال Dinesh Nirmal، النائب الأول لرئيس IBM Software: "إلى حدّ كبير، يعاني RAG من أوجه قصور". وأضاف: "إن الاعتماد على RAG وحده لا يقدّم فعلًا النتائج المثلى التي كنا نتوقعها".

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

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

عندما يُطلب من تطبيق يعتمد نموذجًا لغويًا كبيرًا (LLM) ومدعومًا بنهج RAG تقليدي أن يُنفِّذ عمليات تجميع، مثل إيجاد المجموع، على مجموعة بيانات ضخمة، فالمسألة ليست صعبة فحسب، بل مستحيلة عمليًا. أحد العوامل التي تعيق أداء النظام هو حجم نافذة السياق؛ إذ إن نوافذ السياق في النماذج اللغوية الكبيرة (LLMs) عادة لا تكون قابلة للتوسع بما يكفي لمعالجة، مثلًا، مجموعة تضم 100,000 فاتورة. إضافة إلى ذلك، يعتمد مسار RAG التقليدي على قواعد بيانات المتجهات، وهي مصممة لعمليات البحث بالاعتماد على التشابه، لا لعمليات التجميع.

يوضح Sudheesh Kairali، المهندس المتميز في IBM، ذلك بقوله: "في الأساس، هذا يعني أن قاعدة بيانات المتجهات غير كافية للتعامل مع هذه الحالات. نافذة السياق تمثل مشكلة، والمشكلة الأخرى هي عدم القدرة على التعامل مع العمليات الحسابية".

وهنا يأتي دور SQL RAG.  

وكما يوضح Kairali، عندما يبحث مستخدمو النماذج اللغوية الكبيرة (LLMs) عن إجابات انطلاقًا من مجموعات بيانات كبيرة، يمكن أن يوفّر الجمع بين التوليد المعزز بالاسترجاع (RAG) وSQL نتائج دقيقة.

تتضمن SQL دوال تجميع مدمجة، كما أن قواعد بيانات SQL توفر سعة أكبر من نوافذ السياق في النماذج اللغوية الكبيرة (LLMs). وإذا استوعبت شركة بيانات فواتيرها في قاعدة بيانات SQL، يمكنها استخدام نموذج لغوي كبير (LLM) لتحويل الاستعلامات — مثل "ما هو مجموع جميع فواتير العام الماضي؟" —إلى SQL، ثم يستخدم النظام RAG للاستعلام من قاعدة بيانات SQL والوصول إلى الإجابة.

قال Sudheesh Kairali: "يمكن تنفيذ قدر كبير من عمليات التجميع إذا تمكّنت من بناء هذا الحل" وبعد أن تنفذ قاعدة بيانات SQL عملية التجميع "يصبح الأمر في تلك المرحلة مجرد تمرين معالجة لغة طبيعية (NLP) للنموذج اللغوي الكبير (LLM)".

ويُعد تمييز كيفية ارتباط الأجزاء المختلفة من المعلومات أو الكيانات المسترجعة مع بعضها نقطة ضعف أخرى في نموذج التوليد المعزّز بالاسترداد (RAG) التقليدي. على سبيل المثال، تأمل حالة استخدام تتعلق بمريض له تاريخ مرضي معقد. من خلال عملية الاسترجاع في RAG التقليدي يمكن لنموذج لغوي كبير (LLM) أن يقدّم معلومات ذات صلة. وقد تتضمن هذه البيانات تفاصيل مثل عدد الأطباء الذين راجعهم ذلك المريض خلال سنة واحدة، لكنها قد تعجز عن تحديد العلاج الذي وصفه كل طبيب.

يتصدى GraphRAG، الذي قدّمته Microsoft Research في عام 2024، لهذا التحدي من خلال معالجة العلاقات وتحديدها عبر الرسوم البيانية المعرفية. ينظّم GraphRAG المعلومات في صورة شبكة من عُقد وحوافّ تمثل الكيانات والعلاقات فيما بينها.

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

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

تعرّف على المزيد حول GraphRAG.

يُعَدّ التقسيم أمرًا بالغ الأهمية لتطبيقات التوليد المعزّز بالاسترجاع (RAG). في التقسيم التقليدي عبر نماذج التضمين، تُقسَّم المستندات ذات الصلة عند نقاط ثابتة إلى أجزاء أصغر، يُمثَّل كلٌّ منها في قاعدة بيانات المتجهات. ومع ذلك، قد تتسبب هذه الطريقة في أن يقدّم تطبيق يعتمد على نموذج لغوي كبير (LLM) إجابات غير مكتملة أو غير دقيقة، حتى عند استخدامه خوارزمية تعلّم آلي للبحث الدلالي على قاعدة معرفة خاصة بمجال معيّن.

قال Nirmal: "في هذه العملية، كثيرًا ما تفقد الدقة لأنك لا تعرف موضع تقسيم البيانات." "لنفترض أنّك قسّمت البيانات، أو قطعتها، في منتصف جدول؛ فعندما تسترجع الجدول، تسترجع نصفه فقط. والآن فقدنا دقتها ".

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

تعرّف على المزيد حول التقسيم القائم على الوكلاء.

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

كما يُثري التوليد المعزّز بالاسترجاع القائم على الوكلاء (agentic RAG) كل جزء ببيانات وصفية. تقوم هذه العملية بربط البيانات المُنظَّمة (البيانات الوصفية المخزنة في قاعدة بيانات معاملاتية) مع البيانات غير المنظمة لتحسين دقة الاسترجاع.

قال Nirmal: "إذا استطعنا فعلًا الاستفادة من قوة قاعدة بيانات المتجهات مع الجانب المعاملاتي أو جانب SQL منها ودمجهما معًا، فيمكننا رفع مستوى الدقة والأداء بشكل كبير."

تعرّف على ما يلزم للتغلّب على التحديات الأساسية الثلاثة للبيانات غير المنظمة.

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

قال Kairali: "هذا واقع مع RAG." "عندما تبدأ بإثبات المفهوم، يكون الجميع سعداء. ولكن عندما تريد بعد ذلك دفعه إلى مرحلة الإنتاج وتريد التأكد من أنه بمستوى يناسب بيئة الإنتاج، تبدأ في إدراك أن هناك مشكلة تتعلق بحماية البيانات".

ومعالجة هذه المشكلة تعني الحفاظ على قوائم التحكم في الوصول (ACLs) وسياسات الحوكمة الأخرى عندما يجري استيعاب البيانات غير المنظمة في قواعد بيانات متعددة. قال Kairali: "عندما يَرِد الاستعلام وتُسترجَع البيانات، من المهم التأكد من الالتزام بقوائم التحكم في الوصول (ACLs) وسياسات الحوكمة." "إنها مشكلة هندسية في الأساس."

ويمكن تسهيل حل هذه المشكلة الهندسية من خلال منصات البيانات المناسبة، مثل مستودعات بحيرة البيانات المحكومة والمدعومة بالمصدر المفتوح. فعلى سبيل المثال، يُعد مستودع watsonx.data من IBM مستودع بحيرة بيانات هجينًا ومفتوح المصدر يضمن توارث ضوابط الوصول من أنظمة مصدر المستندات عند استرجاع البيانات. كما يوفّر أيضًا تعليقات توضيحية لمعلومات التعريف الشخصية (PII) لمنع مشاركة المعلومات الحساسة.

ومع ترسّخ النماذج اللغوية الكبيرة (LLMs) وغيرها من حلول الذكاء الاصطناعي التوليدي في مهام سير العمل اليومية، يساعد تحسين RAG المؤسسات على استخلاص قيمة أكبر من بياناتها المؤسسية. قال Nirmal: "تُتيح الأدوات والاستراتيجيات المناسبة على مستوى المؤسسات أداءً أعلى ودقّة أكبر، بحيث تصبح البيانات قابلة للإدارة وذات قيمة." "هذا ما يبحث عنه كل عميل."