Сегментация клиентов с ИИ в этой инструкции — это распределение существующей базы по заранее заданным правилам, а не поиск новой целевой аудитории. Ниже — способ подготовить данные, готовый промпт и заполненный учебный пример. Правила условные: они показывают, как получить проверяемое распределение, но не доказывают, что такие группы полезны для бизнеса.
Какие данные собрать и как выбрать помощника
В этой инструкции мы поручаем помощнику применить заданные правила к текстовому входу. Это сценарий для текстового помощника, а не инструкция по обучению ML-модели или поиску неизвестных групп. Здесь используется простая сегментация по давности последней покупки и числу заказов. Это не отраслевой стандарт RFM и не модель оттока; вероятность покупки мы не рассчитываем.
Для учебного примера нужны нейтральный record_id, recency_days — число дней после последней покупки — и orders — число заказов. Дата среза — 20.10.2026, значения уже рассчитаны. В реальной задаче зафиксируйте дату и источник среза, способ расчёта давности, а также то, какие операции считать заказами. Например, порядок учёта отмен и возвратов — бизнес-условие: если оно не задано, его должен уточнить человек.
Выбирайте маршрут по размеру и ограничениям данных:
| Ситуация | Маршрут |
|---|---|
| Небольшая обезличенная таблица помещается в разрешённый контекст | Передайте помощнику только необходимые поля, затем сверьте назначения таблицей или кодом. Это предлагаемый способ организовать работу, а не лимит конкретного сервиса. |
| Весь набор не помещается или содержит закрытые данные | Сначала примените правила кодом или в разрешённой внутренней базе. Помощнику передайте допустимые агрегаты или образец без контактов. |
| У команды нет навыков интеграции | Начните с правил в таблице и текстового шаблона ниже. |
| Есть поддерживаемая собственная интеграция | Добавьте валидатор схемы входа и журнал изменений, чтобы фиксировать поля, правила и результаты каждого среза. |
Универсального числа строк для выбора маршрута здесь нет. Ориентируйтесь на разрешённый контекст, ограничения обработки данных и возможность независимо сверить результат. При выборе помощника проверьте доступ команды, допустимость передачи конкретных данных и пригодность формата ответа для проверки. Подтверждённую цену здесь не сравниваем: смотрите актуальные официальные условия поставщика.
Один документированный текстовый вариант — GigaChat. Справка GigaChat описывает генерацию текста, краткое содержание и объяснение существующей работы простым языком. ГигаЧат: работа с текстом. Это описание возможностей для работы с текстом, а не свидетельство точности сегментации клиентской базы.
ГигаЧат поддерживает анализ DOCX, PDF и TXT. Документация GigaChat о работе с документами
В учебном примере используются только нейтральные ID и два признака — без ФИО, телефонов и контактов. Для реальной задачи сначала проверьте, разрешён ли выбранный контур и каковы условия обработки данных поставщиком. Не передавайте помощнику сведения, которые не нужны для заданного правила. Если условия неясны, оставьте расчёт во внутренней базе.
Порядок работы от исходников до результата
- Зафиксируйте задачу и дату среза. Распределяются существующие записи базы, а не исследуется рынок или описывается целевая аудитория. Для учебного среза дата — 20.10.2026.
- Согласуйте поля и их определения. Запишите, откуда взяты
recency_daysиorders, как они рассчитаны и какие операции включены в число заказов. Агент по заданным правилам может собрать записи, проверить наличие полей и их типы. Если бизнес-условие неизвестно, его уточняет человек. - Оставьте только необходимый вход. Передавайте ID и признаки, нужные для правил. Не добавляйте контакты и не просите помощника восстанавливать пропуски или угадывать значения. Повторяющиеся ID отправьте на разбор, не объединяйте их молча.
- До сравнений проверьте оба поля отдельно.
recency_daysдолжен иметь типint— неboolи не строка — и значение не меньше нуля.ordersтоже должен иметь типint, неboolи не строка, со значением не меньше единицы. Отсутствующее поле,null, неверный тип, отрицательная или дробная давность, ноль, отрицательное или дробное число заказов сразу направляют запись вreview. Не заменяйте неизвестное нулём. - Только после проверок примените правила. Если
recency_days > 30, назначьтеinactiveнезависимо отorders. Еслиrecency_days <= 30иorders >= 2, назначьтеactive_repeat. Еслиrecency_days <= 30иorders = 1, назначьтеactive_first. - Сверьте покрытие и назначения. Таблица или код могут применить те же условия детерминированно; автоматизированный агент может проверить формат и сравнить назначения с расчётом по правилам. Каждый ID должен встретиться ровно один раз: в одной группе или в
review_queue. Исключения и отсутствующие бизнес-условия разбирает человек; ручная вычитка каждой обычной строки не требуется. - До применения результата согласуйте действия. Для каждой группы определите допустимый сценарий, канал и бизнес-условия. До подтверждения этих условий возможны только черновики и задачи на проверку, не отправка сообщений.
При обновлении среза отделяйте ожидаемые переходы из-за прошедших дней от изменений, вызванных новыми правилами. Иначе нельзя понять, изменились данные или способ распределения.
Промпт и пример
Разбить собственную клиентскую базу по явно заданным правилам и проверить исключения. Полный промпт и заполненный учебный результат на раскрытых входных данных.
Промпт задаёт процедуру для разных наборов данных, а не просит заранее выдать результат для приведённых ниже ID. Перед использованием заполните дату и определения полей, затем вставьте только данные, которые разрешено передать помощнику. Если определения или пороги не согласованы, сначала уточните их с ответственным человеком.
Готовый промпт
Задача: подготовить черновое распределение записей существующей клиентской базы по заданным правилам. Не исследуй рынок, не создавай новые сегменты, не меняй пороги и не выводи вероятность покупки.
Дата среза: [ГГГГ-ММ-ДД].
Поля: record_id, recency_days, orders.
Определения полей, источники и способ расчёта: [вставьте согласованные определения].
До любых сравнений с порогами проверь оба поля отдельно:
- recency_days должен иметь тип int, но не bool и не строку, и значение >= 0;
- orders должен иметь тип int, но не bool и не строку, и значение >= 1.
Если поле отсутствует или равно null, тип не подходит, recency_days отрицателен или дробный, либо orders равен нулю, отрицателен или дробный, сразу помести запись в review_queue и укажи причину. Не применяй к ней правила групп. Не заменяй пропуски нулями и не восстанавливай значения из контекста.
Только если оба поля прошли проверку, примени правила:
- recency_days > 30 — inactive независимо от orders;
- recency_days <= 30 и orders >= 2 — active_repeat;
- recency_days <= 30 и orders = 1 — active_first.
Входные записи:
[вставьте только поля, которые разрешено передать этому помощнику].
Проверь результат:
- каждый record_id встречается ровно один раз: в одной группе или в review_queue;
- если record_id повторяется во входе, помести его в review_queue с причиной;
- не меняй правила, пороги и значения;
- не добавляй сведения, которых нет во входе;
- не отправляй сообщения и не запускай рассылку;
- если распределение невозможно или неоднозначно, укажи ID и причину в review_queue;
- считай ответ черновиком для сверки с отдельным расчётом по тем же правилам.
Верни только JSON по схеме:
{
"groups": {
"название группы": {
"record_ids": ["..."],
"rule": "краткая формулировка применённого правила"
}
},
"review_queue": [
{"record_id": "...", "reason": "почему запись нельзя распределить автоматически"}
]
}
Условный вход
Данные вымышленные: это не клиентский кейс и не результат испытания сервиса. Значения уже рассчитаны на дату среза 20.10.2026.
| ID | recency_days |
orders |
|---|---|---|
| C1 | 10 | 3 |
| C2 | 80 | 1 |
| C3 | null |
2 |
| C4 | 20 | 1 |
| C5 | 35 | 4 |
Заполненный результат
{
"groups": {
"active_repeat": {
"record_ids": ["C1"],
"rule": "recency_days <= 30 и orders >= 2"
},
"inactive": {
"record_ids": ["C2", "C5"],
"rule": "recency_days > 30 независимо от orders"
},
"active_first": {
"record_ids": ["C4"],
"rule": "recency_days <= 30 и orders = 1"
}
},
"review_queue": [
{
"record_id": "C3",
"reason": "recency_days равно null; запись отправлена в review до применения правил групп"
}
]
}
Покрытие входа: C1 — active_repeat, C2 и C5 — inactive, C4 — active_first, C3 — review_queue. Каждый ID указан ровно один раз.
Граничные входы проверяются отдельно и не добавляются к основной пятёрке:
recency_days |
orders |
Ожидаемый результат |
|---|---|---|
| -1 | 2 | review — отрицательная давность недопустима |
| 1.5 | 2 | review — дробная давность недопустима |
| 10 | 0 | review — число заказов должно быть не меньше 1 |
| 30 | 1 | active_first — граница входит в recency_days <= 30 |
| 31 | 1 | inactive — применяется правило recency_days > 30 |
Строковые значения, bool и отсутствующие поля также направляются в review. Во всех случаях сначала проверяются тип и диапазон обоих полей, затем применяются правила групп.
Проверка, ограничения и следующий шаг
Сверьте уникальные ID: каждый должен попасть ровно в одну группу или в review_queue. Проверьте, что для назначений использовано нужное правило, а некорректные значения не исчезли и не превратились в ноль. Технические сверки можно поручить агенту по заданным условиям и повторить таблицей или кодом. Человеку нужно подключаться к исключениям и неизвестным бизнес-условиям, а не вручную перечитывать каждую обычную запись.
Для проверки устойчивости дважды обработайте неизменный вход и сравните назначение каждого ID. Расхождения отправьте в review; затем устраните причину детерминированной реализацией правил. При новом срезе отдельно разберите переходы из-за изменившейся давности и изменения самих правил. Повторяемость показывает, насколько стабильно применяются условия, но не доказывает полезность групп.
До работы с кампаниями сопоставьте каждую группу с заранее согласованным действием и бизнес-условиями. Например, как будущий процесс можно предложить:
| Группа | Возможная задача в CRM и черновик | Что нужно подтвердить до отправки |
|---|---|---|
active_repeat |
Создать задачу проверить уместность повторного предложения и подготовить черновик email. | Актуальность предложения, содержание и разрешение на email. |
active_first |
Создать задачу подготовить помощь после покупки и черновик сообщения в разрешённом мессенджере. | Нужен ли такой сценарий, какой мессенджер разрешён и что должно быть в сообщении. |
inactive |
Создать задачу проверить актуальность потребности и подготовить черновик email без придуманной скидки. | Актуальность потребности, содержание обращения и разрешение на email. |
review |
Создать задачу исправить или уточнить данные. Исходящих сообщений нет. | Корректные значения и причина исключения. |
Это предложения для будущего процесса, не существующая интеграция и не готовые маркетинговые решения. Фактический канал, разрешение на коммуникацию и содержание предложения неизвестны; любые реальные отправки заблокированы до подтверждения этих условий. Полезность сценариев проверяйте отдельно измерением, выбранным для конкретной задачи. Учебная сверка подтверждает только применение условных правил к приведённым строкам.
Если задача — описать аудиторию, а не распределить записи существующей базы, это отдельный материал: «Анализ целевой аудитории с помощью нейросети: пример». Для отдельной проверки таблицы и расчётов пригодится «Нейросеть для анализа данных в Excel: пример и проверка».
В результате у вас будет распределение по заданным правилам и список записей, которым не хватает корректных данных или согласованного бизнес-условия. Следующий шаг — проверить исключения, подтвердить допустимые действия и только после этого решать, запускать ли отдельное измерение эффекта.
Автор метода «Машиночитаемый маркетинг»