Локальная нейросеть для PDF и документов: Ollama, Open WebUI и RAG без облака

Что такое RAG и зачем он нужен для PDF

RAG — Retrieval-Augmented Generation, то есть генерация с дополнением найденным контекстом. Его задача — дать модели факты из документов, которых нет в её исходных знаниях.

Если просто сказать LLM «ответь по моему договору», она ничего не знает о файле, пока текст договора не попадёт в её контекст. Для небольшого документа можно передать весь текст целиком. Для сотен страниц это дорого по памяти и контексту, поэтому используется retrieval.

Из чего состоит локальная система вопросов по документам

Для первого домашнего стенда отдельный Qdrant или PostgreSQL не обязателен. Open WebUI умеет работать со своей встроенной инфраструктурой хранения. Внешняя vector database становится полезна при больших коллекциях, нескольких workers или уже существующем корпоративном индексе.

Что понадобится

• ПК или сервер с Windows, Linux или macOS;
• Ollama с локальной языковой моделью;
• Docker Desktop или Docker Engine для простого запуска Open WebUI;
• несколько гигабайт свободного диска под модели и документы;
• embedding-модель или встроенный SentenceTransformers Open WebUI;
• нормально извлекаемый текст документа либо OCR для сканов.

Если Ollama ещё не установлена, начните с отдельного гайда «Ollama на Windows: установка и первый запуск».

Как установить Open WebUI рядом с Ollama

Официальная документация Open WebUI рекомендует Docker как простой способ запуска. Если Ollama уже установлена на Windows как обычное приложение, контейнеру Open WebUI нужно разрешить обращаться к host через host.docker.internal.

docker run -d ^
  -p 3000:8080 ^
  --add-host=host.docker.internal:host-gateway ^
  -v open-webui:/app/backend/data ^
  -e WEBUI_SECRET_KEY=ЗАДАЙТЕ_СВОЙ_ДЛИННЫЙ_СЕКРЕТ ^
  --name open-webui ^
  --restart always ^
  ghcr.io/open-webui/open-webui:main

В PowerShell перенос строки обычно удобнее делать обратной кавычкой, а в CMD — символом ^. Если не хотите разбираться с переносами, команду можно выполнить одной строкой.

После запуска откройте:

Том open-webui:/app/backend/data обязателен, если нужно сохранять пользователей, чаты, настройки и индекс после пересоздания контейнера.

Как подключить Open WebUI к Ollama

Когда Ollama работает на том же компьютере, Open WebUI обычно пытается найти её автоматически. Для Docker-контейнера типичный адрес backend:

Проверить соединение можно в:

После успешного подключения локальные модели Ollama должны появиться в селекторе моделей Open WebUI.

Самый простой вариант: задать вопрос одному PDF

Для разового документа отдельную Knowledge Base создавать не обязательно.

1. Откройте новый чат.
2. Перетащите PDF в поле сообщения.
3. Дождитесь завершения обработки.
4. Выберите локальную модель.
5. Задайте конкретный вопрос по содержимому.

Open WebUI извлечёт текст, разделит его на фрагменты, создаст embeddings и при запросе передаст модели найденные части документа. В официальной документации этот сценарий описан как one-off attachment.

Как правильно тестировать

Не начинайте с вопроса «расскажи всё про этот документ». Возьмите фразу или число, которое точно есть на одной конкретной странице:

Так проще понять, работает ли retrieval вообще.

Когда нужна Knowledge Base

Если одни и те же файлы нужны во многих чатах, создайте постоянную базу знаний:

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

Затем базу можно:

• подключить к отдельному чату;
• выбрать через символ # в строке ввода;
• привязать к созданной модели/ассистенту;
• использовать через API.

Что такое embeddings и почему это отдельная модель

Embedding-модель не отвечает пользователю. Она превращает текст в вектор — набор чисел, который отражает его смысловое положение в многомерном пространстве.

Тот же процесс выполняется для вопроса пользователя. Затем vector database ищет фрагменты документов, расположенные ближе всего к вектору запроса.

Что использовать сначала

Open WebUI по умолчанию умеет использовать локальный SentenceTransformers-модуль. Для одного пользователя это нормальный старт без дополнительной настройки.

Если Ollama уже работает, embeddings можно вынести туда. В документации Open WebUI среди self-hosted вариантов рекомендуются, в частности, nomic-embed-text и mxbai-embed-large.

ollama pull nomic-embed-text

Что такое chunking и почему от него зависит качество

Большой PDF не превращается в один embedding. Сначала текст разбивается на фрагменты — chunks.

Если chunks слишком маленькие, контекст разваливается: заголовок может оказаться в одном фрагменте, условие — в другом, а таблица — в третьем. Если слишком большие, поиск становится менее точным и быстрее заполняет контекст LLM.

Универсального идеального значения нет. Технический справочник, договор, книга и таблица требуют разных подходов.

Markdown Header Splitting

Open WebUI умеет сначала делить Markdown по H1–H6, а затем применять обычный splitter. Для хорошо структурированной технической документации это полезно: разделы сохраняются логически связанными.

Почему обычный PDF работает, а сканированный — нет

В PDF может вообще не быть текстового слоя. Визуально вы видите страницу, но для парсера это просто изображение.

Open WebUI поддерживает несколько способов извлечения документов, включая встроенные механизмы, Apache Tika, Docling и OCR-сценарии.

Признаки проблемы с extraction

• модель говорит, что документ пуст;
• в preview нет текста;
• русские буквы превратились в мусор;
• таблицы потеряли строки и столбцы;
• найдена только первая часть документа;
• скан виден глазами, но retrieval ничего не находит.

Что попробовать

1. Откройте preview извлечённого содержимого.
2. Для сложных PDF попробуйте Tika или Docling.
3. Для изображений и сканов включите OCR / PDF image extraction.
4. Проверьте результат до изменения LLM.

Почему RAG упирается в context window

Retrieval может найти десять хороших фрагментов, но их ещё нужно передать языковой модели. Они конкурируют за context window с историей диалога, системным prompt и самим вопросом.

В актуальной документации Open WebUI отдельно предупреждается: при использовании Ollama на GPU с объёмом менее 24 GiB default context length может составлять всего 4096 токенов. Для RAG это мало, потому что часть найденного контекста может быть усечена или вообще не использоваться.

Подробно о памяти и контексте: «Сколько RAM и VRAM нужно для локальной LLM».

Как заставить ответы быть проверяемыми

Хороший RAG должен не только отвечать, но и показывать, откуда взят факт. Open WebUI поддерживает citations для найденного контекста.

Для важных документов используйте prompt, который запрещает додумывать отсутствующую информацию:

Даже при citations ответ нужно проверять: LLM может правильно сослаться на документ, но неверно интерпретировать число, исключение или юридическую формулировку.

Почему локальный RAG плохо отвечает: диагностика по шагам

Модель «не видит» файл

Частая причина — extraction. Open WebUI рекомендует сначала проверить preview извлечённого текста и при необходимости сменить parser на Tika или Docling.

Находит не тот PDF

Проблема уже на этапе retrieval. Помогают другая embedding-модель, reindex, hybrid search, reranking и корректная структура базы.

Находит только один и тот же кусок

Проверьте Top K, similarity threshold, chunking и состав Knowledge Base. Для больших наборов документов простой nearest-vector search может быть слишком узким.

После смены embeddings стало хуже

Переиндексируйте все документы. Open WebUI прямо предупреждает, что embeddings разных моделей несовместимы.

Ответ хороший на первом вопросе и медленный на следующих

Для больших документов в документации предлагается RAG_SYSTEM_CONTEXT=True: retrieved context помещается в system message, что позволяет эффективнее использовать prefix/prompt caching в совместимых backend.

Когда базового RAG уже мало

Для десятка технических инструкций встроенного RAG часто достаточно. Для сотен или тысяч документов появляются дополнительные задачи.

• hybrid search: vector similarity + BM25;
• reranking найденных фрагментов;
• метаданные: номер документа, версия, дата, раздел, страница;
• несколько коллекций с разными правами доступа;
• отдельный OCR pipeline;
• обновление только изменившихся файлов;
• external vector database;
• агентный поиск по базе.

Hybrid search и reranking

Vector search хорошо находит семантически похожий текст, но иногда плохо справляется с точными кодами, артикулами, номерами ГОСТ, пунктами договора и редкими терминами. BM25, наоборот, полезен для точных слов. Hybrid search сочетает оба подхода, а reranker заново сортирует найденные кандидаты.

Agentic retrieval и kb_exec

В актуальном Open WebUI есть режим filesystem-style access к Knowledge Base через kb_exec. При поддержке native function calling модель получает инструменты вроде ls, tree, grep, cat и чтения по строкам. Для способных tool-calling моделей это может быть надёжнее простого fan-out поиска.

ENABLE_KB_EXEC=True

Когда нужен Qdrant, Milvus или pgvector

Open WebUI умеет подключать внешние Knowledge Sources без повторного импорта всех документов. В текущей документации экспериментально поддерживаются Qdrant, Milvus и pgvector.

Это имеет смысл, если:

• vector database уже используется другими приложениями;
• индекс формируется отдельным ingestion pipeline;
• документов очень много;
• Open WebUI работает в нескольких экземплярах;
• нужна централизованная корпоративная база;
• требуется независимое масштабирование retrieval.

Насколько такая система действительно локальная

Стек может работать полностью внутри вашей инфраструктуры, но только если локальными остаются все его компоненты.

Если embeddings отправляются в облачный API, наружу уходят chunks документов. Если OCR выполняет внешний сервис, наружу уходят страницы или изображения. Если основная LLM облачная, ей передаются retrieved fragments.

Пример разумной домашней схемы

Не нужно сразу строить LangChain + Qdrant + reranker + OCR + пять микросервисов. Сначала проверьте простой стек на реальных документах. Усложняйте только тот этап, где действительно есть проблема.

Полезные open-source проекты

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