پرامپت‌نویسی عملی: از دستور مبهم تا خروجی قابل اتکا

چرا پرامپت خوب مهمه — و چرا کافی نیست

مدل هیچ چیزی درباره‌ی موقعیت تو نمی‌دونه مگر اینکه بهش گفته باشی. نه می‌دونه مخاطب این متن کیه، نه می‌دونه خروجی قراره کجا استفاده بشه، نه می‌دونه چه چیزی برات غیرقابل قبوله. پرامپت تنها جایی‌ست که این‌ها رو منتقل می‌کنی.

در عین حال، پرامپت‌نویسی سقف داره. اگه اطلاعاتی که برای انجام کار لازمه اصلاً در دسترس مدل نباشه، هیچ جمله‌بندی‌ای نجاتش نمی‌ده. اونجاست که بحث مهندسی کانتکست شروع می‌شه.

چهار تکه‌ای که هر پرامپت جدی داره

لازم نیست هر پیامی این ساختار رو داشته باشه، ولی وقتی خروجی مهمه و باید تکرارپذیر باشه، این چهار تکه معمولاً تفاوت رو می‌سازن:

1. کار — دقیقاً چه چیزی باید تولید بشه. یه فعل مشخص، نه یه موضوع.
2. زمینه — داده، محدودیت‌ها، مخاطب، و هر چیزی که مدل از بیرون نمی‌دونه.
3. قالب خروجی — ساختاری که انتظار داری. فهرست؟ JSON؟ چند بند؟ چه طولی؟
4. معیار خوب‌بودن — از کجا معلوم می‌شه خروجی قابل قبوله. این تکه رو بیشتر از همه جا می‌ندازن.

یک مقایسه‌ی مشخص

پرامپت ضعیف: «درباره‌ی این محصول یه متن تبلیغاتی بنویس». مدل نمی‌دونه برای کی، کجا، با چه لحنی، چه طولی، و چه چیزی رو نباید بگه.

پرامپت قوی: «برای صفحه‌ی محصول، سه بند بنویس که به یه مدیر محصول در یه شرکت کوچک بگه این ابزار چه مشکلی رو حل می‌کنه. لحن ساده و بدون اغراق. هیچ عددی که در متن زیر نیست ننویس. هر بند حداکثر سه جمله.» حالا هم کار روشنه، هم زمینه، هم قالب، هم مرز.

به‌جای صفت، نمونه بده

«حرفه‌ای باش»، «دقیق باش»، «خلاق باش» — این‌ها تقریباً بی‌اثرن، چون هر کدوم برای هر کسی معنی متفاوتی دارن. مؤثرترین جایگزین، دادن یه نمونه‌ی واقعی از خروجی درسته.

یک نمونه معمولاً از ده جمله توصیف بهتر جواب می‌ده. دو یا سه نمونه، وقتی خروجی تنوع داره، الگو رو تثبیت می‌کنه. چند نکته درباره‌ی انتخاب نمونه:

• نمونه باید همون شکلی باشه که واقعاً می‌خوای، نه نسخه‌ی ساده‌شده‌ش.
• اگه حالت‌های مرزی داری، یکی از نمونه‌ها باید حالت مرزی باشه.
• نمونه‌ی «اشتباه» هم کمک می‌کنه: «این شکلی ننویس» با یه مثال، از یه ممنوعیت کلی روشن‌تره.

به مدل جا بده فکر کنه

برای کارهایی که چند مرحله استدلال لازم دارن — محاسبه، مقایسه، تصمیم بین چند گزینه — خواستن جواب مستقیم معمولاً خطا می‌سازه. اگه به مدل بگی اول مراحل رو بنویسه و بعد نتیجه بگیره، کیفیت بالا می‌ره.

ولی این یه معامله‌ست: خروجی طولانی‌تر و گران‌تر می‌شه. راه میانه اینه که بخواهی استدلال رو جدا از جواب نهایی بده، تا بتونی فقط جواب رو استفاده کنی ولی در صورت اشتباه، مسیر رو ببینی.

ابتدا زیر عنوان «بررسی» فرض‌ها و محاسبه را بنویس.
سپس زیر عنوان «نتیجه» فقط عدد نهایی و واحدش را بنویس.
اگر داده‌ای برای محاسبه کم است، به‌جای حدس‌زدن بنویس چه چیزی کم است.

اون خط آخر مهم‌تر از چیزیه که به نظر میاد. مدل‌ها بدون اجازه‌ی صریح برای گفتن «نمی‌دانم»، معمولاً حدس می‌زنن. دادن یه مسیر خروج، بخش بزرگی از خطاهای اعتمادبه‌نفسی رو حذف می‌کنه.

سه الگویی که بیشتر از همه لازمت می‌شه

بیشتر کارهای واقعی توی یکی از این سه دسته می‌افتن. هر کدوم شکل پرامپت متفاوتی می‌خوان و شناختنشون از نوشتن هر بار از صفر جلوگیری می‌کنه.

استخراج: از متن آزاد به داده‌ی ساخت‌یافته

وقتی می‌خوای از یه فاکتور، ایمیل یا تیکت، فیلدهای مشخصی دربیاری. کلید اینجا اینه که اسکیما رو صریح بدی و بگی با فیلدی که در متن نیست چه‌کار کنه — وگرنه پرش می‌کنه.

از متن زیر این فیلدها را دربیاور و فقط JSON برگردان:
  invoice_id (رشته), total (عدد، بدون جداکننده), due_date (YYYY-MM-DD)

اگر فیلدی در متن نبود، مقدارش را null بگذار. حدس نزن.
هیچ توضیحی بیرون از JSON ننویس.

---
{{متن}}

دسته‌بندی: انتخاب از یک فهرست بسته

وقتی ورودی باید به یکی از چند برچسب مشخص تخصیص پیدا کنه. مهم‌ترین نکته، تعریف‌کردن برچسب‌هاست — نه فقط نام بردنشون — و گذاشتن یه برچسب برای «هیچ‌کدام»، چون بدون اون مدل مجبوره به زور یکی رو انتخاب کنه.

بازنویسی: حفظ معنا، تغییر شکل

خلاصه‌کردن، ساده‌کردن، تغییر لحن. تله‌ی اصلی اینه که مدل اطلاعات جدید اضافه می‌کنه. جمله‌ای که این رو مهار می‌کنه: «هیچ ادعایی که در متن اصلی نیست اضافه نکن؛ اگر چیزی مبهم است، همان ابهام را حفظ کن.»

پرامپت رو تکامل بده، حدس نزن

رایج‌ترین اشتباه اینه که وقتی خروجی بد می‌شه، کل پرامپت بازنویسی می‌شه. نتیجه اینه که هیچ‌وقت نمی‌فهمی چی کار کرد و چی نکرد. روش بهتر شبیه دیباگ کردنه:

1. سه تا پنج ورودی واقعی جمع کن که خروجی درستشون رو می‌دونی.
2. پرامپت فعلی رو روی همه‌شون اجرا کن و خطاها رو دسته‌بندی کن.
3. در هر دور فقط یک چیز رو عوض کن.
4. دوباره روی همون مجموعه اجرا کن. اگه یکی بهتر و یکی بدتر شد، تغییر خالص صفر بوده.

این کار حوصله می‌خواد ولی چند ساعت وقت‌گذاشتن روش، از هفته‌ها ور رفتن حدسی جلو می‌زنه. مخصوصاً وقتی پرامپت قراره توی محصول زندگی کنه و هزاران بار اجرا بشه.

خطاهایی که معمولاً پیدا می‌کنی

• دستورهای متناقض — جایی گفتی کوتاه باشه، جای دیگه گفتی همه‌چیز رو پوشش بده.
• مرز نامشخص — نگفتی چه چیزی رو نباید بگه، پس گفته.
• قالب توصیف‌شده ولی نشون‌داده‌نشده — فقط گفتی JSON، نمونه ندادی.
• زمینه‌ی گم‌شده — اطلاعاتی که فرض کردی مدل داره ولی نداشته.

پرامپتی که قراره بمونه

پرامپتی که داخل محصول اجرا می‌شه، با پرامپتی که توی چت می‌نویسی فرق داره. اون یکی باید نسخه‌بندی بشه، تست داشته باشه، و وقتی عوضش می‌کنی بدونی چی شکست.

• پرامپت‌ها رو توی گیت نگه دار، نه داخل متغیر وسط کد.
• برای هر پرامپت یه مجموعه ورودی نمونه با خروجی مورد انتظار نگه دار.
• ورودی کاربر رو از دستور جدا کن و با جداکننده‌ی روشن علامت بزن، تا متن کاربر نتونه نقش دستور بازی کنه.
• خروجی رو قبل از استفاده اعتبارسنجی کن. اگه JSON خواستی، پارسش کن و اگه نشد، دوباره بخواه.

اگه کار از یه پرامپت فراتر رفت و تبدیل شد به یه روش ثابت با فایل مرجع و مرحله‌های مشخص، احتمالاً وقتشه به‌جای پرامپت، یه Skill بنویسی.