هل بقي مخرج النموذج صالحاً بعد تحديث المخطط؟ مشاريع تخرج الذكاء الاصطناعي

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

ابدأ بعقد واضح

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

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

صمم تغييرات صغيرة مقصودة

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

يمكن أن يستلهم الفريق من JSONSchemaBench الذي يدرس تحديات المخططات المنظمة وتغطية قيودها، ومن StructEval الذي يتناول تقييم المخرجات المنظمة. استخدم الأوراق لتحديد أسئلة الاختبار، لا لادعاء أن مشروعك يكرر benchmark بحجمه أو نتائجه.

ابن حالات مرجعية متعددة

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

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

اختبر الهيكل والدلالة على حدة

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

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

مثال تغيير حقل الميزانية

في الإصدار الأول قد تكون budget رقماً. في الإصدار الثاني تصبح كائناً يحتوي amount وcurrency. المخرج “1200” قد يفشل validator الجديد، لكن التحويل الآلي إلى amount=1200 لا يعرف العملة. ينبغي أن يعرض harness أن الإصدار الجديد يحتاج معلومة إضافية، لا أن يخترعها. إذا كان prompt يحدد الدينار الأردني بوضوح، يمكن اختبار ما إذا كان النموذج يعيد رمز العملة المتوقع.

احتفظ بالأمثلة التي نجحت والتي لم تنجح، وبيّن مصدر القاعدة. إن عدل الفريق prompt بالتزامن مع schema، افصل التجربتين أو صمم مصفوفة تغييرات؛ وإلا لن تعرف سبب التحسن.

اجعل المقارنة قابلة للإعادة

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

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

ما الذي لا يقيسه المشروع؟

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

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

ما الذي يناقشه الفريق؟

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

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