Don Nelson aprendió a aprender

10 min de lectura

Día 31 / 60

Estuve muchos dias intentanto escribir este post. No porque no tuviera algo claro que contar, sino porque no sabía como contarlo. No es la historia de un logro técnico, sino de un momento de comprensión. Y contar eso sin sonar pretencioso o vago era un desafío. Al final decidí escribirlo tal cual lo sentí, con la esperanza de que el mensaje llegue claro.

Estuve lunes, martes y miercoles en un flow total. Recuerdo solo sentir que tenia que avanzar, sin entender muy bien hacia dónde ni por qué.


Lunes

Estuve todo el dia lunes intentando correr un flujo de potencia sobre la base de datos del Coordinador Eléctrico Nacional. Me fije que publicaron el 31 de Marzo los escenarios de operación.Es el sistema eléctrico chileno completo: 2600+ barras, generación, cargabilidad, tensión. Pense que iba ser llegar y correr pero no lograba hacerlo funcionar a mano. No se que estaba haciendo mal en el DigSILENT y la verdad que no lo inente mucho.

Por lo que como no pude hacerlo a mano, le pedí a Don Nelson que lo hiciera por mi. En el momento actual del harness de Don Nelson, tengo 2 agentes trabajando en conjunto: Nelson, que piensa, y Spark, que ejecuta. Le dije a Nelson "quiero que corras un flujo de potencia sobre la base de datos del CEN" y él se lo dijo a Spark, que es el que tiene acceso a PowerFactory. Y Spark no podía hacerlo funcionar tampoco.

Ciclo de comunicación entre Don Nelson y Spark, donde Nelson le dice a Spark qué hacer, Spark lo hace y le dice a Nelson qué pasó.

Ciclo de comunicación entre Don Nelson y Spark, donde Nelson le dice a Spark qué hacer, Spark lo hace y le dice a Nelson qué pasó.

Spark y Don Nelson intentaron de todo. Redespachó generadores. Creó redes externas como slack. Duplicó potencias. Activó modelos que no debía. 15 veces. Cada intento tomaba entre 5 y 10 minutos. Y cada vez que fallaba, empezaba de cero. Sin recordar nada. Activaba el caso pero no el escenario, o lo hacia al reves.

15 intentos. Un día entero. Cero resultados.

Recuerdo haberme ido a acostar pensando que algo estaba haciendo mal, que no podía ser tan difícil. Pero no encontraba el error. Y lo peor es que no sabía ni siquiera qué error estaba buscando.


El Martes

Al dia siguiente me di cuenta que el ciclo de aprendizaje que tenia spark debia tenerlo Nelson igual

Hable del ciclo de aprendizaje de spark en un post anterior, pero en resumen es esto: Nelson le dice a Spark "haz esto". Spark lo hace y le dice a Nelson "esto pasó". Nelson analiza lo que pasó, aprende de eso, y decide qué decirle a Spark en el siguiente intento. El problema es que ese ciclo de aprendizaje solo existía para Spark. Nelson no aprendía nada. Cada intento fallido era un error sin sentido para él, porque no tenía forma de entender por qué había fallado.

La respuesta fue agregar el ciclo de aprendizaje a Nelson también.

Ciclo de aprendizaje de Don Nelsón. (Muy parecido al de Spark)

Ciclo de aprendizaje de Don Nelsón. (Muy parecido al de Spark)

  • Don Nelson piensa. Tiene un sistema de experiencias aprendidas (learned/) donde acumula conocimiento de cada intento. Sabe qué funciona, qué no, y por qué.
  • Spark ejecuta. Recibe instrucciones precisas de Nelson y las corre. No decide estrategia.

Nelson ahora le habla a Spark así:

INSTRUCCIONES:
1. Activa Study Case "Base SEN"
2. Activa escenario "Laboral Diurno"
3. Deshabilita todos los ElmDsl

RESTRICCIONES:
- NO modificar despacho de generadores
- NO crear ni asignar slack manualmente
- Si diverge, solo diagnosticar — NO reintentar

Las restricciones son los 15 fracasos del lunes convertidos en conocimiento. No los agregué yo. Nelson los escribió solo después de cada intento fallido.


El momento

Primer intento hoy: divergió con un desbalance de -289 MW. Pero en vez de reintentar a ciegas como el lunes, Nelson analizó el diagnóstico, leyó su experiencia acumulada, y decidió relajar los límites del slack.

Segundo intento. Convergió.

Pantallazo del momento en que Don Nelson corrió el flujo de potencia del SEN por primera vez

Pantallazo del momento en que Don Nelson corrió el flujo de potencia del SEN por primera vez

Generación: 9,319 MW
Carga: 8,892 MW
Pérdidas: 427 MW
Slack: TER ANGAMOS U1
Barras aisladas: 0

Recuerdo haberme parado del asiento.

Los mismos 2 agentes que no lograban nada el lunes, el martes lograron hacer converger el sistema en 2 intentos. La diferencia no fue un mejor modelo de IA ni más compute. Fue un archivo markdown de 40 líneas que decía "esto funciona, esto no, y acá están los números que deberías esperar."


Lo que entendí

No le enseñé a Don Nelson a correr un flujo de potencia. Le enseñé a aprender a correrlo.

La diferencia parece sutil pero lo cambia todo. Un script automatiza una tarea — le dices paso 1, paso 2, paso 3, y ejecuta. Si algo cambia, se rompe. Un agente con memoria desarrolla una capacidad. Los 15 fracasos no fueron tiempo perdido — fueron el entrenamiento. Cada error se convirtió en una línea que dice "esto no funciona y por esto."

Eso no es automatización. Eso es aprendizaje.

Y hay algo más que me quedó claro: el aprendizaje automático necesita supervisión humana. Nelson auto-guardó una experiencia del modelo chico (7 barras) que decía "activar el Study Case por defecto." El modelo no tiene Study Case. Si no hubiera corregido eso manualmente, habría repetido el error en cada run. La combinación ganadora fue: el agente escribe el primer borrador de la lección, el humano lo revisa y refina. Exactamente como funciona un equipo real.


El Miércoles — El primer estudio público

El martes terminó con el flujo convergido. El miércoles decidí ir por todo: correr los 10 escenarios operacionales que publica el CEN y armar un estudio completo. Si Nelson aprendió a correr uno, debería poder correr diez.

Ese fue el primer estudio público de Don Nelson: Flujos de Potencia sobre BD Operación CEN, Marzo 2026.

Portada del estudio Flujos de Potencia sobre BD Operación CEN, Marzo 2026

Portada del estudio Flujos de Potencia sobre BD Operación CEN, Marzo 2026

10 escenarios — Laboral Diurno, Vespertino, Madrugada, Sábado, Domingo, y las combinaciones con máxima penetración de ERNC. 2600+ barras. Cada escenario corrido por Nelson y Spark, usando las mismas experiencias aprendidas que se construyeron el martes.

La generación total del SEN en el escenario Laboral Diurno: 9.6 GW. El 54% es solar fotovoltaica. El Norte Grande solo genera 3.9 GW. Y esos números no los escribí yo — salieron del flujo de potencia que Don Nelson corrió sobre la base de datos del CEN.

Composición de generación por tipo y escenario del SEN - 9.6 GW total en Lab. Diurno

Composición de generación por tipo y escenario del SEN - 9.6 GW total en Lab. Diurno

Al desglosar por zona geográfica se ve la realidad del sistema chileno: la generación está concentrada en el norte (solar y térmica) y la carga en el centro. Todo conectado por un sistema de transmisión que recorre 4.000+ km.

Generación por zona geográfica del SEN en escenario Laboral Diurno, con mapa de Chile

Generación por zona geográfica del SEN en escenario Laboral Diurno, con mapa de Chile

Y el mapa. Cada punto es una barra del SEN. Cada línea es una conexión real. Los colores muestran la cargabilidad — verde es holgura, amarillo es estrés, rojo es problema. Es el sistema eléctrico chileno completo, visualizado desde los resultados de un flujo de potencia que corrió un agente de IA.

Mapa interactivo del SEN mostrando cargabilidad de líneas de transmisión

Mapa interactivo del SEN mostrando cargabilidad de líneas de transmisión

Lo que estoy construyendo no es un software que hace estudios eléctricos. Es una máquina que aprende a hacerlos. Y esa diferencia es la que escala.

Si trabajas en el sector eléctrico y te interesa lo que estoy construyendo, conversemos.

Suscríbete al blog