Классификация жалоб клиентов: как сочетать правила и LLM

Почему простая схема быстро ломается

На бумаге все выглядит просто: есть 8-10 категорий, оператор выбирает одну, и обращение уходит в нужную очередь. На практике такая схема живет недолго.

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

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

Отсюда вторая проблема: в одном тексте часто сразу две или три темы. Клиент мог начать с двойного списания, потом добавить, что карта не привязалась, а в конце пожаловаться на грубый ответ в чате. Если система просит выбрать одну метку, она обрезает смысл. Часть обращения попадет в работу, а часть потеряется.

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

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

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

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

Простая схема ломается не потому, что ее плохо придумали. Она ломается потому, что живой текст и живой бизнес меняются быстрее, чем правила.

Что система решает по каждому обращению

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

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

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

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

Потом система ставит SLA. Один срок для всех тут не работает. Срочность зависит от риска, суммы, канала и типа клиента. Сообщение про двойное списание на 500 тенге и жалоба на операцию на 480 000 тенге не должны ждать одинаково. Жалоба из публичного канала или от крупного B2B-клиента тоже часто требует более быстрого ответа.

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

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

Где оставить правила, а где дать слово LLM

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

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

LLM нужен в другой части задачи. Он читает смысл, даже когда текст неровный и сумбурный. Клиент может жаловаться сразу на три вещи, перескакивать с детали на деталь, путать причину и следствие. Модель все равно часто понимает, что перед ней спор по оплате, вопрос по доставке или риск пропуска SLA.

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

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

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

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

Как собрать схему по шагам

Классификация работает лучше, когда схема остается скучной и понятной. Если команда не может быстро объяснить, чем одна категория отличается от другой, модель тоже начнет путаться.

Сначала сузьте категории

Не начинайте с полного справочника. Для старта хватит рабочего набора из 10-20 категорий. Берите только те группы, которые сотрудники поддержки действительно различают в ежедневной работе. Если две категории почти всегда ведут в одну очередь и получают один срок ответа, их лучше объединить.

Для каждой категории сразу опишите три вещи: куда уйдет обращение, какой у него SLA и при каком условии нужен разбор старшим сотрудником. Иначе получится красивая метка без пользы для процесса. Например, категория "Платеж не прошел" может идти в финансовую очередь, иметь ответ за 30 минут и отдельную эскалацию, если клиент пишет о повторном списании или блокировке карты.

После этого добавьте жесткие правила для срочных и однозначных случаев. Они хорошо ловят слова и признаки, по которым ошибаться нельзя: "двойное списание", "деньги списали дважды", "не могу войти", "утечка данных", упоминание суда, регулятора или медицинского риска. Здесь не нужно спрашивать модель, если маршрут и приоритет очевидны.

Потом добавьте LLM

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

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

Порог уверенности не стоит ставить слишком низко. Если модель колеблется, лучше отправить жалобу человеку, чем сломать SLA и положить обращение в чужую очередь. Многие команды начинают с осторожного режима: все, что ниже 0.7 или 0.8, уходит на ручную проверку.

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

Как работать с неуверенностью и новыми темами

Когда жалобы пишут свободно, модель почти никогда не ошибается одинаково. Сегодня она путает возврат с отменой, завтра видит в жалобе на курьера риск мошенничества. Поэтому системе нужен не один ответ, а честная работа с сомнением.

Два порога вместо одного

Команды часто ставят один общий порог уверенности и на этом останавливаются. Это неудобно. Выбор очереди и выбор SLA лучше разделить.

Очередь можно назначать при более низкой уверенности, если ошибка не слишком дорогая. SLA лучше ставить только там, где модель уверена заметно сильнее. Иначе получится опасная ситуация: обращение ушло "почти туда", а срок реакции система уже пообещала как для критичного случая.

Простой пример: текст "Деньги списались дважды, ответа нет уже третий день" похож и на биллинг, и на эскалацию по срокам. Очередь биллинга можно выбрать рано. Жесткий SLA на финансовый инцидент лучше ставить только после более строгой проверки.

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

Как ловить новые темы

Ручная проверка - это не запасной аэродром, а источник новых правил. Сохраняйте обращения, которые модель часто отправляет на разбор человеку, путает между двумя категориями или помечает как "другое".

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

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

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

Пример: жалоба на двойное списание

Клиент пишет: "Деньги списали два раза, ответа нет уже три дня". Для человека здесь сразу две проблемы. Первая - возможная ошибка в платеже. Вторая - поддержка молчит дольше, чем обещала.

Если система смотрит только на одну тему, обращение легко уходит не туда. Биллинг видит спорную операцию, но никто не замечает срыв по ответу. Или наоборот: жалоба попадает в общую поддержку, хотя деньги нужно проверять сразу.

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

LLM нужен для второй части текста. Он видит, что клиент жалуется не только на списание, но и на то, что ответа нет уже три дня. Правило часто это пропускает, потому что люди пишут по-разному: "тишина", "никто не ответил", "меня уже третий день игнорируют". Модель сводит эти формулировки к одной теме - задержка поддержки.

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

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

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

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

Ошибки, которые дорого обходятся

Самая частая дорогая ошибка - не модель, а сама схема категорий. Команда заводит слишком много похожих ярлыков: "ошибка списания", "двойное списание", "спор по платежу", "возврат по карте". На бумаге разница кажется понятной, а в живых текстах она быстро размывается. В итоге путаться начинают даже люди, не только LLM.

Если категории похожи, одно и то же обращение легко уезжает в разные очереди. Это часто случается, когда правила пересекаются: по словам письмо похоже на биллинг, по тону - на срочную претензию, по сумме - на VIP-кейс. Система отправляет жалобу то в финансы, то в общую поддержку, а таймер SLA живет своей жизнью. Клиенту от этого не легче. Команда тоже теряет время на перекидывание тикета.

Отдельная проблема - изменения, которые никто не доводит до конца. Бизнес меняет SLA, добавляет новую очередь, пересматривает приоритеты, а промпт и тестовый набор остаются старыми. Через месяц на дашборде все выглядит терпимо, но жалобы уже едут по вчерашним правилам. Если вы меняете маршрутизацию, обновляйте сразу правила, промпт, примеры и проверочный набор.

Еще одна дорогая привычка - заставлять модель угадывать то, что правило решает за секунду. Если письмо пришло от партнера с отдельного адреса, если в тексте есть номер типа обращения, если клиент сам выбрал тему в форме, не надо просить LLM заново "понять смысл". Правила и LLM должны честно делить работу: правило забирает очевидное, модель разбирает свободный текст, смешанные случаи и шум.

Хуже всего, когда никто не разбирает спорные случаи. Тогда ложные эскалации копятся тихо: срочные тикеты попадают наверх без причины, простые вопросы получают лишний приоритет, а реальные риски тонут в фоне.

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

Небольшой разбор часто дает больше пользы, чем еще один раунд дообучения. Если система ошиблась 30 раз на одном и том же типе жалоб, причина обычно не в "слабой модели", а в плохой схеме, старом промпте или пересечении правил.

Быстрая проверка перед запуском

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

То же касается SLA. Формулировка вроде "ответим быстро" не годится. Для жалобы на блокировку платежа срок может быть 15 минут, для спорного возврата - 2 часа, для общей претензии по сервису - один рабочий день. Когда сроки заданы явно, система перестает быть лотереей.

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

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

Низкая уверенность должна вести не в случайную очередь, а в ручной разбор. У этого маршрута тоже нужен срок. Иначе туда начнут стекаться все спорные обращения, а команда увидит их слишком поздно. Часто хватает простого правила: все, что ниже заданного порога уверенности, получает человека в цепочке и отдельный SLA.

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

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

Что делать дальше

Не пытайтесь сразу охватить весь поток жалоб. Лучше взять одну линию поддержки и 3-5 самых частых тем, где ошибка дорого стоит: платежи, доставка, возврат и блокировка аккаунта. Так быстрее видно, где правила уже помогают, а где LLM путается.

Проверяйте схему не на старом учебном наборе, а на свежих жалобах за последние 2-4 недели. Люди меняют формулировки постоянно: сегодня пишут "списали дважды", завтра - "деньги ушли повторно", послезавтра прикладывают пол-экрана переписки. Если тестировать только на чистых примерах, система покажет красивую точность на бумаге и слабый результат в живой очереди.

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

Метрики тоже лучше разделить сразу. Ошибка в очереди и ошибка в SLA - не одно и то же. Если жалоба про мошенничество ушла в "общие вопросы", это одна проблема. Если тема распознана верно, но обращение не получило срочный приоритет, это уже другая. Когда вы считаете эти промахи отдельно, команда быстрее находит причину: сбой в правилах, слабое описание SLA или плохой ответ модели.

До запуска в продакшен стоит заранее продумать и служебную часть. Нужны аудит-логи, чтобы потом понять, почему система приняла такое решение. Нужно маскирование PII, чтобы в промпты и логи не утекали номера карт, телефоны и адреса. И лучше заранее решить, как вы будете менять модель, если текущая начнет хуже работать на новых типах жалоб.

В такой точке удобнее иметь один совместимый API-шлюз, а не вшивать отдельную логику под каждого провайдера. Например, AI Router на airouter.kz дает OpenAI-совместимый эндпоинт, так что команда может менять base_url и сравнивать разные модели без переделки клиентского кода, SDK и промптов. Это особенно удобно, если нужно быстро проверить новую модель на реальных жалобах, хранить данные внутри Казахстана и держать аудит-логи в одной схеме.

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