كيفية بناء RAG الموثوق: غوص عميق في 7 نقاط فشل وأطر التقييم

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

ولكن الانتقال من نموذج أساسي إلى نظام جاهز للإنتاج يتضمن التغلب على عقبات كبيرة في استرجاع البيانات ودمج السياق وتركيب الاستجابة.

يوفر هذا المقال غوصًا عميقًا في سبع نقاط فشل نمطية لل RAG وأطر التقييم مع أمثلة برمجية عملية.

تشريح انهيار RAG – 7 نقاط فشل (FPs)

وفقًا للباحثين Barnett et al، نظم التنميط المعزز بالاسترجاع (RAG) تواجه سبع نقاط فشل محددة (FPs) في جميع أنحاء الأنابيب.

يُظهر الشكل التالي هذه المراحل:

الشكل A. عمليات الفهرسة والاستعلام المطلوبة لإنشاء نظام RAG. يتم إجراء عملية الفهرسة في وقت التطوير والاستعلامات في وقت التشغيل. تظهر نقاط الفشل المحددة في هذه الدراسة في صناديق حمراء (المصدر)

دعونا نستكشف كل نقطة فشل مرتبة وفقًا لتسلسل الأنابيب، متبوعة بالتقدّم من أعلى اليسار إلى أسفل اليمين كما هو موضح في الشكل A.

FP1. محتوى مفقود

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

يحدث الفشل عندما يقدم نموذج LLM استجابة تبدو معقولة ولكنها خاطئة بدلاً من قول “لا أعرف”.

FP2. فشل في تحديد المستندات الأعلى تصنيفًا

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

بسبب ذلك، لا تصل المعلومات الصحيحة أبدًا إلى نموذج LLM.

FP3. غير موجود في السياق (قيود استراتيجية التجميع)

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

يحدث هذا عندما يتم إرجاع مستندات كثيرة ويجب على النظام تصفيتها لتناسب نافذة سياق نموذج LLM أو حدود التokens أو حدود المعدل.

FP4. غير مستخرج

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

يحدث هذا عندما يكون السياق مُضطربًا أو يحتوي على معلومات متضاربة تُربك نموذج LLM.

FP5. تنسيق خاطئ

هذه هي الحالة التي تتم فيها تخزين و استرجاع و تجميع و تفسير نموذج LLM بنجاح، لكن نموذج LLM يفشل في اتباع تعليمات التنسيق المحددة في العبارة، مثل الجدول أو قائمة النقاط أو مخطط JSON.

FP6. دقة خاطئة

إخراج نموذج LLM موجود تقنيًا، لكن إما слишком عام أو слишком معقد مقارنة بحاجة المستخدم.

على سبيل المثال، يُنشئ نموذج LLM إجابات بسيطة لاستعلام المستخدم الذي يحتوي على هدف مهني معقد.

FP7. إجابات غير كاملة

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

على سبيل المثال، عندما يسأل المستخدم سؤالاً معقدًا مثل “ما هي النقاط الرئيسية في الوثائق A و B و C؟”، يُجيب نموذج LLM على واحد أو两个 فقط من المصادر.

كيف يُ损ِط FPs أداء أنابيب RAG

تؤثر كل هذه نقاط الفشل على أداء أنابيب RAG:

فشل في سلامة البيانات وثقة

عندما تكون المعلومات المفقودة أو الخاطئة موجودة، لم يعد النظام مصدرًا موثوقًا بالبيانات. تشمل نقاط الفشل الرئيسية:

• FP1 (محتوى مفقود): الجواب ليس في الوثيقة في المقام الأول.
• FP4 (غير مستخرج): نموذج LLM يختار تجاهل الإجابة الصحيحة في الوثيقة.
• FP7 (غير كامل): نموذج LLM يقدم نصف الحقيقة، مع فقدان قطع معلومات importante.

عقبات في الاسترجاع والكفاءة

يمكن لأنابيب RAG أن تكون غير كفؤة عندما تفقد المعلومات الرئيسية في مراحل الاسترجاع والتجميع. تشمل نقاط الفشل الرئيسية:

• FP2 (فشل في تحديد المستندات الأعلى تصنيفًا): نموذج التضمين يفشل في اختيار التضمينات الأعلى تصنيفًا.
• FP3 (غير موجود في السياق): برنامج التصفية يُقصي الأجزاء الأكثر أهمية أثناء تقليل المستندات لتتناسب مع حدود نموذج LLM.

أخطاء في تجربة المستخدم وتشكيل

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

• FP5 (تنسيق خاطئ): نموذج LLM يفشل في اتباع تنسيق الإخراج المحدد مثل JSON.
• FP6 (دقة خاطئة): نموذج LLM يُنشئ إخراجًا طويلاً لاستعلام نعم/لا بسيط، أو العكس (إجابة قصيرة جدًا لاستعلام معقد).

مجموعة التقييم: أطر لتحديد نقاط الفشل

تم تصميم معايير التقييم لتخفيف هذه نقاط الفشل بشكل منهجي.

تستكشف هذه المقالة معايير التقييم الرئيسية مع حالات استخدام عملية.

معايير التقييم الرئيسية ل RAG:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – الاختبار الوحدة قبل النشر

يحسب DeepEval درجة موزونة بناءً على المعايير.

يُقيم نموذج LLM كقاض (على سبيل المثال، GPT-4o) كل معيار ضد إخراج نموذج LLM:

يستخدم DeepEval G-eval، وهو إطار سلسلة التفكير (CoT) يتبع نهج متعدد المراحل لتقييم الإخراج:

1. تحديد معيار لقياسه (على سبيل المثال، “الترابط” أو “السيولة” أو “الملاءمة”).
2. توليد خطوات التقييم (باستخدام نموذج LLM مقيم).
3. اتباع خطوات التقييم وتحليل الإدخال وإخراج نموذج LLM.
4. حساب مجموع وزن متوقع لدرجة كل معيار.

حالة شائعة في الممارسة

• الوضع: مساعد وثائق فني (بوت) لمنتج برمجي معقد يبدو أنه يعمل كل مرة يقوم فريق الهندسة بتحديث قاعدة البيانات.
• المشكلة: لا يوجد دليل كمي على أن البوت لا يزال بإمكانه الإجابة على استعلام المستخدم (فقط “تعتقد” أنه يعمل…).
• الحل: دمج وظيفة PyTest في حزمة انحدار CI/CD في Github Action حيث يُشغل DeepEval G-Eval وغيرها من المقاييس على حالة اختبار:

• النتائج المتوقعة: إذا انخفضت أي درجة من المقاييس عن العتبة (0.85)، يُرفع PyTest AssertionError – مما يُؤدي إلى فشل بناء CI على الفور، وthus منع الانحدار الصامت من الوصول إلى الإنتاج.

ملاحظة المطور – حالة الاختبار ل DeepEval
يحدد مجموعة من كائنات LLMTestCase حالة الاختبار التي يُشغلها DeepEval.

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

يمكن استرجاع هذه من ملف JSON أو CSV.

RAGAS – خبير تحسين الإبرة في العشب

يهدف تقييم التنميط المعزز بالاسترجاع (Ragas) إلى تقييم RAG بدون مجموعة بيانات مصنفة يدوياً من خلال توليد مجموعات اختبار اصطناعية.

ثم، يحسب معايير رئيسية؛

الشكل B. مخطط ثلاثي الأبعاد لتقييم RAGAS يربط بين السؤال والسياق والإجابة من خلال مقاييس الدقة والاسترجاع والولاء والملاءمة (تم إنشاؤه بواسطة Kuriko IWAI)

تُصنف معايير رئيسية إلى ثلاث مجموعات:

• أنابيب الاسترجاع (خط أسود، خط متصل، الشكل B): دقة السياق، استرجاع السياق.
• أنابيب التوليد (خط أسود، خط متقطع، الشكل B): الولاء، ملاءمة الإجابة.
• الحقيقة الأرضية (صندوق أحمر، الشكل B): تشابه دلالة الإجابة، صحة الإجابة.

حالة شائعة في الممارسة

• الوضع: نظام RAG للعقود القانونية يفتقد إلى شروط رئيسية. أنت غير متأكد من أن المشكلة موجودة في البحث (المسترجع) أو القراءة (المنشئ).
• المشكلة: لا فكرة عن أفضل قيمة ل top-k (عدد الشظايا المسترجعة).
• الحل: استخدم RAGAS لإنشاء مجموعة اختبار اصطناعية مع 100 زوج من الأسئلة والأدلة. ثم، شغل نظام RAG على مجموعة الاختبار لحساب دقة السياق واسترجاع السياق:
• النتائج المتوقعة: بناءً على نتائج المقاييس، يمكن أن يكون الخطة الإجرائية كما يلي:

الجدول 1. خطة إجراء تشخيص RAGAS – تعيين الدرجات إلى تعديلات النظام.

TruLens – خبير حلقة التغذية الراجعة

يركز TruLens على الآليات الداخلية لعملية RAG بدلاً من مجرد الإخراج النهائي باستخدام دالات التغذية الراجعة.

كما أنه يستخدم درجة نموذج LLM تعكس مدى رضا الاستجابة عن قصد الاستعلام، باستخدام مقياس Likert من 4 نقاط (0-3)، مما يجعله متفوقًا في ترتيب جودة نتائج البحث المختلفة.

حالة شائعة في الممارسة

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

• النتائج المتوقعة: عندما يُنشئ نموذج LLM استجابة تحتوي على معلومات غير موجودة في الشظايا المسترجعة، يُحدد سجل TruLens في لوحة التحكم.

Arize Phoenix – خريطة الفشل الصامت

يُعتبر Arize Phoenix أداة مفتوحة المصدر للرصد والتقييم لتقييم مخرجات نموذج LLM، بما في ذلك أنظمة RAG المعقدة.

مبني على OpenTelemetry بواسطة Arize AI، يركز على الرصد من خلال معاملته لتقييم نموذج LLM كفرع من فروع MLOps.

في سياق تقييم RAG، يُمتاز Phoenix في تحليل التضمين، باستخدام تخفيض تعيين المنفعة الموحد (UMAP) لتقليل تضمينات المتجهات عالية الأبعاد إلى مساحة 2D/3D.

يكشف تحليل التضمين رياضيًا عن ما إذا كانت الاستعلامات الفاشلة مترابطة семantically، مما يشير إلى فجوة في قاعدة البيانات المتجهة.

حالة شائعة في الممارسة

• الوضع: يعمل بوت الدعم الزبوني بشكل رائع لاسترداد الأموال، لكن يُجيب بأجوبة غير منطقية لطلبات الضمان.
• المشكلة: ثغرة في قاعدة البيانات المتجهة (لا يمكن العثور عليها في السجلات).
• الحل: استخدم Arize Phoenix لإنشاء تصور تضمين UMAP (UEV)، خريطة 3D لقاعدة البيانات المتجهة – لتوجيه استعلامات المستخدم على شظايا الوثائق.
• النتائج المتوقعة: يمكن رؤية تجمع لاستعلامات المستخدم في منطقة مظلمة حيث لا توجد وثائق، مما يشير إلى أن بعض الوثائق لم يتم تحميلها إلى مخزن المتجهات.

Braintrust – شبكة انحدار العبارة

صُمم Braintrust لدوائر التكرار المتكررة باستخدام المقارنة بين النماذج.

حالة شائعة في الممارسة

• الوضع: يُحسن فريق الهندسة العبارة من “الإجابة على السؤال” (الحالة A) إلى تعليمات نظام معقدة بطول 500 كلمة (الحالة B).
• المشكلة: قد يُؤدي تحسين العبارة للحالة B إلى كسر الحالة A بشكل غير مقصود.
• الحل: استخدم Braintrust لإنشاء مجموعة بيانات ذهبية مع مجموعة من الأمثلة الكاملة (مثل N = 50). اترك Braintrust يُشغل المقارنة جنبًا إلى جنب (SxS) كل مرة يُحدث الفريق كلمة واحدة في العبارة:

• النتائج المتوقعة: تقرير الفرق يُظهر بالضبط أي حالات تحسنت أو تدهورت لكل مجموعة من مجموعة البيانات الذهبية (N = 50).

الختام

عند معالجته بأطر تقييم مناسبة، يمكن أن يكون RAG أداة تنافسية لتوفير سياق نموذج LLM الأكثر صلة لاستعلام المستخدم.

استراتيجية التنفيذ: تعيين المقاييس لنقاط الفشل

على الرغم من عدم وجود حل مناسب لجميع الحالات، يُظهر الجدول 2 معايير التقييم التي يجب تطبيقها لكل نقطة فشل غطيناها في هذه المقالة:

الجدول 2. مصفوفة تحديد نقطة الفشل – أي أداة تحل أي نقطة فشل؟

DeepEval و RAGAS يمكنهما استخدام مقاييس الولاء لقياس فشل سلامة البيانات (FP1, FP4, FP7).

TruLens يستخدم دقة السياق / استرجاعه لقياس ملاءمة السياق للإخراج – مما يُقيّم بشكل فعال FP2.

Arize Phoenix يوفر تتبعًا مرئيًا لعملية الاسترجاع، مما يُظهر بسهولة ما إذا كان المستند المسترجع قد فقد خلال التجميع (FP3).

对于 فشل UX، DeepEval يُنشئ مقاييس مخصصة لتقييم فشل UX، بينما Braintrust يُمتاز في مقارنة مجموعة البيانات الأرضية.