MTS: de RAG a los agentes, análisis de tickets de Jira mediante MCP y logs

Ilya Paramoshin, ingeniero principal de MTS Web Services, ha publicado en Habr el tercer artículo de su serie sobre la evolución de un asistente RAG para soporte técnico. Esta vez aborda el paso de la búsqueda en documentación a una plataforma con acceso MCP a logs y bases de datos, además del análisis automático de tickets de Jira.

Tres artículos, una serie

El texto continúa dos publicaciones anteriores del mismo autor en Habr. La primera se centraba en la arquitectura de un asistente RAG (Retrieval-Augmented Generation, generación de respuestas apoyada en documentos recuperados) para soporte técnico: indexación de Confluence y Jira, búsqueda híbrida, generación de respuestas con citas y evaluación de la calidad de la búsqueda. La segunda, más reciente, explicaba cómo en MTS Web Services construyeron un agente de IA para el análisis automático de tickets.

• Autor: Ilya Paramoshin, ingeniero principal de MTS Web Services
• Primer artículo: arquitectura del asistente RAG para soporte técnico (indexación de Confluence y Jira, búsqueda híbrida, evaluación de la calidad de la búsqueda)
• Segundo artículo: agente de IA para el análisis automático de tickets
• Tercer artículo (el que se analiza aquí): MCP, logs y el recorrido de un ticket desde su creación hasta el comentario

¿Por qué RAG necesitó logs y MCP?

Tras implantar el asistente RAG, los ingenieros de la compañía empezaron a encontrar más rápido las instrucciones y normativas que necesitaban. Paramoshin señala que es un efecto directo de la primera versión del sistema. Sin embargo, investigar incidentes exigía además trabajar con logs, bases de datos y la propia Jira, y no solo con el texto de la documentación en Confluence. Por eso el equipo decidió ampliar el sistema más allá de la búsqueda, en lugar de limitarse a retocar la base de conocimiento.

Cómo funciona la nueva plataforma

Los ingenieros de MTS Web Services no reescribieron el sistema RAG desde cero, sino que lo desarrollaron como una plataforma en torno a tres tareas.

«No reescribimos RAG, sino que empezamos a desarrollarlo como una plataforma en torno a tres tareas: interfaz única, acceso a datos operativos y automatización del análisis de tickets», —

Ilya Paramoshin, ingeniero principal de MTS Web Services, en el artículo de Habr.

La búsqueda sigue siendo el núcleo de la plataforma, pero a su alrededor han aparecido servicios independientes: unos para el trabajo interactivo del ingeniero durante una investigación y otros para el análisis de tickets en segundo plano, sin intervención humana. De las tres tareas, la primera es una interfaz única desde la que el ingeniero accede tanto a la búsqueda en documentación como al resto de servicios. La segunda es el acceso a datos operativos (logs, bases de datos y la propia Jira), implementado, a juzgar por el título del artículo, mediante el protocolo MCP (Model Context Protocol), un estándar abierto que da a los agentes de IA acceso estructurado a fuentes de datos externas en lugar de una integración distinta para cada servicio.

La tercera tarea es automatizar el análisis de tickets, es decir, trasladar parte del trabajo rutinario del ingeniero a servicios en segundo plano.

Según el autor, el artículo examina después la arquitectura de la solución, las razones por las que ciertos componentes se sacaron del sistema RAG para convertirlos en servicios autónomos, y el recorrido de un ticket desde su creación hasta un comentario generado automáticamente en Jira. El texto se titula «La vida después de RAG: MCP, logs y análisis automático de tickets de Jira», y el título ya indica un cambio de enfoque: de la búsqueda pura en la base de conocimiento al trabajo con datos operativos en vivo.

Qué significa

El caso de MTS Web Services muestra un camino típico de los sistemas RAG corporativos: de un chatbot puntual sobre documentación a una infraestructura que une búsqueda, datos operativos y automatización de operaciones rutinarias en torno a los tickets de soporte. Las tres publicaciones de Habr, que van de la arquitectura de búsqueda a un agente de IA y después al acceso MCP y los logs, reflejan cómo cambian los requisitos de los asistentes de IA corporativos a medida que los ingenieros los usan no solo para leer documentación, sino también para investigar incidentes.