أنماط التحفيز التي تصمد عبر تحديثات النماذج: دليل تحفيز متين

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

يمكنك رؤية هذا الانقسام بوضوح في JSON. مجرد طلب JSON بشكل مهذب يُنتج ما بين 5-10% من المخرجات المشوهة تقريبًا، بينما يوصلك وضع JSON إلى ما بين 95-99% من المخرجات الصحيحة، والترميز المقيَّد بالمخطط يصل إلى 100% فعليًا (Ashvara). النية نفسها، ثلاث طبقات تطبيق، ومعدلات فشل مختلفة اختلافًا جذريًا في يوم الإصدار.

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

لماذا تتعفن التحفيزات: نمط الفشل الذي لا أحد يضع له إصدارات

لا تتدهور التحفيزات بشكل عشوائي. تتدهور على طول خط تسلسل يمكن التنبؤ به: الأجزاء التي تعتمد على سلوك نموذج بعينه تبطل مفعولها مع النقطة التفتيشية التالية، أما الأجزاء التي تُصرّح بما تريده فتصمد.

نوعان من التحفيز: ما يصف النية وما يستغل ثغرة

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

التحفيز الساذج بعبارة "please return JSON" لا يزال يُنتج ما يُقدَّر بـ 5-10% من المخرجات المشوهة (Ashvara)، وهذا الرقم خاصية للنموذج لا لتحفيزك. غيّر النموذج وسيتغير الرقم. لم تكتب العقد مطلقًا، لذا لا تملك شيئًا تُلزم به النموذج الجديد.

ما الذي ينكسر فعلًا في يوم الإصدار

الانكسار نادرًا ما يكون صاخبًا. يبدأ المحلل في الإخفاق عند فاصلة لاحقة (ما يقرب من 40% من أخطاء JSON في أحد التحليلات تأتي من هذا تحديدًا، Flying Fish Space)، أو يصبح النموذج أكثر محادثةً ويُضيف جملة مقدمة حول الإخراج النظيف. في الوقت ذاته، وتيرة إصدار نماذج جديدة تعني أن النقطة التفتيشية التي ضبطت عليها ربما لن تكون هي المُخدِّمة للطلبات في الربع القادم.

قارن ذلك باستدعاء مقيَّد بالمخطط، حيث يُقيَّد توليد البيانات بالشكل الذي وفّرته ويكون الصحة النحوية فعليًا 100% (Ashvara). التطبيق يعيش خارج نص التحفيز. يمكن لتحديث النموذج أن يُغير النبرة والإسهاب وعمق التفكير دون أن يمسّه.

اختبار المتانة: هل سيظل هذا التحفيز منطقيًا لنموذج أذكى؟

سؤال واحد يُوجَّه لكل تحفيز تمتلكه: لو أصبح النموذج أكثر قدرةً بمرتين بين عشية وضحاها، هل ستظل هذه التعليمة تؤدي عملًا مفيدًا؟

"أعد كائنًا بمفاتيح id وstatus وconfidence، حيث يكون status إحدى ثلاث قيم حرفية" تنجح. RFC 8259 يُثبّت بالفعل المفردات التي تستعيرها: أربعة أنواع بدائية، ونوعان منظمان، وثلاثة أسماء حرفية بالأحرف الصغيرة بالضبط (RFC 8259). هذه التعليمة مقروءة لأي نموذج، الآن أو لاحقًا. "خذ نفسًا عميقًا وفكّر خطوة بخطوة" تفشل، لأنها تُعوّض ضعفًا ربما لن يمتلكه الإصدار القادم. احذف التعويضات واحتفظ بالعقود.

أنماط هندسة التحفيز القابلة للنقل: الدور، السياق، المهمة، التنسيق

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

الفتحات الأربع وما ينتمي لكل منها

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

السياق هو كل ما لا يمكن للنموذج معرفته: المخطط، النظام الأعلى، الحالات الحدية التي واجهتها في الإنتاج بالفعل، وحقيقة أن محللك يرفض BOM بترميز UTF-8. المهمة هي الفعل الوحيد ومفعوله. التنسيق هو عقد الإخراج، ويجب أن يكون دقيقًا بما يكفي للتحقق منه آليًا.

فتحة تنسيق تقول "أعد JSON" هي مجرد أمنية. فتحة تنسيق تُسمّي المفاتيح وأنواعها وما يحدث عند عدم معرفة قيمة هي عقد يمكنك اختباره. يمنحك JSON أربعة أنواع بدائية (سلسلة نصية، رقم، قيمة منطقية، null) ونوعين منظمين، كائنات ومصفوفات (RFC 8259)، لذا ثمة مفردات محدودة صغيرة يمكن الدقة فيها. قل null بدلًا من "اتركه فارغًا"، لأن الأسماء الحرفية true وfalse وnull بأحرف صغيرة ولا شيء آخر قانوني (RFC 8259).

لماذا ينتقل الهيكل عبر Claude وGPT وGemini

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

معظم أدوات هندسة التحفيز الـ 212 التي تُقولب هذا الهيكل في دليلنا تبيع لك الفتحات كنموذج. يمكنك الحصول على نفس التأثير بـ heredoc وأربعة تعليقات.

كتابة القيود كحقائق لا تعاويذ

ثمة اختبار لتحديد ما إذا كان سطر ما ينتمي لتحفيزك: هل يستطيع مقاول كفء التصرف بناءً عليه دون طرح سؤال متابعة؟ "كن شاملًا" تفشل. "أسماء الخصائص بين علامتي اقتباس مزدوجتين، لا فاصلة لاحقة بعد العنصر الأخير" تنجح، وهي تُعيّن أنماط فشل حقيقية، إذ تُشكّل الفواصل اللاحقة وحدها ما يقرب من 40% من أخطاء JSON في أحد التحليلات (Flying Fish Space).

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

إعادة كتابة عملية: قبل وبعد

النسخة اللاحقة لا تقول شيئًا عن شخصية النموذج وتقول كل شيء عن بياناتك. لاحظ أن null و{} كلاهما JSON صحيح لكنهما يعنيان أشياء مختلفة (Jsonic)، لذا اختر أحدهما واكتبه. الأصفار البادئة غير قانونية في أرقام JSON أيضًا (MDN)، وهذا ما يجعل فتحة التنسيق تُصرّح بقاعدة العدد الصحيح بدلًا من الاتكاء على تذكّر النموذج للقواعد النحوية.

سقالات الأمثلة القليلة المُضبَطة للنقل

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

أمثلة تُعلّم حدود القرار لا المفردات

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

ينطبق نفس الاختبار على شكل الإخراج. مثال واحد يُوضح أن النتيجة الفارغة هي [] وليس null يساوي أكثر من خمسة أمثلة على نتائج مُملوءة، إذ المصفوفة الفارغة وnull كلاهما JSON صحيح ويعنيان أشياء مختلفة (Jsonic). النماذج تُخمّن بشكل مختلف في ذلك، ومثال واحد يُحسمه للأبد.

الحالات الحدية والسلبية تستحق تكلفة رموزها

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

تنجح الأمثلة السلبية حين تقرنها بالتصحيح بدلًا من ذكر النهي. أظهر الإخراج المشوه والمصحَّح جنبًا إلى جنب، وسيكون الحد ملموسًا. تعليمات مجردة مثل "لا تستخدم علامات اقتباس مفردة" تتقادم بسرعة، وعلامات الاقتباس المفردة هي أحد المخالفين المتكررين خلف JSON المشوه، إلى جانب الفواصل اللاحقة التي تُشكّل ما يقرب من 40% من الأخطاء في أحد التحليلات (Flying Fish Space).

كم عدد الأمثلة، ومتى تتراجع إلى الصفر

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

تراجع إلى الصفر حين يؤدي المخطط الوظيفة. الترميز المقيَّد وفق مخطط مُوفَّر يمنحك JSON صحيح نحويًا بنسبة 100% فعليًا (Ashvara)، لذا أمثلة التنسيق هي وزن زائد هناك. احتفظ بالأمثلة للحكم، وأنفق المخطط على البنية.

رائحة الإفراط في التخصيص: أمثلة سيُقلّدها النموذج التالي حرفيًا أكثر مما ينبغي

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

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

عقود الإخراج التي تعيش أطول من النموذج

ادفع التطبيق أسفل المكدس حتى يتوقف التنسيق عن الاعتماد على مزاج نقطة التفتيش في ذلك اليوم. الطلب المهذب لـ JSON هو أضعف مستوى متاح، وهو ما تعمل عليه معظم أكواد الإنتاج حتى الآن.

ثلاث مستويات من الموثوقية: طلب نثري، وضع JSON، ترميز مقيَّد

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

ما يجب أن يُحدده العقد فوق "أعد JSON"

سمّ المفاتيح، والنوع خلف كل مفتاح، والسلوك حين لا يملك النموذج شيئًا يضعه هناك.

• كل مفتاح مُهجَّأ بالضبط كما يتوقعه محللك، مع نوع مستمد من الأنواع الستة في JSON: أربعة أنواع بدائية (سلسلة نصية، رقم، قيمة منطقية، null) ونوعان منظمان، كائن ومصفوفة (RFC 8259).
• الأسماء الحرفية بأحرف صغيرة فقط. القواعد النحوية تسمح بثلاثة منها بالضبط: false وnull وtrue (RFC 8259).
• أسماء مفاتيح فريدة داخل كل كائن، وهو ما يوصي به RFC 8259 لضمان اتفاق كل محلل على نفس تعيين الاسم-القيمة.
• هل تُحذف المفاتيح الاختيارية أم تُصدَر بقيمة null، وأي enum تتوقعه مكتوبًا كسلاسل حرفية.

أنماط الفشل التي تستحق التشفير: الفواصل اللاحقة، علامات الاقتباس المفردة، السلاسل غير المُهرَّبة

يضع أحد التحليلات الفواصل اللاحقة عند نحو 40% من جميع أخطاء JSON، وتغطي علامات الاقتباس المفردة، والاقتباسات غير المُهرَّبة داخل السلاسل، والفواصل المفقودة، وأحرف BOM المخفية في UTF-8 معظم الباقي (Flying Fish Space). تستغرق هذه الأخطاء الخمسة نحو 25 رمزًا لحظرها صراحةً في فتحة التنسيق، والحظر يبقى صحيحًا عبر كل نموذج ستُشير إليه. اقرنه بخطوة تحقق-ثم-تنسيق من جانبك بدلًا من الوثوق بالسلسلة (QuickTinyData).

كائن فارغ، مصفوفة فارغة، null: ثلاثة أجوبة مختلفة

هنا تتسرب العقود بين إصدارات النماذج دون أن يلاحظ أحد. الكائن الفارغ والمصفوفة الفارغة كلاهما JSON صحيح، وكلاهما يعني شيئًا مختلفًا عن null (Jsonic). نقطة تفتيش تُعيد [] لعدم وجود نتائج، والتالية تُعيد null، وكودك الدفعي يعامل إحداهما كخطأ.

اختر التمثيل، صرّح به في العقد، وتحقق منه. محللك يحتاج أيضًا أن ينجو من قيمة مجردة في المستوى الأعلى، إذ أي قيمة JSON منفردة تُعدّ مستندًا كاملًا، بما في ذلك سلسلة نصية مستقلة أو الرقم 42 (Jsonic).

الحيل الهشة التي تموت مع كل إصدار

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

'فكّر خطوة بخطوة' العامة كإضافة جانبية

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

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

التهديدات والرشاوى وضغط التمثيل الدرامي

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

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

حيل التنسيق التي تُقاتل المُرمِّز

حشو التحفيزات بطلبات بأحرف كبيرة، وثلاثة علامات تعجب، أو سلاسل طويلة من الفواصل كـ##### هو خرافة. للجزء الخاص بالفواصل حبة حقيقة (حدود القسم الواضحة تساعد)، لكن التصعيد لا يفيد. سطران جديدان وعلامة تشبه XML تتفوقان على أربعين علامة تجزئة.

نفس الأمر لـ"لا كتل كود، لا مقدمة، لا تفسير، أخرج JSON فقط" مُرصوفة ثلاث مرات. قلها مرة في فتحة التنسيق ثم ضع الضمان حيث تعيش الضمانات فعلًا: تقييد التوليد بمخطط مُوفَّر هو ما يأخذك إلى JSON صحيح نحويًا بنسبة 100% فعليًا (Ashvara)، ولا تقترب أي كمية من النواهي على مستوى التحفيز من ذلك الرقم.

التوسل على مستوى التحفيز حيث ينبغي وجود محلل

أنماط الفشل مملة وبنيوية: فواصل لاحقة بعد العنصر الأخير، مفاتيح غير مُقتبَسة، أحرف اقتباس غير صحيحة، فواصل مفقودة، أقواس غير متطابقة (QuickTinyData). الفواصل اللاحقة وحدها تُشكّل ما يقرب من 40% من أخطاء JSON في مجموعة أخطاء واحدة (Flying Fish Space)، وهي محظورة بالتنسيق نفسه (MDN). لا يُغلق أي قدر من الطلب المهذب تلك الفجوة.

احذف التوسل. ضع مخططًا ومُحقِّقًا بدلًا من ذلك، واترك التحفيز يقول ما تعنيه الحقول.

حلقات التقييم تعامل التحفيزات كأدوات موضوعة تحت إصدارات

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

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

الحد الأدنى لمجموعة التقييم القابلة للتطبيق: 20 حالة، تأكيد واحد لكل منها

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

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

تحقق أولًا ثم نسّق: استعارة سير عمل تصحيح أخطاء JSON

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

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

معرفة توزيع الأخطاء تخبرك بما تتحقق منه. يضع أحد التحليلات الفواصل اللاحقة عند نحو 40% من أخطاء JSON، وتُشكّل علامات الاقتباس المفردة، والاقتباسات غير المُهرَّبة داخل السلاسل، والفواصل المفقودة، وأحرف BOM المخفية في UTF-8 الجزء الأكبر من الباقي (Flying Fish Space). جدير بـ BOM تلك تأكيد مخصص، إذ إنها غير مرئية في كل محرر ستستخدمه لفحص الإخراج.

تشغيلات الانحدار في يوم الإصدار

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

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

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

تثبيت الإصدارات، وما تفعله حين لا تستطيع

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

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

نقل تحفيز واحد عبر Claude وGPT وGemini

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

ما يبقى متطابقًا: الهيكل، الأمثلة، العقد

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

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

احتفظ بمجموعة تقييمك محايدة تجاه البائعين أيضًا. عشرون حالة تنجح على Claude وتفشل على Gemini تخبرك بشيء مفيد. عشرون حالة مكتوبة وفق خصائص Claude لا تخبرك بشيء.

ما تُعيد ضبطه لكل مزوّد: وزن رسالة النظام، الفواصل، API التطبيق

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

الأخير هو الجزء الدقيق. وضع JSON بأي نكهة يُعطيك الصحة النحوية ويقف عند ذلك: ملاحظات الإنتاج تضعه عند 95-99% صحيح نحويًا، بينما تقييد التوليد بمخطط مُوفَّر يصل إلى 100% فعليًا (Ashvara). لا أيٌّ من المستويين يقول شيئًا عما إذا كانت المفاتيح هي التي طلبتها، لذا يبقى فحص المخطط في كودك بغض النظر عن المزوّد الذي تستخدمه. لو كنت تختار أهدافًا، يستحق الأمر مرورًا سريعًا لمقارنة النماذج نفسها قبل الالتزام، والمنصات متعددة المزوّدين في دليلنا ستمتص بعض عمل المحوّل هذا نيابةً عنك.

قائمة تحقق قابلية النقل قبل الشحن

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

لو فشل تحفيز ما هذه القائمة على مزوّد واحد فقط، يكون الخلل في الغالب في المحوّل، لا في الهيكل.

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

هل أحتاج إلى إعادة كتابة تحفيزاتي في كل مرة يشحن نموذج جديد؟

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

هل لا تزال عبارة 'فكّر خطوة بخطوة' تعمل على النماذج الحالية؟

إنها في معظمها وزن زائد الآن. كانت تلك العبارة حلًا مؤقتًا للنماذج التي تقفز مباشرة إلى الجواب، والنماذج الحالية بالفعل تُفكّك العمل متعدد الخطوات دون أن تُخبَر بذلك. الأسوأ أن إلحاقها بتحفيز يطلب مخرج JSON صارم يُغري النموذج بإصدار نص استدلالي حول الكائن، وهو بالضبط فئة الفشل التي تدفع التحفيزات الساذجة إلى معدل JSON مشوه يُقدَّر بـ 5-10%. لو أردت التفكير، أعطِه حقلًا مُسمَّى في مخططك واترك المحلل يفصله عن الحمولة.

هل وضع JSON كافٍ، أم أحتاج مخططًا؟

استخدم المخطط. وضع JSON يوصلك إلى ما يقرب من 95-99% مخرج صحيح نحويًا، وهو يبدو جيدًا حتى تُشغّل عشرة آلاف استدعاء يوميًا وتتحمل مئة حالة فشل. الترميز المقيَّد بالمخطط يأخذ صحة الصياغة إلى 100% فعليًا، ويُثبّت أيضًا أسماء مفاتيحك، وهو ما يهم لأن RFC 8259 يعامل كائن JSON ككوليكشن غير مُرتَّب من أزواج الاسم-القيمة ويوصي فقط بالأسماء الفريدة. الصحة النحوية ليست صحة دلالية، لذا استمر في التحقق من الكائن المُحلَّل وفق قواعدك الخاصة على أي حال.

كم عدد الأمثلة القليلة التي يجب أن يتضمنها التحفيز المتين؟

اثنان إلى أربعة، واخترها لتغطية الحالات الحدية لا للحجم. الأمثلة التي تُوضح نفس المسار السعيد مرارًا لا تُعلّم النموذج شيئًا لا يفعله بالفعل؛ الأمثلة التي تُثبّت الحالات الحرجة هي التي تنتقل عبر النماذج. للمخرج المنظَّم، أنفق مثالًا واحدًا على الأقل على التمييز بين حاوية فارغة وقيمة مفقودة، إذ [كائن فارغ {} ومصفوفة فارغة [] كلاهما JSON صحيح لكنهما مختلفان دلاليًا عن null](https://jsonic.io/guides/json-examples). لو كانت أمثلتك تحتوي على تنسيق يرفضه محلل صارم، فأنت تُعلّم الفشل: الفواصل اللاحقة وحدها تُشكّل نحو 40% من أخطاء JSON في أحد التحليلات.

ما الحجم الذي تحتاجه مجموعة تقييم التحفيز لتكون مفيدة؟

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

هل يمكن لنفس التحفيز أن يعمل دون تغيير على Claude وGPT وGemini؟

نص التعليمات ينتقل بشكل نظيف. طبقة تطبيق الإخراج لا تنتقل، لأن وضع JSON والترميز المقيَّد بالمخطط يُضبطان بشكل مختلف لكل مزوّد، لذا خطّط لتحفيز واحد وثلاثة محوّلات رفيعة. يساعد الاحتفاظ بالعقد في تنسيق يتفق عليه كل مزوّد بالفعل: RFC 8259 مستقل عن اللغة ويُعرّف أربعة أنواع بدائية إضافةً إلى الكائنات والمصفوفات، مع true وfalse وnull بأحرف صغيرة كأسماء حرفية وحيدة. لو كنت تتسوق لأدوات لإدارة التحفيزات عبر المزوّدين، يُدرج دليلنا 212 أداة هندسة تحفيز و324 قيدًا تحت نماذج الذكاء الاصطناعي.