بناء نظام RAG موثوق: تعمّق في سبع نقاط فشل وأطر التقييم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FP4. غير مستخرج

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

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

FP5. تنسيق خاطئ

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

FP6. مستوى تفصيل غير مناسب

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

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

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

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

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

كيف تضعف نقاط الفشل أداء سلسلة معالجة RAG

تؤثر كل نقطة من نقاط الفشل هذه في أداء سلاسل معالجة RAG:

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

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

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

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

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

• FP2 (فشل في تحديد المستندات الأعلى تصنيفًا): نموذج التضمين يفشل في اختيار أفضل k تضمينات (top-k).
• 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 Actions حيث يُشغل DeepEval G-Eval وغيرها من المقاييس على حالة اختبار:

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

ملاحظة المطور – حالة الاختبار ل 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 تعكس مدى تلبية الاستجابة لقصد الاستعلام، باستخدام مقياس ليكرت ذي أربع درجات (0-3)، مما يجعله متفوقًا في ترتيب جودة نتائج البحث المختلفة.

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

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

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

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

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

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

في سياق تقييم RAG، يتميز Phoenix في تحليل التضمين، باستخدام تقريب المتشعبات وإسقاطها بصورة موحدة (Uniform Manifold Approximation and Projection، أو UMAP) لتقليل تضمينات المتجهات عالية الأبعاد إلى مساحة 2D/3D.

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

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

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

Braintrust – شبكة أمان من تراجع أداء الموجّهات

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

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

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

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

الختام

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

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

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

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

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

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

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

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