أنفقت 500 دولار على البنية التحتية لـ RAG قبل إصلاح هذه الأخطاء السبعة

قمت ببناء مسار (pipeline) لتقنية RAG للبحث في المستندات الخاصة. كلفني ذلك 500 دولار في تكاليف الحوسبة وأسابيع من تصحيح الأخطاء. كانت النتائج سيئة؛ حيث حصل المستخدمون على إجابات خاطئة وكانت الاستعلامات بطيئة.

قمت بمراجعة المسار، ووجدت 7 أخطاء. إصلاحها غيّر كل شيء.

  1. تقسيم الرموز (Token Chunking) الثابت قمت بتقسيم المستندات إلى 512 رمزاً (tokens). أدى ذلك إلى تدمير السياق؛ فمثلاً، قد ينقسم شرح لـ API في منتصف الجملة. استلم النموذج اللغوي الكبير (LLM) شظايا غير مكتملة وقدم إجابات غير منطقية. الحل: استخدم التقسيم الدلالي (semantic chunking).
  • التقسيم بناءً على حدود طبيعية مثل الفقرات أو العناوين.
  • استخدام استرجاع المستند الأب (parent-document retrieval).
  • إنشاء أجزاء فرعية صغيرة (child chunks) للبحث.
  • إرجاع المستند الأب الكامل إلى الـ LLM.
  • إضافة تداخل بنسبة 10-20% بين الأجزاء.
  1. أوزان البحث الهجين (Hybrid Search) السيئة استخدمت تقسيم 50/50 بين البحث المتجهي (vector search) والبحث بالكلمات المفتاحية (keyword search). فشل هذا الأسلوب مع المستندات التقنية، حيث يحتاج المستخدمون التقنيون إلى مطابقة دقيقة للكلمات المفتاحية. الحل: استخدم أوزانًا ديناميكية.
  • الاستعلامات الواقعية: 35% متجه، 65% كلمات مفتاحية.
  • الاستعلامات الدلالية: 75% متجه، 25% كلمات مفتاحية.
  • الاستعلامات العامة: 60% متجه، 40% كلمات مفتاحية.
  1. الإفراط في ضبط معاملات HNSW قمت بضبط ef_construction على الحد الأقصى، مما أدى إلى تعطل الخادم واستهلاك كامل ذاكرة الوصول العشوائي (RAM) المتاحة. الحل: استخدم معاملات مناسبة.
  • اضبط M بين 8 و32.
  • اضبط ef_construction على 200.
  • اضبط ef_search على 50. انخفض استهلاك الذاكرة بنسبة 70%.

  1. نماذج التضمين (Embedding Models) العامة استخدمت نموذجاً مدرباً على ويكيبيديا، بينما كانت مستنداتي عبارة عن أدلة تشغيل (runbooks) هندسية تقنية. لم يفهم النموذج مجالي التخصصي. الحل: استخدم نموذجاً تم ضبطه بدقة (fine-tuned) للمحتوى التقني أو البرمجي.

  2. غياب إعادة صياغة الاستعلام (Query Rewriting) يطرح المستخدمون أسئلة بلغة طبيعية، بينما تستخدم المستندات التقنية مصطلحات رسمية، مما يؤدي إلى عدم التطابق. الحل: أضف خطوة بسيطة باستخدام LLM لإعادة صياغة الاستعلامات.

  • يسأل المستخدم: "لماذا عملية البناء بطيئة؟"
  • يعيد النظام الصياغة إلى: "CI pipeline performance optimization"
  • أدى ذلك إلى تحسين الاستدعاء (recall) بنسبة 40%.

  1. النتائج المكررة غالباً ما كان استرجاع أفضل 10 أجزاء (chunks) يعطي نفس الفقرة ثلاث مرات، مما جعل الـ LLM يكرر نفسه. الحل: استخدم تقنية Maximal Marginal Relevance (MMR) لضمان تنوع النتائج.

  2. اختبار الشيء الخطأ كنت أختبر المسار بالكامل دفعة واحدة، ولم أكن أعرف ما إذا كانت المشكلة في عملية الاسترجاع (retrieval) أم في الـ LLM. الحل: فصل عملية تقييم الاسترجاع.

  • تتبع معدل الإصابة (hit rate).
  • تتبع متوسط الرتبة المتبادلة (MRR).
  • بناء مجموعة اختبار مكونة من 100 زوج من (الاستعلام-المستند).

النتائج بعد الإصلاحات:

  • صلة الإجابة: من 45% إلى 85%
  • زمن الاستجابة: من 3.2 ثانية إلى 1.8 ثانية
  • التكلفة الشهرية: من 180 دولاراً إلى 95 دولاراً

ابدأ بإصلاح تقسيم النصوص أولاً. ثم الأوزان. ثم جودة التضمين.

المصدر: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph