Один и тот же запрос к ИИ иногда даёт чёткий результат, а иногда — общие слова, странные идеи и лишние детали. Кажется, будто модель решила поимпровизировать. Иногда так и есть: на ответ влияют параметры генерации.
Самый известный параметр — температура. Но она не делает нейросеть умнее. Не исправит мутное ТЗ, не проверит факт и не спасёт плохой запрос. Это ручка вариативности: она меняет, насколько предсказуемо модель выбирает следующую фразу.
Температура меняет разброс ответов, а не их правдивость
При низкой температуре модель чаще выбирает самые ожидаемые продолжения. Ответы обычно становятся похожими друг на друга. При высокой — чаще появляются менее очевидные формулировки и ходы. Это бывает полезно в мозговом штурме и бывает вредно в коде, таблицах и извлечении данных.
Не путайте «меньше вариативности» с «больше точности». Если в исходном тексте нет срока задачи, модель не узнает его от понижения температуры. Она либо честно оставит поле пустым, либо начнёт гадать — и это зависит прежде всего от инструкции.
Почему один запрос даёт разные ответы даже без ручных настроек? Генерация не обязана быть полностью одинаковой. На результат также влияют версия модели, системные инструкции, подключённый поиск, память, файлы и инструменты. Поэтому сначала зафиксируйте условия, а уже потом измеряйте эффект параметра.
Сначала выясните, где настройка вообще доступна
Сравнивать сервисы по температуре нужно по трём простым критериям: есть ли ручная настройка в обычном интерфейсе, можно ли передать её через API и принимает ли её конкретная модель в выбранном режиме. Ползунок сам по себе не доказывает, что сервис выдаёт более качественный текст. Он показывает только гибкость управления.
В обычном чате ChatGPT не стоит рассчитывать на поле `temperature`: пользователь чаще выбирает режим работы, а не числовой параметр генерации. Режим скорости или глубины рассуждений — не прямая замена температуре. Поэтому совет «поставьте 0,7 в чате» часто просто неприменим.
В API OpenAI у поддерживающих моделей есть `temperature` и `top_p`. `temperature` управляет выбором вариантов напрямую, а `top_p` ограничивает выбор набором наиболее вероятных вариантов. В справке Responses API указаны доступные поля и ограничения. На старте меняйте только один из этих параметров: иначе непонятно, что именно сработало.
У Gemini, Claude, Yandex AI Studio, GigaChat и других платформ правила различаются по модели и API. Где-то параметры доступны, где-то рекомендуются значения по умолчанию, где-то отдельные режимы не принимают их вовсе. Не переносите цифру из одного сервиса в другой: одинаковое значение не обещает одинаковый разброс ответов.
Русский интерфейс, локальная оплата и документация могут быть удобны команде. Но это не критерий качества модели. Если рабочая задача — переносить данные в CRM, смотрите на структурированный вывод и проверку схемы. У Yandex AI Studio есть инструкция по генерации структурированных ответов, с которой можно повторить такой сценарий.
Расплывчатый запрос не спасёт даже нулевая температура
Редактор загружает расшифровку созвона и пишет: «Разбери встречу». Модель не знает, нужен пересказ, список задач или решения. Пять запусков могут дать пять похожих, но одинаково бесполезных ответов. Проблема тут не в случайности, а в постановке задачи.
Сразу укажите, что искать, как оформить результат и чего делать нельзя.
Из расшифровки встречи выдели только задачи, по которым назван исполнитель.
Верни таблицу из трёх колонок:
1. Исполнитель;
2. Действие;
3. Срок.
Если срок не прозвучал, напиши «не указан».
Не добавляй задачи от себя.
Не пересказывай обсуждение.Теперь редактор получает таблицу, где можно быстро проверить исполнителя, действие и срок. Если модель добавит несуществующую задачу, ошибка тоже будет видна сразу. Такой результат проще улучшать, чем абстрактное «разбери встречу».
Для текста защищайте факты, для идей задавайте разные углы
При редактировании письма или статьи ИИ может сделать фразы живее, а заодно добавить факт, которого не было в исходнике. Не надейтесь, что низкая температура решит этот риск. Лучше прямо запретите менять данные и попросите пометить спорные места.
Отредактируй текст без изменения фактов, дат, имён и цифр.
Убери канцелярит, повторы и длинные конструкции.
Сохрани спокойный деловой тон.
Не добавляй новые утверждения, примеры и выводы.
После текста перечисли места, которые можно понять по-разному.Для идей высокая вариативность иногда помогает, но не заменяет рамку. Маркетологу нужны не восемь вариантов «Вы забыли товар в корзине», а восемь разных причин вернуться. Перечислите стратегии — и модель будет искать в нужных направлениях.
Придумай 8 тем писем для пользователя, который добавил товар в корзину и не оформил заказ.
Каждая тема должна использовать отдельную стратегию:
выгода, удобство, ограниченный срок, социальное доказательство,
снятие сомнений, сценарий использования, подарок, напоминание.
Не используй слова «срочно», «последний шанс» и «уникальный».
После каждой темы в скобках укажи стратегию.Если варианты всё равно похожи, повышайте вариативность одним параметром и повторяйте задачу. Но в типичной рабочей ситуации сначала улучшайте структуру запроса: она задаёт разнообразие надёжнее, чем случайный разброс.
Для кода и JSON сначала закрепите формат
Когда ИИ переносит данные из писем в CRM, творческий подход не нужен. Нужны поля, допустимые значения и запрет на догадки. Температуру имеет смысл трогать только после того, как базовый сценарий уже выдаёт валидный результат.
Из текста письма извлеки данные в JSON.
Поля:
- name: имя отправителя или null;
- company: компания или null;
- request: краткая тема запроса;
- deadline: срок в формате YYYY-MM-DD или null.
Не придумывай значения, которых нет в письме.После запуска проверьте три вещи: JSON разбирается без ошибки, все обязательные поля на месте, новых сведений нет. Если JSON ломается, сначала уточните схему и пример формата. Понижение температуры без этой работы может лишь сделать одну и ту же ошибку более повторяемой.
Пять запусков покажут повторяемость без магических цифр
Универсального значения вроде «0,7 для текста» нет. Одна модель на нём будет спокойной, другая — заметно свободнее, третья не примет параметр. Проверяйте настройку на собственной задаче, а не на чужом скриншоте.
Возьмите один промпт и одинаковые входные данные. Отключите поиск, память, файлы и инструменты, если они не нужны. Запустите задачу пять раз со значениями по умолчанию. Затем измените один параметр и сделайте ещё пять запусков.
Считайте наблюдаемые нарушения: сломанный JSON, пропущенные поля, выдуманные детали и лишний текст. Это не проверка общей точности модели — для неё нужен эталон и большая выборка. Зато такой мини-тест честно покажет, стала ли задача стабильнее.
Сегодня возьмите запрос, который регулярно раздражает команду. Добавьте формат, запреты и критерий готового ответа. Только если пять запусков всё ещё заметно расходятся, переходите к температуре и меняйте один параметр за раз.
Статья помогла?
