Resumen Técnico: Del Fallo a la Alineación: Un Marco de Ingeniería de Requisitos para Sistemas de Aprendizaje Automático

Declaración del Problema

Las organizaciones que desarrollan Sistemas de Aprendizaje Automático (MLS, por sus siglas en inglés) enfrentan desafíos significativos para garantizar que estos sistemas sean confiables y estén alineados con las necesidades de los interesados. A diferencia del software tradicional, el comportamiento de un MLS se aprende de los datos en lugar de programarse explícitamente, lo que hace que su rendimiento dependa de la distribución y que el fallo sea inherente debido a la generalización y la incertidencia. Las prácticas actuales de Ingeniería de Requisitos (RE) luchan por modelar y razonar sistemáticamente sobre los requisitos de los MLS porque:

1. Subespecificación: Los dominios operativos son de naturaleza abierta y una especificación completa previa no es realista.
2. Supuestos Implícitos: Los supuestos del dominio (por ejemplo, cobertura de datos, límites de detección) suelen ser implícitos, lo que genera una desalineación entre los objetivos de los interesados, los supuestos del dominio y el comportamiento del sistema cuando ocurren fallos.
3. Falta de Integración: Aunque la detección de fallos es común en las pruebas de ML, existe una brecha en la integración sistemática del descubrimiento de fallos en el proceso de RE para impulsar el refinamiento de los requisitos. Los enfoques existentes suelen tratar los fallos como artefactos de prueba o problemas de depuración, en lugar de evidencia diagnóstica para refinar los requisitos y los supuestos del dominio.

El artículo aborda tres Preguntas de Investigación (RQ):

• RQ1: ¿Cómo se puede operacionalizar el razonamiento sobre los requisitos para los MLS?
• RQ2: ¿Cómo se puede integrar sistemáticamente el descubrimiento y la mitigación de fallos en el proceso de RE?
• RQ3: ¿En qué medida la adaptación impulsada por fallos y de capa cruzada mejora mensurablemente la satisfacción de los requisitos?

Metodología: El Marco REAL

Los autores proponen REAL (Requirements Engineering for mAchines that Learn - and Fail), un marco basado en modelos que trata el fallo como un constructo de primera clase. REAL opera sobre tres principios fundamentales: entrelazar los requisitos de datos, de modelo y de sistema; utilizar el fallo para impulsar la exploración de requisitos alternativos; y un refinamiento iterativo y trazable.

El marco establece un bucle de alineación iterativo que involucra tres fases:

1. Identificación de Fallos mediante la Exploración de Escenarios

En lugar de asumir una satisfacción uniforme de los requisitos, REAL operacionaliza el dominio como un espacio de escenarios parametrizado $D(\theta)$.

• Generación Guiada por Gramática: Utiliza la Evolución Gramatical (GE) con un Lenguaje de Dominio Específico (DSL) definido por una gramática formal para generar automáticamente escenarios estructurados (actores, entornos, comportamientos).
• Filtrado de Admisibilidad: El marco distingue entre fallos válidos (que ocurren dentro de los supuestos admisibles del dominio) y fallos espurios (provocados por escenarios fuera de alcance). Solo los fallos válidos, donde $D(\theta), S \not\models R$ y se mantienen las restricciones de admisibilidad, se propagan al análisis.

2. Análisis de Fallos mediante el Análisis de Obstáculos

Los fallos se reinterpretan como obstáculos en un modelo de metas de tipo KAOS.

• Interpretación de Contraejemplos: Un rastro de fallo se trata como un contraejemplo para la relación de satisfacción.
• Derivación de Obstáculos: Los fallos se agrupan para identificar patrones recurrentes, elevando los contraejemplos empíricos en condiciones de obstáculos explícitos ($O$) donde $O \Rightarrow \neg R$. Esto diagnostica desalineaciones entre los objetivos de los interesados, los supuestos del dominio y el comportamiento del sistema.

3. Mitigación de Fallos mediante la Adaptación Multicapa

REAL distingue cuatro capas de adaptación para restaurar la relación de satisfacción ($D, S \models R$):

• Nivel de Datos: Aumentar las distribuciones de entrenamiento o reequilibrar las clases para abordar brechas distributivas.
• Nivel de Modelo: Ajustar arquitecturas, hiperparámetros o umbrales de decisión para remodelar la frontera de decisión aprendida.
• Nivel de Sistema: Introducir lógica de control consciente de la confianza, comportamientos de seguridad ante fallos o redundancia sin modificar el modelo aprendido en sí mismo.
• Nivel de Requisito: Refinar los requisitos ($R$) o los supuestos del dominio ($D$) mismos (por ejemplo, delimitar el Dominio de Diseño Operativo u ODD) cuando los fallos revelan necesidades subespecificadas o supuestos poco realistas.

Este proceso es iterativo; las nuevas adaptaciones pueden exponer nuevas violaciones, requiriendo un nuevo refinamiento de la triple $(D, S, R)$.

Principales Contribuciones

El artículo realiza cuatro contribuciones principales:

1. Vínculo Operacional: Conecta los requisitos de los interesados con la variabilidad ejecutable del dominio mediante la exploración de escenarios guiada por gramática, permitiendo el descubrimiento sistemático de contraejemplos relevantes para los requisitos.
2. Interpretación Basada en Obstáculos: Reinterpreta los fallos empíricos como obstáculos en un modelo de metas, proporcionando un mecanismo fundamentado para diagnosticar la desalineación.
3. Estrategia de Mitigación Multicapa: Define y evalúa la adaptación coordinada a través de las capas de datos, modelo, sistema y requisitos, mostrando explícitamente cómo las decisiones de mitigación afectan la satisfacción de los requisitos.
4. Demostrador de Conducción Autónoma: Proporciona un paquete de replicación disponible públicamente que demuestra el marco en un sistema de frenado automático utilizando CARLA, Scenic y generación de escenarios evolutiva.

Resultados Experimentales

El marco fue evaluado utilizando un sistema de frenado automático con un componente de detección de peatones (YOLOv5) y un controlador de frenado determinista.

Configuración Experimental:

• Entorno: Simulador CARLA con Scenic para la especificación de escenarios.
• Generadores: GRAPE (Evolución Gramatical) para la generación de escenarios.
• Enfoque: Variación sistemática del tamaño del peatón, distancia, dirección, vestimenta y clima (niebla).

Hallazgos:

• Identificación de Fallos: El marco identificó con éxito violaciones de requisitos válidas, tales como detecciones omitidas de niños peatones (relacionadas con el tamaño), fallos bajo baja saliencia visual (contraste de la vestimenta) y rendimiento degradado en niebla (visibilidad).
• Análisis de Obstáculos: Los fallos se agruparon en tres clases de obstáculos: TamañoDePeatónDemasiadoPequeño, SalienciaVisual y ClimaAdverso.
• Efectividad de la Mitigación:
  • Nivel de Modelo (M1): Cambiar a un modelo más grande (YOLOv5m) mejoró la precisión (+17%) pero introdujo fallos inducidos por latencia en escenarios de corta distancia.
  • Nivel de Datos (M2): El ajuste fino (fine-tuning) dirigido en datos de niños-peatones eliminó los fallos relacionados con el tamaño y mejoró significamente el rendimiento en niebla (la tasa de colisión cayó de 100% a 0% en clima nominal).
  • Nivel de Sistema (M4): La implementación de un frenado consciente de la confianza redujo las tasas de colisión residual con niños de 100% a 8% sin necesidad de reentrenar.
  • Nivel de Requisito (M5): Delimitar explícitamente el Dominio de Diseño Operativo (ODD) y definir umbrales cuantitativos aclaró los límites de las garantías de seguridad.
• Impacto General: La adaptación coordinada de capa cruzada redujo las tasas de colisión con niños de 100% (línea base) a 8% y eliminó los fallos en clima nominal. El estudio demostró que la optimización aislada del modelo es insuficiente; la alineación requiere abordar la interacción entre datos, modelo, sistema y requisitos.

Significado y Pretensiones

El artículo sostiene que REAL proporciona un proceso sistemático para integrar los resultados de las pruebas en los artefactos de RE. Su importancia radica en:

• Cambio de Perspectiva sobre el Fallo: Pasar de ver el fallo como un defecto técnico a verlo como evidencia diagnóstica de una desalineación entre los requisitos, los supuestos y la implementación.
• Operacionalización de la Alineación: Proporcionar un mecanismo concreto para vincular las metas de alto nivel de los interesados con los comportamientos de bajo nivel del sistema y los supuestos del dominio mediante el análisis de obstáculos.
• Coordinación de Capa Cruzada: Demostrar que restaurar la alineación en los MLS requiere una adaptación coordinada a través de múltiples capas (datos, modelo, sistema, requisitos) en lugar de correcciones aisladas.

Los autores mantienen una postura modesta, reconociendo que la evaluación se limita a un ejemplo simplificado de seguridad crítica y que el proceso no garantiza la convergencia en todos los casos. Señalan que, si bien el marco estructura el proceso, el juicio humano sigue siendo esencial para interpretar los fallos y seleccionar las estrategias de mitigación. Se propone como trabajo futuro extender REAL a los Modelos de Lenguaje Extensos (LLMs), incorporar los valores de los interesados de manera más profunda e investigar las condiciones de convergencia del bucle de alineación iterativo.