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

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

لماذا هذا صعب

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

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

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

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

كيف تم هيكلة الاختبارات

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

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

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

في عملية كاملة، يستخدم المطورون طلباً قصيراً جداً — 2+2=؟ اختصرها. لكن الهدف من الاختبار ليس رؤية الرقم 4 تحديداً. النقطة مختلفة: بعد الشروط الأساسية، يجب أن يصل الوكيل إلى حالة Ready ويتلقى رداً من الخادم وينقل الرموز بشكل صحيح ويعرض النتيجة في الواجهة. لا يختبر هذا السيناريو إبداع النموذج بل ما إذا كانت مجموعة إضافة IDE وخادم الترخيص وخادم LLM والمكتبات الداخلية لم تنكسر بعد آخر تغيير.

"نحن لا نسعى للحصول على الإجابة 4"

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

من الناحية الفنية، تعتمد Veai على مكتبات JetBrains Starter و Driver. يحضر Starter بيئة IDE ويضبط مشروع الاختبار ويجمع القطع الأثرية، بينما يعمل Driver مع الواجهة الحقيقية ويسمح بوصف العناصر باستخدام نهج Page Object و DSL. إذا كانت المحددات موضعية غير كافية، تضيف الفريق accessibleName إلى كود المنتج أو تعدل قواعس تعمية العناصر تبقى قابلة للاكتشاف.

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

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

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

ماذا يعني هذا

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