مراقبة انجراف إنتاج LLM دون جمع كل شيء

ما يغطيه البحث والتوثيق

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

الأدلة: الحفاظ على الخصوصية، اكتشاف انجراف البيانات واستعادتها لتطبيقات LLM واسعة النطاق عبر تمثيلات الوكيل [1]تقييم لانج سميث [2]

شاهد ثلاثة أنواع من التغيير

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

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

احتفظ بسجل مراقبة مركز

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

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

مثال: المستندات الممسوحة ضوئيًا تتسبب في حدوث أعطال جديدة

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

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

أعط كل تنبيه خطوة تالية

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

• قم بتسجيل إصدارات التطبيق ومجموعة الاختبار والحكم وأخذ العينات.
• قارن الجودة داخل كل مجموعة مهام وكذلك بشكل عام.
• قم بمراجعة عينة واسعة إلى جانب الحالات التي تؤدي إلى التنبيهات.
• التحقق من قواعد الوصول والحذف للبيانات الأولية والتسميات المشتقة.

اجعل لوحة القيادة مفيدة أثناء وقوع الحادث

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

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

الأسئلة الشائعة