Собственная LLM в корпоративном контуре: как мы собрали RAG на n8n и сократили расходы в 5,5 раза

Привет, Хабр! На связи команда ИТ-инфраструктуры и автоматизации, а именно Ольга Мастерова, Анастасия Иванова и Филипп Теряев.

Мы во Flowwow настоящие фанаты автоматизации. На дату публикации этой статьи в нашем корпоративном мессенджере внедрено больше 270 автоматизаций, и это далеко не конец. У вас наверняка возникает закономерный вопрос: а зачем так много?

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

В этой статье мы расскажем, как сократили время на поиск информации в корпоративной базе знаний и превратили тысячи страниц документации в удобного ИИ-ассистента. А также поделимся, как реализовали локальный GPT, почему выбрали путь собственных решений вместо готовых сервисов, с какими инфраструктурными вызовами столкнулись и как в итоге собрали рабочие инструменты на базе self-hosted-версии low-code-платформы n8n, полностью закрыв данные внутри корпоративного контура.

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

Поэтому перед тем как перейти к рассказу о нашем пути в разработке LLM, кратко поделимся, почему мы меняли мессенджер, как выбирали новый и какие ограничения получили на выходе.

Выбор мессенджера и наши ограничения

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

Поэтому мы проанализировали более 40 корпоративных мессенджеров, отсеивая те, что требовали долгого переобучения. Нам было критически важно сохранить существующие автоматизации. Ключевыми критериями отбора стали:

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

• развитое API и поддержка интеграций: у нас уже было много автоматизаций, которые нельзя потерять;

• подтвержденный опыт миграций и инструменты для переноса данных;

• кросс-платформенность: веб, десктоп и мобильные клиенты;

• адекватное менеджерское сопровождение на этапе внедрения.

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

Важно понимать, что бесшовного переезда не бывает. И для нас ключевой сложностью стало ограниченное количество готовых интеграций — часть привычных сценариев пришлось собирать с нуля. Надо отдать должное сотрудникам «Пачки»: они показали себя открытой командой и на всех этапах шли нам навстречу. Но именно на фоне этой пересборки процессов особенно явно проявилась наша старая боль — работа с корпоративными знаниями.

От боли с документацией — к собственной LLM

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

Сотрудники тратили время на поиск или отвлекали коллег вопросами. Последние, в свою очередь, регулярно отвечали на одни и те же запросы. Это снижало общую эффективность и увеличивало косвенные потери времени.

Стало понятно, что проблему не решить простым улучшением поиска. Нам нужен был бот, который позволял бы получать ответы в привычной среде — прямо в «Пачке», оперируя при этом информацией из нашей документации. Для реализации такого решения мы рассматривали три основных варианта.

Вариант 1. Готовые коробочные решения

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

• Стоимость: оплата не только самой модели, но и работы внешних специалистов делала решение дорогим уже на старте.

• Функциональность: нам не хватало гибкости и кастомизации под наши нестандартные сценарии.

• Ограничения: жесткие лимиты по количеству загружаемых документов и объему данных.

В итоге такие решения оказались неэффективными с точки зрения соотношения стоимости и возможностей.

Вариант 2. Open source в облаке

Размещение моделей у облачных провайдеров выглядело более гибким: можно выбирать модель, масштабироваться и не заниматься инфраструктурой. Но, рассмотрев этот вариант под лупой, мы выделили два стоп-фактора. Во-первых, при наших объемах данных и предполагаемой нагрузке стоимость такого решения не будет окупаться. Во-вторых, передача корпоративной документации внешним сервисам добавляла очевидных рисков безопасности, которые мы не были готовы принимать.

Вариант 3. Собственная инфраструктура

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

Зато именно этот вариант дал нам ключевые преимущества:

• возможность адаптировать систему под наши реальные задачи, а не под ограничения продукта;

• отсутствие лимитов на количество документов;

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

• предсказуемую экономику при росте нагрузки.

В какой-то момент стало очевидно, что сделать свое — это не только более гибкое решение, но и более безопасное (в локальную LLM мы могли бы загружать любые документы без каких-либо рисков), к тому же в долгосрочной перспективе — наиболее бюджетное.

Модель, мощности и реализация

Изначально мы планировали разрабатывать абсолютно все элементы системы самостоятельно — от оркестрации до работы с моделями и данными. Однако после декомпозиции задачи стало понятно, что срок реализации в таком случае составит от 6 до 9 месяцев. Для нас это было слишком долго.

Поэтому мы начали искать альтернативные варианты реализации локальных LLM. Довольно быстро мы пришли к решению на базе n8n. Такой подход позволил сократить срок разработки до 2,5 месяца без потери функциональности.

Общая архитектура решения

В основе архитектуры лежат два инстанса n8n:

• Основной (инфраструктурный) n8n развернут на нашем облаке, где работает остальная инфраструктура компании. Он используется для всех автоматизаций в «Пачке», а не только связанных с LLM.

• Локальный (on-premise) n8n развернут на собственном сервере в офисе и отвечает за выполнение ресурсоемких операций.

В «Пачке» реализованы два отдельных бота:

• для поиска по внутренней документации;

• для всех остальных задач и вопросов.

После первичного тестирования для поиска по внутренней документации была выбрана Qwen3 VL 30B Instruct.

Для общего GPT-бота мы добавили возможность пользователю самостоятельно выбирать модель. По умолчанию используется gpt-oss:20b — она наиболее близка по поведению к ChatGPT, так как основана на комбинации нескольких версий GPT-4. К тому же эта модель потребляет наименьшее количество токенов на объем текста и имеет самое большое контекстное окно. 

Также с помощью кнопок в «Пачке» можно переключиться:

• на Qwen3 Coder 30B — для более качественной генерации кода;

• на Qwen3 VL 30B Instruct — для работы с изображениями и лучшего следования инструкциям.

Сервер и мощности

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

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

• Ryzen 9950x;

• RTX 5090 32GB;

• 128 ГБ ОЗУ;

• 2 ТБ SSD.

Что по флоу работы

Флоу работы у обоих ботов одинаковый:

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

Но отличия в работе тоже присутствуют.

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

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

Дополнительно реализована возможность сообщить о неточности в ответе LLM или в самой документации.

2. Бот для всех остальных задач и вопросов. После отправки вопроса пользователю предлагается:

• выбрать модель;

• задать собственный системный промпт

• либо отправить запрос со значениями по умолчанию (без промпта, модель gpt-oss:20B).

Контекст треда сохраняется — каждый тред фактически является отдельным чатом, аналогичным диалогу в ChatGPT.

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

Идет загрузка, или как мы решили проблему очередей

Ключевая проблема проявилась уже на этапе первого нагрузочного тестирования. По умолчанию запросы обрабатывались параллельно, из-за чего время ожидания ответа заметно увеличивалось.

Чтобы решить эту проблему, мы реализовали несколько улучшений:

• настроили последовательную обработку запросов (FIFO);

• реализовали асинхронное взаимодействие между локальным и облачным n8n для стабильности соединения;

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

Важный момент — работа с неизбежными галлюцинациями моделей и качеством самой базы знаний. Для этого мы выстроили процесс непрерывного сбора обратной связи. Прямо в интерфейсе бота мы добавили кнопку «Сообщить об ошибке», которая открывает форму комментария.

При отправке алерт летит в специальный канал «Пачки», собирая весь контекст инцидента:

• исходный вопрос;

• комментарий пользователя;

• ответ LLM.

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

Итоги и планы на будущее

Собственная инфраструктура полностью себя оправдала: локальный RAG обходится нам в 5,5 раза дешевле корпоративных коробочных решений. При этом количество обращений к боту постоянно растет. Мы видим главное: коллеги действительно стали тратить меньше времени на рутинный поиск регламентов и реже отвлекать друг друга типовыми вопросами.

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