مصنّف الخدمات المبني على LLM ارتفع من 73% إلى 94%، لكن سلسلة من ثلاث عقد لا تزال تعطي 75%

كل فريق أطلق LLM في الإنتاج يعرف هذه الخيبة. على مجموعة الاختبار يعطي النموذج 98%، وعلى البيانات الحقيقية 73%. يرى كاتب التحليل على Habr أن جودة النظام ككل نادراً ما تتجاوز 90% في الإنتاج، ولذلك ينبغي الاستناد إلى هذا الرقم تحديداً. وبعض المشاريع ببساطة لن تستقيم بسبب ارتفاع كلفة الخطأ.

المهمة: 50 فئة ودليل مرجعي واحد

المثال مأخوذ من عمل حقيقي. انطلاقاً من اسم الخدمة يجب اختيار الرمز الخاص بالنموذج رقم 402. التصنيف مسطّح من 50 فئة، وكل نوع خدمة يقابل رمزاً واحداً بالضبط. مثلاً: «842 — تطوير البرمجيات وتثبيتها» أو «7123 — النقل البري للبضائع بالسيارات». تبدو المهمة بسيطة، لكنها تُظهر كيف تتصرف عقدة واحدة.

الغريزة الأولى هي إضافة الاستثناءات إلى الـprompt. بذلك يتضخم الـprompt وتظهر ثلاث مشاكل. أولاً، قد «يفقد» النموذج جزءاً من السياق الطويل: المعلومة موجودة في المدخل وغائبة عن الإجابة. ثانياً، إذا كان في prompt واحد عشرات المهام المختلفة (مثلاً استخراج 50 سمة، وللمبلغ وحده فقرة كاملة من القواعد)، تسقط بعض القواعد. ثالثاً، يظهر ما يشبه فرط التخصيص (overfitting): تضبط الـprompt على الاختبار المرجعي نفسه فيحفظ الأمثلة بدل تعلّم القاعدة العامة. توقف الفريق عند 8 أمثلة وحصل على 81%.

ما الذي رفع جودة العقدة فعلاً

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

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

الخطوة التالية هي الأمثلة الديناميكية. من الاختبار المرجعي المُعلَّم يُبنى جدول «متجه اسم الخدمة — الفئة». للخدمة الجديدة يُبحث عن الخدمات المشابهة وتُضاف إلى الـprompt مع رموزها الصحيحة. النتيجة 94%. لا يمكن بلوغ 100%: الجدول غير مكتمل، والمتجهات تتقارب أحياناً بشكل خاطئ فتدخل أمثلة غير مناسبة إلى الـprompt.

السلاسل: الجودة تتضاعف

الفكرة الرئيسية في النصف الثاني من المقال: الجودة النهائية لسلسلة استدعاءات تساوي حاصل ضرب جودة خطواتها. مثال من مركز اتصال: إعادة صياغة السؤال تعمل بنسبة 95%، وبحث RAG في قاعدة المعرفة بنسبة 80%، والإجابة النهائية بنسبة 99%. المحصلة 0.95 × 0.80 × 0.99 = 75%. هذا الحساب صحيح فقط على مجموعة بيانات ثابتة واحدة: لا يجوز قياس كل حلقة على مجموعتها ثم ضرب النتائج.

الإغراء مفهوم: إضافة منسّق (orchestration) بقائمة إيقاف للأسئلة الإشكالية. هو فعلاً يستبعد جزءاً من الحالات، ويعمل RAG على الباقي بشكل أفضل، لنقل 89%. لكن المنسّق نفسه يخطئ أيضاً، مثلاً في 5% من الحالات. المحصلة: 95% × 95% × 89% × 99% ≈ 79.5%. هناك مكسب لكنه صغير، وأصبح النظام أكثر تعقيداً. ولم يصبح مثالياً: فقد أُضيفت إلى السلسلة خطوة أخرى لها خطؤها.

ماذا نفعل عملياً

• قِس الجودة على بيانات واقعية لا على الاختبار الداخلي فقط. الفجوة بين 98% و73% سيناريو شائع.
• قبل تعقيد الـprompt، راجع السجلات وتحدث مع الأعمال. بعض «أخطاء النموذج» ستتبيّن أنها أخطاء في صياغة المهمة أو في الخطوة السابقة.
• قسّم المهمة بحسب المعنى (خدمة واحدة — استدعاء واحد) لا بشكل آلي.
• احسب السلسلة مسبقاً: ثلاث خطوات بنسبة 90% تعطي نحو 73%.
• إذا كانت كلفة الخطأ عالية، فأدخل الإنسان في الحلقة. لا ينبغي توقع 100% من نظام قائم على LLM.

القيود

الأرقام مأخوذة من حالة واحدة للكاتب غيّر فيها المعطيات مع الحفاظ على المعنى العام. لا يوجد تحقق مستقل، ويعتمد حجم المكسب من كل أسلوب على البيانات. لكن المنطق عام: جودة النظام يحددها أضعف حلقة وعدد الخطوات، ومن الأفضل تبنّي مرجع 90% منذ البداية.