كيف تقيّم أنظمة النماذج اللغوية قبل تشغيلها في الإنتاج؟

قد يحقق النموذج اللغوي نتائج قوية في معيار نظيف، ثم يتعثر في الحالات الغامضة التي تهم المستخدمين فعلياً داخل بيئة الإنتاج. هذا هو الدرس المركزي الذي تعرضه GitHub في مادة كتبها Mariko Wakabayashi وZixiao Chen بتاريخ 25 أغسطس 2026، استناداً إلى تجربة تقييم نظام يعتمد على نموذج لغوي للمساعدة في تقليل الإنذارات الكاذبة ضمن GitHub secret scanning.

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

ابدأ بقرار المنتج لا باختيار النموذج

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

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

اجعل التقييم اختبار تكامل قابلاً للتكرار

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

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

حاكِ مهمة الإنتاج ولا تكتفِ ببيانات نظيفة

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

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

تعامل مع الوسوم والبيانات بوصفها أدلة قابلة للفحص

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

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

حلّل الأخطاء واستخدم النموذج المقيّم بحذر

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

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

ما الذي أثبتته التجربة فعلاً؟

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

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