MTS: De RAG a Agentes — Analizando Tickets Jira vía MCP y Logs

El ingeniero principal de MTS Web Services, Ilya Paramoshin, publicó en Habr el tercer artículo de una serie sobre el desarrollo de un asistente RAG para soporte técnico — esta vez sobre la transición de la búsqueda de documentos a una plataforma con acceso MCP a registros, bases de datos y análisis automatizado de tickets de Jira.

Tres artículos en una serie

El material continúa una serie de dos publicaciones anteriores del mismo autor en Habr. El primer artículo fue dedicado a la arquitectura de un asistente RAG (Retrieval-Augmented Generation — generación de respuestas basada 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 calidad de búsqueda. La segunda publicación, reciente, contó cómo MTS Web Services construyó un agente de IA para análisis automático de tickets.

• Autor — Ilya Paramoshin, ingeniero principal en MTS Web Services
• Primer artículo de la serie — arquitectura del asistente RAG para soporte técnico (indexación de Confluence y Jira, búsqueda híbrida, evaluación de calidad)
• Segundo artículo — agente de IA para análisis automático de tickets
• Tercer artículo (discutido aquí) — MCP, registros y la ruta de un ticket de creación a comentario

¿Por qué RAG necesitaba registros y MCP?

Después de implementar el asistente RAG, los ingenieros de la empresa comenzaron a encontrar instrucciones y regulaciones necesarias más rápidamente — este es un efecto directo de la primera versión del sistema, que Paramoshin señala. La investigación de incidentes, sin embargo, requería trabajar con registros, bases de datos y Jira mismo, no solo texto de documentación en Confluence. Por eso el equipo decidió expandir el sistema más allá de la búsqueda en lugar de limitarse a actualizaciones de la base de conocimientos.

Cómo se organiza la nueva plataforma

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

"No reescribimos RAG, sino que comenzamos a desarrollarlo como una plataforma alrededor de tres tareas: interfaz unificada, acceso a datos operacionales y análisis automatizado de tickets", —

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

La búsqueda permaneció como el núcleo de la plataforma, pero alrededor de ella aparecieron servicios separados: algunos para trabajo interactivo del ingeniero durante la investigación, otros para análisis de tickets en segundo plano sin participación humana. De las tres tareas alrededor de las cuales se construye la plataforma, la primera es una interfaz unificada a través de la cual el ingeniero accede tanto a búsqueda de documentos como a otros servicios. La segunda es acceso a datos operacionales: registros, bases de datos, Jira mismo, implementado, juzgando por el título del artículo, a través del protocolo MCP (Model Context Protocol) — un estándar abierto que proporciona a los agentes de IA acceso estructurado a fuentes de datos externas en lugar de una integración separada para cada servicio.

La tercera tarea es automatización de análisis de tickets, es decir, la transferencia de parte del trabajo rutinario del ingeniero a servicios de segundo plano.

Según el autor, el artículo discute además la arquitectura de la solución en sí, las razones por las que ciertos componentes fueron separados del sistema RAG en servicios independientes, y la ruta de un ticket — desde la creación hasta un comentario de Jira generado automáticamente. El material se titula "La vida después de RAG: MCP, registros y análisis automático de tickets de Jira" — el título indica directamente un cambio de enfoque: de la búsqueda pura de la base de conocimientos a trabajar con datos operacionales en vivo.

Qué significa esto

El caso de MTS Web Services muestra un camino típico para el desarrollo de sistemas RAG empresariales: de un chatbot único sobre documentación — a una infraestructura que combina búsqueda, datos operacionales y automatización de operaciones de tickets de soporte rutinarias. Tres artículos en una serie en Habr — desde arquitectura de búsqueda a agente de IA y luego a acceso MCP y registros — capturan cómo cambian los requisitos para asistentes de IA corporativos a medida que los ingenieros los usan no solo para leer documentación, sino para investigación de incidentes.

Preguntas frecuentes

¿Qué es MCP y por qué se necesita?

MCP (Model Context Protocol) es un estándar abierto que proporciona a los agentes de IA acceso estructurado a fuentes de datos externas — registros, bases de datos y sistemas de tickets — en lugar de requerir una integración separada para cada servicio.

¿Por qué servicios separados en lugar de un sistema RAG unificado?

Separar componentes permite a la plataforma optimizar cada tarea independientemente: búsqueda interactiva de documentación, análisis de segundo plano de registros y enrutamiento de tickets automatizado — cada uno con sus propios requisitos y SLAs.

¿Cómo difiere esto de otros sistemas RAG empresariales?

La mayoría de las implementaciones RAG corporativas permanecen enfocadas solo en búsqueda. MTS evolucionó la suya para incluir integración de datos operacionales y automatización — haciendo la plataforma adecuada para investigación de incidentes, no solo búsqueda de documentación.