Температура (Temperature)

Температура (temperature) — это параметр, передаваемый во время инференса, который контролирует, насколько «случайным» или «детерминированным» является выбор токена LLM. Внутри модель вычисляет распределение вероятностей по каждому возможному следующему токену; температура масштабирует это распределение перед тем, как токен будет выбран (сэмплирован). Температура 0 (или очень близкая к ней) заставляет модель почти всегда выбирать токен с самой высокой вероятностью — детерминированный, сфокусированный, воспроизводимый вывод. Более высокие температуры (1.0 и выше) сглаживают распределение вероятностей, давая токенам с более низкой вероятностью реальный шанс быть выбранными, что даёт более разнообразный, творческий, иногда неожиданный вывод — но и более высокий риск бессвязности или галлюцинаций на экстремумах. Это одна из самых практически важных настроек для SaaS-разработчиков, потому что правильная температура полностью зависит от задачи. Структурированные, фактические задачи или задачи генерации кода (генерация SQL, извлечение данных, классификация, форматирование ответа API) требуют низкой температуры (от 0 до 0.3) ради согласованности и корректности — вы не хотите, чтобы ваш экстрактор JSON-схемы иногда проявлял творчество с именами полей. Творческие задачи (мозговой штурм маркетинговых текстов, генерация имён, написание историй) выигрывают от более высокой температуры (от 0.7 до 1.0+), чтобы избежать повторяющегося, шаблонного вывода. Конкретный пример: запрос к LLM «Дай слоган для кофейной подписки» при температуре 0 может надёжно возвращать «Свежая обжарка, доставка к вашей двери» каждый раз — безопасно, но однообразно для множества пользователей. Тот же промпт при температуре 0.9 может вернуть «Проснись для чуда» в одном вызове и «Ваш ежедневный ритуал, переосмысленный» в следующем — больше разнообразия, полезно при генерации нескольких вариантов или чтобы избежать шаблонности среди тысяч пользователей. Разработчикам стоит понимать, что температура — не волшебная ручка «творчества», повышающая качество, — она лишь контролирует случайность сэмплирования, поэтому её чрезмерное повышение в задачах, требующих точности (извлечение номера телефона из текста, генерация валидного кода), увеличивает частоту ошибок без какой-либо выгоды. Температуру часто комбинируют с сэмплированием top-p для более тонкого контроля, и большинство API рекомендуют настраивать что-то одно, а не оба параметра одновременно. Некоторые поставщики также предоставляют смежные параметры, о которых стоит знать наряду с температурой: `frequency_penalty` и `presence_penalty` (доступны в некоторых API) не дают модели повторять одни и те же слова или темы, что полезно для длинной генерации, которая иначе становится повторяющейся; а параметр `seed` (где поддерживается) может улучшить — хотя редко гарантировать — воспроизводимость между вызовами при фиксированной температуре, что полезно для тестирования и отладки. Разработчики, запускающие автоматизированные пайплайны оценки вывода модели, обычно фиксируют температуру на 0 именно для того, чтобы тестовые прогоны были сопоставимы между изменениями кода, ослабляя это ограничение только после того, как функция перешла из оценки в живую, ориентированную на пользователя генерацию, где некоторое разнообразие действительно желательно.