MTS: De RAG para Agentes — Analisando Tickets Jira via MCP e Logs

O engenheiro líder do MTS Web Services, Ilya Paramoshin, publicou no Habr o terceiro artigo de uma série sobre o desenvolvimento de um assistente RAG para suporte técnico — desta vez sobre a transição da busca de documentos para uma plataforma com acesso MCP a registros, bancos de dados e análise automatizada de tickets de Jira.

Três artigos em uma série

O material continua uma série de duas publicações anteriores do mesmo autor no Habr. O primeiro artigo foi dedicado à arquitetura de um assistente RAG (Retrieval-Augmented Generation — geração de resposta baseada em documentos recuperados) para suporte técnico: indexação de Confluence e Jira, busca híbrida, geração de resposta com citações e avaliação de qualidade de busca. A segunda publicação, recente, contou como MTS Web Services construiu um agente de IA para análise automática de tickets.

• Autor — Ilya Paramoshin, engenheiro líder no MTS Web Services
• Primeiro artigo da série — arquitetura do assistente RAG para suporte técnico (indexação de Confluence e Jira, busca híbrida, avaliação de qualidade)
• Segundo artigo — agente de IA para análise automática de tickets
• Terceiro artigo (discutido aqui) — MCP, registros e o caminho de um ticket de criação a comentário

Por que RAG precisava de registros e MCP?

Depois de implementar o assistente RAG, os engenheiros da empresa começaram a encontrar instruções e regulamentos necessários mais rapidamente — este é um efeito direto da primeira versão do sistema, que Paramoshin nota. A investigação de incidentes, porém, exigia trabalhar com registros, bancos de dados e Jira em si, não apenas texto de documentação em Confluence. É por isso que a equipe decidiu expandir o sistema além da busca em vez de se limitar a atualizações da base de conhecimento.

Como a nova plataforma é organizada

Os engenheiros do MTS Web Services não reescreveram o sistema RAG do zero, mas o desenvolveram como uma plataforma em torno de três tarefas.

"Não reescrevemos RAG, mas começamos a desenvolvê-lo como uma plataforma em torno de três tarefas: interface unificada, acesso a dados operacionais e análise automatizada de tickets", —

Ilya Paramoshin, engenheiro líder no MTS Web Services, em um artigo no Habr.

A busca permaneceu o núcleo da plataforma, mas serviços separados apareceram ao seu redor: alguns para trabalho interativo do engenheiro durante a investigação, outros para análise de tickets em background sem envolvimento humano. Das três tarefas em torno das quais a plataforma é construída, a primeira é uma interface unificada através da qual o engenheiro acessa tanto a busca de documentos quanto outros serviços. A segunda é acesso a dados operacionais: registros, bancos de dados, Jira em si, implementado, julgando pelo título do artigo, através do protocolo MCP (Model Context Protocol) — um padrão aberto que fornece agentes de IA acesso estruturado a fontes de dados externas em vez de uma integração separada para cada serviço.

A terceira tarefa é automação de análise de tickets, ou seja, a transferência de parte do trabalho rotineiro do engenheiro para serviços em background.

Segundo o autor, o artigo discute ainda a arquitetura da solução em si, as razões pelas quais certos componentes foram separados do sistema RAG em serviços independentes, e o caminho de um ticket — desde a criação até um comentário Jira gerado automaticamente. O material é intitulado "Vida após RAG: MCP, registros e análise automática de tickets Jira" — o título indica diretamente uma mudança de foco: de busca pura de base de conhecimento para trabalhar com dados operacionais em tempo real.

O que isto significa

O caso MTS Web Services mostra um caminho típico para o desenvolvimento de sistemas RAG corporativos: de um chatbot único sobre documentação — para uma infraestrutura que combina busca, dados operacionais e automação de operações de tickets de suporte rotineiras. Três artigos em uma série no Habr — desde arquitetura de busca a agente de IA e depois a acesso MCP e registros — capturam como os requisitos para assistentes de IA corporativos mudam conforme os engenheiros os usam não apenas para ler documentação, mas para investigação de incidentes.

Perguntas frequentes

O que é MCP e por que é necessário?

MCP (Model Context Protocol) é um padrão aberto que fornece aos agentes de IA acesso estruturado a fontes de dados externas — registros, bancos de dados e sistemas de tickets — em vez de exigir uma integração separada para cada serviço.

Por que serviços separados em vez de um sistema RAG unificado?

Separar componentes permite que a plataforma otimize cada tarefa independentemente: busca interativa de documentação, análise em background de registros e roteamento automatizado de tickets — cada um com seus próprios requisitos e SLAs.

Como isto difere de outros sistemas RAG corporativos?

A maioria das implementações RAG corporativas permanecem focadas apenas em busca. MTS evoluiu a sua para incluir integração de dados operacionais e automação — tornando a plataforma adequada para investigação de incidentes, não apenas busca de documentação.