مشروع جميل جدا اللهم بارك Jyad d، وجهد مقدر، خصوصا إن فصل "فهم السؤال" عن "مصدر الإجابة" اختيار موفق جدًا مع النص القرآني، خصوصًا مع اعتماد الإجابة على فهرس موثّق بدل التوليد.
عندي كذا نقطة أتمنى تفيد:
١. مشكلة الـ Closed-set classification
طالما الـclassifier بيوزّع الاحتمالات على الخمس نوايا، فأي سؤال خارج النطاق ممكن يتوجّه لأقرب intent بثقة عالية. وده يفسر أمثلة زي "بر الوالدين" أو "الكلمة في منتصف القرآن".
إضافة "other" وحدها غالبًا مش كفاية. ممكن تجربة:
- Confidence threshold على أعلى احتمال، مع fallback للأسئلة غير الواضحة.
- Calibration مثل Temperature Scaling على validation set، لأن confidence = 0.97 لا تعني بالضرورة احتمال صحة 97%.
- تدريب "none/out-of-scope" بأمثلة hard negatives متنوعة، خصوصًا الأسئلة الموضوعية والتفسيرية، بدل أمثلة عشوائية.
٢. الأسئلة الموضوعية تحتاج Intent مختلف
أسئلة مثل "أين وردت كلمة الرحمن؟" مختلفة معماريًا عن "ماذا ورد عن بر الوالدين؟".
الأخيرة ممكن تكون "topical search" تذهب إلى semantic retrieval باستخدام embeddings عربية + vector index على فهرس موضوعي/تفسيري موثوق. وبكده تفضل الإجابة مسترجعة من المصدر، بدل إدخال LLM في توليد المحتوى.
٣. لو أضفت LLM، أخليه Router لا Generator
لو احتجت LLM كـfallback، ممكن يكون دوره إخراج structured output مثل:
"{intent, parameters}"
مع Schema validation، وبعدها الـretriever هو اللي ينفذ ويعيد النص من المصدر. كده الـLLM يفهم لغة المستخدم، لكن لا يكون مسؤولًا عن صياغة النص القرآني نفسه.
والأسئلة التي تفشل فيها الـrouter يمكن جمعها ومراجعتها يدويًا، ثم استخدامها لاحقًا لتحسين بيانات التدريب أو الـfine-tuning للـencoder.
٤. نقطة مهمة في الـBenchmark
لو المقارنة بين النموذج المحلي وAPI تشمل الـ106x latency، فالأدق فصل زمن inference عن زمن network round-trip؛ لأن المقارنة هنا ليست بين النموذجين فقط.
وأعتقد أن أهم Benchmark للمشروع نفسه سيكون Test Set مخصص لأسئلة البحث القرآني، يشمل اللهجات، الأخطاء الإملائية، الصياغات المختلفة، والأسئلة المركبة، مع قياس Precision/Recall لكل intent، وليس Accuracy فقط.
بارك الله في جهدك وتقبل منك يا رب🌿
