Habr: 6 أسباب لإخفاق ذاكرة وكيل RAG، وكيف تفحص عملية الاسترجاع (retrieval)

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

تربط تقنية RAG (Retrieval-Augmented Generation) النموذج بقاعدة معرفة خارجية. فلا يعتمد الوكيل على ما حفظه أثناء التدريب وحده، بل يبحث أولاً عن المعلومات في مستندات المؤسسة أو الأدلة المرجعية أو الإنترنت، ثم يكتب إجابته استناداً إليها. ويضم خط المعالجة خمس مراحل على الأقل: تقطيع المستندات، والتحويل إلى متجهات، والفهرسة، والبحث، وتجميع السياق. وأي خطأ في أي مرحلة منها يبدو بالشكل نفسه: الوكيل «نسي».

أين يتعطل البحث عادةً

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

الثانية هي نموذج التضمينات (embeddings). فإذا كان أداؤه ضعيفاً مع اللغة الروسية أو المصطلحات المتخصصة أو الشيفرة البرمجية، ستبتعد النصوص المتقاربة دلالياً بعضها عن بعض في الفضاء المتجهي.

الثالثة هي حداثة الفهرس. فقد حُدّث المستند ولم تُشغَّل إعادة الفهرسة، فيواصل الوكيل الاستشهاد بثقة بنسخة اللائحة من العام الماضي. وهذا أكثر مصادر الإجابات «القديمة» شيوعاً في ذاكرة الوكيل.

الرابعة هي صياغة الاستعلام. يكتب المستخدم «كيف أقدّم طلب إجازة؟»، بينما يحمل المستند في القاعدة عنوان «إجراءات منح الإجازة السنوية مدفوعة الأجر». ويساعد في ذلك إعادة صياغة الاستعلام وتقسيم السؤال المعقد إلى استعلامات فرعية.

الخامسة هي الترتيب. فالبحث المتجهي الخالص يجد بصعوبة أرقام الأصناف والأسماء والاختصارات. وعادةً ما يحقق مخطط هجين يجمع BM25 مع معيد ترتيب (reranker) للمرشحين الأوائل زيادة ملحوظة في الدقة.

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

كيف تشخّص retrieval

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

ثم تُحتسب المقاييس:

• recall@k: نسبة الأسئلة التي وصل المقطع المطلوب فيها إلى أعلى k نتيجة. وإذا ظهر إخفاق هنا، فلا حاجة إلى النظر في بقية المقاييس؛
• precision@k: كم من النتائج المسترجعة مفيد فعلاً، أي كم من الضوضاء يتسرب إلى المطالبة؛
• MRR: في أي موضع يقع في المتوسط أول نتيجة صحيحة؛
• nDCG: جودة ترتيب النتائج عند وجود عدة مقاطع ذات صلة؛
• زمن استجابة البحث وإعادة الترتيب، لأن الدقة التي تُشترى بثوانٍ من الانتظار غالباً ما تكون غير مقبولة للوكيل.

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

الترتيب العملي للخطوات

ابدأ بإعداد المجموعة المرجعية وتثبيت الأرقام الأساسية. ثم غيّر معاملاً واحداً في كل مرة: حجم المقطع، أو نموذج التضمينات، أو إضافة BM25، أو معيد الترتيب، أو عدد المقاطع المُمرَّرة. وقارن كل تغيير بالمقاييس، لا بالانطباع الذي تتركه بضع محادثات ناجحة.

وأعدّ مراقبةً مستقلة: سجّل الاستعلام والمقاطع المسترجعة وتقييماتها. وعندما يشتكي مستخدم من إجابة خاطئة، انظر أولاً هل كان المستند المطلوب ضمن النتائج. وفعّل إعادة فهرسة دورية وتحققاً من أن المستندات المحدّثة دخلت الفهرس فعلاً. ولا تعالج retrieval بالمطالبة: فطلب «أجب بدقة أكبر» لن يعيد حقيقة غير موجودة في السياق.