Классический RAG долгое время продавали бизнесу как «серебряную пулю»: залейте документы в базу, прикрутите LLM, и сотрудники уйдут в бессрочный отпуск. На поверку выяснилось, что умная поисковая строка остается всего лишь строкой. Если инженер второй линии техподдержки не понимает, что именно искать в терабайтах логов и тикетов Jira, семантический поиск ему не поможет. Мы уперлись в кризис инструментов, которые умеют отвечать на вопросы, но не способны их задавать. Ситуация в МТС Web Services (MWS), описанная SRE-лидом Владимиром Дроботом, — идеальная иллюстрация этого потолка. Компания построила RAG-систему на базе Jira и Confluence, но быстро споткнулась о человеческий фактор: инженеры не знали, как формулировать запросы при разборе инцидентов, где корень проблемы (root cause) изначально не очевиден.
Проблема в том, что в сложных B2B-процессах знания распределены хаотично. Чтобы закрыть тикет, нужно сопоставить документацию, историю багов и сырые дампы трафика. Как отмечает Владимир Дробот, главным барьером стало то, что для получения пользы от RAG инженер должен заранее осознать, какие данные ему нужны. В итоге инструмент, призванный ускорить работу, использовался лишь эпизодически, а его влияние на бизнес-метрики болталось в «серой зоне» субъективных отзывов. Попытка автоматизировать интеллект через поиск превратилась в создание очередного справочника, который пылится на полке, потому что к нему забыли составить оглавление.
От справки к цифровому сотруднику
Логика развития привела команду MWS к агентной архитектуре. Это переход от модели «спроси — отвечу» к концепции «вот задача — иди и разберись». Разница фундаментальная: вместо ожидания запроса система сама инициирует расследование сразу после появления тикета. Она забирает текст задачи, вытягивает данные из вложений — от PDF до tcpdump — и запускает многоэтапный цикл анализа. По сути, это попытка превратить ИИ из секретаря в автономного стажера, который сам копается в архивах, не дергая старшего коллегу каждые пять минут.
Технически это сложнее обычного промпт-инжиниринга. Команда использует связку паттернов Prompt Chaining и Parallelization, где нейросеть (в данном случае Qwen-32B или аналогичные модели) на каждом этапе решает, хватает ли ей фактов или нужно «сходить ногами» в базу данных за добавкой.
Наше решение ближе к workflow, поскольку основные этапы анализа тикета известны заранее.
Это заявление Владимира Дробота фиксирует важный сдвиг: ИИ наконец-то разрешили не только красиво галлюцинировать, но и распоряжаться инструментами разработки. В результате инженер получает в Jira не просто ссылку на статью в Confluence, а готовую подзадачу с гипотезой, выгрузками из БД и списком аналогичных аварий в прошлом.
Экономика и барьеры автономности
Агентные workflow — это не только технологический апгрейд, но и вопрос выживания экономики техподдержки. Когда система берет на себя первичный анализ, она напрямую экономит самый дорогой ресурс — время инженеров L2. Однако здесь скрыт подвох: агент бесполезен без качественного «топлива». В кейсе МТС успех системы завязан на то, как обрабатываются входные данные. Использование специализированных моделей вроде Kimi K2 для парсинга тяжелых документов — это признание того, что стандартные LLM все еще пасуют перед реальным корпоративным хаосом.
Интеграция с внутренними REST-сервисами превращает поддержку в конвейер, где человек лишь верифицирует результат. Но чтобы этот конвейер не множил ошибки, требуется высочайшая культура документирования. Если в Confluence пусто, а логи не структурированы, агент просто масштабирует неразбериху. МТС развернула решение на собственной инфраструктуре через MWS GPT, что снимает вопросы безопасности, но оставляет открытым вопрос масштабируемости на менее зрелые ИТ-команды. Без внятной истории инцидентов любой «автономный аналитик» останется дорогой игрушкой. Главный вопрос теперь не в том, какую модель выбрать, а в том, готовы ли компании навести порядок в своих процессах, который они игнорировали десятилетиями.