ПРИМЕНЕНИЕ МАШИННОГО ОБУЧЕНИЯ В СИСТЕМНОМ АНАЛИЗЕ ДЛЯ ОПТИМИЗАЦИИ ПРОЦЕССОВ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ

ВВЕДЕНИЕ

Цифровая трансформация предприятий и повсеместное внедрение информационных систем привели к экспоненциальному росту объема запросов в службы технической поддержки. Согласно исследованию Gartner, средняя крупная организация обрабатывает от 50 000 до 100 000 инцидентов ежегодно, при этом до 40% времени сотрудников технической поддержки тратится на рутинные операции триажа и классификации [1, С. 15]. Ручной триаж входящих обращений часто приводит к человеческим ошибкам, неоптимальному назначению приоритета и, как следствие, к превышению установленных соглашениями об уровне обслуживания (SLA) показателей MTTR (Mean Time To Resolution) и AHT (Average Handle Time) [2, С. 87-89].

Традиционные подходы к управлению инцидентами, основанные на фреймворках ITIL (Information Technology Infrastructure Library) и ITSM (IT Service Management), предполагают значительное участие человека на всех этапах обработки запроса [3, С. 124]. Однако по мере роста сложности IT-инфраструктуры и увеличения числа пользователей, данный подход демонстрирует ограничения в масштабируемости и эффективности. Проблема усугубляется нелинейным характером рабочих процессов поддержки, где время обработки может значительно варьироваться в зависимости от типа инцидента, уровня квалификации специалиста и текущей загрузки системы [4, С. 201-203].

Интеграция систем на основе искусственного интеллекта (AI) и машинного обучения (МО) стала перспективным решением для устранения этих узких мест. Современные модели глубокого обучения, особенно трансформерные архитектуры класса BERT (Bidirectional Encoder Representations from Transformers), продемонстрировали впечатляющие результаты в задачах обработки естественного языка (NLP), включая классификацию текстов и извлечение смысловых признаков [5, С. 4172-4186]. Применение таких моделей для автоматического анализа текстовых описаний инцидентов позволяет значительно ускорить процесс первичной обработки и повысить точность классификации [6].

В то же время, разработка систем с AI-компонентами представляет значительные вызовы для традиционных практик системного анализа (СА), требующих верифицируемости и предсказуемости поведения [7, С. 1-12]. Недетерминированное поведение моделей МО, их «непрозрачность» (проблема черного ящика) и сложность интеграции в непрерывные производственные процессы требуют пересмотра классической методологии СА [8, С. 45-48]. В частности, исследования показывают, что только около 13-22% проектов МО достигают стадии производственного развертывания, что подчеркивает значительные операционные сложности и разрыв между исследовательскими прототипами и промышленными решениями [9].

Методология MLOps (Machine Learning Operations) появилась как ответ на эти вызовы, предлагая структурированный подход к жизненному циклу ML-моделей, включающий непрерывную интеграцию, развертывание, мониторинг и переобучение [10, С. 3468-3476]. Однако интеграция MLOps-практик в контекст технической поддержки требует дополнительного исследования, особенно в части оценки системного влияния AI-компонентов на бизнес-метрики и операционную эффективность.

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

Цель исследования – разработка архитектурного и методологического фреймворка, основанного на принципах системного анализа и MLOps, для интеграции моделей машинного обучения в процессы технической поддержки с целью оптимизации ключевых показателей эффективности, таких как MTTR, AHT, и времени первого отклика (FRT).

Задачи исследования:

1. Провести анализ современных подходов к применению машинного обучения в системах технической поддержки и выявить основные ограничения существующих решений.
   
2. Разработать архитектуру интегрированного фреймворка, объединяющего NLP-модели, MLOps-практики и методы имитационного моделирования.
   
3. Предложить методологию оценки системного эффекта от внедрения ML-компонентов на основе теории массового обслуживания.
   
4. Провести верификацию предложенного подхода с использованием синтетических и реальных данных.
   

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

МАТЕРИАЛЫ И МЕТОДЫ

Предложенный подход носит междисциплинарный характер, сочетая: 1) методы глубокого обучения для обработки естественного языка (NLP); 2) принципы системного инжиниринга и MLOps для операционализации моделей; 3) имитационное моделирование на основе теории массового обслуживания (ТМО) для оценки системной производительности.

Роль системного анализа и MLOps

Системный анализ в контексте разработки AI-систем выполняет ключевую роль в определении не только функциональных, но и, что более важно, нефункциональных требований к системе [7, С. 5-7]. Традиционный СА фокусируется на верифицируемости и предсказуемости поведения детерминированных алгоритмов, однако модели МО демонстрируют стохастическое поведение, зависящее от данных обучения, гиперпараметров и даже случайной инициализации весов [11, С. 234-237].

Для обеспечения надежного развертывания и непрерывной эксплуатации моделей используется методология MLOps (Machine Learning Operations). MLOps представляет собой набор практик, интегрирующих рабочие процессы МО с принципами DevOps, обеспечивая автоматизированное тестирование, контроль версий моделей и данных, непрерывный мониторинг производительности [10, С. 3470-3472]. Ключевые компоненты MLOps включают:

Управление данными: версионирование датасетов, отслеживание происхождения данных (data lineage), обеспечение качества и репрезентативности обучающих выборок [12, С. 156-159].

Управление моделями: версионирование моделей, эксперименты с гиперпараметрами, регистр моделей (model registry), управление метаданными экспериментов [10, С. 3473].

Развертывание: автоматизированные пайплайны CI/CD для ML, стратегии развертывания (blue-green deployment, canary release, A/B тестирование) [13].

Мониторинг: отслеживание производительности модели в реальном времени, обнаружение смещения данных (data drift) и концептуального смещения (concept drift), алертинг при деградации точности [14, С. 89-92].

Архитектура MLOps v2, предложенная ведущими облачными провайдерами, явно выделяет фазы разработки (development), тестирования (staging), продакшена (production) и мониторинга, что критически важно для интеграции AI в корпоративную IT-инфраструктуру [13].

Модели машинного обучения

Для анализа и прогнозирования проблем поддержки используются следующие классы моделей:

NLP-модели для классификации и приоритизации

Использование трансформерных моделей, например, класса BERT, для автоматического присвоения категории, продукта и уровня критичности (Severity) на основе заголовков и описаний обращений [5, С. 4174-4176]. BERT (Bidirectional Encoder Representations from Transformers) представляет собой предобученную языковую модель, которая использует механизм двунаправленного внимания (bidirectional attention) для кодирования контекстных представлений слов [5, С. 4173].

Специализированные модели, такие как Ticket-BERT, были разработаны специально для задач классификации инцидентов в системах ITSM [6]. Эти модели дообучаются (fine-tuning) на корпусе текстов технической поддержки, что позволяет им эффективно распознавать технические термины, аббревиатуры и специфическую лексику IT-домена.

Помимо BERT, исследуются и другие архитектуры:

• RoBERTa (Robustly Optimized BERT Pretraining Approach) – улучшенная версия BERT с модифицированным процессом предобучения [15, С. 1-13].
  
• DistilBERT – облегченная версия BERT, сохраняющая 97% точности при 40% ускорении и 60% меньшем размере модели [16].
  
• Большие языковые модели (LLM) класса GPT для генерации рекомендаций по решению инцидентов и автоматического формирования ответов [17, С. 234-239].
  

Процесс применения NLP-моделей для классификации инцидентов включает следующие этапы:

1. Предобработка текста: токенизация, нормализация, удаление стоп-слов, лемматизация.
   
2. Кодирование: преобразование текста в векторные представления с использованием предобученной модели BERT.
   
3. Классификация: применение полносвязных слоев (dense layers) поверх BERT-представлений для предсказания категории и приоритета.
   
4. Постобработка: калибровка вероятностей, применение бизнес-правил для финальной классификации.
   

Такой подход позволяет снизить задержку, вызванную ручным триажем, и обеспечить быстрый первый отклик (FRT), который является критическим показателем удовлетворенности пользователей [2, С. 91-93].

Регрессионные модели для прогнозирования KPI

Применение машинного обучения для прогнозирования MTTR и AHT на основе исторических данных (текст обращения, предыдущие решения, метрики пользователя и технического специалиста) [18, С. 1456-1459]. Для этих задач применяются следующие классы моделей:

• Градиентный бустинг (XGBoost, LightGBM, CatBoost) – эффективные алгоритмы для работы с табличными данными, включающими как числовые признаки (время суток, загрузка системы, исторические метрики пользователя), так и категориальные (тип инцидента, продукт, приоритет) [19, С. 785-794].
  
• Случайный лес (Random Forest) – ансамблевый метод, обеспечивающий хорошую обобщающую способность и устойчивость к переобучению [20, С. 5-32].
  
• Нейронные сети прямого распространения (Feed-forward Neural Networks) – для моделирования сложных нелинейных зависимостей между признаками [21, С. 234-237].
  

Важным аспектом является инжиниринг признаков (feature engineering), включающий:

• Текстовые признаки: TF-IDF представления, эмбеддинги из BERT, длина текста, наличие специфических ключевых слов.
  
• Временные признаки: час суток, день недели, сезонность.
  
• Исторические признаки: среднее время решения аналогичных инцидентов, загрузка назначенного специалиста, история взаимодействий пользователя.
  
• Контекстные признаки: текущая загрузка системы, количество открытых инцидентов, доступность специалистов.
  

Модели прогнозирования MTTR и AHT позволяют менеджерам поддержки прогнозировать всплески инцидентов и принимать упреждающие меры, такие как перераспределение ресурсов или привлечение дополнительного персонала [18, С. 1460-1462].

Имитационное моделирование

Для оценки влияния внедрения AI на сквозную производительность системы используется имитационное моделирование на основе теории массового обслуживания (ТМО) [22, С. 145-148]. Процессы технической поддержки представляют собой систему массового обслуживания (СМО), где заявки (инциденты) поступают в систему с определенной интенсивностью, ставятся в очередь и обслуживаются ограниченным числом операторов (серверов).

Поскольку процессы поддержки являются нелинейными и стохастическими, традиционные аналитические модели ТМО (например, M/M/c – модель Марковской системы с пуассоновским входным потоком, экспоненциальным временем обслуживания и c серверами) часто не масштабируются для реальных сложных систем [23, С. 1089-1094]. Реальные системы характеризуются:

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

Используется гибридный подход: прогнозы, полученные от МО-моделей (например, прогнозируемое время обслуживания, скорректированный приоритет), используются в качестве входных параметров для симуляционной модели массового обслуживания [22, С. 149-151]. Симуляция реализуется с использованием дискретно-событийного моделирования (Discrete Event Simulation, DES), где состояние системы изменяется только в моменты наступления определенных событий (прибытие заявки, начало обслуживания, завершение обслуживания).

Основные компоненты симуляционной модели:

Генератор заявок: моделирует поступление инцидентов с использованием неоднородного пуассоновского процесса или на основе реальных исторических данных.

Модуль классификации: использует обученную ML-модель для назначения категории и приоритета каждой заявке, определяя время обслуживания на основе предсказаний регрессионной модели.

Очередь: реализует приоритетную очередь (priority queue), где заявки упорядочиваются по приоритету и времени поступления.

Пул серверов: моделирует операторов технической поддержки с учетом их специализации, квалификации и загрузки.

Модуль мониторинга: собирает статистику по ключевым метрикам (FRT, MTTR, AHT, длина очереди, коэффициент загрузки операторов, вероятность нарушения SLA).

Это позволяет проводить сценарный анализ «что, если» (what-if analysis) для оценки таких метрик, как вероятность нарушения SLA, изменение длины очереди и требуемое количество операторов при различных стратегиях триажа и приоритизации [24, С. 45-48].

Методология верификации

Для верификации предложенного фреймворка применяется многоуровневая методология:

Уровень 1: Оценка точности ML-моделей

• Классификационные метрики: accuracy, precision, recall, F1-score для моделей классификации инцидентов.
  
• Регрессионные метрики: MAE (Mean Absolute Error), RMSE (Root Mean Square Error), MAPE (Mean Absolute Percentage Error) для моделей прогнозирования MTTR и AHT.
  
• Кросс-валидация: k-fold cross-validation для оценки обобщающей способности моделей.
  

Уровень 2: Оценка системного эффекта через симуляцию

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

Уровень 3: Пилотное развертывание (если применимо)

• A/B тестирование: сравнение производительности с ML и без ML на реальных потоках инцидентов.
  
• Мониторинг в реальном времени: отслеживание метрик качества и операционных показателей.
  
• Обратная связь от пользователей: оценка удовлетворенности пользователей и операторов.
  

РЕЗУЛЬТАТЫ: АРХИТЕКТУРНЫЙ ИНТЕГРАЦИОННЫЙ ФРЕЙМВОРК

Предлагается трехкомпонентный MLOps-ориентированный фреймворк для оптимизации процессов технической поддержки (см. рис. 1). Каждый компонент выполняет специфические функции, обеспечивая при этом тесную интеграцию и обмен данными.

Рисунок 1 – Трехкомпонентный фреймворк интеграции ML и СА в процессах технической поддержки

Примечание: Рисунок демонстрирует архитектуру фреймворка с тремя основными компонентами и потоками данных между ними. Компонент 1 обеспечивает автоматизированную обработку входящих обращений, Компонент 2 управляет жизненным циклом ML-моделей через MLOps-практики, Компонент 3 проводит симуляционную оценку системных эффектов.

Компонент 1. Автоматизированный входной контроль (Triage Automation Layer)

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

Классификация: назначение категории (например, «Сетевые проблемы», «Ошибки ПО», «Доступ и права», «Аппаратные сбои») и продукта (конкретное приложение или сервис) [6]. Модель анализирует заголовок и описание инцидента, извлекая семантические признаки и сопоставляя их с известными паттернами.

Приоритизация: определение уровня критичности (Severity: Critical, High, Medium, Low) на основе текстового содержания, исторических данных и бизнес-правил [2, С. 94-96]. Например, упоминание слов «не работает», «критично», «производственная среда» может автоматически повысить приоритет.

Прогнозирование: регрессионная модель прогнозирует ожидаемый MTTR и AHT для данного обращения на основе исторических данных о решении аналогичных инцидентов [18, С. 1461]. Прогноз учитывает не только характеристики самого инцидента, но и контекстные факторы: текущую загрузку системы, доступность специалистов, время суток.

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

Результаты прогнозирования (категория, критичность, прогнозируемое время решения) используются системой поддержки (например, ServiceNow, Jira Service Management) для мгновенного автоматического назначения, минуя первый уровень ручного анализа. Это обеспечивает значительное сокращение FRT с типичных 15-30 минут до менее чем 1 минуты [2, С. 98].

Компонент 2. Ядро системной динамики (System Dynamics Core)

Этот компонент включает интеграцию МО-моделей в полноценный конвейер MLOps, обеспечивая надежность и управляемость AI-системы на протяжении всего жизненного цикла.

CI/CD и версионирование

Обеспечение непрерывной интеграции и развертывания (CI/CD) моделей, их версионирование и автоматизированное тестирование перед выпуском в продакшен [10, С. 3474-3475]. Конвейер включает:

• Автоматическое переобучение моделей при появлении новых данных или снижении точности.
  
• Версионирование моделей с использованием инструментов типа MLflow, DVC (Data Version Control).
  
• Автоматизированное тестирование: unit-тесты для компонентов обработки данных, интеграционные тесты для проверки взаимодействия с внешними системами, A/B тесты для сравнения версий моделей.
  
• Регистр моделей (model registry) для управления артефактами моделей, метаданными и зависимостями.
  

Развертывание и мониторинг

Модель разворачивается с использованием современных паттернов развертывания:

• Parallel Deployment (Blue-Green): одновременное существование двух идентичных продакшен-сред (синяя и зеленая), что позволяет мгновенно переключаться между версиями при обнаружении проблем [13].
  
• Canary Release: постепенное перенаправление трафика на новую версию модели, начиная с небольшого процента запросов, с постоянным мониторингом метрик качества [13].
  
• Shadow Deployment: параллельный запуск новой версии модели без влияния на продакшен, только для сбора метрик и сравнения с текущей версией.
  

Критически важен непрерывный мониторинг:

• Data Drift Detection: отслеживание изменений в распределении входных данных, что может указывать на изменение паттернов инцидентов или появление новых типов проблем [14, С. 90-91]. Используются статистические тесты (Kolmogorov-Smirnov, Chi-square) и метрики расхождения распределений (KL-divergence, Wasserstein distance).
  
• Model Performance Monitoring: непрерывное отслеживание метрик точности (accuracy, F1-score для классификации; MAE, RMSE для регрессии) в реальном времени.
  
• System Performance Monitoring: отслеживание латентности предсказаний, пропускной способности, использования ресурсов (CPU, память, GPU).
  
• Alerting: автоматическое оповещение при обнаружении деградации точности, аномальных паттернов или превышении пороговых значений метрик.
  

Управление обратной связью

Сбор обратной связи от операторов и пользователей для непрерывного улучшения моделей:

• Операторы могут корректировать автоматическую классификацию, эти исправления фиксируются и используются для дообучения.
  
• Анализ случаев, когда автоматическая классификация была неверной, для выявления слабых мест модели.
  
• Периодический ретроспективный анализ (retrospective analysis) для оценки долгосрочного влияния ML-системы на операционные метрики.
  

Компонент 3. Симуляция и оценка производительности (Simulation & Evaluation Layer)

На этом уровне прогнозы MTTR и классификация, полученные от Компонента 1, подаются в симуляционную модель для оценки системного эффекта [22, С. 150-152].

Входные параметры симуляции:

• Скорость поступления обращений: моделируется на основе исторических данных с учетом суточной, недельной и сезонной периодичности.
  
• Прогнозируемое время обслуживания: используются предсказания регрессионной модели для каждого инцидента.
  
• Количество и квалификация агентов: моделируется пул операторов с различной специализацией и производительностью.
  
• Политики приоритизации: базовая (FIFO – First In First Out), приоритетная (на основе ML-классификации), динамическая (адаптивная приоритизация на основе текущего состояния системы).
  

Выходные параметры и метрики:

• First Response Time (FRT): среднее время от поступления инцидента до первого контакта с оператором или автоматического уведомления пользователя.
  
• Mean Time to Resolution (MTTR): среднее время полного решения инцидента.
  
• Average Handle Time (AHT): среднее время активной работы оператора с инцидентом (без учета времени ожидания в очереди).
  
• Queue Length: средняя и максимальная длина очереди ожидающих обработки инцидентов.
  
• Utilization: коэффициент загрузки операторов (отношение времени активного обслуживания к общему рабочему времени).
  
• SLA Compliance: процент инцидентов, решенных в рамках установленных SLA.
  
• First Contact Resolution (FCR): процент инцидентов, решенных при первом контакте без эскалации.
  

Сценарный анализ:

Симуляция позволяет проводить what-if анализ для различных сценариев:

• Сценарий 1 (Baseline): ручной триаж, без ML-оптимизации.
  
• Сценарий 2 (ML-Triage): автоматическая классификация и приоритизация с использованием ML.
  
• Сценарий 3 (ML-Triage + Прогнозирование): дополнительное использование прогнозов MTTR для динамического перераспределения ресурсов.
  
• Сценарий 4 (Полная автоматизация): включение автоматических решений для типовых инцидентов (self-healing).
  

Для каждого сценария проводится серия симуляционных прогонов (обычно 100-1000 итераций) для получения статистически значимых оценок метрик с доверительными интервалами.

Оптимизация ресурсов:

Симуляция также используется для решения задач оптимизации:

• Определение оптимального количества операторов для достижения целевых SLA при минимальных затратах.
  
• Оптимизация распределения специалистов по сменам с учетом прогнозируемой нагрузки.
  
• Выбор оптимальных порогов приоритизации для балансировки между скоростью обработки критичных и массовых инцидентов.
  

Интеграция компонентов

Три компонента фреймворка тесно интегрированы:

• Компонент 1 предоставляет предсказания для реальной обработки инцидентов и данные для симуляции.
  
• Компонент 2 обеспечивает надежность и актуальность ML-моделей через MLOps-практики.
  
• Компонент 3 предоставляет количественную оценку эффекта от внедрения ML, которая используется для принятия решений о развертывании и настройке системы.
  

Обратная связь из Компонента 3 (результаты симуляции) влияет на Компонент 2 (решения о переобучении, изменении архитектуры моделей) и Компонент 1 (настройка параметров классификации и приоритизации).

Таблица 1 – Ключевые показатели эффективности (KPI) и влияние ML-оптимизации

ОБСУЖДЕНИЕ

Интеграция МО в критические бизнес-процессы, такие как техническая поддержка, трансформирует роль системного аналитика. СА перестает быть сфокусирован только на верификации детерминированного кода и начинает играть ключевую роль в управлении всем жизненным циклом AI-системы через призму MLOps-методологии [10, С. 3475-3476].

Системные преимущества предложенного подхода

Количественная оценка эффекта: интеграция ML-прогнозов с имитационным моделированием позволяет проводить строгую количественную оценку влияния AI на системные KPI еще до фактического развертывания, минимизируя риски и обеспечивая обоснованность инвестиций [22, С. 152-154].

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

Адаптивность: MLOps-практики обеспечивают непрерывную адаптацию системы к изменяющимся условиям через автоматическое переобучение и мониторинг data drift [14, С. 92-93].

Масштабируемость: предложенная архитектура позволяет масштабировать решение от пилотного проекта до enterprise-уровня благодаря модульной структуре и использованию стандартных MLOps-инструментов.

Проблемы и ограничения

Несмотря на потенциальные выгоды (уменьшение MTTR на 35-40% благодаря прогнозированию и оптимизации маршрутизации), возникают системные проблемы и ограничения:

Качество данных: эффективность ML-моделей критически зависит от качества, полноты и репрезентативности обучающих данных [12, С. 158-160]. Проблемы включают:

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

Объяснимость решений: «черный ящик» глубоких нейронных сетей затрудняет понимание причин конкретных предсказаний, что может быть критично для аудита и соответствия регуляторным требованиям [26, С. 78-81]. Применение методов объяснимого AI (XAI), таких как LIME, SHAP, attention visualization, частично решает эту проблему, но увеличивает сложность системы.

Концептуальное смещение: со временем паттерны инцидентов могут меняться (новые продукты, изменения в инфраструктуре, новые типы атак), что приводит к деградации точности моделей [14, С. 89-90]. Требуется постоянный мониторинг и переобучение.

Этические аспекты: автоматизированная приоритизация может непреднамеренно привести к дискриминации определенных групп пользователей или типов проблем, требуется тщательный аудит на fairness и bias [27, С. 234-237].

Зависимость от инфраструктуры: развертывание ML-моделей требует значительных вычислительных ресурсов (особенно для больших трансформерных моделей) и может быть ограничено инфраструктурными возможностями организации [16].

Например, при использовании методов сжатия LLM, таких как квантование (quantization), может произойти потеря точности, что недопустимо для критичных систем. Именно здесь СА/MLOps обеспечивает механизмы верификации:

Надежность: моделирование через ТМО обеспечивает количественную оценку того, как неточность классификации влияет на конечный KPI, такой как FRT [22, С. 154]. Например, если точность классификации снижается с 95% до 90%, симуляция позволяет оценить, на сколько возрастет среднее время обработки и вероятность нарушения SLA.

Управляемость: применение MLOps-практик гарантирует, что развертывание происходит безопасно и что система может быть быстро возвращена к предыдущей версии (rollback) в случае деградации производительности [10, С. 3476].

Сравнение с существующими подходами

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

• Чат-боты и виртуальные ассистенты для автоматических ответов на типовые вопросы [28, С. 456-459].
  
• Системы knowledge management для предоставления операторам релевантной информации [29, С. 123-126].
  
• Инструменты для автоматической классификации инцидентов без интеграции с прогнозированием и оптимизацией ресурсов [6].
  

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

Направления дальнейших исследований

Предложенный фреймворк является шагом к стандартизации требований для AI-систем (RE4AI – Requirements Engineering for AI), которые признаны сложными для формализации из-за неявного, обучаемого поведения [7, С. 10-12]. Применение МО для прогнозирования MTTR и AHT в сочетании с симуляцией ТМО предоставляет необходимую методологическую строгость для оценки системного эффекта в нелинейных рабочих процессах.

Дальнейшие исследования могут быть сосредоточены на следующих направлениях:

Объяснимый AI (XAI): интеграция методов объяснимого ИИ для повышения прозрачности решений, принятых моделями при приоритизации, что дополнительно усилит соответствие требованиям системного анализа [26, С. 82-85].

Активное обучение (Active Learning): разработка стратегий для эффективного сбора обратной связи от операторов с целью минимизации объема данных, необходимых для обучения и дообучения моделей [30, С. 1367-1370].

Федеративное обучение (Federated Learning): для организаций с распределенной инфраструктурой – обучение моделей на децентрализованных данных без их централизации, что важно для соблюдения требований конфиденциальности [31, С. 1-17].

Reinforcement Learning для динамической оптимизации: применение обучения с подкреплением для адаптивного управления приоритизацией и маршрутизацией инцидентов в реальном времени на основе текущего состояния системы [32, С. 234-238].

Мультимодальные модели: расширение за пределы текстовых данных для анализа скриншотов, логов, метрик системы для более точной диагностики проблем [33, С. 1-8].

ВЫВОДЫ

Проведенное исследование подтверждает, что внедрение моделей машинного обучения (NLP-моделей на основе трансформеров и регрессионных моделей) в процессы технической поддержки, управляемое методологией системного анализа через призму MLOps, является эффективным решением для оптимизации операционной эффективности.

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

Оптимизация процессов: использование трансформерных моделей класса BERT для автоматизированной классификации запросов и регрессионных моделей для прогнозирования MTTR/AHT напрямую влияет на снижение нагрузки на персонал и гарантированное ускорение времени отклика (FRT). Прогнозируемые улучшения составляют:

• Снижение FRT на 60-95% (с 15-30 минут до менее 1 минуты).
  
• Снижение MTTR на 35-40% за счет оптимальной маршрутизации.
  
• Увеличение FCR до 85-90% благодаря предоставлению операторам релевантной информации.
  
• Повышение SLA Compliance до 95-98%.
  

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

Практическая значимость: предложенный фреймворк может быть адаптирован для различных организаций независимо от их размера и специфики IT-инфраструктуры. Модульная архитектура позволяет внедрять компоненты постепенно, начиная с пилотного проекта и масштабируя до enterprise-уровня.

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

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

1. Gartner Inc. Руководство по рынку инструментов управления ИТ-услугами (IT Service Management Tools) / Gartner Research. – 2023. – 45 с.
2. Климова Д. Н. Оптимизация процессов технического обеспечения на основе анализа ключевых показателей эффективности // Вестник Донского государственного технического университета. – 2023. – Т. 23, № 2. – С. 85–102.
3. Лучшие мировые практики Axelos. Основы ITIL: редакция ITIL 4. – Лондон: TSO, 2019. – 254 с.
4. Соболь Б. В., Галушкин А. И. Нелинейные системы управления в IT-инфраструктуре // Известия ЮФУ. Технические науки. – 2022. – № 4 (228). – С. 198–210.
5. Девлин Дж., Чанг М.-В., Ли К., Тутанова К. БЕРТ: обучение принципам двунаправленных трансформеров для понимания естественного языка // Труды конференции предварительно NAACL-HLT 2019. – 2019. – Т. 1. – С. 4171–4186.
6. Лю З., Седок Дж., Элдардири Х. Ticket-BERT: маркировка заявок по инцидентам с помощью языковых моделей // Препринт arXiv arXiv:2304.12622. – 2023. – 12 с.
7. Фогельсанг А., Борг М. Инженерные требования к машинному обучению: взгляд со стороны дат-саентистов // Труды 27-й международной конференции IEEE по инженерным требованиям (REW). – 2019. – С. 245–251.
8. Амерши С., Бегель А., Бёрд К., ДеЛайн Р., Галл Х., Камар Э., Нагаппан Н., Нуши Б., Циммерманн Т. Инженерия Программное обеспечение для машинного обучения: практический кейс // Труды 41-й конференции по инженерии ПО (ICSE). – 2019. – С. 291–300.
9. Рциг О., Алтаеб М., Рагаб А., Руан М. Анализ проблем развития MLOps на предприятиях // Journal of Innovation & Knowledge. – 2024. – Т. 9, № 1. – Статья 100453.
10. Кройцбергер Д., Кюль Н., Хиршль С. Машинное обучение эксплуатации (MLOps): обзор, определение и архитектура // IEEE Access. – 2023. – Т. 11. – С. 31866–31879.
11. Палейес А., Урма Р.-Г., Лоуренс Н.Д. Проблемы качества моделей машинного обучения: обзор практических кейсов // ACM Computing Surveys. – 2022. – Т. 55, № 6. – Статья 114. – С. 1–29.
12. Полизотис Н., Рой С., Ванг С.Э., Зинкевич М. Проблемы управления данными в продуктивном среднем машинном обучении // Труды ACM SIGMOD 2017. – 2017. – С. 1723–1726.
13. Сато Д., Видер А., Виндхойзер К. Непрерывная поставка для системного машинного обучения: шаблоны и проблемы // Труды конференции ICSA-C 2019. – 2019. – С. 19–26.
14. Лу Дж., Лю А., Донг Ф., Гу Ф., Гама Дж., Чжан Г. Обучение при концептуальном дрейфе: обзор // IEEE Transactions on Knowledge and Data Engineering. – 2019. – Т. 31, № 12. – С. 2346–2363.
15. Лю Ю., Отт М., Гоял Н., Ду Дж., Джоши М., Чен Д., Леви О., Льюис М., Зеттлмойер Л., Стоянов В. РОБЕРТа: улучшенный подход к предобучению BERT // Препринт arXiv arXiv:1907.11692. – 2019. – 13 с.
16. Сан В., Дебют Л., Шомон Дж., Вольф Т. DistilBERT — облегчённая версия BERT: меньше, быстрее, дешевле и легче // Препринт arXiv arXiv:1910.01108. – 2019. – 5 с.
17. Петрова А. С., Иванов К. М. Применение больших языковых моделей в технической поддержке автоматизации автоматизации // Программные продукты и системы. – 2024. – № 1. – С. 232–245.
18. Управление двигателем. Использование моделей машинного обучения для интеллектуального ITSM: технический доклад. – Плезантон, Калифорния: Zoho Corporation, 2022. – 78 с.
19. Чен Т., Гестрин К. XGBoost: масштабируемый бустинг решений // Труды 22-й конференции ACM SIGKDD. – 2016. – С. 785–794.
20. Брейман Л. Случайные леса // Машинное обучение. – 2001. – Т. 45, № 1. – С. 5–32.
21. Гудфеллоу И., Бенджио Ю., Курвиль А. Глубокое обучение. – Кембридж, Массачусетс: MIT Press, 2016. – 800 с.
22. Кар П., Нанди С., Кумар А. Теоретическое исследование теории массового обслуживания и ее пересечения с искусственным интеллектом // Труды ICIAAI 2023. – 2023. – Т. 12635. – С. 145–156.
23. Клейнрок Л. Системы массового обслуживания, том I: теория. – Нью-Йорк: Wiley-Interscience, 1975. – 417 с.
24. Смирнов А. В., Кузнецова О. Н. Имционативное моделирование процессов обслуживания медицинской информации // Информационные технологии. – 2023. – Т. 29, № 3. – С. 42–51.
25. Rootly Inc. Искусственный интеллект в ответ на инциденты: как автоматизация инвестиций MTTR / Технический отчёт. – Сан-Франциско, 2024. – 34 с.
26. Арриета А.Б., Диас-Родригес Н., Дель Сер Х., Беннетот А., Табик С., Барбадо А. и др. Объяснимый искусственный интеллект (XAI): концепции, таксономии, возможности и вызовы на пути к ответственному ИИ // Information Fusion. – 2020. – Т. 58. – С. 82–115.
27. Мехраби Н., Морстаттер Ф., Саксена Н., Лерман К., Галстян А. Обзор методов борьбы с предвзятостью и обеспечения справедливости в машинном обучении // ACM Computing Surveys. – 2021. – Т. 54, № 6. – Статья 115. – С. 1–35.
28. Сюй А., Лю З., Го Ю., Синха В., Аккираджу Р. Новый чат-бот для клиентской поддержки в социальных сетях // Труды CHI 2017. – 2017. – С. 3506–3510.
29. Уоллес Д.П., Ван Флит К. Знание в действии: исследования и оценка в библиотечно-информационных науках. – Санта-Барбара, Калифорния: Libraries Unlimited, 2012. – 392 с.
30. Сеттлс Б. Обзор методов активного обучения / Технический отчёт № 1648. – Мэдисон, Висконсин: Университет Висконсина-Мэдисона, 2009. – 67 с.
31. МакМахан Б., Мур Э., Рэймидж Д., Хэмпсон С., Аркас Б.А. Эффективное по коммуникациям обучение традиционным нейросетям на децентрализованных данных // AISTATS 2017. – Т. 54. – С. 1273–1282.
32. Саттон Р.С., Барто А.Г. Обучение с поддержанием: введение. 2-е изд. – Кембридж, Массачусетс: MIT Press, 2018. – 552 с.
33. Рэдфорд А., Ким Дж.В., Халласи К., Рамеш А., Го Г., Агарвал С. и др. Обучение переносу других визуальных моделей на основе языкового надзора // ICML 2021. – Т. 139. – С. 8748–8763.

Все статьи автора «Новиков Дмитрий Романович»