Почему нейросеть даёт разные ответы на один запрос

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

Откуда берётся разброс

Четыре источника, от самого управляемого к наименее.

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

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

Состав пакета на стороне провайдера. Запросы обрабатываются группами, и то, с какими соседями попал ваш, влияет на вычисления. Вы на это не влияете и даже не видите.

Версия модели. За одним публичным именем может стоять обновляющаяся версия. Ответ, полученный месяц назад, воспроизвести нельзя, если модель с тех пор обновилась.

Первый пункт снимается настройкой. Остальные три — нет, и это надо принять как данность, а не искать обходной путь.

Почему temperature = 0 не даёт гарантии

Самое частое заблуждение стоит разобрать отдельно.

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

Дальше работает накопление. Один изменившийся токен меняет контекст для всех последующих, и ответы расходятся тем сильнее, чем длиннее генерация. Первое предложение совпадёт, третий абзац может отличаться заметно.

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

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

Когда разброс — это плохо, а когда нет

Разделение, от которого зависит, стоит ли вообще с этим бороться.

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

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

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

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

Что делать вместо борьбы с разбросом

Пять приёмов, которые работают.

1. Задавайте формат жёстко и проверяйте его программно. Не «верни JSON», а схема плюс валидация на вашей стороне. Не прошло проверку — повторите запрос. Это надёжнее любой температуры.
2. Сокращайте генерируемое. Чем короче ответ, тем меньше места для расхождения. Просьба ответить одним словом почти устраняет проблему — заодно удешевляя запрос.
3. Разбивайте задачу. Три коротких шага с проверкой после каждого дают более стабильный результат, чем один длинный.
4. Храните результат, а не запрос. Если ответ понадобится предъявить, сохраните его. Попытка получить тот же ответ заново — заведомо ненадёжная стратегия.
5. Фиксируйте версию модели там, где это возможно. Публичное имя может указывать на обновляющуюся версию; конкретный идентификатор снимает хотя бы этот источник расхождений.

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

Как измерить разброс на своей задаче

Раз универсальных цифр нет, полезно уметь получить свои. Замер занимает полчаса и даёт больше, чем любые рассуждения о температуре.

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

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

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

Повторите на длинном ответе. Разброс растёт с длиной, и картина на ответе в двадцать слов не переносится на ответ в тысячу.

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

Зачем вообще нужна случайность

Логичный вопрос: если разброс мешает, почему бы не сделать модели детерминированными по умолчанию.

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

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

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

Как это связано с расходом

Небольшое, но практичное замечание.

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

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

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

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

Не даём точных значений параметров. Оптимальная температура зависит от задачи; универсального числа не существует.

Не описываем поведение конкретных вендоров в деталях. Как именно группируются запросы и обновляются версии, поставщики обычно не раскрывают.

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

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

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

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

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