پرامپت تجزیه به زیرمسئله؛ مسئلهٔ بزرگ را خرد کن

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

۱) تجزیه به زیرمسئله چیست

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

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

نکتهٔ کلیدی در ترتیب است. زیرمسئله‌ها بی‌ربط به هم نیستند؛ جواب زیرمسئلهٔ اول ورودی زیرمسئلهٔ دوم می‌شود. به همین دلیل مرتب‌کردن از ساده به دشوار صرفاً یک نظم ظاهری نیست، بلکه شرط کارکرد تکنیک است.

۲) پشتوانهٔ پژوهشی

این تکنیک ریشه در مقالهٔ «Least-to-Most Prompting Enables Complex Reasoning in Large Language Models» دارد که نویسندگان اصلی‌اش دِنی ژو و ناتانائل شرلی از گوگل بودند. مقاله در اردیبهشت ۱۴۰۱ (مه ۲۰۲۲) منتشر شد و بعد در کنفرانس ICLR سال ۲۰۲۳ ارائه شد.

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

نتیجه چشمگیر بود. در آزمون SCAN که تعمیم ترکیبی را می‌سنجد، مدل code-davinci-002 با روش تجزیه و تنها ۱۴ نمونه به دقت دست‌کم ۹۹ درصد رسید، در حالی که همان مدل با زنجیرهٔ تفکر معمولی حدود ۱۶ درصد گرفت. طبق همان مقاله، این نتیجه حتی از مدل‌های تخصصی عصبی-نمادین که با بیش از ۱۵ هزار نمونه آموزش دیده بودند بهتر بود.

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

۳) متن کامل پرامپت

این متن را می‌توانی مستقیم کپی کنی و پیش از مسئله‌ات بگذاری:

مسئلهٔ من را مستقیم جواب نده. اول آن را به کوچک‌ترین زیرمسئله‌های ممکن بشکن، آن‌ها را از ساده به دشوار مرتب کن، سپس یکی‌یکی حل کن و در پایان جواب‌ها را در یک نتیجهٔ نهایی جمع کن.

چهار جزء این پرامپت هر کدام کار مشخصی می‌کنند:

«مستقیم جواب نده» — بازدارندهٔ اصلی است. بدون آن، مدل معمولاً یک جواب کوتاه می‌دهد و بعد به‌عنوان توجیه، زیرمسئله‌ها را ردیف می‌کند؛ یعنی برعکس چیزی که می‌خواهی.

«کوچک‌ترین زیرمسئله‌های ممکن» — جلوی تجزیه‌های سطحی را می‌گیرد. اگر فقط بنویسی «بشکن»، مدل مسئله را به سه بخش کلی تقسیم می‌کند که هرکدام همچنان یک مسئلهٔ بزرگ‌اند.

«از ساده به دشوار مرتب کن» — همان چیزی است که در مقالهٔ اصلی least-to-most نامیده شده و قلب تکنیک است.

«در یک نتیجهٔ نهایی جمع کن» — بدون این جمله، خروجی می‌شود مجموعه‌ای از جواب‌های پراکنده بدون جمع‌بندی.

۴) چهار نسخهٔ موقعیتی

نسخهٔ کسب‌وکار و تصمیم‌گیری

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

نسخهٔ کدنویسی و رفع اشکال

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

نسخهٔ یادگیری

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

نسخهٔ نگارش و پروژه

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

۵) تفاوتش با زنجیرهٔ تفکر

خیلی‌ها این دو را یکی می‌گیرند، در حالی که فرق مهمی دارند.

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

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

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

۶) کجا بیشترین اثر را دارد

تجربه نشان می‌دهد این تکنیک در چند دسته از کارها تفاوت محسوسی می‌سازد:

مسائل چندمرحله‌ای با وابستگی. هرجا که برای رسیدن به جواب باید چند چیز را به ترتیب بدانی، مثل محاسبات مالی چندمرحله‌ای یا برنامه‌ریزی پروژه.

مسائل مبهم. وقتی خودت هم دقیقاً نمی‌دانی سؤال درست چیست، مرحلهٔ تجزیه عملاً سؤالت را برایت روشن می‌کند.

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

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

۷) پنج اشتباه رایج

اشتباه اول: حذف عبارت «مستقیم جواب نده». بدون آن، مدل جواب می‌دهد و تجزیه را به یک زینت تبدیل می‌کند.

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

اشتباه سوم: تجزیهٔ بیش از حد. سی زیرمسئله برای یک تصمیم ساده، خروجی را غیرقابل‌استفاده می‌کند. معمولاً بین چهار تا هشت زیرمسئله کافی است.

اشتباه چهارم: نادیده‌گرفتن ترتیب. اگر مدل زیرمسئله‌ها را از دشوار به ساده مرتب کرد، از او بخواه دوباره مرتب کند؛ در غیر این‌صورت مزیت اصلی روش از بین می‌رود.

اشتباه پنجم: فراموش‌کردن جمع‌بندی. مجموعه‌ای از جواب‌های درست بدون نتیجهٔ نهایی، هنوز جواب مسئلهٔ تو نیست.

۸) ترکیب با تکنیک‌های دیگر

تجزیه به زیرمسئله پایه‌ای است و خوب با بقیه ترکیب می‌شود.

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

با زنجیرهٔ تفکر: جملهٔ «هر زیرمسئله را گام‌به‌گام حل کن» را اضافه کن.

با اسکلت پاسخ: اگر خروجی نهایی یک سند طولانی است، بعد از تجزیه از مدل بخواه اسکلت سند را هم بسازد.

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

۹) یک مثال کامل

فرض کن می‌پرسی «آیا برای کسب‌وکار کوچکم باید اپلیکیشن موبایل بسازم؟» با پرامپت تجزیه، خروجی چیزی شبیه این می‌شود:

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

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

پرسش‌های پرتکرار دربارهٔ پرامپت تجزیه به زیرمسئله

این تکنیک روی همهٔ مدل‌ها کار می‌کند؟

پژوهش اصلی روی نسل قدیمی‌تری از مدل‌ها انجام شد و از آن زمان مدل‌ها بسیار قوی‌تر شده‌اند. مدل‌های امروزی این دستور را راحت‌تر اجرا می‌کنند؛ در مدل‌های کوچک‌تر ممکن است لازم باشد صریح‌تر بنویسی «حداقل پنج زیرمسئله بساز».

چند زیرمسئله مناسب است؟

قاعدهٔ عملی بین چهار تا هشت زیرمسئله است. کمتر از چهار تا یعنی تجزیه واقعی اتفاق نیفتاده و بیشتر از هشت تا معمولاً یعنی داری موضوع را بی‌جهت ریز می‌کنی.

فرقش با فهرست‌کردن مراحل چیست؟

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

آیا برای کارهای خلاقانه هم مفید است؟

تا حدی. برای طراحی ساختار یک داستان یا کمپین، تجزیه کمک می‌کند. اما برای تولید ایدهٔ خام، تکنیک‌های واگرا مناسب‌ترند چون تجزیه ذاتاً محدودکننده است.

می‌شود آن را در حافظهٔ مدل ذخیره کرد؟

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