پرامپت‌نویسی برای مدل‌های استدلالی؛ چرا با هوش مصنوعی متفکر باید کمتر حرف بزنی

تا همین دیروز، هرچه بیشتر برای هوش مصنوعی توضیح می‌دادی، جواب بهتری می‌گرفتی؛ «قدم‌به‌قدم فکر کن»، چند مثال حل‌شده و یک دنیا جزئیات. اما نسل تازه‌ای از مدل‌ها آمده‌اند که این قاعده را وارونه می‌کنند: مدل‌های استدلالی مثل خانوادهٔ o در OpenAI، حالت تفکر گستردهٔ Claude و نسخه‌های متفکر Gemini. با این مدل‌ها هرچه کمتر و شفاف‌تر حرف بزنی، جواب دقیق‌تری می‌گیری. در این درس یاد می‌گیری چرا این‌طور است و پرامپت‌نویسی برای مدل‌های استدلالی را چطور باید انجام بدهی.

مدل استدلالی چیست و چه فرقی با مدل معمولی دارد؟

مدل استدلالی مدلی است که پیش از تولید جواب نهایی، درون خودش یک زنجیرهٔ فکر طولانی می‌سازد، مسیرها را می‌سنجد و بعد پاسخ می‌دهد. این «فکر کردن» بخشی از خود مدل است و لازم نیست تو آن را روشن کنی. در مقابل، یک مدل معمولی (مثل مدل‌های سریع و ارزان‌تر) بلافاصله شروع به نوشتن می‌کند و اگر بخواهی استدلال کند، باید خودت با تکنیک‌هایی مثل زنجیرهٔ تفکر او را وادار کنی.

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

چرا زنجیرهٔ فکر برای مدل استدلالی جواب نمی‌دهد؟

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

همین منطق دربارهٔ مثال‌های زیاد (few-shot) هم صادق است. مثال برای مدل معمولی مثل ریل راهنماست، اما برای مدل استدلالی مثل حصار است؛ خلاقیت و انعطافش را محدود می‌کند. کارِ تو دیگر «نشان‌دادن راهِ حل» نیست، بلکه «روشن‌کردن مقصد» است.

چهار قاعدهٔ طلایی برای پرامپت‌دادن به مدل‌های متفکر

این چهار قاعده جانِ کلام این درس است؛ اگر فقط همین‌ها را رعایت کنی، تفاوت را در همان اولین جواب می‌بینی.

1. هدف را بگو، نه مسیر را. به‌جای «اول این کار را بکن، بعد آن کار»، فقط نتیجهٔ نهایی و معیار موفقیت را روشن کن و بگذار مدل خودش راه را پیدا کند.
2. مثال‌ها را کم کن. اگر واقعاً به مثال نیاز داری، یک نمونهٔ کوتاه کافی است؛ نه ده تا. اغلب اصلاً بی‌مثال بهتر جواب می‌گیری.
3. محدودیت‌ها و زمینه را کامل بده. کم‌حرفی به معنای پنهان‌کردن اطلاعات نیست. مخاطب، محدودیت‌ها، داده‌های ورودی و قالب خروجی را شفاف بنویس؛ فقط از دستوردادن به «نحوهٔ فکرکردن» پرهیز کن.
4. به مدل فرصت بده. جواب اول را نهایی نبین؛ اگر لازم است بگو «قبل از پاسخ نهایی، فرض‌هایت را بررسی کن». این با تحمیل زنجیرهٔ فکر فرق دارد — تو مقصدِ بازبینی را می‌دهی، نه مسیرش را.

نمونهٔ عملی؛ یک پرامپت بد و بازنویسی درست آن

فرض کن می‌خواهی برای یک محصول نرم‌افزاری، استراتژی قیمت‌گذاری بگیری. ببین همان درخواست در دو حالت چطور نوشته می‌شود.

پرامپت بد (به سبک مدل‌های قدیمی): «تو یک متخصص قیمت‌گذاری هستی. قدم‌به‌قدم فکر کن. اول بازار را تحلیل کن، بعد رقبا را لیست کن، بعد سه مدل قیمت را با مثال توضیح بده. مثلاً برای اسپاتیفای این‌طور بود…، برای نتفلیکس این‌طور… حالا برای محصول من هم همین کار را بکن.»

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

پرامپت خوب (به سبک مدل‌های استدلالی): «یک استراتژی قیمت‌گذاری برای این محصول پیشنهاد بده. محصول: ابزار مدیریت پروژه برای تیم‌های کوچک ایرانی. هزینهٔ ما ماهی X، مخاطب استارتاپ‌های زیر ۱۰ نفر، رقبای اصلی A و B. خروجی: دو تا سه گزینهٔ قیمت با منطق هرکدام و ریسک‌هایش. معیار موفقیت: قابل‌دفاع بودن جلوی سرمایه‌گذار.»

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

کجا از مدل استدلالی استفاده کنیم و کجا نه؟

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

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

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

اشتباهات رایج و راه‌حلشان

این جدول کوتاه، خطاهایی را که بیشتر کاربران هنگام کار با مدل‌های متفکر مرتکب می‌شوند کنار راه‌حلشان می‌گذارد.

پرسش‌های پرتکرار

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

چطور بفهمم مدلی که استفاده می‌کنم استدلالی است؟ معمولاً در نامش نشانه‌ای هست (مثل خانوادهٔ o یا حالت‌های «thinking» و «reasoning» و «تفکر گسترده») و هنگام پاسخ، کمی مکث می‌کند تا فکر کند. اگر بلافاصله و لحظه‌ای جواب می‌دهد، احتمالاً مدل معمولی است.

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

آیا می‌توانم به مدل استدلالی بگویم استدلالش را نشانم بدهد؟ می‌توانی خلاصه‌ای از منطقِ جواب را بخواهی، اما این با «دیکته‌کردن مسیر فکر» فرق دارد. اولی خروجی است، دومی تحمیلِ فرایند.

جمع‌بندی

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

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

نسخهٔ فوری این مطلب در تلگرام: اینجا بخوانید