Plurai تجمع 13 مليون دولار لتطوير محاكي يرصد أخطاء وكلاء الذكاء الاصطناعي

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

بحسب TechCrunch، جمعت الشركة 13 مليون دولار في جولة تمويل تأسيسية. قادت Team8 الجولة، بمشاركة U&I وVelocity وMercer. وعمل المؤسسان إيلان كادار وإلعاد ليفي سابقًا في Nexar، فيما عمل كادار مع Waymo على محاكاة برمجيات القيادة الذاتية وتقييمها. وينقل الفريق الآن هذه الخبرة إلى الوكلاء البرمجيين.

كيف تعمل بيئة الاختبار

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

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

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

لماذا تراهن الشركة على النماذج الصغيرة

الاختبارات هي الجزء الأول من الفكرة. أما الجزء الثاني فهو استخدام البيانات الاصطناعية الناتجة لإجراء ضبط دقيق لنماذج صغيرة مفتوحة الأوزان، بما يناسب مهام عميل محدد. وبحسب TechCrunch، تعمل المنصة إلى جانب الأدوات القائمة، ومنها Claude Code وCodex وCopilot وCursor.

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

يقول كادار إن بالإمكان خفض التكاليف بمقدار يتراوح بين 10 و100 ضعف، مع تحقيق جودة مماثلة للنماذج الكبيرة أو أعلى منها. ويشير المقال أيضًا إلى اختبارات بالتعاون مع Nvidia وNebius، تفوقت فيها نماذج Plurai، بحسب الشركة، على بعض النماذج المتقدمة متوسطة الحجم، بتكاليف أقل.

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

ما الذي يجب التحقق منه قبل التطبيق

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

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

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