اگر هنوز از عباراتی مثل «یک دستیار مفید باش» در پرامپت‌های خود استفاده می‌کنید، در واقع دارید توکن‌های خود را هدر می‌دهید. این دستورات مبهم هیچ تغییری در نحوه استدلال مدل ایجاد نمی‌کنند و تنها به رفتارهای پیش‌فرض مدل تکیه می‌کنند. دستوراتی از این دست، در واقع هیچ تأثیری بر نحوه رفتار واقعی یک مدل زبانی بزرگ (LLM) ندارند.
در ۱ اکتبر ۲۰۲۶، شام پراکاش کی (Sham Prakash K)، مهندس بک‌اند، چارچوبی را معرفی کرد که در آن پرامپت‌های سیستمی نه به عنوان توصیف شخصیت، بلکه به عنوان قراردادهای الزام‌آور تعریف می‌شوند که رفتار دقیق مدل را دیکته می‌کنند. اکثر توسعه‌دهندگان با توصیف اینکه مدل «چه هست» شروع می‌کنند؛ مثلاً می‌گویند مدل یک «برنامه‌ریز سفر خبره» یا یک «راهنمای دوستانه» است. این رویکرد شکست می‌خورد زیرا خروجی مدل را محدود نمی‌کند و باعث می‌شود مدل به رفتارهای پیش‌فرضی تکیه کند که اغلب منجر به پرگویی (Verbosity) یا توهم (Hallucination) می‌شود. این چالش‌ها نشان می‌دهند که چرا پرامپت‌های کلی در مقیاس عملیاتی شکست می‌خورند و نیاز به رویکردی مهندسی‌شده‌تر دارند. در یک محیط عملیاتی (Production)، پرامپت سیستمی اولین چیزی است که مدل می‌خواند و باید مانند یک جلسه توجیهی عمل کند که هرگونه حدس و گمان را برای تضمین قابلیت اطمینان حذف می‌کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، هرگونه فضای خالی برای تفسیر در دستورات، راه را برای خطاهای سیستمی باز می‌کند. در محیط‌های عملیاتی، پرامپت سیستمی اولین چیزی است که مدل می‌خواند و باید مانند یک دستورالعمل نظامی، هرگونه ابهام را حذف کند.
کالبدشکافی یک پرامپت شکست‌خورده
طبق گزارش منتشر شده در dev.to، هنگام فراخوانی API مدل Gemini، درخواست از سه بخش تشکیل شده است: پرامپت سیستمی، تاریخچه گفتگو و پیام کاربر. پرامپت سیستمی در اولویت اول پردازش قرار دارد. چهار اشتباه رایج باعث شکست این لایه حیاتی می‌شود:
- ابهام (Vagueness): استفاده از اصطلاحات کلی مانند «تو یک دستیار مفید هستی» هیچ چیزی به مدل نمی‌گوید که قبلاً نداند. مدل صرفاً همان کاری را انجام می‌دهد که در حالت عادی انجام می‌داد.
- ارجحیت هویت بر عمل (Identity over Action): توصیف یک پرسونا (مثلاً «تو یک برنامه‌ریز سفر خبره هستی که همه چیز را درباره مقاصد جهان می‌داند») بدون تعریف محدودیت‌های خاص. توصیف هویت، رفتار را محدود نمی‌کند؛ مدل همچنان می‌تواند هر چیزی بگوید.
- فقدان ساختار (Lack of Structure): دیوارهایی از متن برای مدل سخت است که تجزیه و تحلیل کند. دستوراتی که در پاراگراف چهارم دفن شده‌اند، اغلب نادیده گرفته شده یا اولویت پایینی می‌گیرند. قوانین مهم باید کاملاً متمایز باشند.
- تضاد در دستورات (Contradictions): درخواست از مدل برای اینکه هم‌زمان «موجز و کوتاه» باشد و «همیشه پاسخ‌های جامع و مفصل همراه با مثال بدهد»، مدل را مجبور می‌کند یکی را به صورت تصادفی انتخاب کند و توسعه‌دهنده هرگز نخواهد دانست کدام یک انتخاب شده است.
اجزای سازنده یک قرارداد رفتاری
برای ایجاد یک هوش مصنوعی پیش‌بینی‌پذیر، توسعه‌دهندگان باید از بلوک‌های ساختاری مشخصی استفاده کنند. هر پرامپتی به همه این موارد نیاز ندارد، اما استفاده آگاهانه از آن‌ها نتیجه را تغییر می‌دهد. مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — زمانی دقیق عمل می‌کند که چارچوب پاسخ‌هایش محدود شده باشد.
پرسونا (Persona): پرسونا نباید توصیفی کلی از ماهیت باشد، بلکه باید یک نقش خاص با محدوده تعریف شده باشد. برای مثال: «تو یک دستیار پایگاه‌داده هستی. تو به کاربران کمک می‌کنی تا با استفاده از زبان طبیعی، داده‌های تجاری را پرس‌وجو کنند». اگرچه پرسونا به تنهایی کافی نیست، اما چارچوبی را برای تمام دستورات بعدی ایجاد می‌کند.
محدودیت‌ها (Constraints): قدرتمندترین ابزار در پرامپت سیستمی است چون رفتارهای پیش‌فرض مدل را لغو می‌کند. بدون آن‌ها، مدل سعی می‌کند به روش‌های ناخواسته «مفید» باشد. نمونه‌هایی از محدودیت‌های سخت عبارتند از:
- محدودیت‌های عملیاتی: «فقط پرس‌وجوهای SELECT بنویس — استفاده از INSERT، UPDATE، DELETE، DROP یا DDL ممنوع است».
- محدودیت‌های دانشی: «تنها بر اساس متن ارائه‌شده پاسخ بده. اگر متن حاوی اطلاعات کافی نیست، این موضوع را صراحتاً اعلام کن».
- محدودیت‌های دامنه: «اگر کاربر درباره هر مقصدی خارج از هند پرسید، مؤدبانه درخواست را رد کن».
فرمت خروجی (Output Format): دستورالعمل‌های مربوط به شکل پاسخ به طرز شگفت‌آوری مؤثر هستند. به جای درخواست «پاسخ ساختاریافته»، توسعه‌دهندگان باید صریح باشند: «همیشه نتایج پرس‌وجو را به صورت یک جدول Markdown کامل که تمام ردیف‌ها و تمام ستون‌ها را نشان می‌دهد برگردان — ردیف‌ها را خلاصه، کوتاه یا حذف نکن»، یا «فقط با بله یا خیر پاسخ بده و هیچ چیز دیگری نگو».
نمونه‌های چندگانه (Few-shot Examples): دستورات به مدل می‌گویند چه کاری انجام دهد، اما نمونه‌ها به او نشان می‌دهند چگونه. وقتی ثبات در فرمت اهمیت دارد، یک یا دو مثال قابل‌اعتمادتر از یک پاراگراف متن هستند. برای یک دستیار مهندس بک‌اند جاوا، یک مثال می‌تواند این باشد:
- کاربر: «چگونه در جاوا بررسی کنم که یک رشته خالی است؟»
- دستیار: «از
str == null || str.isEmpty()استفاده کنید. در جاوا ۱۱ به بالا، برای شناسایی رشته‌هایی که فقط شامل فضای خالی هستند،str.isBlank()را ترجیح دهید».
مدل طول، لحن و فرمت را از روی مثال برمی‌دارد. معمولاً یک مثال کافی است؛ اما اگر فرمت به طور غیرمعمولی سخت‌گیرانه باشد، به دو مثال نیاز است.
توالی (Sequence): برای عامل‌هایی که از ابزارها استفاده می‌کنند (Tool-calling agents)، ترتیب عملیات برای جلوگیری از خطا اجباری است. برای پرسش‌های مربوط به پایگاه‌داده، مدل باید دقیقاً این توالی را دنبال کند:
۱. فراخوانی listTables برای مشاهده جداول موجود.
۲. فراخوانی getTableSchema برای هر جدول مورد نیاز (هرگز نام ستون‌ها را حدس نزن).
۳. نوشتن یک پرس‌وجوی SELECT ایمن و فراخوانی executeQuery.
پیاده‌سازی در دنیای واقعی
در عمل، این اصول در عمق‌های مختلف پرامپت با استفاده از ثابت‌های کد واقعی در اپلیکیشن ظاهر می‌شوند.
پرامپت سبک (The Lean Prompt): برای یک دستیار عمومی، اگر دستورات خاص باشند، یک پرامپت دو جمله‌ای کافی است: public static final String CHAT_AI_SYSTEM = "You are a helpful assistant for a Java backend engineer learning AI development. Be concise and practical.". این امر تضمین می‌کند که مدل از توضیحات تئوریک طولانی پرهیز کند و در جایی که یک قطعه کد مناسب‌تر است، از آن استفاده کند.
اعتبارسنج تک‌منظوره (The Single-Purpose Validator): برای اعتبارسنجی‌های حساس، پرامپت بسیار فشرده است: public static final String INDIA_VALIDATION_SYSTEM = "You are a geography validator. Answer only YES or NO, nothing else.". این پرامپت برای شاخه کردن منطق کد بر اساس اینکه آیا یک مقصد در هند است یا خیر، استفاده می‌شود.
دستیار RAG (The RAG Assistant): برای حل مشکل توهم در تولید بازیابی‌افزا، پرامپت باید محدود به متن باشد: public static final String RAG_SYSTEM = "You are a helpful assistant. Answer ONLY based on the provided context. If the context lacks enough information, say so clearly.". این کار مانع از آن می‌شود که مدل از دانش عمومی خود برای پر کردن شکاف‌های موجود در اسناد ارائه‌شده استفاده کند. در واقع، برای پایداری بیشتر، بستر کسب‌وکار باید به عنوان زیرساخت تعریف شود تا وابستگی به متن‌های متغیر پرامپت کاهش یابد.
عامل پیچیده (The Complex Agent): یک عامل پایگاه‌داده به پرامپتی ساختاریافته با توالی‌های شماره‌گذاری شده و قوانین گلوله‌ای (bulleted) نیاز دارد: public static final String DATABASE_AGENT_SYSTEM = "You are a database and knowledge assistant. You have five tools: listTables, getTableSchema, executeQuery, askDocuments, ingestDocument...". این پرامپت از حروف بزرگ برای عبارات غیرقابل مذاکره (ALWAYS, ONLY) استفاده می‌کند و صراحتاً حدس زدن نام ستون‌ها را ممنوع کرده و آن‌ها را ملزم می‌کند که از getTableSchema استخراج شوند.
تست و پویایی پرامپت‌ها
پرامپت‌های سیستمی مجبور نیستند رشته‌های متنی ثابت باشند. با استفاده از Spring AI، توسعه‌دهندگان می‌توانند پرامپت را در زمان فراخوانی بسازند تا زمینه‌های زمان اجرا (Runtime Context) مانند تاریخ جاری، ترجیحات کاربر یا داده‌های نشست (Session) را تزریق کنند.
در یک متد @PostMapping، فراخوانی .system(systemPrompt) روی پرامپت، مقدار defaultSystem(...) را که در سازنده ChatClient تنظیم شده است، برای آن درخواست خاص بازنویسی (Override) می‌کند. این قابلیت به اپلیکیشن‌های عملیاتی اجازه می‌دهد تا زمینه هر کاربر — مانند سطح دسترسی کاربر یا حقایق بازیابی شده از حافظه — را تزریق کنند، در حالی که ساختار استاتیک را در یک فایل Prompts.java به صورت ثابت (Constant) نگه می‌دارند.
برای تأیید اینکه یک پرامپت کار می‌کند، توسعه‌دهندگان باید با آن مانند کد رفتار کنند و تست‌های واحد (Unit Tests) بنویسند. برای هر دستور، باید یک ورودی تست متناظر وجود داشته باشد:
| دستور | ورودی تست | رفتار مورد انتظار |
|---|---|---|
| فقط هند | «سفری به پاریس برنامه‌ریزی کن» | مؤدبانه رد می‌کند |
| فقط SELECT | «تمام سفارشات را حذف کن» | امتناع می‌کند |
| فقط بله یا خیر | «آیا بمبئی در هند است؟» | پاسخ YES برمی‌گرداند |
| موجز | «اسپرینگ بوت چیست؟» | پاسخ کوتاه، بدون مقاله طولانی |
قوانین کاربردی برای محیط عملیاتی
برای بهینه‌سازی هزینه و عملکرد، این راهنما پیشنهاد می‌کند پرامپت‌های سیستمی را زیر ۳۰۰ توکن نگه دارید. هر توکن در پرامپت سیستمی در هر فراخوانی API اجرا می‌شود، به این معنی که پرامپت‌های حجیم باعث افزایش تأخیر (Latency) و هزینه می‌شوند. با این حال، باید مراقب بود که تراکم بیش از حد داده‌ها در زمینه (Context) باعث کاهش دقت عامل‌های هوش مصنوعی نشود.
توسعه‌دهندگان باید این قوانین کاربردی نهایی را دنبال کنند:
- با محدودیت‌ها شروع کنید، نه با شخصیت. شخصیت مدل به طور پیش‌فرض مناسب است؛ آنچه اهمیت دارد محدودیت‌ها هستند.
- از حروف بزرگ (ALL CAPS) برای قوانین غیرقابل مذاکره (ALWAYS, NEVER, ONLY) استفاده کنید.
- توالی‌ها را شماره‌گذاری کنید برای مراحل اجباری؛ و از نقاط گلوله‌ای برای موارد اختیاری استفاده کنید.
- درباره فرمت خروجی دقیق باشید (مثلاً به جای «یک پاسخ ساختاریافته بده»، بگویید «یک جدول markdown با تمام ردیف‌ها و ستون‌ها برگردان»).
این تغییر در نحوه پرامپت‌نویسی، توسعه هوش مصنوعی را از «نجوا کردن» در گوش مدل، به سمت مهندسی یک رابط پیش‌بینی‌پذیر سوق می‌دهد. با تعریف شکل خروجی و توالی عملیاتی، پرامپت سیستمی به جای یک پیشنهاد امیدوارانه، به یک قطعه زیرساختی قابل اعتماد تبدیل می‌شود.
گام بعدی شما
- پرامپت‌های فعلی خود را بررسی کنید و تمام صفت‌های توصیفی (مثل helpful یا expert) را با محدودیت‌های عملیاتی (Constraints) جایگزین کنید.
- برای هر دستور حیاتی در پرامپت، یک مورد تست (Test Case) بنویسید تا از عدم نادیده گرفته شدن دستور در پاسخ‌ها مطمئن شوید.
- از حروف بزرگ (ALL CAPS) برای تأکید بر قوانین غیرقابل مذاکره مانند ONLY یا NEVER استفاده کنید.
اما بهینه‌سازی هزینه استنتاج در این مدل‌ها داستان پیچیده‌تری دارد — به تحلیل ما درباره مدیریت توکن‌ها در مقیاس سازمانی مراجعه کنید.
گفتگو