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

ایده‌ی پارادایم: محاسبه‌ی بیشتر در لحظه‌ی پاسخ

تا حالا مسیر بهبود مدل‌ها تقریباً همیشه «بهبود قبل از کار» بود: آموزش بیشتر، مدل بزرگ‌تر، داده‌ی بهتر — همه‌چیز قبل از اینکه شما پرامپت بدهید. مدل‌های استدلالی محور را جابه‌جا کرده‌اند: بخشی از بهبود را به «لحظه‌ی کار» منتقل کرده‌اند. وقتی سؤال سخت می‌آید، مدل به‌جای جواب فوری، زنجیره‌ای از استدلال داخلی تولید می‌کند: مسئله را می‌شکند، مسیرهای حل را می‌سنجد، در مسیر غلط متوقف می‌شود و برمی‌گردد، نتایج میانه را چک می‌کند — و وقتی به اطمینان رسید، پاسخ نهایی را می‌دهد. به این رویکرد Test-time Compute می‌گویند: «حسابِ بیشتر هنگام پاسخ».

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

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

در عمل چه چیزی عوض می‌شود؟

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

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

راهنمای انتخاب: کِی استدلالی، کِی معمولی؟

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

نکات استفاده از مدل‌های استدلالی

  • مسئله را کامل تعریف کنید: این مدل‌ها به «شرایط صریح» عادت دارند؛ قیود، ورودی‌ها و تعریف موفقیت را در پرامپت بدهید — فکرشان به همان اندازه‌ای که داده‌اید دقیق می‌شود.
  • برای خلاقیت خام استفاده نکنید: brainstorming و نثر ادبی با مدل‌های معمولی بهتر و ارزان‌تر جواب می‌گیرد.
  • مسیر فکر را ابزار دیباگ ببینید: اگر جواب غلط بود، در خلاصه‌ی استدلال ببینید کجا فرض اشتباه گرفته — اصلاح همان فرض، مؤثرتر از تکرار درخواست است.
  • مهلت و بودجه درنظر بگیرید: برای سیستم‌های بلادرنگ، استدلالی انتخاب پیش‌فرض نیست؛ تأخیر چند ده ثانیه‌ای را در تجربه‌ی کاربر حساب کنید.

جمع‌بندی

مدل استدلالی، بهبود را از «قبل از کار» به «لحظه‌ی کار» منتقل کرده است: با محاسبه‌ی بیشتر در لحظه‌ی پاسخ، در مسائل سختِ قابل‌راستی‌آزمایی جهش کیفیت می‌دهد — به بهای سرعت و هزینه. قاعده‌ی انتخاب ساده است: ساده ← سبک و سریع؛ متوسط ← مدل اصلی؛ سخت ← استدلالی. و همان‌طور که در مطلب توکن دیدیم، فکرِ طولانی یعنی توکنِ بیشتر؛ پس این انتخاب را هم در بودجه‌ی پروژه حساب کنید. در ماین‌دبیس مدل‌های استدلالی و معمولی کنار هم در دسترس‌اند — با یک حساب می‌توانید همین امروز دو حالت را روی مسئله‌ی واقعی خودتان مقایسه کنید.