Коли чатбот робить паузу й показує «thinking», це не просто анімація очікування. За цією затримкою стоїть новий підхід до використання обчислювальних ресурсів під час роботи моделей — test-time compute. Канал IBM Technology розбирає, як «обдумування» на етапі відповіді змінює точність великих мовних моделей (LLM) і чому це може стати другим ключовим вектором масштабування ШІ після розміру моделі.
Від train-time до test-time: що саме змінюється
Класичний підхід до розвитку LLM останні роки був простим: масштабувати все.
- більше параметрів моделі
- більше тренувальних даних
- більше FLOPs (обчислень) під час навчання
Це так званий train-time compute — фіксована вартість. Модель місяцями тренують на гігантських масивах тексту, витрачають мільйони доларів, після чого ваги «заморожують». Далі, незалежно від завдання — від короткого резюме листа до задачі з вищої фізики — модель робить одне й те саме: один прямий прохід мережею, генеруючи відповідь токен за токеном.
У цього підходу є фундаментальне обмеження:
кожен наступний токен — це своєрідне зобов’язання. Модель обирає статистично найімовірніший варіант, виводить його й уже не повертається назад, навіть якщо перший крок повів у хибному напрямку. Саме тому LLM можуть дуже переконливо «галюцинувати» — вони послідовно розвивають неправильну думку, не маючи механізму переосмислення.
Test-time compute змінює цю картину. Ідея проста:
моделі виділяють бюджет обчислень не під час навчання, а під час виконання запиту — і дають їй можливість вирішувати, як саме цей бюджет витратити. Це і є те саме «thinking», яке бачить користувач.
Ланцюжок міркувань: «thinking tokens» як чорновик відповіді
Найпомітніший механізм, який використовує test-time compute, — це chain of thought (ланцюжок міркувань).
Від підказки до вбудованого мислення
Будь-яку сучасну LLM можна змусити «думати вголос», просто додавши в промпт інструкцію на кшталт «думай крок за кроком». Але з’явився окремий клас reasoning-моделей, які вміють це робити автоматично. Їх додатково навчають за допомогою reinforcement learning (RL):
- під час RL-моделі показують, що розбиття задачі на кроки й проміжні пояснення
(тобто генерація проміжних «міркувальних» токенів)
частіше приводить до правильної відповіді; - за такі розгорнуті міркування модель отримує вищу винагороду;
- у результаті вона привчається спочатку міркувати, а вже потім відповідати.
Ці проміжні токени можна назвати thinking tokens. Вони:
- генеруються до фінальної відповіді;
- є звичайними вихідними токенами й коштують реальних обчислень;
- змінюють призначення прямого проходу:
перші кроки — це вже не «остаточна відповідь», а чернетка розв’язання задачі.
Як це допомагає
Замість того, щоб одразу будувати остаточну відповідь, модель:
- отримує запит;
- генерує ланцюжок міркувань (thinking tokens);
- лише потім формує відповідь для користувача.
У цьому проміжному просторі вона може:
- спробувати один підхід;
- «помітити», що він не веде до розв’язання;
- змінити стратегію — ще до того, як з’явиться перше слово відповіді.
Так LLM отримує можливість «передумати», чого немає в класичному одноразовому прямому проході.
Пошук і самоперевірка: як моделі вчаться вибирати кращий шлях
Окрім ланцюжка міркувань, test-time compute використовує ще два важливі механізми: пошук і self-consistency.
Пошук як дерево рішень
У стандартному режимі модель застосовує жадібне або майже жадібне декодування:
обирає найімовірніший наступний токен і рухається далі, без альтернативних гілок.
З test-time compute можна реалізувати tree search:
- модель починає ланцюжок міркувань;
- у певні моменти розгалужується, пробуючи кілька варіантів продовження;
- щоб не досліджувати всі гілки нескінченно, використовується verifier — окрема модель або механізм, який оцінює, яка гілка виглядає найперспективнішою;
- далі модель продовжує міркування вже по обраній гілці.
Це дозволяє не просто «йти вперед», а досліджувати простір рішень і вибирати кращий маршрут.
Self-consistency: кілька спроб, одне рішення
Третій підхід — self-consistency:
- одну й ту саму задачу модель розв’язує n разів;
- кожного разу використовується висока температура — щоб отримати різні шляхи міркувань;
- у підсумку виходить n незалежних ланцюжків;
- далі застосовується більшість голосів: якщо, наприклад, 7 із 10 ланцюжків дали однакову відповідь, її й беруть як фінальну.
Тут не потрібен окремий verifier:
модель використовує власний розподіл відповідей як сигнал впевненості.
Масштабування «на роздуми»: нові закони й старі обмеження
Дослідження Google DeepMind 2024 року показало, що test-time compute має власні закони масштабування. Якщо відкласти на графіку:
- по осі X — обчислення під час інференсу (test-time compute);
- по осі Y — результат на бенчмарках з міркувань,
то продуктивність плавно й стабільно зростає зі збільшенням обчислень під час виконання запиту.
Один із ключових висновків:
- невелика модель приблизно на 3 млрд параметрів,
- яка використовує пошукові стратегії на етапі відповіді,
може перевершити в задачах з важкою математикою:
- значно більшу модель на 70 млрд параметрів,
- тобто більш ніж у 20 разів більшу за розміром.
Інакше кажучи, «думати довше» іноді ефективніше, ніж «бути більшим».
Ціна роздумів: затримки, гроші й «перемислення»
Однак за це доводиться платити.
-
Затримка (latency)
Якщо кожен запит до чатбота перетворюється на 45 секунд пошуку по дереву рішень, користувацький досвід різко погіршується. -
Вартість токенів
Thinking tokens — це звичайні вихідні токени.
Якщо модель витрачає, скажімо, 10 000 токенів на одне складне міркування,
це напряму збільшує вартість обслуговування. -
Перемислення (overthinking)
Примушувати reasoning-модель довго міркувати над простими питаннями може бути шкідливо: - модель починає «перегравати» ситуацію;
- сумнівається в очевидних відповідях;
- у підсумку частіше помиляється — як студент, який на іспиті відмовляється від правильної інтуїтивної відповіді після довгих сумнівів.
CAPEX проти OPEX у світі ШІ
З економічної точки зору:
- Train-time compute — це CAPEX (капітальні витрати):
платять один раз за тренування, незалежно від того, скільки потім буде запитів. - Test-time compute — це OPEX (операційні витрати):
платять за кожен запит, причому можна гнучко вирішувати, скільки обчислень виділити.
Це відкриває можливість динамічного керування якістю й вартістю відповіді.
Адаптивні системи: коли варто «думати довше»
З урахуванням усіх компромісів найперспективнішим підходом виглядає адаптивний:
- простим запитам — швидкий, одноразовий прямий прохід без складних міркувань;
- складним задачам — повний reasoning-пайплайн із ланцюжком міркувань, пошуком і/або self-consistency.
Так уже працюють деякі популярні системи. Наприклад, ChatGPT використовує «пікер», який маршрутизує запити між reasoning-моделями та звичайними моделями залежно від складності задачі.
У підсумку ШІ масштабують не лише по осі «більше параметрів і даних», а й по осі «більше обчислень під час відповіді там, де це потрібно». Моделі стають не тільки більшими й швидшими, а й навчаються уповільнюватися й думати, коли цього вимагає задача.
Джерело
Why AI Models Pause to Think: Test Time Compute Explained — IBM Technology