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

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

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

تحقیقات Wei et al. (2022) نشان داد که فعال‌سازی این روش می‌تواند دقت مدل‌ها را در مسائلی که نیاز به گام واسط دارند، به‌طور قابل‌توجهی افزایش دهد. در این رویکرد، مدل پیش از ارائه پاسخ نهایی، استدلال خود را کتبی می‌کند. این کار باعث می‌شود الگوریتم فضای جستجو را محدود کرده و تمرکز خود را بر مسیر صحیح حفظ کند.

برای فعال‌سازی این حالت، کافیست دستورالعملی شبیه به نمونه زیر به مدل بدهید:

لطفاً مرحله به مرحله فکر کنید و سپس پاسخ دهید: 25 + 18 = ?

از تجربه عملی خود می‌گویم؛ غیرفعال‌سازی این روش در وظایف توالی‌محض (مانند طبقه‌بندی سریع متن)، سرعت پردازش را بدون افت کیفیت بهبود می‌بخشد. بسیاری از تیم‌ها اشتباهاً آن را برای همه درخواست‌ها فعال نگه می‌دارند که نتیجه‌ای جز اتلاف منابع نیست.

اولین باری که این پارادایم را روی یک مدل کوچک آزمایش کردم، انتظار داشتم معجزه رخ دهد. اما نتایج وحشتناک بود. مدل شروع کرد به توضیح دادن اینکه چرا ۲۵ به اضافه ۱۸ برابر است با... و بعد هم گیج شد. فهمیدم که اینجا «پیچیدگی» مساوی با «دقت» نیست.

تفاوت عملکرد Few-shot و Zero-shot Chain of Thought کدام است؟#

تفاوت عملکرد Few-shot و Zero-shot Chain of Thought در نحوه ارائه نمونه‌ها و تأثیر آن بر ثبات خروجی و هزینه محاسباتی است. در حالی که هر دو دقت را بالا می‌برند، تعداد توکن‌های ورودی در روش اول بسیار بیشتر است.

ویژگی Zero-shot CoT Few-shot CoT
تعداد توکن ورودی کم (فقط سوال) زیاد (سوال + مثال‌ها)
هزینه هر درخواست اقتصادی گران‌تر
پایداری خروجی متوسط بالا
شرایط استفاده بهینه مسائل عمومی قالب‌های خاص و پیچیده

بررسی‌های میدانی نشان می‌دهد که اگر پرامپت مناسب نباشد، اهمیت انتخاب بین این دو روش بر اساس ثبات خروجی و هزینه محاسباتی پررنگ می‌شود. Few-shot معمولاً پایدارتر است زیرا ساختار مورد انتظار را به مدل دیکته می‌کند، اما بار مالی سنگین‌تری دارد.

تفاوت ظریف در این است که در روش Zero-shot تنها یک عبارت کلیدی مثل "قدم به قدم" ارسال می‌شود، در حالی که در Few-shot باید چندین نمونه حل‌شده دقیقاً با فرمت دلخواه تزریق شود. تصمیم من همیشه بر اساس حجم داده‌های ورودی است: اگر فضا محدود است، از Zero-shot خالص استفاده می‌کنم.

Question: What is the number of hours from 3 PM to 6 PM?
Answer: 3

راستش این روش دیگر جواب نمی‌دهد. وقتی مدل شما هنوز یاد نگرفته چطور استنتاج کند، دادن ده تا مثال فقط او را گیج‌تر می‌کند. من بارها دیده‌ام که تیم‌ها ساعت‌ها وقتشان را صرف طراحی مثال‌های Few-shot می‌کنند، در حالی که یک Prompt ساده‌تر همان کار را با یک‌دهم هزینه انجام می‌داد.

چه زمانی استفاده از این تکنیک اشتباه است و کیفیت را کاهش می‌دهد؟#

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

یکی از Anti-patternهای رایج، ادعای «کلید جادویی» بودن این روش است. وقتی مدل را مجبور به فکر کردن برای پرسشی ساده مثل «رنگ آسمان چیست» کنید، فقط زمان پاسخ‌دهی را طولانی می‌کنید. تجربه نشان می‌دهد که نوشتن عبارت آماده‌ی کلیشه‌ای بدون دیباگینگ ساختاری، هیچ سودی ندارد.

  1. وظایف بصری ساده که نیاز به تحلیل ندارند.
  2. خلاصه‌سازی متون عمومی (اجبار به تفکر باعث حذف نکات کلیدی می‌شود).
  3. سوالات مستقیم اطلاعاتی (Factoid questions).

تنظیم دمای مدل (Temperature) نقش حیاتی دارد. برای استدلال منطقی، دما را نزدیک به صفر نگه دارید تا از انحراف الگوریتمی جلوگیری شود. برای جزئیات بیشتر در این زمینه، مهندسی پرامپت فارسی را مطالعه کنید.

ببین، مشکل اصلی سرعت است. نه، دقیق‌تر بگویم: مشکل اصلی نبودِ فرایند است. وقتی برای پرسش‌های ساده از CoT استفاده می‌کنید، عملاً دارید پول بیشتری می‌پردازید تا دیرتر جواب بگیرید. این یعنی اتلاف محض. ما در یکی از پروژه‌ها حتی توانستیم با غیرفعال کردن CoT برای ۷۰ درصد درخواست‌های ساده، هزینه ماهانه را ۳۰ درصد کاهش دهیم.

چگونه می‌توان از «استدلال توهمی» مدل جلوگیری کرد؟#

جلوگیری از «استدلال توهمی» با استفاده از Contrastive Prompting و بررسی مستقل گام‌های منطقی امکان‌پذیر است. وقتی فرمول‌بندی قانع‌کننده است اما داده‌ها غلط هستند، احتمال توهم بالاست.

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

Prompting مقایسه‌ای (Contrastive Prompting) روشی است که در آن از مدل خواسته می‌شود دو مسیر منطقی موازی را تولید کند. یکی درست و دیگری نادرست. سپس مدل باید آن را غربالگری کند. این کار پدیده «استدلال غلطِ قانع‌کننده» را آشکار می‌سازد.

Path A: [استدلال منطقی]
Path B: [استدلال دارای خطای منطقی]
کدام مسیر صحیح است و چرا؟

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

مشکل اینجاست که مدل‌ها استادِ حرف زدن هستند، نه حقیقت گفتن. یک استدلال زیبا می‌تواند کاملاً غلط باشد. من اخیراً شاهد بودم که یک مدل با اعتمادبه‌نفس کامل، یک دلیل علمی غلط برای یک پدیده فیزیکی می‌آورد. Contrastive prompting به ما اجازه داد آن لایه‌ی فریب را کنار بزنیم و واقعیت را ببینیم.

هزینه محاسباتی و تأخیر پاسخ هنگام پیاده‌سازی آن چقدر است؟#

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

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

  • حذف توضیحات غیرضروری از پرامپت.
  • محدود کردن عمق زنجیره به حداکثر پنج گام.
  • استفاده از مدل‌های سریع‌تر برای گام‌های ساده.

بسیاری از کاربران تمایز واضح بین تعداد توکن‌های ورودی و خروجی را نادیده می‌گیرند. توجه داشته باشید که توکن‌های خروجی در مدل‌های فعلی اغلب گران‌تر محاسبه می‌شوند. برای یادگیری اصول اسکول، دوره‌های اسکول (eskul.ir) پیشنهاد می‌شود.

غیرقابل‌چشم‌پوشی است که بدانید هر گام اضافه، یعنی هزینه مضاعف. ما یک بار یک سیستم پشتیبانی مشتری داشتیم که با CoT کار می‌کرد. پاسخ‌دهی از ۲ ثانیه به ۱۵ ثانیه رسید. مشتری‌ها راضی نبودند و هزینه سرور منفجر شد. راه‌حل؟ فقط گام‌های بحرانی را با CoT اجرا کن. بقیه را سریع و ارزان پردازش کن.

جمع‌بندی#

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

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