الخلل ليس في نموذج اللغة الكبير: كيف تُخفي البنية المعمارية المشكلات خلف ما يبدو ضعفًا في جودة النموذج

كشفت تجربة تطبيق LLM في خدمات العملاء عن نمط خطير: حين تقدّم LLM إجابة خاطئة، فغالبًا لا يكون الذنب ذنبها.

العرض التجريبي مقابل الواقع

في العرض التجريبي التجريبي (pilot) عمل النظام على نحو مثالي: كان النموذج يجيب بحيوية، ورأت الإدارة تقدمًا ملموسًا، وقارن الفريق بين نماذج LLM مختلفة وأدخل تعديلات متكررة على الـprompts. ثم جاء المستخدمون الحقيقيون ومعهم البيانات الحقيقية والقيود الحقيقية. صارت الإجابات واثقة النبرة، لكنها كانت خاطئة أحيانًا.

الخلل ليس في النموذج

خطّط الفريق لاستبدال النموذج بـLLM أقوى. لكن تحليل السجلات أظهر أن النموذج، في جزء من المحادثات، لم يكن ينبغي له أن يجيب أصلًا. فقد كان routing يوجّه المستخدم إلى فرع answer، مع أن API أعاد partial response، وهي حالة تستوجب handoff إلى موظف بشري.

• المشكلة كانت في التوجيه (routing)، لا في جودة التوليد
• حين يعيد API استجابة partial، يجب على النظام تحويل المستخدم إلى الدعم
• لكن LLM كانت تتلقى الاستجابة partial على أنها إجابة كاملة، فتكتب نصًا مقنعًا لكنه خاطئ
• النموذج كان يصوغ أخطاء البنية المعمارية بأسلوب جميل

أين كانت الأخطاء الحقيقية

لم تكن أغلى الأخطاء في LLM. بل كانت في:

• Routing — يوجّه المستخدمين إلى الفروع الخطأ
• تكاملات API — لا تفرّق بين استجابة partial واستجابة full
• منطق Handoff — متى يجب التحويل إلى موظف بشري
• قاعدة المعرفة — معلومات قديمة (outdated) أو ناقصة (incomplete)
• طبقة الامتثال (Compliance) — الالتزام بالأنظمة واللوائح
• المقاييس — ما الذي يُعدّ خطأً من الأساس

نقطة التحول

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

والخلاصة مُرّة: LLM قوية لا تعوّض بنية معمارية ضعيفة. فإذا غاب routing سليم، وغاب مالك لقاعدة المعرفة (knowledge base)، وغاب منطق handoff واضح، فإن المقارنة بين النماذج تتحول غالبًا إلى تشتيت مكلف للانتباه. الأجدى أن يُنفَق الوقت على النظام لا على الـprompts.