پرامپت سیستمی چیست و چه نقشی در رفتار مدل زبانی دارد؟
پرامپت سیستمی چارچوب رفتاری و مرزهای مدل زبانی را تعیین می‌کند؛ لایه‌ای که پیش از هر تعامل کاربر، ساختار پاسخ را شکل می‌دهد.
پرامپت سیستمی (System Prompt) لایه‌ای است که پیش از هر تعامل، هویت، مرزهای رفتاری و چارچوب پاسخ مدل زبانی را تعیین می‌کند. این لایه، پایه‌ای‌ترین سطح کنترل در یک سیستم مبتنی بر LLM است و کیفیت آن، تعیین‌کننده تجربه کاربری در تمام نوبت‌های بعدی خواهد بود.
آنچه در ادامه می‌خوانید، حاصل تجربه روی پروژه‌های مختلفی است که در آن‌ها پرامپت سیستمی، نقطه‌ی اصلی تمایز بین یک چت‌بات معمولی و یک دستیار تخصصی بوده است. تمرکز روی این است که چرا این لایه این‌قدر مهم است، چه چیزی باید در آن باشد و چه چیزی نباید، و چه الگوهایی برای طراحی آن وجود دارد.
خلاصه آنچه پیش رو دارید
در این نوشتار ابتدا تعریف دقیق پرامپت سیستمی و نقش آن در رفتار مدل ارائه می‌شود. سپس ساختار یک پرامپت سیستمی مؤثر و اجزای اصلی آن بررسی می‌گردد. تفاوت آن با پرامپت کاربر، ملاحظات امنیتی، و الگوهای طراحی، بخش‌های بعدی را تشکیل می‌دهند. در انتها، اشتباهات رایج، شاخص‌های سنجش اثربخشی و نگاه معمارانه به این لایه جمع‌بندی می‌شود.
پرامپت سیستمی چیست؟
پرامپت سیستمی اولین پیام در یک نشست است که با نقش system به مدل ارسال می‌شود. این پیام، برخلاف پرامپت کاربر، در طول نشست ثابت می‌ماند و رفتار مدل را در تمام نوبت‌های بعدی شکل می‌دهد. در بیشتر APIهای مدل‌های زبانی مدرن، این نقش به‌صورت رسمی پشتیبانی می‌شود و مدل‌ها طوری آموزش دیده‌اند که به آن توجه ویژه‌ای داشته باشند.
اهمیت این لایه در آن است که مدل را از یک "پاسخ‌دهنده عمومی" به یک "دستیار تخصصی" تبدیل می‌کند. اگر بخواهید مدل مثل یک وکیل حقوقی رفتار کند، پرامپت سیستمی همان جایی است که این هویت را تعریف می‌کنید. برای درک عمیق‌تر ساختار پرامپت در پرامپت نویسی، پیشنهاد می‌کنم نوشتار ساختار یک پرامپت مؤثر را مطالعه کنید.
نقش پرامپت سیستمی در رفتار مدل
پرامپت سیستمی به‌طور مستقیم روی چهار بُعد رفتار مدل اثر می‌گذارد:
۱. تعیین هویت و نقش
اینکه مدل خودش را چه کسی می‌داند، در پاسخ‌های آن اثر می‌گذارد. مدلی که خود را "دستیار پشتیبانی فروشگاه" می‌داند، پاسخ‌هایی متفاوت از مدلی می‌دهد که خود را "دستیار عمومی" می‌شناسد. این تعریف هویت، معمولاً در پرامپت سیستمی انجام می‌شود.
۲. تعیین لحن و سبک
آیا لحن پاسخ باید رسمی باشد یا خودمانی؟ کوتاه باشد یا مفصل؟ این تصمیم‌ها نیز در پرامپت سیستمی تعریف می‌شوند. تفاوت یک دستیار برند لوکس با یک دستیار فروشگاه تخفیفی، در همین لایه شکل می‌گیرد.
۳. تعیین مرزها
مدل باید بداند در چه زمینه‌هایی وارد نمی‌شود، چه درخواست‌هایی را رد می‌کند، و چه اطلاعاتی را افشا نمی‌کند. این مرزها به‌طور صریح در پرامپت سیستمی تعریف می‌شوند. برای مطالعه دقیق‌تر، نوشتار ملاحظات اخلاقی در پرامپت نویسی را ببینید.
۴. تعیین فرمت پاسخ
آیا پاسخ‌ها باید در قالب Markdown باشند؟ JSON؟ متن ساده؟ این تصمیم در پرامپت سیستمی گرفته می‌شود و به‌طور قابل توجهی بر قابلیت پردازش خودکار پاسخ‌ها اثر می‌گذارد.
در تجربه‌های واقعی، پرامپت سیستمی که به‌درستی طراحی شده باشد، می‌تواند به‌تنهایی رفتار مدل را از یک چت‌بات عمومی به یک دستیار تخصصی تبدیل کند، بدون آنکه به تغییر مدل یا تنظیم دقیق نیاز باشد.
ساختار یک پرامپت سیستمی مؤثر
یک پرامپت سیستمی مؤثر معمولاً از چند بخش تشکیل می‌شود که هر یک وظیفه مشخصی دارند:
| بخش | وظیفه | مثال |
|---|---|---|
| هویت | تعریف نقش مدل | شما یک دستیار پشتیبانی هستید |
| دامنه | مشخص کردن حوزه تخصص | فقط در مورد محصولات فروشگاه |
| لحن | تعیین سبک پاسخ | رسمی، مختصر، بدون شوخی |
| مرزها | تعریف آنچه نباید انجام شود | افشای قیمت‌های داخلی ممنوع |
| فرمت | تعریف ساختار خروجی | پاسخ در قالب پاراگراف کوتاه |
| مثال | نمونه پاسخ مطلوب | مثال‌های few-shot |
نکته‌ی مهم این است که این بخش‌ها باید به‌صورت مرتب و بدون ابهام کنار هم قرار بگیرند. اگر مرزهای بین بخش‌ها شفاف نباشد، مدل ممکن است بخشی از دامنه را نادیده بگیرد یا از مرزها عبور کند.
اجزای اصلی پرامپت سیستمی
در تجربه‌های عملی، پرامپت سیستمی موفق از اجزای زیر ساخته می‌شود:
توصیف نقش
یک جمله‌ی صریح که نقش مدل را تعریف می‌کند. این جمله باید مستقیم باشد و از کلی‌گویی پرهیز کند. "شما یک دستیار مفید هستید" بسیار ضعیف‌تر از "شما یک متخصص پشتیبانی فنی در زمینه وردپرس هستید" عمل می‌کند.
زمینه تخصصی
هر تخصص، زمینه‌ای دارد. اگر مدل قرار است درباره‌ی محصولات خاصی صحبت کند، این اطلاعات باید در پرامپت سیستمی تزریق شود. برای مطالعه دقیق‌تر درباره این تزریق، نوشتار نقش زمینه و بافت در پرامپت نویسی را ببینید.
دستورالعمل‌های رفتاری
مجموعه‌ای از قواعد که نحوه پاسخ‌دهی را مشخص می‌کند. این قواعد باید قابل اجرا و قابل سنجش باشند. "خوب پاسخ بده" یک قاعده نیست؛ "پاسخ‌ها حداکثر ۳ پاراگراف باشند" یک قاعده است.
نمونه‌های راهنما
نمونه‌های کوچکی از پاسخ مطلوب که به مدل کمک می‌کنند قالب موردنظر را درک کند. این تکنیک که با نام few-shot prompting شناخته می‌شود، در نوشتار تفاوت پرامپت صفر-نمونه و چند-نمونه به تفصیل بررسی شده است.
مدیریت خطا
تعیین اینکه مدل در صورت ندانستن پاسخ یا مواجهه با درخواست خارج از دامنه، چه رفتاری داشته باشد. این بخش در سیستم‌های تولیدی حیاتی است، چرا که نبود آن به تولید پاسخ‌های ساختگی منجر می‌شود.
پرامپت سیستمی، قانون اساسی یک نشست است. اگر این قانون مبهم یا متناقض باشد، هیچ نوبت بعدی نمی‌تواند آن را جبران کند.
تفاوت پرامپت سیستمی با پرامپت کاربر
پرامپت سیستمی و پرامپت کاربر دو لایه‌ی متفاوت از کنترل هستند که شاید در نگاه اول مشابه به‌نظر برسند، اما نقش‌های کاملاً متفاوتی دارند:
| بُعد | پرامپت سیستمی | پرامپت کاربر |
|---|---|---|
| ثبات | در کل نشست ثابت | در هر نوبت تغییر می‌کند |
| منبع | تعریف‌شده توسط توسعه‌دهنده | تعریف‌شده توسط کاربر |
| هدف | شکل‌دهی به رفتار کلی | ارائه‌ی درخواست مشخص |
| اولویت | بالاتر در سلسله‌مراتب دستورها | پایین‌تر در سلسله‌مراتب |
این تفکیک، پایه‌ی بسیاری از تصمیم‌های طراحی است. اگر دستورالعمل‌های پایه را به پرامپت کاربر منتقل کنید، مدل ممکن است در نوبت‌های بعدی آن‌ها را در سایه‌ی درخواست‌های جدید نادیده بگیرد. برای مطالعه دقیق‌تر درباره پرامپت کاربر، نوشتار پرامپت کاربر و نحوه نوشتن آن را ببینید.
پرامپت سیستمی فراتر از دستورالعمل ساده
در نگاه اول، پرامپت سیستمی ممکن است مثل مجموعه‌ای از دستورالعمل‌های ساده به‌نظر برسد. اما در سیستم‌های بالغ، این لایه کارکردهای بسیار بیشتری دارد:
مدیریت چندنقشی
یک پرامپت سیستمی می‌تواند مدل را در حالت‌های مختلف قرار دهد. مثلاً در یک سیستم پشتیبانی، مدل ابتدا در نقش "تشخیص مسئله" عمل می‌کند و بعد در نقش "ارائه راه‌حل". این تغییر نقش‌ها معمولاً با دستورالعمل‌های شرطی در پرامپت سیستمی مدیریت می‌شوند.
تزریق دانش
اطلاعات ثابتی که مدل در طول نشست به آن‌ها نیاز دارد — مثل اطلاعات محصولات، سیاست‌های شرکت، یا راهنمای پاسخ‌دهی — می‌توانند در پرامپت سیستمی قرار گیرند. این تکنیک در کنار سیستم‌های RAG مکمل خوبی است، هرچند نباید جایگزین آن شود. برای مطالعه دقیق‌تر، نوشتار پرامپت نویسی برای RAG را ببینید.
کنترل فرمت خروجی
در سیستم‌هایی که پاسخ مدل باید توسط کد پردازش شود، پرامپت سیستمی می‌تواند فرمت دقیق خروجی را تعیین کند. این کنترل فرمت، در نوشتار درخواست خروجی JSON از مدل به تفصیل بررسی شده است.
مدیریت زبان و لحن برند
برای برندها، پرامپت سیستمی جایی است که صدای برند به مدل منتقل می‌شود. تصمیم‌هایی مثل "همیشه از ضمیر شما استفاده کن" یا "از اصطلاحات تخصصی پرهیز کن" در همین لایه اعمال می‌شوند.
ملاحظات امنیتی پرامپت سیستمی
از منظر امنیتی، پرامپت سیستمی هم هدف و هم ابزار است:
نشت پرامپت سیستمی
کاربران می‌توانند با درخواست‌های ماهرانه، مدل را وادار به افشای پرامپت سیستمی کنند. اگر پرامپت سیستمی شامل اطلاعات محرمانه باشد، این نشت می‌تواند مشکل‌ساز شود. برای درک این تهدید، نوشتار نشت پرامپت و خطرات آن را ببینید.
تزریق پرامپت
مهاجم می‌تواند با تزریق دستورهای مخرب در ورودی کاربر، مدل را از دستورهای سیستمی منحرف کند. دفاع در برابر این تهدید، نیازمند طراحی دقیق پرامپت سیستمی و استفاده از تکنیک‌های دفاعی است. برای مطالعه دقیق‌تر، نوشتار دفاع در برابر تزریق پرامپت را ببینید.
جیلبریک
تلاش‌های هدفمند برای عبور از مرزهای تعریف‌شده در پرامپت سیستمی. دفاع در برابر جیلبریک، ترکیبی از طراحی پرامپت، فیلتر ورودی، و ارزیابی مستمر است. برای مطالعه بیشتر، نوشتار جیلبریک پرامپت و جلوگیری از آن را ببینید.
الگوهای طراحی پرامپت سیستمی
در تجربه‌های واقعی، چند الگوی طراحی به‌طور مکرر اثربخش بوده‌اند:
الگوی شخصیت واحد
در این الگو، مدل یک شخصیت مشخص دارد و در طول نشست همان شخصیت را حفظ می‌کند. این الگو برای دستیارهای تخصصی مناسب است.
الگوی نقش‌های چندگانه با سوئیچ
مدل ابتدا در نقش "تحلیلگر" پاسخ می‌دهد و سپس با یک سوئیچ صریح، به نقش "ارائه‌دهنده راه‌حل" منتقل می‌شود. این الگو در سیستم‌های پیچیده‌ی تصمیم‌گیری مفید است.
الگوی محدودسازی دامنه
در این الگو، پرامپت سیستمی صریحاً اعلام می‌کند که مدل فقط در زمینه‌ای مشخص پاسخ می‌دهد و درخواست‌های خارج از دامنه را رد می‌کند. این الگو برای دستیارهای پشتیبانی مناسب است.
الگوی چندلایه
پرامپت سیستمی به چند بلوک تقسیم می‌شود که هر یک وظیفه‌ای دارد. این الگو در سیستم‌های پیچیده، قابلیت نگهداری را بالا می‌برد.
اشتباهات رایج در نوشتن پرامپت سیستمی
- نوشتن پرامپت سیستمی در قالب یک پاراگراف بلند بدون ساختار
- قرار دادن دستورالعمل‌های پایه در پرامپت کاربر به‌جای پرامپت سیستمی
- نبود مدیریت خطا و رفتار در مواجهه با درخواست‌های خارج از دامنه
- نادیده گرفتن ملاحظات امنیتی و افشای اطلاعات محرمانه
- استفاده از دستورالعمل‌های متناقض که مدل را گیج می‌کند
- طولانی‌کردن بی‌دلیل پرامپت سیستمی بدون افزودن ارزش
- نداشتن نسخه‌بندی و تاریخچه تغییرات پرامپت سیستمی
- عدم تست پرامپت سیستمی در سناریوهای مختلف
- نادیده گرفتن تفاوت زبان فارسی در طراحی پرامپت سیستمی
- نبود هماهنگی بین پرامپت سیستمی و سیستم بازیابی (RAG)
سنجش اثربخشی پرامپت سیستمی
برای سنجش اینکه پرامپت سیستمی تا چه اندازه مؤثر است، چند شاخص کلیدی وجود دارد:
| شاخص | توضیح |
|---|---|
| Consistency Score | انسجام پاسخ‌ها با نقش تعریف‌شده |
| Scope Adherence | درصد پاسخ‌های در دامنه |
| Jailbreak Resistance | مقاومت در برابر تلاش‌های عبور از مرز |
| Response Quality | کیفیت پاسخ‌ها بر اساس معیارهای تعریف‌شده |
| Token Efficiency | نسبت کیفیت به تعداد توکن مصرفی |
پایش دوره‌ای این شاخص‌ها، اجازه می‌دهد قبل از این که کاربران نارضایتی نشان دهند، انحراف را تشخیص دهید. مخصوصاً در سیستم‌های پشتیبانی و فروش، کیفیت پرامپت سیستمی به‌طور مستقیم بر نتیجه اقتصادی اثر می‌گذارد.
برای مطالعه دقیق‌تر در مورد شاخص‌های ارزیابی پرامپت، نوشتار معیارهای ارزیابی پرامپت را ببینید.
پرسش‌های پرتکرار درباره پرامپت سیستمی
پرامپت سیستمی چیست؟
پرامپت سیستمی اولین پیام در یک نشست است که با نقش system به مدل ارسال می‌شود. این پیام هویت، مرزها، لحن و چارچوب پاسخ مدل را تعریف می‌کند و در کل نشست ثابت می‌ماند.
چطور پرامپت سیستمی بنویسیم؟
یک پرامپت سیستمی مؤثر معمولاً از بخش‌های هویت، دامنه، لحن، مرزها و فرمت تشکیل می‌شود. هر بخش باید صریح، قابل اجرا و قابل سنجش باشد.
آیا پرامپت سیستمی می‌تواند نشت کند؟
بله، کاربران می‌توانند با درخواست‌های ماهرانه مدل را وادار به افشای پرامپت سیستمی کنند. به همین دلیل نباید اطلاعات محرمانه را در این لایه قرار دهید.
تفاوت پرامپت سیستمی و پرامپت کاربر چیست؟
پرامپت سیستمی توسط توسعه‌دهنده تعریف می‌شود و در کل نشست ثابت است، در حالی که پرامپت کاربر توسط کاربر ارسال می‌شود و در هر نوبت تغییر می‌کند.
آیا پرامپت سیستمی روی هزینه اثر می‌گذارد؟
بله، هر توکن در پرامپت سیستمی، در هر نوبت هزینه ایجاد می‌کند. اگر پنجره زمینه پشتیبانی از کش داشته باشد، بخش‌های ثابت پرامپت سیستمی می‌توانند کش شوند و هزینه را کاهش دهند. برای مطالعه دقیق‌تر، نوشتار بهینه‌سازی هزینه در پرامپت نویسی را ببینید.
نگاه معمارانه به پرامپت سیستمی
از منظر معمار سیستم، پرامپت سیستمی یک لایه‌ی پیکربندی است که رفتار کلی سیستم را در سطح تعامل تعریف می‌کند. این لایه، نقطه‌ی تلاقی چند دغدغه است: کیفیت پاسخ، امنیت، هزینه و قابلیت نگهداری.
در سیستم‌های بالغ، پرامپت سیستمی به‌عنوان یک artifact جداگانه نگهداری می‌شود، با نسخه‌بندی مشخص، تست‌های خودکار، و فرآیند تغییر تعریف‌شده. این موضوع در نوشتار نسخه‌بندی پرامپت به تفصیل بررسی شده است.
نکته‌ی مهم دیگر این است که پرامپت سیستمی باید با معماری حافظه و پنجره زمینه هماهنگ باشد. اگر پرامپت سیستمی طولانی باشد، بخش قابل توجهی از بودجه توکن را می‌گیرد و فضای کمتری برای سایر اجزا باقی می‌ماند. برای مطالعه دقیق‌تر در این زمینه، نوشتار مدیریت پنجره زمینه در پرامپت نویسی را ببینید.
در معماری‌های پیشرفته، معمولاً پرامپت سیستمی به چند بلوک تقسیم می‌شود که هر یک می‌تواند مستقل کش شود. این تفکیک، هم هزینه را کاهش می‌دهد و هم امکان آزمایش A/B روی بخش‌های مختلف را فراهم می‌کند. برای مطالعه دقیق‌تر در مورد آزمایش، نوشتار آزمون A/B پرامپت‌ها را ببینید.
آخرین نکته‌ای که در طراحی سیستم‌های بزرگ بارها با آن روبه‌رو شده‌ام: پرامپت سیستمی یک سند زنده است. اگر آن را یک بار بنویسید و فراموش کنید، به‌تدریج از واقعیت کسب‌وکار فاصله می‌گیرد. باید بازبینی دوره‌ای داشته باشید و از داده‌های واقعی کاربران برای بهبود آن استفاده کنید. این چرخه‌ی بازخورد، تفاوت بین یک پرامپت سیستمی معمولی و یک پرامپت سیستمی حرفه‌ای است.
تجربه شما
اگر در پروژه‌ای واقعی روی طراحی پرامپت سیستمی کار کرده‌اید، برای من جالب است بدانید کدام بخش آن بیشترین اثر را روی کیفیت پاسخ داشته و کجا با چالش مواجه شده‌اید. اگر رویکرد متفاوتی برای ساختاردهی این لایه دارید، تجربه‌تان را در دیدگاه‌ها بنویسید تا خواننده بعدی از آن استفاده کند.
نویسنده در وردپرس کار.