Классификация обращений в Service Desk с помощью LLM

Почему тикеты плохо классифицируются и что дает LLM

Почти в любом Service Desk категории заполняются «как получится». Пользователь выбирает первое, что похоже, оператор спешит разобрать очередь, а каталог услуг со временем обрастает похожими пунктами. В итоге тикет оказывается не там, где нужно, и команда тратит время не на решение, а на пересылки.

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

Ручная классификация плохо масштабируется. В спокойные часы опытный диспетчер еще держит качество, но в пиковые моменты (массовые проблемы после обновления, начало рабочего дня, ночные дежурства) оно быстро падает. Новые сотрудники учатся долго: нужно запомнить тонкие различия вроде «Доступ к системе» vs «Проблемы с учетной записью» и понимать, где проходит граница между инцидентом и запросом.

Здесь часто помогает классификация обращений в Service Desk с помощью LLM (больших языковых моделей). Модель читает свободный текст и пытается понять смысл, а не точное совпадение слов. Это особенно полезно, когда описания короткие, написаны «человеческим» языком, содержат опечатки или смешанные языки (например, русский и казахский в одном сообщении).

Где LLM помогает, а где нет

LLM дает максимум пользы, когда в тикете есть хотя бы 1-2 предложения с понятным описанием проблемы или просьбы, а категории реально отражают услуги и зоны ответственности. Очень помогает и минимальная история прошлых обращений: без примеров модели сложнее «схватить» вашу логику.

Но это не панацея. Если в данных и процессе хаос, автоматизация упирается не в качество модели, а в отсутствие опоры: пустые поля, одинаковые категории с разными названиями, противоречивые правила, или половина тикета состоит из «не работает, помогите». Модель не заменит владельца каталога услуг и не исправит плохую форму обращения.

Типичная ситуация: пользователь пишет «Не печатает, срочно, на 3 этаже» и не указывает устройство и кабинет. Оператор может отправить тикет в «Принтеры», потом выяснится, что проблема в сетевом доступе, и обращение уйдет в «Сеть». LLM может сразу предложить наиболее вероятную категорию и подсказать, каких данных не хватает (например, модель принтера, имя ПК, номер кабинета). Это снижает число пересылок и ускоряет старт работы, особенно когда поддержка обслуживает большой парк рабочих станций, серверов и рабочих мест в разных филиалах.

Категории и подкатегории: как собрать рабочую схему

Хорошая классификация начинается не с «удобных ярлыков», а с ответственности. Категория должна отвечать на простой вопрос: какая команда реально возьмет тикет и по какому процессу его решать. Поэтому схему лучше привязать к каталогу услуг (что поддерживаем) и зонам ответственности (кто поддерживает). Иначе автоматическая маршрутизация будет постоянно ошибаться.

Для старта полезно собрать минимально жизнеспособный набор полей и только потом углубляться. На первом этапе обычно хватает такой структуры:

• Тип: инцидент или запрос.
• Услуга: например, «Рабочее место», «Почта», «Сеть», «Серверы», «Service Desk доступы».
• Компонент: уточнение внутри услуги (VPN, принтер, учетная запись, монитор, RAID и т.д.).
• Приоритет: по правилам бизнеса (влияние и срочность), а не «на глаз».

Частая ошибка - делать дерево слишком глубоким: 6-8 уровней, десятки похожих веток и разные названия одного и того же. Это портит и статистику, и обучающие данные: на каждую ветку набирается мало примеров, и модель начинает путаться. Практичный ориентир - 2-3 уровня. На каждом уровне названия должны быть взаимно исключающимися и понятными без внутреннего жаргона.

Чтобы договориться о названиях и правилах, не обсуждайте их абстрактно. Возьмите по 10-20 реальных тикетов на каждую будущую категорию и разберите их вместе: «как бы вы назвали это» и «почему это попадает сюда». Затем зафиксируйте правила так, чтобы их понял новичок:

• Короткое имя категории и одно предложение, что входит.
• Несколько примеров «входит» и «не входит».
• Явная команда-владелец и запасной маршрут (если владелец недоступен).
• Правило выбора между похожими категориями: один решающий признак.

С «прочее» лучше быть жесткими. Допустимо временно оставить «прочее» как аварийный контейнер, пока нет данных или процесс еще не определен. Вредно, когда «прочее» становится привычным выбором: так вы прячете новые типы проблем и лишаете LLM опоры. Простое правило: если доля «прочее» держится выше 3-5% две недели подряд, значит пора либо добавить новую категорию, либо уточнить правила и примеры.

Пример из практики: в поддержке производственной компании «Рабочее место -> Не включается» и «Рабочее место -> Медленно работает» лучше разнести по разным компонентам, если их часто берут разные специалисты и под них действуют разные SLA. Это хороший признак, что компонент нужен по делу, а не как «еще один уровень ради красоты».

Данные из Service Desk: что подготовить заранее

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

По каждому тикету полезно собрать минимальный «паспорт обращения». Обычно хватает:

• Тема и полное описание (как написал пользователь).
• Короткая выжимка по вложениям (название файла, тип, 1-2 строки, без содержимого).
• Заявитель (лучше роль или тип пользователя, а не ФИО).
• Подразделение и локация (если влияют на маршрутизацию).
• CI или сервис (что сломалось: сервер, рабочая станция, почта, ВКС и т.д.).
• Канал обращения (портал, почта, телефон, мессенджер).

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

Отдельный шаг - очистка и маскирование. Здесь лучше быть строгими:

• Персональные данные (ФИО, телефоны, адреса, e-mail) заменяйте на маркеры.
• Номера документов, договоров, счетов, ИИН/БИН, банковские реквизиты скрывайте целиком.
• Секретные детали (пароли, ключи, внутренние IP, названия закрытых проектов) вырезайте или обобщайте.
• Длинные логи и дампы сворачивайте до 3-5 строк «что за ошибка».
• Дубли и «пустые» обращения (без текста) помечайте отдельно.

Чтобы проверка была честной, соберите эталонную выборку. Практичный вариант - взять последние 3-6 месяцев и обязательно включить разные команды и типы обращений: инциденты, запросы на доступ, заявки на закупку, вопросы по рабочим местам и серверам. Если вы поддерживаете инфраструктуру на базе локально произведенных ПК и серверов (как у GSE.kz), важно, чтобы в выборке были и обращения по рабочим станциям, и по серверным сервисам, а не только «пароль забыл».

Учтите двуязычные сообщения (ru-kz) и шаблонные формулировки. Не пытайтесь «исправить язык» вручную. Лучше хранить исходный текст и добавлять признак языка (или вероятность языка), а шаблоны выделить как отдельный тип. Тогда модель меньше путается на одинаковых коротких фразах и чаще опирается на контекст: CI, канал, подразделение и историю похожих тикетов.

Как LLM выдает категорию и «уверенность»

Чтобы автоматическая маршрутизация работала, от модели обычно нужен не «умный текст», а понятные сигналы для Service Desk. На практике удобно просить LLM вернуть три вещи: категорию (и при необходимости подкатегорию), оценку уверенности и короткое обоснование, которое оператор может быстро проверить.

Категория нужна для маршрута, уверенность - для выбора правил обработки, а обоснование - чтобы человек понял, почему система решила именно так. Например: «Категория: Доступы -> VPN. Причина: пользователь пишет “не подключается VPN”, “ошибка авторизации”».

Что считать «уверенностью» и как ее читать

Уверенность можно представлять по-разному. Главное - заранее договориться о формате и смысле:

• Вероятность по классам (например, 0.72 для выбранной категории).
• Нормированный балл 0-1 без строгой статистической интерпретации.
• Уровни: высокая, средняя, низкая.
• Топ-2 или топ-3 вариантов с баллами, если категории часто путаются.

Важно помнить: уверенность - не «правда» и не гарантия. Это сигнал, насколько выбор похож на типовые примеры. Один и тот же балл может вести себя по-разному на новых темах, коротких сообщениях и при плохом качестве текста (опечатки, жаргон, смешение языков). Поэтому пороги лучше подбирать на ваших данных, а не переносить из чужих кейсов.

Когда лучше задать уточняющий вопрос

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

• В сообщении нет объекта проблемы (что именно не работает: почта, VPN, принтер).
• Есть конфликтующие признаки (упоминаются сразу несколько систем).
• В тикете только «не работает», «срочно», «помогите».

Пример: пользователь пишет «Не могу войти, ошибка». Вместо назначения в «Доступы -> AD» модель может спросить: «Вы не можете войти в Windows, в почту или в корпоративный портал? Пришлите текст ошибки».

Что логировать для аудита и разбора ошибок

Чтобы потом улучшать классификацию обращений в Service Desk с помощью LLM, важно сохранять не только итоговую категорию. Минимальный набор для трассировки обычно включает: исходный текст тикета (с учетом обезличивания), версию промпта, время запроса, ответ модели (категория, уверенность, обоснование), а также итоговую «истину» после работы оператора (что он выбрал и почему). Так проще находить типовые промахи: где модель путает подкатегории, где уверенность завышена, и какие слова чаще всего уводят ее в неверный класс.

Правила эскалации и маршрутизации: решения по порогам

Цель правил - безопасно использовать уверенность модели и не ломать привычную работу Service Desk. Хорошая схема похожа на светофор: при высокой уверенности LLM можно автоназначать тикет, при средней - просить подтверждение, при низкой - отдавать на ручной разбор.

Пороги по уверенности: простой «светофор»

Пороговые значения лучше выбрать один раз для пилота и корректировать по факту ошибок. Обычно достаточно трех зон:

• Высокая уверенность (например, 0.85-1.00): автоназначение в команду и очередь, проставление категории, запуск стандартного шаблона ответа.
• Средняя уверенность (например, 0.60-0.84): категория предлагается оператору как вариант по умолчанию, но требует подтверждения или выбора другой.
• Низкая уверенность (ниже 0.60): тикет идет в общую очередь первичной линии, где человек уточняет детали и выбирает категорию вручную.

Чтобы не нарушать SLA, меняйте только «первый шаг» (куда попадает тикет), а не сроки и приоритеты. Если сейчас все начинается с 1-й линии, пусть так и остается, но с подсказкой от LLM и автоназначением только для безопасных классов.

Эскалация по риску: не все стоит автоматизировать

Есть темы, где цена ошибки высока. Для них даже высокая уверенность не должна означать полную автоматику. Правило «всегда через подтверждение» обычно оправдано для обращений про доступы, финансы, персональные данные и безопасность (например, сброс MFA, запрос прав администратора, подозрение на фишинг, блокировка учетной записи, платежные вопросы). В этих категориях модель может помогать, но финальное решение остается за человеком.

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

Фолбек-сценарии спасают от неожиданностей и снижают раздражение пользователей:

• Модель недоступна: тикет идет по старым правилам маршрутизации.
• Пустое или слишком короткое описание: автоответ с просьбой уточнить (что сломалось, где, когда), затем ручная классификация.
• Нестандартный запрос без подходящей категории: пометка «Другое» и очередь на первичный разбор.
• Слишком много категорий с близкой уверенностью: показывать топ-2 оператору, без автоназначения.
• Резкий рост ошибок в одной категории: временно отключить автоназначение для этой категории до разбора.

Пример: пользователь пишет «не могу войти в почту, просит код, код не приходит». Модель дает 0.92 на «Доступы - MFA». По правилам риска тикет не уходит автоматически в исполнение, а попадает на подтверждение 1-й линии с подсказкой и чеклистом вопросов. Это сохраняет безопасность и все равно ускоряет обработку.

Пошаговый сценарий внедрения: от пилота до продакшена

Чтобы классификация обращений в Service Desk с помощью LLM дала пользу, начинайте с маленького и измеримого пилота. Цель не в том, чтобы заменить операторов, а в том, чтобы безопасно проверить качество категорий, понятность уверенности модели и работоспособность эскалаций.

Пилот: 2-4 недели, узкий периметр

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

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

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

Практичный маршрут выглядит так:

• Согласовать цель пилота, границы (1-2 услуги или очереди), метрики и срок.
• Подготовить категории, примеры и правила эскалации по порогам уверенности.
• Настроить интеграцию (API или шина), формат запроса и фильтры по данным.
• Запустить режим подсказок оператору без автоназначения.
• Включить автоназначение для части тикетов и постепенно расширять охват.

В режиме подсказок оператор видит предложенную категорию, короткое объяснение (1-2 признака из текста) и значение уверенности. Оператор либо подтверждает, либо исправляет. Эти исправления - самый ценный материал для улучшения подсказок и правил.

Продакшен: расширение и защита от ошибок

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

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

Контроль качества после запуска: проверки и мониторинг

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

Ежедневные проверки: как сделать это привычкой

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

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

Метрики качества и признаки дрейфа

Следите за метриками так же регулярно, как за SLA. Достаточно 3-5 показателей, но они должны быть понятны операторам и руководителю:

• точность топ-1 по категории (на проверенной выборке)
• доля автоназначенных тикетов (где модель сразу отправила в нужную очередь)
• доля возвратов (когда тикет вернули из очереди или перекинули в другую)
• доля ручных правок категории оператором
• среднее время до первого ответа и до решения (до и после запуска)

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

Human-in-the-loop можно сделать почти незаметным: добавьте кнопку «Категория неверна» с выбором правильного варианта и коротким полем «почему». Важно, чтобы это действительно было в 1 клик, иначе обратная связь перестает собираться.

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

• пороги меняем, если растут возвраты, но точность на выборке стабильна
• промпт меняем, если повторяются одни и те же ошибки формулировок
• категории меняем, если появилась новая услуга или новая команда поддержки
• переобучение или расширение примеров делаем, если дрейф держится больше 2-3 недель

Так качество становится управляемым процессом, а не разовой настройкой.

Как оценить эффект по скорости обработки: метрики до и после

Чтобы понять, помогла ли классификация обращений в Service Desk с помощью LLM, нужны метрики, которые отражают реальную скорость обработки, а не только «красивую» долю автокатегоризации. Лучше всего работает сравнение «до/после» на одинаковых условиях.

Какие метрики смотреть

Начните с времени. Эти показатели обычно есть в любом Service Desk и легко объясняются бизнесу:

• Время от создания тикета до назначения на исполнителя (time to assignment)
• Время до первого ответа пользователю (time to first response)
• Время до решения (time to resolution)
• Доля тикетов, закрытых в пределах SLA
• Разброс по очередям: медиана и 90-й перцентиль (чтобы видеть «хвост»)

Дальше добавьте метрики нагрузки. Они показывают, сколько работы реально убрали у операторов первой линии:

• Доля тикетов, которые требовали ручной классификации
• Среднее время оператора на разбор и маршрутизацию (минуты на тикет)
• Количество переадресаций между очередями до правильного назначения

Как сравнивать честно и посчитать эффект

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

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

«Экономия минут на тикет» = (среднее время ручной классификации до) - (среднее время после, с учетом проверки и исправлений).

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

Пример: если раньше оператор тратил 2 минуты на разбор и выбор очереди, а после внедрения тратит 30 секунд только на подтверждение, экономия - 1,5 минуты на тикет. При 4000 тикетах в месяц это около 100 часов.

Как фиксировать побочные эффекты

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

Реалистичный пример: как это работает на потоке тикетов

Представим организацию с несколькими линиями поддержки. Первая линия принимает все обращения и закрывает простые вопросы. Вторая линия держит экспертов по сервисам, а еще есть отдельные команды по рабочим местам, сети, бизнес-системам (например, 1С/ERP) и ВКС. Раньше часть тикетов уходила не туда: заявитель выбирал «Другое», оператор спешил, а потом тикет перекидывали между группами.

Типовой поток обращений обычно включает доступы (сброс пароля, выдача прав, VPN), почту (не приходит письмо, переполнен ящик), рабочие места (не включается ПК, принтер, установка ПО), 1С/ERP (ошибки входа, «не проводится документ») и сеть или ВКС (пропал интернет, низкая скорость, не работает камера/звук).

Теперь добавляем классификацию обращений в Service Desk с помощью LLM. Заявка поступает как обычно: тема, описание, иногда вложение или выбранный сервис. Модель читает текст и предлагает категорию, подкатегорию и числовую уверенность (например, 0.92). Параллельно предлагается маршрут: в какую группу поддержки назначить тикет.

Как тикет проходит путь

Ключевой момент - пороги, по которым принимается решение:

• 0.85 и выше: автоназначение в команду, оператор только смотрит выборочно
• 0.60-0.85: оператору показывается подсказка, он подтверждает или правит
• ниже 0.60: ручная классификация и отметка «сложно» для обучения правил

Как это выглядит на практике. Пользователь пишет: «После обновления не открывается 1С, пишет “нет доступа к информационной базе”». Модель выбирает «Бизнес-системы -> 1С -> Ошибка доступа», уверенность 0.88. Тикет сразу попадает в команду 1С, и первая линия не тратит время на поиск категории.

Другой пример: «Не работает микрофон в переговорке, завтра встреча с клиентом». Модель предлагает «ВКС -> Аудио», но уверенность 0.72, потому что деталей мало. Оператору показывается подсказка и короткие уточняющие вопросы (например, какая переговорка, какое приложение). Он подтверждает маршрут в команду ВКС, и тикет не зависает в очереди «Неразобранное».

Эффект здесь заметен быстро: меньше перекидываний между группами, быстрее первичное назначение, а в отчетах появляются понятные срезы по категориям. Вместо «90% - Другое» видно, где действительно болит: доступы, почта или конкретный модуль 1С. Разговор с владельцами сервисов становится проще: не «кажется стало хуже», а «по сети выросла очередь и упала уверенность, давайте уточним категории и правила эскалации».

Чеклист и следующие шаги: как закрепить результат

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

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

• Категории и подкатегории согласованы, у каждой есть владелец (кто меняет правила и отвечает за качество).
• Пороги уверенности модели зафиксированы и утверждены: что идет в автораспределение, что в ручную проверку.
• Настроен фолбек: если уверенность низкая или тема спорная, тикет уходит в общий первичный разбор с понятным SLA.
• Включены логи решений (категория, уверенность, версия промпта/модели) и метка «вмешательство оператора».
• Назначен ответственный за качество и график пересмотра ошибок (например, 2 раза в неделю в первый месяц).

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

• Маскирование персональных данных в тексте тикета до отправки в LLM (ФИО, телефоны, ИИН, адреса, номера карт).
• Роли доступа: кто видит исходный текст, кто видит только итоговую категорию и уверенность.
• Сроки хранения: сколько держите логи, кто их удаляет, где фиксируется согласование.
• Правила для чувствительных тем (финансы, медицина, кадры): запрет на автодействия, только маршрутизация и ручная проверка.
• Регулярная выборочная проверка: 20-30 тикетов в неделю на корректность и соблюдение политики.

План на 30 дней лучше расписать заранее. Дни 1-7: пилот на 1-2 популярных категориях и сбор обратной связи от операторов. Дни 8-14: корректировка схемы категорий, уточнение порогов, добавление примеров «как не надо». Дни 15-30: расширение охвата по очередям, чтобы команда успевала учиться и не теряла контроль.

Для масштабирования заранее подготовьте «опоры»: актуальный каталог услуг, короткую базу знаний с типовыми решениями и обучение операторов (как работать с уверенностью модели и когда отключать автоматику).

Если следующий шаг для вас - интеграция с Service Desk и инфраструктура под LLM, имеет смысл подключать системного интегратора, чтобы не собирать все по частям. В GSE.kz (gse.kz) можно обсудить системную интеграцию, серверную инфраструктуру под нагрузку и организацию круглосуточной технической поддержки 24/7 для вашей службы поддержки.