База знаний в Open WebUI: настройка RAG на своих документах

Open WebUI RAG позволяет загрузить свои документы и спрашивать по ним модель, не вставляя тексты в чат вручную. Это удобно для внутренних инструкций, договоров и справочников. Ниже: как создать базу знаний, какие настройки влияют на качество, как выбрать модель через шлюз и сколько стоит один вопрос.

Описание основано на документации Open WebUI (раздел Knowledge и страница про устранение проблем с RAG). Интерфейс и настройки в нём меняются между версиями, поэтому названия пунктов сверяйте с вашей установкой.

Open WebUI RAG: как это устроено

RAG (retrieval augmented generation) работает в три шага. Документ разбивается на куски, для каждого куска строится вектор (эмбеддинг), а при вопросе Open WebUI находит самые близкие по смыслу куски и подставляет их в запрос к модели. Модель отвечает уже с этим текстом перед глазами. Эмбеддинг — это список чисел, который описывает смысл текста. Важно, что на этом пути участвуют две разные модели.

• Модель эмбеддингов превращает текст в векторы. По умолчанию в Open WebUI это небольшая локальная модель (в документации упомянута all-MiniLM-L6-v2), а при желании можно выбрать модель через Ollama или OpenAI.
• Чат-модель читает найденные куски и отвечает. Вот её вы подключаете через шлюз.

В документации шлюза в перечне эндпоинтов эмбеддингов нет, поэтому оставьте эмбеддинги на встроенной модели или подключите отдельный источник. Чат-модель при этом может быть любой: Claude, GPT, DeepSeek и другие.

Шаг 1. Подключите модель

В Open WebUI откройте Settings, Admin, Connections, добавьте подключение OpenAI-совместимого API. В поле адреса укажите https://api.zukko.pro/v1, в поле ключа — ваш ключ fetch_.... Если проверка подключения выдаёт ошибку, документация Open WebUI советует вписать идентификаторы моделей в список вручную: чат от этого работать не перестанет. Подробная настройка — в статье Open WebUI: подключение к Zukko↗.

Шаг 2. Создайте базу знаний

По документации Open WebUI:

1. Откройте Workspace, Knowledge и нажмите Create. Задайте имя и описание.
2. Загрузите небольшой текстовый PDF или текстовый файл и дождитесь окончания обработки.
3. В чате вызовите базу через # или прикрепите её к модели в Workspace, Models, Edit.
4. Задайте вопрос, ответ на который есть в файле, и попросите процитировать фрагмент.

Первый тест всегда делайте на документе, где вы знаете ответ. Так сразу видно, видит ли модель содержимое.

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

Шаг 3. Выберите режим поиска

Для прикреплённых документов есть два режима, переключаются по клику на прикреплённый элемент.

• Focused Retrieval (по умолчанию). Находит и подставляет только самые подходящие куски. Подходит для больших наборов документов.
• Full Context. Подставляет документ целиком при каждом сообщении. Подходит для коротких справочников, которые нужны всегда.

Есть нюанс, который нужно знать заранее. В режиме нативного вызова функций (в текущих версиях он включён по умолчанию) привязанные к модели знания автоматически не вставляются: модель должна сама вызвать инструменты поиска по базе. Если она этого не делает, документация предлагает добавить в системный промпт указание пользоваться поиском по знаниям, выбрать модель, которая надёжно вызывает инструменты, либо переключить вложение в режим Full Context. Каждый вызов инструмента — это дополнительный запрос и дополнительные токены.

Шаг 4. Настройте разбиение и поиск

Параметры находятся в Settings, Admin, Documents. Документация Open WebUI приводит рекомендации под разные сценарии. Для облачных моделей с большим контекстом:

Для локальных моделей с маленьким окном (до 8K токенов) значения скромнее: чанк 1000, перекрытие 100, Top K от 3 до 5. Логика проста: чем больше кусков вы подставляете, тем больше входных токенов тратится и тем больше нужно окна у модели.

Дополнительно проверьте две вещи:

• Извлечение текста. Если модель «не видит» документ, чаще всего виноват не поиск, а плохо извлечённый текст. Документация советует использовать надёжный движок (Apache Tika, Docling) и посмотреть извлечённый текст в предпросмотре. Пустой или обрезанный текст нужно чинить до всего остального.
• Смена модели эмбеддингов. После смены нужно переиндексировать базу, иначе старые векторы окажутся несовместимыми с новыми. Смена размера чанка не требует переиндексации, но для единообразия её рекомендуют.

Сколько стоит вопрос по документам

Допустим, справочник занимает 60 000 токенов, и по нему задают 30 вопросов. Формула: токены входа × цена входа. Выход (ответ) считается отдельно, здесь его не учитываем. Цены на 18 октября 2026.

Сценарий А, Full Context: 60 000 × 30 = 1 800 000 токенов входа. Сценарий Б, Focused Retrieval: 5 кусков по 1000 токенов плюс вопрос и контекст, примерно 5 500 токенов на вопрос, итого 5 500 × 30 = 165 000 токенов.

Два замечания. Первое: Open WebUI общается со шлюзом в OpenAI-формате. Для GPT-моделей шлюз видит чтение кэша, поэтому при повторяющемся Full Context часть входа может пойти по цене чтения кэша (у gpt-6.1-sol $0.013 вместо $0.27 за 1M), и реальный счёт окажется ниже таблицы. Для Claude в этом формате весь вход идёт по цене входа, ровно как в таблице. Второе: цифры показывают порядок, а не прогноз, потому что реальный размер контекста зависит от вашего диалога. Какая модель лучше отвечает по вашим документам, проверяйте на своих вопросах. Подробнее про кэш — в документации по лимитам и кэшу↗.

Как поднять качество ответов

• Переформулируйте вопросы под документ, чтобы в них были термины из текста: поиск идёт по смыслу, но редкие термины помогают.
• Не заливайте в одну базу всё подряд. Привяжите к модели только нужные базы, тогда поиск не отвлекается на лишнее.
• Просите цитату и источник. Если ответ расходится с цитатой, ищите причину в извлечённом тексте или в параметрах разбиения.
• Для маленьких документов попробуйте Full Context: при большом окне модели он нередко надёжнее поиска по кускам, но стоит дороже на каждый вопрос, как видно из таблицы.
• Если вы запускаете модель на Ollama, проверьте окно контекста: по документации, на видеокартах до 24 ГиБ по умолчанию оно равно 4096 токенов, и найденные куски просто не помещаются.

Про локальные сервера вроде LM Studio: Open WebUI подключает любой сервер с OpenAI-совместимым API, так что RAG работает и с ними, но детали подключения смотрите в документации самого инструмента. Общую схему поиска по базе знаний на дешёвой модели описывает статья RAG на дешёвой модели без векторной БД↗.

Частые вопросы

Нужна ли отдельная векторная база?

Нет. Open WebUI хранит векторы сам; в документации перечислены поддерживаемые хранилища, включая ChromaDB и PGVector. Свою векторную базу можно подключить как внешний источник знаний, но для начала это не требуется.

Какую модель выбрать для ответов по документам?

Подойдёт любая с достаточным окном и надёжным вызовом инструментов. По цене входа выгоднее всего дешёвые модели, например deepseek-v4.1-flash, но качество проверьте на своих документах и вопросах.

Почему модель отвечает «не нашёл в документах», хотя ответ там есть?

Проверьте, что обработка файла завершилась, что текст извлечён полностью, что база прикреплена к модели и что модель вызывает инструменты поиска. Если нет, переключите вложение в Full Context для проверки.

Сколько стоит загрузка документов?

Сама загрузка и построение эмбеддингов на встроенной модели не расходуют баланс шлюза. Платными становятся только запросы к чат-модели.

Чтобы попробовать, создайте ключ в кабинете↗ и подключите его к Open WebUI. Параметры запроса к чат-модели описаны в справочнике chat completions↗.