Температура, top p и стоп‑токены для реальных задач

Почему один пресет постоянно подводит

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

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

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

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

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

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

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

Что действительно меняют эти настройки

Люди часто относятся к temperature, top p и стоп‑токенам как к одной большой кнопке «креативности». Это не одно и то же.

Temperature контролирует вариативность. Низкая температура держит модель близко к наиболее безопасному следующему слову, поэтому ответы кажутся устойчивыми и повторяемыми. Более высокая температура даёт больше свободы, что полезно для черновиков, но может привести к странным формулировкам, лишним деталям или сдвигу тона.

Top p управляет, насколько большой пул слов рассматривается перед выбором. Низкий top p ограничивает пул наиболее вероятными вариантами. Высокий top p оставляет в игре больше опций. По звучанию это похоже на эффект от temperature, но механизм срабатывает раньше в процессе выбора.

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

Проще мыслить так:

• Temperature меняет, насколько смелым будет следующий выбор.
• Top p меняет, сколько возможных вариантов остаётся в пуле.
• Стоп‑токены решают, где ответ должен закончиться.

Последний параметр важнее, чем многие команды предполагают. Стоп‑токены особенно полезны для JSON, CSV, извлечения полей, форматов чатов с метками или любой задачи, где лишний текст ломает дальнейшую обработку. Маркер вроде END или Customer: может остановить модель до того, как она уйдёт в шаблонные фразы.

Если ответ службы поддержки начинает болтать, стоп‑токен может помочь быстрее, чем понижение temperature. Если извлечение остаётся точным, но продолжает менять формулировки, вероятно, важнее скорректировать temperature, а не top p. Эти параметры решают разные проблемы — тестируйте их отдельно.

Не меняйте temperature и top p одновременно на первом этапе. Если двигать оба, вы потеряете след того, что именно повлияло на результат. Меняйте один параметр, прогоняйте те же примеры и смотрите, что именно улучшилось.

Как настраивать задачи по извлечению

Извлечение требует меньше креативности и больше дисциплины. Если модель вытаскивает имена, даты, суммы или теги, начните с низкой temperature, обычно в диапазоне 0–0.2. Задайте строгий формат, фиксированные имена полей и чёткое правило для отсутствующих значений.

Простая схема обычно лучше хитрой подсказки. Если нужен JSON, перечислите каждое поле в том порядке, в котором вы его ожидаете, и скажите модели возвращать null или пустую строку, когда в источнике нет ответа. Это одно правило сильно сокращает выдуманные значения — частую причину неудач при извлечении.

Представьте консультанта стартапа, который собирает заметки и извлекает company_name, team_size, current_stack, budget_range и urgency. Если эти поля возвращаются в точности каждый раз, следующий шаг простой. Если модель начинает переименовывать поля или добавлять комментарии, весь пайплайн становится грязным.

Top p здесь обычно требует лёгкой руки. Держите его консервативным или оставьте по умолчанию, пока сначала тестируете temperature и формат подсказки. Это даст вам ясное понимание, что именно вызвало результат.

Стоп‑токены очень помогают со структурированным выводом. Поставьте стоп‑токен прямо после последнего поля или закрывающей скобки, чтобы модель не дрейфовала в лишний текст. Это предотвращает типичную ситуацию, когда валидный JSON объект дополняется вежливой фразой, которая ломает парсер.

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

• отсутствующие значения, которые должны быть null
• лишний текст до или после полезной нагрузки
• сломанные кавычки или скобки в JSON
• строки CSV, разбитые на несколько строк
• поля, которые модель придумала вместо извлечения

Если JSON продолжает ломаться, подсказка обычно слишком вольная. Ужесточите схему, ещё больше понизьте temperature и сделайте стоп‑токен строже. Для извлечения скучный вывод — обычно правильный вывод.

Как настраивать черновики

Черновики требуют больше простора. Если temperature слишком низкая, текст быстро становится деревянным. Небольшое повышение даёт модели пространство для вариаций в формулировках и синтаксисе, сохраняя смысл.

Для большинства черновиков начните примерно с 0.5–0.7. Этот диапазон часто подходит для обновлений продукта, писем для аутрича, коротких статей и копий для лендингов. Если текст всё ещё звучит плоско, поднимите немного. Если модель начинает добавлять неподтверждённые утверждения, понизьте.

Top p помогает, когда черновик начинает «уходить в сторону». Среднее значение, часто 0.8–0.95, даёт достаточно гибкости, не позволяя блуждать слишком далеко. Если и temperature, и top p высоки, черновик может отклоняться, повторяться или менять тон посередине.

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

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

Простой пример: если нужен короткий апдейт основателя для инвесторов, тон должен быть кратким, тёплым и прямым. Пресет с temperature ≈ 0.6, top p ≈ 0.9 и без стоп‑токенов обычно даст лучший старт, чем один глобальный пресет, общий для извлечения и поддержки. Первый черновик всё ещё требует ревью, но он начинается с гораздо лучшей точки.

Как настраивать ответы поддержки

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

Умеренные настройки обычно работают лучше. Во многих случаях temperature ≈ 0.4–0.7 даёт спокойные и естественные ответы без превращения каждого ответа в эксперимент со стилем. Top p может оставаться относительно открытым, но не экстремальным. И снова — меняйте по одному параметру и наблюдайте эффект.

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

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

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

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

Как настраивать параметры по одному изменению

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

Начните с одной узкой задачи, а не целого рабочего процесса. Выберите, например, извлечение номеров счетов из писем или написание первых ответов на вопросы о выставлении счетов. Потом определите одну метрику успеха. Для извлечения используйте точное совпадение. Для черновиков считайте, сколько правок человек делает перед отправкой.

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

Простой цикл работает хорошо:

• зафиксируйте задачу, подсказку и примеры входа
• прогоните базовый пресет несколько раз
• измените только одну настройку
• сравните качество вывода и время правки
• оставьте победителя и назовите его по задаче

Последний шаг легко пропустить, но он важен. «Support reply - billing v1» лучше, чем «default low temp». Ясные названия делают пресеты переиспользуемыми.

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

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

Простой пример с тремя пресетами

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

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

Они исправили это, рассматривая настройки как контролеры задач, а не как личность модели.

Для извлечения они использовали строгий пресет: temperature 0.0–0.2, top p 0.1–0.3 и стоп‑токен вроде END_JSON или явной границы схемы. Это сделало вывод стабильным и сократило битые импорты.

Для вступлений в блоги они ослабили настройки: temperature 0.6–0.8, top p 0.8–0.95 и иногда стоп‑токен вроде ##, чтобы модель не уходила в следующий раздел. Черновики всё ещё требовали правки, но выглядели менее жестко и правились быстрее.

Поддержка оказалась посередине: temperature ~0.3–0.5, top p ~0.5–0.8 и стоп‑токен перед внутренними заметками или блоками подписи. Это давало агентам ответы спокойные, чёткие и предсказуемые, без ощущения шаблонности.

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

Один пресет казался проще. Три пресета сэкономили время.

Ошибки, которые создают грязный вывод

Большинство «грязного» вывода имеет простую причину: настройки не подходят к задаче.

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

Top p создаёт похожие проблемы. Команды открывают его широко, получают один живой ответ и думают, что пресет стал лучше. Иногда так и есть. Иногда модель просто заблудилась, и это выглядело удачно однажды. Для извлечения и поддержки такой дрейф проявляется в лишних деталях, изменённых формулировках или ответах, которые не соответствуют задаче.

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

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

Правки подсказок создают свои проблемы. Пресет, который работал неделю назад, может сломаться, если вы добавите примеры, смените формат вывода или попросите более дружелюбный тон. Даже небольшие изменения в подсказке меняют, как модель реагирует на temperature и top p.

Несколько полезных привычек удерживают ситуацию под контролем:

• менять только один параметр за раз
• тестировать на одном и том же наборе примеров
• смотреть, где вывод начинает дрейфовать или обрезаться
• повторно тестировать после каждой правки подсказки

Когда вывод становится грязным, причина обычно проста: подсказка стала свободной, настройки расширены или стоп‑токен сработал слишком рано.

Быстрая проверка перед выпуском

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

Смотрите на несколько признаков отказа: обрыв ответа, повторяющиеся строки и списки, которые обрываются на полуслове. Эти проблемы часто возникают, когда max tokens, стоп‑токены и параметры сэмплинга не согласованы с задачей. Ответ поддержки, который обрывается после «Thanks for reaching out», очевиден. Результат извлечения, который тихо теряет последнее поле, хуже, потому что люди могут не заметить.

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

Короткий проход ревью обычно ловит большинство проблем:

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

Держите небольшой тест‑набор и используйте его при каждой смене пресета. 10–20 примеров достаточно для старта. Включайте случаи, которые уже проваливались, а не только те, что выглядели хорошо. Эта привычка экономит время, потому что вы сопоставляете реальные выводы, а не спорите по памяти.

Если ваша команда занимается поддержкой, созданием контента и извлечением данных, держите отдельные тест‑наборы для каждой работы. Одна общая проверка «всё выглядит хорошо» слишком слаба.

Следующие шаги для вашей команды

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

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

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

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

Также полезно записать причину существования пресета. «Low temperature for invoice extraction because extra wording breaks parsing» гораздо полезнее пустого поля конфигурации.

Если ваша команда настраивает пресеты для продуктовой работы, поддержки или автоматизации, Oleg Sotnikov at oleg.is помогает компаниям протестировать эти настройки на реальных рабочих процессах. Внешний обзор часто быстрее, чем недели споров о ползунках в чате.