Chain of Thought, RLVR і Test-Time Compute: виміряно

Є спокуса сказати, що друга версія «подумала над цим». Не варто: механізм і простіший, і корисніший для розуміння.

transformer виконує фіксований обсяг обчислень на кожен згенерований token. Один forward pass: ті самі шари, ті самі матриці, та сама кількість операцій незалежно від того, чи питання — скільки буде 2+2, чи доведіть цю теорему. Усередині моделі немає регулятора «постарайся сильніше саме тут».

Тож коли модель просять відповісти негайно, усе доступне їй обчислення — це один forward pass. Усі проміжні величини мають уміститися в активаціях цього одного проходу, і все, що вона не може обчислити там, вона не може обчислити взагалі.

Виведення token змінює це — і змінює двома окремими способами, які варто розрізняти:

• Більше обчислень. Кожен згенерований token — це ще один повний forward pass. Сто сорок п’ять token роботи — це у сто сорок п’ять разів більше арифметики, ніж відповідь одразу.
• Зовнішня пам’ять. token записуються в context, тож наступний прохід може їх прочитати. 5 × 13 = 65 стає фактом у вхідних даних, а не значенням, яке модель мусить утримувати в активації й переносити далі. Модель використовує власний вихід як чернетку.

Саме другий пункт часто пропускають, і він пояснює, чому роботу треба саме записати, щоб вона допомогла. Модель, яку просять «подумати мовчки, а потім відповісти», не має куди покласти думку.

У цьому немає нічого містичного, і з цього випливає тверде передбачення: chain of thought має найбільше допомагати в задачах із послідовною структурою — де другий крок потребує результату першого — і найменше в задачах, що зводяться до одного пошуку. Саме це й показує література, і саме тому «think step by step» нічого не дає для яка столиця Франції.

Техніка з’явилася у 2022 році у двох частинах. Wei та співавт. показали, що включення розв’язаних прикладів у prompt — демонстрацій, де відповіді передує міркування, — дає великі прирости на арифметичних і commonsense benchmark.¹ Потім Kojima та співавт. показали дещо дивніше: приклади не потрібні. Додавання «Let's think step by step» до zero-shot prompt дає значну частину того самого приросту.²

Саме другий результат пояснює, що відбувається. Якщо магічна фраза розблоковує поведінку, ця поведінка вже була в моделі: pretraining наповнений розв’язаними прикладами, а фраза вказує на відповідну область розподілу. Chain of thought нічого не навчила модель. Вона вибрала те, що модель уже мала.

Таке формулювання також передбачає майбутнє застарівання техніки — до цього ми повернемося наприкінці розділу.

Очевидний наступний крок: якщо один ланцюжок міркувань може бути неправильним, згенерувати кілька й узяти відповідь більшістю голосів. Це self-consistency.³ Витрати суворо більші — $n$ повних генерацій замість однієї — а інтуїція така: неправильні відповіді розсіюються, тоді як правильні збігаються.

Виміряно на 16 тих самих задачах, sampling із temperature 0,8, голосування більшістю за $n$ ланцюжками:

Шістнадцять задач — малий знаменник, і правило з розділу 4 стосується цієї таблиці так само, як і будь-якої іншої. 13 із 16 — це 81 % із 95 % інтервалом Вілсона [57, 93]; 16 із 16 — це 100 % із [81, 100]. Вони перекриваються. Читайте форму кривої — це і є знахідка; не читайте точну сходинку, на якій вона вирівнюється, бо шістнадцять задач не можуть її визначити.

У цій таблиці є дві речі, і друга — не та, на яку я очікував.

Крива вирівнюється на $n = 3$. На третьому зразку точність уже досягає стелі, а решта два зразки нічого не купують, коштуючи по 172 token кожен, 345 разом. Саме таку форму мають усі криві self-consistency, про які повідомляє література, і це значно раніше, ніж підказує рамка «більше зразків — ще краще».

А greedy decoding уже мав 100 %. Поверніться до початку розділу: один ланцюжок, без sampling, 145 token, 24/24. Sampling із temperature 0,8 знизив точність до 81 %, і self-consistency знадобилися три генерації, щоб піднятися назад туди, де один greedy pass уже був, — за 3,6 раза більше token, або в шість разів більше, якщо прогнати sweep до п’яти, не знаючи, де крива вирівняється.

Це не аргумент проти self-consistency. Це точне твердження про те, що вона робить: temperature купує різноманіття, вводячи помилки, а голосування прибирає помилки, які щойно ввело. У задачах, де greedy decoding провалюється — де один найімовірніший ланцюжок веде кудись неправильно, а менш імовірний є правильним, — ця угода окупається, і саме тому техніка існує. У задачах, де greedy вже спрацьовує, це спосіб витратити в шість разів більший бюджет, щоб вийти в нуль.

Другий випадок ніхто не публікує, тому його варто виміряти на власному завданні, перш ніж приймати техніку. Це прості двокрокові задачі для малої моделі; саме в такому режимі результат виходить таким.

Усе досі відбувалося під час prompt на моделі, яку спеціально для цього ніколи не навчали. Зсув, що створив нинішнє покоління reasoning models, полягав у перенесенні цього в навчання — і ключ, який це уможливив, вужчий, ніж здається.

Post-training із розділу 11 потребував людських уподобань, бо на питання «чи була це добра відповідь?» немає програмної відповіді. Але для деяких питань вона є. Математична відповідь або дорівнює правильному значенню, або ні. Код або проходить тести, або ні. Доведення або перевіряється, або ні.

Для таких доменів reward model можна замінити verifier, і все нижче за ланцюгом одразу стає кращим: жодних анотаторів, жодного Bradley–Terry fitting, жодного reward hacking того типу, який вимірювали в розділі 11, — бо unit test неможливо задобрити лестощами. Це reinforcement learning from verifiable rewards, і саме для цього сетингу створили GRPO: згенерувати групу спроб розв’язання тієї самої задачі, перевірити кожну й використати середній бал групи як baseline. Без critic, без анотатора, без reward model. Лише програма, яка каже правильно чи неправильно.

Результат, який переосмислив галузь, прийшов від DeepSeek на початку 2025 року.⁶ Вони взяли базову модель і застосували reinforcement learning with verifiable rewards напряму, без попереднього етапу supervised fine-tuning — етапу, який розділ 11 подає як фундамент усього. Довгі ланцюжки міркувань усе одно виникли. Так само виникла поведінка, якої ніхто не навчав: модель почала повторно перевіряти власні кроки і, в найчастіше цитованому фрагменті статті, спонтанно переглядати підхід посеред розв’язання.

Чесне прочитання не в тому, що reasoning — магія. А в тому, що коли винагороджується лише правильність, а бути правильним у складній задачі означає пропрацювати її, то саме це й знаходить оптимізатор — включно з тими частинами пропрацювання, які роблять і люди, бо їх вимагає сама задача, а не тому, що хтось цього навчав.

Практичний наслідок усього цього такий: reasoning model виробляє token, яких ви просили, і token, яких не просили, — і ви платите за обидва.

Провайдери обробляють це по-різному, і ця різниця важлива:

• Більшість API рахують reasoning tokens усередині кількості output token. Ваш рахунок і ваш ліміт max_tokens включають мислення, якого ви ніколи не бачите.
• Google Gemini повідомляє thinking tokens як окреме поле, поза стандартною кількістю output.

Це справжня несумісність між двома способами рахувати одне й те саме, і будь-який код, який обчислює вартість або забезпечує бюджет між провайдерами, має це нормалізувати. Розділ 16 — там, де це стає грошима, а розділ 23 — там, де це стає бюджетом, який можна примусово дотримувати.

Інший наслідок — latency, яка дивує людей уперше. Час reasoning model до першого видимого token включає все її мислення, тож request, який вісім секунд нічого не stream, а потім відповідає за одну секунду, — це не зависле з’єднання; це модель працює. Будь-який інтерфейс, що показує spinner без пояснення вісім секунд, має проблему дизайну, а не мережі.

Наостанок — попередження, бо саме так матеріал цього розділу найчастіше застосовують неправильно.

Уся перша половина — це техніка, яка змушує модель, не навчену reason, усе одно виробляти reasoning. Моделі, навчені з RLVR, уже це роблять: вони виводять власну роботу, власної довжини, перед відповіддю. Казати такій моделі think step by step у найкращому разі зайве, а в найгіршому — шкідливо: це може створити короткий, сформований prompt ланцюжок замість довшого, який модель згенерувала б сама, і деякі провайдери прямо це документують.

Те саме стосується складних scaffolds для міркування, побудованих у коді застосунку. prompt, який проводить модель через дерево рішень, яким вона вже навігує внутрішньо, витрачає ваші token на обмеження поведінки, яку вже навчено. Це перша поява теми, що проходить через решту курсу: техніки, які були essential у 2022 році, стали superstition у 2025-му, і єдиний спосіб зрозуміти, що є що для вашої моделі сьогодні, — виміряти обидва варіанти.

Розділ 15 — там, де це вимірювання стає дисципліною, а не думкою.

Reasoning має незручну властивість: це єдина здатність, чия вартість масштабується зі складністю питання. Модель, яка думає дев’ятсот token, виконує дев’ятсот forward pass, тримає зростаючий cache у пам’яті для всіх них і утримує GPU протягом усього часу.

Це робить економіку serving reasoning model суттєво гіршою, ніж serving chat model, і перетворює набір деталей реалізації на різницю між життєздатним і нежиттєздатним продуктом: як зберігається й повторно використовується cache минулих keys and values, скільки request можуть спільно використовувати forward pass і якої precision насправді потребують ваги.

Розділ 13 — останній, де модель є об’єктом у вашій пам’яті, а не сервісом за портом, і він про те, як зробити цей об’єкт достатньо дешевим для serving. Він також виконує обіцянку з цього розділу: speculative decoding, який виробляє кілька token приблизно за ціну одного, коли мала модель вгадує, а велика перевіряє, — трюк, який має сенс лише після того, як ви побачили, скільки forward pass витрачається на очікування пам’яті, а не на арифметику.

Усі вимірювання в цьому розділі походять із Qwen/Qwen2.5-0.5B-Instruct на 24 згенерованих текстових задачах на два кроки, з greedy decoding, окрім місць, де явно зазначено sampling, і з нулем truncated generations на використаних token caps. Вони відтворювані, і це мала модель на простих задачах: читайте результат self-consistency як демонстрацію механізму, а не як benchmark. Розділ 18 конспекту лекцій CS229 і розділ 12 Hugging Face LLM Course також висвітлюють цей матеріал із більшими моделями та коректними benchmark.