В предыдущем уроке мы проследили, как браузер, серверная часть Open WebUI, языковые модели и хранилища взаимодействуют между собой. Поскольку эти компоненты не привязаны друг к другу жёстко, одну и ту же систему можно собрать по-разному. От вашего сценария зависит, где размещать само приложение, откуда подключать модели и как организовать доступ.
Чтобы не запутаться в настройках, мы пойдём от простого к сложному: сначала назовём задачи, затем определим круг пользователей и место обработки данных, а после этого учтём расписание работы, интернет-доступ и сопровождение. Выбирать операционную систему, настраивать Docker или подсчитывать объём памяти сейчас не нужно. На этом шаге мы составим понятное описание системы, на которое вы будете опираться дальше.
Какие задачи определяют набор сервисов
Планирование начинается с того, что именно вы хотите делать в Open WebUI. От списка повседневных задач зависит, какие технические компоненты вообще понадобятся системе.
Если вам нужен только текстовый собеседник для черновиков, перевода или объяснения кода, в базовой схеме достаточно самого приложения Open WebUI и подключённой чат-модели. Для ответов по внутренним регламентам или договорам понадобится обработка документов. Если вы планируете искать подходящие фрагменты по смыслу, приложению потребуется извлекать текст из файлов и создавать его числовые представления, эмбеддинги. В предыдущем уроке мы также разобрали вариант передачи текста документа целиком. Если же модель должна проверять свежие сведения в сети или запускать вычисления, в схему добавляются внешние инструменты или поиск.
Каждая дополнительная возможность опирается на свой обработчик или сервис. Поэтому уже на старте полезно отделить функции, которые нужны вам сразу, от тех, что кажутся просто интересными. Чем точнее очерчена задача, тем меньше лишних сервисов придётся подключать и обслуживать.
Что меняется при переходе от личной работы к командной
По числу пользователей сценарии делятся на персональные и командные. Этот признак описывает только то, кто входит в систему, и никак не ограничивает выбор моделей.
Если вы разворачиваете Open WebUI только для себя, вы сами управляете своим аккаунтом, чатами и загруженными файлами. Когда к тем же рабочим регламентам нужно подключить отдел или проектную группу, сценарий становится командным. Как показано в руководстве по совместному доступу, команда может пользоваться одной общей установкой Open WebUI: коллеги просто открывают адрес приложения в своих браузерах, и ставить программу или Docker на компьютер каждого сотрудника не нужно.
Общая установка позволяет коллегам работать в одном приложении, сохраняя отдельные учётные записи и права на ресурсы. Внутри Open WebUI действуют разграничения доступа. Согласно документации по правам и группам, администратор отдельно настраивает права на функции (например, возможность загружать файлы) и доступ к конкретным ресурсам или базам знаний. Важно учитывать, что итоговые права пользователя складываются из базовых разрешений по умолчанию и правил всех групп, в которых он состоит: если хотя бы одно правило разрешает действие, запрет в другой группе его не отменит. Кроме того, при настройке командного доступа результат всегда стоит проверять под обычной учётной записью, так как экран администратора не отражает того, что в действительности видят коллеги.
Где обрабатываются запросы и какие данные уходят наружу
Определив круг пользователей, нужно решить, где именно будут выполняться вычисления. В инструкции по подключению провайдеров описано, что один экземпляр Open WebUI может работать как с локальными серверами моделей на вашем оборудовании, так и с внешними облачными сервисами. При этом само слово API означает лишь программный способ обмена данными между приложением и моделью, но не указывает на облако: по API отвечают и локальная программа на соседнем сервере, и внешний коммерческий провайдер.
В зависимости от того, где работают ваши сервисы, схему можно назвать локальной, облачной или смешанной (гибридной). Это не переключатели режимов внутри самого Open WebUI, а удобное описание вашей архитектуры:
- Локальная обработка. Модели и вспомогательные сервисы работают на ваших компьютерах или серверах.
- Облачная обработка. Вычисления передаются внешним поставщикам.
- Смешанная обработка. Часть задач выполняется внутри вашей инфраструктуры, а часть отправляется во внешние сервисы.
Этот выбор напрямую связан с правилами работы с информацией. Как объясняется в материале о передаче и хранении данных чата, внешнему поставщику передаются сообщение и данные, включённые в запрос. Если в контекст добавлены фрагменты документов, они тоже отправятся этой модели. При этом важно проверять маршрут данных для каждой функции отдельно. Выбор локальной чат-модели не переносит на ваше оборудование остальные этапы: если для разбора сложных документов, построения эмбеддингов или веб-поиска подключены облачные сервисы, данные, нужные для этих операций, будут передаваться соответствующим внешним сервисам.
Поэтому уже сейчас полезно разделить данные: какие тексты и вопросы допустимо отправлять внешним провайдерам, а какие должны оставаться только на вашем оборудовании. Подробно маршруты передачи данных мы разберём в отдельном материале курса.
Откуда нужен доступ и что означает работа без интернета
Следующий шаг связывает сценарий с физическим размещением системы и расписанием её работы. Даже для личного использования важно понять, будете ли вы открывать чат только за рабочим столом или вам нужен доступ с ноутбука в поездке. Для команды этот вопрос становится основным.
Чтобы сотрудники могли открыть общую установку, их устройства должны видеть сервер Open WebUI по сети. В документации по организации доступа описано несколько подходов: подключение внутри локальной сети офиса, доступ через корпоративный VPN или закрытые частные сети (overlay-сети), а также публикация через обратный прокси-сервер с защищённым протоколом HTTPS. Для работы внутри сети компании публичный домен в интернете может не понадобиться.
Расписание работы тоже влияет на выбор места для установки. Из архитектуры системы следует простое правило: если единственный компьютер с приложением Open WebUI выключен или ушёл в спящий режим, никто не сможет открыть интерфейс чата. Поэтому рабочий ноутбук одного из сотрудников плохо подходит на роль круглосуточного командного сервера. А если приложение работает, но выключен отдельный сервер с языковой моделью, пользователи войдут в интерфейс, но не получат ответов от этой модели.
Отдельного внимания требует сценарий работы без интернета. Сам факт установки Open WebUI на свой сервер не делает систему полностью автономной. Как поясняется в руководстве сообщества по автономному режиму (этот материал подготовлен сообществом и не поддерживается командой Open WebUI), к отключению от сети нужно готовиться заранее. До отключения интернета нужно подготовить модели и программные зависимости для выбранных функций. Для обычного чата понадобится локальный источник модели; для поиска по документам потребуются также локальные средства извлечения текста и создания эмбеддингов. Внутренние настройки автономного режима отключают отдельные автоматические загрузки и проверки обновлений. Чтобы блокировать внешние сетевые обращения, нужны отдельные настройки сети. Без интернета облачные модели, внешний поиск и внешние сервисы входа могут перестать работать. Для автономного сценария выбранные функции должны работать с доступными локальными компонентами. Это касается и входа в приложение.
Как зафиксировать свой сценарий и распределить ответственность
Наконец, любая рабочая система требует присмотра. Согласно документации по развёртыванию, перед открытием доступа пользователям нужно продумать аутентификацию, сохранность данных при перезапусках, резервное копирование и базовый контроль доступности. В персональном сценарии сопровождение можете взять на себя. Для команды стоит заранее договориться, кто заводит учётные записи, обновляет приложение и следит за созданием резервных копий. Само назначение ответственного человека не защищает данные от сбоев; оно определяет, кто занимается этими задачами.
Сведём принятые решения в короткое описание сценария. Ниже приведены два условных примера, которые показывают, как одна и та же задача с рабочими документами приводит к разным схемам:
- Сценарий А: персональный со смешанной обработкой. Вы работаете один со своего компьютера. Текст из открытых справочников извлекается и подготавливается для поиска локально, а ответы пишет облачная чат-модель по API. Передача вопросов и найденных фрагментов выбранному поставщику для этой задачи допустима. Сопровождение приложения и резервные копии вы берёте на себя.
- Сценарий Б: командный с локальной обработкой. Десять сотрудников в рабочие часы ищут ответы по внутренним регламентам компании. Передавать документы внешним провайдерам нельзя, поэтому приложение, сервер чат-моделей, извлечение текста и модель эмбеддингов работают внутри компании. Дополнительные функции тоже выбирают с учётом этого ограничения. Сотрудники подключаются к Open WebUI через корпоративный VPN. За права групп и регулярное копирование хранилищ отвечает системный администратор.
Попробуйте составить такую же короткую запись для своей задачи: укажите, что вы планируете делать в системе, кто будет к ней подключаться, какие данные допустимо обрабатывать снаружи, когда должен работать сервер и кто будет его сопровождать. Если по какому-то пункту пока нет точного ответа, просто отметьте его как вопрос для уточнения. С этим описанием перейдём к уроку «Требования к Open WebUI», где переведём выбранный сценарий в конкретные технические условия для вашей будущей установки.
