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

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.

Термины: RAG · MCP · n8n · Мультиагентная система · Векторная база данных

См. также: