Лемана Тех показала, как объединила LLM, RAG и классический ML в техподдержке

Лемана Тех рассказала, как перестроила автоматизацию Service Desk после роста потока заявок. Компания не стала заменять всю поддержку одной большой моделью, а собрала гибридную схему: массовую классификацию оставила классическому ML, а LLM с RAG подключила только там, где это реально дает пользу.

Почему старого ML мало

Внутри экосистемы Лемана Тех больше 500 бизнес-систем, 2500 сервисных операций и около 100 тысяч обращений в поддержку в месяц. Для такой нагрузки важны не только качество модели, но и цена ошибки, скорость реакции и стоимость вычислений. Базовый стек на бустингах и TF-IDF долго работал нормально: модель с дополнительными признаками вроде должности, места работы и времени обращения давала F1 около 0,86 и закрывала большую долю типовых маршрутов.

Но по мере роста количества сценариев этого стало не хватать. Команда перебрала LSTM, GRU, BERT, RoBERTa, Electra, Yandex Foundation Models и LoRA-адаптеры к открытым LLM. Часть подходов проиграла бустингам по метрикам, часть оказалась слишком дорогой по обучению.

В итоге лучший результат для классификации дал не «чистый» LLM-подход, а трансформер с дополнительными табличными признаками и additive attention: такая схема подняла F1 macro до 0,89 и лучше учитывала контекст конкретного сотрудника.

Где включают RAG LLM в этой архитектуре не пытается решать все подряд.

Ее включают только в тех классах обращений, где пользователю нужен осмысленный ответ по внутренней документации, а не просто правильная маршрутизация тикета. Один из примеров — поддержка MLOps-платформы, где сотрудникам нужны ответы по Kubeflow, Jenkins и внутренним пайплайнам. Здесь запрос идет в чат, проходит через классификатор и попадает в RAG-контур на базе Qwen2.

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

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

• Qwen2.5 8B используют в квантованной CPU-версии Кастомный эмбеддер обучали на 10 тысячах триплетов Точность поиска по базе знаний достигла 92% Hit@3 Эскалация срабатывает при confidence score ниже 0,7 Пользователь может мгновенно переключиться на человека ## Что сработало лучше Отдельная часть кейса — авторешения. Команда нашла повторяющиеся шаблоны обращений, которые можно закрывать без участия поддержки, но не стала слепо автоматизировать все частотные ответы. Для отбора использовали Qwen2.5 14B: модель оценивала, сможет ли человек реально решить проблему сам по инструкции или без сотрудника ничего не выйдет. Это отсекло ложные шаблоны вроде сброса пароля, где письмо стандартное, но действие все равно должен выполнить специалист.

«Использовать везде LLM, как сейчас модно, не стоит».

После такого отбора в продакшене снова работает не LLM, а легкая модель — логистическая регрессия. Она быстро учится, почти ничего не стоит на инференсе и может постоянно обслуживать поток заявок. На выходе Лемана Тех говорит о росте автоматизированной классификации с 55% до 76%, повышении точности классификации до 92% с учетом порогов и ускорении успешных авторешений и ответов бота более чем в 20 раз. LLM здесь не заменила классический ML, а заняла узкое, но ценное место в цепочке.

Что это значит

Кейс Лемана Тех хорошо показывает текущую зрелую логику внедрения генеративного ИИ в поддержку: дорогие LLM не обязаны быть ядром всей системы. Часто лучший результат дает гибрид, где классический ML быстро сортирует поток, RAG отвечает только в сложных доменных зонах, а человек подключается без трения, если уверенности модели недостаточно. Для корпоративных команд это, вероятно, более реалистичный путь, чем попытка перевести весь Service Desk на одну универсальную модель.