الخطأ ليس في نموذج اللغة الكبير: كيف تخفي العمارة المشاكل تحت غطاء جودة النموذج

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

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

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

اللوم لا يقع على النموذج

كانت الفريق تخطط للتبديل إلى LLM أقوى. لكن تحليل السجلات أظهر: في بعض الحوارات، لم يكن يجب على النموذج أن يجيب على الإطلاق. كان التوجيه يرسل المستخدم إلى فرع إجابة عندما أرجعت API استجابة جزئية — في مثل هذه الحالات، كان نقل الإجابة إلى إنسان ضروريًا.

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

حيث عاشت الأخطاء الحقيقية

لم تكن الأخطاء الأكثر تكلفة في LLM. كانت في:

• التوجيه — يرسل المستخدمين بشكل غير صحيح عبر الفروع
• تكامل API — لم يتم التمييز بين الاستجابة الجزئية والكاملة
• منطق النقل — متى يتم النقل إلى إنسان
• قاعدة المعرفة — معلومات قديمة أو غير كاملة
• طبقة الامتثال — الامتثال التنظيمي
• المقاييس — ما يُحسب خطأ على الإطلاق

نقطة الانقلاب

حدث التحول عندما تغير السؤال. بدلاً من "لماذا أجاب LLM بشكل غير صحيح؟" سأل الفريق: "لماذا وضع النظام النموذج في موقف حيث كانت الإجابة الصحيحة مستحيلة؟"

الخلاصة

LLM قوي لا يعوض عن بنية ضعيفة. إذا لم يكن هناك توجيه مناسب، ولا صاحب قاعدة معرفة واضح، ولا منطق نقل واضح، تصبح مقارنة النماذج غالباً تحويلاً باهظاً. من الأفضل قضاء الوقت على النظام بدلاً من المطالبات.