تقنية

تصحيح أمر فاشل: غير عنصرا واحدا ثم قارن

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

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

الخلاصة السريعة

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

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

حدد الخطأ والنتيجة المطلوبة

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

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

اكتب فرضية وعدل جزءا واحدا

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

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

افحص حالات أخرى دون تبديل الهدف

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

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

افصل التطوير عن فحص النسخة النهائية

توصي AWS باستخدام أمثلة للتطوير وأمثلة محجوزة لمراجعة تعميم النسخة النهائية، لا تعديلها مرارا على الأمثلة المحجوزة. [1]

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

المصادر ومتابعة القراءة

  1. AWS Amazon Bedrock: Design a prompt — Best practices for good generalization (يفتح في نافذة جديدة)docs.aws.amazon.com

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