إيجي تاج · اعرف. ناقش. جرّب. نفّذ.
المطالبة الجيدة للذكاء الاصطناعي: بناء أمثلة قابلة للتكرار

المطالبة الجيدة للذكاء الاصطناعي: بناء أمثلة قابلة للتكرار

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

دليل عملي

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

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

ما الذي يجعل المثال قابلًا للتكرار؟

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

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

حوّل الطلب العام إلى مهمة لها شروط قبول

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

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

ابنِ قالبًا يفصل التعليمات عن البيانات

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

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

اختر أمثلة تكشف القرارات المهمة

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

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

حدّد شكل المخرجات ومعنى القيم الناقصة

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

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

كوّن مجموعة تحقق مستقلة عن أمثلة القالب

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

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

شخّص الإخفاق وعدّل سببًا واحدًا في كل مرة

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

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

أدر التكرار والخصوصية وحدود الاعتماد

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

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

أسئلة شائعة

هل الأفضل كتابة مطالبة طويلة أم قصيرة؟

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

هل يجب أن تتطابق الإجابة حرفيًا حتى أعتبر المطالبة قابلة للتكرار؟

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

كيف أعرف أن المثال يعلّم قاعدة بدل أن يشجع نسخ محتواه؟

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

متى ينبغي تقسيم المهمة إلى أكثر من مطالبة؟

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

هل تريد الاحتفاظ بالمقال أو إعادة استخدامه؟
مجتمع إيجي تاجعن المجتمع

شارك في تقييم ونقاش المقال

رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.

تفاعل مع المقالاختر التفاعل المناسب، ويمكنك تغيير رأيك لاحقًا.
قيّم جودة المقاللا توجد تقييمات بعد — كن أول من يقيّم.

نقاش القراء

النقاش

جارٍ تحميل التعليقات…

بعد هذه المادة

تابع القراءة

كل مواد الذكاء الاصطناعي
من نفس القسم04
  1. 02
  2. 03
  3. 04
اختيار القراء

الأكثر قراءة

الترتيب الكامل
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
يتجدد مع النشر

أحدث المواد

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06