Real-Time Toxicity Filtering for Open-Source Code Reviews

1. Planteamiento del Problema

El desarrollo de software de código abierto (OSS) depende críticamente de la colaboración. Sin embargo, las plataformas como GitHub a menudo albergan interacciones tóxicas que rompen los límites profesionales. Estas interacciones tienen consecuencias negativas graves:

• Disminución de la productividad.
• Creación de barreras para nuevos contribuyentes.
• Fomento de conflictos y reducción de la calidad del software.

Los enfoques existentes para gestionar la toxicidad en OSS suelen ser post hoc (después de los hechos), basándose en la clasificación de texto una vez que el daño ya se ha causado. No existe una solución integrada en tiempo real que no solo detecte la toxicidad, sino que ofrezca retroalimentación accionable y sugiera alternativas civiles antes de que el comentario se publique.

2. Metodología: ToxiShield

Los autores proponen ToxiShield, una extensión de navegador de tiempo real que implementa un marco de trabajo de tres módulos para detectar, explicar y mitigar la toxicidad en las revisiones de código.

Módulo 1: Filtro de Toxicidad (Toxicity Filter)

• Objetivo: Identificar si un comentario es tóxico o no (clasificación binaria).
• Enfoque: Se utilizaron Modelos de Lenguaje enmascarados (MLM) y Modelos de Lenguaje Grande (LLM).
• Datos: Se creó un nuevo conjunto de datos filtrando 15 millones de comentarios de pull requests para anotar 10,120 instancias tóxicas y 28,641 no tóxicas.
• Modelo: Se ajustó finamente (fine-tuning) el modelo BERT-base-uncased.
• Desafíos: Los modelos existentes a menudo fallan con matices como la ironía o términos específicos del dominio que se confunden con profanidades.

Módulo 2: Entrenador de Comunicación (Communication Coach)

• Objetivo: Una vez detectada la toxicidad, clasificar el comentario en subcategorías específicas (11 categorías según la taxonomía de Sarker et al.) y proporcionar una explicación detallada.
• Enfoque: Debido a la escasez de datos anotados de manera fina, se optó por LLMs con ingeniería de prompts en lugar de ajustar modelos tradicionales.
• Datos: Se combinaron 600 comentarios anotados manualmente (532 tóxicos) con 600 no tóxicos, creando un conjunto de 1,200 muestras para clasificación multiclase y multietiqueta.
• Estrategia: Se utilizó aprendizaje en contexto (in-context learning) con prompts iterativos que definían roles, tareas y especificaciones de salida XML. Se evaluaron modelos como GPT-4o, Claude 3.5 Sonnet y Llama 3.3 70B.

Módulo 3: El Reformulador (The Reframer)

• Objetivo: Reescribir automáticamente el comentario tóxico en una alternativa civil y constructiva, preservando el significado técnico original (Transferencia de Estilo de Texto - TST).
• Enfoque: Dado que no existía un corpus paralelo (tóxico vs. no tóxico) para el dominio de ingeniería de software, se sintetizó un dataset.
  • Se tomaron los 10,120 comentarios tóxicos del Módulo 1.
  • Se utilizaron LLMs de vanguardia (GPT-4o, Qwen 2.5, etc.) para reescribirlos respetando la intención original.
  • Se seleccionó el dataset generado por GPT-4o-05-13 (con el mejor puntaje J) para entrenar modelos "estudiante".
• Modelo: Se entrenó un modelo Llama 3.2 3B para realizar la detoxificación en tiempo real.

3. Resultados Clave

| Módulo | Métrica Principal | Resultado Obtenido | Observaciones |
| :--- | :--- | :--- | : |
| Módulo 1 (Clasificación Binaria) | F1-Score (Clase Tóxica) | 97% | Precisión: 0.98, Recall: 0.96. BERT-base-uncased fue el mejor. |
| Módulo 2 (Clasificación Multiclase) | F1 Macro / MCC | 42% F1 / 39% MCC | Claude 3.5 Sonnet fue el mejor. Funciona bien en categorías explícitas (insultos), pero falla en casos ambiguos (toxicidad dirigida a objetos). |
| Módulo 3 (Reformulación) | Puntaje J / Precisión de Estilo / Fluidez | 84% J / 95.27% / 97.03% | Llama 3.2 3B logró un equilibrio excelente. La preservación de contenido fue del 67.07%. |

Análisis de Errores:

• El Módulo 1 a veces confunde términos técnicos con profanidades.
• El Módulo 2 tiene dificultades con la toxicidad pasivo-agresiva o sarcasmo.
• El Módulo 3 a veces falla en contextos técnicos complejos donde una palabra específica (ej. "disgusting" en un nombre de variable) se interpreta erróneamente como ofensiva en lugar de técnica.

4. Evaluación con Usuarios

Se integraron los tres módulos en una extensión de navegador y se evaluó con 10 desarrolladores profesionales durante dos semanas utilizando el Modelo de Aceptación Tecnológica (TAM).

• Hallazgos: Los desarrolladores recibieron la herramienta de manera muy positiva, destacando su facilidad de uso y la satisfacción general.
• Limitaciones: Se identificó la necesidad de mejorar la gestión de errores y la eficiencia en tareas específicas para una adopción más amplia.

5. Contribuciones y Significancia

• Primera herramienta en tiempo real: Es el primer estudio que ofrece una solución de detoxificación en tiempo real con explicaciones para desarrolladores de software.
• Enfoque proactivo: Cambia el paradigma de la moderación reactiva a la preventiva, fomentando un entorno más inclusivo antes de que se publique el comentario.
• Recursos Abiertos: Los autores han hecho públicos el dataset, el código y la herramienta, contribuyendo a la investigación futura en la mitigación de toxicidad en OSS.
• Impacto Social: Al reducir la toxicidad, la herramienta busca eliminar barreras para nuevos contribuyentes y mejorar la calidad de la colaboración en el ecosistema de código abierto.

En resumen, ToxiShield representa un avance significativo al combinar técnicas avanzadas de IA (BERT, LLMs, ingeniería de prompts) en un flujo de trabajo práctico que no solo detecta el problema, sino que educa al usuario y ofrece soluciones inmediatas.