بسیاری از تیم‌ها پرامپتنویسی را مهارتی یک‌باره می‌دانند: پرامپت خوب بنویس، در کد بگذار، برو سراغ کار بعدی. این تصور، پرامپتنویسی را از یک فرآیند مهندسی به حدس‌زدن تقلیل می‌دهد. وقتی معیار کمّی برای ارزیابی خروجی نباشد، تیم در چرخه‌ی «بهتر شدن توهمی» گیر میکند — هر نسخه‌ی جدید «بهتر به‌نظر می‌رسد» ولی هیچ‌کس نمی‌تواند بگوید بهتر از چه، روی چه معیاری، و در چه درصدی از موارد.
مهندسی پرامپت چیست و مرز آن با fine-tuning و RAG کجاست؟#
مهندسی پرامپت (Prompt Engineering) طراحی ورودی متنی مدل زبانی بزرگ (LLM) برای هدایت رفتار آن، بدون تغییر وزن‌های مدل است. مرز عملی آن با fine-tuning و RAG در هزینه و زمان پیاده‌سازی خلاصه میشود: پرامپتنویسی در چند دقیقه قابل تغییر است، fine-tuning هفته‌ها طول می‌کشد، و RAG به زیرساخت بازیابی نیاز دارد.
تعریف عملی مهندسی پرامپت و آنچه نیست#
پرامپتنویسی حرفه‌ای یعنی انتخاب کلمات، ساختاردهی، محدودسازی خروجی و ارائه‌ی مثال‌های مرتبط — همه در سطح ورودی متنی. شما مدل را تغییر نمی‌دهید؛ فقط نحوه‌ی درخواست‌کردن را بهینه می‌کنید. همین.
آنچه پرامپتنویسی نیست: آموزش مدل با دادهی جدید (fine-tuning)، اتصال به پایگاه دانش خارجی (RAG)، یا نوشتن کد برای post-processing خروجی. این‌ها روش‌های متفاوتی‌اند و در پروژه‌های واقعی اغلب ترکیبشان لازم میشود.
OpenAI در راهنمای پرامپتنویسی GPT-4 توصیه میکند برای taskهای پیچیده، مسئله را به گام‌های کوچک‌تر تجزیه کنید به‌جای اینکه همه‌چیز را در یک پرامپت بگذارید. این توصیه، مرز عملی پرامپتنویسی را مشخص میکند: ساختاردهی ورودی، نه جادو کردن با کلمات.
مقایسه‌ی سه‌گانه — پرامپتنویسی در برابر fine-tuning در برابر RAG#
| معیار | مهندسی پرامپت | Fine-tuning | RAG |
|---|---|---|---|
| هزینه | پایین (زمان نوشتن و تست) | بالا (داده + رانینگ GPU) | متوسط (زیرساخت بازیابی) |
| زمان پیاده‌سازی | چند دقیقه تا چند ساعت | چند هفته | چند روز تا چند هفته |
| انعطاف‌پذیری | هر لحظه قابل تغییر | نیاز به رانینگ مجدد | وابسته به کیفیت دادهی بازیابی |
| نیاز به داده | مثال‌های کم در پرامپت | دسته‌ی آموزش بزرگ و باکیفیت | پایگاه دانش ساختاریافته |
چه زمانی کدام روش مناسب‌تر است؟#
این سه‌گانه رقابتی نیست؛ مکمل یکدیگرند. اگر مشکل از نحوه‌ی درخواست‌کردن است، پرامپتنویسی کافی است. اگر مدل «نمی‌داند» (دادهی تخصصی ندارد)، RAG لازم است. اگر مدل «نمی‌تواند» (سبک خروجی خاص را یاد نمی‌گیرد)، fine-tuning جواب می‌دهد.
اشتباه پرهزینه‌تر از آن است که به‌نظر می‌رسد: تیم‌هایی که ابتدا سراغ fine-tuning می‌روند و بعد کشف می‌کنند مشکل فقط از ساختار پرامپت بوده، هفته‌ها رانینگ GPU را هدر داده‌اند.
مستر پرامپت چیست و چه فرقی با system prompt و user prompt دارد؟#
مستر پرامپت (Master Prompt) یک قرارداد زنده و چندبخشی است که نقش، زمینه، محدودیت، فرمت خروجی و مثال‌ها را یکجا تعریف میکند و در لایه‌ی system prompt قرار می‌گیرد، در حالی که user prompt فقط ورودی متغیر هر درخواست است.
لایه‌بندی پرامپت‌ها: system، user، assistant#
پرامپت سامانه‌ای (System Prompt) قوانین ثابت رفتار مدل را تعیین میکند. پرامپت کاربری (User Prompt) ورودی متغیر هر نوبت گفتگو است. پرامپت دستیار (Assistant Prompt) خروجی‌های قبلی مدل را به‌عنوان زمینه‌ی ادامه‌ی گفتگو برمی‌گرداند.
مستر پرامپت در لایه‌ی system قرار می‌گیرد. اگر آن را در user بگذارید، با هر درخواست جدید پاک میشود و مدل «قوانین» را فراموش میکند. این اشتباه در تیم‌هایی که از UI چت به API مهاجرت می‌کنند، بسیار رایج است.
مستر پرامپت به‌عنوان قرارداد زنده در برابر قالب ثابت#
تفاوت کلیدی: قالب ثابت یعنی یک فایل copy-paste که یکبار نوشته‌اید و فراموشش می‌کنید. قرارداد زنده یعنی سندی که با هر آپدیت مدل، هر تغییر task و هر بازخورد از محیط تولید به‌روزرسانی میشود. اگر مستر پرامپت شما شش ماه است دست‌نخورده مانده، احتمالاً دارد با رفتار مدل فعلی تضاد پیدا میکند.
Anthropic در راهنمای رسمی پرامپتنویسی Claude تأکید میکند که ساختاردهی پرامپت با XML tags یا سرتیترهای واضح، کیفیت خروجی را به‌ویژه در taskهای پیچیده‌ی چندمرحله‌ای بهبود می‌دهد. یعنی مستر پرامپت باید ساختارمند باشد، نه صرفاً طولانی.
اجزای ساختاری یک مستر پرامپت مؤثر#
هر مستر پرامپت مؤثر این اجزا را دارد — نه همه‌شان همیشه، ولی بدون آگاهی از وجودشان نمی‌توانید حذف‌شان کنید:
- نقش (Role): مدل چه کسی است و از چه زاویه‌ای پاسخ می‌دهد
- زمینه (Context): اطلاعات پس‌زمینه‌ای که مدل بدون آن نمی‌فهمد
- محدودیت (Constraints): چه کارهایی نباید بکند، چه فرمتی باید رعایت شود
- فرمت خروجی (Output Format): ساختار دقیق پاسخ مورد انتظار
- مثال (Examples): نمونه‌ی ورودی-خروجی، در صورت نیاز
مراحل عملی ساخت مستر پرامپت: مشاهده، محدودسازی، ارزیابی#
ساخت مستر پرامپت یک فرآیند سه‌مرحله‌ای است: ابتدا رفتار خام مدل را بدون ساختار مشاهده کنید، سپس بر اساس همان رفتار محدودیت و جهت‌دهی اضافه کنید، و در نهایت خروجی را با معیار کمّی ارزیابی و تکرار کنید. حذف هر مرحله، هزینهی بازگشت را چند برابر میکند.
مرحله ۱ — مشاهده‌ی رفتار طبیعی#
قبل از نوشتن هر محدودیتی، 5 تا 10 خروجی خام بگیرید. فقط بپرسید «این کار را بکن» و ببینید مدل خودش چه ساختاری تولید میکند. این مرحله را حذف نکنید.
الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی اسکول: تیم‌هایی که بدون مرحله‌ی مشاهده مستقیماً ساختار می‌نویسند، پس از 3 تا 4 iteration به نقطه‌ی شروع برمی‌گردند چون محدودیت‌هایشان با رفتار ذاتی مدل در تضاد بوده است. مدل ذاتاً آن ساختار را تولید نمی‌کند و شما دارید با جریان آب می‌جنگید.
مرحله ۲ — محدودسازی و ساختاردهی#
حالا بر اساس آنچه دیدید، محدودیت اضافه کنید. اگر مدل ذاتاً لیست می‌دهد ولی شما جدول می‌خواهید، صریح بگویید. اگر مدل ذاتاً توضیح اضافه میکند و شما فقط پاسخ می‌خواهید، محدودیت «بدون توضیح» بگذارید.
نمونه‌ی مستر پرامپت برای خلاصه‌سازی مقاله:
نقش: تو یک ویراستار محتوای فنی هستی.زمینه: مخاطب خروجی، توسعه‌دهنده‌ای است که وقت خواندن متن کامل را ندارد.محدودیت:- حداکثر 120 کلمه- بدون مقدمه‌چینی و جمع‌بندی کلیشه‌ای- اگر عدد یا ادعای خاصی در متن هست، حفظش کنفرمت خروجی:- یک پاراگراف خلاصه- سه bullet point از نکات کلیدیمثال ورودی/خروجی:ورودی: [متن مقاله]خروجی: [خلاصه در فرمت خواسته‌شده]مرحله ۳ — ارزیابی و تکرار#
معیار کمّی تعریف کنید. مثلاً: «از 20 خروجی، چندتای آنها دقیقاً در فرمت خواسته‌شده هستند؟» بدون این عدد، ارزیابی شهودی و ناپایدار است. نسخه‌های مختلف پرامپت را روی همان مجموعه‌ی تست مقایسه کنید.
هر تغییر پرامپت یعنی re-evaluation (ارزیابی مجدد). اگر پرامپت را تغییر دادید و فقط «حس می‌کنید» بهتر شده، احتمالاً نشده است. حس، معیار نیست.
تکنیک‌های پیشرفته پرامپتنویسی کدام‌اند و چه زمانی باید از هرکدام استفاده کرد؟#
تکنیک‌هایی مثل few-shot، chain-of-thought، role prompting و decomposition هرکدام برای نوع خاصی از task مؤثرند. استفاده‌ی کورکورانه از آنها فقط توکن اضافی مصرف میکند و گاهی خروجی را بدتر میکند. انتخاب تکنیک باید از تشخیص نوع task شروع شود، نه از ترند.
Few-shot Examples — چه زمانی و چند نمونه؟#
Few-shot prompting (پرامپتنویسی با چند نمونه) یعنی ارائه‌ی 2 تا 5 مثال ورودی-خروجی در پرامپت. مؤثر است وقتی فرمت خروجی پیچیده یا غیربدیهی است. برای taskهای ساده‌ی ترجمه یا خلاصه‌سازی، معمولاً لازم نیست و فقط هزینهی توکن را بالا می‌برد.
Chain-of-Thought — فقط برای taskهای استدلالی#
Chain-of-Thought (CoT، زنجیره‌ی تفکر) یعنی از مدل بخواهید مرحله‌به‌مرحله فکر کند. پژوهش Wei و همکاران (2022) نشان داد که افزودن عبارت‌های راهنمای تفکر مرحله‌ای به پرامپت، دقت مدل در taskهای استدلالی ریاضی و منطق را به‌طور قابل‌توجهی افزایش می‌دهد.
اما برای extraction (استخراج اطلاعات) یا classification (طبقه‌بندی)، CoT فقط توکن اضافی مصرف میکند و گاهی مدل را گیج میکند. قانون ساده: اگر task «فکر کردن» می‌طلبد، CoT بگذارید. اگر task «پیدا کردن» می‌طلبد، نگذارید.
Role Prompting — نقش‌دهی مؤثر در برابر نقش‌دهی نمایشی#
«تو یک متخصص 20 ساله‌ی با تجربه‌ای» نقش‌دهی نمایشی است و تأثیر کمی دارد. «پاسخ بده طوری که برای کسی نوشته شده که هیچ پیش‌زمینه‌ای ندارد» نقش‌دهی مؤثر است چون رفتار واقعی مدل را تغییر می‌دهد. اولی صفت اضافه میکند، دومی رفتار.
Problem Decomposition — تجزیهی مسئله به گام‌ها#
وقتی task پیچیده است، آن را به چند پرامپت کوچک‌تر تقسیم کنید. هر پرامپت یک گام انجام می‌دهد و خروجی‌اش به پرامپت بعدی می‌رود. این روش قابلdebugتر و قابل‌نگهداری‌تر از یک پرامپت 500 کلمه‌ای است.
Temperature و تنظیمات پارامتریک#
Temperature (دمای مدل) یک پارامتر تنظیم مدل است، نه بخشی از متن پرامپت. مقدار پایین (نزدیک 0) خروجی را قطعی و تکرارپذیر میکند — مناسب taskهای extraction. مقدار بالا خروجی متنوع‌تر تولید میکند — مناسب نوشتن خلاقانه. تنظیم temperature را در پرامپت بنویسید و مدل ممکن است آن را نادیده بگیرد؛ این کار API است، نه پرامپت.
اشتباهات رایج پرامپتنویسی و چرایی شکست آنها#
رایج‌ترین اشتباهات شامل استفاده از کلمات جادویی، طولانی‌کردن بی‌ساختار پرامپت، اعمال یک قالب ثابت برای همهی taskها، و جداسازی پرامپتنویسی از دانش دامنه‌ای است. هرکدام هزینهی متفاوتی دارد: کلمات جادویی فقط وقت تلف می‌کنند، قالب ثابت خروجی را بی‌ارزش میکند، و بی‌دانشی دامنه‌ای پرامپت را به فرمت‌دهی صرف تقلیل می‌دهد.
کلمات جادویی و عبارات سری#
«فرض کن بهترین متخصص جهان هستی» یا «اگر اشتباه کنی گربه‌ای می‌میرد» — این‌ها افسانه‌اند. مدل‌های زبانی بزرگ با کلمات جادویی کار نمی‌کنند. آنچه کار میکند: ساختار شفاف، محدودیت دقیق و مثال مرتبط.
پرامپت 500 کلمه‌ای بی‌ساختار در برابر پرامپت 80 کلمه‌ای ساختارمند#
الگوی مشاهده‌شده در پروژه‌های اعضای کامیونیتی: تیم‌هایی که پرامپت‌های طولانی بدون نقش و محدودیت می‌نویسند، در مقایسه‌ی A/B با پرامپت‌های کوتاه ساختارمند، خروجی ناهمگن‌تر و بازخوانی‌ناپذیرتری گزارش می‌دهند. طول پرامپت به‌خودی‌خود ارزش نیست. ساختار ارزش است.
یک قالب ثابت برای همهی taskها#
قالبی که برای خلاصه‌سازی مقاله کار میکند، برای نوشتن SQL یا تولید تصویر مناسب نیست. ساختار مؤثر task-specific است. اجزای مشترک (نقش، زمینه، محدودیت، فرمت) وجود دارند، ولی ترکیب و اولویت‌بندی‌شان فرق میکند.
بدون دانش دامنه‌ای، بهترین ساختار پرامپت خروجی بی‌ارزش می‌دهد#
پرامپتنویسی بدون فهم task، فقط فرمت‌دهی است. اگر نمی‌دانید خروجی مطلوب چیست، نمی‌توانید محدودیت درست بنویسید. دانش دامنه‌ای پیش‌شرط پرامپتنویسی مؤثر است، نه مکمل آن.
نمونه‌ی مقایسه‌ای — پرامپت غلط و پرامپت صحیح:
❌ غلط:لطفاً یک متن خیلی خوب و حرفه‌ای و جذاب درباره‌یهوش مصنوعی بنویس که همهی مخاطبان دوستش داشته باشند.✅ صحیح:نقش: نویسنده‌ی محتوای فنی برای مخاطب غیرتخصصی.موضوع: سه کاربرد عملی هوش مصنوعی در بازاریابی.محدودیت:- حداکثر 200 کلمه- بدون اصطلاح فنی (اگر لازم بود، در پرانتز توضیح بده)- هر کاربرد = یک پاراگراففرمت خروجی:عنوان + سه پاراگراف مستقلمثال: [نمونه‌ی یک پاراگراف مطلوب]با آپدیت مدل‌ها پرامپت‌های قبلی هنوز کار می‌کنند؟#
Prompt rot (پوسیدگی پرامپت) یک مشکل عملی روزمره است: با هر آپدیت مدل، پرامپت‌هایی که دیروز مؤثر بودند ممکن است خروجی متفاوت بدهند و بدون بازبینی دوره‌ای، کیفیت سیستمهای مبتنی بر پرامپت به‌تدریج افت میکند.
Prompt rot چیست و چرا رخ می‌دهد؟#
مدل‌های زبانی آپدیت می‌شوند. رفتارشان تغییر میکند. پرامپتی که روی نسخه‌ی قبلی «دستور» را درست اجرا می‌کرد، روی نسخه‌ی جدید ممکن است آن را نادیده بگیرد، تفسیر متفاوت کند یا فرمت خروجی را بشکند.
نشانه‌های افت کیفیت پرامپت در محیط تولید#
نشانه‌های عملی: افزایش rate خروجی‌های خارج از فرمت، تغییر لحن پاسخ‌ها، نادیده‌گرفتن محدودیت‌هایی که قبلاً رعایت می‌شدند، و تولید محتوای تکراری یا بی‌ربط در taskهایی که قبلاً تمیز بودند.
استراتژی بازبینی دوره‌ای پرامپت‌ها#
الگوی تکرارشونده در پروژه‌های اعضای کامیونیتی: تیم‌هایی که پرامپت‌هایشان را در محیط production اجرا می‌کنند، پس از آپدیت‌های بزرگ مدل‌ها (مثل انتقال از GPT-4 به GPT-4o یا Claude 3 به Claude 3.5) گزارش می‌دهند که بخش عمده‌ای از پرامپت‌ها نیاز به بازبینی داشته‌اند.
راه‌حل عملی: هر بار که نسخه‌ی مدل عوض میشود، مجموعه‌ی تست پرامپت‌ها را روی نسخه‌ی جدید اجرا کنید. پرامپت‌هایی که fail می‌کنند را اصلاح کنید. این کار را در تقویم تیم قرار دهید، نه بعد از شکایت کاربر.
مدیریت و نسخه‌بندی کتابخانه پرامپت در تیم#
یک تیم برای مدیریت پرامپت‌ها به سه چیز نیاز دارد: قرارداد نام‌گذاری، changelog ساختاریافته، و ابزار نسخه‌بندی. بدون این سه، پرامپت‌ها به انباری از فایل‌های بی‌سر و ته تبدیل می‌شوند که هیچ‌کس نمی‌داند کدام‌شان هنوز معتبر است.
قرارداد نام‌گذاری و ساختار پوشه‌بندی#
فرمت پیشنهادی: [task]_[مدل]_[نسخه]_[تاریخ].md — مثلاً summarize_claude-v3.5_2024-09.md. این فرمت allows grep کردن سریع و ردیابی اینکه کدام نسخه برای کدام مدل تست شده.
Changelog پرامپت — چه چیزی، چرا و چه زمانی تغییر کرد#
الگوی مشاهده‌شده در پروژه‌های اعضای کامیونیتی: تیم‌هایی که changelog پرامپت ندارند، پس از 2 تا 3 ماه نمی‌توانند بگویند کدام نسخه چرا تغییر کرده و این مانع debug کردن افت کیفیت در production میشود.
هر تغییر پرامپت حداقل این سه فیلد را در changelog ثبت کند: چه چیزی تغییر کرد، چرا تغییر کرد (معیار ارزیابی)، و نتیجه‌ی ارزیابی (بهتر شد/بدتر شد/فرقی نکرد).
ابزارها و پلتفرم‌های مدیریت پرامپت#
PromptLayer، LangChain، و Humanloop نمونه‌هایی از ابزارهای مدیریت و نسخه‌بندی پرامپت‌اند. انتخاب ابزار بستگی به اندازه‌ی تیم و حجم پرامپت‌ها دارد. برای تیم‌های کوچک، یک ریپوی Git با ساختار پوشه‌بندی منظم و changelog در README کافی است.
چه زمانی نباید از مهندسی پرامپت استفاده کرد؟#
مهندسی پرامپت برای taskهایی با ground truth روشن و ساختار مشخص ارزش افزوده‌ی کمی دارد. در این موارد باید سراغ fine-tuning، RAG یا کد مستقیم رفت. پرامپتنویسی ابزار همه‌کاره نیست و اصرار بر استفاده از آن در هر شرایطی، هزینهی پنهان تولید میکند.
Taskهای extraction و classification با ساختار ثابت#
نگاه انتقادی بر اساس تجربه‌ی میدانی: در taskهایی که ورودی و خروجی ساختار مشخصی دارند (مثل استخراج فیلدهای ثابت از یک فرم)، یک اسکریپت ساده با regex یا یک تابع classification دقیقتر و ارزانتر از هر پرامپتنویسی است.
زمانی که دادهی آموزش کافی برای fine-tuning دارید#
اگر هزاران نمونه‌ی ورودی-خروجی دارید و task تکراری است، fine-tuning یکبار هزینه دارد و بعد بدون پرامپتنویسی کار میکند. پرامپتنویسی در این حالت overhead اضافی است.
زمانی که دانش‌تان بیرون از context window مدل است#
اگر باید از پایگاه دانش بزرگ و پویا پاسخ بدهید، RAG ابزار درست است. پرامپتنویسی نمی‌تواند اطلاعاتی را که در context window جا نمی‌شوند، جایگزین کند.
ادغام مهندسی پرامپت با workflow design#
در پروژه‌های واقعی، پرامپتنویسی بخشی از یک workflow بزرگ‌تر است: ایجنت‌های هوش مصنوعی (AI Agent)، ابزارها، تصمیم‌گیری شرطی و post-processing. پرامپت به‌تنهایی محصول نیست؛ قطعه‌ای از سیستم است.
جمع‌بندی عملی#
مهندسی پرامپت یک مهارت عملی است، نه یک هنر جادویی. مستر پرامپت از مشاهده‌ی رفتار خام مدل شروع میشود، با محدودسازی شکل می‌گیرد، و با ارزیابی کمّی تکرار میشود. بدون این چرخه، پرامپتنویسی تبدیل به حدس‌زدن میشود.
اگر می‌خواهید این چرخه را در پروژه‌های واقعی تمرین کنید و با تیم‌هایی که روزانه پرامپتنویسی و ساخت ایجنت انجام می‌دهند در ارتباط باشید، دوره‌ی «آموزش جامع Claude و ابزارهای مشابه» در کامیونیتی Claude اسکول دقیقاً همین مسیر را پوشش می‌دهد.
محتوای این دوره در صفحه‌ی کامیونیتی Claude در دسترس است.
دیدگاهها
برای گذاشتن دیدگاه وارد شو
دیدگاهها فقط از حسابهای کاربری پذیرفته می‌شوند.
ورود / ثبتنامهنوز دیدگاهی ثبت نشده — اولین نفر باش.