Температура модели: на что влияет и когда менять

Температура не делает модель «креативнее» — она меняет резкость распределения вероятностей при выборе следующего токена. Ниже температура — чаще берётся самый вероятный вариант, выше — чаще что-то из хвоста. Из этого следует всё практическое: на извлечении данных низкая температура полезна, на генерации текстов — средняя, а крайние значения портят результат в обе стороны. И следует главное ограничение: настройкой не чинятся фактические ошибки, потому что параметр влияет на выбор из вариантов, а не на знания. Разбираем, что делают температура, top_p и seed, и в каком порядке их трогать.

Что происходит при генерации

Без этого механизм непонятен, а с ним всё становится очевидным.

На каждом шаге модель считает вероятности для всех возможных следующих токенов. Получается распределение: у одних вариантов вероятность высокая, у большинства — близкая к нулю. Дальше из этого распределения надо выбрать один токен.

Температура меняет форму распределения перед выбором. Низкая делает его резким: разрыв между лидером и остальными увеличивается, и почти всегда берётся первый. Высокая сглаживает: у маловероятных вариантов появляется реальный шанс.

Отсюда сразу два вывода, которые экономят много времени.

Первый: температура не добавляет модели вариантов. Она перераспределяет шансы между теми, что уже есть. Если нужного варианта в распределении нет, никакая температура его не создаст.

Второй: высокая температура — это не «фантазия», а больше шума. На длинном тексте это выглядит как разнообразие, на извлечении данных — как ошибки в номерах.

Что ставить под задачу

Без конкретных чисел, потому что диапазоны различаются между моделями, а логика — нет.

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

Средняя. Тексты, ответы помощника, переформулирование. Там, где правильных ответов много и однообразие само по себе плохо.

Высокая. Генерация вариантов для перебора: заголовки, идеи, формулировки, из которых человек выберет. Единственный сценарий, где шум полезен.

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

Другие параметры

Коротко о том, что стоит рядом и часто крутится заодно.

top_p. Отсекает хвост: из распределения оставляются только варианты, набирающие в сумме заданную долю вероятности, и выбор идёт из них. Работает похоже на температуру по эффекту, но иначе по механизму. Менять оба сразу не стоит — потом не разберёте, что подействовало.

max_tokens. Предел длины ответа. Не влияет на стиль, зато прямо влияет на счёт: это единственный рычаг на выходную часть расхода — почему выход бывает дороже входа.

seed. Фиксирует случайность выбора. Полезен при отладке, чтобы сравнивать изменения промпта, а не шум. Полной воспроизводимости не гарантирует.

stop. Последовательности, на которых генерация обрывается. Иногда решает проблему «модель дописывает лишнее» лучше, чем инструкции в промпте.

Поддержка параметров различается между моделями и протоколами. В нашем каталоге у большинства позиций возможности помечены unknown — это означает «не проверяли», а не «не работает». Как читать эти поля — в разборе полей ответа GET /v1/models.

Почему одинаковых ответов всё равно не будет

Ожидание, из-за которого возникает больше всего разочарования.

Нулевая или близкая к нулю температура делает выбор токена почти детерминированным. Но «почти» здесь существенное: на итог влияет ещё несколько обстоятельств, не зависящих от вашего запроса, — от особенностей вычислений до того, что за вашим маршрутом может стоять не одна и та же конфигурация от запроса к запросу.

Мы разбирали это отдельно: почему модель даёт разные ответы на один запрос. Практический вывод оттуда простой — если вашему коду нужна стабильность, её надо обеспечивать проверкой результата, а не настройкой генерации.

В каком порядке трогать

Порядок действий, который экономит больше всего времени.

1. Сначала промпт. Восемь из десяти проблем, которые пытаются решить температурой, решаются одним примером в задании — что работает в промптах.
2. Потом формат. Если ломается структура ответа, нужен строгий вывод, а не низкая температура.
3. Потом один параметр. Меняйте что-то одно и смотрите на двадцати запросах, а не на одном.
4. Потом модель. Если после трёх шагов результат не устраивает, дело не в настройке.

Обратный порядок — сначала крутить параметры — встречается чаще и почти всегда стоит дороже: время уходит, а причина остаётся.

Чего температура не чинит

Список, из-за незнания которого параметр крутят напрасно.

Фактические ошибки. Модель не знает того, чего не знает. Низкая температура сделает выдумку стабильной, а не верной. Лечится данными в контексте или поиском по своей базе.

Несоблюдение формата. Лечится строгим выводом или проверкой в вашем коде.

Игнорирование инструкций. Лечится переписыванием системного промпта, а не настройкой.

Слишком длинные ответы. Лечится max_tokens и прямой просьбой о краткости.

Медленные ответы. Температура на скорость не влияет. На ощущение скорости влияет потоковая передача.

Как проверять изменения

Короткая методика, без которой любые правки — это гадание.

Соберите два-три десятка реальных запросов с известными правильными ответами. Прогоните на текущей настройке, зафиксируйте долю верных. Поменяйте один параметр, прогоните ту же выборку, сравните.

Двадцать запросов — минимум, при котором разницу видно. На трёх запросах вы увидите шум и примете его за улучшение.

И держите выборку: она пригодится при смене модели, обновлении промпта и через полгода, когда захочется понять, стало лучше или хуже.

Почему настройка кажется работающей

Небольшое наблюдение про то, как легко здесь себя обмануть.

Модель отвечает по-разному на один и тот же запрос сама по себе. Значит любые два прогона различаются, независимо от того, меняли вы что-нибудь или нет. И если после смены параметра ответ стал лучше, это может быть эффектом параметра, а может быть обычным разбросом.

Отсюда механика самообмана, знакомая каждому: поменяли температуру, посмотрели один ответ, увидели улучшение, зафиксировали настройку. Через неделю проблема вернулась, потому что её и не решали.

Три способа не попадаться:

Смотрите на выборку, а не на один ответ. Двадцать запросов — минимум, при котором разброс усредняется.

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

Меняйте один параметр за раз. При двух одновременных изменениях причина улучшения неизвестна, а значит невоспроизводима.

Тот же принцип касается и промптов, и смены моделей — просто с параметрами генерации ловушка срабатывает чаще всего, потому что менять их проще всего.

Чего мы не утверждаем

Не называем конкретных значений. Шкалы и поведение различаются между моделями; переносить настройку без перепроверки нельзя.

Не сравниваем модели по управляемости. Своих замеров мы не делали.

Поддержка параметров не гарантирована. У большинства позиций каталога соответствующие возможности помечены unknown; проверять нужно на своей задаче.

Ещё одна привычка, которая экономит время: записывайте настройки рядом с результатами. Через месяц вопрос «а на чём мы получили тот хороший прогон» возникает обязательно, и без записи ответа на него нет. Параметры генерации — такая же часть конфигурации сервиса, как выбор модели, и относиться к ним стоит так же.

Что держать в голове

Температура управляет резкостью выбора следующего токена, а не «креативностью». Низкая полезна там, где ответ один; средняя — где ответов много; крайние значения вредят в обе стороны.

И главное ограничение: параметр влияет на выбор из вариантов, а не на знания. Если модель ошибается в фактах, крутить настройку бессмысленно — нужны данные. Прогоны с записанными настройками и выборкой запросов — это, по сути, тот же самый инструмент, что и тесты в коде: он отвечает на вопрос, стало лучше или показалось.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Прогнать свою выборку на нескольких моделях по одному ключу: keydealer.ru/login.