МТС: от RAG к агентам — анализ тикетов Jira через MCP и логи

Ведущий инженер МТС Web Services Илья Парамошин опубликовал на Habr третью статью цикла о развитии RAG-помощника для технической поддержки — на этот раз о переходе от поиска по документации к платформе с MCP-доступом к логам, базам данных и автоматическим анализом тикетов Jira.

Три статьи одного цикла

Материал продолжает серию из двух более ранних публикаций того же автора на Habr. Первая статья была посвящена архитектуре RAG-помощника (Retrieval-Augmented Generation — генерация ответов с опорой на найденные документы) для технической поддержки: индексации Confluence и Jira, гибридному поиску, генерации ответов с цитатами и оценке качества поиска. Вторая, недавняя публикация рассказывала, как в МТС Web Services построили ИИ-агента для автоматического анализа тикетов.

• Автор — Илья Парамошин, ведущий инженер МТС Web Services
• Первая статья цикла — архитектура RAG-помощника для техподдержки (индексация Confluence и Jira, гибридный поиск, оценка качества поиска)
• Вторая статья — ИИ-агент для автоматического анализа тикетов
• Третья статья (разбираемая здесь) — MCP, логи и путь тикета от создания до комментария

Зачем RAG понадобились логи и MCP?

После внедрения RAG-помощника инженеры компании стали быстрее находить нужные инструкции и регламенты — это прямой эффект первой версии системы, который отмечает Парамошин. Расследование инцидентов, впрочем, требовало ещё и работы с логами, базами данных и самой Jira, а не только с текстом документации в Confluence. Именно поэтому команда решила расширить систему за пределы поиска, а не ограничиваться правками базы знаний.

Как устроена новая платформа

Инженеры МТС Web Services не стали переписывать RAG-систему заново, а развили её как платформу вокруг трёх задач.

«Мы не стали переписывать RAG, а начали развивать его как платформу вокруг трёх задач: единый интерфейс, доступ к эксплуатационным данным и автоматизация анализа тикетов», —

Илья Парамошин, ведущий инженер МТС Web Services, в статье на Habr.

Поиск остался ядром платформы, но вокруг него появились отдельные сервисы: одни — для интерактивной работы инженера в момент расследования, другие — для фонового анализа тикетов без участия человека. Из трёх задач, вокруг которых выстроена платформа, первая — единый интерфейс, через который инженер обращается и к поиску по документации, и к остальным сервисам. Вторая — доступ к эксплуатационным данным: логам, базам, самой Jira, реализованный, судя по заголовку статьи, через протокол MCP (Model Context Protocol) — открытый стандарт, который даёт ИИ-агентам структурированный доступ к внешним источникам данных вместо отдельной интеграции под каждый сервис. Третья задача — автоматизация анализа тикетов, то есть перенос части рутинной работы инженера на фоновые сервисы.

По словам автора, далее в статье разбирается сама архитектура решения, причины, по которым отдельные компоненты вынесли из RAG-системы в самостоятельные сервисы, и путь тикета — от момента создания до автоматически сгенерированного комментария в Jira. Сам материал озаглавлен «Жизнь после RAG: MCP, логи и автоматический анализ тикетов Jira» — название прямо указывает на смену фокуса: с чистого поиска по базе знаний на работу с живыми эксплуатационными данными.

Что это значит

Кейс МТС Web Services показывает типичный путь развития корпоративных RAG-систем: от разового чат-бота над документацией — к инфраструктуре, которая объединяет поиск, эксплуатационные данные и автоматизацию рутинных операций вокруг тикетов поддержки. Три статьи одного цикла на Habr — от архитектуры поиска к ИИ-агенту и затем к MCP-доступу и логам — фиксируют, как меняются требования к корпоративным AI-помощникам по мере того, как инженеры используют их не только для чтения документации, но и для расследования инцидентов.