🤖 AI

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

El artículo propone RAG4Tickets, un marco de trabajo impulsado por IA que integra datos de JIRA y GitHub mediante la Generación Aumentada por Recuperación para ofrecer recomendaciones de resolución de tickets con conciencia de contexto y basadas en evidencia, mejorando significativamente la precisión y la eficiencia en los flujos de trabajo de desarrollo de software.

Autores originales: Mohammad Baqar

Publicado 2026-02-06

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Mohammad Baqar

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un desarrollador de software trabajando en un proyecto masivo. Cada vez que aparece un error, es como un nuevo caso detectivesco. En el pasado, resolver estos casos era como buscar una aguja en un pajar hecho de millones de otras agujas. Tenías que excavar entre viejos tickets de JIRA (reportes de errores), leer miles de comentarios de desarrolladores y escanear cambios de código en GitHub para ver si alguien más ya había resuelto un problema similar. A menudo, incluso si el problema era el mismo, las palabras utilizadas para describirlo eran diferentes, por lo que perdías la conexión y desperdiciabas horas reinventando la rueda.

Este artículo, "RAG4Tickets", propone un asistente inteligente que actúa como una combinación de bibliotecario y detective superpotenciado para solucionar este problema. Así es como funciona, desglosado en pasos sencillos:

1. El Problema: La biblioteca "Perdida en la Traducción"

Piensa en el historial de errores y correcciones de tu empresa como una biblioteca gigante y caótica.

El Problema: Un desarrollador escribe un ticket que dice: "La aplicación se congela cuando hago clic en el botón". Otro desarrollador hace dos años escribió un ticket que decía: "La pantalla se bloquea durante la interacción del usuario". Aunque estos son el mismo problema, una búsqueda simple por palabras clave podría perder la conexión.
El Resultado: Los desarrolladores pasan demasiado tiempo buscando y no tanto tiempo arreglando.

2. La Solución: El "Bibliotecario Inteligente" (RAG)

Los autores construyeron un sistema llamado RAG4Tickets. Piensa en este sistema como un bibliotecario altamente capacitado que no solo lee los títulos de los libros, sino que entiende el significado detrás de ellos.

Paso 1: Leer y Comprender (Embeddings):
El sistema lee cada reporte de error, comentario y cambio de código (Pull Request) antiguo. Utiliza una herramienta especial llamada Sentence-Transformers para convertir estas palabras en "mapas de significado" (vectores). En lugar de solo buscar la palabra "crash" (caída), entiende que "freeze" (congelar), "lock up" (bloquear) y "hang" (colgarse) apuntan al mismo concepto.
Paso 2: La Búsqueda Superrápida (FAISS):
Una vez que el sistema tiene estos mapas de significado, los almacena en un índice masivo y ultra rápido llamado FAISS. Imagina esto como un mapa mágico donde las ideas similares están ubicadas físicamente una al lado de la otra. Cuando llega un nuevo error, el sistema encuentra instantáneamente los 5 o 10 casos pasados más similares, incluso si la redacción es totalmente distinta.
Paso 3: El Informe del Detective (Generación de LLM):
El sistema no solo te muestra los tickets antiguos; actúa como un detective que resume el caso. Toma las soluciones antiguas que encontró y las alimenta a un Modelo de Lenguaje Extenso (IA). La IA luego escribe una guía clara, paso a paso, sobre cómo arreglar el nuevo error, citando exactamente qué cambios de código antiguos lo resolvieron. Es como tener a un ingeniero sénior susurrándote: "Oye, arreglamos esto mismo el año pasado; aquí está el código que usamos".

3. Cómo Funciona en la Vida Real

Los autores probaron este sistema durante una actualización importante de una aplicación web (pasando de React 18 a React 19).

El Escenario: Los desarrolladores estaban luchando con un tipo específico de "congelamiento de la interfaz de usuario (UI)" causado por la nueva versión del software.
El Resultado: El sistema encontró tickets y cambios de código antiguos relacionados con congelamientos similares. Les dijo a los desarrolladores: "Esto parece el problema que tuvimos antes. Aquí está el arreglo de código que usamos entonces".
El Resultado Final:
- Velocidad: El tiempo para arreglar un error cayó de 18.5 horas a 10.2 horas (una mejora del 45%).
- Confianza: Aproximadamente el 68% de las veces, los desarrolladores aceptaron la sugerencia de la IA directamente o con solo una pequeña edición.
- Precisión: El sistema fue muy bueno encontrando los casos pasados correctos (el 82% de las veces, la respuesta correcta estaba en los 5 resultados principales).

4. Por Qué Esto Importa

El artículo destaca que esto no se trata solo de ser más rápidos; se trata de no inventar cosas.

Sin Alucinaciones: Debido a que la IA se ve obligada a mirar evidencia real e histórica (los tickets y el código antiguos) antes de escribir una solución, es mucho menos probable que invente arreglos falsos. Es como un estudiante que debe citar su libro de texto antes de responder un examen.
Reutilización del Conocimiento: Evita que las empresas pierdan su "memoria institucional". Cuando un desarrollador sénior se va, su conocimiento no se pierde; queda guardado en el sistema para que todos puedan usarlo.

5. El Problema (Limitaciones)

Los autores son honestos sobre los desafíos:

Errores Antiguos: Si los tickets antiguos contenían malos consejos, el sistema podría repetir esos mismos errores.
Cambios de Lenguaje: Si la tecnología del software cambia drásticamente (como una nueva versión de React), los antiguos "mapas de significado" podrían volverse menos precisos, requiriendo que el sistema sea reentrenado.
Costo: Ejecutar este sistema requiere computadoras potentes para buscar a través de millones de registros instantáneamente.

Resumen

En resumen, RAG4Tickets es una herramienta que conecta los puntos entre problemas pasados y soluciones actuales. Convierte una pila caótica de reportes de errores en una base de conocimientos inteligente y buscable que ayuda a los desarrolladores a resolver problemas más rápido, con menos frustración y con la confianza de que están construyendo sobre arreglos reales y probados.

Resumen Técnico: RAG4Tickets – Resolución de Tickets Impulsada por IA mediante Generación Aumentada por Recuperación

1. Planteamiento del Problema

Los equipos modernos de desarrollo de software enfrentan retrasos significativos en la resolución de problemas recurrentes debido a la fragmentación del conocimiento disperso en tickets de JIRA, discusiones de desarrolladores y pull requests (PRs) de GitHub. A medida que los proyectos escalan, el crecimiento exponencial de tickets y cambios de código conduce a una sobrecarga de información. Los desarrolladores suelen tener dificultades para localizar resoluciones pasadas para problemas semánticamente similares pero lingüísticamente distintos (por ejemplo, emparejar "UI crash" con "application freeze"). Los enfoques tradicionales de aprendizaje supervisado para la clasificación de errores suelen fallar al no capturar la variabilidad semántica inherente en los reportes de errores del mundo real, lo que genera ineficiencias en el triaje y la resolución.

2. Metodología

El artículo propone RAG4Tickets, un marco de trabajo de Generación Aumentada por Recuperación (RAG) diseñado para unificar artefactos de software heterogéneos en un flujo de resolución consciente del contexto. El sistema opera a través de cuatro capas principales:

Ingesta de Datos y Preprocesamiento: El sistema ingiere datos estructurados de JIRA (títulos, descripciones, estado, comentarios) y GitHub (PRs, mensajes de commit, diffs, comentarios de revisión). El preprocesamiento implica la normalización de texto, la eliminación de código redundante (boilerplate) y el uso de analizadores de Árbol de Sintaxis Abstracta (AST) para resumir los diffs de código a nivel de función para reducir el ruido.
Capa de Embedding: Los artefactos heterogéneos se convierten en representaciones vectoriales densas. El marco utiliza Sentence-Transformers (específicamente all-MiniLM-L6-v2 y multi-qa-MPNet-base-dot-v1) para datos textuales (tickets, comentarios). Para los datos específicos de código (diffs de PR), emplea una estrategia híbrida que incorpora CodeBERT y GraphCodeBERT para capturar dependencias estructurales y semántica de programación. Los embeddings se particionan por tipo de artefacto para permitir una búsqueda dirigida.
Capa de Recuperación: Todos los embeddings se indexan utilizando FAISS (Facebook AI Similarity Search) para realizar una búsqueda de Vecino Más Cercano Aproximado (ANN). El sistema evalúa diferentes estructuras de índice (Flat, IVF, HNSW) y selecciona HNSW por su equilibrio óptimo entre velocidad y recuperación (recall) en conjuntos de datos de escala empresarial (millones de vectores). Al recibir un nuevo ticket, el sistema lo codifica y recupera los $k$ mejores tickets, comentarios y PRs históricamente similares.
Capa de Generación: La evidencia recuperada se sintetiza en un prompt estructurado para un Modelo de Lenguaje Grande (LLM). El LLM genera sugerencias de resolución fundamentadas, incluyendo planes paso a paso, hipervínculos a los PRs/commits relevantes y puntuaciones de confianza. Esta capa está diseñada para minimizar las alucinaciones al basarse estrictamente en la evidencia recuperada.

Integración de Despliegue: El marco es modular, lo que permite la integración mediante plugins de JIRA (para comentarios de triaje automatizados), GitHub Actions (para la detección de problemas vinculados a PRs) y pipelines de CI/CD (para el triaje automático de fallos de prueba recurrentes).

3. Contribuciones Clave

El artículo describe cinco contribuciones principales:

Arquitectura Unificada: Un flujo de trabajo que ingiere y vincula datos de JIRA y GitHub, estableciendo conexiones explícitas entre tickets y cambios de código.
Estrategia de Embedding Especializada: Un enfoque adaptado para artefactos heterogéneos, combinando embeddings de texto semántico con embeddings conscientes del código (CodeBERT) para capturar tanto la similitud de lenguaje natural como la estructural del código.
Pipeline de Decisión Guiado por Evidencia: Un flujo de trabajo RAG donde la evidencia histórica recuperada guía directamente las sugerencias de resolución generadas por el LLM, asegurando la trazabilidad.
Evaluación Exhaustiva: Una evaluación utilizando tanto métricas de Recuperación de Información (IR) (Recall@k, Mean Reciprocal Rank) como medidas de productividad del desarrollador (tiempo de resolución, tasas de aceptación).
Caso de Estudio Práctico: Un escenario de despliegue real que involucra una migración de microservicios a React 19, demostrando la capacidad del sistema para manejar problemas recurrentes relacionados con métodos de ciclo de vida obsoletos y gestión de estado.

4. Resultados Experimentales

El sistema fue evaluado en un conjunto de datos que comprende aproximadamente 15,000 tickets de JIRA y 6,500 PRs de GitHub de un proyecto de migración a React 19 a gran escala.

Rendimiento de Recuperación: Utilizando el índice HNSW, el sistema logró un Recall@5 del 82% y un Recall@10 del 91%, con un Mean Reciprocal Rank (MRR) de 0.78. Esto indica que las resoluciones históricas relevantes se encuentran típicamente dentro de los cinco mejores resultados.
Calidad de Generación: En un conjunto de prueba de 500 problemas no vistos, las soluciones generadas alcanzaron un puntaje BLEU de 0.47 y un ROUGE-L de 0.62. Crucialmente, el puntaje de consistencia fáctica fue del 84%, demostrando que el LLM se adhirió en gran medida a la evidencia recuperada, minimizando así las alucinaciones.
Impacto en el Negocio: En un despliegue a través de tres equipos ágiles, el sistema produjo las siguientes mejoras:
- Tiempo de Resolución: Reducción de un promedio de 18.5 horas a 10.2 horas (una mejora del 45%).
- Tasa de Aceptación: Los desarrolladores adoptaron directamente o editaron ligeramente las resoluciones sugeridas por la IA el 68% de las veces.
- Productividad: Los desarrolladores reportaron un incremento de productividad auto-reportado del 32%, atribuido a la reducción del tiempo dedicado al triaje repetitivo y la búsqueda manual.

5. Significación y Limitaciones

El artículo postula que RAG4Tickets demuestra cómo los flujos de trabajo de DevOps aumentados por IA pueden mitigar la sobrecarga cognitiva y mejorar la reutilización del conocimiento organizacional. Al cerrar la brecha entre los datos históricos no estructurados y la resolución automatizada, el marco ofrece un camino escalable hacia entornos de ingeniería conscientes del contexto.

Sin embargo, los autores mantienen una postura modesta respecto a las limitaciones actuales:

Riesgo de Alucinación: Aunque la fundamentación fáctica es alta (84%), ocurren alucinaciones ocasionales cuando el LLM extrapola más allá de la evidencia recuperada.
Sesgo de Datos y Deriva (Drift): El sistema corre el riesgo de propagar patrones subóptimos de datos heredados y puede sufrir de deriva semántica a medida que los frameworks evolucionan (por ejemplo, de React 18 a 19).
Costos Operativos: El indexado de grandes repositorios y la inferencia frecuente de LLM introducen sobrecargas de cómputo y latencia.

El artículo concluye que, si bien el sistema muestra un fuerte potencial para automatizar el mantenimiento de software, el éxito a largo plazo depende de mitigar los riesgos de alucinación mediante la verificación de la recuperación, asegurar la adaptabilidad del modelo a tecnologías en evolución y mantener la transparencia para generar confianza en los desarrolladores. Se propone como trabajo futuro incluir capas de verificación de recuperación, aprendizaje por refuerzo con retroalimentación humana (RLHF) y arquitecturas de recuperación híbridas que combinen búsqueda densa y dispersa.