Sampling в LLM: как параметры генерации меняют ответ

Прямой ответ

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

Основные параметры:

• temperature. Масштабирует логиты перед softmax. Значения меньше 1 «заостряют» распределение (модель увереннее и предсказуемее), больше 1 — «сглаживают» (больше разнообразия и ошибок). При 0 фактически выбирается наиболее вероятный токен (жадное декодирование).
• top-k. Оставляет k наиболее вероятных токенов, остальные отбрасывает. Грубый фильтр: при k=40 хвост распределения не участвует.
• top-p (nucleus sampling). Оставляет минимальное множество токенов, суммарная вероятность которого ≥ p. Адаптивнее top-k: на уверенных шагах список короткий, на неоднозначных — длинный.
• min_p. Отсекает токены с вероятностью ниже доли от максимальной. Удобен как дополнительный фильтр на высоких температурах.
• repetition_penalty / presence_penalty / frequency_penalty. Штрафуют повторы. Полезны при зацикливании, но при злоупотреблении ломают естественные повторы (например, обязательные ключевые слова в JSON).
• seed. Фиксирует случайность; вместе с одинаковым входом даёт воспроизводимый результат там, где движок это гарантирует.

Ориентиры по задачам:

Практические правила:

1. Меняйте один параметр за раз. Температура и top-p влияют сходным образом; одновременная подкрутка обоих делает результат неинтерпретируемым.
2. Не компенсируйте промпт температурой. Если модель «путается», чаще виновата инструкция или контекст — см. system prompt.
3. Значения по умолчанию у разных движков разные. llama.cpp, vLLM и клиентские библиотеки задают разные дефолты; всегда указывайте параметры явно.

Практика: настройка и проверка

Явная передача параметров:

curl -s  \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5-7b-instruct",
    "messages": [{"role": "user", "content": "Верни JSON: {\"service\": ..., \"severity\": ...}"}],
    "temperature": 0.1,
    "top_p": 0.9,
    "max_tokens": 200,
    "seed": 42
  }'

Проверка стабильности формата. Прогоните один и тот же запрос 20 раз и посчитайте долю валидных ответов:

import json
ok = 0
for _ in range(20):
    r = call_llm(prompt)
    try:
        json.loads(r); ok += 1
    except json.JSONDecodeError:
        pass
print(f"валидных JSON: {ok}/20")

Если при temperature=0.1 валидность ниже 100 %, проблема не в случайности, а в инструкции или в модели: температуру повышать бессмысленно. Методика систематической оценки — в статье про eval для LLM-приложений.

Локальный запуск с явными параметрами:

./llama-cli -m model-q4_k_m.gguf \
  --temp 0.2 --top-p 0.9 --top-k 40 --repeat-penalty 1.05 \
  --seed 42 -p "Перечисли три признака утечки памяти."

Рекомендации:

1. Фиксируйте параметры в конфигурации, а не в коде. Их придётся подбирать; изменения должны быть видны в ревью.
2. Разделяйте профили по сценариям. Один набор параметров для извлечения данных, другой для свободной генерации. Универсальный профиль всегда хуже специализированных.
3. Помните о воспроизводимости. Даже при seed результат может отличаться между версиями движка и при разных размерах батча. Для регрессионных тестов сравнивайте не побайтово, а по ключевым признакам ответа.
4. Штрафы за повторы — крайняя мера. Сначала проверьте, не зацикливается ли модель из-за промпта или длинного однотипного контекста.

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

Практический сценарий: JSON «плывёт» в 12 % случаев

Контекст: сервис извлекает поля из тикетов в JSON; иногда ответ содержит пояснение до JSON или лишнюю запятую.

1. Диагностика. Параметры были temperature=0.7, top_p=0.95 — дефолт клиентской библиотеки, который никто не задавал явно. При таких значениях модель регулярно добавляет «отсебятину».
2. Изменение. Ставим temperature=0.1, top_p=0.9, добавляем явное требование «только JSON, без пояснений» в системный промпт и ограничение max_tokens.
3. Дополнительно. Включаем структурированный вывод, если движок поддерживает грамматическое ограничение (JSON schema / grammar). Это убирает класс ошибок синтаксиса независимо от температуры.
4. Проверка. На 200 тикетах доля валидных ответов растёт с 88 % до 100 %; при этом качество извлечения полей не изменилось, что проверено на размеченной выборке.
5. Профилактика. Параметры вынесены в конфигурацию, добавлен тест на валидность схемы для типовых входов; отклонение по доле валидных ответов поднимает алерт.

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

FAQ

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

Делает ли temperature=0 ответ полностью воспроизводимым? Не гарантирует. Жадное декодирование детерминировано математически, но реализация (порядок операций, параллелизм, версия ядра) может давать разные результаты. Для стабильности фиксируйте версию движка и сравнивайте ответы по смыслу, а не посимвольно.

Почему модель зацикливается на повторе фразы? Обычно из-за длинного однотипного контекста, слишком низкой температуры или неудачного промпта. Помогает сокращение контекста, небольшой штраф за повторы и переформулировка задачи; на локальном сервере стоит также проверить, не обрезается ли вход — см. llama-server.

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

Источники: nucleus sampling paper (arXiv), llama.cpp, vLLM docs — ссылки в шапке.