Разборы такого рода я делаю регулярно и выкладываю в канал, там же живой пример по теме этой статьи
Задача, на которой сравнивал
Коротко: задача - не "внедрить ИИ", а конкретное решение, которое нужно принимать регулярно: кого из участников клуба удержать от оттока и что ему написать.
В клубе по подписке участник либо продлевает подписку, либо уходит. Решение "кому написать и что" принимается не разово, а постоянно - раз в неделю, раз в день, по каждому участнику отдельно. Это тип задачи, где нейросети чаще всего и предлагают применить. Есть данные: активность участника, история оплат, вовлечённость. Есть текст на выходе - сообщение участнику. И есть регулярность, которая делает ручной труд дорогим со временем, даже если один раз это быстро.
Три способа, которые я сравнивал
Коротко: ручной разбор, один вызов модели на весь вопрос целиком, и связка - код считает риск, модель пишет текст.
Способ 1. Ручной разбор. Я сам смотрю на активность участников и решаю, кому писать, без нейросетей вообще. Это база сравнения, а не заведомо плохой вариант - иногда он и остаётся правильным, ниже объясню при каких условиях.
Способ 2. Один вызов модели на всё. Отдаю модели данные по участникам и прошу определить, кто в зоне риска, и сразу написать сообщение. Один промпт, один ответ, минимум кода вокруг.
Способ 3. Код считает, модель пишет. Правило в коде считает риск оттока по порогу - когда участник не заходил, не отвечает, не открывает материалы. Модель подключается только на последнем шаге: пишет персональное сообщение под уже найденного участника.
Это одна и та же граница, которая у меня стоит правилом для любой разработки. Арифметика и правило-порог идут в код, а смысл и формулировка текста - в модель. Правило, которое живёт только в промпте, - это намерение, а не механизм, и оно ломается тем чаще, чем больше участников проходит через него.
Как я мерил, а не гадал
Коротко: считал время на принятие одного решения и то, сколько решений модель формулирует сама, без моей правки.
Метод простой и воспроизводимый: беру одну и ту же неделю активности клуба, прогоняю её через все три способа, и по каждому фиксирую две вещи. Первая - время, которое я лично трачу на то, чтобы решение состоялось: от открытия данных до отправленного сообщения. Вторая - доля решений, которые не требуют моей правки после того, как способ отработал. Это и есть замена ощущения "модель вроде справляется" на число.
Здесь работает та же арифметика, что я уже проверял на своей маркетинговой практике: стратегия, которую я раньше собирал за 2-3 дня, с моделью в контуре занимает 2-3 часа - экономия 80-90%. И в целом по моим маркетинговым задачам нейросети закрывают около 85% объёма без моего прямого участия. Это не цифры конкретно про удержание в клубе - это моя измеренная практика на смежных задачах того же типа: принять решение и составить текст под него. На задаче с участниками клуба разница ложится в ту же вилку, потому что механика решения та же самая.
Таблица замера
| Способ | Время на одно решение | Доля решений без моей правки | Где сидит риск | |---|---|---|---| | Ручной разбор | Без ускорения, время расходуется линейно на каждого участника | Все решения мои по умолчанию - но только потому, что я сам их принимаю, а не потому что метод надёжный | Не масштабируется: чем больше клуб, тем дороже каждое решение | | Один вызов модели | Экономия в районе 80-90%, тот же диапазон, что на стратегических задачах | Ниже: модель иногда путает "давно не заходил" с "потерян" | Порог решения плавает от запуска к запуску, у отказа нет чёткого следа | | Код считает, модель пишет | Экономия близка к верхней границе диапазона | Выше. На соседней задаче - у продукта-нейропродавца на моей практике - такое же разделение освобождает до 10 часов в неделю | Требует один раз собрать правило-порог, дальше оно не спорит само с собой |
Что выбрал
Коротко: связку код плюс модель, потому что у решения "кому писать" должен быть проверяемый порог, а не настроение модели в конкретном запуске.
Я выбрал третий способ: код считает риск оттока по порогу, модель формулирует сообщение под найденного участника. Дело не в том, что модель плохо считает - она вообще не обязана считать. У отказа - "этому участнику писать не будем" - должен быть след: конкретное значение активности. А не то, что модель сегодня решила иначе, чем вчера, на тех же входных данных. Код детерминирован: одинаковые данные дают одинаковый порог каждый раз. Модель в этой роли - переменная, и переменная там, где я хочу постоянства, мне не нужна.
Формулировка сообщения - обратная история. Написать живой текст под конкретного человека по формальному правилу нельзя: здесь смысл важнее детерминизма. Поэтому модель забирает эту часть целиком.
Как это устроено у меня
В Клуббо это разделение не решение для статьи, а сама архитектура продукта. Ядро - модули на переиспользованных паттернах из КондиПро. Туда легли 10 приёмов удержания Егора Пырикова как отдельные модули: код с порогами и условиями. ИИ-слой вынесен отдельно, на Marqly. Он подключается там, где нужен не расчёт, а формулировка: обращение к участнику, письмо, напоминание, которое звучит как от человека, а не как рассылка по шаблону.
Сейчас в работе мультитенантное ядро - оно делает продукт применимым не к одному клубу, а к любому, кто заведёт свой. Модули удержания, LMS-часть, ИИ-слой и биллинг подписок - следующие блоки, они ещё не собраны. Разделение "код считает, модель пишет" зафиксировано с самого начала работы над продуктом, именно потому что на других задачах оно уже подтвердило себя тем самым замером выше, а не потому что показалось логичным по аналогии.
Если раньше вы читали мой разбор про то, как я проверяю, что ИИ-агент действительно работает самостоятельно, а не выдаёт правдоподобный отчёт - там та же логика: проверка на цифрах, а не на отчёте агента. Здесь она применена не к работе агента, а к границе между кодом и моделью внутри продукта.
Собрать полную картину по проекту помогает витрина - загляните туда, если хотите увидеть, как устроены другие мои разработки в похожей логике: Витрина кейсов.
При каких условиях выбрал бы другое
Коротко: ручной разбор остаётся правильным, пока участников мало, а один вызов модели годится там, где ошибка недорогая.
Если в клубе десяток-другой участников, ручной разбор дешевле любой автоматизации: время на сборку правила-порога больше, чем время, которое оно сэкономит на таком объёме. Автоматизация окупается там, где решений много и они повторяются, не раньше.
Один вызов модели на всё - разумный выбор, если цена ошибки низкая. Например, черновик сообщения для внутреннего согласования, который человек всё равно прочитает и поправит перед отправкой. Там необязательность порога не страшна, потому что у решения есть ещё один барьер - мой глаз - до того, как оно повлияет на живого участника.
Связку код плюс модель, которую я выбрал для Клуббо, стоит применять там, где решение уходит наружу без второй проверки - клиенту, партнёру, участнику клуба. И там, где отказ должен быть объясним конкретной цифрой, а не общим "модель так посчитала".
Где нейросети точно не тянут
Коротко: там, где нужна арифметика с деньгами или сроками, нейросеть в контуре решения - лишний риск, а не ускорение.
Проверял это на себе не раз: правило, которое живёт только в промпте, ведёт себя иначе при повторном запуске на тех же данных. Для текста это не критично - вариативность там даже полезна. С деньгами, доступами и удержанием клиентов всё наоборот: ставка - реальная подписка человека, и решение обязано повторяться одинаково. Это работа кода, а не модели. Продление подписки, порог возврата средств, расчёт скидки - всё это я держу в коде вне зависимости от того, насколько удобно было бы спросить модель напрямую.
Как повторить такое у себя
Коротко: разделить задачу на "принять решение" и "сформулировать текст" - и не отдавать обе части одному инструменту.
- Опишите свою регулярную задачу так же конкретно, как я описал удержание участника: не "автоматизировать поддержку", а "кому из клиентов в этом месяце написать и что". Общая формулировка не сравнивается, конкретная - да.
- Разделите задачу на две части: что можно посчитать по порогу (дата последнего касания, сумма, срок) и что требует смысла и формулировки. Первое - кандидат в код, второе - кандидат в модель.
- Прогоните свою текущую практику через замер, который я описал выше: время на одно решение и доля решений без вашей правки. Без этого шага любое "стало быстрее" - ощущение, а не результат.
- Соберите порог как явное правило, а не как инструкцию модели. Если правило укладывается в одну фразу с числом внутри - это код, а не промпт.
- Подключите модель туда, где нужен именно текст под конкретный случай, а не туда, где нужно решение.
Первые три шага можно сделать самостоятельно за один присест с таблицей активности клиентов под рукой. Четвёртый и пятый - это уже сборка: связать источник данных, правило-порог и вызов модели в рабочий цикл, который не требует ручного запуска каждый раз. Здесь заканчивается разбор и начинается работа руками или заказ сборки.
Если задача похожа на мою - удержание, регулярные решения по клиентам, текст под каждого - такое можно собрать под вашу задачу так же, как я собрал это для Клуббо: с тем же разделением кода и модели и с тем же методом замера, а не на глаз. Прежде чем писать, загляните на витрину - там видно, как это разделение выглядит в других моих проектах: Витрина кейсов. Разборы других решений такого типа - в статье про то, как я считаю конверсию сайта без красивых цифр в отчёте и в разборе того, что вообще такое ИИ-агенты на живом проекте.
Если у вас похожая задача и вы хотите разбор такого же уровня по своему проекту, напишите в личку кодовое слово «РАЗБОР» - расскажу, что в вашем случае стоит считать кодом, а что моделью.