Параметры Open WebUI: настройка ответа и рассуждений

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

На этой условной задаче разберём, как в 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 важно не смешивать управление вычислениями на сервере, настройки отображения текста в чате и общий лимит токенов. Посмотрим, как распределены эти роли (руководство по рассуждающим моделям, поля интерфейса, передача параметров, обработка потока ответа):

Из этого устройства следуют три практических вывода:

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 и сжатие чата и проверьте нужную деталь по исходной переписке.