تحسين البرومبت بالتكرار: كيف تختبره وتطوّره

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

للطريقة خمس خطوات: حدّد شكل الجيد، واحتفظ بمُدخلات اختبار ثابتة، وغيّر شيئًا واحدًا في كل مرة، وقارن المخرجات، واعرف متى تتوقف.

حدّد شكل الإجابة الجيدة

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

1. سطر الموضوع أقل من 50 حرفًا.
2. تتبع صيغة Conventional Commits (fix: وfeat: وغيرهما).
3. نص الرسالة يقول لماذا كان التغيير ضروريًا، لا ما يُظهره الفرق (diff) أصلًا.
4. تذكر رقم الـ issue حين يوجد.

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

احتفظ بمجموعة صغيرة من مُدخلات الاختبار

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

اكتب الموجّه قالبًا فيه خانة للمُدخل، حتى تعمل كل نسخة على المادة نفسها بالضبط.

غيّر شيئًا واحدًا في كل مرة

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

النسخة 1النسخة 2النسخة 3

EditCopy

اكتب رسالة commit بالإنجليزية لهذا الفرق.- if len(password) > 8: + if len(password) >= 8: return True

Try it

Example replyReplies vary between models and runs.

Update password length validation

This commit updates the password validation logic by changing the comparison operator from > to >=. As a result, passwords that are exactly 8 characters long will now be considered valid. This change improves the accuracy of the validation and provides a better experience for users creating accounts.

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

قارن المخرجات جنبًا إلى جنب

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

وللمعايير الدقيقة، يمكن أن يؤدي استدعاء نموذج ثانٍ المرور الأول من التقييم. الصق المخرجات في موجّه تقييم مع المعايير مكتوبة بوضوح:

قيّم المخرجات وفق معايير ثابتة

EditCopy

Fill inالمعايير

افحص كل مخرج من المخرجات التالية وفق المعايير. لكل معيار، أجب بنجاح أو فشل مع سبب قصير يقتبس من المخرج. احكم على المعايير المذكورة فقط. لا تكافئ الطول أو الأسلوب. المعايير: 1. سطر الموضوع أقل من 50 حرفًا. 2. يتبع Conventional Commits. 3. النص يقول لماذا كان التغيير ضروريًا، لا ما يُظهره الفرق. 4. يذكر رقم الـ issue. المخرج A: """ fix: accept passwords of exactly 8 characters Change the length check from > to >= so that passwords with exactly 8 characters pass validation. """ المخرج B: """ fix: accept passwords of exactly 8 characters The signup page asks for at least 8 characters, but the check rejected passwords of exactly that length, so users who followed the instructions could not sign up. Fixes #412 """ أجب بجدول فيه صف لكل معيار.

Try it

Example replyReplies vary between models and runs.

المعيار	المخرج A	المخرج B
1. الموضوع أقل من 50 حرفًا	نجاح: الموضوع 45 حرفًا	نجاح: الموضوع نفسه، 45 حرفًا
2. Conventional Commits	نجاح: يبدأ بـ "fix:"	نجاح: يبدأ بـ "fix:"
3. النص يشرح السبب	فشل: "Change the length check from > to >=" يعيد سرد الفرق	نجاح: "users who followed the instructions could not sign up"
4. يذكر الـ issue	فشل: لا رقم issue	نجاح: "Fixes #412"

تعامل مع المقيّم من النماذج على أنه مساعد، لا حَكَم. وثّق Zheng وزملاؤه عام 2023، في بحث "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena"، تحيّزات لدى النماذج المقيِّمة، منها تفضيل الإجابات الأطول والإجابة في موضع معين. اجعل المعايير قابلة للفحص، واطلب دليلًا مقتبسًا، وبدّل ترتيب A وB حين تقارن بين اثنين، واقرأ عينة من المخرجات بنفسك. والفحوص مثل عدّ الأحرف أكثر موثوقية كسطر كود منها كحكم نموذج.

أصلح الموجّه، لا المحادثة

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

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

إجراء المقارنة في الكود

ما إن يعمل الموجّه عبر واجهة API، يستطيع سكربت قصير إنتاج العرض المتجاور لكل نسخة وكل مُدخل اختبار. يستخدم هذا السكربت مكتبة Python من OpenAI ويكتب ملف markdown تقرؤه من أوله إلى آخره.

from openai import OpenAI

client = OpenAI()
MODEL = "your-model-id"  # e.g. from your provider's model list

# each prompt file contains {input} where the test diff goes
PROMPTS = {
    "v2": open("prompts/commit_v2.txt").read(),
    "v3": open("prompts/commit_v3.txt").read(),
}
TESTS = [open(f"tests/diff_{i}.txt").read() for i in range(1, 6)]

with open("results.md", "w") as out:
    for i, test in enumerate(TESTS, 1):
        out.write(f"## Test {i}\n\n")
        for name, template in PROMPTS.items():
            for run in (1, 2):
                response = client.chat.completions.create(
                    model=MODEL,
                    messages=[{"role": "user", "content": template.replace("{input}", test)}],
                )
                out.write(f"### {name}, run {run}\n\n{response.choices[0].message.content}\n\n")

متى تتوقف

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

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