Test-Time Compute
test-time compute — дополнительные вычисления модели во время решения задачи
Test-Time Compute — способы потратить больше вычислений на конкретный ответ: сделать несколько попыток, провести поиск, проверить решение или увеличить внутренний бюджет рассуждения. Польза зависит от задачи и не растёт бесконечно вместе с числом токенов.
Коротко
Коротко. Test-time compute — дополнительные вычисления во время решения задачи: несколько попыток, поиск вариантов или проверка ответа. Даже одна обычная попытка требует многих проходов модели, пока она строит ответ токен за токеном. Дополнительный бюджет может повысить точность, но увеличивает задержку и стоимость.
Чем это отличается от обучения
При обучении меняются веса модели. Дополнительные вычисления расходуются заранее и влияют на все будущие запросы.
При test-time compute веса могут остаться прежними. Больше ресурсов получает только текущая задача. Поэтому один запрос можно обработать быстро, а другому дать несколько попыток и проверку.
Это ещё один способ улучшать решение наряду с:
- размером и архитектурой модели;
- объёмом и качеством обучения;
- контекстом и инструментами во время запроса.
Основные способы
Длиннее обработать одну попытку
Reasoning-модель может использовать больший внутренний или выходной бюджет на промежуточное решение. Конкретный механизм зависит от API: видимый текст рассуждения не обязательно совпадает с внутренним вычислением.
Сгенерировать несколько кандидатов
Модель решает задачу несколько раз. Затем система выбирает ответ голосованием, по заданному правилу или с помощью отдельного проверяющего. Если попытки повторяют одну ошибку, голосование её не исправит.
Искать по вариантам
Вместо одной цепочки система развивает несколько веток, отбрасывает слабые и продолжает перспективные. Такой поиск помогает в коде, планировании и головоломках, но быстро расходует бюджет.
Проверить и исправить
Ответ проходит через тест, калькулятор, компилятор, симулятор или другую модель. Обнаруженная ошибка возвращается в следующую итерацию. Проверяемый внешний сигнал часто полезнее просьбы «подумай ещё».
Выделять бюджет по сложности
Маршрутизатор оценивает запрос и выбирает быстрый либо глубокий режим. Ошибка маршрутизации тоже имеет цену: сложная задача может уйти в короткий проход, а простая — потратить лишние ресурсы.
Наглядный пример
Представим, что модели нужно исправить функцию так, чтобы она проходила тесты.
Обычный режим предлагает одну правку кода. Система с дополнительными вычислениями может:
- построить несколько гипотез причины;
- внести минимальную правку для каждой;
- запустить тесты в изолированной среде;
- сравнить изменения кода и побочные эффекты;
- выбрать прошедший вариант;
- остановиться по лимиту времени или шагов.
Здесь помогает обратная связь от тестов, а не длина текста. Пройденные тесты подтверждают только проверенные случаи: среди прошедших вариантов всё ещё может оказаться ошибочный.
Почему дополнительные попытки помогают
Вероятностная модель способна знать нужный приём и всё же выбрать неудачное продолжение. Несколько траекторий повышают шанс найти верную. Проверяющий затем отделяет хороший кандидат от убедительной ошибки.
Проверяющий должен выбирать лучше, чем случайный отбор. Если все попытки повторяют одно заблуждение или проверяющий предпочитает уверенный стиль, вычисления только укрепят ошибку.
Где эффект обычно заметнее
- задачи с проверяемым ответом;
- математика и код;
- планирование с ограничениями;
- поиск доказательства или контрпримера;
- извлечение, которое можно сверить со схемой и источником;
- агентские действия с наблюдаемым результатом.
Для простого приветствия, свободного стиля или факта без доступа к источнику длинное рассуждение часто не окупается.
Бюджет не равен качеству
После некоторого уровня улучшение замедляется. Модель может начать ходить по кругу, менять верное решение или производить больше правдоподобного текста без новых доказательств.
Остановка строится по наблюдаемому сигналу:
- тесты прошли;
- найдено подтверждение в источнике;
- кандидаты сошлись, хотя само согласие не доказывает правильность;
- улучшение метрики прекратилось;
- исчерпаны шаги, время или деньги;
- дальнейшее действие требует человека.
Как измерять
Сравнивают несколько бюджетов на одном наборе задач. Для каждого записывают:
- долю корректных результатов;
- стоимость и задержку;
- число попыток и инструментальных вызовов;
- долю задач, где дополнительный бюджет изменил ответ;
- ошибки проверяющего;
- стоимость одного принятого результата.
График «качество против вычислений» показывает больше, чем один рекорд на тестовом наборе: видно, после какого бюджета улучшение становится небольшим.
Скрытое и видимое рассуждение
Длинная цепочка рассуждений в ответе не даёт надёжного отчёта о внутренних причинах решения. Это может быть удобное объяснение, реконструкция или просто ещё один сгенерированный текст.
Для аудита лучше сохранять проверяемые артефакты: запросы к инструментам, найденные документы, результаты тестов, кандидаты и критерий выбора. Они воспроизводимее свободного рассуждения.
Стоимость и задержка
Дополнительная попытка расходует токены, вычисления и иногда платные инструменты. Параллельный запуск сокращает время ожидания, но не общую работу. Последовательная проверка экономит ресурсы при ранней остановке, но увеличивает задержку.
Точные цены и лимиты принадлежат конкретной модели. Для продукта важна формула:
общая стоимость = все попытки + проверки + инструменты + повторы
Частые ошибки
- Считать длинный ответ более умным. Объём текста не измеряет корректность.
- Полагаться только на модель-проверяющего. Она может повторять ошибки кандидатов.
- Не ставить предел циклу. Агент способен повторять похожие действия.
- Измерять только лучший результат. Нужны средняя стоимость и распределение ошибок.
- Показывать пользователю всё внутреннее рассуждение. Это может раскрыть данные и не объясняет систему точно.
- Давать одинаковый бюджет всем запросам. Простые задачи оплачивают сложные без пользы.
Частые вопросы
Reasoning-модель и test-time compute — одно и то же?
Reasoning-модель — тип модели или продукта. Test-time compute — более общий принцип, который включает несколько попыток, поиск и внешнюю проверку.
Можно ли улучшить маленькую модель?
Иногда да, особенно при доступе к точному проверяющему. Поиск может помочь вывести решение из известных правил, но без источников он не восстановит произвольный неизвестный факт.
Как выбрать thinking budget?
По кривой качества, задержки и стоимости на собственном наборе. Универсального числа токенов нет.
Самопроверка всегда помогает?
Нет. Без нового сигнала модель может повторить прежнюю ошибку. Тест, источник или независимый кандидат обычно полезнее простого запроса «проверь себя».
Главное
Test-Time Compute превращает вычисления на запросе в управляемый ресурс. Его можно потратить на более длинную попытку, несколько решений, поиск или проверку. Выигрыш появляется там, где есть сложность и надёжный сигнал качества; без остановки и измерения дополнительное «размышление» легко становится просто более дорогим ответом.
