جودة الاسترجاع — تقيس نتايجك إزاي

فيه مقياسين بسيطين: recall (هل جبت كل القطع المهمة؟) وprecision (قد إيه اللي جبته كان فعلًا على الموضوع؟). الاتنين بيدّوك صورة صحّة بحثك.

زي مساعد بتبعته يجيبلك ملفات عن موضوع: recall هو جاب كل الملفات المهمة ولا ساب حاجة؟ وprecision هو اللي جابه كله كان في الموضوع ولا نصّه حشو؟ عايزهم الاتنين عالي.

تعمل ٢٠ سؤال معروف إجاباتهم، وتشوف الاسترجاع بيجيب القطعة الصح في أول ٣ نتايج كام مرة؛ لو ١٢/٢٠ بس، تعرف إن التقطيع أو الموديل محتاج شغل.

بتبني مجموعة تقييم صغيرة: 20–50 سؤال، ولكل سؤال عارف أنهي قطعة (أو قطع) فيها الإجابة — دي الـ ground truth. بتشغّل الاسترجاع على كل سؤال وبتحسب: recall@k (نسبة القطع الصح اللي ظهرت في أول k نتيجة) وprecision@k (نسبة أول k نتيجة اللي كانت صح فعلًا). فيه شدّ طبيعي بينهم: تكبير k بيرفع recall (فرصة أكبر تلقط الصح) بس بينزّل precision (حشو أكتر بيدخل مع النتايج). بعد ما المقياس يثبت، أي تغيير — حجم chunk، موديل، hybrid، reranking — بتقيسه بالأرقام قبل وبعد بدل الإحساس.

🧪 جرّب بنفسك: اكتب ٢٠ سؤال على مستنداتك وحدّد لكل واحد القطعة اللي فيها إجابته. احسب recall@3 وprecision@3 للنظام الحالي وسجّل الرقمين. بعدين غيّر حاجة واحدة بس (حجم الـ chunk مثلًا) وأعد القياس — دلوقتي بقى عندك رقم بيقولك التغيير حسّن ولا بوّظ، وده الفرق بين هندسة وتخمين.

أشهر غلطة: تقيّم بالإحساس — «جرّبت ٣ أسئلة وشكلها كويس» — وده بيخفي انحدار الجودة لما تغيّر حاجة. غلطة تانية: تعالج recall واطي بتكبير k على طول — ممكن يعدّي، بس بتحشي الـ context بقطع مش مرتبطة بتشتّت الموديل وبترفع التكلفة. وتالتة: تحكم على الـ RAG كله من الإجابة النهائية بس — لازم تقيس الاسترجاع لوحده الأول، لأن إجابة غلط ممكن سببها استرجاع سليم وموديل غلط، أو العكس.

ابني مجموعة تقييم أول ما الـ RAG يبقى فيه مستخدمين حقيقيين أو قرارات بتتاخد على إجاباته، وقبل أي تغيير كبير (موديل جديد، تقطيع جديد) عشان تقارن قبل/بعد بأرقام.

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