Как нейросеть каждый раз создает новый ответ
Нейросеть не хранит готовые ответы на вопросы. Каждый запрос запускает процесс порождения ответа с нуля через последовательный выбор токенов из распределения вероятностей. Даже при полном текстовом совпадении вопроса результат может отличаться - не в отдельных словах, а полностью, от первого до последнего токена. Что такое токен и почему он не равен слову, разобрано в материале Токены в нейросети: в чём модель считает текст.
Понятие “тот же запрос” требует уточнения. В диалоговых системах к тексту вопроса автоматически добавляются контекст пользователя, его настройки и результаты поиска. В API запрос включает системные инструкции, описания инструментов, подставленные даты и время. Любое, даже минимальное расхождение создает другой входной вектор и приводит к другому распределению вероятностей.
Инженерная проблема проявляется в нестабильных тестах: сегодня ответ совпадает с эталоном, завтра отличается, хотя ни запрос, ни эталон не менялись. Разберем подробно механизмы, лежащие в основе этого поведения, и способы обеспечения повторяемости там, где она критически важна.
Авторегрессионный механизм: эффект домино в генерации
На каждом шаге генерации модель создаёт распределение вероятностей по всему словарю токенов. Выбор конкретного токена из этого распределения осуществляет отдельная процедура, не входящая в основные веса модели. Эта процедура реализует два принципиально разных подхода:
- Случайный выбор (сэмплирование) - токен выбирается с вероятностью, пропорциональной его весу в распределении
- Детерминированный выбор - всегда выбирается токен с наибольшей вероятностью
Процесс генерации является авторегрессионным: выбранный токен добавляется к входным данным, и следующий шаг вычислений выполняется уже с учетом этого нового токена. Такая архитектура создает эффект домино: даже минимальное расхождение в начале ответа полностью меняет его дальнейшее развитие.
Рассмотрим этот механизм на примере. Допустим, на первом шаге вместо ожидаемого токена “компиляция” модель выбрала токен “интерпретация”. Второй шаг генерации будет вычисляться уже не для последовательности “компиляция”, а для “интерпретация”. Третий шаг - для “интерпретация кода” вместо “компиляция кода”. Каждое последующее слово будет зависеть от всех предыдущих выборов, и даже небольшое начальное расхождение приведет к совершенно другому результату через несколько токенов.
Параметры генерации: что они действительно контролируют
Температура - ключевой параметр, определяющий форму распределения вероятностей. Она действует как делитель логитов перед применением функции softmax, влияя на вероятности следующим образом:
- Значение меньше единицы концентрирует вероятность вокруг наиболее вероятных токенов
- Значение больше единицы выравнивает распределение, делая выбор более разнообразным
- Единица сохраняет исходное распределение вероятностей
Особого внимания требует значение ноль. Формально оно недопустимо в формуле температуры (это деление на ноль), но используется как условное обозначение жадного выбора. Реализация обработки нуля зависит от конкретной системы:
- В некоторых серверах ноль обрабатывается как особый случай, включающий жадный выбор
- В других системах ноль отвергается как недопустимое значение
- Жадный выбор может включаться отдельным параметром, не связанным с температурой
Нулевая температура принимается не везде - у части моделей запрос с любым нестандартным значением температуры отклоняется с ошибкой, а на некоторых серверах ноль отвергается как недопустимое значение, и жадный выбор включается отдельным параметром.
Другие важные параметры генерации включают:
- top-k, который ограничивает выбор k наиболее вероятными токенами
- top-p (ядерное сэмплирование), ограничивающий выбор минимальным набором токенов, суммарная вероятность которых достигает заданного порога
В обоих случаях вероятности оставшихся токенов перенормируются для сохранения общей суммы вероятностей. Доступность этих параметров зависит от конкретного поставщика услуг. Некоторые модели отклоняют запросы с нестандартными значениями температуры, top-p или top-k, возвращая ошибку клиенту.
Следует понимать, что все эти параметры влияют на форму распределения и набор доступных для выбора токенов, но не отменяют сам процесс выбора. Одни и те же значения параметров могут вести себя по-разному на разных серверах из-за различий в порядке их применения и особенностей реализации конкретных систем.
Значение температуры по умолчанию у разных поставщиков и локальных серверов разное, а там, где жадный выбор задается отдельным параметром, режим по умолчанию от температуры не зависит вовсе. Поэтому незаданная температура сама по себе не означает ни жадного, ни случайного выбора: и значение, и режим по умолчанию смотрят в описании параметров запроса в документации своего поставщика или в справке своего сервера вывода.
Низкая температура уменьшает разброс ответов, а не число ошибок, и верным ответ не делает: откуда берутся выдумки и почему температура их не убирает, разобрано в материале Почему модель выдумывает и что с этим делать.
Почему даже жадный выбор не гарантирует идентичных ответов
Жадный выбор всегда отдает предпочтение самому вероятному токену на каждом шаге генерации. Однако он не гарантирует получения самого вероятного ответа целиком. Вероятность ответа определяется произведением вероятностей всех его токенов, и последовательность с большим произведением может начинаться с токена, который на первом шаге был менее вероятен.
Основные источники расхождений даже при использовании жадного выбора включают:
- Неассоциативность операций с плавающей точкой - результат вычислений зависит от порядка выполнения операций
- Размер пакета запросов - влияет на порядок операций в вычислительных библиотеках
- Нагрузка на сервер - меняет размер пакета и, соответственно, порядок вычислений
- Маршрутизация запросов - попадание на разные реплики с потенциально разным оборудованием и версиями библиотек
Закрепленная версия модели необходима: она убирает смену весов и остается условием воспроизводимого поведения на контрольной выборке и для модели, поднятой у себя. Как незакрепленная модель меняет поведение без объявления, разобрано в материале о промпте как коде. Но фиксирует она веса, а не окружение исполнения, и побитового совпадения текста у стороннего поставщика сама не дает. При неизменном идентификаторе модели могут обновляться:
- Логика маршрутизации запросов между серверами
- Алгоритмы выбора токенов на уровне сервиса
- Конфигурация серверов и используемых библиотек
В системах, где ответ содержит метаданные о конфигурации сервера, их рекомендуется сохранять в журнале вместе с ответом. Это позволяет отслеживать изменения в среде исполнения, отделяя их от изменений в самом запросе.
Практические стратегии обеспечения повторяемости
Сохраненный ответ — решение для продукта, где один и тот же результат обязан вернуться повторно, и для тестов обвязки вокруг модели. Тест качества ответа он не чинит: тест, которому подставили запись, саму модель уже не проверяет. Есть и цена: кэш закрепляет неудачный ответ так же, как удачный, и ошибка становится повторяемой.
Там, где модель все же вызывают повторно, следует проверять не текст ответа, а его свойства и характеристики.
Единственный надежный способ гарантировать идентичный ответ от стороннего поставщика - полностью отказаться от повторных вызовов модели. Вместо этого ответ следует сохранять на своей стороне по составному ключу, включающему все параметры запроса:
- Идентификатор модели и ее версии
- Все параметры генерации (температура, top-k, top-p и т.д.)
- Полный текст запроса со всеми системными инструкциями
- Предел длины ответа
- Стоп-последовательности
- Описания инструментов и функций
- Схему вывода и формат ответа
Пропуск любого поля в ключе может привести к ситуации, когда фактически разные запросы будут возвращать один и тот же кэшированный ответ, что создаст иллюзию повторяемости при фактической нестабильности системы.
Необходимо четко различать два принципиально разных механизма кэширования:
- Кэш префикса у поставщика - сохраняет внутреннее состояние по совпавшему началу входа, но ответ при этом генерируется заново каждый раз
- Кэш полных ответов на своей стороне - обеспечивает полную повторяемость результатов
Почему установка temperature 0 не решает проблему
Первое, что обычно пробуют для устранения разброса ответов - установить температуру в ноль. Там, где нулевая температура принимается и действительно включает жадный выбор, разброс уменьшается, тесты начинают проходить - но через некоторое время снова падают без единой правки в запросе или тестах.
Основные ограничения этого подхода включают:
- Нулевая температура принимается не везде - у части моделей запрос с любым нестандартным значением температуры отклоняется с ошибкой, а на некоторых серверах ноль отвергается как недопустимое значение, и жадный выбор включается отдельным параметром
- Даже в системах, где ноль обрабатывается как жадный выбор, сохраняются численные расхождения из-за:
- Различий в порядке вычислений при разной нагрузке на сервер
- Попадания запросов на разные реплики с разным оборудованием
- Особенностей реализации вычислительных библиотек и их версий
- Параметр seed при жадном выборе не имеет смысла, так как случайные числа в этом режиме не используются
- Добавление инструкции “отвечай всегда одинаково” влияет на распределение вероятностей, но не меняет процедуру выбора токенов
Таким образом, нулевая температура там, где поставщик её принимает и где она действительно включает жадный выбор, убирает только один источник вариативности - случайность выбора токена, но не затрагивает численные расхождения под нагрузкой и смену окружения у поставщика. Этот подход может уменьшить разброс ответов, но не обеспечивает полной повторяемости и стабильности системы.
Позиция редакции
Позиция редакции неверна в одном случае: когда модель запущена у себя на неизменном оборудовании и неизменной сборке библиотек, обрабатывает запросы по одному, с неизменным числом потоков, без повторного использования состояния между запросами и выбирает токены жадно. В таких строго контролируемых условиях побитовая повторяемость достижима, и требовать её от системы вполне обоснованно.
Во всех остальных случаях повторяемость следует строить вокруг модели, а не требовать от неё невозможного. Сохранённый ответ подходит для продукта, где требуется возвращать один и тот же результат повторно, и для тестов обвязки вокруг модели, но не годится для проверки качества самой модели. При необходимости повторных вызовов модели следует проверять свойства и характеристики ответа, а не его точный текст.
Закрепление версии модели необходимо для обеспечения повторяемости, но в условиях стороннего сервиса его недостаточно. Нулевая температура может уменьшить разброс ответов, но не гарантирует полной повторяемости. Она убирает только один источник вариативности, оставляя другие нетронутыми.