MTS : De RAG aux Agents — Analyse des Tickets Jira via MCP et Logs

Le chef d'équipe des services Web de MTS, Ilya Paramoshin, a publié sur Habr le troisième article d'une série sur le développement d'un assistant RAG pour le support technique — cette fois sur la transition de la recherche documentaire vers une plateforme avec accès MCP aux journaux, bases de données et analyse automatique des tickets Jira.

Trois articles dans une série

Le matériel poursuit une série de deux publications antérieures du même auteur sur Habr. Le premier article était consacré à l'architecture d'un assistant RAG (Retrieval-Augmented Generation — génération de réponses basée sur les documents récupérés) pour le support technique : indexation de Confluence et Jira, recherche hybride, génération de réponses avec citations et évaluation de la qualité de la recherche. La deuxième publication, récente, raconte comment MTS Web Services a construit un agent IA pour l'analyse automatique des tickets.

• Auteur — Ilya Paramoshin, chef d'équipe chez MTS Web Services
• Premier article de la série — architecture de l'assistant RAG pour le support technique (indexation de Confluence et Jira, recherche hybride, évaluation de la qualité)
• Deuxième article — agent IA pour l'analyse automatique des tickets
• Troisième article (discuté ici) — MCP, journaux et le chemin d'un ticket de création à commentaire

Pourquoi RAG avait-il besoin de journaux et MCP ?

Après la mise en œuvre de l'assistant RAG, les ingénieurs de l'entreprise ont commencé à trouver plus rapidement les instructions et réglementations requises — c'est un effet direct de la première version du système, que Paramoshin note. L'enquête sur les incidents, cependant, exigeait de travailler avec les journaux, les bases de données et Jira lui-même, pas seulement la documentation textuelle dans Confluence. C'est pourquoi l'équipe a décidé d'étendre le système au-delà de la recherche plutôt que de se limiter aux mises à jour de la base de connaissances.

Comment la nouvelle plateforme est organisée

Les ingénieurs de MTS Web Services n'ont pas réécrit le système RAG de zéro, mais l'ont développé comme une plateforme autour de trois tâches.

"Nous n'avons pas réécrit RAG, mais avons commencé à le développer

comme une plateforme autour de trois tâches : interface unifiée, accès aux données opérationnelles et analyse automatique des tickets", — Ilya Paramoshin, chef d'équipe chez MTS Web Services, dans un article sur Habr.

La recherche est restée au cœur de la plateforme, mais des services distincts sont apparus autour d'elle : certains pour le travail interactif de l'ingénieur lors d'une enquête, d'autres pour l'analyse des tickets en arrière-plan sans intervention humaine. Parmi les trois tâches autour desquelles la plateforme est construite, la première est une interface unifiée à travers laquelle l'ingénieur accède à la fois à la recherche de documents et à d'autres services. La seconde est l'accès aux données opérationnelles : journaux, bases de données, Jira lui-même, implémenté, à en juger par le titre de l'article, via le protocole MCP (Model Context Protocol) — une norme ouverte qui donne aux agents IA un accès structuré aux sources de données externes au lieu d'une intégration séparée pour chaque service.

La troisième tâche est l'automatisation de l'analyse des tickets, c'est-à-dire le transfert d'une partie du travail routinier de l'ingénieur vers les services en arrière-plan.

Selon l'auteur, l'article discute en outre de l'architecture de la solution elle-même, les raisons pour lesquelles certains composants ont été séparés du système RAG en services indépendants, et le chemin d'un ticket — de la création à un commentaire Jira généré automatiquement. Le matériel s'intitule "Vie après RAG : MCP, journaux et analyse automatique des tickets Jira" — le titre indique directement un changement de focus : de la recherche pure de base de connaissances au travail avec des données opérationnelles en direct.

Ce que cela signifie

Le cas MTS Web Services montre un chemin typique pour le développement de systèmes RAG d'entreprise : d'un chatbot unique sur la documentation — à une infrastructure qui combine la recherche, les données opérationnelles et l'automatisation des opérations de tickets de support routinières. Trois articles dans une série sur Habr — de l'architecture de la recherche à l'agent IA, puis à l'accès MCP et aux journaux — capturent comment les exigences des assistants IA d'entreprise changent à mesure que les ingénieurs les utilisent non seulement pour lire la documentation, mais pour enquêter sur les incidents.

Questions fréquemment posées

Qu'est-ce que MCP et pourquoi est-il nécessaire ?

MCP (Model Context Protocol) est une norme ouverte qui donne aux agents IA un accès structuré aux sources de données externes — journaux, bases de données et systèmes de tickets — plutôt que d'exiger une intégration séparée pour chaque service.

Pourquoi des services séparés au lieu d'un système RAG unifié ?

Séparer les composants permet à la plateforme d'optimiser chaque tâche indépendamment : recherche interactif de documentation, analyse en arrière-plan des journaux et routage automatique des tickets — chacun avec ses propres exigences et SLA.

En quoi cela diffère-t-il des autres systèmes RAG d'entreprise ?

La plupart des implémentations RAG d'entreprise restent concentrées uniquement sur la recherche. MTS a évolué la sienne pour inclure l'intégration des données opérationnelles et l'automatisation — rendant la plateforme adaptée à l'enquête sur les incidents, pas seulement à la recherche de documentation.