🤖 AI

RAG4Tickets: AI-Powered Ticket Resolution via Retrieval-Augmented Generation on JIRA and GitHub Data

L'article propose RAG4Tickets, un cadre alimenté par l'IA qui intègre les données JIRA et GitHub à l'aide de la génération augmentée par récupération pour fournir des recommandations de résolution de tickets contextuelles et fondées sur des preuves, améliorant considérablement la précision et l'efficacité des flux de travail de développement logiciel.

Auteurs originaux : Mohammad Baqar

Publié 2026-02-06

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Mohammad Baqar

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un développeur de logiciels travaillant sur un projet colossal. Chaque fois qu'un bug apparaît, c'est comme une nouvelle enquête policière. Par le passé, résoudre ces enquêtes revenait à chercher une aiguille dans une botte de foin composée de millions d'autres aiguilles. Vous deviez fouiller dans les anciens tickets JIRA (rapports de bugs), lire des milliers de commentaires de développeurs et scanner les changements de code sur GitHub pour voir si quelqu'un avait déjà résolu un problème similaire. Souvent, même si le problème était le même, les mots utilisés pour le décrire étaient différents, ce qui vous faisait manquer la solution et vous faisait perdre des heures à réinventer la roue.

Ce document, « RAG4Tickets », propose un assistant intelligent qui agit comme un bibliothécaire et un détective surpuissants combinés pour résoudre ce problème. Voici comment il fonctionne, décomposé en étapes simples :

1. Le Problème : La bibliothèque « Perdue dans la Traduction »

Considérez l'historique des bugs et des corrections de votre entreprise comme une immense bibliothèque chaotique.

Le Problème : Un développeur écrit un ticket disant : « L'application se fige quand je clique sur le bouton. » Un autre développeur, il y a deux ans, a écrit un ticket disant : « L'écran se bloque lors d'une interaction utilisateur. » Même si ces deux cas sont identiques, une simple recherche par mot-clé pourrait manquer le lien.
Le Résultat : Les développeurs passent trop de temps à chercher et pas assez de temps à réparer.

2. La Solution : Le « Bibliothécaire Intelligent » (RAG)

Les auteurs ont construit un système appelé RAG4Tickets. Considérez ce système comme un bibliothécaire hautement qualifié qui ne se contente pas de lire les titres des livres, mais qui comprend le sens qui se cache derrière eux.

Étape 1 : Lire et Comprendre (Embeddings) :
Le système lit chaque ancien rapport de bug, commentaire et changement de code (Pull Request). Il utilise un outil spécial appelé Sentence-Transformers pour transformer ces mots en « cartes de sens » (vecteurs). Au lieu de simplement chercher le mot « crash », il comprend que « freeze », « lock up » et « hang » pointent tous vers le même concept.
Étape 2 : La Recherche Ultra-Rapide (FAISS) :
Une fois que le système possède ces cartes de sens, il les stocke dans un index massif et ultra-rapide appelé FAISS. Imaginez cela comme une carte magique où des idées similaires sont physiquement situées les unes à côté des autres. Lorsqu'un nouveau bug survient, le système trouve instantanément les 5 ou 10 cas passés les plus similaires, même si la formulation est totalement différente.
Étape 3 : Le Rapport du Détective (Génération par LLM) :
Le système ne se contente pas de vous montrer les anciens tickets ; il agit comme un détective qui résume l'affaire. Il prend les anciennes solutions qu'il a trouvées et les transmet à un Modèle de Langage Étendu (IA). L'IA rédige ensuite un guide clair, étape par étape, sur la façon de corriger le nouveau bug, en citant précisément quels anciens changements de code l'ont résolu. C'est comme avoir un ingénieur senior qui vous murmure : « Hé, nous avons réglé exactement ce problème l'année dernière ; voici le code que nous avons utilisé. »

3. Comment cela fonctionne dans la vie réelle

Le document a testé ce système lors d'une mise à jour majeure d'une application web (le passage de React 18 à React 19).

Le Scénario : Les développeurs étaient confrontés à un type spécifique de « gel de l'interface utilisateur » (UI freeze) causé par la nouvelle version du logiciel.
Le Résultat : Le système a trouvé des tickets et des changements de code anciens liés à des gels similaires. Il a dit aux développeurs : « Cela ressemble au problème que nous avons eu auparavant. Voici le correctif de code que nous avons utilisé à l'époque. »
L'Issue :
- Vitesse : Le temps nécessaire pour corriger un bug est passé de 18,5 heures à 10,2 heures (une amélioration de 45 %).
- Confiance : Environ 68 % du temps, les développeurs acceptent la suggestion de l'IA directement ou avec une modification mineure.
- Précision : Le système était très efficace pour trouver les bons cas passés (82 % du temps, la bonne réponse figurait dans les 5 premiers résultats).

4. Pourquoi c'est important

Le document souligne que ce n'est pas seulement une question de rapidité ; c'est aussi une question de ne pas inventer de fausses informations.

Pas d'Hallucinations : Parce que l'IA est contrainte de s'appuyer sur des preuves historiques réelles (les anciens tickets et le code) avant de rédiger une solution, elle est beaucoup moins susceptible d'inventer de faux correctifs. C'est comme un étudiant qui doit citer son manuel avant de répondre à un examen.
Réutilisation des Connaissances : Cela empêche les entreprises de perdre leur « mémoire institutionnelle ». Lorsqu'un développeur senior part, ses connaissances ne sont pas perdues ; elles sont verrouillées dans le système pour que tout le monde puisse les utiliser.

5. Le revers de la médaille (Limites)

Les auteurs sont honnêtes quant aux défis :

Vieilles Erreurs : Si les anciens tickets contenaient de mauvais conseils, le système pourrait répéter ces erreurs.
Changement de Langages : Si la technologie logicielle change radicalement (comme une nouvelle version de React), les anciens « modèles de sens » pourraient devenir moins précis, nécessant un réentraînement du système.
Coût : Faire fonctionner ce système nécessite des ordinateurs puissants pour effectuer des recherches instantanées parmi des millions d'enregistrements.

Résumé

En bref, RAG4Tickets est un outil qui relie les points entre les problèmes passés et les solutions actuelles. Il transforme un tas chaotique de rapports de bugs en une base de connaissances intelligente et interrogeable qui aide les développeurs à résoudre les problèmes plus rapidement, avec moins de frustration, et avec la certitude qu'ils s'appuient sur des correctifs éprouvés et réels.

Résumé Technique : RAG4Tickets – Résolution de Tickets par IA via la Génération Augmentée par Récupération

1. Énoncé du Problème

Les équipes de développement logiciel modernes font face à des retards importants dans la résolution d'incidents récurrents en raison de la fragmentation des connaissances éparpillées entre les tickets JIRA, les discussions des développeurs et les pull requests (PR) GitHub. À mesure que les projets passent à l'échelle, la croissance exponentielle des tickets et des changements de code entraîne une surcharge d'informations. Les développeurs peinent souvent à localiser des résolutions passées pour des problèmes sémantiquement similaires mais linguistiquement distincts (par exemple, faire correspondre « UI crash » avec « application freeze »). Les approches traditionnelles d'apprentissage supervisé pour la classification de bugs échouent souvent à capturer la variabilité sémantique inhérente aux rapports de bugs réels, ce qui entraîne des inefficacités dans le triage et la résolution.

2. Méthodologie

Le document propose RAG4Tickets, un cadre de Génération Augmentée par Récupération (RAG) conçu pour unifier les artefacts logiciels hétérogènes dans un pipeline de résolution sensible au contexte. Le système opère à travers quatre couches principales :

Ingestion et Prétraitement des Données : Le système ingère des données structurées de JIRA (titres, descriptions, statut, commentaires) et de GitHub (PR, messages de commit, diffs, commentaires de revue). Le prétraitement implique la normalisation du texte, la suppression du texte superflu (boilerplate) et l'utilisation de parseurs d'Arbre de Syntaxe Abstraite (AST) pour résumer les diffs de code au niveau de la fonction afin de réduire le bruit.
Couche d'Embedding : Les artefacts hétérogènes sont convertis en représentations vectorielles denses. Le cadre utilise des Sentence-Transformers (spécifiquement all-MiniLM-L6-v2 et multi-qa-MPNet-base-dot-v1) pour les données textuelles (tickets, commentaires). Pour les données spécifiques au code (diffs de PR), il emploie une stratégie hybride incorporant CodeBERT et GraphCodeBERT pour capturer les dépendances structurelles et la sémantique de programmation. Les embeddings sont partitionnés par type d'artefact pour permettre une recherche ciblée.
Couche de Récupération (Retrieval) : Tous les embeddings sont indexés à l'aide de FAISS (Facebook AI Similarity Search) pour effectuer une recherche de plus proches voisins approximatifs (ANN). Le système évalue différentes structures d'index (Flat, IVF, HNSW) et sélectionne HNSW pour son équilibre optimal entre vitesse et rappel dans des jeux de données à l'échelle de l'entreprise (millions de vecteurs). Lorsqu'un nouveau ticket est reçu, le système l'encode et récupère les $k$ meilleurs tickets, commentaires et PR historiquement similaires.
Couche de Génération : Les preuves récupérées sont synthétisées dans un prompt structuré pour un Grand Modèle de Langage (LLM). Le LLM génère des suggestions de résolution fondées, incluant des plans étape par étape, des hyperliens vers les PR/commits pertinents et des scores de confiance. Cette couche est conçue pour minimiser les hallucinations en se fondant strictement sur les preuves récupérées.

Intégration du Déploiement : Le cadre est modulaire, permettant une intégration via des plugins JIRA (pour les commentaires de triage automatisés), des GitHub Actions (pour faire remonter les problèmes liés aux PR) et des pipelines CI/CD (pour le triage automatique des échecs de tests récurrents).

3. Contributions Clés

Le document souligne cinq contributions principales :

Architecture Unifiée : Un pipeline qui ingère et lie les données JIRA et GitHub, établissant des connexions explicites entre les tickets et les changements de code.
Stratégie d'Embedding Spécialisée : Une approche sur mesure pour les artefacts hétérogènes, combinant des embeddings textuels sémantiques avec des embeddings conscients du code (CodeBERT) pour capturer à la fois le langage naturel et les similitudes structurelles du code.
Pipeline de Décision Guidé par les Preuves : Un flux de travail RAG où les preuves historiques récupérées guident directement les suggestions de résolution générées par le LLM, assurant la traçabilité.
Évaluation Complète : Une évaluation utilisant à la fois des métriques de recherche d'information (IR) (Recall@k, Mean Reciprocal Rank) et des mesures de productivité des développeurs (temps de résolution, taux d'acceptation).
Étude de Cas Pratique : Un scénario de déploiement réel impliquant une migration de microservice React 19, démontrant la capacité du système à gérer les problèmes récurrents liés aux méthodes de cycle de vie dépréciées et à la gestion d'état.

4. Résultats Expérimentaux

Le système a été évalué sur un ensemble de données comprenant environ 15 000 tickets JIRA et 6 500 PR GitHub provenant d'un projet de migration de grande envergure vers React 19.

Performance de Récupération : En utilisant l'index HNSW, le système a atteint un Recall@5 de 82 % et un Recall@10 de 91 %, avec un Mean Reciprocal Rank (MRR) de 0,78. Cela indique que les résolutions historiques pertinentes se trouvent généralement dans les cinq premiers résultats.
Qualité de Génération : Sur un ensemble de test de 500 problèmes inédits, les solutions générées ont obtenu un score BLEU de 0,47 et un ROUGE-L de 0,62. Crucialement, le score de cohérence factuelle était de 84 %, démontrant que le LLM respectait largement les preuves récupérées, minimisant ainsi les hallucinations.
Impact Métier : Dans un déploiement auprès de trois équipes agiles, le système a produit les améliorations suivantes :
- Temps de Résolution : Réduit d'une moyenne de 18,5 heures à 10,2 heures (une amélioration de 45 %).
- Taux d'Acceptation : Les développeurs adoptent ou modifient légèrement les résolutions suggérées par l'IA 68 % du temps.
- Productivité : Les développeurs ont rapporté une augmentation de la productivité auto-déclarée de 32 %, attribuée à la réduction du temps passé sur le triage répétitif et la recherche manuelle.

5. Signification et Limites

Le document soutient que RAG4Tickets démontre comment les flux de travail DevOps augmentés par l'IA peuvent atténuer la surcharge cognitive et améliorer la réutilisation des connaissances organisationnelles. En comblant le fossé entre les données historiques non structurées et la résolution automatisée, le cadre offre une voie évolutive vers des environnements d'ingénierie sensibles au contexte.

Cependant, les auteurs maintiennent une position modeste concernant les limites actuelles :

Risque d'Hallucination : Bien que l'ancrage factuel soit élevé (84 %), des hallucinations occasionnelles surviennent lorsque le LLM extrapole au-delà des preuves récupérées.
Biais de Données et Dérive (Drift) : Le système risque de propager des modèles sous-optimaux issus de données héritées et peut souffrir d'une dérive sémantique à mesure que les frameworks évoluent (ex: de React 18 à 19).
Coûts Opérationnels : L'indexation de grands dépôts et l'inférence fréquente du LLM introduisent des surcoûts de calcul et de latence.

Le document conclut que bien que le système montre un fort potentiel pour automatiser la maintenance logicielle, le succès à long terme dépend de l'atténuation des risques d'hallucination par la vérification de la récupération, de la garantie de l'adaptabilité du modèle aux technologies évolutives et du maintien de la transparence pour instaurer la confiance des développeurs. Des travaux futurs sont proposés, incluant des couches de vérification de la récupération, l'apprentissage par renforcement avec feedback humain (RLHF) et des architectures de récupération hybrides combinant recherche dense et parcimonieuse (sparse).