توقف عن إجراء اختبارات أداء النماذج الجديدة وابدأ بمراقبة وكيلك وهو يحاول إلغاء اشتراك. الفجوة بين هذين النشاطين هي المكان الذي تنهار فيه أنظمة الإنتاج. يمكن للاختبار أحادي الخطوة أن يخبرك ما إذا كانت الاستجابة تبدو لطيفة، لكنه لا يستطيع إخبارك ما إذا كان الوكيل قد أعاد المبلغ للعميل الخطأ، أو دخل في حلقة مفرغة أربع عشرة مرة ضد واجهة برمجة تطبيقات (API) للتقويم، أو قرر تخطي فحص الاحتيال تماماً. النص هو أقل الأشياء خطورة التي ينتجها الوكيل. المخاطر الحقيقية تكمن في الأدوات التي يلمسها، والبيانات التي يعدلها، واللحظات التي كان ينبغي فيها طلب المساعدة لكنه استمر في المضي قدماً.
لماذا تفشل اختبارات النصوص في بيئة الإنتاج
الدرجات العالية في اختبارات الأداء القياسية أصبحت نوعاً مضللاً من الطمأنينة. قد يظل الوكيل الذي يكتب نثراً بليغاً خطراً تشغيلياً. عندما يقوم نظامك بحجز المواعيد، أو تعديل سجلات قاعدة البيانات، أو تقديم تذاكر الدعم، فإن النص الناتج ليس سوى السطح المرئي لسير العمل. في العمق، يتخذ الوكيل قرارات ملموسة بشأن نقطة النهاية (endpoint) التي سيتم استدعاؤها، وحمولة البيانات (payload) التي سيتم إرسالها، ومتى يتوقف. يمكنه أن يتصدر قائمة صدارة فهم القراءة بينما يكلفك المال عن طريق الحجز المزدوج للموارد، أو تعديل الصف الخاطئ، أو تسريب حالة حساسة إلى ملف سجل (log file). أنت بحاجة إلى التحقق من آليات العمل، وليس فقط صقل المخرجات. إذا كان بإمكان الوكيل الحصول على درجة جيدة في اختبار ضمان جودة (QA) غير متصل بالإنترنت ومع ذلك يفشل في سير عملك عن طريق الدخول في حلقة مفرغة أو إساءة استخدام أداة، فإن تقييمك ينظر إلى الإشارات الخاطئة.
تحديد الاعتمادات الخمسة
يبدأ الفريق في Van Data Team كل عملية تقييم بتحديد خمس نقاط تحكم محددة. هذا يغير السؤال تماماً؛ فأنت تتوقف عن السؤال عما إذا كان أحد النماذج أذكى من الآخر، وتبدأ في السؤال عما إذا كان الوكيل يستطيع فعلياً إكمال مهمة إنتاجية في ظل قيودك الحقيقية.
نتائج الأعمال. حدد معنى "الإنجاز" بالدولارات وتأثير العملاء. لا تعتبر المهمة مكتملة لمجرد أن الوكيل أصدر ملخصاً؛ بل تكتمل عندما يكون سجل المخزون دقيقاً، والموعد مؤكداً، وقد استلم العميل رقم تتبع صالحاً.
الحالة القابلة للتعديل. اعرف بالضبط ما يُسمح للوكيل بتغييره. أي الجداول، أي الحالات، أي علامات الحساب؟ إذا كان بإمكان الوكيل إصدار عمليات استرداد الأموال، أو إعادة جدولة المهام، أو تحديث عناوين الفواتير، فأنت بحاجة إلى جرد كل حقل يلمسه.
صلاحيات الأدوات. كن صريحاً بشأن نقاط نهاية واجهة برمجة التطبيقات (API endpoints) والوظائف التي تقع ضمن النطاق. الوكيل الذي لديه وصول إلى أداة بحث، وأداة كتابة، وأداة إشعارات سيخلط بينها إذا كانت الحدود غير واضحة. قم بربط كل صلاحية بحاجة تشغيلية محددة.
التعافي من الفشل. قرر ما يحدث عندما تنتهي مهلة واجهة برمجة تطبيقات التقويم (calendar API)، أو تعيد خطأ 500، أو تعيد ملف JSON مشوهاً. لا ينبغي للوكيل أن يصاب بالذعر، أو يتخيل رسالة نجاح، أو يحاول مراراً وتكراراً إلى الأبد. إنه بحاجة إلى مسار بديل واضح.
بوابات المراجعة البشرية. حدد اللحظات التي يجب فيها على الشخص الموافقة قبل أن يتابع الوكيل. هذا ليس علامة ضعف في الأتمتة، بل هو صمام أمان للتغييرات عالية التأثير ومصدر لبيانات الحقيقة الأرضية (ground-truth labels) لمعايير التقييم الخاصة بك.
كيف يبدو مخطط التقييم الحقيقي
بمجرد تحديد الاعتمادات، ستحتاج إلى خطة تقييم تتناسب مع فوضى بيئة الإنتاج. لن تساعدك مقاييس العروض التقديمية هنا.
قم ببناء مجموعات اختبار من إخفاقات الإنتاج الحقيقية، وليس من بنوك الأسئلة الاصطناعية. إذا فشل وكيلك الثلاثاء الماضي بسبب الخلط بين وحدتي SKU متشابهتين، فيجب أن يكون هذا الارتباك تحديداً حالة اختبار دائمة. يجب أن تنمو مجموعة التقييم الخاصة بك في كل مرة يعلمك فيها حادث ما شيئاً جديداً.
اكتب معايير تقييم تحدد الإكمال الناجح بمصطلحات تشغيلية. المعايير الغامضة مثل "مفيد" أو "دقيق" لا فائدة منها. يذكر معيار التقييم المفيد أن مهمة استرداد الأموال لا تنجح إلا إذا تمت الإشارة إلى معرف الدفع الأصلي، وتطابق المبلغ مع الطلب، وتم وضع رسالة تأكيد في قائمة الانتظار، وتم تسجيل معرف المعاملة.
حدد مواصفات التتبع لاستدعاءات الأدوات وعمليات إعادة المحاولة. أنت بحاجة إلى القدرة على المراقبة (observability) لما خطط له الوكيل، وما استدعاه بالفعل، وعدد المرات التي حاول فيها مجدداً، وما إذا كانت استراتيجية إعادة المحاولة مناسبة. التتبع بدون دقة على مستوى الأداة ليس سوى قصة جميلة.
ضع سياسات لتحديد متى يتم تنبيه الإنسان. يجب أن يعرف الوكيل حدوده الخاصة. إذا تجاوز الطلب حداً معيناً من الدولارات، أو أشار إلى حساب VIP، أو واجه حالة لم يرها من قبل، فيجب عليه التصعيد بدلاً من التخمين.
قم بتثبيت بوابات الإصدار لمنع ترقيات النماذج السيئة. النموذج الجديد لا يُعد ترقية إلا إذا أدى إلى تحسين نتائجك المحددة. إذا زاد من "الهلوسة" في وسائط الأدوات (tool arguments)، أو زاد من زمن الاستجابة (latency)، أو أدخل مخاطر سلامة جديدة، فلا يتم إطلاقه. تحافظ هذه البوابة على استقرار بيئة الإنتاج حتى عندما يطلق مورد النموذج الأساسي إصدارًا جديدًا.
التقييم أثناء التشغيل: مراقبة عمل الوكيل (Agent)
تدفع شركة Anthropic الصناعة نحو تجاوز الاختبارات غير المتصلة (offline tests) والتوجه نحو التقييم أثناء التشغيل (runtime grading). بدلاً من الحكم على سجل المحادثة بعد انتهائه، يتيح التقييم أثناء التشغيل للنظام تقييم عمل الوكيل بينما لا تزال المهمة قيد التنفيذ. وهذا يمنح فرصة لاكتشاف الأخطاء قبل أن تتحول إلى مشكلات حقيقية يصعب حلها.
إضافة مُقيّم (grader) تستهلك الرموز (tokens) وتزيد من زمن الاستجابة. لا يمكنك تحمل تكلفة تقييم كل خطوة صغيرة. إن تحديد مكان كل مُقيّم هو قرار تصميمي؛ ضعهم حيث تكون الأخطاء مكلفة. تكمن أهم نقاط التحقق قبل إجراء تغيير في الحالة في قاعدة البيانات مباشرة، وقبل إتمام عملية دفع، وقبل إرسال رسالة إلى العميل. هذه هي اللحظات التي يتحول فيها القرار السيئ إلى إجراء لا يمكن الرجوع عنه.
احذر من نقطة عمياء محددة؛ فإذا كان النموذج نفسه هو من يؤدي العمل وهو من يقوم بتقييمه أيضًا، فقد يغفل عن نفس الأخطاء. فالتفكير المنطقي الذي أنتج الخطأ يمكنه بسهولة تبرير ذلك الخطأ أثناء المراجعة. بالنسبة للمهام ذات التأثير العالي، اجعل المراجعة البشرية جزءًا من العملية. اسمح للبشر بالتحقق من حكم المُقيّم نفسه، خاصة عندما تكون الأموال أو ثقة العملاء على المحك.
الهدف هنا هو التحكم التشغيلي. اربط بيانات الحوادث، ومعايير المهام (rubrics)، وتتبعات التشغيل (runtime traces) في دورة تغذية راجعة واحدة. قم بتقييم المسار بأكمله: الخطة، استخدام الأدوات، سلوك التعافي، والنتيجة النهائية. استخدم الاختبارات غير المتصلة لاكتشاف الأخطاء المعروفة والقابلة للتكرار قبل الإصدار. استخدم تتبعات التشغيل للعثور على الإخفاقات الجديدة التي لم تتوقعها. واستخدم المراجعة البشرية لاكتشاف المواضع التي تكون فيها معاييرك سطحية وتحتاج إلى تشديد.
لذا اسأل نفسك: أين ستضع مُقيّم التشغيل في سير عملك؟ قبل استدعاء أداة، أم بعد استدعاء أداة، أم فقط قبل إجراء تغيير محفوف بالمخاطر؟ تبدأ معظم الفرق بنطاق واسع جدًا، حيث تقيم كل شيء، ثم تتوقف تمامًا بسبب التكلفة. ابدأ بنطاق ضيق. اختر الإجراء الواحد الذي سيكون ضرره الأكبر إذا حدث خطأ ما، وضع المُقيّم هناك أولاً.
ابدأ بخطأ واحد مكلف
التقييم التشغيلي ليس تمرينًا بحثيًا، بل هو وسيلة لتنام بشكل أفضل بمجرد أن يصبح الوكيل متاحًا للاستخدام الفعلي. لست بحاجة إلى إطار عمل مثالي في اليوم الأول. أنت بحاجة إلى سير عمل واحد محدد جيدًا، ومعايير مكتوبة بلغة أعمال واضحة، ومُقيّم موضوع في اللحظة الدقيقة التي يصبح فيها الخطأ مكلفًا. إذا فعلت ذلك بشكل صحيح، فستمتلك أساسًا يمكنك الوثوق به حقًا.
إذا كنت ترغب في التعمق في تقييم الوكيل والتقييم أثناء التشغيل مع مجتمع من الممارسين، يمكنك العثور على مجتمع GyaanSetu التعليمي عبر https://t.me/GyaanSetuAi.