Введение

Open WebUI предоставляет встроенную интеграцию с веб-поиском для обогащения ответов LLM актуальной информацией из интернета. Однако стандартная конфигурация часто приводит к проблеме «недостаточного контекста»: модель делает один поиск, получает фрагментарные сниппеты и не может полноценно ответить на вопрос 1. Данный обзор исследует три ключевых направления: выбор оптимального провайдера поиска, правильную настройку контекста и реализацию мультишагового итеративного поиска.

Архитектура веб-поиска в Open WebUI

Два режима работы

Open WebUI поддерживает два принципиально разных подхода к веб-поиску 2:

Традиционный RAG-режим (Default Mode) работает по схеме: генерация поисковых запросов → выполнение поиска → извлечение контента → разбиение на чанки → векторизация → семантический поиск релевантных фрагментов → инъекция в промпт. Этот режим подходит для простых вопросов, но теряет контекст при chunking и embedding 2.

Агентный режим (Native Function Calling) — принципиально другой подход, где модель сама решает когда искать, что искать и когда углубляться 3. Модель получает два инструмента — search_web (поиск) и fetch_url (получение полного содержимого страницы) — и автономно выполняет цикл: THINK → ACT → EVALUATE → DECIDE → ITERATE 3. Этот режим доступен только для frontier-моделей (GPT-5, Claude 4.5+, Gemini 3+) 3.

«By enabling Native Function Calling (Agentic Mode), you allow quality models to independently explore the web, verify facts, and follow links autonomously» 3.

Ключевые различия режимов

АспектТрадиционный RAGАгентный (Native)
Решение о поискеСистемаМодель
Обработка данныхChunking → Vector DB → Top-KСниппеты напрямую
Исследование ссылокТолько сниппетыПолные страницы через fetch_url
Контекстное окноTop-K чанковДо 50 000 символов на fetch
ИтеративностьОдин циклМногошаговые циклы поиска

Генерация поисковых запросов

В обоих режимах Open WebUI использует LLM для генерации 1-3 поисковых запросов на основе истории чата. Шаблон генерации настраивается через Admin Panel → Settings → Interface → Query Generation Prompt или переменную окружения QUERY_GENERATION_PROMPT_TEMPLATE 4. Формат ответа — JSON: {"queries": ["query1", "query2"]}.

По умолчанию шаблон «приоритизирует генерацию 1-3 широких и релевантных запросов, если нет уверенности, что дополнительная информация не нужна» 4.

Сравнение провайдеров поиска

Open WebUI поддерживает более 20 провайдеров веб-поиска 5. Критически важное различие между ними — возвращают ли они полное содержимое страниц или только сниппеты.

Провайдеры с полным контентом

Tavily — AI-ориентированный поисковый API, рекомендуемый для агентных систем 6. При включении параметра include_raw_content=true возвращает полный очищенный контент каждой страницы в формате markdown 7. Поддерживает два режима глубины: basic (1 кредит) и advanced (2 кредита). Бесплатный тариф — 1000 кредитов/месяц 7. Отдельный Extract API позволяет извлекать контент из конкретных URL (5 URL = 1 кредит) 8.

Ключевое преимущество Tavily: единый API-вызов выполняет и поиск, и извлечение контента — не нужно отдельно загружать каждую страницу 6.

Exa AI — семантический поисковый движок с собственным нейронным индексом 9. Показывает лучшие результаты на RAG-бенчмарках: 81% качества retrieval против 71% у Tavily 9. Возвращает query-dependent highlights — наиболее релевантные пассажи, а не статический контент, что на 50-75% сокращает количество токенов для LLM 9. При этом работает в 2-3 раза быстрее Tavily 9. Стоимость — $5/1000 поисков + $1/1000 страниц.

Jina Search — бесплатный сервис с двумя режимами работы 10. Search Mode (s.jina.ai/query) выполняет поиск и автоматически извлекает контент из топ-5 результатов в markdown. Reader Mode (r.jina.ai/url) конвертирует отдельную страницу в LLM-friendly текст. Бесплатный тариф — 10 млн токенов/месяц, API-ключ для базового поиска не требуется 10.

SearXNG — self-hosted метапоисковик, агрегирующий результаты из 200+ поисковых систем 11. Полностью контролируется пользователем, бесплатен. Для получения полного контента требуется настройка: формат вывода JSON, лимит слов через PAGE_CONTENT_WORDS_LIMIT, настройка таймаутов через TRAFILATURA_TIMEOUT 11.

Провайдеры, возвращающие только сниппеты

ПровайдерСтоимостьОсобенности
Brave Search$5/мес бесплатно + $5/1000 запросовНезависимый индекс, требует sequential requests на бесплатном тарифе 12
Serper$1/1000 запросовSERP-обёртка Google 6
DuckDuckGo (DDGS)БесплатноПриватный поиск, без API-ключа 5
BingMicrosoft-интеграцияСтандартный веб-поиск 5
Google PSEDeprecated (закрытие в январе 2027)Не рекомендуется для новых проектов 6
KagiПодпискаПремиальный поиск 5

Сравнительный анализ для 10 000 запросов/месяц

ПровайдерСтоимостьПолный контентКачество RAG
JinaБесплатноДа (топ-5)Хорошее
SearXNGБесплатно (self-host)Да (настраиваемо)Зависит от движков
Tavily~$24 (basic)Да71%
Exa AI~$50Да (highlights)81%
Brave~$40-50Нет60-65%
Serper~$50Нет60-65%

Проблема «недостаточного контекста» и её решение

Корневые причины

Проблема «модель говорит, что контекста недостаточно» имеет несколько типичных причин 13 14:

  1. Малое контекстное окно модели. Ollama по умолчанию использует 2048 токенов, тогда как веб-страницы после извлечения содержат 4000-8000+ токенов 2. При таком лимите большая часть контента просто обрезается.

  2. Потеря информации при chunking. В RAG-режиме контент разбивается на чанки, векторизуется, и только Top-K фрагментов попадают в промпт. Релевантная информация может оказаться в отброшенных чанках 14.

  3. Один поисковый запрос. Система генерирует 1-3 запроса и делает один раунд поиска. Для сложных вопросов этого часто недостаточно.

  4. Сниппеты вместо полного контента. Многие провайдеры (Brave, Serper, DuckDuckGo) возвращают только короткие описания, а не содержимое страниц 6.

Рекомендуемые настройки

Контекстное окно модели. Увеличить до 16384+ токенов: Admin Panel → Models → Settings → Advanced Parameters 2. Для работы с веб-контентом значение ниже 8192 неприемлемо.

Параметры RAG. В Admin Panel → Settings → Documents:

  • Chunk Size — размер чанка при разбиении (рекомендуется увеличить для веб-контента)
  • Chunk Overlap — перекрытие между чанками (помогает сохранить контекст)
  • Top K — количество возвращаемых чанков (увеличить для большего покрытия) 14

Количество результатов поиска. Переменная RAG_WEB_SEARCH_RESULT_COUNT определяет сколько результатов загружается (по умолчанию 5). Известный баг: встроенный инструмент search_web имеет жёстко заданное значение 5, игнорируя эту настройку 15.

Инъекция контекста. Переменная RAG_SYSTEM_CONTEXT=True перемещает RAG-контекст в системное сообщение вместо пользовательского 2. Это позволяет провайдеру кэшировать контекст и ускоряет последующие запросы. Рекомендуется для Ollama, llama.cpp, OpenAI и Vertex AI 2.

Bypass Embedding and Retrieval. Режим, при котором полный контент отправляется модели без chunking и векторного поиска. Полезен когда нужно гарантировать, что модель видит весь загруженный контент 14.

Web Loader Engine. Выбор движка для извлечения контента из страниц: Tavily, Playwright (для JS-heavy сайтов), Firecrawl (профессиональная экстракция) 5. Настраивается через WEB_LOADER_ENGINE.

Агентный режим: мультишаговый поиск «из коробки»

Настройка Native Function Calling

Для активации агентного поиска в Open WebUI необходимо 3:

  1. Включить Web Search глобально: Admin Panel → Settings → Web Search → выбрать провайдер и ввести API-ключ
  2. Включить capability для модели: Admin Panel → Settings → Models → выбрать модель → включить Web Search в Capabilities
  3. Включить Default Feature: В той же модели отметить Web Search в Default Features (оба параметра обязательны — без любого из них инструменты не будут доступны) 3
  4. Активировать Native Mode: Advanced Parameters → Function Calling → Native

Как работает итеративный цикл

В агентном режиме модель автономно выполняет цикл 3:

  1. THINK — определяет пробелы в знаниях
  2. ACT — вызывает search_web или fetch_url
  3. EVALUATE — оценивает качество полученной информации
  4. DECIDE — нужно ли продолжать исследование
  5. ITERATE — уточняет запросы или синтезирует финальный ответ

«The iterative loop of Thought → Action → Thought continues until the model has sufficient information to answer your request» 3.

Модель может вызывать search_web многократно, уточняя запросы на основе предыдущих результатов, а через fetch_url загружать полные страницы (до 50 000 символов) 3.

Ограничения агентного режима

  • Требует frontier-моделей: маленькие локальные модели не справляются с многошаговым рассуждением 3
  • Нет контроля над количеством итераций: модель сама решает когда остановиться
  • Непредсказуемая длительность: от нескольких секунд до минут
  • Зависимость от качества reasoning: модель может зациклиться или остановиться слишком рано

Пользовательские решения: Deep Research Tools

Для случаев, когда агентный режим недоступен (локальные модели) или недостаточно контролируем, существуют community-решения.

research-openwebui (teodorgross)

Асинхронный инструмент для Open WebUI, реализующий итеративный поиск через SearXNG 16:

  • Максимум 5 итераций с пагинацией
  • Автоматическое уточнение запроса: если в итерации получено менее 3 валидных результатов, запрос модифицируется и поиск повторяется 16
  • Параллельная обработка: результаты обрабатываются через ThreadPoolExecutor
  • Конфигурируемые параметры (Valves): URL SearXNG, игнорируемые сайты, лимит слов на страницу, количество результатов 16

Ограничения: репозиторий архивирован, уточнение запросов использует предопределённые фразы а не AI-генерацию, работает только с SearXNG 16.

Haervwe/open-webui-tools

Модульный набор из 20+ инструментов для Open WebUI 17, включающий:

  • arXiv Search — поиск академических статей без API-ключа
  • arXiv Research MCTS — итеративный исследовательский процесс через Monte Carlo Tree Search: систематическое исследование темы через ветвящиеся пути запросов с вероятностной оценкой перспективных направлений 17
  • Perplexica Search — веб-поиск с цитированием источников

deep-research-web-ui (AnotiaWang)

Standalone веб-приложение (не плагин Open WebUI), реализующее итеративный deep research через комбинацию поисковых движков, веб-скрапинга и LLM 18.

Паттерны мультишагового поиска

Архитектуры итеративного поиска

Исследования в области agentic RAG выделяют три основные архитектуры 19 20:

Последовательная (Sequential): поиск → анализ → уточнение запроса → повторный поиск. Наиболее гибкая, позволяет адаптировать стратегию после каждой итерации. Используется в Perplexity AI (3-4 итерации, 30-90 секунд) 21.

Параллельная (Parallel): декомпозиция вопроса на подвопросы → одновременный поиск по всем → синтез. Самая быстрая, подходит для структурированных запросов. Исследование ParallelSearch показывает значительное ускорение без потери качества 22.

Гибридная (Hybrid): параллельная декомпозиция + последовательное углубление. Используется в MindSearch (InternLM) — 2-3 итерации, 15-60 секунд 23. Оптимальна для сложных исследовательских вопросов.

Декомпозиция вопросов

Два подхода к разбиению вопроса 20:

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

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

Критерии остановки

Практика production-систем показывает оптимум в 3-5 итерациях 19 21. Рекомендуемые критерии остановки (использовать 2+ одновременно):

  1. Максимум итераций — жёсткий лимит (обычно 5)
  2. Отсутствие новых документов — поиск не возвращает неизвестных ранее результатов
  3. Конвергенция информации — менее 50% новизны в последней итерации
  4. Порог уверенности — модель оценивает достаточность информации (0.85+)
  5. Исчерпание бюджета токенов — при контексте 4-8K безопасно 3 итерации, максимум 5

Обработка противоречий

Исследование DRAGged into Conflicts 24 выделяет таксономию из 5 типов конфликтов:

  1. Нет конфликта → прямой ответ
  2. Дополняющая информация → синтез
  3. Противоречащие мнения → представить множественные позиции
  4. Устаревшая информация → приоритет свежим источникам
  5. Дезинформация → отфильтровать

Исследование Madam-RAG 25 показывает, что мультиагентный дебат (несколько LLM обсуждают противоречия) улучшает точность на 9-24 пункта по сравнению с одноагентным подходом.

Рекомендации по конфигурации

Для текущей установки (SearXNG + Tavily)

Проблема: SearXNG возвращает ссылки и сниппеты, Tavily используется как web loader, но один раунд поиска недостаточен для сложных вопросов.

Рекомендация 1 — переключиться на агентный режим (если используются frontier-модели):

  1. Установить Tavily как провайдер поиска (вместо SearXNG) — он возвращает и сниппеты, и полный контент одним запросом 7
  2. Включить Native Function Calling в настройках модели 3
  3. Модель получит возможность итеративного поиска «из коробки»

Рекомендация 2 — для локальных моделей (если frontier-модели недоступны):

  1. Оставить SearXNG как поисковый движок
  2. Установить community-инструмент deep research (research-openwebui или аналог) 16
  3. Увеличить контекстное окно модели до 16384+ токенов 2
  4. Включить RAG_SYSTEM_CONTEXT=True для кэширования 2
  5. Увеличить Top-K значение в Documents → Query Params 14

Оптимальный выбор провайдера

СценарийРекомендация
Frontier-модели + максимальное качествоExa AI — лучший RAG-скор (81%), query-dependent highlights 9
Frontier-модели + простота настройкиTavily — единый API для поиска и контента, хорошая интеграция 7
Локальные модели + бюджетJina Search — бесплатно, полный контент, markdown 10
Полный контроль + приватностьSearXNG — self-hosted, 200+ движков 11
Максимальная экономияSearXNG (поиск) + Jina Reader (контент) — полностью бесплатно

Переменные окружения: чеклист

# Провайдер поиска
RAG_WEB_SEARCH_ENGINE=tavily          # или searxng, jina, exa, brave
RAG_WEB_SEARCH_RESULT_COUNT=10        # количество результатов (по умолчанию 5)

# Контекст
RAG_SYSTEM_CONTEXT=True               # инъекция в system message для кэширования

# Web Loader (для извлечения контента из URL)
WEB_LOADER_ENGINE=tavily              # или playwright, firecrawl
WEB_LOADER_CONCURRENT_REQUESTS=4

# SSL и прокси
ENABLE_WEB_LOADER_SSL_VERIFICATION=True
WEB_SEARCH_TRUST_ENV=True             # для прокси

# Последовательные запросы (для Brave free tier)
WEB_SEARCH_CONCURRENT_REQUESTS=1

Создание собственного мультишагового агента

Архитектура решения

Для реализации мультишагового поиска с декомпозиция вопросов в Open WebUI оптимальный подход — создание Custom Tool (Python) с использованием Native Function Calling 3 16:

Пользовательский вопрос
    ↓
[Декомпозиция] → Подвопрос 1, Подвопрос 2, Подвопрос 3
    ↓
[Параллельный поиск] по каждому подвопросу
    ↓
[Анализ результатов] → Достаточно информации?
    ↓ Нет                         ↓ Да
[Генерация новых вопросов]    [Синтез ответа]
    ↓
[Повторный поиск] (макс. 3-5 итераций)
    ↓
[Финальный синтез с цитированием]
    или
[Явное указание на недостаток информации]

Ключевые принципы реализации

  1. Декомпозиция перед поиском: вместо одного запроса генерировать 3-5 подвопросов, покрывающих тему с разных сторон
  2. Итеративное углубление: после каждого раунда поиска оценивать пробелы и генерировать новые запросы
  3. Жёсткий лимит итераций: максимум 5 раундов поиска, при исчерпании — честно сообщить пользователю о нехватке данных
  4. Критерий минимальных результатов: если за итерацию получено менее 3 валидных результатов — уточнить запрос 16
  5. Цитирование: каждый факт в финальном ответе должен иметь ссылку на источник
  6. Прозрачность: статус-обновления о ходе поиска на каждом этапе

Существующие реализации как отправная точка

Для создания собственного решения стоит изучить:

  • research-openwebui 16 — готовая реализация итеративного поиска через SearXNG, можно использовать как основу
  • Haervwe/open-webui-tools 17 — коллекция инструментов с паттерном MCTS для исследований
  • Встроенный агентный режим Open WebUI 3 — для frontier-моделей уже реализует итеративный поиск, может быть достаточно правильной конфигурации

Дискуссионные вопросы и противоречия

RAG vs Native Function Calling

Сообщество Open WebUI обсуждает переход от RAG-подхода к Native Function Calling 26. RAG-режим дробит контент на чанки и теряет информацию, тогда как Native режим передаёт сниппеты напрямую, но требует мощных моделей. Пользователь в discussion #8990 обнаружил, что «отключение веб-поиска давало лучшие результаты, чем его использование с маленькими моделями» 14.

Количество результатов: больше — не значит лучше

Увеличение RAG_WEB_SEARCH_RESULT_COUNT до 50 не улучшает качество — модель всё равно не может обработать весь контекст 14. Оптимум — 5-10 результатов с полным контентом лучше, чем 50 сниппетов.

SearXNG vs коммерческие API

SearXNG бесплатен и приватен, но качество результатов зависит от выбора движков и инфраструктуры. Коммерческие API (Tavily, Exa) предоставляют предварительно отранжированные результаты с извлечённым контентом, что упрощает интеграцию 6 9.

Токенный бюджет итеративного поиска

При контексте 8K токенов каждая итерация поиска потребляет 2000-2500 токенов, что ограничивает безопасное число итераций до 3 19. Для 5 итераций требуется контекст 16K+. Это создаёт trade-off между глубиной исследования и стоимостью/скоростью.

Метрики качества

МетрикаЗначение
Источников найдено27
Источников процитировано26
Типы источниковofficial: 8, industry: 6, community: 7, academic: 3, blog: 3
Покрытие цитированием~95%
Исследовано подвопросов6

  1. Web search does not provide all information retrieved to the model — GitHub Discussion #8990 ↩︎

  2. Retrieval Augmented Generation (RAG) — Open WebUI Docs ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. Agentic Search & URL Fetching — Open WebUI Docs ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. Where can I customize the prompt given to the agent during generation of web search queries? — GitHub Discussion #13159 ↩︎ ↩︎

  5. Web Search — Open WebUI Docs ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. Best Web Search APIs for AI Applications — Firecrawl Blog ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. Tavily Search API Documentation ↩︎ ↩︎ ↩︎ ↩︎

  8. Tavily Extract API Documentation ↩︎

  9. Exa vs Tavily Comparison ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  10. Jina Reader API ↩︎ ↩︎ ↩︎

  11. SearXNG Documentation ↩︎ ↩︎ ↩︎

  12. Brave Search API — Use with Open WebUI ↩︎

  13. Web Search Troubleshooting — Open WebUI Docs ↩︎

  14. Web search does not provide all information — GitHub Discussion #8990 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  15. Built-in search_web tool ignores WEB_SEARCH_RESULT_COUNT — GitHub Issue #21371 ↩︎

  16. research-openwebui — GitHub (teodorgross) ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  17. open-webui-tools — GitHub (Haervwe) ↩︎ ↩︎ ↩︎

  18. deep-research-web-ui — GitHub (AnotiaWang) ↩︎

  19. A Survey of LLM-based Deep Search Agents — arXiv ↩︎ ↩︎ ↩︎

  20. PRISM: Agentic Retrieval with LLMs for Multi-Hop QA — arXiv ↩︎ ↩︎

  21. Architecting and Evaluating an AI-First Search API — Perplexity Research ↩︎ ↩︎

  22. ParallelSearch: Query Decomposition — arXiv ↩︎

  23. MindSearch — GitHub (InternLM) ↩︎

  24. DRAGged into Conflicts: Taxonomy-based Conflict Detection — arXiv ↩︎

  25. Retrieval-Augmented Generation with Conflicting Evidence (Madam-RAG) — arXiv ↩︎

  26. Native vs Default Functions/Tools/Web Search/RAG — GitHub Discussion #19326 ↩︎