🤖 AI

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

Het artikel stelt RAG4Tickets voor, een door AI aangedreven framework dat JIRA- en GitHub-gegevens integreert met behulp van Retrieval-Augmented Generation om contextbewuste, op bewijs gebaseerde aanbevelingen voor ticketresolutie te leveren, wat de nauwkeurigheid en efficiëntie in softwareontwikkelingsworkflows aanzienlijk verbetert.

Oorspronkelijke auteurs: Mohammad Baqar

Gepubliceerd 2026-02-06

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Mohammad Baqar

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een softwareontwikkelaar bent die werkt aan een enorm project. Elke keer als er een bug opduikt, is het alsof er een nieuwe detectivezaak is. In het verleden was het oplossen van deze zaken als het zoeken naar een naald in een hooiberg die bestond uit miljoenen andere naalden. Je moest door oude JIRA-tickets (bugrapporten) graven, duizenden reacties van ontwikkelaars lezen en door GitHub-codewijzigingen scannen om te zien of iemand anders het probleem al had opgelost. Vaak, zelfs als het probleem hetzelfde was, waren de woorden die gebruikt werden om het te beschrijven anders, waardoor je de oplossing miste en urenlang het wiel opnieuw uitvond.

Dit artikel, "RAG4Tickets," stelt een slimme assistent voor die fungeert als een combinatie van een superkrachtige bibliothecaris en een detective om dit probleem op te lossen. Zo werkt het, onderverdeeld in eenvoudige stappen:

1. Het Probleem: De "Lost in Translation" Bibliotheek

Beschouw de geschiedenis van de bugs en fixes van je bedrijf als een gigantische, chaotische bibliotheek.

Het Probleem: Een ontwikkelaar schrijft een ticket met: "De app bevriest wanneer ik op de knop klik." Een andere ontwikkelaar van twee jaar geleden schreef een ticket met: "Het scherm blokkeert tijdens gebruikersinteractie." Hoewel dit hetzelfde probleem is, kan een eenvoudige zoekopdracht op trefwoorden de verbinding missen.
Het Resultaat: Ontwikkelaars besteden te veel tijd aan zoeken en te weinig aan oplossen.

2. De Oplossing: De "Slimme Bibliothecaris" (RAG)

De auteurs hebben een systeem gebouwd genaamd RAG4Tickets. Zie dit systeem als een hoogopgeleide bibliothecaris die niet alleen de titels van boeken leest, maar ook de betekenis erachter begrijpt.

Stap 1: Lezen en Begrijpen (Embeddings):
Het systeem leest elk oud bugrapport, elke reactie en elke codewijziging (Pull Request). Het gebruikt een speciaal hulpmiddel genaamd Sentence-Transformers om deze woorden om te zetten in "betekenis-kaarten" (vectoren). In plaats van alleen te zoeken naar het woord "crash", begrijpt het dat "bevriezen", "blokkeren" en "hangen" allemaal naar hetzelfde concept wijzen.
Stap 2: De Super-Snel Zoeken (FAISS):
Zodra het systeem deze betekenis-kaarten heeft, slaat het ze op in een enorme, razendsnelle index genaamd FAISS. Stel je dit voor als een magische kaart waar vergelijkbare ideeën fysiek vlak naast elkaar liggen. Wanneer er een nieuwe bug binnenkomt, vindt het systeem direct de top 5 of 10 meest vergelijkbare eerdere gevallen, zelfs als de bewoording totaal anders is.
Stap 3: Het Rapport van de Detective (LLM Generatie):
Het systeem laat je niet alleen de oude tickets zien; het fungeert als een detective die de zaak samenvat. Het neemt de oude oplossingen die het heeft gevonden en voert deze aan een Large Language Model (AI). De AI schrijft vervolgens een duidelijke, stapsgewijze handleiding over hoe de nieuwe bug opgelost moet worden, waarbij precies wordt aangegeven welke oude codewijzigingen het oplosten. Het is alsof een senior engineer in je oor fluistert: "Hé, dit hebben we vorig jaar precies zo opgelost; hier is de code die we toen gebruikten."

3. Hoe het werkt in de praktijk

De auteurs testten dit systeem tijdens een grote upgrade van een webapplicatie (de overstap van React 18 naar React 19).

Het Scenario: Ontwikkelaars worstelden met een specifiek type "UI-freeze" veroorzaakt door de nieuwe softwareversie.
Het Resultaat: Het systeem vond oude tickets en codewijzigingen die gerelateerd waren aan soortgelijke freezes. Het vertelde de ontwikkelaars: "Dit lijkt op het probleem dat we eerder hadden. Hier is de code-fix die we toen gebruikten."
De Uitkomst:
- Snelheid: De tijd die nodig was om een bug op te lossen daalde van 18,5 uur naar 10,2 uur (een verbetering van 45%).
- Vertrouwen: In ongeveer 68% van de gevallen accepteerden ontwikkelaars de suggestie van de AI direct of met slechts een kleine aanpassing.
- Nauwkeurigheid: Het systeem was erg goed in het vinden van de juiste eerdere gevallen (82% van de tijd stond het juiste antwoord in de top 5 resultaten).

4. Waarom dit belangrijk is

Het artikel benadrukt dat dit niet alleen gaat over sneller zijn; het gaat over niet dingen verzinnen.

Geen Hallucinaties: Omdat de AI wordt gedwongen om naar echt, historisch bewijs te kijken (de oude tickets en de code) voordat hij een oplossing schrijft, is de kans veel kleiner dat hij nep-fixes verzint. Het is als een student die eerst uit zijn tekstboek moet citeren voordat hij een vraag beantwoordt.
Kennishergebruik: Het voorkomt dat bedrijven hun "institutionele geheugen" verliezen. Wanneer een senior ontwikkelaar vertrekt, gaat zijn kennis niet verloren; die zit vergrendeld in het systeem voor iedereen om te gebruiken.

5. De Keerzijde (Beperkingen)

De auteurs zijn eerlijk over de uitdagingen:

Oude Fouten: Als de oude tickets slecht advies bevatten, kan het systeem die fouten herhalen.
Veranderende Talen: Als de softwaretechnologie drastisch verandert (zoals een nieuwe versie van React), kunnen de oude "betekenis-kaarten" minder accuraat worden, wat vereist dat het systeem opnieuw getraind wordt.
Kosten: Het draaien van dit systeem vereist krachtige computers om miljoenen records direct te doorzoeken.

Samenvatting

Kortom, RAG4Tickets is een tool die de lijnen verbindt tussen problemen uit het verleden en oplossingen van nu. Het verandert een chaotische stapel bugrapporten in een slimme, doorzoekbare kennisbank die ontwikkelaars helpt problemen sneller op te lossen, met minder frustratie en met het vertrouwen dat ze bouwen op bewezen, real-world fixes.

Technische Samenvatting: RAG4Tickets – AI-gestuurde ticketresolutie via Retrieval-Augmented Generation

1. Probleemstelling

Moderne softwareontwikkelingsteams worden geconfronteerd met aanzienlijke vertragingen bij het oplossen van terugkerende problemen door gefragmenteerde kennis die verspreid is over JIRA-tickets, discussies tussen ontwikkelaars en GitHub pull requests (PR's). Naarmate projecten schalen, leidt de exponentiële groei van tickets en codewijzigingen tot informatieoverbelasting. Ontwikkelaars hebben vaak moeite om oplossingen uit het verleden te lokaliseren voor semantisch vergelijkbare maar taalkundig verschillende problemen (bijv. het matchen van "UI crash" met "application freeze"). Traditionele supervised machine learning-benaderingen voor bugclassificatie slagen er vaak niet in de semantische variabiliteit te vangen die inherent is aan real-world bugrapporten, wat leidt tot inefficiënties in de triage en resolutie.

2. Methodologie

Het paper stelt RAG4Tickets voor, een Retrieval-Augmented Generation (RAG) framework ontworpen om heterogene software-artefacten te verenigen in een contextbewuste resolutie-pipeline. Het systeem werkt via vier primaire lagen:

Data Ingestie & Preprocessing: Het systeem importeert gestructureerde data uit JIRA (titels, beschrijvingen, status, commentaren) en GitHub (PR's, commit berichten, diffs, review commentaren). Preprocessing omvat het normaliseren van tekst, het verwijderen van boilerplate en het gebruik van Abstract Syntax Tree (AST) parsers om code-diffs op functieniveau samen te vatten om ruis te verminderen.
Embedding Laag: Heterogene artefacten worden omgezet in dichte vectorrepresentaties. Het framework maakt gebruik van Sentence-Transformers (specifiek all-MiniLM-L6-v2 en multi-qa-MPNet-base-dot-v1) voor tekstuele data (tickets, commentaren). Voor code-specifieke data (PR diffs) hanteert het een hybride strategie die CodeBERT en GraphCodeBERT combineert om structurele afhankelijkheden en programmeersemantiek te vangen. Embeddings worden gepartitioneerd per type artefact om gerichte zoekopdrachten mogelijk te maken.
Retrieval Laag: Alle embeddings worden geïndexeerd met behulp van FAISS (Facebook AI Similarity Search) om een Approximate Nearest Neighbor (ANN) zoekopdracht uit te voeren. Het systeem evalueert verschillende indexstructuren (Flat, IVF, HNSW) en selecteert HNSW vanwege de optimale balans tussen snelheid en recall in enterprise-schaal datasets (miljoenen vectoren). Bij ontvangst van een nieuw ticket codeert het systeem dit en zoekt het de top- $k$ semantisch vergelijkbare historische tickets, commentaren en PR's op.
Generatie Laag: De opgehaalde bewijslast wordt gesynthetiseerd in een gestructureerde prompt voor een Large Language Model (LLM). De LLM genereert gegronde resolutievoorstellen, inclusief stapsgewijze plannen, hyperlinks naar relevante PR's/commits en betrouwbaarheidsscores. Deze laag is ontworpen om hallucinaties te minimaliseren door de output strikt te funderen in het opgehaalde bewijs.

Deployment Integratie: Het framework is modulair en maakt integratie mogelijk via JIRA-plugins (voor automatische triage-commentaren), GitHub Actions (voor het signaleren van gerelateerde issues bij PR's) en CI/CD-pipelines (voor het automatisch triageren van terugkerende testfouten).

3. Belangrijkste Bijdragen

Het paper schetst vijf primaire bijdragen:

Verenigde Architectuur: Een pipeline die JIRA- en GitHub-data importeert en koppelt, waardoor expliciete verbindingen tussen tickets en codewijzigingen worden gelegd.
Gespecialiseerde Embedding Strategie: Een op maat gemaakte aanpak voor heterogene artefacten, waarbij semantische tekst-embeddings worden gecombineerd met code-bewuste embeddings (CodeBERT) om zowel natuurlijke taal als structurele code-overeenkomsten te vangen.
Bewijs-gestuurd Beslissingsproces: Een RAG-workflow waarbij opgehaald historisch bewijs direct de door de LLM gegenereerde resolutievoorstellen stuurt, wat traceerbaarheid garandeert.
Uitgebreide Evaluatie: Een beoordeling met zowel Information Retrieval (IR) metrieken (Recall@k, Mean Reciprocal Rank) als productiviteitsmetingen voor ontwikkelaars (tijd-tot-resolutie, acceptatiepercentages).
Praktische Casestudy: Een real-world deployment scenario betrokken bij een React 19 microservice migratie, die de capaciteit van het systeem demonstreert om terugkerende problemen gerelateerd aan deprecated lifecycle methoden en state management af te handelen.

4. Experimentele Resultaten

Het systeem werd geëvalueerd op een dataset bestaande uit ongeveer 15.000 JIRA tickets en 6.500 GitHub PR's van een grootschalig React 19 migratieproject.

Retrieval Prestaties: Met behulp van de HNSW-index bereikte het systeem een Recall@5 van 82% en een Recall@10 van 91%, met een Mean Reciprocal Rank (MRR) van 0,78. Dit geeft aan dat relevante historische resoluties doorgaans binnen de top vijf resultaten worden gevonden.
Generatie Kwaliteit: Op een testset van 500 ongeziene issues bereikten de gegenereerde oplossingen een BLEU-score van 0,47 en een ROUGE-L van 0,62. Cruciaal is dat de feitelijke consistentiescore 84% was, wat aantoont dat de LLM grotendeels vasthield aan het opgehaalde bewijs, waardoor hallucinaties werden geminimaliseerd.
Zakelijke Impact: In een deployment over drie agile teams leverde het systeem de volgende verbeteringen op:
- Resolutie Tijd: Verminderd van een gemiddelde van 18,5 uur naar 10,2 uur (een verbetering van 45%).
- Acceptatie Ratio: Ontwikkelaars namen de door AI voorgestelde resoluties direct over of bewerkten deze licht in 68% van de gevallen.
- Productiviteit: Ontwikkelaars rapporteerden een zelfgerapporteerde productiviteitsstijging van 32%, toe te schrijven aan minder tijd besteed aan repetitieve triage en handmatig zoeken.

5. Betekenis en Beperkingen

Het paper stelt dat RAG4Tickets aantoont hoe AI-geaugmenteerde DevOps-workflows cognitieve overbelasting kunnen verminderen en kennishergebruik binnen organisaties kunnen verbeteren. Door de kloof tussen ongestructureerde historische data en geautomatiseerde resolutie te overbruggen, biedt het framework een schaalbaar pad naar contextbewuste engineering-omgevingen.

De auteurs hanteren echter een bescheiden standpunt met betrekking tot de huidige beperkingen:

Risico op Hallucinaties: Hoewel de feitelijke gronding hoog is (84%), komen er incidenteel hallucinaties voor wanneer de LLM extrapoleert buiten het opgehaalde bewijs.
Data Bias en Drift: Het systeem loopt het risico suboptimale patronen uit legacy-data te propageren en kan last krijgen van semantische drift naarmate frameworks evolueren (bijv. van React 18 naar 19).
Operationele Kosten: Het indexeren van grote repositories en frequente LLM-inferentie introduceren compute- en latency-overhead.

Het paper concludeert dat hoewel het systeem een sterk potentieel toont voor het automatiseren van softwareonderhoud, langetermijnsucces afhangt van het mitigeren van hallucinatie-risico's door middel van retrieval-verificatie, het waarborgen van model-adaptiviteit aan evoluerende technologieën, en het handhaven van transparantie om het vertrouwen van ontwikkelaars te winnen. Toekomstig werk richt zich op het toevoegen van retrieval-verificatielagen, reinforcement learning met menselijke feedback (RLHF) en hybride retrieval-architecturen die dense en sparse search methoden combineren.