Обсудить проект
7 июля, 2026 · Искусственный интеллект и ML

Плагины Open WebUI: веб-поиск, код-интерпретатор, генерация изображений

Голая языковая модель умеет многое, но по-настоящему полезным ассистентом она становится, когда получает руки — доступ к актуальной информации из интернета, возможность выполнить код и посчитать, а не угадать ответ, и способность нарисовать иллюстрацию по описанию. В Open WebUI всё это реализовано через систему плагинов и функций, и на сервере srv-ai01 в сети 192.168.10.0/24 их можно включить буквально за один вечер. Вопрос не в том, включать ли плагины, а в том, как включить их безопасно, не открыв случайно дыру в периметр компании.

Важно понимать, что каждый плагин — это не просто галочка в настройках, а фактически отдельный сервис со своим жизненным циклом, своими зависимостями и своей поверхностью атаки. Веб-поиск добавляет зависимость от внешней сети, код-интерпретатор — от изолированного исполнения произвольного кода, генерация изображений — от отдельной модели с собственными требованиями к GPU. Прежде чем включать плагин в продакшене, стоит понимать эти зависимости так же хорошо, как и саму основную LLM.

В этой статье разберём три самых востребованных плагина Open WebUI — веб-поиск, код-интерпретатор и генерацию изображений — с точки зрения настройки и типичных рисков.

Веб-поиск: как подключить и не слить внутренний трафик наружу

Open WebUI поддерживает несколько провайдеров веб-поиска: SearXNG (self-hosted, самый приватный вариант), Google PSE, Bing, Brave Search API, Tavily и другие. Для корпоративного использования разумнее всего поднять собственный SearXNG прямо в периметре, чтобы поисковые запросы сотрудников не улетали к третьей стороне с привязкой к корпоративному IP.

# docker-compose.yml для SearXNG на srv-ai01
services:
  searxng:
    image: searxng/searxng:latest
    container_name: searxng
    ports:
      - "192.168.10.15:8080:8080"
    volumes:
      - ./searxng:/etc/searxng
    environment:
      - SEARXNG_BASE_URL=http://searxng.itpages.lab.local:8080/
    restart: unless-stopped

В настройках Open WebUI (Admin Panel → Settings → Web Search) включаем поиск и указываем адрес:

ENABLE_RAG_WEB_SEARCH=true
RAG_WEB_SEARCH_ENGINE=searxng
SEARXNG_QUERY_URL=http://searxng.itpages.lab.local:8080/search?q=<query>

Важный момент безопасности: веб-поиск означает, что модель формирует поисковый запрос сама, на основе диалога с пользователем. Если пользователь вставил в чат кусок внутреннего документа с конфиденциальными данными и попросил «найди похожие компании», есть риск, что фрагмент этих данных попадёт в поисковый запрос и уйдёт наружу. Настрой системный промпт так, чтобы модель не включала в поисковые запросы дословные цитаты из пользовательского ввода, и веди логирование исходящих поисковых запросов отдельно от остальных логов диалога.

Код-интерпретатор: песочница обязательна

Код-интерпретатор — самый мощный и самый опасный плагин из трёх. Он даёт модели возможность писать и выполнять Python-код прямо на сервере, и если это делается без изоляции, любой промпт-инъекшн или неудачная генерация может обратиться к файловой системе или сети srv-ai01. Open WebUI поддерживает выполнение кода через Jupyter-совместимый бэкенд, и здесь категорически нельзя запускать интерпретатор в том же контейнере, где крутится сама модель.

# изолированный контейнер для code interpreter
services:
  code-sandbox:
    image: jupyter/scipy-notebook:latest
    container_name: code-sandbox
    network_mode: none        # без сети вообще
    read_only: true
    tmpfs:
      - /tmp
    mem_limit: 2g
    cpus: 1.0
    security_opt:
      - no-new-privileges:true

Ключевые настройки для песочницы:

  • network_mode: none — код-интерпретатор не должен иметь доступа к сети вообще, иначе сгенерированный код сможет обратиться к внутренним сервисам сети 192.168.10.0/24 или к интернету;
  • лимиты CPU и памяти — чтобы случайный или намеренный бесконечный цикл не положил весь srv-ai01;
  • read_only файловая система с временным tmpfs — после каждой сессии контейнер пересоздаётся с чистого состояния.

В Open WebUI код-интерпретатор включается через Admin Panel → Settings → Code Execution, где указывается адрес изолированного Jupyter-бэкенда. Не давай доступ к этому плагину группе standard — только power-user и выше, с логированием каждого выполненного скрипта.

Генерация изображений: локально или через внешний API

Для генерации изображений Open WebUI поддерживает интеграцию со Stable Diffusion (через AUTOMATIC1111 или ComfyUI API) либо с внешними сервисами вроде DALL-E. Для корпоративного контура логичнее держать генерацию локально — так изображения, созданные по внутренним промптам (например, макеты с элементами фирменного стиля), не покидают периметр.

ENABLE_IMAGE_GENERATION=true
IMAGE_GENERATION_ENGINE=automatic1111
AUTOMATIC1111_BASE_URL=http://srv-ai01.itpages.lab.local:7860
IMAGE_GENERATION_MODEL=sdxl-base-1.0
IMAGE_SIZE=1024x1024

Здесь риски скорее репутационные и юридические, чем инфраструктурные: сотрудник может сгенерировать изображение с нарушением авторских прав или неуместным содержанием. Включи фильтрацию NSFW-контента на уровне самого генератора (у AUTOMATIC1111 есть встроенный safety checker) и ограничь доступ к плагину ролями, у которых есть реальная рабочая необходимость — дизайн, маркетинг.

Плагины сторонних разработчиков: отдельный уровень доверия

Помимо трёх встроенных плагинов, экосистема Open WebUI активно растёт за счёт пользовательских функций (Functions и Tools), которые можно установить из community hub. Здесь риск выше, чем с официальными плагинами: код функции выполняется на срv-ai01 с теми же правами, что и весь остальной сервис, и не проходит официальный security-ревью, сравнимый с проверкой пакетов в крупных репозиториях.

  • Перед установкой любой сторонней функции читай её исходный код целиком — большинство таких функций компактны, на 50-200 строк Python, и вычитать их за 10 минут вполне реально.
  • Никогда не устанавливай функции, которые запрашивают доступ к переменным окружения или файловой системе, если это не оправдано их прямым назначением.
  • Держи отдельное тестовое окружение (staging-инстанс Open WebUI) для обкатки новых функций перед выкаткой в прод.

Управление доступом к плагинам через группы

Как и с моделями (см. статью про ограничение доступа и учёт токенов), доступ к плагинам стоит выдавать через группы, а не индивидуально. В Admin Panel → Settings → Models можно привязать конкретные функции к конкретным моделям и группам пользователей:

# псевдо-конфигурация привязки плагинов к группам
groups:
  power-user:
    allowed_tools: [web_search, code_interpreter, image_generation]
  standard:
    allowed_tools: [web_search]
  guest:
    allowed_tools: []

Такое разделение стоит пересматривать так же регулярно, как и общую модель ролей — плагин, который казался безобидным полгода назад, может обрасти новыми возможностями в обновлении и потребовать пересмотра уровня доступа.

Мониторинг использования плагинов

Каждый плагин стоит логировать отдельно от общего чата, потому что именно вызовы плагинов чаще всего становятся источником нагрузки на сеть (веб-поиск), CPU (код-интерпретатор) или внешние сервисы (генерация изображений). Полезные метрики для дашборда:

# метрики Prometheus для плагинов Open WebUI
plugin_calls_total{plugin="web_search", status="success"}
plugin_calls_total{plugin="code_interpreter", status="timeout"}
plugin_execution_duration_seconds{plugin="image_generation"}
plugin_calls_total{plugin="code_interpreter", user_id="..."}

Алерт на резкий рост вызовов код-интерпретатора одним пользователем часто указывает либо на автоматизированный скрипт, использующий чат как обёртку над API, либо на попытку злоупотребления вычислительными ресурсами srv-ai01 в личных целях, например для майнинга или тяжёлых вычислений, не связанных с рабочими задачами.

Пилотный запуск плагинов на ограниченной группе

Прежде чем открывать плагины всем пользователям сразу, полезно провести двухнедельный пилот на небольшой группе из 5-10 добровольцев из разных отделов. Это позволяет обнаружить проблемы конфигурации (например, неверно настроенный whitelist доменов для веб-поиска или слишком жёсткий лимит на код-интерпретатор) до того, как с ними столкнётся вся компания.

# группа пилота в Open WebUI
groups:
  plugin-pilot:
    members: [i.petrov, e.ivanova, s.kuznetsov, ...]
    allowed_tools: [web_search, code_interpreter, image_generation]
    feedback_channel: "#ai-pilot-feedback"

В течение пилота стоит собирать обратную связь не только о багах, но и о самой полезности плагина для конкретных задач — нередко оказывается, что один из трёх плагинов почти не используется определённым отделом, и тогда решение выдавать его по умолчанию всем становится осознанным, а не автоматическим «потому что можем».

Комбинация плагинов в одном запросе

Реальная сила Open WebUI раскрывается, когда агент комбинирует несколько плагинов в рамках одной задачи — например, находит через веб-поиск актуальные курсы валют, затем через код-интерпретатор считает конвертацию для таблицы расходов. Здесь важно понимать, что каждый дополнительный плагин в цепочке увеличивает время ответа и поверхность для ошибок, поэтому агент должен явно решать, какие инструменты действительно нужны для конкретного запроса, а не вызывать все доступные «на всякий случай».

# системный промпт с явным указанием на экономность в вызове инструментов
Ты используешь инструменты (веб-поиск, код-интерпретатор,
генерация изображений) только когда это действительно необходимо
для ответа. Если можешь ответить на основе своих знаний без
дополнительных инструментов - отвечай сразу, не вызывая их.

Без такой инструкции модели иногда демонстрируют избыточное усердие — вызывают веб-поиск для вопросов, ответ на которые не менялся годами, что впустую расходует ёмкость сервиса и замедляет ответ без реальной пользы для пользователя.

Частые ошибки и как их избежать

  • Код-интерпретатор в одном контейнере с моделью. Экономия на инфраструктуре, которая аукается при первой же нештатной генерации кода. Всегда выноси выполнение кода в отдельный изолированный контейнер без сетевого доступа.
  • Плагины включены всем пользователям сразу. Веб-поиск и генерация изображений нагружают внешние сервисы и сеть; код-интерпретатор нагружает CPU. Включай плагины по группам, начиная с ограниченного пилота.
  • Нет логирования запросов плагинов отдельно от чата. Если через полгода спросят «кто и зачем искал в интернете такой-то запрос», без отдельных логов plugin-уровня ответить будет нечем.
  • Плагины сторонних разработчиков ставятся без ревью кода. Функция из community hub выполняется с теми же правами, что и весь сервис, и может содержать как ошибки, так и намеренно вредоносный код. Всегда читай исходники перед установкой, даже если это займёт лишние десять минут.

Настройка лимитов специфично для каждого плагина

Общий rate limiting на уровне API (см. отдельную статью про защиту от злоупотреблений) не всегда учитывает разную стоимость разных плагинов. Веб-поиск и генерация изображения — это, по сути, отдельные внешние вызовы со своей стоимостью и задержкой, поэтому разумно лимитировать их отдельно от обычных текстовых запросов к модели.

# отдельные зоны лимитов для ресурсоёмких плагинов в nginx
limit_req_zone $http_x_user_id zone=web_search_limit:10m rate=10r/m;
limit_req_zone $http_x_user_id zone=image_gen_limit:10m rate=5r/m;
limit_req_zone $http_x_user_id zone=code_exec_limit:10m rate=15r/m;

location /api/plugins/web_search {
    limit_req zone=web_search_limit burst=3 nodelay;
    proxy_pass http://srv-ai01.itpages.lab.local:8080;
}

location /api/plugins/image_generation {
    limit_req zone=image_gen_limit burst=2 nodelay;
    proxy_pass http://srv-ai01.itpages.lab.local:8080;
}

Генерация изображений особенно чувствительна к лимитам — одно изображение в высоком разрешении на Stable Diffusion XL может занимать GPU на 10-20 секунд, и без ограничения параллельности несколько одновременных запросов от разных пользователей легко создают очередь, заметную даже для обычного текстового чата, если генерация делит GPU-память с основной моделью.

Что дальше

Свой AI-сервер редко ограничивается одной настройкой — вот что обычно идёт следом:

Автор — Команда IT-Pages