Cómo evaluar una IA energética: qué demuestra realmente una prueba
Repetir un cálculo, respetar un permiso y reducir un coste son logros diferentes. Una evaluación debe explicar cuál ha comprobado y bajo qué condiciones.
Un porcentaje de acierto dice poco hasta que sabemos qué se ha contado. El sistema puede haber respondido a una pregunta, calculado una alternativa viable, detectado que faltaba información o evitado una actuación que no estaba autorizada.
Presentar esos resultados bajo una única cifra de «fiabilidad» simplifica una presentación, pero dificulta entender qué podemos esperar del sistema. Cuando evalúo una propuesta de IA aplicada a energía, me interesa empezar por el problema que debía resolver. Después vienen la arquitectura y el modelo utilizado.
Primero hay que acordar qué significa hacerlo bien
Supongamos que un sistema propone reducir el coste de una instalación desplazando parte del consumo a otro horario. Una prueba puede comprobar que la multiplicación entre consumo y precio es correcta. Otra más completa preguntaría si ese desplazamiento es posible, si requiere personal adicional o si afecta a la producción.
Ambas tienen utilidad, con alcances diferentes. Antes de comparar resultados, definiría el objetivo, los datos disponibles y las condiciones que deben respetarse. También dejaría claro qué herramientas recibió cada alternativa y cuánto tiempo y recursos pudo utilizar.
Comparar un modelo aislado con otro sistema que dispone de documentación, un optimizador y reglas de negocio permite estudiar esas configuraciones. Para atribuir la diferencia a un componente concreto, habría que examinar su contribución dentro del conjunto.
Incluiría, además, soluciones convencionales sin modelos de lenguaje. Si un procedimiento sencillo resuelve el problema con menor coste y suficiente calidad, ese es un resultado relevante. La evaluación debe permitir cuestionar la arquitectura que hemos elegido.
Reconstruir el resultado y comprobar que es adecuado
El determinismo es valioso cuando necesitamos revisar un cálculo. Obtener el mismo resultado bajo las mismas condiciones facilita localizar qué ha cambiado y examinar el procedimiento. Aun así, una fórmula puede utilizar una unidad equivocada y repetir el error perfectamente.
Con una previsión podemos conservar los datos, la versión del modelo y el procedimiento utilizado. Eso permite revisar cómo se obtuvo; su capacidad predictiva se comprueba al contrastarla con lo que ocurre. Son dos preguntas: si podemos reconstruir el resultado y si ese resultado era adecuado para el problema.
Incluiría situaciones incómodas: datos incompletos, contratos modificados, equipos con nombres parecidos o restricciones que aparecen después de haber calculado una alternativa. Me interesa identificar dónde deja de ser fiable el sistema y qué hace al llegar a ese punto. Pedir una comprobación adicional puede ser una respuesta mejor que completar el proceso con un supuesto no declarado.
Qué aportan mis propuestas de evaluación
En mi investigación he abordado estas cuestiones desde planos diferentes. La propuesta de arquitectura energética describe una forma de organizar la representación del dominio y la decisión. Energy Decision Benchmark plantea criterios para examinar capacidades y condiciones operativas. SARA Scale propone una clasificación centrada en propiedades de gobierno.
Son trabajos propios publicados como preprints, con alcances distintos. Los presento como propuestas que pueden contrastarse con otras arquitecturas y mediante evaluaciones independientes.
Una prueba puede comprobar que una autorización revocada bloquea una actuación. Eso informa sobre el control del sistema. Otra puede examinar si encuentra una solución válida ante una combinación nueva de restricciones. Eso informa sobre su capacidad. Necesitamos ambas para conocerlo mejor.
Del mismo modo, describir una arquitectura o una invención y demostrar el comportamiento de una implementación son pasos diferentes. Para sostener una capacidad concreta hay que identificar qué la implementa, cómo se ha probado y qué resultados se han observado. Ese criterio también debe aplicarse a mis propios trabajos.
Seguir la decisión más allá de la recomendación
En control de edificios, BOPTEST ofrece emuladores y métricas para comparar estrategias bajo condiciones definidas. Estos entornos permiten examinar propuestas antes de trasladarlas a una instalación, sabiendo a qué casos se refiere el resultado.
Después queda otro recorrido: comprobar qué se aprobó, qué llegó a ejecutarse y qué ocurrió. Una tarifa recomendada puede no contratarse. Una factura inferior puede reflejar tanto el cambio de contrato como una menor actividad de la instalación.
Al comunicar un resultado distinguiría entre una alternativa calculada, una actuación ejecutada y un efecto observado. Si atribuimos una mejora a la decisión, explicaría contra qué referencia se ha comparado y qué otras condiciones cambiaron.
La información que pediría a una evaluación es concreta: casos utilizados, versiones, datos de entrada, criterios de éxito, recursos consumidos y fallos encontrados. Con ella se puede discutir el resultado, decidir dónde utilizar el sistema y plantear la siguiente prueba.
Antes de preguntar cuánto acierta una IA, quiero saber qué problema resuelve, frente a qué alternativa y qué hace cuando le falta información.
Lecturas relacionadas
Referencias
Alejandro Díaz
Fundador de TheryOS, empresario y emprendedor en los sectores energético y financiero.
