Каким методом следует оценивать причинно-следственный эффект внедрения генеративного AI-ассистента на первой линии клиентской поддержки на удовлетворённость пользователей (CSAT) и операционные затраты, если полное A/B-тестирование невозможно из-за риска деградации сервиса в пиковые часы, существует эффект обучения как операторов, так и пользователей, а часть диалогов требует эскалации на человека, создавая зависимость между тестовой и контрольной группами?

Ответ на вопрос

Исторически клиентская поддержка развивалась от монополии человеческих операторов к автоматизации через rule-based чат-боты, которые, однако, часто фрустрировали пользователей из-за жёстких сценариев. Современный этап характеризуется внедрением Large Language Models (LLM) типа GPT-4 или Claude, способных вести контекстные диалоги и решать комплексные задачи без жёсткого программирования логики. Проблема оценки эффективности таких систем усугубляется тем, что традиционные метрики (время решения, cost-per-ticket) коррелируют с качеством обслуживания нелинейно: снижение затрат может приводить к падению CSAT, а повышение автоматизации — к росту фрустрации при неудачных эскалациях.

Постановка задачи требует изоляции чистого эффекта именно AI-ассистента, отделённого от сезонности (праздничные распродажи меняют профиль обращений), эффекта новизны (пользователи экспериментируют с ботом активнее в первые недели) и эндогенности самоотбора (простые запросы уходят боту, сложные — сразу к людям). Классическая рандомизация невозможна, так как отключение поддержки для контрольной группы в пиковые часы создаёт этические и бизнес-риски, а эскалация диалога от бота к человеку загрязняет чистый эффект.

Оптимальное решение — использование Regression Discontinuity Design (RDD) на пороге длины очереди ожидания. Когда количество ожидающих пользователей превышает порог N (например, 5 человек), система автоматически предлагает AI-ассистента как альтернативу ожиданию оператора. Это создаёт естественный эксперимент: пользователи слева и справа от порога статистически идентичны по наблюдаемым и ненаблюдаемым характеристикам. Для учёта эффекта обучения модели применяется Difference-in-Differences с прокси-группой — например, пользователи ночного времени, где бот работает постоянно, сравниваются с аналогичным временным окном до внедрения. Для анализа гетерогенности эффектов (разный impact для разных категорий запросов) используются Causal Forests, позволяющие построить условные средние эффекты воздействия (CATE).

Ситуация из жизни

В крупном e-commerce проекте с 500K обращений в месяц команда решила внедрить LLM-ассистента для обработки запросов типа "где мой заказ" и "изменить адрес доставки". Проблема заключалась в том, что пилот совпал с предновогодним сезоном, когда трафик вырос в 3 раза, а исторические данные показывали сезонное снижение CSAT из-за задержек логистики независимо от качества поддержки.

Первый рассмотренный вариант — прямое сравнение метрик месяц до и месяц после внедрения. Плюсы: простота реализации, не требует изменений в инфраструктуре. Минусы: полное отсутствие контроля сезонности, невозможно отделить эффект AI от эффекта роста общего трафика и изменения ассортимента (новогодние товары имеют другой профиль возвратов). Этот подход отвергли сразу.

Второй вариант — гео-сплит A/B тест, где в одних регионах бот включён, в других — нет. Плюсы: чистая рандомизация, простая интерпретация. Минусы: сетевые эффекты (пользователь может жить в регионе A, но оформлять заказ в регионе B для друга), различная логистическая инфраструктура влияет на природу обращений, а в пиковые часы перегрузка в одном регионе создавала бы риск потери клиентов. Решено было искать альтернативу.

Выбранное решение — RDD с порогом длины очереди 3 человека. Когда очередь превышала 3 ожидающих, система предлагала AI-ассистента с возможностью остаться в очереди на человека. Для корректировки эффекта эскалации использовали Intent-to-Treat (ITT) анализ: сравнивали всех, кому предложили бота, независимо от фактического использования, что избегало смещения самоотбора по технической грамотности. Дополнительно построили Synthetic Control из исторических данных похожих категорий запросов, где бот не применялся (например, сложные претензии), чтобы отфильтровать сезонные колебания.

Итоговый результат: удалось измерить, что AI-ассистент снижает среднее время решения простых запросов с 8 до 2 минут без статистически значимого падения CSAT (разница в 0.1 пункта в пределах доверительного интервала). Однако обнаружили негативный эффект для сегмента "возвраты": при эскалации от бота к человеку CSAT был на 15% ниже, чем при прямом обращении к оператору, что привело к созданию отдельного fast-track маршрута для таких запросов. Операционные затраты снизились на 30% за счёт разгрузки первой линии.

Что кандидаты часто упускают

Как корректно обработать эндогенность эскалации, когда пользователь, разочаровавшись в боте, переходит к человеку с повышенной фрустрацией?

Кандидаты часто предлагают сравнивать только успешные диалоги с ботом против диалогов с человеком, игнорируя смещение выживания. Правильный подход — анализ Local Average Treatment Effect (LATE) через инструментальные переменные: использование случайных технических сбоев в работе бота (когда он временно недоступен) как инструмента для оценки эффекта именно для тех, кто был бы обслужен ботом при наличии такой возможности. Это позволяет отделить эффект самой технологии от эффекта селекции по типу запроса.

Почему стандартные метрики accuracy бота (F1-score, BLEU) некорректны для продуктовой оценки causal impact?

Часто аналитики фокусируются на качестве генерации ответов, забывая, что продуктовая цель — изменение бизнес-метрик, а не техническое совершенство. LLM может генерировать грамотные, но нерелевантные ответы, или наоборот — давать технически неточные, но решающие проблему пользователя инструкции (например, "попробуйте перезагрузить приложение"). Корректный подход — оценка uplift на уровне пользовательской сессии с использованием Propensity Score Matching для сопоставления сложности запросов, а не точности генерации текста.

Как учесть non-stationarity эффекта при постоянном дообучении модели на новых данных?

Кандидаты упускают, что LLM в продакшене подвергается continual learning: модель дообучается на размеченных диалогах ежедневно, поэтому эффект недели 1 некомпарабелен с эффектом недели 4. Необходимо использовать Time-Varying Treatment Effects модели с rolling window оценкой или Bayesian Structural Time Series (BSTS) для динамической корректировки baseline. Игнорирование этого приводит к недооценке долгосрочного эффекта, когда бот "обучается" на специфике продукта, или к переоценке эффекта новизны.