Проверка сегмента клиентов после запроса к ИИ

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

ИИ может перевести такое пожелание в условия сегмента или SQL — язык запросов к базе данных. Это упрощает работу, но не освобождает от проверки смысла. Запрос может успешно выполниться и вернуть убедительное число клиентов, хотя отобранная аудитория не соответствует задаче.

Сначала переведите пожелание в договорённость

Правила сегментации должны быть однозначными ещё до обращения к помощнику. Вместо «покупал недавно» укажите событие, период, исключения и момент расчёта. Отдельно определите, как объединяются заказы одного клиента из разных каналов.

Условный пример. На начало 1 октября по московскому времени нужны клиенты как минимум с двумя завершёнными, не полностью возвращёнными заказами за предыдущие 90 суток и без таких заказов за последние 30 суток. Неоплаченная корзина не считается заказом. Отдельная строка товара не считается отдельной покупкой.

Здесь важны границы интервалов. Период начинается включительно, заканчивается перед моментом расчёта. Так заказ ровно на границе попадёт в ожидаемую часть расчёта, а не будет случайно учтён дважды или пропущен. Условие «нет покупок» также относится к определённому периоду, а не ко всей истории клиента.

Почему правильный синтаксис не гарантирует результат

Исследование BIRD предложило проверять перевод текста в SQL на задачах, где нужно понимать значения данных, внешние сведения и устройство реальных баз. Его ценность для CRM — напоминание, что недостаточно получить формально исполнимый запрос. Результаты конкретных моделей в этом исследовании не являются оценкой качества сегодняшнего помощника в вашей компании.

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

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

Подготовьте контрольные профили

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

Последняя строка отделяет две задачи. Поведенческий сегмент описывает историю клиента. Аудитория конкретной отправки дополнительно учитывает доступность канала, разрешения, ограничения частоты и другие исключения. Если эти проверки скрыто смешаны, маркетологу трудно понять, почему итоговое число получателей меньше размера сегмента.

Сверьте результат несколькими способами

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

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

Если помощник предлагает SQL, ограничьте доступ нужными таблицами и полями. Право только на чтение всё равно позволяет извлекать чувствительные сведения. Поэтому права помощника должны ограничивать и объём доступных данных, и возможность их вывода. Проверять смысл сегмента удобнее на обезличенном наборе с достаточной структурой.

Закрепите версию перед запуском

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

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

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

Источники

Li J., Hui B., Qu G. и соавторы. Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs. arXiv:2305.03111. 2023; NeurIPS 2023.