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

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

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

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

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

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

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

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

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

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

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

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

FP2. تفويت المستندات ذات التصنيف الأعلى

هذا هو وضع حيث يوجد مستند صحيح في المتجر المتجه، لكن الاسترجاع يفشل في تصنيفه بدرجة كافية لتشمله في المستندات العليا التي يتم تغذيتها إلى LLM كسياق.

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

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

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

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

FP4. غير مستخرج

هذا هو وضع حيث يفشل LLM في تحديد المعلومات الصحيحة في السياق، حتى لو كانت المعلومات الصحيحة موجودة في المتجر المتجه وتم استرجاعها بنجاح / توحيد.

يحدث هذا عندما يكون السياق ممتلئًا بالضوضاء أو يحتوي على معلومات متناقضة ت混ّ لLM.

FP5. تنسيق خاطئ

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

FP6. دقة غير صحيحة

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

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

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

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

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

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

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

اختراقات سلامة البيانات وثقة

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

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

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

يمكن أن يكون خط أنابيب 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 كsuite انحدار CI / CD في Github Action حيث يدير DeepEval G-Eval و其他 معايير عبر حالة اختبار:

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

المنافع

• مجموعة متنوعة من المعايير (50+) بما في ذلك فحوصات التحيز والسمية المتخصصة.
• يتكامل بسلاسة مع أنابيب CI / CD الحالية.
• لا يحتاج إلى مرجع. تقييم الإخراج بناءً على الاستعلام والسياق المحدد فقط.

العيوب

• جودة التقييم تعتمد بشكل كبير على قدرات LLM القاضي.
• مكلف حسابيًا عند استخدام LLM القاضي كنموذج عالي المستوى.

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

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

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

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

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

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

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

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

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

سيناريو شائع في الممارسة

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

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

المنافع

• ممتازة لمشروع في مرحلة مبكرة بدون مجموعات بيانات أرضية (كما رأينا في قطعة التعليمات البرمجية، يمكن لـ RAGAS إنشاء مجموعة اختبار اصطناعية).

العيوب

• مجموعة الاختبار الاصطناعية قد تفوت الأخطاء الواقعية الدقيقة.
• يتطلب نموذج مستخرج قوي لتحويل الإجابات إلى مطالبات فردية (استخدمت gpt-4o في المثال).

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.

سيناريو شائع في الممارسة

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

المنافع

• مفتوح المصدر؛ يدمج مع مجموعات مراقبة المؤسسات الحالية.
• أفضل أداة لتصوير النقاط العمياء في المتجر المتجه.

العيوب

• أقل تركيزًا على التقييم، أكثر على المراقبة.
• يمكن أن يكون مبالغًا فيه لالتطبيقات الصغيرة أو الأدوات الفردية.

Braintrust – شبكة أمان الانحدار بالاستعلام

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

سيناريو شائع في الممارسة

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

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

المنافع

• سريع جدًا للاختبار قبل النشر.
• واجهة مستخدم رائعة لمشاركي غير تقنيين لمراجعة وتقييم الإخراج.

العيوب

• مملوك / متوجه لبرامج السحابة (على الرغم من أن لديهم مكونات مفتوحة المصدر).
• معايير تقنية أقل مدمجة مقارنةً بـ DeepEval أو Ragas.

الختام

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

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

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

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

يمكن لـ DeepEval و RAGAS الاستفادة من معايير الولاء لقياس اختراقات سلامة البيانات (FP1، FP4، FP7).

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

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

لأخطاء تجربة المستخدم، يمكن لـ DeepEval إنشاء معايير مخصصة لتقييم أخطاء تجربة المستخدم، بينما يمتاز Braintrust في مقارنة مجموعة بيانات أرضية.