Validación de modelos de aprendizaje automático de automatización: el problema de Oracle

A menos que se actualicen los protocolos de puesta en marcha, puede resultar difícil realizar pruebas de validación en el software de control de automatización a medida que el aprendizaje automático y la IA se vuelven más comunes.

Bill Mueller

Por Bill Mueller, fundador e ingeniero senior de Lucid Automation and Security

Uno de mis objetivos profesionales más ambiciosos ha sido aumentar la eficiencia de las pruebas de validación sin disminuir la calidad. La prueba de los sistemas automatizados es esencial para garantizar la calidad tanto en el sistema de control como en el producto. Tradicionalmente, la puesta en marcha consistía en comparar la respuesta del sistema con un conjunto de salidas preaprobadas. Este método ha servido bien a la industria donde todas las rutas de ejecución de código eran deterministas y conocibles.

A medida que la adopción del aprendizaje automático (ML) y la inteligencia artificial (IA) en la planta se vuelve más común, se hace evidente que los modelos de máquinas recientemente implementados están subvirtiendo las técnicas de prueba tradicionales. No siempre es posible, ni práctico, identificar todas las rutas de ejecución posibles de un modelo de máquina moderno desarrollado a través del aprendizaje supervisado. Los protocolos desarrollados para secuencias o lógica de máquina de estado tradicional requerirán modernización para continuar brindando el mismo nivel de confianza.

La generación actual de protocolos de puesta en servicio se basa en técnicas de prueba de software automatizadas establecidas a principios de los años 80 y 90 utilizando lo que se conoce como "Oracles" de prueba. Un Oráculo en este sentido se refiere a la autoridad absoluta (es decir, la fuente de la verdad) utilizada para determinar si una determinada prueba pasa o falla. Oracle determina la salida correcta para una entrada esperada. Este rol puede ser documentación de diseño, requisitos del usuario o expertos en la materia con experiencia.

Con el uso cada vez mayor de aplicaciones ML en la planta, el software de control de automatización comenzará a caer en la clase de software no comprobable. Los dominios de entrada son grandes, los límites son difíciles de definir y las condiciones previas del entorno determinan la interpretación correcta de los resultados. La dependencia actual de las pruebas explícitas deberá evolucionar y aprovechar los métodos de prueba implícitos para mantener la relevancia.