Оригинал: https://timofei-ermolaev.ru/courses/open-webui/povsednevnaya-rabota/parametry-i-rassuzhdayushchie-modeli/ # Параметры Open WebUI: настройка ответа и рассуждений Разбираем системную инструкцию, temperature, лимит ответа и рассуждения в Open WebUI. Меняем одну поддерживаемую настройку и проверяем результат. [![Тимофей Ермолаев](https://timofei-ermolaev.ru/_astro/timofei-ermolaev-portrait.s0mCFw-J_Z1x8STQ.webp)]() [Тимофей Ермолаев]() Директор по информационным технологиям (CIO) **Опубликовано** 22 октября 2026 г. **Обновлено** 22 октября 2026 г. **На урок** 20 мин **Тема** [Повседневная работа и контекст]() ## После урока вы сможете - Различать системную инструкцию, параметры генерации и режим рассуждений - Находить настройки чата и учитывать поддержку модели и подключения - Сравнивать одно изменение по фактам и форме ответа, затем восстанавливать настройки - Отличать запрос инструмента и его выполнение от проверенного результата **Проверяемый результат:** Сравниваем одну поддерживаемую настройку на одинаковой задаче и записываем наблюдение без обещаний улучшения. Допустим, участнику книжного клуба нужно подготовить короткий черновик объявления о встрече по уже известной карточке. Правила для такого ответа задают текстовой инструкцией, а вариативность формулировок и технический предел генерации меняют поддерживаемыми параметрами в настройках чата. Числовой регулятор сам по себе не проверяет факты, поэтому готовый текст всё равно сверяют с исходными условиями. На этой условной задаче разберём, как в Open WebUI связаны системная инструкция, параметры генерации, настройки сервера модели и режим рассуждений. Реальных запусков модели здесь не проводилось: примеры ниже объясняют устройство настроек и дают схему для вашей самостоятельной проверки. ## Задайте объявлению факты и правило ответа Прежде чем открывать числовые настройки, определим, что именно мы передаём модели и какой результат считаем подходящим. Разделим входные данные на три части: исходные факты, текст запроса в чате и общее правило оформления ответа. Возьмём одну карточку встречи книжного клуба со следующими сведениями: - время: суббота, 15:00–16:00; - место: библиотека, зал 2; - тема: участники обсуждают уже прочитанную книгу без указанного названия; - условия: можно прийти впервые, регистрация не нужна; - неизвестные детали: стоимость участия и контакты организаторов в карточке не указаны; дату, точный адрес, сайт или название книги от себя не добавляем. Саму просьбу к модели сформулируем в обычном сообщении чата: > Подготовь объявление о встрече по этой карточке: три коротких предложения. Сохрани время, место и условия участия. Общие требования к языку и работе с неизвестными фактами вынесем в системную инструкцию (`System Prompt`): > Пиши по-русски простыми словами. Используй только переданные сведения. Если для ответа не хватает факта, обозначь это; не добавляй его от себя. Так мы разделяем роли: карточка и запрос задают содержание конкретной задачи, а системная инструкция описывает правило, по которому модель должна строить ответ. По этим же условиям вы будете проверять полученный черновик объявления: 1. Время, место и условия участия из карточки сохранены. 2. В тексте три коротких предложения. 3. Модель не добавила от себя неподтверждённые сведения вроде адреса, цены или названия книги. При работе с системной инструкцией учитывайте, как Open WebUI собирает её перед отправкой. Когда браузер формирует запрос ([логика сборки в интерфейсе чата]() ), инструкция текущей беседы выбирается приоритетнее инструкции из настроек вашего аккаунта. Но на стороне сервера ([маршрутизатор OpenAI]() , [маршрутизатор Ollama]() ) дополнительно применяется системная инструкция, сохранённая в карточке самой модели. Поэтому здесь нет единой простой лестницы, где настройка чата полностью стирает остальные уровни. В проверенном пути обработки запроса ([формирование тела запроса]() , [объединение системных сообщений]() ) собственная инструкция модели сохраняется и добавляется перед существующим системным сообщением. Формулировка в [документации по моделям Workspace]() о том, что пользователь не может переопределить системный промпт модели, означает сохранение модельной инструкции рядом с вашей, а не полное удаление текста из чата. Само наличие инструкции не гарантирует безусловного подчинения: соблюдение правил всегда зависит от модели, шаблона и полного контекста диалога. ## Найдите параметры чата и проверьте, откуда берётся значение Когда содержание и правило ответа заданы, нужно найти место, где параметры меняются только для текущей беседы, не затрагивая остальные диалоги. Мы ориентируемся на интерфейс стабильного релиза Open WebUI `v0.12.3` ([запись о релизе на GitHub]() , опубликованном 16 октября 2026 года и проверенном как последний доступный на 21 октября 2026 года UTC). В других версиях, при другом языке интерфейса или ограниченных правах названия и доступность элементов могут отличаться. Согласно [документации по параметрам чата]() , одними и теми же настройками можно управлять на трёх уровнях: - в боковой панели **`Controls`** (`Управление чатом`) внутри текущего диалога, где расположены поле **`System Prompt`** и блок **`Advanced Params`** ([панель управления чатом]() ); - в личных настройках аккаунта **`Settings` → `General`** (`Настройки` → `Общие`); - в настройках конкретной модели **`Workspace` → `Models`** (`Рабочая область` → `Модели`). Для учебной практики менять настройки всего аккаунта или редактировать модель в рабочей области не нужно: мы работаем только в панели `Controls` открытого чата. Общую схему хранения конфигураций мы разбирали в уроке о том, [где меняются настройки]() . Если вы открыли `Controls`, но не видите поля `System Prompt` или раздела `Advanced Params`, это не доказывает поломку установки: доступ к системной инструкции и к расширенным параметрам регулируется двумя независимыми пользовательскими правами (`chat.system_prompt` и `chat.params`), которые администратор мог отключить. Внутри блока `Advanced Params` большинство регуляторов изначально стоят в положении **`Default`**. В [коде настроек параметров]() `Default` означает отсутствие локального переопределения в этом чате (`null`), а не отсутствие значений на уровне аккаунта, модели или провайдера. Когда вы нажимаете на переключатель и переводите параметр в режим **`Custom`**, интерфейс подставляет начальное число (например, `0.8` для температуры, `0.9` для `top_p` или `128` для лимита токенов) и начинает передавать это явное значение в запросе. Такие стартовые числа заложены в сам интерфейс Open WebUI, поэтому не воспринимайте их как универсальные значения по умолчанию вашего провайдера или как готовый рецепт для задачи. Повторное переключение обратно в `Default` очищает локальное переопределение чата. Перед любыми пробами сначала запишите, в каком состоянии (`Default` или `Custom` с конкретным числом) находился параметр. Чтобы понимать, какое именно число уйдёт к модели, учитывайте порядок приоритетов для обычных параметров генерации ([передача из чата]() , [слияние на бэкенде]() , [правило перезаписи ключей]() ): 1. Явное значение в текущем чате перекрывает значение из настроек аккаунта. 2. Переданное в запросе значение перекрывает стандартные параметры, сохранённые в карточке модели. 3. Настройки модели перекрывают глобальные значения по умолчанию. Пользовательские `custom_params` объединяются отдельно по ключам, а глобальные defaults не работают как жёсткий запрет на изменение параметров. Из этого порядка есть два существенных исключения ([правила приоритетов в документации моделей]() , [применение параметров в запросе]() ): - переключатель потокового вывода **`Stream Chat Response`**, заданный на уровне модели, имеет приоритет над настройками чата и аккаунта; - действующие опции **`Model Controls`** заменяют одноимённые обычные параметры из чата и аккаунта в отправляемом запросе; если явный вариант не выбран, применяется настроенный для этого элемента вариант по умолчанию, когда он задан. Для моделей Ollama отдельные корневые опции вроде `think`, `format` и `keep_alive`, заданные напрямую на модели, также могут сохранять приоритет. Такая замена происходит при сборке запроса и не означает, что ползунок в `Advanced Params` будет визуально заблокирован в интерфейсе. Поэтому сам факт, что ползунок двигается, не доказывает, что ваше число дошло до модели. Если в вашей установке видны настройки модели или действующий выбор `Model Controls`, перед сравнением проверьте, не переопределяют ли они выбранный параметр. Если эти сведения недоступны, зафиксируйте эту неизвестность: отсутствие значка или открытая панель параметров не гарантируют отсутствия переопределения на стороне модели. ## Меняйте вариативность через temperature или top\_p Когда модель составляет объявление по нашей карточке, на каждом шаге она выбирает следующее слово или фрагмент текста из нескольких вероятных продолжений. Способ такого отбора при генерации называют сэмплированием (*sampling*), а управляют им прежде всего параметры **`temperature`** и **`top_p`**. В [официальных подсказках интерфейса]() и [документации Modelfile Ollama]() параметр **`temperature`** описывается как регулятор вариативности или «креативности» ответа: более высокие значения могут давать более разнообразные формулировки, а более низкие делают выбор сфокусированнее. Второй регулятор сэмплирования, **`top_p`**, в [настройках расширенных параметров]() решает схожую задачу: более высокие значения допускают большее разнообразие вариантов, а меньшие удерживают выбор в рамках наиболее вероятных продолжений. Для понятного сравнения на нашем объявлении меняйте только один из этих параметров за раз: возьмите за основу `temperature`, а `top_p` оставьте в исходном состоянии. Если захотите отдельно посмотреть на работу `top_p`, сначала верните `temperature` к начальному значению. Изменение по одному параметру делает два запроса сопоставимее и позволяет точно описать условия, при которых получены ответы, хотя одна пара ответов сама по себе не доказывает, что разница в тексте вызвана именно этой настройкой, и не гарантирует лучшего результата. При выборе числа учитывайте два ограничения: - **Ни `temperature`, ни `top_p` не проверяют факты.** Снижение температуры не защищает от выдуманных деталей и не гарантирует абсолютно одинаковый текст при каждом запросе, а её повышение не обязательно испортит объявление — конкретный эффект на вашей модели заранее неизвестен. - **Диапазон ползунка в интерфейсе не равен поддержке со стороны сервера.** В Open WebUI `v0.12.3` ползунок `temperature` размечен от `0` до `2`, а `top_p` — от `0` до `1`, но допустимые значения всегда определяются вашим провайдером и конкретной моделью. Например, в [серверном маршрутизаторе OpenAI]() для части новых моделей при обращении через ветку Azure нестандартная `temperature` принудительно удаляется из запроса. Это частное правило конкретного маршрута, но оно наглядно показывает, почему нужно сверяться с документацией своего подключения. ## Отделяйте три предложения от лимита max\_tokens В нашем запросе есть требование: «три коротких предложения». Пользователи иногда пытаются подкрепить это условие техническим параметром **`max_tokens`**, но эти инструменты решают разные задачи. Количество предложений и краткость формулировок задаются текстом вашего запроса и системной инструкцией. Параметр `max_tokens` в [настройках чата]() устанавливает лишь верхний технический предел на число генерируемых токенов ответа. Токен — это внутренняя учётная единица модели: фрагмент слова, целое слово или знак препинания. Универсального коэффициента пересчёта токенов в русские слова или предложения не существует, поэтому подобрать число в `max_tokens` так, чтобы модель всегда писала ровно три законченных предложения, нельзя. При отправке запроса Open WebUI переводит название этого лимита на язык выбранного подключения: - для моделей Ollama при [сборке параметров запроса]() `max_tokens` преобразуется в `num_predict` ([описание `num_predict` в Ollama]() ); - при преобразовании запросов под Responses API в [маршрутизаторе OpenAI]() лимит передаётся как `max_output_tokens`. Трогать `max_tokens` при подготовке обычного короткого объявления не нужно. Обратиться к нему имеет смысл, если ответ модели действительно оборвался на полуслове: тогда стоит проверить поддерживаемый лимит вашего подключения и при необходимости провести отдельную пробу, предварительно вернув остальные изменённые настройки к исходным. Само по себе короткое сообщение от модели не доказывает, что сработал лимит токенов. Кроме того, в зависимости от модели и точки подключения этот предел может расходоваться не только на видимый ответ, но и на предварительные рассуждения. ## Проверьте поддержку рассуждений и смысл блока Thinking Для простого объявления по готовой карточке включать или усиливать режим рассуждений (*reasoning*) нет необходимости. Разбираться с этими настройками и сравнивать их имеет смысл тогда, когда ваша подключённая модель поддерживает рассуждения, а сама задача требует проверить работу модели в таком режиме. В Open WebUI важно не смешивать управление вычислениями на сервере, настройки отображения текста в чате и общий лимит токенов. Посмотрим, как распределены эти роли ([руководство по рассуждающим моделям]() , [поля интерфейса]() , [передача параметров]() , [обработка потока ответа]() ): | Элемент в Open WebUI | За что отвечает | Главная особенность и ограничение | | --- | --- | --- | | **`Reasoning Effort`** (`reasoning_effort`) | Передаёт желаемый уровень усилий на рассуждение провайдерам и моделям, которые поддерживают этот параметр API | В `v0.12.3` это открытое текстовое поле со стартовым значением `medium` при включении `Custom`. Значения `low`, `medium`, `high` служат примерами, а не закрытым универсальным списком для всех моделей | | **`think`** (в нативной Ollama) | Управляет режимом размышлений напрямую в поддерживаемых моделях Ollama | Отдельный корневой параметр Ollama; допустимые уровни зависят от конкретной модели и версии Ollama, поэтому копировать сюда `reasoning_effort` без проверки документации нельзя | | **`reasoning_tags`** | Управляет тем, как интерфейс ищет и разбирает теги рассуждений в тексте ответа для показа в чате | Настраивает только разбор и отображение текста; сам по себе этот параметр не меняет объём вычислений модели | | **Сворачиваемый блок `Thinking`** | Показывает пользователю текст рассуждений или сводку, которые реально вернул сервер | Отображает только переданные провайдером данные из размеченных тегов или полей потока `reasoning_content`, `reasoning`, `thinking` | | **Токеновый предел (`max_tokens` и аналоги)** | Ограничивает объём генерируемых токенов по правилам конкретного подключения | Не работает как универсальный отдельный «бюджет только на рассуждения» в стандартном интерфейсе | Из этого устройства следуют три практических вывода: 1. **Единого универсального поля «бюджет токенов на рассуждения» в стандартном наборе `Advanced Params` нет.** Вы управляете либо текстовым параметром `Reasoning Effort`, либо нативным `think` для Ollama, а специфические параметры конкретного бэкенда при их наличии передаются через пользовательские настройки модели ([документация Workspace Models]() ). 2. **Видимый блок `Thinking` не равен полной внутренней цепочке мыслей модели.** Open WebUI показывает только то, что прислал провайдер. Согласно [документации Open WebUI по рассуждающим моделям]() и [руководству OpenAI по reasoning-моделям]() , некоторые провайдеры вообще не возвращают «сырые» токены рассуждений и отдают только краткую сводку (*summary*). Поэтому оценивать правильность объявления по длине или наличию блока `Thinking` нельзя. 3. **Дополнительные рассуждения могут увеличить расход ресурсов и время ответа.** На локальной модели это проявляется в объёме вычислений и времени ожидания, а у облачных провайдеров может влиять также на оплачиваемый расход токенов и исчерпание лимита в зависимости от правил подключения. Например, по [правилам OpenAI]() токены рассуждений тарифицируются как выходные токены (*output tokens*) и входят в общий лимит генерации вместе с видимым ответом. У других API и локальных серверов правила учёта могут отличаться. ## Различайте запрос инструмента, выполнение и проверенный результат Рассуждения модели внутри генерации нужно отличать от реальных действий во внешних системах — вызова инструментов (*tool calling*). Даже если в тексте ответа или в блоке `Thinking` написано, что сведения проверены, сам текст генерации не доказывает, что инструмент действительно запускался. При штатном вызове инструментов ([документация по Tools]() , [описание server-side tool calling]() , [обработка вызовов на сервере]() ) цепочка событий состоит из пяти отдельных шагов: 1. Модель возвращает структурированное предложение вызвать инструмент с определённым именем и аргументами. 2. Open WebUI проверяет доступность и выполняет сам инструмент. 3. Инструмент возвращает полученные данные обратно в Open WebUI. 4. Модель получает эти данные и формирует итоговый ответ в чате. 5. Человек проверяет источник данных или фактический результат действия. Режим **`Native`** (нативный вызов функций) установлен в Open WebUI по умолчанию начиная с версии `v0.10.0`, тогда как старый режим **`Legacy`** остаётся неподдерживаемым вариантом отключения и не может использовать встроенные системные инструменты. Но сам по себе выбор рассуждающей модели или режима `Native` не наделяет чат инструментами: их доступность зависит от настроек экземпляра Open WebUI, прав пользователя, поддержки нативного вызова функций самой моделью, её категории и выбранных в чате или модели функций. Появится ли запрос на подтверждение перед выполнением, зависит от настроек сервера и типа чата ([документация Tool Permissions]() , [проверка разрешений при запуске]() , [ожидание подтверждения в потоке]() ): - Ручное подтверждение (**`Tool Permissions`**) — экспериментальная функция, которая **выключена по умолчанию**. Обычный чат предложит режим **`Ask for approval`** (`Запрашивать подтверждение`), только если администратор явно включил эту возможность. - Когда функция выключена или в меню выбран режим **`Full access`** (`Полный доступ`), доступный инструмент выполняется сразу, без паузы. В режиме `Full access` также всегда работают фоновые автоматизации и ответы в каналах. - Если режим `Ask for approval` включён и выбран в обычном сохранённом чате, выполнение встаёт на паузу с кнопками **`Allow`** / **`Deny`** (`Разрешить` / `Отклонить`), а во временном чате открывается диалоговое окно `Tool Permissions` с именем инструмента и его аргументами. Отказ (`Deny`) возвращает модели сообщение об ошибке, а нажатие кнопки остановки генерации (`Stop`) автоматически отклоняет ожидающие вызовы. Разрешение на запуск — это лишь согласие на попытку вызова, а не гарантия безопасности или правильного результата. Поэтому до нажатия `Allow` человек проверяет имя инструмента и передаваемые аргументы, а после выполнения сверяет возвращённые данные с задачей. Для нашей основной практики с объявлением книжного клуба внешние инструменты не требуются. ## Сравните одну настройку на том же объявлении и верните исходное значение Соберём все правила в короткую самостоятельную практику. Ваша цель — изменить один поддерживаемый параметр на задаче с объявлением книжного клуба, проверить результат по фактам и форме, а затем вернуть настройки чата в исходное состояние. Выполните проверку по шагам: 1. **Зафиксируйте исходное состояние.** Запишите выбранную модель и тип подключения. Откройте панель `Controls` текущего чата и сохраните исходное состояние поля `System Prompt` (текст инструкции или его отсутствие в этом чате), а также состояние выбранного параметра и остальных регуляторов в `Advanced Params` (`Default` или `Custom` с конкретным числом). Настройки аккаунта и самой модели не меняйте. Если в вашей установке доступны настройки модели или выбор `Model Controls`, убедитесь, что действующий вариант (включая вариант по умолчанию) не перезаписывает выбранный параметр; если проверить это нельзя, запишите эту неизвестность. Когда у учётной записи нет прав на изменение параметров чата, провайдер не поддерживает настройку или её переопределяет модель, не подбирайте случайные значения и не перенастраивайте сервер — просто зафиксируйте ограничение. 2. **Подготовьте неизменные входные данные.** Используйте карточку встречи, текст запроса и учебную системную инструкцию из первого раздела урока. Если ради практики вы добавили или заменили `System Prompt` в текущем чате, запишите это как часть подготовки, чтобы вернуть прежний вид после упражнения; в обоих сравниваемых запросах системная инструкция должна быть одинаковой. 3. **Выберите один поддерживаемый параметр.** Для первой пробы возьмите `temperature`. Остальные регуляторы (`top_p`, `max_tokens`, настройки рассуждений) оставьте без изменений. Режим рассуждений для этого объявления не обязателен; если вы решите отдельно проверить его на поддерживающей модели, сначала верните `temperature` к записанному состоянию и учитывайте возможный расход времени или токенов по правилам вашего подключения. 4. **Выполните два сопоставимых запроса.** Первый ответ получите при записанном исходном состоянии выбранного параметра, а второй — изменив только этот параметр при той же модели, том же подключении, тех же фактах карточки, запросе, `System Prompt` и остальных настройках. Оба ответа должны создаваться при одинаковом входном контексте: если написать второе сообщение в продолжение того же диалога, первый ответ модели войдёт в историю и изменит входные данные. Поэтому используйте либо переключение веток на первом сообщении при полностью одинаковом контексте (как устроены [первый чат и варианты ответа]() ), либо два независимых новых чата. Во втором случае явно повторите в обоих новых чатах нужную системную инструкцию и все исходные настройки `Custom`, иначе новый чат получит значения `Default` вместо вашего исходного состояния. 5. **Сверьте оба ответа и запишите наблюдение.** Заполните для себя короткую карточку проверки: - Модель и подключение: `...` - Исходное состояние параметра: `...` - Одно выполненное изменение: `...` - Сохранены ли время, место и условия участия (да/нет): `...` - Выполнено ли условие про три коротких предложения (да/нет): `...` - Появились ли придуманные сведения, которых не было в карточке: `...` - Чем отличаются формулировки первого и второго ответов: `...` - Что осталось неизвестным после одного сравнения: `...` 6. **Верните исходное состояние.** После записи наблюдения верните изменённый параметр во всех затронутых чатах к тому состоянию, которое было до практики: если изначально стоял `Default`, переключите в `Default`, а если был `Custom` с конкретным числом, верните это число. Если на время упражнения вы меняли `System Prompt` чата, восстановите и его исходное состояние. При оценке записей помните, что одна пара ответов показывает поведение конкретной модели и подключения в конкретных условиях, но не доказывает общего закона или причины различий и не обещает улучшения текста. Если при смене параметра оба ответа оказались почти одинаковыми или не стали лучше, это нормальное рабочее наблюдение, а не признак неисправности Open WebUI. В итоге каждая настройка остаётся на своём месте: системная инструкция задаёт требуемую форму и правила работы с фактами, поддерживаемый параметр меняет способ или технический предел генерации, а блок `Thinking` и вызовы инструментов требуют отдельной проверки и не заменяют вычитку ответа человеком. Сохраните свою короткую запись о проведённом сравнении и восстановленном исходном состоянии (будь то прежний `Default`, исходное число в `Custom` или прежняя системная инструкция чата), а выбранную настройку применяйте в похожих задачах только тогда, когда она даёт проверенную пользу по вашим критериям. Если в длинном разговоре теряются важные условия, разберите [контекст Open WebUI и сжатие чата]() и проверьте нужную деталь по исходной переписке. ## Материалы урока - [Первый чат и варианты ответа timofei-ermolaev.ru]() - [Где меняются настройки Open WebUI timofei-ermolaev.ru]() ## Отметить прохождение Отметьте урок после того, как получили проверяемый результат из практической части. Урок пройден ![Тимофей Ермолаев](https://timofei-ermolaev.ru/_astro/timofei-ermolaev-portrait.s0mCFw-J_2r7Nkv.webp) ## Об авторе ### Тимофей Ермолаев Директор по информационным технологиям (CIO) Пишу о больших языковых моделях, автоматизации и применении ИИ в бизнесе. В статьях разделяю личный опыт, выводы исследований и практические рекомендации. [Подробнее об авторе]()