Как мы автоматизировали комьюнити Дельфин-клуба: пошаговый разбор с архитектурой

14 мая 2026 г. · Богдан Шишкин

В Дельфин-клубе чат на 10 000+ участников. Команда модераторов отвечала на одинаковые вопросы по 30+ часов в неделю: расписание, условия членства, регламенты, доступ к материалам. Каждую неделю — одни и те же диалоги, только новые люди.

Мы закрыли этот процесс ИИ-ассистентом. По итогу — −85% нагрузки на модерацию, +5% к конверсии в членство, один модератор делает работу троих. Дальше — как именно это собрано.

Что мы НЕ стали делать

Когда приходит клиент с чатом на десять тысяч человек, первое искушение — поставить условный «GPT в чат» и научить его отвечать на всё. Это не работает.

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

Мы пошли другим путём. Сузили задачу до одного процесса — ответы на типовые информационные вопросы — и сделали так, чтобы агент работал только в этой зоне. Всё остальное — мимо него, к живым модераторам.

Архитектура: что под капотом

Стек получился такой:

n8n — оркестратор пайплайна, ловит сообщения через Telegram-триггер
Claude Sonnet — основной классификатор и генератор ответа
Postgres + pgvector — векторная база знаний клуба (FAQ, регламенты, расписание)
Кастомный TypeScript-сервис — pre-processing сообщений и эскалации
Redis — кэш для повторных запросов и rate limiting

Поток выглядит так. Сообщение попадает в n8n. Первая нода — классификатор: это вопрос к клубу или просто общение между участниками. Если общение — игнорируем. Если вопрос — идём дальше.

Telegram trigger
   ↓
Classifier (вопрос / шум / эскалация)
   ↓
Retrieval (pgvector, top-5 чанков)
   ↓
Claude (ответ на основе чанков + system prompt)
   ↓
Confidence check (если < 0.7 → модератор)
   ↓
Reply + log

Классификация в начале — критичная деталь. На 10К чате 80% сообщений — это разговоры между участниками, мемы, реакции. Если агент будет реагировать на всё, его быстро возненавидят. Поэтому первый шаг — фильтр на «адресован ли вопрос клубу».

RAG и почему важна структура базы

Retrieval работает по векторной базе из примерно 400 чанков. Это вычитка регламентов, FAQ, расписания мероприятий, тарифов и условий вступления. По нашему опыту, на чанк уходит 300-500 токенов — это компромисс между точностью retrieval и качеством ответа.

Что мы поняли в процессе: качество RAG на 70% определяется качеством исходной базы, а не моделью эмбеддингов. Первая итерация была собрана из «как есть» документов клуба. Точность была 60% на тестовом наборе из 80 вопросов. Мы переписали базу: разнесли пересекающиеся темы, убрали устаревшее, добавили примеры формулировок. Точность поднялась до 91% без замены модели.

«Часто на проектах ИИ-агентов мы тратим больше времени на чистку и реструктуризацию знаний, чем на сам код агента. База знаний — это продукт, который живёт. Один раз залить и забыть не получится.» — Богдан Шишкин, основатель Articortex

Эскалация: где агент сдаётся

У агента есть три исхода работы с сообщением:

Уверенный ответ (confidence ≥ 0.7) — отвечает в чат, пишет лог
Сомнения (0.4 – 0.7) — отвечает в чат с пометкой «уточните у модератора, если что» + ставит флаг
Не знает (< 0.4) — молчит и кидает уведомление дежурному модератору

Confidence считается комбинацией: similarity score из pgvector + self-evaluation от Claude (просим модель оценить, насколько ответ покрыт контекстом). Эта двойная проверка отсекает галлюцинации.

Третий сценарий важнее, чем кажется. Главный страх клиента — что бот наврёт от лица клуба. Поэтому базовая установка: лучше промолчать, чем выдумать. Если контекста нет — модератор разберётся.

Грабли, на которые наступили

Первое — лимиты Telegram. На пике активности приходило по 30-40 сообщений в минуту. Сначала упирались в API rate limits бота. Решили очередью в Redis с равномерным flush раз в 2 секунды.

Второе — длинные треды. Участники цитируют друг друга, отвечают через реплай на сообщения недельной давности. Контекст разваливался. Добавили окно из 5 последних сообщений треда плюс родительский reply — стало лучше, но не идеально.

Третье — приватные данные в логах. Логи запросов и ответов идут в Postgres для аудита. Когда показали клиенту, обнаружилось, что в некоторых вопросах участники называли реальные имена и контакты. Дописали маскирование PII на этапе логирования.

Четвёртое — обновления базы. Клуб меняет расписание раз в две недели, тарифы — раз в квартал. Если базу обновлять руками, она устаревает. Сделали интеграцию: модератор правит документ в Notion → webhook → переиндексация чанков. Без техкоманды клиента.

Цифры по итогу

После двух месяцев работы в проде:

Среднее время до ответа на типовой вопрос — 4 секунды (раньше 12-40 минут)
Точность ответов по выборке аудита — 91%
Нагрузка на модераторов по часам — −85%
Конверсия из бесплатного чата в платное членство — +5%
Стоимость инференса — около 8 000 ₽ в месяц при текущем трафике

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

Что бы сделали иначе

Если бы запускали проект заново — начали бы с базы знаний, а не с архитектуры. Первый месяц проект буксовал именно из-за того, что мы быстро собрали инфраструктуру и потом долго мучились с качеством retrieval. Сейчас на похожих проектах первая неделя — это только работа с контентом: что в базе, как структурировано, какие вопросы покрыты, какие нет.

Второе — раньше показали бы клиенту confidence scoring. Когда модераторы видят, на каких вопросах агент сомневается, они быстрее правят базу. Это превращает систему в самообучающуюся не на словах, а на деле.

Когда такой подход подходит

Кратко — если у вас:

Сообщество, поддержка или внутренняя база знаний с потоком повторяющихся вопросов
Документированные правила и FAQ (или готовность их написать)
Возможность смириться с тем, что 5-10% случаев агент эскалирует человеку

Если процесс требует доступа к live-данным (CRM, складские остатки, личные кабинеты), архитектура будет другой — там нужны MCP-серверы и инструменты для агента, не только RAG. Это отдельный разговор.

Что дальше

Хотите оценить, как такая система ляжет на ваш процесс — есть калькулятор с грубой оценкой бюджета и сроков. Если нужно поговорить предметно — /contacts.

См. также: