ИИ на службе... на службе технической поддержки. История про то, как использование больших языковых моделей помогло оптимизировать работу службы технической поддержки крупного Холдинга. А также размышления про то, к чему это может привести в итоге.
Когда перед департаментом информационных технологий крупного отечественного Холдинга встала задача внедрения инструментов ИИ в бизнес-процессы Холдинга, то одним из перспективных направлений приложения усилий была выбрана оптимизация работы собственной службы технической поддержки с помощью больших языковых моделей.
Идея состояла в создании ИИ-сервиса поддержки, который будет помогать сервис-инженерам выполнять свою работу, а в перспективе частично выполнять эту работу вместо них.
ИТ-инфраструктура Холдинга включает в себя более 40 информационных систем на различных платформах, эксплуатируемых в 90 юридических лицах. Для централизации и унификации технической поддержки этого парка информационных систем в 2022 году была внедрена отдельная система на базе программного продукта 1С:ITIL. Ежемесячно через систему проходит около 30 тысяч обращений от 12 тысяч активных пользователей, которые обрабатываются 800 сервис-инженерами.
Одной из услуг, предоставляемых в рамках технической поддержки Холдинга, является услуга технической поддержки самого 1С:ITIL. Этой услугой пользуются сервис-инженеры, когда у них возникают вопросы по использованию 1С:ITIL. Именно с этой услуги и было принято решение начать построение ИИ-сервиса поддержки. Причины такого выбора – ограниченное количество бизнес-процессов, покрываемых информационной системой, а также небольшой состав команды сервис-инженеров. Это позволило быстро проверить начальные гипотезы и нарастить первичный объем практических компетенций. После получения приемлемого уровня результатов для 1С:ITIL, департамент информационных технологий приступил к масштабированию ИИ-сервиса поддержки на другие информационные системы Холдинга.
Архитектура ИИ-сервиса поддержки
Уровень пользователей. Для бизнес-пользователей работа ИИ-сервиса поддержки спрятана «под капотом». Они как формировали обращения по почте или из своего бизнес-приложения, так и продолжают это делать. У сервис-инженеров на различных этапах процесса технической поддержки пользователей появились новые команды, вызывающие того или иного ИИ-агента.
Уровень Service Desk. Среда, в которой сервис-инженеры инициируют обращения к языковым моделям и в которой обрабатывают полученные ответы. Основное назначение в архитектуре – обеспечить интерфейс взаимодействия с языковыми моделями непосредственно из привычного рабочего места сервис-инженеров.
Уровень LLM GUI. Среда, в которой выполняются основные настройки ИИ-сервиса поддержки и в которой запускаются ИИ-агенты. Основное назначение в архитектуре – минимизировать хард-кодинг на Python, воспользовавшись готовой оснасткой управления языковыми моделями.
Уровень LLM Server. Среда, в которой выполняется непосредственное взаимодействие с языковыми моделями. Основное назначение в архитектуре – запустить языковые модели на графических процессорах, предоставить к ним программный доступ через API и сбалансировать нагрузку между графическими процессорами.
Уровень векторной СУБД. Среда, в которой выполняется управление векторными базами знаний. Основное назначение в архитектуре – формировать и хранить векторные базы знаний.
Уровень инструментария OCR. Среда, в которой выполняется оптическое распознавание текста. Основное назначение в архитектуре – трансформировать сложные скриншоты из бизнес-приложений в текст.
Для реализации этой архитектуры был использован Kubernetes-кластер, включающий в себя графические процессоры NVIDIA A100 и NVIDIA H200. Ресурс кластера, выделенный под языковые модели, входящие в ядро ИИ-сервиса поддержки, составил около 1.3 TB VRAM. Для тестирования других языковых моделей в рамках развития ИИ-сервиса поддержки задействуются дополнительные ресурсы кластера.
Llama 4 Maverick развернута на 8 NVIDIA H200 с форматом хранения весов FP16 и длиной контекста 750K. Gemma 3 развернута на 2 NVIDIA A100 с форматом хранения весов FP16 и длиной контекста 128K. Использование тензорного параллелизма при разворачивании языковых моделей с помощью vLLM позволило распределить их между графическими процессорами, увеличить пропускную способность и в результате сократить время получения ответов.
ИИ-агенты
Давайте разберемся, что понимается под сущностью ИИ-агента в контексте ИИ-сервиса поддержки. Это чат-бот языковой модели, у которого есть API и есть предопределенные настройки. В качестве предопределенных настроек могут выступать:
текст системного промта
ссылка на размещение векторной базы знаний
настройки температуры или длины контекста, отличные от значений по умолчанию
и др.
Таким образом, базовый чат-бот, который появляется в Open WebUI при запуске локально размещенной языковой модели или при подключении к языковой модели в облаке – это тоже ИИ-агент, просто без предопределенных настроек.
Оркестрация ИИ-агентов в рамках ИИ-сервиса поддержки выполняется сервис-инженером вручную в зависимости от решаемой задачи.
Сложносочиненный промт
Когда мы общаемся с большими языковыми моделями с помощью встроенных чат-ботов, мы воспринимаем каждое сообщение, которое мы отправляем в языковую модель как единое целое. В архитектуре ИИ-сервиса поддержки запрос, который в конечном итоге подается на вход в языковую модель, является составным. Одну часть информации формирует сервис-инженер, другая часть информации предопределена ИИ-агентом.
Роль. Мы субъективируем языковую модель, давая ей понять от лица кого она будет отвечать. Например, сообщаем, что ответ должен быть дан с позиции консультанта 1-й линии поддержки или с позиции технического архитектора.
Навык. Мы определяем действие и ожидаемый результат, конкретизируя для языковой модели, что именно она должна сделать и каким образом. Например, сообщаем, что нужно найти ответ или придумать формулировку задачи для разработчика, при этом быть дружелюбной и избегать расплывчатых формулировок.
Контекст. Мы описываем ситуацию, в которой должна представить себя языковая модель. Например, сообщаем, что возникла хозяйственная операция, которую нужно отразить в конкретной системе, или возникла потребность разработать новый отчет.
Знания. Мы передаем набор информации, учитывая который языковая модель будет давать ответ. Например, сообщаем текст конкретной инструкции или регламента проектирования отчетов.
Связь между навыком и ИИ-агентом определяется настройкой ИИ-сервиса поддержки.
Не все навыки требуют использования RAG. Следовательно, в этом случае запрос не обогащается «знаниями» и используется языковая модель в чистом виде.
Локальное использование языковых моделей
Open WebUI позволяет гибко выстраивать взаимодействие с большими языковыми моделями. Можно подключаться к языковым моделям, расположенным в облаках, а можно к языковым моделям, размещенным локально. Для построения ИИ-сервиса поддержки был выбран второй вариант – языковые модели, развернутые локально на ИТ-инфраструктуре Холдинга. Это сделано по следующим причинам:
Конфиденциальность. Инструкции, регламенты, скриншоты информационных систем, параметры учетных записей и сеансов подключения – все это является чувствительной информацией с точки зрения информационной безопасности, и, следовательно, должно передаваться исключительно внутри ИТ-инфраструктуры Холдинга.
Автономность. В качестве ядра ИИ-сервиса поддержки были выбраны зарубежные языковые модели, а при текущей геополитической обстановке всегда существует значительный риск столкнуться с внезапными ограничениями доступа к облачным сервисам, сервера которых находятся за пределами РФ.
Наличие этих двух причин предопределило вариант локального использования языковых моделей, хотя с финансовой точки зрения вариант интеграции с облачными сервисами и оплаты за токены выглядел предпочтительнее.
Языковых моделей много не бывает
ИИ-сервис поддержки представляет собой набор ИИ-навыков:
Поиск ответа. Ключевой навык ИИ-сервиса поддержки. Применяется для подготовки ответа на вопрос бизнес-пользователя или решения проблемы, обозначенной бизнес-пользователем.
Улучшение ответа. Применяется для доведения ответа, написанного сервис-инженером самостоятельно в виде тезисов, до финального вида с корректным стилем изложения, ссылками на инструкции и т.п.
Формирование постановки. Применяется для подготовки технической постановки на доработку сопровождаемой системы.
Улучшение постановки. Применяется для доведения постановки, написанной сервис-инженером самостоятельно в виде тезисов, до финального вида с дизайном баз данных, сценариями тестирования и т.п.
Формирование темы. Применяется для унификации тем обращений бизнес-пользователей.
Исправление опечаток. Применяется для поддержания грамматического уровня ответов.
Формирование эффекта от внедрения. Применяется для подготовки обоснования доработки сопровождаемой системы.
Практика показала, что с какими-то задачами лучше справляется Llama 4 Maverick, с какими-то Gemma 3. Таким образом, можно сделать вывод, что длинный контекст и большое количество параметров – это не всегда преимущество. Для некоторых задач формальный «сухой» ответ, с выкрученным в ноль параметром «температуры», подходит лучше, чем глубокие «размышления» языковой модели.
Ядро архитектуры ИИ-сервиса поддержки в виде набора больших языковых моделей не статично. Более того, к текущему набору языковых моделей пришли не сразу, а путем перебора. При появлении новых языковых моделей, которые видятся перспективными, с точки зрения развития ИИ-сервиса поддержки, на них тестируются существующие ИИ-навыки. Главное, чтобы эти языковые модели можно было развернуть локально, в принципе (например, языковые модели из линейки Chat GPT невозможно развернуть локально) или с учетом технических ограничений (например, языковая модель DeepSeek V3 требует увеличения мощности текущего стенда в три раза). В текущий момент, в рамках развития ИИ-сервиса поддержки, ИИ-навыки тестируются на языковых моделях Qwen 3.5 и Gemma 4.
Лет ми спик фром май харт
Большинство современных больших языковых моделей, у которых параметры исчисляются десятками и сотнями миллиардов, мультиязычны. И поддержка литературного русского языка, достаточная для работы ИИ-сервиса поддержки, в них изначально находится на достойном уровне. Без дополнительного дообучения. Даже несмотря на маленькую долю русскоязычных данных, использованных при обучении языковых моделей. Даже несмотря на флективность русского языка, пожирающую лишние токены в контекстном окне (ох уж эти приставки, суффиксы и окончания).
Мы воспринимаем эту ситуацию как данность. Все-таки десятилетия использования корпоративного программного обеспечения, локализованного под русский язык, не прошли даром. Хотя локализовать интерфейс программного обеспечения под конкретный язык и обучить языковую модель на конкретном языке – это две большие разницы.
Такая ситуация позволяет использовать максимально широкий круг языковых моделей для построения ядра ИИ-сервиса поддержки и не ограничиваться только лишь отечественными языковыми моделями (GigaChat, Яндекс GPT и др.) или дообученными языковыми моделями иностранных вендеров (Vikhr, Saiga и др.).
RAG
Основным наполнением векторных баз данных ИИ-сервиса поддержки являются пользовательские инструкции. Эти инструкции создавались в свое время без оглядки на будущее использование в ИИ-сервисе поддержки. Поэтому для получения наилучших результатов инструкции пришлось подготовить для их использования в RAG:
Инструкции по сквозным бизнес-процессам были «нарезаны» по объектам системы
Размер чанка был настроен, чтобы полностью покрывать «нарезанные» инструкции
В инструкциях была актуализирована семантическая разметка: заголовки, маркированные и нумерованные списки, подписи к скриншотам и т.п.
Из инструкций был удален неинформативный «мусор»: колонтитулы, номера страниц и т.п.
Инструкции были обогащены синонимами используемых в них терминов
Инструкции были обогащены метатегами: объекты системы, роли пользователя и т.п.
Дообучение языковых моделей
А зачем было использовать RAG на основе векторных баз? Не проще ли было дообучать языковые модели?
Давайте сначала посчитаем «экономику» на обучение языковых моделей:
Постоянные затраты:
Стенд с графическими процессорами для обучения языковых моделей (мощность стенда для обучения должна быть в несколько раз выше, чем мощность стенда для инференса)
Переменные затраты:
Фонд оплаты труда специалистов, участвующих в обучении языковых моделей (программисты, аналитики данных и т.д.)
Электроэнергия (большие языковые модели требуют много электроэнергии на обучение)
Теперь учтем, что у нас не одна языковая модель, а парк языковых моделей, с возможностью его расширения. И каждую языковую модель нужно дообучать.
И учтем, что контекст используемых баз знаний не статичен. Среди сопровождаемых систем Холдинга, есть системы с высокой частотой обновления. Причем, высокая частота обновлений зачастую диктуется извне. Например, из-за изменения законодательной базы в сфере бухгалтерского, налогового или кадрового учета. Высокая частота обновлений систем влечет сопоставимую частоту обновления инструкций в базах знаний. Что в свою очередь приводит к потребности в постоянном дообучении языковых моделей.
Из всего этого можно сделать вывод, что заниматься дообучением языковых моделей только для целей обеспечения функционирования ИИ-сервиса поддержки экономически нецелесообразно. Гораздо выгоднее поддерживать в актуальном состоянии векторные базы знаний. Хотя и этот процесс требует определенного уровня затрат, если мы, конечно, не хотим постепенной деградации ИИ-сервиса поддержки.
Нет, ну все-таки…
Внимательный читатель спросит: «С FFT все понятно. А как же LoRA?». Действительно, метод частичного дообучения (Low-Rank Adaptation) позволяет существенно снизить затраты на дообучение языковых моделей (за счет низких требований к инфраструктуре и сокращения времени на дообучение) по сравнению с методом полного дообучения (Full Fine-Tuning). Но из-за фактора высокой частоты обновления «знаний» по сопровождаемым системам RAG выглядит предпочтительнее LoRA. Обновление векторных баз знаний актуальными инструкциями проходит на порядок быстрее, чем подготовка датасетов для дообучения на базе этих же инструкций.
Модель взаимодействия пользователя с ИИ-сервисом поддержки
Когда мы говорим об ИИ-сервисах поддержки, то первой на ум приходит модель прямого взаимодействия пользователей с ИИ-сервисом. Такая модель взаимодействия является целевой, т.к. ради этого ИИ-сервисы поддержки и внедряются, чтобы снизить затраты на промежуточное звено в цепочке «пользователь → сервис-инженер → база знаний».
Но текущий уровень развития ИИ-сервисов поддержки пока не позволяет сделать работу ИИ-сервиса неотличимой от работы сервис-инженера. При возникновении задач с уровнем сложности выше базового, это начинает вызывать негативную реакцию пользователей, т.к. пользователь начинает впустую тратить свой самый ценный ресурс – время.
Каждый из нас сталкивался с моделью прямого взаимодействия пользователей с ИИ-сервисом поддержки, когда, будучи в роли клиента, обращался в службы поддержки банков или операторов сотовой связи. Думаю, многие в процессе такого общения писали/произносили заветную фразу «переключите на оператора».
При внедрении ИИ-сервиса поддержки в Холдинге была выбрана модель косвенного взаимодействия пользователя с ИИ-сервисом. С ИИ-сервисом контактируют только сервис-инженеры, а пользователи даже не догадываются, что результат обращения за технической поддержкой получен с помощью ИИ-сервиса. Это позволяет снизить уровень негатива со стороны пользователей.
Результаты
Спустя год использования ИИ-сервиса поддержки имеет смысл оценить промежуточные результаты. Поставленная задача «внедрить инструменты ИИ в бизнес-процессы Холдинга» решена. Да, степень удовлетворенности разными ИИ-навыками отличается. Да, RAG не является панацей от ИИ-галлюцинаций. Но в целом инструмент работоспособный. Принято решение продолжать работать над ИИ-сервисом поддержки, повышать качество ответов и масштабировать его, добавляя новые ИИ-навыки и новые векторные базы знаний, чтобы полностью покрыть новым инструментом информационные системы Холдинга.
Для полноты картины, осталось посмотреть на «экономику» вопроса. До определенного момента Холдинг инвестировал, т.е. тратил деньги. А в какой момент Холдинг начнет деньги зарабатывать или хотя бы их экономить?
Зарабатывать на ИИ-сервисе поддержки в теории возможно. Например, продавая проекты внедрения подобных сервисов под ключ за пределами Холдинга. Но это не является целевым видом деятельности департамента информационных технологий Холдинга. Поэтому логичнее сконцентрироваться на экономии затрат. Самой логичной статьей расходов для сокращения является фонд оплаты труда сервис-инженеров.
После внедрения ИИ-сервиса поддержки на пилотных системах, удалось сократить штат сервис-инженеров на несколько процентов. В первом приближении это не самые выдающиеся цифры. Но, с другой стороны, в последние годы в Холдинге наблюдался постоянный рост штата сервис-инженеров из-за роста объема задач. Для пилотных систем, в отличие от систем, еще не покрытых ИИ-сервисом поддержки, удалось остановить этот рост численности сервис-инженеров. Что уже можно интерпретировать как экономически значимый результат.
Перспективы
На этом месте можно было поставить точку. Но давайте попробуем смоделировать, что нас ждет впереди. Сегодня мы внедрили ИИ-сервис поддержки. Завтра внедрим ИИ-сервис написания кода. Послезавтра внедрим ИИ-сервис функционального тестирования. Если текущая тенденция сохранится, то с высокой долей вероятности мы придем в точку, когда останется потребность только в тим-лидах, у которых «тим» будет состоять не из людей, а из ИИ-агентов.
И в этом месте возникает интересный вопрос. С одной стороны, создается ситуация, когда потребность в ИТ-специалистах уровня «джун» и «мидл» сокращается, т.к. часть их задач начинают выполнять ИИ-агенты. И в первом приближении это идеально накладывается на демографическую яму в возрастной пирамиде в диапазоне «от 15 до 30» на которую приходится большая часть ИТ-специалистов уровня «джун» и «мидл», которые являются таковыми сегодня или станут таковыми завтра.
С другой стороны, тим-лиды из вакуума не появляются. Каждый тим-лид с той или иной скоростью прошел всю цепочку «джун», «мидл», «сеньор». И каким образом проходить этот путь, когда объем задач для ИТ-специалистов уровня «джун» и «мидл» сокращается? За счет чего наращивать компетенции? Одними pet-проектами сыт не будешь. И если вернуться к возрастной пирамиде, то указанная выше демографическая яма – это на самом деле головная боль для HR и менеджеров по развитию ИТ-направлений. Все хотят не просто новых работников, все хотят лучших работников. Ради этого бизнес готовы идти в вузы и даже в школы: организовывать ИТ-кружки, летние ИТ-лагеря и стажировки, чтобы заманить к себе перспективных молодых работников. И если в прежние времена задач для начинающих ИТ-специалистов было очень много, то с внедрением новых инструментов ИИ объем этих задач будет сокращаться.
В такой ситуации разумной стратегией видится не впадать в крайности и пытаться удерживать баланс:
Продлевать «опытное» окно внедрения ИИ-агентов, чтобы максимально точно оценить возможность замещения работников, а также затраты на поддержку самих ИИ-агентов (например, векторные базы знаний сами себя не актуализируют).
Не сокращать персонал на опережение, чтобы потом не заниматься обратным наемом, столкнувшись с внезапной деградацией новых версий ИИ.
Поощрять кросс-функциональность работников уровня «джун» и «мидл», чтобы повысить качество кадрового резерва и максимально сгладить ситуации, когда тим-лид вдруг ушел из компании, а за его спиной никого не осталось.
Возвращаясь к вопросу, что нас ожидает в ситуации, когда в карьерной цепочке между начинающим ИТ-специалистом и тим-лидом образуется «пустота». Ведь тут вопрос не только в постепенном наращивании компетенций работником до того момента, когда он будет способен выполнять роль тим-лида. Но и в оплате труда работника все это время.
С высокой долей вероятности ИТ-индустрия пойдет по тому же пути, что и другие отрасли. Например, медицина или юриспруденция. Где с одной стороны имеет место длительное наращивание компетенций через практику, а с другой стороны резкий скачок в доходах при достижении определенного уровня компетенций, который отчасти компенсируют не самый высокий уровень оплаты труда в процессе наращивания компетенций.