Привет! Меня зовут Владимир Дробот, я SRE-лид и руководитель центра техподдержки кластера рекламных технологий компании МТС Web Services. Наша команда отвечает за вторую линию саппорта: мы разбираем сложные инциденты, ищем корни проблем и передаем разработчикам те баги, которые упираются в код или архитектуру.     

Для решения задач инженерам приходится работать одновременно с Jira, Confluence, логами и базами данных. Несмотря на существующую документацию, много времени уходило на поиск информации и анализ уже решенных инцидентов. Недавно мы внедрили систему поиска на базе RAG: общее описание и технические детали. Наше решение объединило данные из Jira и Confluence в единую поисковую систему, инженеры получают ответы на вопросы на естественном языке.

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

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

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

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

Что мы подразумеваем под ИИ-агентной системой

 Термин «ИИ-агент» сегодня используют настолько широко, что под ним могут подразумеваться совершенно разные решения — от простых сценариев с вызовом LLM до полностью автономных систем, самостоятельно планирующих свою работу.

В статье Building Effective Agents компания Anthropic разделяет два понятия:

• Агент (agent) — система, в которой LLM самостоятельно определяет последовательность действий и выбирает инструменты для достижения цели.

• Workflow — система с заранее заданным сценарием работы, где LLM выполняет отдельные шаги анализа и принятия решений.

Для обозначения обоих подходов Anthropic использует общий термин агентные системы (agentic systems).

Наше решение ближе к workflow, поскольку основные этапы анализа тикета известны заранее: сбор данных, работа с документацией, логами и базой данных, формирование результата. При этом на некоторых этапах LLM все же принимает решения о том, какие действия выполнять дальше и какие источники информации использовать. Поэтому мы используем понятие агентная система именно в этом широком смысле — как систему, в которой LLM не только генерирует текст, но и участвует в управлении процессом решения задачи.

В плане архитектуры наше решение сочетает два паттерна агентных систем по Anthropic: цепочку промптов (Prompt Chaining) и параллельную обработку (Parallelization).

Архитектура и логика работы системы анализа тикетов

На вход система принимает тикет Jira, собирает текст из всех текстовых полей и дополняет его текстом из прикрепленных файлов. Основные поддерживаемые форматы: Microsoft Office, pdf, графические файлы, tcpdump. Для обработки файлов используем модель Kimi K2. Для остальных задач мы использовали LLM, развернутые на инфраструктуре компании в рамках решения MWS GPT. Наилучшее соотношение качества и скорости мы получили на модели Qwen3.5-35B-A3B.

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

Когда анализ завершен, в исходном тикете создается подзадача с полным решением, а также появляется комментарий с резюме полного текста решения. Он содержит рекомендуемые действия и текст ответа пользователю. Если нужно сделать, например, выгрузку из базы данных, прикрепляется еще и файл с результатами. Решение содержит не только ссылки на документацию на Confluence, но и на аналогичные тикеты в Jira.

Описание сервисов

Система состоит из нескольких сервисов, взаимодействующих между собой по REST-протоколу. Каждый из них по ходу работы обращается к LLM.

Обработчик тикетов

Начальная обработка тикета Jira и оркестрация работы системы состоит из следующих шагов:

●        извлечение текста из прикрепленных файлов;

●        анализ текста тикета и решение о дальнейших действиях;

●        если данных для анализа недостаточно — сообщение об этом пользователю;

●        определение дальнейшего пути анализа;

●        формирование запроса к сервисам;

●        создание комментария и подзадачи в Jira с результатами анализа.

А еще сервис регулярно обращается к Jira, чтобы находить и добавлять в задачу новые тикеты, подходящие под критерии анализа. Из-за ограничений корпоративной Jira мы не смогли использовать вебхуки для оперативного запуска анализа, но и при текущем подходе обычно решение появляется не позднее чем через 10 минут после создания тикета, что вполне приемлемо. Он запускается при создании тикета, а также при условии, что тикет остается открытым в течение 24 часов после последнего анализа и за это время появились новые комментарии. Это помогает лучше понять, что происходит с редкими тикетами, которые остаются открытыми долгое время и в которых нередко идет довольно интенсивная переписка в комментариях.

Сервис анализа логов

Он напрямую извлекает логи из хранилища логов Victoria Logs и делает анализ на основе данных тикета.

Сервис работы с данными

На основе данных тикета он извлекает нужное из баз данных и анализирует. Если нужно, делает выгрузку и прикрепляет к тикету в виде CSV-файла. Доступ к базам данных PostreSQL и ClickHouse организован через протокол MCP.

Сервис RAG

Сервис ищет по векторной базе, содержащей документы из проектов Jira и пространств Confluence, а также обрабатывает ответ LLM.  Как раз об этом мы подробно рассказывали в двух предыдущих постах: первый и второй.

Поддерживает подключение по OpenAI Chat Completions API.

Внедрение и результаты

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

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

Правильное решение — примерно 40% всех тикетов. К правильным мы относили следующие случаи:

• логика расследования и рекомендуемые действия соответствовали фактическому способу решения задачи;

• сделано исследование и подготовлен ответ клиенту;

• система поняла, что нужны дополнительные данные для анализа и сформулировала запрос.

Неправильное решение — примерно 15% задач. В этих случаях ИИ делал неверные выводы и предлагал шаги, которые не приводили к решению.

Неполное решение — в остальных случаях, примерно 45% задач. Агент находил частичное решение: в анализе была полезная информация, но нужно было дополнительное исследование со стороны инженера.

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

Сразу после внедрения коллеги отметили такие преимущества новой системы:

• Аналогичные тикеты в Jira помогают лучше понять проблему и найти решение.

• Готовые формулировки можно сразу использовать при ответах клиенту.

• Решение несложных запросов на консультацию. От клиентов и аккаунт-менеджеров приходят вопросы и жалобы на поведение системы. Теперь их можно решить просто поиском через RAG. Кстати, одна из таких задач как раз стала первой, которая была закрыта без участия инженеров поддержки: менеджер клиента создал задачу на консультацию, изучил ответ ИИ и самостоятельно ее закрыл.

• Работа с базой данных. Это задачи на выгрузку данных от клиентов или менеджеров, на изменение данных или задачи, в которых для решения нужно использовать данные из БД. Теперь при запросе на изменение данных в БД генерируется SQL-запрос: по понятным причинам доступ по MCP у нас только на чтение. В остальных случаях система успешно справляется с несложными выгрузками, а в сложных случаях пока необходима помощь человека.

• Обращение к логам. Около 20% всех задач решилось за счет анализа логов, поиска ошибки и быстрого составления ответа по шаблону в зависимости от кода ошибки. В остальных задачах обращение к логам относилось скорее к общему исследованию.

Примеры решений

1. Успешное решение запроса на консультацию от клиентского менеджера.

Запрос:

Коллеги, добрый день!    

Прошу пояснить, как возможно начисление средств на счет клиента, если до момента оплаты была установлена блокировка?

Ответ ИИ-агента:

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

2. Успешное решение на основе анализа логов.

Запрос:

Прошу уточнить причину недоставки СМС на номер +70001234567.

Сценарий 1 (Успешная отправка, но нет подтверждения доставки)

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

Сценарий 2 (Обнаружение ошибки в логах)

Анализ логов ошибка доставки. По коду ошибки определяется причина: «Некорректный формат номера или статус абонента (выключен/недоступен в течение длительного периода)». Система фиксирует данные из логов и логику анализа в тикете. На основании этой информации ИИ-агент генерирует итоговый ответ для клиента и вносит его в комментарий тикета.

3. Успешное решение запроса на выгрузку.

Запрос:

Просьба сформировать выгрузку за [период] по клиентам, использующим услугу [название услуги].

Формат: ИНН, наименование, количество транзакций в разбивке по дням. Пример: 123456789 ООО «Компания» 01.05.26 5 транзакций, 02.05.26 145 транзакций.

Ответ ИИ-агента:

«Составлен SELECT-запрос с использованием функций агрегирования, объединяющий три таблицы. Результат выполнения выгружен в виде Excel-файла и прикреплен к тикету.»

4. Неуспешное решение запроса на выгрузку

Запрос:

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

Формат вывода: ИНН, наименование, текст шаблона, ID шаблона, список операторов.

Действия ИИ-агента

Агент определил, что для решения задачи необходимо объединить данные о шаблонах сообщений и данные о привязках операторов связи. После этого он сгенерировал SQL-запрос с JOIN между соответствующими таблицами и попытался выполнить его через сервис работы с БД.

Что пошло не так

Таблицы находились в разных базах данных, объединить их напрямую на стороне СУБД было нельзя. Агент не учел это ограничение архитектуры и попытался решить задачу одним SQL-запросом.

В результате выполнение запроса завершилось ошибкой.

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

Для решения задачи необходимо было:

• Получить данные о шаблонах из первой базы данных.

• Получить данные о привязках операторов из второй базы данных.

• Выполнить сопоставление и пересечение данных на уровне приложения.

• Сформировать итоговую выгрузку.

Этот кейс показал, что агент успешно понимает бизнес-логику задачи, но пока не всегда учитывает архитектурные ограничения источников данных.

5. Неуспешное решение (неполная документация)

Запрос:

Прошу загрузить список из одного сайта. Текущий функционал ограничивает загрузку списков менее чем из трех записей.

Ответ ИИ-агента:

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

Правильное решение: рекомендовать клиенту перейти в личный кабинет и установить галочку «Выключение ограничений по загрузке списков.»

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

Улучшение качества ответов

После внедрения и первых результатов мы задались целью — повысить качество ответов и уровень доверия к ИИ. Для этого стали выборочно анализировать тикеты с неправильными или неполными решениями и создавали отдельные задачи на улучшение качества анализа.

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

1. Расширение или изменение документации.

2. Изменения в системные промпты, которые используются при обращении к LLM в разных сервисах.

Так мы смогли улучшить полноту ответа для небольшого подкласса задач. А в идеале хотим, чтобы отдельные классы задач можно было решать без участия человека. В этом случае мы сократим время решения не только за счет того, что ИИ быстрее человека обращается к источникам данных и находит документацию, но и потому, что он может быстрее приступить к решению, пока люди разбирают очередь из более приоритетных и сложных задач. Если учесть время, которое простая и низкоприоритетная задача ждет в бэклоге, то скорость решения в некоторых случаях можно снизить с 2–3 часов до нескольких минут.

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

Выводы

После нескольких месяцев эксплуатации системы мы пришли к некоторым неочевидным в начале проекта выводам:

• RAG оказался не конечным решением, а промежуточным этапом. Основная проблема поддержки была не в отсутствии поиска, а в том, что инженеру нужно было понять, что именно искать. Агентная система может выполнять эту часть работы и в нашем случае начинает расследование сразу после появления тикета.

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

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

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

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

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

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