Короткий ответ

Связка n8n, Ollama, Qdrant и PostgreSQL действительно позволяет за короткий срок собрать локальный ИИ-контур и проверить бизнес-гипотезу без передачи документов внешнему API. Но работающий Docker Compose — это ещё не промышленная система.

Официальный Self-hosted AI Starter Kit от n8n объединяет оркестратор процессов, локальный запуск модели, векторную базу и операционную базу данных. Авторы прямо предупреждают: комплект предназначен прежде всего для старта и proof-of-concept и не полностью оптимизирован для production. Это важная граница. Пилот отвечает на вопрос «решает ли ИИ задачу», а промышленный контур — ещё и на вопросы «кто имеет доступ», «что произойдёт при сбое», «как восстановить данные» и «кто подтверждает опасное действие».

Что даёт такой стек бизнесу

Компоненты закрывают разные части процесса:

  • **n8n** связывает почту, CRM, файловое хранилище и внутренние API, запускает цепочки и сохраняет историю выполнения;
  • **Ollama** запускает языковую модель внутри выбранного контура;
  • **Qdrant** хранит векторный индекс для поиска фрагментов документов в RAG-сценариях;
  • **PostgreSQL** хранит служебные данные автоматизации и состояние процессов.

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

Пилот следует начинать не с «универсального корпоративного агента», а с процесса, где известны вход, ожидаемый результат и ответственный сотрудник. Иначе команда получит красивый чат, но не сможет измерить пользу.

Что проверить до разговора о production

Для пилота достаточно репрезентативной выборки и ручной проверки результата. Минимальный набор метрик:

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

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

Почему быстрый Docker Compose нельзя просто оставить как есть

В демонстрационном контуре компоненты обычно находятся в одной сети, секреты задаются через локальный файл окружения, а обновление выполняется подтягиванием свежих образов. Это удобно для эксперимента, но создаёт несколько классов риска.

Изменяемые версии

Образ с тегом `latest` может измениться между перезапусками. Для production нужны фиксированные версии n8n, Ollama, Qdrant и PostgreSQL, журнал обновлений и проверка совместимости на отдельном стенде. Официальный репозиторий n8n Hosting также советует фиксировать конкретный тег образа вместо `latest` или `stable`.

Секреты и сетевой периметр

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

Сервисы не следует публиковать напрямую в интернет. Внешний доступ проходит через TLS, обратный прокси или корпоративный шлюз; внутренние порты доступны только тем узлам, которым они действительно нужны.

Векторная база без защиты по умолчанию

Документация Qdrant отдельно предупреждает: self-hosted open-source экземпляр по умолчанию слушает сетевые интерфейсы без аутентификации и шифрования. Перед работой с реальными документами нужно ограничить привязку к частной сети, включить TLS и ключи доступа. Для сервисов, которым нужен только поиск, следует использовать read-only или ограниченные по коллекциям права вместо административного ключа.

Отсутствие проверенного восстановления

Наличие тома Docker не равно резервному копированию. Нужны расписание копий PostgreSQL, снимки или резервирование коллекций Qdrant, хранение конфигурации процессов и регулярная проверка восстановления на отдельном контуре. Главный тест резервной копии — не факт её создания, а измеренное время возврата системы в работу.

Базовая производственная архитектура

Для первого промышленного сценария необязательно сразу строить Kubernetes-кластер. Малому бизнесу часто достаточно одного или двух управляемых узлов, если роли разделены и эксплуатация формализована.

Практичная схема выглядит так:

1. **Входной слой.** Корпоративный шлюз принимает запросы, проверяет пользователя, ограничивает частоту и пишет технический журнал.
2. **Оркестрация.** n8n выполняет только утверждённые процессы. Производственные и экспериментальные workflow разделены.
3. **Инференс.** Ollama или другой локальный сервер модели работает в закрытой сети и получает только необходимый контекст, а не весь архив компании.
4. **RAG.** Qdrant хранит векторы вместе с метаданными доступа, версией документа, подразделением и сроком действия.
5. **Операционные данные.** PostgreSQL размещён на резервируемом диске, копируется по расписанию и не совмещается с временными экспериментами.
6. **Контур действий.** Чтение отделено от записи. Отправка письма, изменение CRM, публикация или удаление требуют детерминированной проверки и, для значимых операций, подтверждения человеком.

Если нагрузка становится неравномерной, n8n поддерживает очередь с PostgreSQL и Redis и отдельными workers. Но переход к очередям нужен после измерения нагрузки, а не ради архитектурной солидности на диаграмме.

Данные и RAG: модель — не главный риск

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

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

Права должны проверяться до поиска или на уровне фильтрации коллекций, а не после генерации ответа. Модель не является системой авторизации и не должна решать, имеет ли сотрудник доступ к найденному фрагменту.

Агентам нужны меньшие права, чем сотрудникам

OWASP описывает «избыточную агентность» как сочетание лишней функциональности, лишних разрешений и лишней автономии. Для бизнес-контура это означает три простых правила:

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

Ограничение в системном промпте полезно, но не заменяет права базы данных, OAuth-scopes, сетевые политики и контроль на стороне целевой системы.

Экономика: считать нужно весь контур

Локальная модель убирает переменную оплату внешнего API, но добавляет оборудование, электричество, обновления, мониторинг и ответственность за доступность. Поэтому сравнивать следует не цену токена с ценой видеокарты, а полную стоимость одного надёжно завершённого процесса.

В расчёт входят:

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

Если процесс выполняется редко и не содержит чувствительных данных, внешний API может оказаться экономичнее. Локальный контур оправдан, когда важны контроль данных, предсказуемая нагрузка, автономность или интеграция с закрытыми системами.

Практический план перехода

Для первого сценария можно использовать такой порядок:

1. Зафиксировать один процесс, владельца и метрику успеха.
2. Собрать пилот на обезличенной или ограниченной выборке.
3. Провести приёмку на реальных примерах и записать типовые ошибки.
4. Составить карту данных, интеграций и необходимых прав.
5. Зафиксировать версии компонентов и отделить тестовый контур.
6. Настроить TLS, секреты, сетевые ограничения и роли.
7. Добавить журналы, лимиты, отказоустойчивость и резервные копии.
8. Проверить восстановление и сценарий безопасного отключения.
9. Оставить человеческое подтверждение для необратимых действий.
10. Только после этого расширять процесс или подключать новые подразделения.

Что взять руководителю

Self-hosted AI Starter Kit — хороший способ недорого доказать ценность локального ИИ, но не готовый «корпоративный ИИ в одной команде». Разумный следующий шаг — провести короткий пилот одного процесса и закончить его не демонстрацией, а документом с метриками, картой данных, перечнем рисков и сметой промышленного контура.

Если после пилота неизвестно, кто отвечает за данные, как восстановить систему и кто подтверждает запись во внешнюю систему, проект ещё не готов к production — даже если робот уже радостно мигает всеми лампочками.