لقد قمت ببناء أداة داخلية تتيح للفريق تشغيل 28 اختبار وحدة (unit test) على ميزة تعتمد على النماذج اللغوية الكبيرة (LLM) دون الحاجة مطلقاً لاستدعاء واجهة برمجة التطبيقات (API) الخاصة بالنموذج. لقد حققت ذلك عن طريق تغليف النموذج في واجهة قابلة للمحاكاة (fakeable interface) وإضافة ثلاث طبقات من التقييم: الحتمي (deterministic)، والاستدلالي (heuristic)، والقائم على النماذج اللغوية الكبيرة (LLM-based).
تنهار عمليات التأكيد القياسية (Standard assertions) بمجرد أن يقوم النموذج اللغوي بتوليد نصوص نثرية. فقد يؤدي نفس الأمر (prompt) إلى جملة مختلفة في كل مرة، لذا فإن assertEqual(output, expected) يشير إلى فشل حتى عندما يتصرف النموذج بشكل صحيح. تقوم معظم المجموعات الهندسية إما بشحن الميزة دون أي تحقق، أو تحاول اختبار النموذج نفسه، مع معاملة هدف متغير باستمرار كما لو كان مكتبة ثابتة.
لماذا تهم هذه المشكلة
أصبحت النماذج اللغوية الكبيرة (LLMs) الآن جزءاً من سير العمل الموجه للعملاء — مثل التواصل عبر البريد الإلكتروني، وردود الدعم، وتوليد المحتوى. يمكن لحقيقة واحدة مهلوسة (hallucinated fact) أو معرف مسرب أن يضر بسمعة العلامة التجارية، أو يكشف عن بيانات خاصة، أو يتسبب في انتهاكات للامتثال. وبدون استراتيجية اختبار موثوقة، تضيع الفرق وقتها في مطاردة الإخفاقات غير المستقرة (flaky failures) أو تشحن أخطاءً لا تظهر إلا في بيئة الإنتاج.
النهج: تقليص مسؤولية النموذج
كانت الخطوة الأولى هي الحد مما يفعله النموذج اللغوي فعلياً. في نظام المؤلف، يقوم النموذج فقط بصياغة رسائل التواصل. تظل جميع عمليات منطق التوجيه (routing logic)، وإدارة الحالة (state management)، وفحوصات الأمان في الكود البرمجي العادي. ومن خلال حصر النموذج في مخرج واحد محدد جيداً، يظل النظام المحيط به حتمياً وقابلاً للاختبار.
ولجعل ذلك ممكناً، يوضع النموذج اللغوي خلف واجهة مزود (provider interface)، مما يسمح باستخدام نسخة محاكاة (fake version) في الاختبارات. في بيئة الإنتاج، تقوم عملية التنفيذ باستدعاء واجهة برمجة التطبيقات الخارجية؛ أما في مجموعة الاختبارات، فتقوم نسخة محاكاة خفيفة بإرجاع استجابة جاهزة (canned response). ولأن بقية الكود يتفاعل فقط مع الواجهة، يمكن اختبار سير العمل بالكامل من خلال اختبارات الوحدة التي لا تتصل بالشبكة أبداً. والنتيجة هي نواة يمكن التنبؤ بها تتحقق منها الاختبارات الـ 28.
إطار تقييم صادق
حتى مع تضييق النطاق، يظل مخرج النموذج غير حتمي (nondeterministic). لذلك، بنى المؤلف إطار تقييم مكوناً من ثلاث طبقات، حيث تتعامل كل طبقة مع فئة مختلفة من المخاطر.
الطبقة 1 – فحوصات حتمية (Deterministic checks) تلتقط قواعد التعبيرات النمطية (regular-expression) البسيطة الأخطاء الملموسة مثل معرف مبنى خاطئ أو رموز محظورة. هذه الفحوصات سريعة وتعطي نتيجة ثنائية (نجاح/فشل).
الطبقة 2 – فحوصات استدلالية (Heuristic checks) تبحث البرمجيات النصية (scripts) عن الأرقام أو التواريخ المهلوسة، مما يشير إلى التزييفات الواقعية الواضحة. وهي قد تغفل الادعاءات الكاذبة التي تفتقر إلى مؤشرات رقمية، ويعترف المؤلف صراحة بهذا القصور.
الطبقة 3 – حَكَم النموذج اللغوي (LLM judge) يقوم نموذج ثانوي بتقييم النبرة والاحترافية. ولأن هذه الخطوة تعتمد على نظام احتمالي آخر، فإنها تُستخدم فقط للجوانب الذاتية حيث يستحيل وضع قواعد حتمية.
المفتاح في إطار التقييم هو مجموعة البيانات المستخدمة للتقييم. قام المؤلف بتشفير أنماط الفشل المعروفة — فخاخ محددة ومعرفة بالمجال — بحيث يختبر الإطار بالضبط الأخطاء التي ظهرت في الممارسة العملية. إنه ليس "أداة سحرية شاملة"، بل هو شبكة أمان مستهدفة.
ماذا يعني هذا للفرق
- اجعل مهام النموذج اللغوي محدودة. تقليل المسؤوليات يجعل العزل والاختبار أسهل.
- ضع التوجيه والحالة والأمان في الكود. يظل المنطق التقليدي حتمياً وقابلاً للاختبار بالكامل.
- اجعل النموذج متاحاً عبر واجهة قابلة للمحاكاة. تعمل اختبارات الوحدة دون استدعاءات خارجية، مما يحافظ على سرعة وموثوقية مجموعة الاختبارات.
- استخدم طبقات للتقييم. ابدأ بالقواعد الحتمية، ثم أضف الاستدلالات للهلوسات المعروفة، واحتفظ بحكام النماذج اللغوية لفحوصات الجودة الذاتية.
- حدد الحدود. لا تضمن أي طبقة الكمال؛ فإطار التقييم يلتقط فقط ما تمت برمجته صراحةً لاكتشافه.
وجهة نظر معارضة: لا يمكنك حتى الآن إجراء اختبارات وحدة للنموذج نفسه
يقر المؤلف بأن النموذج هو هدف متغير. فحتى طبقة حَكَم النموذج اللغوي ترث نفس عدم الحتمية التي تحاول تقييمها. وبناءً على ذلك، لا يمكن للنظام أبداً أن يضمن اكتشاف كل حالة هلوسة أو خرق للسياسة قبل الإصدار. النهج يقلل المخاطر ولا يلغيها، ويعتمد على قدرة الفريق على إبقاء بيانات التقييم محدثة مع ظهور أنماط فشل جديدة.
الخلاصة
لا يمكنك كتابة اختبار وحدة كلاسيكي يؤكد المخرج الدقيق للنموذج اللغوي، ولكن يمكنك بناء نظام يكون فيه تأثير النموذج محدوداً، وواجهته قابلة للاستبدال، ومخرجاته مفحوصة من خلال عمليات تحقق شفافة ومتعددة الطبقات. هذا المزيج يحول مكوناً غير مستقر إلى جزء يمكن التنبؤ به من تطبيق أكبر وقابل للاختبار.