Анализ обращений клиентов нейросетью: как найти повторяющиеся проблемы

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

Подпишитесь на Telegram-канал, чтобы получать разборы применения ИИ в рабочих задачах.

Что считать одним обращением и какие данные выгрузить?

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

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

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

Работайте в разрешённой компанией среде. Из подготовленной копии уберите лишние контакты, номера документов и закрытые сведения. Удаление имён само по себе не доказывает полной анонимности: человека иногда можно узнать по оставшемуся контексту. Правила доступа сотрудников и допустимые данные стоит закрепить в политике использования ИИ в компании.

Как задать категории, чтобы нейросеть не придумала причину?

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

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

В руководстве CDC по анализу качественных данных описаны письменные определения категорий, повторное чтение материалов и проверка альтернативных объяснений. Это метод из другой области. Здесь он служит опорой для практического правила: смысл категории должен быть понятен проверяющему, а вывод должен находиться в тексте.

Сам сценарий поиска повторяющихся проблем указан и в анонсе Яндекса:

Это заявление производителя о возможном применении. Оно не подтверждает качество разметки ваших данных. Для проверки попросите по каждому ID вернуть категорию, дословную цитату и отметку сомнения. Если данных не хватает, ответ «неясно» полезнее выдуманной жалобы.

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

Как выглядит анализ на примере 12 сообщений и 10 обращений?

Все сообщения созданы для учебного теста. Это не переписки реальных клиентов и не результат внедрения в компании. Разметку выполнил Codex один раз: ему передали тексты и правила, но не передавали заранее подготовленный эталон. После этого программа сверила результат с эталоном, ID и точными цитатами. Совпадение в этом примере не оценивает качество на других данных.

Для повторения упражнения приложите таблицу и задайте правила:

Разметить каждое обращение по его ID. Разные ID не объединять.
Основная категория: первое явно описанное затруднение.
Доставка: опоздание, неверный адрес или отсутствие доставки.
Качество: дефект или неполный комплект товара.
Оплата: ошибочное списание или ожидание возврата денег.
Поддержка: нет ответа оператора.
Вопрос: информационный вопрос без явно описанной проблемы.
Неясно: по тексту нельзя установить, что именно произошло.
Запрос возврата платы за задержку оставить второй темой «оплата».
Для каждого ID вернуть основную категорию и дополнительные темы,
ID сообщений, точную цитату клиента и отметку «нужна проверка».
Новые ID, цитаты и причины не добавлять. Подсчёты пока не делать.

Полученная сводка основных категорий выглядит так:

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

Как проверить разметку и правильно посчитать проблемы?

1. В такой небольшой выгрузке проверьте все строки. Для A01 в результате должны сохраниться M01, M02 и M03. У A03 цитата про опоздание подтверждает доставку, а запрос вернуть плату подтверждает дополнительную тему оплаты. Для A10 нужна отметка проверки. Не ограничивайтесь убедительными примерами: сверяйте и записи, которым модель не назначила проблему.

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

3. Арифметику вынесите в таблицу или программу. По основным категориям сумма равна 10: 3 + 2 + 2 + 1 + 1 + 1. Для доставки берутся уникальные A01, A02, A03. Подсчёт строк сообщений дал бы M01, M02, M03, M04, M05, то есть пять. Повторный контакт показывает развитие одного обращения, но не добавляет отдельный случай в выбранную единицу подсчёта.

4. С дополнительными темами оплата встречается у A03, A06 и A07. Тогда получится 11 назначений категорий на 10 обращений. В документации Zendesk о COUNT и D_COUNT объясняется похожая ситуация: уникальные значения внутри групп с несколькими тегами могут в сумме превышать общий итог. Подпишите, что именно считает каждый столбец.

5. Если нужны доли, укажите знаменатель. Доставка здесь занимает 3 из 10 обращений, то есть 30%. В числитель и знаменатель входят обращения, а не сообщения или клиенты. Подготовка вычислений и проверка результата подробнее разобраны в статье про нейросеть для анализа таблиц.

Как превратить сводку жалоб в действие компании?

Группа доставки в учебной таблице неоднородна: два обращения о сроках и одно о неверном пункте. Общий вывод «исправить доставку» слишком широк. Для A01 и A03 можно проверить обещанный и фактический срок; для A02 проверить выбор пункта при оформлении и передачу адреса. Нехватка курьеров, ошибка интерфейса или ошибка сотрудника пока остаются предполагаемыми причинами.

Составьте короткий список: проблема, подтверждающие ID, проверяемый вопрос, ответственный за проверку и принятое действие. Приоритет определяйте по частоте и последствиям проблемы: даже единичное ошибочное списание может требовать внимания раньше информационного вопроса, который клиенты задают регулярно.

В поддержку обращаются не все клиенты, а часть каналов может отсутствовать в файле. Поэтому 30% обращений о доставке не означает, что задержку испытали 30% покупателей. Для такого вывода нужны сведения обо всех соответствующих заказах и правило выявления задержки. Похожую оговорку делает CFPB для своей базы жалоб: она не представляет статистическую выборку всего клиентского опыта. Перенос этой оговорки на вашу выгрузку требует учитывать способ её сбора.

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

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

Когда обычного чата для анализа обращений недостаточно?

Документация ChatGPT подтверждает работу с CSV и вычислениями. Для таблицы нужны понятные заголовки и одна запись на строку. Доступность анализа зависит от модели, аккаунта и настроек. Проверяйте метод, предположения и результаты; возможность прочитать файл не гарантирует правильную классификацию жалоб.

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

Например, Yandex SpeechSense обрабатывает текстовые диалоги клиента с оператором или ботом; авторов сообщений необходимо обозначить перед загрузкой. Теги настраиваются и активируются на уровне проекта. Для смысловых тегов каналы оператора и клиента назначаются совместно, поэтому проверяйте, чья реплика стала основанием. Это не подтверждение загрузки произвольной CSV-таблицы без подготовки.

Отдельно выясните, охватывает ли отчёт все диалоги или только часть. Для описанного в документации SpeechSense механизма смысловых атрибутов в выборке отчёта нужны минимум 100 диалогов. Если их больше 1000, анализируется случайная тысяча. Это условие конкретного механизма, которое нельзя переносить на весь продукт.

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