Veai تكشف كيف تختبر وكيل الذكاء الاصطناعي داخل JetBrains IDE دون الاعتماد على النموذج

كشفت Veai كيف بنت اختبارات واجهة المستخدم لوكيل الذكاء الاصطناعي الخاص بها داخل JetBrains IDE بحيث لا تتأثر الفحوص بتقلبات النموذج اللغوي. فصل الفريق اختبار الواجهة عن المنطق التجاري وعن LLM نفسه، ثم جمع ذلك في خط معالجة (pipeline) مستقر لطلبات الدمج (PR) وعمليات التشغيل الليلية.

لماذا الأمر صعب

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

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

ينطلق الفريق من مبدأ بسيط: جودة رد النموذج وسلامة عمل الواجهة مهمتان مختلفتان، ولا ينبغي الخلط بينهما في اختبار واحد. وكانت في المشروع بالفعل فحوص على مستويات أخرى، منها اختبارات نموذج IDE وسيناريوهات لمزوّدي LLM المختلفين ومعيار أداء (benchmark) مستقل للوكلاء. لذلك أصبحت أتمتة الواجهة قمة هرم الاختبار، لا محاولة لاستبدال كل ما عداها.

هذا النهج مهم لإضافات IDE، فالوكيل يرد في نافذة الدردشة وعبر الطرفية (terminal) معًا، ما يعني أن عدد المواضع التي قد يتذبذب فيها الاختبار عرَضًا أكبر بوضوح مما في واجهة الويب العادية.

كيف صُمّمت الاختبارات

لتفادي الخلط بين الأهداف، قسّمت Veai عمليات التشغيل إلى عدة أنماط. تعمل اختبارات Smoke مع كل طلب دمج (pull request) وتتحقق من سلامة الواجهة الأساسية دون استدعاء فعلي لـLLM. أما عمليات Full فتُشغَّل ليلًا، وتعمل مع الخادم الحقيقي وتمر بالسلسلة كاملة من الإضافة حتى رد النموذج. وهناك benchmark منفصل: وهو ليس اختبارات واجهة، بل تقييم لسيناريوهات المستخدم وجودة عمل الوكيل وفق مبدأ LLM-as-a-Judge.

نتيجة ذلك أن الفريق يرصد حالات التراجع في الواجهة نهارًا بسرعة أكبر، ولا يفقد الفحص الشامل للمنتج ليلًا.

• Smoke في كل PR: فحص الواجهة والمنطق الأساسي دون تحميل على LLM
• Full ليلًا: العمل مع خادم حقيقي وانتظار الرد في الواجهة
• Benchmark بشكل منفصل: تقييم سيناريوهات الوكيل وجودة النتيجة
• تشغيل متوازٍ على IDE مختلفة: تغطية أوسع دون زيادة في العمل اليدوي الروتيني

في التشغيل الكامل يستخدم المطورون طلبًا قصيرًا جدًا: 2+2=? Ответь покороче (أي: أجب باختصار). لكن هدف الاختبار ليس رؤية الرقم 4 تحديدًا. فالمغزى مختلف: بعد استيفاء الشروط المسبقة اللازمة، يجب أن يصل الوكيل إلى حالة Ready، ويتلقى ردًا من الخادم، ويستكمل بث الرموز (tokens) بشكل صحيح، ويعرض النتيجة في الواجهة. هذا السيناريو لا يختبر إبداع النموذج، بل يتحقق من أن الترابط بين إضافة IDE وخادم التراخيص وخادم LLM والمكتبات الداخلية لم ينهَر بعد التعديل الأخير.

«لا نسعى إلى الحصول على الإجابة 4».

ما الذي ساعد في CI

من الناحية التقنية، تعتمد Veai على مكتبتي JetBrains Starter وDriver. يُعدّ Starter بيئة IDE ويضبط المشروع التجريبي ويجمع مخرجات التشغيل، بينما يتعامل Driver مع الواجهة الحقيقية ويتيح وصف العناصر عبر Page Object ونهج DSL. وإذا لم تكفِ المحددات (locators)، يضيف الفريق accessibleName إلى شيفرة المنتج أو يعدّل قواعد التعتيم (obfuscation) كي تبقى العناصر قابلة للعثور عليها. كما تُجهَّز جزء من الحالة مسبقًا عبر إعدادات XML للإضافة، لذا لا تضطر الاختبارات إلى تجاوز شاشة Welcome والتهيئة الأولية (onboarding) في كل مرة.

وثمة عنصر مهم آخر هو الوصول إلى الحالة الداخلية للـIDE عبر JMX. وهذا يتيح عدم الاكتفاء بالنقر على الواجهة، بل التحقق مما سُجّل فعليًا في دردشة الوكيل، وأي مزوّد جرى اختياره، وكيف تبدو حالة JSON من وجهة نظر الإضافة.

لأغراض CI، يحتفظ الفريق بمصفوفة تضم إصدارات مختلفة من IntelliJ Platform وعدة بيئات JetBrains IDE وأعلام الميزات (feature flags) وإصدارات معتّمة (obfuscated). تُشغَّل الفحوص الثقيلة ليلًا، ويُستخدم Xvfb على Linux، وفُعّلت إعادة محاولات محدودة لتقليل الضجيج: لا أكثر من إعادة تشغيل واحدة للاختبار ولا أكثر من ثلاثة إخفاقات في التشغيل الواحد بأكمله.

الأثر العملي بات ملحوظًا: عشرات اختبارات الواجهة تغطي إعدادات الإضافة والانتقال بين حالات الدردشة واستدعاءات skills وسجل المحادثات ودخول المستخدم الجديد. وفي الأشهر الأولى كشفت هذه الفحوص أخطاء تطبيقية فعلية: فبعد إضافة السحب والإفلات (drag and drop) للملفات تعطّل النسخ واللصق (copy and paste)، وكان شريط تقدم السياق لا يراعي جميع مزوّدي LLM، كما أن اختيار الوكيل في الواجهة لم يكن يعمل بدوره في كل التهيئات، وبدأ سيناريو التعافي من الخطأ يومض بصريًا مع الاختبارات. وحتى عمليات التشغيل الليلية أبرزت عدم استقرار في إحدى التهيئات التجريبية لخادم LLM.

ماذا يعني ذلك

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