В предыдущем уроке мы разделили роли между удобной рабочей оболочкой и источником языковых моделей. Теперь посмотрим, как эти части взаимодействуют на практике. Представьте обычную рабочую задачу: вы открыли чат, прикрепили текстовый регламент компании и попросили нейросеть коротко перечислить правила согласования договора. Чтобы на экране появился ответ, в работу включаются браузер, серверная часть Open WebUI, хранилища данных и сам сервер моделей. Разберём каждый этап этой цепочки по порядку.
Путь сообщения от браузера к модели и обратно
В стандартной схеме, когда вы вводите вопрос и нажимаете кнопку отправки, сообщение сначала поступает из браузера на сервер Open WebUI. Сам интерфейс не вычисляет текст ответа. Как описано в инструкции по подключению провайдеров, в стандартной схеме сервер Open WebUI формирует запрос и отправляет его выбранному источнику моделей по API (программному интерфейсу для обмена данными). Выбранная модель выполняет вычисления, после чего ответ возвращается в Open WebUI и отображается в вашем чате.
Место, где фактически генерируется ответ, зависит от того, какой именно адрес подключения вы используете:
- Локальный или сетевой сервер моделей. Если вы запускаете модели через Ollama или другой локальный сервер с OpenAI-совместимым API, запрос направляется на ваше оборудование.
- Внешний облачный провайдер. Если выбран внешний сервис, сервер Open WebUI пересылает ваш вопрос и сопутствующие данные для ответа на серверы этого поставщика.
При этом программы не обязаны работать в одном месте. Open WebUI и Ollama можно разместить на разных компьютерах. Но даже на одном компьютере они могут оказаться в разных сетях: например, когда Open WebUI работает в контейнере. Такие варианты показаны в официальных сетевых схемах. Даже если они находятся на одном физическом устройстве, между ними всё равно устанавливается сетевое соединение. Кроме того, выбор локальной модели для чата не переносит на ваш компьютер все остальные операции: если для чтения файлов или поиска в сети подключены внешние сервисы, приложение будет обращаться к ним отдельно.
Из чего состоит запрос и чем контекст отличается от истории
Перед тем как отправить запрос модели, сервер Open WebUI собирает для неё рабочий пакет данных. Вместе с вашим вопросом в запрос могут войти предыдущие реплики диалога, системные инструкции с правилами ответа и фрагменты текста из документов. Весь этот объём сведений, который модель получает за один раз для подготовки ответа, называют контекстом. Подробнее о том, как устроен этот механизм и почему его объём ограничен, рассказано в материале «Контекстное окно LLM».
Сохранённая история чата и контекст запроса могут различаться. В базе данных приложения может храниться длинная переписка за несколько недель и десяток загруженных файлов. Но при отправке нового сообщения Open WebUI отбирает для модели только то, что предусмотрено текущими настройками, режимом работы и ограничениями по объёму. Старые реплики остаются в истории на экране, но могут не войти в очередной запрос.
Получив собранный контекст, языковая модель обрабатывает и создаёт текст по небольшим частям, которые называют токенами (один токен может соответствовать слову, части слова или знаку препинания). Если источник модели поддерживает потоковую передачу, сервер Open WebUI пересылает токены в браузер сразу по мере их появления, и вы видите, как ответ печатается на экране постепенно.
Как текст документа попадает в запрос
Вернёмся к нашему примеру с рабочим регламентом. В обычном сценарии поиска по текстовому документу Open WebUI сначала извлекает из PDF или DOCX текст, который сможет использовать модель. Этот этап называется извлечением содержимого. Как указано в документации по извлечению данных из документов, за эту задачу отвечает встроенный обработчик Open WebUI или отдельно подключённый внешний сервис (который тоже можно развернуть локально). Способ обработки зависит и от типа файла: чтение текста из PDF и анализ изображений или видео опираются на разные настройки системы.
Во временном чате этот этап устроен иначе. Если вы включили режим временного чата (Temporary Chat), извлечение текста из прикреплённых документов происходит прямо в браузере без участия серверных обработчиков. Некоторые сложные форматы могут обработаться некорректно, а сам подготовленный контекст затем всё равно отправляется выбранной языковой модели.
Когда текст из документа получен, Open WebUI должен решить, как именно передать его модели. В описании работы с документами и RAG выделяются три основных подхода:
- Поиск подходящих фрагментов (RAG). Текст документа разбивается на небольшие части. Вспомогательная модель эмбеддингов создаёт их числовые представления, которые Open WebUI сохраняет для поиска. Когда вы спрашиваете про согласование договора, система ищет наиболее близкие по смыслу абзацы регламента и добавляет в запрос к чат-модели только их. Модель получает найденные сведения для этого ответа. Её параметры от этого не меняются, а ошибки всё ещё возможны.
- Передача документа целиком (Full Context). Если включить режим использования всего документа (Using Entire Document), приложение пропустит этап выборочного поиска и добавит в контекст запроса весь извлечённый текст файла.
- Обращение к файлу через инструменты (Tools-Only). В режимах Default и Native можно отключить автоматическую подстановку текста файла и включить встроенные инструменты. Тогда модель может запросить чтение вложения во время подготовки ответа. В Legacy эти встроенные инструменты для вложений недоступны.
То, какие сведения из файла получит модель, зависит от выбранного способа работы с документом.
Как модель пользуется инструментами
Если для ответа на вопрос недостаточно текста из чата и документов (например, нужно проверить актуальный курс валют в сети или выполнить расчёт), используются инструменты. Языковая модель анализирует вопрос и предлагает вызвать подходящий инструмент с нужными параметрами. Само действие выполняет программа или сервис, к которому обращается Open WebUI.
Согласно справке по серверному вызову инструментов, когда процессом управляет сервер Open WebUI, работа идёт по шагам:
- Модель возвращает предложение вызвать конкретный инструмент.
- Сервер Open WebUI проверяет права пользователя и запускает этот инструмент.
- Инструмент выполняет свою задачу и отдаёт результат серверу Open WebUI.
- Сервер передаёт полученные данные обратно модели, чтобы она сформулировала итоговый ответ или предложила следующий шаг.
Для запуска инструмента нужны разрешения и подходящий режим работы. Например, Legacy допускает один раунд вызовов, а некоторые обращения через API возвращают предложенные вызовы без их исполнения. Поэтому предложение модели ещё не подтверждает, что действие выполнено.
Сами инструменты тоже работают в собственном окружении: на сервере Open WebUI, на отдельном сервере инструментов или прямо в браузере пользователя, если для выполнения кода используется среда Pyodide. Ни один из этих вариантов не даёт чат-модели автоматического доступа ко всем личным файлам на вашем компьютере.
Где хранятся переписка, файлы и сами модели
Чтобы история диалогов и загруженные базы знаний не пропадали после закрытия вкладки, Open WebUI распределяет данные по нескольким хранилищам на сервере. В руководстве по обслуживанию базы данных показано, что сведения разделены на три части:
- Основная база данных приложения. В стандартной установке для одного сервера используется файл SQLite (
webui.db). В нём хранятся учётные записи пользователей, история чатов, настройки, а также записи о загруженных файлах и базах знаний. - Файловое хранилище. Сами исходные файлы документов, которые вы загрузили в систему, лежат в отдельном каталоге на диске, а не внутри файла
webui.db. - Векторное хранилище. Числовые представления фрагментов текста для поиска по документам (по умолчанию на базе ChromaDB) тоже хранятся отдельно от основной базы чатов.
Для переноса системы недостаточно скопировать только webui.db. Без файлового хранилища приложение потеряет доступ к самим документам, а без поисковых данных не сможет использовать прежний индекс.
Отдельно от всех этих хранилищ находятся файлы самой языковой модели (её веса, то есть параметры для вычислений). Ими управляет сервер моделей или внешний провайдер. Например, Ollama хранит загруженные модели в собственном каталоге, как описано в её документации. При запуске нескольких экземпляров Open WebUI им нужен доступ к общим данным. В официальной схеме используются общая база PostgreSQL, общее векторное и файловое хранилище. Сервис Redis координирует работу экземпляров. Для одиночной установки весь этот набор не требуется: по умолчанию приложение использует SQLite и ChromaDB.
Что меняют прямые подключения (Direct Connections)
Из стандартного маршрута «браузер → сервер Open WebUI → сервер модели» есть исключение, которое называется прямым подключением (Direct Connections). Как отмечено в документации по прямым подключениям, эта функция позволяет браузеру пользователя отправлять запрос на генерацию ответа напрямую в OpenAI-совместимый API модели, минуя серверную часть Open WebUI на этом шаге.
Для работы такой схемы администратор должен разрешить её в настройках, а сам сервер моделей обязан принимать запросы напрямую из браузера со страницы вашего приложения (разрешение на такие обращения задаётся через CORS на стороне провайдера). Если пользователь подключает таким способом личного провайдера, ключ доступа сохраняется в локальном хранилище браузера.
При этом прямое подключение не превращает Open WebUI в приложение без сервера и не отменяет сохранение переписки. Сервер Open WebUI продолжает отвечать за учётные записи, хранение данных и фоновые задачи, такие как создание заголовков и тегов для чатов. Кроме того, разработчики отмечают этот режим как экспериментальный, поэтому его поведение в будущих версиях может меняться.
Где остаются сообщения и документы
Вернёмся к вопросу о рабочем регламенте. Сам файл и история разговора хранятся в Open WebUI, а подготовленный для ответа контекст получает выбранная модель. Если извлечение текста или поиск выполняет внешний сервис, он тоже участвует в обработке. Поэтому место установки веб-интерфейса ещё не определяет весь путь данных.
Для своего сценария можно проследить четыре участка: где сохраняются чаты и файлы, где извлекается текст, где строится поисковый индекс и куда отправляется запрос за ответом. Внешний сервис на любом из этих участков означает отдельное соединение с ним. Прямое подключение меняет путь запроса к модели, но не отменяет остальные участки.
Этой карты достаточно для выбора сценария в следующем уроке. Сроки хранения, удаление, резервные копии и автономную работу подробно разберём в разделе эксплуатации.
Маршрут генерации
Обычное подключение: браузер отправляет запрос серверу Open WebUI, сервер передаёт его Ollama или внешнему сервису моделей; ответ возвращается через сервер в браузер. Ollama запускает локальные модели, внешний сервис предоставляет доступ к моделям провайдера. При экспериментальных Direct Connections запрос генерации идёт из браузера напрямую к OpenAI-совместимому провайдеру. Функция должна быть включена, провайдер должен разрешать браузерные запросы через CORS; возможность может быть удалена. Сервер Open WebUI продолжает другие операции, включая названия чатов и теги.
Теперь можно решить, какие компоненты вы хотите держать на своём оборудовании, а какие готовы подключить как внешние сервисы. В следующем уроке разберём выбор сценария использования Open WebUI в зависимости от ваших задач, числа пользователей и требований к месту обработки данных.
