Automated Root-Cause Subclassification and No-Code Fix Generation for Invalid Bug Reports

Resumen Técnico: Subclasificación Automatizada de la Causa Raíz y Generación de Soluciones Sin Código para Informes de Errores Inválidos

Planteamiento del Problema
El mantenimiento de software incurre en costos significativos, con una parte sustancial de los informes de errores siendo "inválidos", lo que significa que no requieren modificaciones en el código fuente. Estos informes a menudo surgen de malentendidos del usuario, errores de configuración, dependencias externas o solicitudes de nuevas funcionalidades. Actualmente, los equipos de soporte al cliente clasifican manualmente estos informes para identificar las causas raíz y proporcionar "soluciones sin código" (orientación accionable sin cambios en el código). Este proceso manual consume muchos recursos, retrasa la resolución y deja a los usuarios inciertos sobre cómo resolver sus problemas. Si bien investigaciones anteriores han abordado la detección de errores inválidos o el análisis de la causa raíz, ningún estudio ha automatizado simultáneamente la subclasificación de la causa raíz de informes inválidos y la generación de soluciones accionables sin código.

Metodología
Los autores proponen IssueSupport, un marco automatizado diseñado para subclasificar informes de errores inválidos por causa raíz y generar las correspondientes soluciones sin código. El estudio utiliza una nueva referencia de evaluación curada manualmente derivada del repositorio de GitHub del Navegador Brave, que contiene 302 informes de errores inválidos de alta calidad y anotados con subclases de verdad fundamental y soluciones sin código exitosas o fallidas.

El marco evalúa cuatro configuraciones experimentales distintas para abordar preguntas de investigación específicas:

1. Pipeline LLM Vanilla: Prompts de cero disparos (zero-shot) a modelos de lenguaje grandes (LLM) propietarios (Gemini 3.1 Pro, GPT-5.4, Claude Opus 4.6) y de código abierto (GLM-5, MiniMax M2.7, Kimi 2.5) para clasificar y generar soluciones.
2. Sin Información Previa (Ablación): Una configuración donde se solicita al LLM sin la taxonomía específica de subclases inválidas ni directrices de solución para medir el impacto del conocimiento previo.
3. Generación Aumentada por Recuperación (RAG): El LLM se potencia con un proceso de recuperación de dos etapas (búsqueda de vectores densos seguida de reordenamiento con codificador cruzado) utilizando informes de errores históricos y documentación oficial de la wiki del proyecto.
4. Búsqueda Web Agente: Un pipeline basado en agentes (inspirado en WebThinker) que realiza búsquedas web externas limitadas y de múltiples pasos para recopilar evidencia externa dinámica (por ejemplo, registros de cambios de versiones anteriores, rastreadores de terceros) antes de generar una respuesta.

Contribuciones Clave

1. Taxonomía y Metodología: Una taxonomía exhaustiva basada en la causa raíz para informes de errores inválidos (que cubre siete subclases: Sistema Externo y Dependencia, Configuración Defectuosa, Solicitud de Funcionalidad, No Reproducible, Pregunta, Funcionando Según lo Diseñado y Versión Incorrecta) y una metodología para la subclasificación automatizada.
2. Generación de Soluciones Sin Código: Un enfoque novedoso para generar automáticamente soluciones accionables y no invasivas para informes inválidos.
3. Evaluación Exhaustiva: Una evaluación rigurosa de cómo la información previa (subclases) y la ingeniería de contexto (RAG, búsqueda web) afectan tanto la precisión de la clasificación como la calidad de la generación de soluciones.
4. Nueva Referencia de Evaluación: La introducción de una referencia de evaluación de oro que contiene informes de errores inválidos, sus subclases de causa raíz y soluciones sin código verificadas, llenando un vacío en los conjuntos de datos existentes que carecen de etiquetado explícito de subclases y evaluación de la calidad de la solución.

Resultados Experimentales
El estudio evaluó el rendimiento utilizando la Puntuación F1 Ponderada para la subclasificación y una combinación de BERTScore y tasas de éxito del LLM Juez para la generación de soluciones sin código.

• Subclasificación (RQ1):

  • RAG logró el mejor rendimiento general con una Puntuación F1 Ponderada de 0.66, superando ligeramente a los LLM Vanilla (0.65) y a la Búsqueda Web Agente (0.64).
  • RAG destacó en No Reproducibilidad (0.85 F1) y Problemas de Sistema Externo y Dependencia (0.67 F1).
  • Versión Incorrecta permaneció como la subclase más desafiante en todos los métodos, con puntuaciones que oscilaron entre 0.00 y 0.29.
  • La Búsqueda Web Agente mostró utilidad específica para la categoría Versión Incorrecta (mejorando la puntuación de Gemini de 0.00 a 0.20) al acceder a datos de versiones externos.

• Generación de Soluciones Sin Código (RQ2):

  • La Búsqueda Web Agente logró la tasa de éxito general más alta del LLM Juez con un 68.9% (usando Gemini 3.1 Pro), superando a RAG (64.4%) y a los LLM Vanilla (64.9%).
  • La búsqueda agente fue particularmente efectiva para las categorías Pregunta (72.2%) y Versión Incorrecta (41.7%), donde el contexto externo es crítico.
  • RAG tuvo el mejor rendimiento para Funcionando Según lo Diseñado (88.2% de tasa de éxito), aprovechando discusiones históricas del proyecto.
  • El estudio de ablación "Sin Precedentes" reveló que proporcionar información de subclases generalmente mejora el rendimiento, aunque en casos específicos (por ejemplo, Configuración Defectuosa), eliminar los precedentes permitió a los modelos inferir soluciones más directamente sin distraerse por una categorización rígida.

Significado y Afirmaciones
El artículo afirma que diferentes componentes son efectivos para diferentes tareas: RAG es superior para tareas de subclasificación que requieren contexto histórico y conocimiento específico del proyecto, mientras que la Búsqueda Web Agente es más beneficiosa para generar soluciones sin código que requieren información externa actualizada (por ejemplo, lanzamientos de versiones, dependencias de terceros).

El estudio concluye que automatizar este flujo de trabajo tiene el potencial de:

• Reducir el esfuerzo de clasificación manual para el soporte al cliente y los desarrolladores.
• Proporcionar orientación inmediata y accionable a los usuarios dentro de los sistemas de seguimiento de errores.
• Mejorar la experiencia del usuario resolviendo informes inválidos sin intervención humana.

Los autores enfatizan que, aunque BERTScore indica una alta similitud textual, la métrica del LLM Juez es más crítica para evaluar la corrección funcional. También señalan que la efectividad del marco depende de la disponibilidad de datos ricos del proyecto (para RAG) y de la capacidad del modelo para navegar la búsqueda externa sin alucinaciones (para Búsqueda Agente). El artículo no afirma resolver todos los informes de errores inválidos, reconociendo que subclases como "Versión Incorrecta" y "Configuración Defectuosa" siguen siendo desafiantes.