اجتاز العميل الذكي (AI agent) الذي أطلقته 23 اختباراً للوحدات (unit tests)، ولكن في غضون ساعة واحدة من دخوله الخدمة، اخترع ميزة منتج وقدم سعراً أقل بثلاث مرات من الواقع. وعندما واجهه المستخدم، أصرّ البوت على موقفه، وانتهت المحادثة، وفقدتُ عميلاً. أثبت هذا الخطأ أن مجموعة من اختبارات الوحدات الحتمية (deterministic unit tests) لا يمكنها ضمان موثوقية العميل الذكي.

لماذا تقصر اختبارات الوحدات عن تلبية احتياجات العملاء الأذكياء

تعمل اختبارات الوحدات مع الأكواد التقليدية لأن المدخلات نفسها تؤدي دائماً إلى نفس المخرجات. فمعادلة "2 + 2 = 4" هي ضمان يمكنك التحقق منه عبر فحص بسيط للتساوي. أما العميل الذي يعمل بنماذج اللغات الكبيرة (LLM-driven agent)، فتتغير مخرجاته بناءً على الأمر (prompt)، والسياق المحيط، وحالة أي أدوات خارجية يستدعيها. إن الاختبار الذي يتحقق من تطابق النصوص بدقة يغفل عن الهلوسة (hallucinations)، أو تغير النبرة، أو انتهاك ضوابط الحماية (guardrails). إن الفشل الصامت الذي كلفني عميلاً يوضح ضرورة تقييم التفاعل بأكمله، وليس مجرد وظائف معزولة.

بناء إطار تقييم (evaluation harness) قبل كتابة كود أي ميزة

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

الطبقة 1 – وظائف الأدوات

يتحقق خط الدفاع الأول مما إذا كان بإمكان العميل استدعاء أدواته بشكل صحيح. تغطي الاختبارات عمليات البحث الناجحة، والاستعلامات المشوهة عمداً، وفشل واجهات برمجة التطبيقات (API) المحاكى. ولأن استخدام الأدوات حتمي إلى حد كبير — فإما أن يتم تشكيل الطلب بشكل صحيح أو تعيد الـ API خطأً — فإن تأكيدات Python (Python assertions) البسيطة تكفي. إن اكتشاف الطلبات المشوهة هنا يمنع حدوث ارتباك في المراحل اللاحقة.

الطبقة 2 – اتباع التعليمات

بعد ذلك، يتحقق إطار التقييم من احترام العميل لضوابط الحماية. يعمل نموذج LLM أصغر كمُقيّم، حيث يفحص استجابة العميل للتأكد من الامتثال: البقاء في الشخصية، وتجنب المواضيع المحظورة، وإصدار مخطط JSON المطلوب. تكتشف هذه الطبقة الانحراف الدلالي (semantic drift) الذي تغفله اختبارات الوحدات، مثل الانزلاق إلى شخصية غير مقصودة أو تسريب الأوامر (prompts) الداخلية.

الطبقة 3 – السلوك الموجه نحو الهدف

الطبقة الثالثة هي الأكثر أهمية، فهي تسأل عما إذا كان العميل يحقق غرضه بالفعل. بالنسبة لبوت توليد العملاء المحتملين (lead-generation bot)، يعني ذلك التأكد من طرحه للأسئلة التأهيلية الصحيحة وتصعيده الأمر إلى بشري عند الاقتضاء. أستخدم هنا نموذجاً موجهاً نحو الاستنتاج (reasoning-oriented model) لأنه يستطيع تقييم التدفق العام دون تضخيم التكاليف. إذا فشل البوت في تحقيق هدفه — حتى لو اجتاز الطبقتين الأوليين — يتم تمييزه لإعادة التصميم.

الطبقة 4 – الأداء

أخيراً، يسجل إطار التقييم زمن الاستجابة (latency) وسرعة توليد الرموز (token-generation speed). الاستجابات البطيئة تضعف تجربة المستخدم، خاصة في الدردشة الفورية. من خلال تتبع هذه المقاييس جنباً إلى جنب مع الصحة الوظيفية، أضمن أن العميل دقيق وسريع الاستجابة في آن واحد.

خيارات توفير التكلفة

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

المقايضة: السرعة مقابل الأمان

أدى إدخال إطار التقييم إلى حدوث عقبات أولية؛ حيث طالت دورات التطوير وتأخر الجدول الزمني للإطلاق.

ما يجب مراقبته لاحقاً

  • المُقيّمون المعتمدون على النماذج: مع تحسن نماذج LLM، يمكن للمُقيّم في الطبقة 2 أن يصبح أكثر دقة، مما يقلل من النتائج الإيجابية الخاطئة (false positives) مع الاستمرار في رصد الانتهاكات الدقيقة للسياسات.

الخلاصة

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