Кейс Лемана Тех: как внедрить LLM с RAG в Service Desk для человекообразных ответов и эскалации

Почему Service Desk Лемана Тех плакал по ночам

Типичный понедельник. 5000 сотрудников, 300 тикетов. Половина - "забыл пароль". Остальное - мрак. Токен истек? Ошибка в интеграции SAP? Падение продаж в Азии? Все это летело в общую кучу, а в ответ - шаблонное "перезагрузите компьютер" от джуна, который вчера узнал про SLA. Первая линия горела, вторая - тонула в сложных кейсах, бизнес терял деньги на простоях. Классический ад технической поддержки.

Проблема была не в людях. Проблема - в информации. Она лежала в двадцати разных системах: Confluence, Jira, мануалы от вендоров, переписки в Slack, отчеты по инцидентам. Ни один живой человек не мог это все знать. Нужен был гибрид: машина, которая мгновенно найдет нужный мануал, и интеллект, который понятным языком объяснит решение. Или честно скажет: "Ребята, это не ко мне, вот специалист по SAP". Так родился проект "Оператор".

Архитектура: что склеило LLM, RAG и здравый смысл

Мы отказались от идеи "скормить модели все документы". Это путь к галлюцинациям и астрономическим счетам за токены. Вместо этого родилась гибридная трехслойная система.

• Слой 1: Классификатор и диспетчер (ML). Обычная модель (например, BERT-based), обученная на исторических тикетах. Ее задача - понять суть запроса и решить: это простой FAQ ("как сменить пароль"), сложный инцидент ("ошибка 500 в CRM") или запрос на эскалацию? Она же извлекает сущности: имена систем, коды ошибок, имена пользователей. Это резко сужает контекст для дорогой LLM.
• Слой 2: RAG-движок (Retrieval-Augmented Generation). Вот тут начинается магия. Диспетчер передает контекст (например, "ошибка в SAP FI-модуле"). RAG-система лезет не во все документы, а только в релевантный векторный индекс. Мы использовали актуальный на 2026 год Qdrant 1.8.x с новыми фильтрами по метаданным. Для чанкинга отказались от наивного разделения по абзацам - взяли семантический чанкинг с перекрытием, о котором я писал в гайде по семантическим пайплайнам.
• Слой 3: LLM-агент с навыками (Skills). Сердце системы. Мы не просто отправляем промпт с контекстом. Мы создали агента со строго описанными навыками (Skills), как в этой статье. Навык "Ответить на вопрос по документации". Навык "Запросить дополнительные данные у пользователя". Навык "Инициировать эскалацию". LLM (мы тестировали GPT-5 Turbo и открытые модели DeepSeek-R1) выступает как orchestrator, выбирая навык на основе контекста от диспетчера и данных от RAG.

1Собрать и очистить данные - не для слабонервных

Это заняло 70% времени. Не верьте тем, кто говорит "просто загрузите PDF в векторную БД". Корпоративные данные - это хаос. Один и тот же процесс в Confluence описан устаревшей версией, в Jira - комментарием от 2022 года, а в голове у старшего инженера - вообще иначе.

Мы построили ETL-пайплайн, который не просто парсил файлы. Он:

• Определял актуальность документа (дата изменения, ссылки на него).
• Извлекал метаданные: к какой системе относится, для какой аудитории (новичок/эксперт), тип (инструкция/отчет/диаграмма).
• Контекстуализировал сырые данные, превращая "custom_attribute_2847" в "внутренний ID заказа в SAP". Об этом был целый разговор в другом гайде.

2Научить агента говорить "не знаю" и эскалировать

Самое сложное - не заставить LLM дать ответ. Самое сложное - заставить ее промолчать, когда она не уверена. Мы реализовали Delegation Filter - пороговую систему уверенности. Если оценка уверенности (рассчитываемая на основе релевантности найденных чанков и внутренней "уверенности" модели) ниже порога, агент не генерирует ответ. Он либо запрашивает уточнения у пользователя, либо - и это ключ - сразу инициирует эскалацию, создавая тикет в Jira с предзаполненными полями и найденным контекстом.

Промпт для эскалации выглядел так (упрощенно):

Вы - ассистент Service Desk Лемана Тех.
КОНТЕКСТ ДЛЯ ПОИСКА: {query_context}
НАЙДЕННЫЕ МАТЕРИАЛЫ: {retrieved_chunks}
ИНСТРУКЦИЯ:
1. Если найденные материалы прямо и полно отвечают на вопрос, сгенерируй ответ.
2. Если материалов недостаточно или вопрос сложный (связан с падением продаж, ошибками в ядре системы), НЕ ГЕНЕРИРУЙ ОТВЕТ.
3. Вместо этого создай заявку на эскалацию. Используй шаблон:
   [ЭСКАЛАЦИЯ] Краткое описание: {summary}
   Система: {system}
   Приоритет: {calculated_priority}
   Контекст для эксперта: {извлеченные ключевые данные}

Этот подход убил двух зайцев: снизил галлюцинации и ускорил попадание сложных тикетов к нужным экспертам. Мы даже ввели метрику "Коэффициент разумного молчания" - процент случаев, когда агент правильно отказался от ответа. Цель - 95%.

3Интеграция в живую среду: не сломать SLA

Мы не стали запускать агента в открытый доступ. Внедрение шло поэтапно:

1. Тень (Shadow Mode). Агент обрабатывал входящие тикеты параллельно с людьми, но его ответы никому не показывались. Мы сравнивали его решения с решениями инженеров и калибровали пороги.
2. Ассистент (Copilot Mode). Ответы агента стали показываться инженеру первой линии в виде подсказок. Инженер мог их отредактировать и отправить или проигнорировать. Здесь мы собрали ценнейший фидбек.
3. Автономная работа (Pilot Mode). Для простых, высокоуверенных запросов (типа сброса пароля) агент стал отвечать автоматически. Все остальное - с человеческим одобрением.

Критически важным было тестирование. Как тестировать недетерминированную LLM? Мы использовали подход, описанный в статье "Тестируем недетерминированные LLM": фаззинг промптов, проверка структуры ответа (например, JSON с определенными полями), а не точного текста, и батарея регрессионных тестов на критичные кейсы.

Что пошло не так? Ловушки, в которые мы попали

• Галлюцинации источников. Модель иногда ссылалась на несуществующие пункты документации. Лечилось строгой привязкой чанков к ID исходного документа и post-processing проверкой: "упоминаешь источник - приложи ссылку".
• "Молчаливый ученый". В нашей базе была куча неполных, сырых записей от инженеров. Модель, получая такой чанк, думала, что это полное знание, и давала урезанный ответ. Помог принцип из статьи про эпистемическую асимметрию: мы добавили в метаданные чанков поле "completeness_score" и учили модель скептически относиться к низким оценкам.
• Стоимость. Вызов GPT-5 для каждого тикета - банкротство. Кэширование частых ответов, эффективный чанкинг (меньше токенов в контексте) и fallback на более дешевые модели для простых задач резко сократили счет. Иногда проще купить лицензию на OpenAI API, чем содержать свою инфраструктуру.
• Сопротивление команды. Инженеры боялись, что их заменят. Мы вовлекли их в процесс: они стали лучшими тестерами и "тренерами" для агента, пополняя базу знаний. Агент взял на себя рутину, освободив им время для сложных задач.

Метрики успеха: не NPS, а время и деньги

Мы забыли про абстрактное "удовлетворение пользователей". Считали конкретику:

• Среднее время решения (MTTR) для тикетов уровня 1: упало на 40%.
• Коэффициент эскалации с первой линии: вырос на 15%. Звучит плохо? Нет. Это значит, что джуны перестали мучать сложные тикеты и быстрее передавали их экспертам. Общее время решения сложных инцидентов сократилось.
• Автоматическое закрытие тикетов: 30% всех обращений (сброс пароля, информация по отпускам) теперь решается без человека.
• Операционные расходы Service Desk: снизились на 25% за счет оптимизации нагрузки.

Частые вопросы от скептиков (которые были правы)

Следующий шаг для Лемана Тех - превращение этого агента в проактивного помощника, который предупредит о проблемах до того, как о них напишут в Service Desk. Но это уже история про агентное обучение с подкреплением. А пока что, если ваш Service Desk тонет в тикетах, начните не с покупки лицензии на ChatGPT, а с аудита своих данных. Самый умный ИИ бесполезен, если кормить его мусором.

Подписаться на канал