12/30فصل 12 از 30

Chain of Thought، RLVR و Test-Time Compute، اندازه‌گیری‌شده

همان 24 مسئله: 0٪ درست با 1.9 token، 100٪ با 145. سپس self-consistency، بازخرید دقتی که greedy decoding از قبل داشت.

22 تیر 1405به‌روزرسانی شده 20 شهریور 140514 دقیقه مطالعه

در این صفحه

بیست‌وچهار مسئلهٔ کلامی دومرحله‌ای. از یک مدل کوچک — با نیم میلیارد پارامتر، همان مدل فصل 11 — هر مسئله دو بار پرسیده می‌شود.

اول، فقط پاسخ خواسته می‌شود:

TEXT

"...How many bolts are left?  Reply with only the final number, nothing else."

  0 / 24 correct        1.9 tokens per answer

بعد، پاسخ خواسته می‌شود، اما با اجازه برای کار کردن قبل از پاسخ:

TEXT

"...How many bolts are left?  Think step by step, then give the final
 number on its own line."

  24 / 24 correct       145.2 tokens per answer

از صفر تا صد درصد. همان مدل، همان وزن‌ها، همان مسئله‌ها، همان greedy decoding. تنها تفاوت این است که نسخهٔ دوم اجازه داشت پیش از متعهد شدن به یک عدد، 143 token بیشتر منتشر کند.

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

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

لینک به بخش: مدل فکر نمی‌کند. مدت بیشتری محاسبه می‌کند.

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

یک transformer برای هر token تولیدشده مقدار ثابتی محاسبه انجام می‌دهد. یک forward pass: همان لایه‌ها، همان ماتریس‌ها، همان تعداد عملیات، فارغ از اینکه سؤال ۲+۲ چند می‌شود باشد یا این قضیه را اثبات کن. داخل مدل هیچ پیچ تنظیمی برای «روی این یکی بیشتر تلاش کن» وجود ندارد.

پس وقتی از مدل خواسته می‌شود فوراً پاسخ بدهد، کل محاسبه‌ای که در اختیار دارد یک forward pass است. همهٔ کمیت‌های میانی باید در activationهای همان تک pass جا شوند، و هر چیزی را که آنجا نتواند محاسبه کند، نمی‌تواند محاسبه کند.

انتشار tokenها این را تغییر می‌دهد، و این تغییر به دو شکل جداگانه رخ می‌دهد که ارزش تفکیک دارند:

محاسبهٔ بیشتر. هر token تولیدشده یک forward pass کامل دیگر است. صد و چهل‌وپنج token کار کردن، یعنی صد و چهل‌وپنج برابر محاسبهٔ پاسخ‌دادن مستقیم.
حافظهٔ بیرونی‌شده. tokenها در context نوشته می‌شوند، پس pass بعدی می‌تواند آن‌ها را بخواند. 5 × 13 = 65 به یک واقعیت در ورودی تبدیل می‌شود، نه مقداری که مدل باید در یک activation نگه دارد و جلو ببرد. مدل از خروجی خودش به‌عنوان چرک‌نویس استفاده می‌کند.

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

هیچ‌کدام از این‌ها به چیز عرفانی نیاز ندارد، و یک پیش‌بینی محکم می‌سازد: chain of thought باید بیشترین کمک را در مسئله‌هایی با ساختار سریالی بکند — جایی که مرحلهٔ دوم به نتیجهٔ مرحلهٔ اول نیاز دارد — و کمترین کمک را در مسئله‌هایی که فقط یک lookup ساده‌اند. ادبیات دقیقاً همین را نشان می‌دهد، و به همین دلیل است که «مرحله‌به‌مرحله فکر کن» برای پایتخت فرانسه کجاست کاری نمی‌کند.

Chain of thought، به‌عنوان یک تکنیک prompting

لینک به بخش: Chain of thought، به‌عنوان یک تکنیک prompting

این تکنیک در سال 2022 در دو بخش آمد. Wei و همکاران نشان دادند که گنجاندن مثال‌های حل‌شده در prompt — نمونه‌هایی که در آن‌ها پاسخ پس از استدلال می‌آید — روی benchmarkهای حساب و commonsense بهبودهای بزرگی ایجاد می‌کند.¹ سپس Kojima و همکاران چیز عجیب‌تری نشان دادند: به مثال‌ها نیاز ندارید. افزودن "Let's think step by step" به یک prompt صفرشات، بخش زیادی از همان سود را می‌گیرد.²

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

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

Self-consistency، و نتیجه‌ای که من را غافلگیر کرد

لینک به بخش: Self-consistency، و نتیجه‌ای که من را غافلگیر کرد

گام بعدی واضح است: اگر یک زنجیرهٔ استدلال می‌تواند غلط باشد، چندتا را sample کنید و پاسخ اکثریت را بگیرید. این همان self-consistency است.³ این هزینه‌ای قطعاً بزرگ‌تر است — به‌جای یکی، $n$ تولید کامل — و شهودش این است که پاسخ‌های غلط پراکنده می‌شوند، اما پاسخ‌های درست با هم توافق دارند.

اندازه‌گیری روی 16 مسئله از همان مجموعه، با sampling در temperature برابر 0.8 و رأی اکثریت روی $n$ زنجیره:

$n$	دقت	tokenهای تجمعی	token به‌ازای هر مسئله
1	81 %	2,952	185
2	81 %	5,618	351
3	100 %	8,417	526
4	100 %	11,103	694
5	100 %	13,933	871

شانزده مسئله مخرج کوچکی است، و قاعدهٔ فصل 4 برای این جدول هم مثل هر جدول دیگری صدق می‌کند. 13 از 16 یعنی 81 % با بازهٔ Wilson 95 % برابر [57, 93]؛ 16 از 16 یعنی 100 % با [81, 100]. این‌ها هم‌پوشانی دارند. شکل منحنی را بخوانید، که یافته همین است؛ پلهٔ دقیقِ تخت‌شدنش را نخوانید، چون شانزده مسئله نمی‌تواند جای آن را مشخص کند.

دو چیز در آن جدول هست، و دومی چیزی نبود که انتظار داشتم.

منحنی در $n = 3$ تخت می‌شود. تا sample سوم، دقت به سقف خود رسیده و دو sample باقی‌مانده هیچ چیز نمی‌خرند، درحالی‌که هرکدام 172 token هزینه دارند، جمعاً 345. این شکل هر منحنی self-consistency است که در ادبیات گزارش شده، و خیلی زودتر از چارچوب «sample بیشتر یعنی بهترتر» اتفاق می‌افتد.

و greedy decoding از قبل روی 100 % بود. به ابتدای فصل نگاه کنید: یک زنجیره، بدون sampling، 145 token، 24/24. sampling با temperature برابر 0.8 دقت را به 81 % کاهش داد، و self-consistency به سه تولید نیاز داشت تا دوباره به جایی برسد که یک pass حریصانهٔ واحد از قبل آنجا بود — با 3.6 برابر token، یا اگر بدون دانستن نقطهٔ تخت‌شدن sweep را تا پنج اجرا کنید، شش برابر.

این استدلالی علیه self-consistency نیست. بیان دقیقی است از کاری که می‌کند: temperature با تزریق خطا تنوع می‌خرد، و رأی‌گیری خطاهایی را که همین الان تزریق کرده حذف می‌کند. در مسئله‌هایی که greedy decoding شکست می‌خورد — جایی که محتمل‌ترین زنجیرهٔ واحد به مسیر غلط می‌رود و زنجیره‌ای کم‌احتمال‌تر درست است — این معامله می‌ارزد، و به همین دلیل این تکنیک وجود دارد. در مسئله‌هایی که greedy از قبل موفق است، راهی است برای خرج‌کردن شش برابر بودجه تا سربه‌سر شوید.

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

Tree of thoughts، و هزینه‌اش در تعداد callها.

تعمیم این است که شاخه بزنیم: به‌جای sampling از $n$ زنجیرهٔ مستقل، یک درخت از حالت‌های استدلال جزئی را بگردیم، آن‌ها را ارزیابی کنیم، و گزینه‌های امیدبخش را گسترش دهیم.⁴ کار می‌کند، و برای مسئله‌هایی که به جست‌وجو نیاز دارند ساختار درستی است — معماها، برنامه‌ریزی، هر چیزی با backtracking.

هزینه همان چیزی است که نمی‌گذارد default شود. Self-consistency با $n = 5$ یعنی پنج تولید. درختی با پهنای $b$ و عمق $d$ تا $b^d$ حالت دارد، و هر حالت برای گسترش دست‌کم به یک تولید نیاز دارد و اغلب برای ارزیابی به یکی دیگر. نتایج منتشرشده برای یک پاسخ واحد از ده‌ها تا صدها call مدل استفاده می‌کنند.

این نوعی هزینهٔ متفاوت از زنجیرهٔ طولانی‌تر است. زنجیره‌ای با 900 token یک request با latency قابل‌پیش‌بینی است. درخت صد callی یعنی صد رفت‌وبرگشت، صد فرصت برای خوردن به rate limit، و latencyای که مجموع صد وابستگی سریالی است — که مسئلهٔ فصل 14 است، نه مسئله‌ای مدل‌سازی.

از درخواست‌کردن تا آموزش‌دادن

لینک به بخش: از درخواست‌کردن تا آموزش‌دادن

همهٔ آنچه تا اینجا بود در زمان prompt روی مدلی اتفاق می‌افتد که هرگز مشخصاً برای آن آموزش ندیده بود. تغییری که نسل فعلی مدل‌های reasoning را ساخت این بود که آن را وارد training کردند — و کلیدی که این را ممکن کرد محدودتر از چیزی است که به نظر می‌رسد.

post-training فصل 11 به ترجیحات انسانی نیاز داشت، چون «آیا این پاسخ خوب بود؟» پاسخ برنامه‌پذیر ندارد. اما برای بعضی سؤال‌ها دارد. پاسخ ریاضی یا برابر مقدار درست هست یا نیست. کد یا testها را پاس می‌کند یا نمی‌کند. اثبات یا check می‌شود یا نمی‌شود.

برای این حوزه‌ها می‌توانید reward model را با یک verifier جایگزین کنید، و همه‌چیز در ادامه هم‌زمان بهتر می‌شود: نه annotator، نه برازش Bradley–Terry، نه reward hacking از نوعی که در فصل 11 اندازه‌گیری شد — چون نمی‌توانید از یک unit test چاپلوسی کنید. این reinforcement learning from verifiable rewards است، و همان محیطی است که GRPO برایش ساخته شد: گروهی از تلاش‌های حل برای یک مسئله را sample کنید، هرکدام را check کنید، و میانگین امتیاز گروه را به‌عنوان baseline به کار ببرید. نه critic، نه annotator، نه reward model. فقط برنامه‌ای که می‌گوید درست یا غلط.

Outcome reward. فقط پاسخ نهایی را امتیاز بدهید. ارزان است — یک مقایسهٔ رشته‌ای — و یک حفرهٔ واضح دارد: راه‌حلی که از مسیر استدلال غلط به عدد درست می‌رسد دقیقاً مثل راه‌حل صحیح reward می‌گیرد، پس policy آزاد است چرندیاتِ موجه‌نما یاد بگیرد که اتفاقاً به مقصد می‌رسند.

Process reward. هر گام را امتیاز بدهید. Lightman و همکاران⁵ مجموعه‌داده‌ای از 800,000 گام استدلال با برچسب انسانی ساختند تا مدلی را آموزش دهند که این کار را انجام دهد، و نشان دادند روی ریاضیات سخت به‌طور چشمگیری از outcome supervision بهتر عمل می‌کند. هزینه در خود نام است: کسی 800,000 گام را برچسب زده است.

نتیجه‌ای که میدان را از نو قاب‌بندی کرد اوایل 2025 از DeepSeek آمد.⁶ آن‌ها یک مدل پایه را گرفتند و reinforcement learning با verifiable rewards را مستقیماً اعمال کردند، بدون اینکه اول مرحلهٔ supervised fine-tuning وجود داشته باشد — همان مرحله‌ای که فصل 11 آن را بنیاد همه‌چیز معرفی می‌کند. زنجیره‌های طولانی استدلال بااین‌حال پدیدار شدند. رفتارهایی هم پدیدار شدند که هیچ‌کس برایشان آموزش نداده بود: مدل شروع کرد به بازبینی گام‌های خودش و، در نقل‌قول‌شده‌ترین بخش مقاله، به‌طور خودجوش در میانهٔ راه‌حل در رویکردش تجدیدنظر کرد.

خوانش صادقانه این نیست که reasoning جادوست. این است که وقتی تنها چیزی که reward می‌گیرد درست‌بودن است، و درست‌بودن در یک مسئلهٔ سخت مستلزم کار کردن روی آن است، همان کار کردن چیزی است که optimiser پیدا می‌کند — از جمله بخش‌هایی از کار کردن که انسان‌ها هم انجام می‌دهند، چون همان چیزی‌اند که مسئله می‌طلبد نه چیزی که کسی آموزش داده باشد.

Reasoning tokenها یک ردیف روی صورت‌حساب‌اند

لینک به بخش: Reasoning tokenها یک ردیف روی صورت‌حساب‌اند

پیامد عملی همهٔ این‌ها این است که یک مدل reasoning هم tokenهایی تولید می‌کند که شما خواسته‌اید و هم tokenهایی که نخواسته‌اید، و برای هر دو پول می‌دهید.

providerها این را متفاوت مدیریت می‌کنند، و تفاوت مهم است:

بیشتر APIها reasoning tokenها را داخل شمارش output token حساب می‌کنند. صورت‌حساب شما و محدودیت max_tokens شما هر دو شامل فکری هستند که هرگز نمی‌بینید.
Gemini گوگل thinking tokenها را به‌عنوان فیلدی جداگانه، خارج از شمارش استاندارد output، گزارش می‌کند.

این یک ناسازگاری واقعی بین دو روش شمارش یک چیز واحد است، و هر کدی که هزینه را محاسبه می‌کند یا بودجه‌ای را میان providerها enforce می‌کند باید آن را normalise کند. فصل 16 جایی است که این موضوع به پول تبدیل می‌شود، و فصل 23 جایی که به بودجه‌ای تبدیل می‌شود که می‌توانید enforce کنید.

پیامد دیگر از جنس latency است و اولین بار که آدم‌ها می‌بینند غافلگیرشان می‌کند. زمان یک مدل reasoning تا اولین token قابل‌مشاهده شامل تمام فکر کردنش است، پس requestای که هشت ثانیه هیچ چیزی stream نمی‌کند و بعد در یک ثانیه پاسخ می‌دهد، اتصال گیرکرده نیست — مدل دارد کار می‌کند. هر interfaceای که هشت ثانیه spinner را بدون توضیح نشان دهد، مشکل طراحی دارد نه مشکل شبکه.

محور سوم.

قوانین scaling فصل 10 دو knob داشتند: پارامترها و دادهٔ training. هر دو قبل از عرضهٔ مدل خرج می‌شوند، و هر دو در زمان inference ثابت‌اند.

Test-time compute سومین محور است، و رفتارش با آن دو فرق دارد: به‌ازای هر request خرج می‌شود، می‌تواند به‌ازای هر request تغییر کند، و به‌جای بودجهٔ training مستقیماً با latency و هزینه معامله می‌کند. Snell و همکاران⁷ نشان می‌دهند که برای بعضی مسئله‌ها، یک بودجهٔ compute ثابت وقتی در inference خرج شود دقت بیشتری می‌خرد تا وقتی صرف یک مدل بزرگ‌تر شود — و این فرض را وارونه می‌کند که راه گرفتن پاسخ‌های بهتر، مدل بزرگ‌تر است.

خوانش عملی، و دلیل اینکه این یک تصمیم مهندسی است نه پژوهشی: یک مدل کوچک که به آن مجال کار بدهید می‌تواند مدل بزرگی را که فوراً جواب می‌دهد شکست دهد، با هزینه‌ای که به‌ازای هر request کنترل می‌کنید نه به‌ازای هر deployment. اینکه این معامله خوب است یا نه بستگی دارد به اینکه بودجهٔ latency شما چقدر می‌ارزد؛ و این پرسشی دربارهٔ محصول شماست، نه دربارهٔ مدل.

وقتی «مرحله‌به‌مرحله فکر کن» دیگر کمک نمی‌کند

لینک به بخش: وقتی «مرحله‌به‌مرحله فکر کن» دیگر کمک نمی‌کند

یک هشدار پایانی، چون رایج‌ترین راهِ کاربرد غلطِ مطالب این فصل همین است.

همهٔ چیزهایی که در نیمهٔ اول آمد تکنیکی برای واداشتن مدلی بود که برای reasoning آموزش ندیده بود تا بااین‌حال reasoning تولید کند. مدل‌هایی که با RLVR آموزش دیده‌اند از قبل این کار را می‌کنند: آن‌ها پیش از پاسخ، کار خودشان را، با طول خودشان، منتشر می‌کنند. گفتن اینکه چنین مدلی مرحله‌به‌مرحله فکر کند، در بهترین حالت زائد و در بدترین حالت زیان‌بار است — می‌تواند به‌جای زنجیرهٔ طولانی‌تری که مدل خودش تولید می‌کرد، یک زنجیرهٔ کوتاه و prompt-شکل بسازد، و بعضی providerها دقیقاً همین را مستند کرده‌اند.

همین دربارهٔ داربست‌های استدلالی مفصلی هم صدق می‌کند که در کد application ساخته می‌شوند. promptای که مدل را از درخت تصمیمی عبور می‌دهد که خودش از قبل دروناً پیمایش می‌کند، tokenهای شما را خرج می‌کند تا رفتاری را محدود کند که آموزش داده شده است. این نخستین ظهورِ مضمونی است که در بقیهٔ دوره ادامه دارد: تکنیک‌هایی که در 2022 ضروری بودند، تا 2025 به خرافه تبدیل شدند، و تنها راه تشخیص اینکه امروز برای مدل شما کدام کدام است، اندازه‌گیری هر دو است.

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

مسیر بعدی کجاست

لینک به بخش: مسیر بعدی کجاست

reasoning یک ویژگی ناراحت‌کننده دارد: تنها قابلیتی است که هزینه‌اش با سختی سؤال scale می‌شود. مدلی که برای نهصد token فکر می‌کند، نهصد forward pass انجام می‌دهد، برای همهٔ آن‌ها یک cache رو‌به‌رشد را در حافظه نگه می‌دارد، و در تمام مدت یک GPU را مشغول نگه می‌دارد.

این اقتصادِ serving یک مدل reasoning را به‌مراتب بدتر از serving یک مدل chat می‌کند، و مجموعه‌ای از جزئیات پیاده‌سازی را به تفاوت میان محصولی viable و محصولی unviable تبدیل می‌کند: اینکه cache کلیدها و مقادیر گذشته چگونه ذخیره و دوباره استفاده می‌شود، چند request می‌توانند یک forward pass را share کنند، و وزن‌ها واقعاً به چه میزان precision نیاز دارند.

فصل 13 آخرین فصلی است که در آن مدل به‌جای سرویسی پشت یک port، شیئی در حافظهٔ شماست، و دربارهٔ آن است که این شیء را آن‌قدر ارزان کنیم که بتوان آن را serve کرد. همچنین وعده‌ای از این فصل را نقد می‌کند: speculative decoding، که با واداشتن یک مدل کوچک به حدس‌زدن و یک مدل بزرگ به check کردن، چند token را تقریباً با قیمت یکی تولید می‌کند — ترفندی که فقط وقتی معنا دارد که دیده باشید چه مقدار از یک forward pass به‌جای انجام حساب، صرف انتظار برای حافظه می‌شود.

منابع و روش

لینک به بخش: منابع و روش

همهٔ اندازه‌گیری‌های این فصل از Qwen/Qwen2.5-0.5B-Instruct روی 24 مسئلهٔ کلامی دومرحله‌ایِ تولیدشده می‌آیند، با greedy decoding مگر جایی که sampling ذکر شده، و با صفر تولیدِ truncate‌شده در سقف‌های token استفاده‌شده. قابل بازتولیدند، و مربوط به یک مدل کوچک روی مسئله‌های آسان‌اند: نتیجهٔ self-consistency را به‌عنوان نمایش سازوکار بخوانید، نه به‌عنوان benchmark. فصل 18 یادداشت‌های درس CS229 و فصل 12 دورهٔ LLM در Hugging Face هر دو این مطالب را با مدل‌های بزرگ‌تر و benchmarkهای درست پوشش می‌دهند.

ارجاعات

لینک به بخش: ارجاعات

Wei, J. et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903 (2022). ↩
Kojima, T., Gu, S. S., Reid, M., Matsuo, Y. and Iwasawa, Y. Large Language Models are Zero-Shot Reasoners. arXiv:2205.11916 (2022). نتیجهٔ «let's think step by step». ↩
Wang, X. et al. Self-Consistency Improves Chain of Thought Reasoning in Language Models. arXiv:2203.11171 (2022). ↩
Yao, S. et al. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601 (2023). ↩
Lightman, H. et al. Let's Verify Step by Step. arXiv:2305.20050 (2023). PRM800K را معرفی می‌کند، مجموعه‌دادهٔ process supervision با 800,000 گام. ↩
DeepSeek-AI. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948 (2025). نتیجهٔ R1-Zero — اعمال reinforcement learning مستقیماً روی یک مدل پایه، بدون مرحلهٔ supervised fine-tuning — در بخش 2.2 است. ↩
Snell, C., Lee, J., Xu, K. and Kumar, A. Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters. arXiv:2408.03314 (2024). ↩