Ежегодно 350 тысяч сотрудников Росатома создают примерно 1 200 000 обращений в поддержку. Значительная часть приходилось на систему для ведения бухгалтерского, налогового, регламентированного учета «1С: ERP 2.0 Цифровой Росатом». После внедрения ИИ-продукта «Атом.Зая» это количество сократилось на 24%. В этом тексте хочу рассказать, как мы двигались, чего удалось добиться, и какие уроки извлекли.

Как выглядела работа поддержки раньше

Росатом эксплуатирует несколько сотен информационных систем, как централизованных, так и локальных отраслевых. В рамках центра «1С Гринатом» мы разрабатываем и поддерживаем 28 систем. Среди них есть такие, в которых в одномоментно работает более 5 000 сотрудников, а также небольшие системы, в которых ежедневно работают около 100-150 человек. В качестве примера для этого текста мы взяли систему «1С: ERP 2.0 Цифровой Росатом».

Раньше в случае, когда требовалась консультация или обнаруживалась ошибка, пользователи обращались в техподдержку по электронной почте, телефону или через специальную систему работы с ИТ-инцидентами. По системе «1С: ERP 2.0 Цифровой Росатом» в день мы фиксировали от 400 до 700 обращений. Дальше они обрабатывались сотрудниками первой линии. Если первая линия не могла закрыть вопрос по действующим инструкциям, то обращение передавалось на вторую линию. Если и там не удавалось решить вопрос, то для ответа подключали третью линию поддержки и разработчиков. Эта классическая цепочка работы с ИТ-инцидентами.

Шаг 1: Создание обращений из системы

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

Создание обращений из системы упрощает как работу пользователей, так и работу поддержки. Пользователю не требуется открывать новую систему для формирования вопроса или набирать по телефону сотрудника call-центра. В обращении фиксируется автор, дополнительная контактная информация для уточнения деталей, ссылка на объект в системе, по которому задается вопрос, контекст предыдущих действий сотрудника.

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

Это позволило нам на 38% сократить время на распределение обращений между специализированными группами поддержки. Например, группа «НСИ» стала получать обращения только по справочникам, а группа «Казначейство» стала получать обращения только по цепочкам оплат.

Темы обращений и шаблоны под каждую тему

Итак, теперь наши пользователи формируют обращения из системы, но возникает сложность: что делать, когда по одному и тому же объекту консультации могут оказывать две группы. Например, в Договоре контрагента есть информация о планах оплат группы «Казначейство», а также об аналитиках отражения в учете группы «НСИ». Мы предложили пользователям выбирать тему обращений, по которой будем определять группу обработки обращений, и под каждую тему формировать шаблон. Шаблон обращения определяет поля, которые пользователь заполняет для уточнения всех деталей.

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

За счет внедрения тем и шаблонов мы сократили на 18% обращения к пользователям для уточнения шагов по воспроизведению ошибок

Связанная информация по теме или объекту метаданных

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

Это сократило на 6% обращения по однотипным вопросам.

Предложение о создании обращения в случае ошибки

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

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

За счет этого мы сократили на 11% ошибки, которые встречаются в системе.

Предопределенные тексты обращений

В платформе 1С заложены тексты ошибок по предопределенным событиям. Например, если объект был изменен другим пользователем, то платформа 1С выдает ошибку: «Данные были изменены или удалены другим пользователем».

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

Как выглядит ошибка в коробочном функционале:

А так выглядит ошибка с нашими доработками:

Так мы сократили на 4% обращения в систему.

Чат-бот с ответами на вопросы

Нам очень хотелось разгрузить поддержку, чтобы ответы на типовые вопросы по инструкциям давали не люди, а чат-бот. По системе «1С: ERP 2.0 Цифровой Росатом» у нас больше 500 пользовательских инструкций, памяток, описаний типовых процессов. Суммарный объем этих инструкций превышает 3000 страниц. Ни один пользователь в компании не прочитал все эти инструкции, но в них очень много полезной информации. И мы посчитали, если прочитать только самые важные, это позволит значительно сократить количество обращений.

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

Итак, чтобы решить задачу по созданию LLM, нам нужно было выполнить следующие шаги:

1. Собрать все инструкции воедино.

2. Реализовать автоматический парсер инструкций:

   1. убрать из инструкции лишнюю информацию (оглавление, кто редактировал документ, колонтитулы и т. д.);

   2. передать инструкции LLM-модели.

3. Загрузить все инструкции в модель.

4. Подготовить список 500 тестовых вопросов, ответы на которые есть в инструкции, чтобы оценить качество модели.

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

6. Поддержать возможность удаления инструкции (если логика работы системы меняется и информация устареет).

7. Реализовать возможность из системы задавать вопросы LLM-модели, и отображать ответ также внутри системы.

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

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

Когда модель была обучена, мы перешли к ее испытаниям. На тестовых примерах сеть демонстрировала возможность корректно отвечать на 65% поступающих вопросов. После этого мы перешли к опытной эксплуатации в ERP-системе. 30 апреля в продуктивной базе «Атом.Зая» начала отвечать на реальные вопросы пользователей. Теперь любое обращение пользователя в поддержку сначала проходит через «Атом.Заю», и если ответ пользователя удовлетворил, то обращение не направляется дальше, а считается решенным.

Нужно иметь в виду, что в реальной жизни процент вопросов пользователей, на которые можно ответить по инструкции, не более 50-60%. Ровно поэтому процент верных ответов на заранее подготовленные по инструкциям вопросы значительно выше, чем процент точности ответов на произвольные вопросы.

Создание «Атом.Заи» позволило снизить количество обращений в поддержку на 24%. Процент ответов, которые пользователи отметили как верные, составил 26%. Однако точность ответов зависит от опыта работы пользователей в системе. Чем больше у пользователя опыта работы в системе, тем его вопросы сложнее и детальнее, соответственно процент верных ответов модели падает. Модель очень хорошо закрывает обращения от неопытных пользователей, когда они задают базовые вопросы по системе.

Разбивка по точности ответов на вопросы в зависимости от опыта пользователя работы в системе:

• 2 года и более – 20%;

• 1,5 года – 21%;

• 1 год – 26%;

• 0,5 года – 31%;

• без опыта – 38%.

Усложнение логики работы чат-бота

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

И мы решили изменить поведение системы. Если за короткое время ответ не удовлетворил пользователя, то он сам может решить, готов ли подождать 2-3 минуты, чтобы система попыталась дать корректный ответ. Оказалось, что 70% пользователей на консультационные вопросы готовы подождать с автоматическим ответом.

При этом, если система думает над ответом не 15 секунд, а 2-3 минуты, точность ответов возрастает с 26% до 31%, то есть это позволило на 5% увеличить точность ответов.

Вывод и дальнейшие шаги

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

• позволить пользователям голосовать за полезные вопросы и ответы (среди часто задаваемых);

• автоматически классифицировать похожие вопросы в поддержку и направлять их одному исполнителю;

• искать похожие вопросы, на которые поддержка давала ответ ранее и отображать их пользователю;

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

Поделитесь, пожалуйста, а что вы делали, чтобы упростить работу поддержки?