كيفية تشخيص إخفاقات ضمان الجودة في نماذج اللغة الكبيرة المخصصة في 7 خطوات

ملاحظات من دورة الإطلاق — الجزء السادس

بدأت مجموعة اختبارات ضمان جودة مُسجَّلة بالنقاط في الإشارة إلى نموذج للأسئلة والأجوبة الطبية لدى أحد العملاء. الرقم الرئيسي — الجودة الإجمالية عبر كل الشرائح — انخفض 6 نقاط بين عشية وضحاها. أمضى الفريق يومين في تنقيح النموذج. أعادوا تشغيل عمليات الضبط الدقيق. تراجعوا إلى الإصدار السابق. لم تتحرك الأرقام.

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

عبر عمليات إطلاق عملائنا، هذا هو النمط المهيمن. إنذار “إخفاق ضمان الجودة” هو العَرَض. والسبب يكون النموذج تقريباً مرة واحدة من كل سبع مرات. المرات الست الأخرى، يكون الخلل في مكان ما أعلى المجرى: في تصميم التقييم، أو في معايرة الحَكَم، أو في بصمة قالب الموجِّه (SHA)، أو في خط أنابيب المعالجة المسبقة، أو في إصدار مجموعة البيانات، أو في فهرس الاسترجاع. كل فئة من هذه الأخطاء تبدو متطابقة من زاوية الإنذار — رقم انخفض — لكن لها إصلاحاً مختلفاً تماماً.

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

شجرة القرار

الشجرة متسلسلة لأن خطواتها تتدرج من رخيصة إلى مكلفة. الخطوة 1 هي git diff لمجموعة التقييم؛ الخطوة 7 هي دورة ضبط دقيق كاملة. تريد أن تقضي عشر دقائق على كل من الفحوصات الستة الرخيصة قبل أن تقضي أسبوعاً على الفحص المكلف.

الخطوة 1 — هل غطّى التقييم هذه الشريحة؟

العَرَض. تنخفض الجودة الإجمالية، لكن التحليل لكل شريحة يُظهر شريحة واحدة تتهاوى بينما الباقي ثابت. أو — بشكل أكثر إرباكاً — كل شريحة تنخفض قليلاً، جميعها بمقادير متشابهة.

التشخيص. قارن بصمة كشف مجموعة التقييم مع تلك الخاصة بالإصدار السابق. إذا تغيَّرت مجموعة التقييم ولم تغيِّر النموذج، فالتراجع في التقييم لا في النموذج.

# قارن بصمة كشف مجموعة التقييم بين الإصدارات
curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.eval_suite_sha256'
curl https://api.divinci.ai/v1/releases/rel_8f72b1 | jq '.eval_suite_sha256'
# مختلفة؟ تقييمك تغيَّر. دقِّق فيما أُضيف.

الإصلاح. إما أن تتراجع عن تغيير مجموعة التقييم (إذا كان غير مقصود)، أو وسِّع تغطية التدريب لتطابق التقييم الجديد (إذا كانت الشريحة الجديدة شاغلاً إنتاجياً حقيقياً). لا تطلق إصلاحاً لتراجع نموذج لمعالجة مشكلة تغطية تقييم — ستجعل النموذج أسوأ في ما كان يحسن فعله.

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

الخطوة 2 — هل الحَكَم معاير مقابل البشر على هذه الشريحة؟

العَرَض. شريحة جديدة على مجموعة التقييم تُسجِّل نقاطاً ضعيفة، لكن المراجعة البشرية لمخرجات النموذج عليها تُقيِّمها أنها جيدة. الحَكَم يعتقد أن النموذج يفشل؛ البشر لا يعتقدون ذلك.

التشخيص. احسب معامل سبيرمان ρ بين تقييمات الحَكَم اللغوي وعينة صغيرة مُقيَّمة بشرياً (50 عنصراً) على الشريحة المُخفقة. إذا كان ρ < 0.4، فإن الحَكَم لا يقيس ما يقيسه البشر على هذه الشريحة.

curl -X POST https://api.divinci.ai/v1/judges/<judge_id>/calibrate \
  -d '{ "slice": "pediatric-oncology-dosing", "human_ratings_csv": "..." }'
# ← { "spearman_rho": 0.31, "interpretation": "judge_uncalibrated_for_slice" }

الإصلاح. إما أن تختار نموذج حَكَم مختلفاً لهذه الشريحة، أو استخدم سلسلة حُكّام مع حَكَم مُحَكَّم. تُظهر MT-Bench^[1] أن GPT-4 كحَكَم يتفق مع البشر >80% في المتوسط، لكن مع تباين لكل فئة من 86% (البرمجة) إلى 36–44% (الكتابة/العلوم الإنسانية). التباين هو الرقم الفاعل؛ “جيد في المتوسط” يُخفي شرائح يكون فيها الحَكَم على خطأ.

أين يختبئ هذا في خط أنابيبنا. المرحلة 2 — البوابة تتطلب حَكَماً معايراً لكل شريحة. تُوثِّق تدوينة معايرة الحَكَم اللغوي الإجراء. إذا أُضيفت الشريحة إلى التقييم دون خطوة معايرة، فلديك بوابة غير جديرة بالثقة بنيوياً.

الخطوة 3 — هل بصمة قالب الموجِّه تطابق الإنتاج؟

العَرَض. تنخفض الجودة، لكن model_ref و dataset_ref لم يتغيرا. لا شيء يتعلق بالتدريب تغيَّر. النموذج هو نفس النموذج. ومع ذلك.

التشخيص. قارن بصمة prompt_template_ref في كشف الإصدار المُخفق بتلك الخاصة بالإصدار السابق. تعديل من 38 حرفاً على موجِّه النظام “يحسِّن الإيجاز” قد يُغيِّر السلوك التابع أكثر من إعادة تدريب كاملة.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.prompt_template_ref'
curl https://api.divinci.ai/v1/releases/rel_8f72b1 | jq '.prompt_template_ref'
# مختلفة؟ اسحب الفرق. انظر إليه بعناية.

الإصلاح. عامل الموجِّهات كأنها كود. تُغطي تدوينة الـ 10 إخفاقات إطلاق نمط الإخفاق المتعلق بالتحرير من اللوحة — يُسمي تشريح تيانبان لـ كذبة Semver^[2] هذا النمط بوصفه نمط الإخفاق المهيمن في 2026. إن استطعت إثبات تغيُّر الموجِّه، فقد وجدت خللك.

الخطوة 4 — هل خط أنابيب المعالجة المسبقة يطابق الإنتاج؟

العَرَض. النموذج ينجح في التقييم محلياً. نفس النموذج يُخفق في نفس التقييم في الإنتاج. نفس model_ref، نفس الموجِّه، نفس مجموعة البيانات.

التشخيص. اسحب بصمة preprocessing_ref من كشف الإنتاج وتحقق من أن التقييم جرى بنفسها. الحالة الكلاسيكية: التدريب يُسوِّي الفراغات ويُحوِّل إلى أحرف صغيرة؛ الإنتاج لا يفعل. التقييم جرى عبر معالجة الإنتاج المسبقة؛ كل شيء تحقَّق. حتى قام أحدهم بتحديث المعالجة المسبقة في جانب واحد فقط.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.preprocessing_ref'
# قارن بالمعالجة المسبقة التي استخدمها فعلاً جهاز التدريب/التقييم.

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

الخطوة 5 — هل بصمة مجموعة البيانات تطابق الإنتاج؟

العَرَض. نقاط تقييم البوابة من الإصدار المُخفق مختلفة عن نقاط تقييم البوابة لـ نفس النموذج في اليوم السابق.

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

diff <(curl .../rel_a01c66 | jq '.dataset_version') \
     <(curl .../rel_8f72b1 | jq '.dataset_version')

الإصلاح. اعتمد البصمة المعتمدة على المحتوى لمجموعات بياناتك. اسم مجموعة البيانات ليس إصداراً؛ البصمة هي.

الخطوة 6 — هل بصمة فهرس الاسترجاع تطابق الإنتاج؟

العَرَض. لأحمال RAG فقط. تنخفض الجودة على الأسئلة التي تعتمد على السياق المُسترجع. أسئلة الإجابة المباشرة لم تتغير.

التشخيص. اسحب بصمة retrieval_index_ref من الكشف. قارنها بفهرس الاسترجاع المستخدم في تقييم البوابة. تحدَّث فهرس RAG بين عشية وضحاها (تشغيل استيعاب جديد)؛ خزَّن تقييم البوابة استرجاعاً أقدم؛ استخدم الكنار الإنتاجي الجديد.

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.retrieval_index_ref'

الإصلاح. اربط بصمة فهرس الاسترجاع في الكشف، تماماً كما نربط المعالجة المسبقة. وتيرة AutoRAG الآلية لتدوير الفهرس تجعل هذا الفحص جديراً بالاهتمام بشكل خاص — الفهرس سيتحدَّث عليك سواء أذنت بذلك أم لا، إن لم تكن تثبِّته.

الخطوة 7 — النموذج نفسه، أخيراً

ست خطوات في الداخل. التقييم يغطي الشريحة. الحَكَم معاير. بصمة الموجِّه تطابق. المعالجة المسبقة تطابق. مجموعة البيانات تطابق. فهرس الاسترجاع يطابق.

الآن — وفقط الآن — كسبت حق النظر إلى النموذج.

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

curl -X POST https://api.divinci.ai/v1/releases/<failing_id>/diff-eval \
  -d '{ "baseline_release_id": "<prior_id>", "slices": ["legal-IP-licensing"] }'
# ← { "spearman_rho_failing": 0.41, "spearman_rho_baseline": 0.68, "delta": -0.27 }

إذا أكدت الدلتا تراجعاً حقيقياً: يُطلَق التراجع التلقائي (إن لم تكن قد استدعيته يدوياً)، ويُعاد تدريب النموذج المُخفق مقابل مجموعة موسَّعة تغطية الشرائح. إذا فاتت البوابةَ التي رقَّت هذا الإصدار الشريحةُ في المقام الأول، فالبوابة أيضاً خلل — القدرة 4 المفقودة من خط أنابيب إطلاقك.

كيف يبدو التوزيع فعلاً

تأطير “1 من 7” سابقاً لم يكن أداة بلاغية. إنه تقريباً التوزيع الذي نراه عبر عمليات إطلاق العملاء. من كل سبعة إنذارات ضمان جودة:

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

ما لا تحلّه هذه التدوينة

ثلاث قيود بصراحة:

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

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

التراجع الحقيقي يمكن أن يركب على خلل غير متعلق بالنموذج. الحالات التي يكون فيها لديك كلاهما انحراف موجِّه و تراجع نموذج حقيقي هي الأسوأ، لأن الخطوة 3 تجد انحراف الموجِّه، فتُصلحه، ثم يُعاد إطلاق الإنذار. ترتيب التشخيص في هذه التدوينة يتعامل معها لكن يُضيف وقتاً منقضياً. لا اختصار لـ “كان الخلل في مكانين في آن واحد.”

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

لماذا يُنتج نموذجي اللغوي مخرجات مختلفة لموجِّهات متشابهة؟

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

كم مرة يجب أن تُعيد تقييم معايير نموذجك اللغوي؟

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

ما الذي يسبب الهلوسات في نماذج اللغة المخصصة؟

للهلوسات أسباب متعددة في أعلى المجرى — إخفاقات الاسترجاع (الخطوة 6 في الشجرة أعلاه)، وثغرات تغطية التدريب (الخطوة 1، بشكل غير مباشر)، ومشكلات مسار فك الترميز (شأن نموذجي حقيقي في الخطوة 7). تعالج AutoRAG الأسباب من جانب الاسترجاع بربط فهرس الاسترجاع في كشف الإصدار وإعادة التثبيت في كل إصدار. الاثنان الآخران يتطلبان إصلاحات على مستوى خط الأنابيب في أعلى مجرى النموذج.

كيف تعرف ما إذا كانت بيانات تدريبك هي المشكلة؟

إذا كانت بصمة مجموعة البيانات في الإصدار المُخفق تطابق بصمة مجموعة البيانات في الإصدار الجيد السابق (الخطوة 5 من الشجرة)، فالبيانات ليست السبب المباشر. إذا اختلفتا، فقد وجدتها. السؤال الأصعب — “هل مجموعة البيانات كاملة لتغطية شرائح إنتاجنا؟” — هو ما تختبره الخطوة 1. مجموعة بيانات كاملة للتقييم لكنها غير كاملة لحركة الإنتاج هي مشكلة تغطية شريحة.

هل يمكنك إصلاح إخفاقات ضمان الجودة دون إعادة تدريب النموذج كاملاً؟

نعم — ست مرات من كل سبع، لا يكون الإصلاح إعادة تدريب. الخطوات 1–6 في الشجرة لديها إصلاحات لا تمس النموذج: حدِّث التقييم، أعد معايرة الحَكَم، أعد تسجيل بصمة الموجِّه، أصلح المعالجة المسبقة، أعد تثبيت مجموعة البيانات، أو أعد تثبيت فهرس الاسترجاع. إعادة التدريب هي الخطوة 7، الإصلاح الأكثر تكلفة، محجوز لتراجعات النموذج الفعلية. مسار التدقيق لخط أنابيب الإطلاق يتيح لك إجراء هذه الإصلاحات في أعلى المجرى بنفس انضباط المصدرية الذي تستخدمه لتغيير نموذج.

المراجع

1. تباين LLM-as-judge لكل فئة. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). اتفاق GPT-4 الإجمالي مع البشر >80% مع تباين لكل فئة من البرمجة (86%) نزولاً إلى الكتابة (36–44%). مرجع للخطوة 2 — لماذا يجب قياس معايرة الحَكَم لكل شريحة بدلاً من افتراضها من رقم رئيسي منشور.
2. كذبة Semver. Tianpan — The Semver Lie: how an LLM minor update breaks production (أبريل 2026). تشريح نمط الإخفاق المهيمن لعام 2026. يُسمي انحراف موجِّه التحرير من اللوحة بأنه السبب الأكثر اقتباساً لحوادث إنتاج نماذج اللغة الكبيرة. مرجع للخطوة 3.
3. NIST AI RMF — وظيفة القياس. إطار NIST لإدارة مخاطر الذكاء الاصطناعي. تُغطي وظيفة "القياس" صراحةً صلاحية المعيار وتغطية التقييم كجزء من الحوكمة، لا كشأن هندسي منفصل. مُقتبسة كمرجع مؤسسي لمعاملة تصميم التقييم بوصفه الخطوة التشخيصية الأولى.
4. RAGAS — تقييم التوليد المعزَّز بالاسترجاع. Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation (arXiv:2309.15217). الإطار المرجعي لتقييم جانب RAG. مرجع للخطوة 6 — فصل إخفاقات الاسترجاع عن إخفاقات التوليد يتطلب انضباط تقييم واعٍ بـ RAG.
5. داخلي — توزيع الأسباب الجذرية عبر عمليات إطلاق العملاء. النسب المئوية في الرسم البياني الدائري هي ملاحظتنا الداخلية عبر عمليات إطلاق عملاء Divinci، وليست من معيار مضبوط. سيختلف توزيعك حسب نوع الحمل، ووتيرة الضبط الدقيق، وانضباط الفريق. الترتيب النسبي (هيمنة الخطوتين 1–2) ثابت عبر القائمة التي قسناها؛ النسب المئوية الدقيقة غير قابلة للنقل إلى بيئتك دون بياناتك الخاصة.
6. خط أنابيب الإطلاق المكوَّن من أربع مراحل. كيفية بناء خط أنابيب CI/CD لنماذج اللغة الكبيرة مع Divinci AI. كل خطوة تشخيصية في هذه التدوينة تقابل حقلاً في الكشف مربوطاً في المرحلة 1 — التسجيل. بدون انضباط الكشف في أعلى المجرى، يفقد التشخيص قبضته؛ لا يمكنك مقارنة ما لم تربطه.

التالي في هذه السلسلة: اختبار الانحدار الآلي لنماذج اللغة الكبيرة المخصصة في 2026. هذه التدوينة عن التشخيص بعد إطلاق إنذار ضمان جودة. التالية عن انضباط اختبار الانحدار الذي قاد الإنذار في المقام الأول — ما تضعه في التقييم، وكيف تُبقيه أميناً، وماذا تفعل عندما يبدأ اختبار الانحدار بمعارضة حَكَمك.