Что произошло

Мотив знакомый: эксперименты с локальными LLM идут легко, а «продукт, которым могут пользоваться люди без опыта администрирования» собирается из бэкенда, фронта, векторного хранилища и оркестрации. Каждый слой сам по себе документирован. Стыков обычно нет.

VaultRAG закрывает типичный путь. Пользователь загружает PDF. FastAPI принимает файл и отдаёт его в цепочку LangChain. Текст режется через RecursiveCharacterTextSplitter. Эмбеддинги считает локальная модель в Ollama (в заметке фигурирует nomic-embed-text). Векторы кладутся в локальное хранилище. На вопрос система поднимает близкие фрагменты и отдаёт ответ потоком по SSE, не дожидаясь «всего текста сразу».

Для генерации автор упоминает семейства вроде Llama 3.1 и Qwen, тоже через Ollama, без внешнего ключа. Клиент на React с Tailwind — это обычный чат поверх этого контура. Весь контур поднимается через Docker Compose: один каталог, один compose up, вместо ручной склейки портов и переменных окружения.

Код: репозиторий стартового набора на GitHub.

Два места, где автор реально упёрся. Сначала сеть Docker: контейнер FastAPI должен видеть Ollama по имени сервиса, а не через localhost с хоста. Потом размер и перекрытие фрагментов: слишком мелкие куски теряют контекст, слишком крупные замедляют вывод модели и раздувают индекс.

Почему это важно

Многие пилоты RAG умирают не на качестве ответа, а на политике данных. Юристы, медицина, внутренние регламенты: просьба «отправьте корпус в облако» уже стоп. Локальный стек снимает этот стоп, но только если его можно воспроизвести без недельной сборки.

Готовый Compose-контур полезен как эталон стыков, а не как финальная архитектура. Он показывает, где живёт загрузка, где нарезка, где эмбеддинги и где поток ответа. Какой индекс в проде, как версионировать документы и как мерить качество — уже другая глубина, ближе к промышленной инженерии RAG.

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

На практике

Имеет смысл смотреть на набор, если вы уже знаете, зачем вам офлайн, и не хотите неделю тратить на склейку.

1. Поднимите Compose и проверьте, что FastAPI ходит в Ollama по имени сервиса из сети Docker, а не на 127.0.0.1 хоста.
2. Загрузите один знакомый PDF и задайте вопросы, ответы на которые вы знаете наизусть — так быстрее видно, что индекс «живой».
3. Покрутите chunk_size и chunk_overlap у RecursiveCharacterTextSplitter: начните с умеренных значений и смотрите, не рвутся ли абзацы посередине мысли.
4. Смените модель генерации (Llama 3.1, Qwen и т.п.) и эмбеддинги (nomic-embed-text) под железо: слабый ноутбук и сервер с GPU — разные бюджеты.
5. Проверьте поток SSE в интерфейсе: обрыв соединения и повторный запрос должны вести себя предсказуемо.
6. Не путайте стартовый каркас с продакшеном: права доступа, версии документов, оценка качества и наблюдаемость сюда почти наверняка не входят — их добавляют поверх.

Итог

VaultRAG отвечает на вопрос «как быстро поднять приватный RAG без облака»: PDF → нарезка → локальные эмбеддинги → поиск → поток ответа, всё в Docker Compose.

Ценность в собранных стыках Ollama ↔ FastAPI ↔ React и в двух известных граблях: сеть контейнеров и размер фрагментов. Маркетинговое «корпоративный» тут ни при чём.

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