Агентный RAG в Open WebUI: локальные документы, поиск и проверка цитат

В чём здесь агентный RAG?

В обычном поиске с генерацией приложение может заранее выбрать фрагменты из файла и вложить их в запрос к модели. В агентном режиме модель сама решает, вызвать ли инструмент поиска, а Open WebUI исполняет его и возвращает найденный материал. Для базы, прикреплённой к модели или папке в Native, содержимое не поступает заранее: без Builtin Tools ответ по документу может оказаться ответом по памяти модели s1s2. Это не гарантия, что конкретная локальная модель всегда сделает нужный вызов: решение нужно наблюдать в трассе чата.

Интент этой страницы — готовый интерфейс Knowledge Base внутри Open WebUI. Если нужен собственный код условной маршрутизации, см. отдельный граф LangGraph. Если Open WebUI ещё не установлен, сначала откройте базовое руководство. Не смешивайте настройку RAG и установку сервера.

Что подготовить до загрузки документа?

Нужны работающий Open WebUI, подключённый локальный inference-сервер и чат-модель с проверенной на ваших задачах поддержкой native function calling. Официальное руководство показывает путь управления Ollama через Settings → Admin → Connections; это лишь способ подключить провайдера, а не проверка того, что модель правильно вызывает поиск s6s3. На одном устройстве чат-модель, модель embeddings и извлечение текста — разные звенья; проверьте провайдеров в Admin Settings → Documents, прежде чем называть весь стек локальным s7. Размер файла модели нельзя превращать в минимальное требование RAM/VRAM. Подбирайте конкретный вариант по собственному железу и условиям использования.

Для учебного опыта создайте вымышленный TXT-файл со строками вроде:

DEMO-417: срок обработки четыре рабочих дня.
DEMO-932: срок обработки семь рабочих дней.

Это синтетические данные, не клиентский документ и не наш выполненный прогон. Они дают буквальный маркер, который можно найти в исходнике и отличить от вероятной догадки модели. Для сканированного PDF сначала отдельно убедитесь, что текст извлечён; простой текстовый файл помогает не путать ошибку OCR с ошибкой поиска s4.

Как создать Knowledge Base и сделать поиск доступным модели?

1. Откройте Workspace → Knowledge → Create, дайте базе понятное имя, загрузите тестовый TXT и дождитесь конца обработки. Документация допускает также текстовый PDF. Незавершённая загрузка не подтверждает индексацию s1.
2. Прикрепите базу к модели через Workspace → Models → Edit, чтобы ограничить круг просматриваемых коллекций; для разового вопроса можно прикрепить её в чат через #, но эти два способа не полностью эквивалентны s1s2. Выберите Focused Retrieval, если хотите проверить поиск отдельных фрагментов. Full Context передаёт весь короткий документ и не является тестом работы поискового инструмента s1.
3. Убедитесь, что Function Calling = Native, Builtin Tools включены и категория Knowledge Base доступна этой модели. Native — режим по умолчанию согласно документации для актуальной ветки; старый Legacy описан как неподдерживаемый и не равен агентному поиску s1s3s8. Не включайте сторонние Workspace Tools или внешние MCP-серверы ради поиска по одному тестовому TXT: встроенных knowledge-инструментов достаточно s3.
4. Задайте модели узкое правило: «Для фактов о DEMO обращайся к прикреплённой базе; укажи номер документа и дословную строку, а если ответа нет — сообщи об отсутствии». Это инструкция для теста, не доказательство исполнения инструмента. Посмотрите в интерфейсе чата, был ли вызов query_knowledge_files; для буквального идентификатора может помочь grep_knowledge_files, а view_file читает строки вокруг найденного места s1. Названия и наличие инструментов зависят от версии и конфигурации.

Важная развилка: матрица File Context/Builtin Tools в документации относится к файлу или базе, прикреплённой в чате. Когда база прикреплена к модели/папке, Native не подставляет её заранее при любом состоянии File Context. Сочетание выключенных Builtin Tools и Native оставит такую базу недоступной; прикрепление в чат может привести к предварительной подстановке, а не к вызову инструмента s2. Поэтому для чистого теста агентного поиска прикрепите базу к модели, оставьте Builtin Tools включёнными и ищите наблюдаемый вызов, а не только правдоподобный ответ.

Как понять, что ответ опирается на нужный фрагмент?

Спросите: «Сколько дней занимает обработка DEMO-417 по загруженному документу?» Зафиксируйте три отдельных события: (1) вызов knowledge-инструмента в чате; (2) фрагмент с DEMO-417 и строкой «четыре рабочих дня» в результате поиска; (3) ответ, утверждение и указанную ссылку на источник. Затем вручную сравните их с исходным TXT. Open WebUI документирует цитаты как указатели на переданный контекст, но наличие ссылки само по себе не доказывает соответствие конкретного утверждения первоисточнику s1s2. Не называйте успешным тест, в котором модель просто написала «я поискал» без результата инструмента.

Контрастный вопрос: «Какой срок у DEMO-999?» — такого маркера в учебном файле нет. Ожидаемое поведение — поиск и честное сообщение об отсутствии подтверждения; число, сгенерированное без источника, провал проверки. Для приветствия вызов поиска не обязателен. Если даже простой вопрос не вызывает инструмент, проверьте режим Function Calling, категорию Builtin Tools, прикрепление базы, доступ текущего пользователя, завершённость обработки и предел контекста модели s4. Не делайте вывод о качестве RAG по одному вопросу: следующий шаг — набор проверок поиска и цитат.

Что меняется для приватных баз и полностью локального контура?

Область поиска и права — разные свойства. Прикреплённая к модели база ограничивает поиск по этому набору, а без привязки модель может обнаружить другие базы, доступные текущему пользователю. Права на ресурс задавайте отдельно: Private и явный Read для нужных пользователей или групп. Проверьте тест под разрешённой и запрещённой учётными записями, в том числе после изменения прав; один доступ к общей модели не означает автоматического права читать приватную базу s1s5. Этот тест — инструкция читателю, не проверка Modelium. Не загружайте рабочие договоры, пока не подтверждены и права, и обработка данных.

Локальный адрес Ollama не доказывает отсутствие облачных embeddings, внешнего OCR, reranking, авторизации или исходящих запросов инструмента. Официальная offline-инструкция требует заранее подготовить локальные зависимости и отдельно ограничить сеть: OFFLINE_MODE и HF_HUB_OFFLINE не являются файрволом s7. При смене embedding-модели существующие документы нужно переиндексировать; отсутствие результата сначала расследуйте на уровне извлечения текста, индекса и области доступа, а не называйте сразу галлюцинацией модели s4. Экспериментальный kb_exec выключен по умолчанию и не требуется для базового теста query_knowledge_files s1.

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