زنجیره تفکر در پرامپت‌نویسی: Chain of Thought با نمونه و پرامپت فارسی

زنجیره تفکر (Chain of Thought یا CoT) یعنی از مدل هوش مصنوعی بخواهید پیش از پاسخ نهایی، مسئله را مرحله‌به‌مرحله استدلال کند؛ یا با یک جمله ساده مثل «قدم‌به‌قدم فکر کن»، یا با آوردن نمونه‌ای که استدلال کامل در آن نوشته شده است. این روش در مسئله‌های چندمرحله‌ای مثل حساب، تصمیم‌گیری و اشکال‌یابی خطا را کم می‌کند، اما برای کارهای ساده لازم نیست و پاسخ را کندتر و طولانی‌تر می‌کند.

این راهنما یک بررسی عمیق از خود زنجیره تفکر و خانواده آن است: CoT بدون نمونه و با نمونه، خودسازگاری (Self-Consistency)، پرسش یک‌قدم‌عقب‌تر (Step-Back)، حل از ساده به دشوار (Least-to-Most) و درخت افکار (Tree of Thoughts). سپس می‌بینید با مدل‌هایی که خودشان پیش از پاسخ فکر می‌کنند چه چیزی عوض می‌شود، CoT کجا ضرر دارد و چطور استدلال را از پاسخ نهایی جدا کنید. نمونه‌ها آموزشی و نوشته خود ما هستند، نه گزارش آزمایش روی یک مدل خاص؛ هر پرامپت را روی ابزار و داده خودتان امتحان کنید.

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

زنجیره تفکر روشی است که در آن مدل به‌جای پریدن مستقیم به جواب، گام‌های میانی استدلال را می‌نویسد و جواب را از دل همان گام‌ها بیرون می‌کشد. اصطلاح Chain-of-Thought Prompting در مقاله‌های پژوهشی سال ۲۰۲۲ نام‌گذاری شد و از آن زمان به یکی از پایه‌ای‌ترین تکنیک‌های مهندسی پرامپت تبدیل شده است.

تفاوت را با یک مثال ساده ببینید. اگر بپرسید «قیمت کالایی ۸۰۰ هزار تومانی بعد از ۲۵ درصد تخفیف و ۱۰ درصد مالیات چقدر است؟»، پاسخ سریع ممکن است درصدها را با هم جمع و تفریق کند و بگوید ۱۵ درصد کمتر، یعنی ۶۸۰ هزار تومان. اما اگر مدل گام‌به‌گام برود، اول تخفیف را حساب می‌کند (۶۰۰ هزار تومان) و بعد مالیات را روی همین عدد (۶۶۰ هزار تومان). جواب درست دوم است و گام‌های نوشته‌شده به شما اجازه می‌دهند ببینید کجا محاسبه درست یا غلط شده است.

دو نکته را از همین ابتدا جدا کنید:

• زنجیره تفکر با زنجیره پرامپت فرق دارد. در زنجیره پرامپت (Prompt Chaining) کار را بین چند پرامپت جداگانه تقسیم می‌کنید و خروجی هر کدام ورودی بعدی است؛ این روش در راهنمای مهندسی پرامپت توضیح داده شده است. در زنجیره تفکر، همه استدلال داخل یک پاسخ اتفاق می‌افتد.
• CoT با «تقسیم کار به مراحل» هم یکی نیست. وقتی شما مراحل را تعیین می‌کنید، نقشه را خودتان داده‌اید. در CoT از مدل می‌خواهید خودش مسیر استدلال را بسازد و بنویسد. این دو را می‌شود با هم ترکیب کرد.

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

مدل زبانی متن را کلمه‌به‌کلمه تولید می‌کند و هر کلمه بر اساس متن قبلی ساخته می‌شود؛ وقتی گام‌های میانی نوشته شوند، هر گام زمینه‌ای برای گام بعد می‌شود و مدل مجبور نیست کل محاسبه را در یک جهش انجام دهد. به زبان ساده، نوشتن استدلال مثل چرک‌نویس برای مدل عمل می‌کند.

این توضیح سه پیامد عملی دارد:

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

تفاوت CoT بدون نمونه (Zero-shot) و با نمونه (Few-shot) چیست؟

در CoT بدون نمونه فقط یک دستور کلی برای استدلال مرحله‌ای اضافه می‌کنید؛ در CoT با نمونه، یک یا چند مسئله حل‌شده می‌آورید که استدلال کامل در آن‌ها نوشته شده تا مدل هم شکل و هم عمق استدلال را تقلید کند. منطق کلی نمونه‌دادن را در راهنمای few-shot و zero-shot مفصل بخوانید؛ اینجا فقط کاربرد آن برای استدلال را می‌بینیم.

CoT بدون نمونه

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

[مسئله یا سؤال]

پیش از پاسخ، مسئله را قدم‌به‌قدم حل کن:
۱. داده‌های مسئله و چیزی را که خواسته شده فهرست کن.
۲. هر محاسبه یا استنتاج را در یک خط جدا بنویس.
۳. در پایان، جواب را با داده‌های مسئله دوباره بسنج.
سپس در یک خط جدا بنویس: «پاسخ نهایی: …»

چه انتظاری داشته باشید: یک فهرست گام‌به‌گام و یک خط پاسخ نهایی. پیش از استفاده، اعداد هر گام را خودتان چک کنید؛ مدل‌ها در محاسبه‌های طولانی هنوز خطا می‌کنند.

CoT با نمونه

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

مسئله‌های قیمت‌گذاری را مثل نمونه حل کن.

مسئله نمونه: کالایی ۵۰۰ هزار تومان است. ۲۰ درصد تخفیف دارد و هزینه ارسال ۴۰ هزار تومان به قیمت نهایی اضافه می‌شود. مشتری چقدر می‌پردازد؟
استدلال:
- قیمت پایه: ۵۰۰ هزار تومان
- تخفیف: ۲۰ درصد از ۵۰۰ = ۱۰۰ ← قیمت پس از تخفیف ۴۰۰
- ارسال روی قیمت پس از تخفیف اضافه می‌شود: ۴۰۰ + ۴۰ = ۴۴۰
- بررسی: تخفیف فقط روی کالا اعمال شد، نه روی ارسال ✔
پاسخ نهایی: ۴۴۰ هزار تومان

مسئله جدید: [مسئله]
استدلال:

در CoT با نمونه، خطای رایج این است که نمونه خودش اشتباه داشته باشد. مدل خطای نمونه را هم با دقت تقلید می‌کند؛ پس نمونه را دو بار حساب کنید.

چطور استدلال را از پاسخ نهایی جدا کنیم؟

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

سؤال: [سؤال]

پاسخ را دقیقاً در این دو بخش بنویس:
<تحلیل>
استدلال گام‌به‌گام، فرض‌ها و محاسبه‌ها. این بخش به کاربر نشان داده نمی‌شود.
</تحلیل>
<پاسخ>
فقط پاسخ نهایی برای کاربر، حداکثر [تعداد] جمله، بدون اشاره به بخش تحلیل.
</پاسخ>

برای استفاده در برنامه، برچسب‌های انگلیسی ساده‌ترند، چون جداکردن آن‌ها با کد راحت‌تر است:

Think through the problem step by step inside <reasoning> tags.
Then give only the final answer, in Persian, inside <answer> tags.
Do not mention the reasoning inside <answer>.

Question: [question]

چند قاعده برای این کار:

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

خودسازگاری (Self-Consistency) چیست و کی به کار می‌آید؟

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

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

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

محدودیت مهم: وقتی هر سه راه در یک پاسخ نوشته شوند، کاملاً مستقل نیستند؛ راه دوم ممکن است تحت تأثیر راه اول باشد. برای کارهای مهم، اجرای جداگانه بهتر است. هزینه و زمان هم چند برابر می‌شود، پس خودسازگاری را برای جواب‌هایی نگه دارید که یک خطا گران تمام می‌شود.

پرسش یک‌قدم‌عقب‌تر (Step-Back Prompting) چیست؟

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

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

پیش از پاسخ به سؤال اصلی، یک قدم عقب برو:
۱. سؤال کلی‌تری که پشت این مسئله است را بنویس.
۲. اصول یا معیارهای اصلی برای پاسخ به آن سؤال کلی را در حداکثر ۵ مورد فهرست کن.
۳. حالا سؤال اصلی را فقط با تکیه بر همین اصول پاسخ بده و بگو هر بخش پاسخ به کدام اصل برمی‌گردد.
سؤال اصلی: [سؤال]
اطلاعات: [متن یا داده]

این روش زمانی بیشترین کمک را می‌کند که سؤال شما «مورد خاص یک قاعده کلی» باشد: ارزیابی متن، تشخیص علت یک مشکل، یا پرسش‌های مفهومی درسی. برای مسئله‌های حسابی ساده معمولاً لازم نیست.

حل از ساده به دشوار (Least-to-Most) چطور کار می‌کند؟

در روش Least-to-Most مسئله دشوار را اول به چند زیرمسئله کوچک‌تر می‌شکنید و آن‌ها را از ساده‌ترین تا دشوارترین به ترتیب حل می‌کنید، طوری که جواب هر زیرمسئله در حل بعدی استفاده شود. تفاوتش با CoT معمولی این است که مرحله «شکستن مسئله» صریح و جداست.

مسئله: [مسئله پیچیده]

مرحله ۱ - شکستن: این مسئله را به زیرمسئله‌هایی تقسیم کن که هرکدام به‌تنهایی قابل حل باشند. آن‌ها را از ساده به دشوار مرتب کن. هنوز حل نکن.
مرحله ۲ - حل: زیرمسئله‌ها را به ترتیب حل کن. در حل هر زیرمسئله، از جواب‌های قبلی صریحاً نام ببر.
مرحله ۳ - جمع‌بندی: جواب مسئله اصلی را از جواب زیرمسئله‌ها بساز.
اگر برای حل یکی از زیرمسئله‌ها اطلاعات کافی نیست، همان‌جا توقف کن و بگو چه اطلاعاتی لازم است.

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

درخت افکار (Tree of Thoughts) چیست و کی زیادی است؟

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

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

اگر می‌خواهید ایده آن را بدون کدنویسی امتحان کنید، این نسخه ساده‌شده در یک پیام کار می‌کند:

برای این مسئله سه رویکرد کاملاً متفاوت پیشنهاد کن و هرکدام را در دو جمله توضیح بده.
برای هر رویکرد، از ۱ تا ۵ امتیاز بده بر اساس: [معیار ۱]، [معیار ۲]، [معیار ۳] و دلیل هر امتیاز را بنویس.
دو رویکرد ضعیف‌تر را کنار بگذار و رویکرد برتر را تا سه گام جلوتر توسعه بده.
اگر در این گام‌ها به بن‌بست رسیدی، برگرد و رویکرد دوم را امتحان کن.
مسئله: [مسئله]

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

با مدل‌های استدلالی که خودشان فکر می‌کنند، پرامپت چه تغییری می‌کند؟

برخی مدل‌ها و حالت‌ها در ChatGPT، Claude و Gemini پیش از پاسخ، به‌صورت داخلی استدلال می‌کنند؛ با این مدل‌ها دیگر لازم نیست بنویسید «قدم‌به‌قدم فکر کن» و بهتر است به‌جای دیکته کردن مسیر استدلال، هدف، محدودیت‌ها و معیار موفقیت را دقیق بدهید. نام این حالت‌ها و شیوه فعال‌کردنشان در هر ابزار متفاوت است و مرتب تغییر می‌کند؛ گزینه‌های فعلی ابزار خود را بررسی کنید.

چند تفاوت عملی:

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

هدف: [چه می‌خواهم به دست بیاورم]
زمینه: [اطلاعات، داده، محدودیت‌های واقعی]
معیار پاسخ خوب: [مثلاً هزینه کمتر از X، قابل اجرا با تیم دو نفره، بدون نیاز به ابزار پولی]
آنچه نمی‌دانم یا مطمئن نیستم: [موارد]

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

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

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

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

۱. مسئله حسابی کلامی

مریم سه بسته دفتر ۱۲ تایی خرید. ۸ دفتر به برادرش داد و نصف باقی‌مانده را برای بچه‌های کلاس برد. چند دفتر برای خودش ماند؟

قدم‌به‌قدم حل کن، هر محاسبه را در یک خط بنویس و در پایان جواب را با صورت مسئله چک کن.
پاسخ نهایی را در خط آخر با عبارت «پاسخ نهایی:» بنویس.

استدلال مورد انتظار: کل دفترها ۳ × ۱۲ = ۳۶؛ بعد از دادن به برادر ۳۶ − ۸ = ۲۸؛ نصف ۲۸ یعنی ۱۴ برای کلاس؛ پس ۱۴ دفتر می‌ماند. بررسی: ۸ + ۱۴ + ۱۴ = ۳۶ ✔. اگر مدل در خط اول ۳ را با ۱۲ جمع کرده باشد، خطا را در همان خط می‌بینید؛ همین قابلیت ردیابی، ارزش اصلی CoT در مسئله‌های حسابی است.

۲. تصمیم کسب‌وکاری

من یک فروشگاه اینترنتی کوچک لوازم تحریر دارم و باید بین دو تأمین‌کننده یکی را انتخاب کنم.
تأمین‌کننده الف: [قیمت، زمان تحویل، حداقل سفارش، شرایط مرجوعی]
تأمین‌کننده ب: [قیمت، زمان تحویل، حداقل سفارش، شرایط مرجوعی]
محدودیت‌های من: نقدینگی ماهانه [مبلغ]، فضای انبار [مقدار]، فروش ماهانه حدود [تعداد].

پیش از توصیه:
۱. معیارهای تصمیم را با توجه به محدودیت‌های من وزن‌دهی کن و دلیل هر وزن را بگو.
۲. هر تأمین‌کننده را روی هر معیار بسنج و فقط از اطلاعات بالا استفاده کن.
۳. سناریوی بد را بررسی کن: اگر فروش نصف شود یا یک محموله دیر برسد، کدام گزینه آسیب کمتری دارد؟
۴. اطلاعاتی را که کم است و می‌تواند تصمیم را عوض کند فهرست کن.
در پایان، توصیه را در دو جمله بنویس.

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

۳. اشکال‌یابی کد

در اشکال‌یابی، CoT یعنی مدل پیش از پیشنهاد اصلاح، رفتار کد را با یک ورودی مشخص خط‌به‌خط دنبال کند.

این تابع باید میانگین نمره‌های بالای ۱۰ را برگرداند، اما برای ورودی [12, 8, 15] به‌جای 13.5 عدد 9 برمی‌گرداند.

[کد]

پیش از پیشنهاد اصلاح:
۱. اجرای تابع را با همین ورودی خط‌به‌خط دنبال کن و مقدار متغیرها را بعد از هر خط بنویس.
۲. اولین خطی را که مقدارش با انتظار فرق دارد مشخص کن.
۳. علت را در یک جمله بگو.
بعد کد اصلاح‌شده را بنویس و آن را با همان ورودی و یک ورودی خالی [] دوباره دنبال کن.

یک کد نمونه که این مشکل را دارد:

def avg_passing(scores):
    passing = [s for s in scores if s > 10]
    return sum(passing) / len(scores)

استدلال مورد انتظار: فهرست passing برابر [12, 15] است و جمع آن ۲۷؛ اما تقسیم بر طول کل فهرست (۳) انجام شده و ۹ به دست آمده. اصلاح: تقسیم بر len(passing). دنبال‌کردن ورودی خالی هم نشان می‌دهد تقسیم بر صفر رخ می‌دهد و باید حالت فهرست خالی جدا مدیریت شود. پرامپت‌های بیشتر برای کد را در راهنمای پرامپت برنامه‌نویسی ببینید.

۴. تحلیل متن فارسی

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

نظر مشتری: «دستتون درد نکنه، فقط دو هفته منتظر موندم تا یه جعبه خالی تحویل بگیرم. واقعاً عالی!»

پیش از تعیین احساس این نظر:
۱. عبارت‌هایی را که ظاهر مثبت دارند و عبارت‌هایی را که واقعیت تجربه را می‌گویند جدا کن.
۲. بررسی کن آیا عبارت مثبت با واقعیت گفته‌شده جور است یا طعنه است.
۳. مشکل اصلی مشتری را در یک عبارت کوتاه بنویس.
خروجی نهایی در یک خط: احساس [مثبت/منفی/خنثی] | مشکل اصلی | آیا پیگیری فوری لازم است [بله/خیر]

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

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

CoT برای کارهای ساده، کارهای پرتکرار با حجم بالا و جاهایی که کاربر نهایی پاسخ را مستقیم می‌بیند معمولاً لازم نیست یا حتی آسیب می‌زند. پیش از افزودن «قدم‌به‌قدم فکر کن» به هر پرامپت، این موارد را در نظر بگیرید:

• کارهای ساده و یک‌مرحله‌ای: ترجمه یک جمله، تصحیح املای یک بند، یا پاسخ به سؤال مستقیم. استدلال در این‌ها فقط متن اضافه می‌سازد و گاهی مدل در توضیح‌دادن چیز ساده، آن را بی‌دلیل پیچیده می‌کند.
• زمان پاسخ و هزینه: هر خط استدلال زمان و توکن مصرف می‌کند. در چت‌بات پشتیبانی یا ابزاری که هزاران متن را دسته‌بندی می‌کند، این هزینه جمع می‌شود. برای چنین کارهایی، نمونه‌دادن بدون استدلال معمولاً گزینه بهتری است.
• نشان‌دادن استدلال به کاربر نهایی: مشتری‌ای که سؤال ساده‌ای پرسیده نمی‌خواهد چهار بند تحلیل بخواند. بدتر اینکه استدلال ممکن است قواعد داخلی، فرض‌های نادرست یا اطلاعاتی را فاش کند که نباید دیده شود. استدلال را جدا کنید و فقط پاسخ را نشان دهید.
• کارهای خلاقانه: شعر، شعار یا ایده‌پردازی آزاد با استدلال مرحله‌ای اغلب خشک و قابل پیش‌بینی می‌شود. اگر می‌خواهید بسنجید، ایده‌ها را اول آزاد بگیرید و بعد در پیام جداگانه با معیار ارزیابی کنید.
• اعتماد کاذب: استدلال مرتب و منطقی‌نما خواننده را قانع می‌کند، حتی وقتی یک گام آن غلط است. اگر استدلال را نمی‌خوانید و چک نمی‌کنید، بخشی از فایده CoT را از دست داده‌اید.
• مدل‌های استدلالی: همان‌طور که گفته شد، دستور «قدم‌به‌قدم فکر کن» برای این مدل‌ها تکراری است.

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

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

پرامپت‌های آماده بیشتر برای استدلال مرحله‌ای

این پرامپت‌ها را برای موقعیت‌هایی که در بخش‌های قبل نیامد آماده کرده‌ایم. جای کروشه‌ها را با اطلاعات خودتان پر کنید.

بررسی استدلال یک پاسخ قبلی

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

تحلیل علت ریشه‌ای یک مشکل

مشکل: [مثلاً فروش ماه گذشته ۳۰ درصد کم شده]
داده‌هایی که دارم: [داده‌ها]

علت‌های احتمالی را گام‌به‌گام بررسی کن:
۱. همه علت‌های ممکن را فهرست کن.
۲. برای هر علت بنویس کدام داده موجود آن را تأیید یا رد می‌کند.
۳. علت‌هایی را که داده‌ای برایشان نداریم جدا کن و بگو با چه داده‌ای می‌شود آزمودشان.
۴. در پایان، محتمل‌ترین علت‌ها را به ترتیب بنویس و میزان اطمینانت را با «کم، متوسط، زیاد» مشخص کن.

استدلال برای سؤال درسی با هدف یادگیری

من دانش‌آموز پایه [پایه] هستم و این سؤال را دارم: [سؤال]
جواب را یک‌جا نده. فقط گام اول را توضیح بده و از من بخواه گام بعد را حدس بزنم.
اگر جوابم غلط بود، اشتباهم را بدون گفتن جواب کامل نشان بده.

این نوع پرامپت برای معلم‌ها هم کاربرد دارد؛ نمونه‌های بیشتر در راهنمای پرامپت طرح درس و تدریس آمده است.

تصمیم بله یا خیر با سنجش موافق و مخالف

تصمیم: [مثلاً اضافه‌کردن ارسال رایگان برای سفارش‌های بالای X]
اطلاعات: [حاشیه سود، میانگین سبد خرید، هزینه ارسال]

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

پرامپت انگلیسی برای استفاده در برنامه

You will receive a customer message in Persian.
First, inside <analysis> tags, identify: the customer's main request, any secondary request, the emotional tone, and whether an order number is present.
Then, inside <label> tags, output exactly one of: refund, delivery, product_question, complaint, other.
Output nothing outside these two tags.

Message: [message]

اگر زنجیره تفکر جواب نداد، چه کنیم؟

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

• استدلال درست، جواب نهایی غلط: مدل در خط آخر عدد را اشتباه نقل کرده. بخواهید پاسخ نهایی «عیناً از آخرین گام» برداشته شود.
• استدلال از فرض غلط شروع می‌شود: فرض‌ها را جدا بخواهید («ابتدا فرض‌هایت را فهرست کن») و پیش از ادامه آن‌ها را اصلاح کنید.
• استدلال خیلی طولانی و تکراری است: سقف بگذارید: «حداکثر ۶ گام کوتاه».
• جواب اول نوشته شده و بعد دلیل: ترتیب را صریح بنویسید یا از برچسب‌های جدا استفاده کنید.
• هر بار جواب متفاوت است: نشانه این است که مسئله مبهم است یا داده کم است. ابهام را برطرف کنید یا خودسازگاری را به کار ببرید.
• مدل حساب بزرگ را اشتباه می‌کند: برای محاسبه دقیق از ماشین‌حساب، صفحه‌گسترده یا ابزار اجرای کد که برخی دستیارها دارند کمک بگیرید و از مدل فقط ساختن فرمول را بخواهید.

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

راهنماهای مرتبط

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