Don Nelson: estado actual

El 22 de diciembre del año pasado partí un desafío de 60 días para construir un agente capaz de hacer estudios eléctricos. Después lo extendí a 100 días, y en algún momento dejé de publicar porque estaba colapsado.

El número real es 200 días. Ese es el tiempo que me llevó construir a Don Nelson y que hiciera un estudio aprobado por el CEN. Tengo que admitir que pensé que me iba a demorar mucho menos, pero ese es el número real.

Cómo funciona hoy

Entra el estudio, que generalmente es un CES (Carta de escenarios entregado por el CEN), y Don Nelson me entrega un entregable que puede demorar entre 10 y 12 horas (trabajando completamente autónomo). La parte que más tiempo toma es actualizar la base, alrededor de 4 a 6 horas. Después de eso escribe y me entrega una versión.

Flujo de iteración entre el humano y Don Nelson

Yo la reviso y, en el mejor de los casos, sale a la primera con modificaciones mías. Si no, tengo que iterar. Hasta ahora nunca he tenido que iterar más de 2 veces.

Cómo le dejo los comentarios a Don Nelson en Google Docs

Estimo que el trabajo que hace Don Nelson es 80% y yo hago 20%.

La arquitectura: un agente, una responsabilidad

En un inicio la idea era que el mismo Don Nelson fuera a InfoTécnica, PGP y Acceso Abierto, pero mi conclusión fue copiar lo que hacen los informáticos con su metodología SOLID. La S (principio de responsabilidad única) significa tener una tarea por función, y es lo que mejor me ha funcionado.

En este caso, Mateo es el agente que es el modelo de la red. Voy a hablar en profundidad de Mateo en un siguiente post, pero básicamente la idea es que conoce la red mejor que nadie: mezcla InfoTécnica, PGP, Acceso Abierto e internet, y le puedo preguntar todo lo imaginable sobre la red.

La arquitectura: Don Nelson delega en Mateo (la red) y Spark (las simulaciones)

Lo mismo pasa con Spark: Don Nelson no necesita saber hacer simulaciones. Simplemente le encarga ese trabajo a Spark, que va a DIgSILENT, escribe el script y le devuelve el dato.

Resultados

Don Nelson ya entregó estudios que fueron aprobados por el CEN. Aún no puede hacer estudios de ECAP, porque es conocimiento más complicado que el de los estudios simples, y tampoco puede hacer estudios dinámicos/EMT.

Cada decisión que toma Don Nelson, cada simulación que le encarga a Spark y cada consulta que le hace a Mateo queda guardada, entonces la auditoría es muy fácil de hacer. Cada cifra del informe sale de una fuente única generada por la simulación, nunca hay tipeo a mano, porque aprendí (a la mala 😔) que un número transcrito a mano se puede contradecir.

Otro punto importante: Don Nelson no parte de cero. Aprendió leyendo todo lo público del CEN, el corpus histórico de los estudios pasados, y con eso sabe con certeza qué es lo que los revisores revisan.

Don Nelson ya auditó y rehízo estudios hechos por terceros que tenían observaciones.

Dos cosas que aprendí verificando a un agente

Estas dos me costaron caro y creo que le sirven a cualquiera que esté construyendo agentes, no solo en el mundo eléctrico.

1. Leer los datos crudos, nunca el resumen del agente

Cuando Spark termina una simulación me devuelve dos cosas: los resultados crudos (un JSON con los números tal cual salieron de PowerFactory) y un resumen en lenguaje natural de cómo le fue. Al principio yo leía el resumen, porque obvio, para eso está.

Error. El resumen siempre se lee bien. El agente te escribe "corrieron los 50 casos y convergen" con la misma seguridad cuando es cierto que cuando corrieron 45. No es que mienta: es que el texto que genera es plausible por construcción, y plausible no es lo mismo que verdadero. La regla que me quedó: la narrativa del agente sirve para orientarse, pero cualquier cosa que termine en el informe se verifica contra el dato crudo.

2. Contar en vez de leer

Este es el que más hallazgos me ha dado. Cuando reviso un entregable de Don Nelson, ya no parto leyéndolo de corrido — parto contando: el texto dice que se corrieron N casos, ¿hay N resultados en el respaldo? Dice que hay M contingencias, ¿el anexo tiene M filas? Cada número que el documento afirma, lo cruzo contra el conteo real.

¿Por qué funciona? Porque leyendo no pillo nada. Una frase como "el caso no converge" se lee perfectamente bien aunque el caso ya converja hace tres versiones — el texto no tiene cara de estar malo. Los desfases entre lo que el documento dice y lo que el modelo tiene no se ven leyendo; se ven contando. Es la revisión más aburrida que hago y es lejos la que más errores encuentra.

Suena loco pero es completamente verdad.

Otros aprendizajes

• El rol del humano tiene que ser decidir, no detectar.
• Las barreras van en código, no en documentos. El protocolo de verificación estaba perfectamente escrito… y no se ejecutaba. Un checklist en Markdown no es un mecanismo; un gate que corre tras cada mutación de la base y bloquea el avance, sí.
• Verificar antes de redactar. El ciclo escribir → verificar → parchar dio por terminados los informes tres veces antes de estarlo. El orden correcto que uso actualmente es: cosechar → verificar → congelar números → redactar.

Roadmap

Los estudios simples (EFP, ECB y revisión de estudios) ya están listos. En lo que estoy trabajando ahora es en que Don Nelson aprenda a coordinar protecciones por sí solo. Y después de eso, vamos por los estudios dinámicos.

Si necesitas un estudio en tiempo récord, o revisar uno antes de presentarlo ante el CEN, puedes agendar una reunión conmigo o conocer más en valdivia.tech y lo hacemos.