Гибридная RAG-система на AnythingLLM: VPS, домашняя GPU и проверка защищённого доступа

Бизнес хочет RAG, но боится облаков. И правильно делает.

Вы когда-нибудь пробовали подключить свою конфиденциальную базу знаний к ChatGPT? У меня после первого такого опыта дёргался глаз. Данные улетают в неизвестность, счёт за API растёт, а скорость ответа – как повезёт. Малый бизнес не может платить $500-1000 в месяц за API и спать спокойно.

RAG (Retrieval-Augmented Generation) – штука крутая: модель отвечает на основе ваших документов, а не на основе мутного интернета. Но где это хостить? Полностью локальный сервер – дорого, сложно в поддержке. Облако – опять зависимость.

Гибридная схема: VPS для интерфейса и базы знаний, домашняя GPU для инференса через защищённый туннель. Это не полностью локальная обработка: документы и индексы хранятся на VPS. Ни VPN, ни локальная модель сами по себе не гарантируют отсутствия утечек. Ниже — порядок подготовки и проверки; параметры VPN зависят от вашей сети, готовой универсальной конфигурации здесь нет.

Если вы ещё не собрали домашнюю станцию, сначала прочитайте гайд по железу за $15 000 – там всё про выбор видеокарт и RAM. А если сомневаетесь между облаком и локальным хостингом, у меня есть системная статья про стратегию развёртывания.

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

VPS в этой схеме хранит документы и интерфейс, а GPU остаётся дома. Сравните RAM и диск для базы знаний, резервное копирование и условия обработки данных; Timeweb Cloud можно включить в сравнение провайдеров. Это партнёрская ссылка; конфигурацию и текущую стоимость нужно проверять под свою нагрузку, минимальный тариф не является гарантией достаточности ресурсов.

Не пугайтесь списка – всё стандартное. Из необычного разве что VPN-туннель.

Я не буду разжёвывать установку драйверов NVIDIA – это миллион раз описано. Если что, загляните в статью про «бетонную стену» – там есть секция железа.

Шаг 1: Поднимаем IPsec-туннель между VPS и домашним сервером

Сначала настройте VPN по официальному руководству strongSwan под вашу топологию. Пример с одинаковыми 0.0.0.0/0 selectors не является готовой настройкой для домашнего NAT. Без проверки маршрутов и firewall переходить к данным нельзя.

• При взаимной аутентификации сертификатами каждой стороне нужны собственный закрытый ключ и сертификат с корректной identity/SAN; обе стороны доверяют сертификату CA. Закрытый ключ CA остаётся на машине выпуска, на VPS его не копируют. Подпишите запросы сертификатов на CA и передайте соответствующей стороне только её сертификат и публичную цепочку.
• Определите адреса защищаемых узлов, traffic selectors, маршруты, NAT traversal и обратный путь. Docker bridge может менять адрес источника: проверяйте доступ из контейнера AnythingLLM, а не только с хоста VPS.
• Разрешите 11434 только для нужного трафика, прошедшего IPsec-политику. Разрешение большой частной подсети само по себе не доказывает шифрование. При падении VPN соединение должно блокироваться, а не уходить в открытый интернет.
• Проверьте IKE SA и CHILD SA, счётчики зашифрованных пакетов, запрос тестовой модели из контейнера и отказ доступа при отключении VPN. Одного ESTABLISHED или ping недостаточно.

Пошаговый выпуск ключей и сертификатов: strongSwan Certificates Quickstart. Готовую конфигурацию для конкретного роутера, NAT и адресов должен проверить администратор до загрузки рабочих документов.

Шаг 2: Запускаем Ollama на домашнем сервере

Установите Ollama по официальной инструкции. Для первого теста возьмите небольшую модель, а не 70B: веса 70B Q4 сами по себе могут занимать около 40 ГБ, поэтому в 24 ГБ VRAM они полностью не помещаются. Считайте также контекст, runtime и эмбеддинги; частичный offload в RAM меняет скорость.

ollama pull llama3.1:8b-instruct-q4_K_M
ollama pull nomic-embed-text
curl http://localhost:11434/api/tags

Если установщик уже запустил systemd-службу, второй ollama serve не нужен. По умолчанию API слушает loopback. Для IPsec задайте OLLAMA_HOST на выбранный защищаемый адрес домашнего узла и порт 11434 в systemd override; фактический адрес зависит от вашей топологии. Не назначайте 0.0.0.0 до настройки фильтрации. Перезапустите службу и повторите проверку из контейнера на VPS.

Порт 11434 не публикуйте на домашнем роутере. Если приватный адрес недостижим, исправьте VPN и маршруты; публичный port forwarding не заменяет туннель.

Шаг 3: Разворачиваем AnythingLLM на VPS

Вот где начинается магия. AnythingLLM – это open-source платформа для создания чат-ботов с RAG. Она умеет подключаться к любому LLM-провайдеру, включая Ollama по API.

Используйте Docker Engine 28 или новее: у более старых версий есть известное ограничение изоляции localhost-публикаций. Подготовьте постоянное хранилище по инструкции AnythingLLM и закрепите проверенный тег образа перед эксплуатацией. Для первичной настройки достаточно следующего шаблона в отдельном рабочем каталоге:

mkdir -p data
touch data/.env

services:
  anythingllm:
    image: mintplexlabs/anythingllm:latest
    container_name: anythingllm
    ports:
      - "127.0.0.1:3001:3001"
    environment:
      - STORAGE_DIR=/app/server/storage
    volumes:
      - ./data:/app/server/storage
      - ./data/.env:/app/server/.env
    restart: unless-stopped

Проверьте права записи контейнера в data. LLM-провайдер и embedding-провайдер настройте через интерфейс после защищённого подключения: Ollama, адрес домашнего узла внутри проверенной IPsec-схемы, модель llama3.1:8b-instruct-q4_K_M и embedding-модель nomic-embed-text. Не используйте localhost как адрес домашнего Ollama внутри контейнера VPS.

Запустите:

docker compose up -d

На своём компьютере откройте SSH-туннель: ssh -N -L 3001:127.0.0.1:3001 USER@VPS_IP. Затем зайдите на http://127.0.0.1:3001: между компьютером и VPS данные идут внутри SSH. Сразу включите пароль для одного пользователя либо multi-user mode с администратором и ролями. До настройки доступа и проверки обоих туннелей используйте только искусственные тестовые файлы. Рабочие документы загружайте после проверки прав, резервного копирования и допустимости хранения данных на VPS. Для доступа команды через домен отдельно настройте HTTPS reverse proxy с валидным сертификатом и аутентификацией; публичный 3001 остаётся закрыт.

Проверьте тестовый запрос и эмбеддинги из AnythingLLM, а затем повторите тест при отключённом VPN: доступа к домашнему API быть не должно. Задержку измеряйте на своей сети и модели; гарантировать 5–20 мс нельзя.

Шаг 4: Тюним RAG под бизнес-задачи

Мало просто запустить – надо, чтобы модель реально помогала. Вот три вещи, которые я меняю почти в каждом проекте:

1 Настройка prompt’а в AnythingLLM

Зайдите в Settings → Chat Settings → System Prompt. Пишите чётко: «Ты – ассистент отдела продаж компании X. Отвечай на основе предоставленных документов. Если ответа нет в документах – честно скажи, что не знаешь, не выдумывай.»

Без такого промпта модель начнёт галлюцинировать – проверено.

2 Выбор chunk size и overlap

По умолчанию AnythingLLM режет документы на куски по 1000 символов с пересечением 200. Для юридических договоров лучше уменьшить до 500 символов – контекст точнее. Для технической документации можно 1500. Настройка в Settings → Embedding → Chunk size.

3 Включаем гибридный поиск

Наличие гибридного поиска и его настройку проверяйте для используемой версии и векторного хранилища. Не считайте BM25 автоматически включённым SQLite-индексом. Сравните выдачу на собственном наборе вопросов; фиксированный прирост релевантности не гарантирован.

Типичные ошибки и как их избежать

Собрал грабли, на которые наступил сам и мои клиенты:

• VPN упал – модель недоступна. Решение: добавьте auto=start и dpdaction=restart в конфиг IPsec, а ещё лучше – cron скрипт, проверяющий туннель каждую минуту.
• Ollama падает из-за перегрузки GPU. При параллельных запросах от нескольких пользователей видеопамять переполняется. Ограничьте число одновременных сессий в AnythingLLM (Settings → Multi-User) или используйте модель меньшего размера.
• Медленная загрузка больших документов. Для PDF с сотнями страниц настройте параллельную обработку. В AnythingLLM этого нет из коробки, но можно предварительно разбить файл на части.
• Домашний IP меняется. Если у провайдера динамический IP, используйте DDNS (например duckdns.org) и в конфиге IPsec пропишите DNS-имя вместо IP.

А что дальше?

После успешных проверок доступа, восстановления из резервной копии и качества ответов можно расширять тестовый стенд:

• Проверить роли пользователей и права рабочих пространств; аутентификация должна быть включена ещё до загрузки данных.
• Подключить несколько моделей для разных задач (например, для аналитики – более мощную, для чата – легковесную).
• Интегрировать через API с CRM или телеграм-ботом.

При локальном инференсе нет оплаты API за токены, но остаются затраты на VPS, электричество, трафик по тарифу и обслуживание. Если захотите расшириться – см. мой гайд «Корпоративный LLM за бетонной стеной», там про кластеризацию.

Не советую так делать, но одну вещь скажу: я видел компании, которые просто проксировали Ollama через VPS без шифрования. Через месяц у них украли модель и базу знаний. Не будьте такими. IPsec – это больно настраивать, но оно того стоит.

В следующей статье разберу, как заменить IPsec на WireGuard (проще, но чуть медленнее) и добавить балансировку на несколько домашних GPU. Подпишитесь, чтобы не пропустить.

Подписаться на канал