Гайд · TNWS AI

Как добавить ползунок temperature к AI-чату через additional_inputs в Gradio

4 мин—

Связываем Slider и функцию чат-бота без ошибки порядка аргументов; проверяем значение до вызова нейросети.

Задача и применимость

Русскоязычный вопрос: «как добавить настройку temperature в чат gradio additional_inputs». Работает в документированном ChatInterface Gradio, когда нейросеть или её сервер принимает регулируемый temperature. Конкретный диапазон значений зависит от выбранного модельного API: здесь UI ограничен учебным интервалом 0–1, который надо согласовать с upstream до интеграции. Источник интерфейса проверен 20 сентября 2026 года.

Что подтверждено производителем

Gradio передаёт значения additional_inputs в fn после первых двух аргументов message и history, в порядке перечисления компонентов. Если inputs не размещены заранее в Blocks, по документации они отображаются в Accordion под чатом. Значение ползунка само по себе не меняет параметры сервера, пока вы не передали его в вызов модели.

Порядок действий

  1. Создайте gr.Slider с понятной подписью и стартовым значением.
  2. Определите функцию с третьим аргументом temperature.
  3. При отладке верните полученное число вместе с сообщением без реального запроса к модели.
  4. После подтверждения порядка аргументов передайте число в поле совместимого модельного API.
  5. Проверяйте контрольные тесты на нескольких значениях, не требуя одинакового текста от стохастической модели.

Готовый шаблон

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

import gradio as gr

def inspect(message, history, temperature):
    if not 0 <= temperature <= 1:
        raise gr.Error("Значение вне разрешённого интервала")
    return f"Вопрос: {message}; temperature: {temperature:.1f}"

slider = gr.Slider(minimum=0, maximum=1, step=0.1,
                   value=0.2, label="Temperature")
gr.ChatInterface(inspect, additional_inputs=[slider],
                 additional_inputs_accordion="Настройки генерации").launch(server_name="127.0.0.1")

Вход и ожидаемый результат

Выберите на ползунке 0.7 и задайте «Назови два способа проверить ответ». Ожидается диагностическая строка с temperature: 0.7; содержание двух способов этот учебный код ещё не генерирует. На интеграционном этапе логируйте отправленное числовое поле тестового API без чувствительного текста.

Проверка контракта

Порядок аргументов — частый источник незаметных ошибок. Если позднее появится второй компонент, например max_tokens, сигнатура должна стать fn(message, history, temperature, max_tokens). Перестановка мест без изменения функции может отправить температуру в ограничение длины и вызвать ошибку сервера или бессмысленный ответ. Зафиксируйте контракт тестом на исходные значения UI. Используйте имена аргументов и точные схемы upstream, не считайте одинаковыми параметры с похожими названиями у разных провайдеров.

Работа с данными пользователя

Изменение temperature влияет на распределение возможных ответов модели, но не исправляет отсутствие фактов. Для RAG или справки службы поддержки сравнительный тест должен измерять не «красоту», а соблюдение источника, длину и долю отказов на неизвестные вопросы. Сохраните одинаковый набор запросов и версию модели, затем сравните поведение при двух значениях. Не обещайте, что нулевое значение всегда даст идентичный текст: реализация и режим вычислений имеют свои нюансы.

Что проверить перед развёртыванием

Структура UI не является валидацией серверного API. Даже если Slider не предлагает отрицательное значение, клиентский вызов endpoint может передать другое число, если endpoint опубликован. Повторно валидируйте данные в функции перед отправкой модели, проверяйте авторизацию и лимит запросов на серверной стороне. Для внутренних демо не показывайте в описании реальные ключи или URL внешней сети. Значение temperature является пользовательским вводом, а не доверенным системным параметром.

Готовый шаблон системной инструкции для downstream: «Отвечай на вопрос только по приведённому фрагменту; при нехватке данных напиши, что источник этого не подтверждает». Это отдельный механизм контроля фактов, не эквивалент настройке температуры. Для приёмки сохраните одну запись о том, какие поля действительно ушли к модели; затем удалите запись с пользовательским содержимым, если политика хранения этого требует.

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

Критерии приёмки

  1. При выборе 0.7 callback действительно получает 0.7.
  2. Дополнительный input не занимает место message либо history.
  3. Интеграция передаёт значение в поддерживаемое поле API.

Типичные ошибки и чего не делать

  • Не ожидать изменения модели от одного движения Slider.
  • Не путать порядок входных компонентов.
  • Не считать frontend ограничением безопасности endpoint.

FAQ

Куда попадает Slider?

Третьим аргументом функции после message и history.

Где он показан?

По умолчанию в блоке дополнительных входов.

Нужна ли проверка диапазона?

Да, особенно при доступном API endpoint.

Официальные источники

Частые вопросы

Куда попадает Slider?

Третьим аргументом функции после message и history.

Где он показан?

По умолчанию в блоке дополнительных входов.

Нужна ли проверка диапазона?

Да, особенно при доступном API endpoint.

Читайте также

Комментарии

Пока тихо. Скажите первое слово