Automatizar estudios de cortocircuito y protecciones con IA
Día 36 / 60
Para los que no están al tanto, un recordatorio de los 4 objetivos que persigo con este proyecto:
- Tesis de pregrado — Nunca me titulé de Ingeniero, y quiero obtener mi título con este proyecto
- Hackathon Gemini 3 — 25 mil inscritos, quedan 2 semanas para entregar la postulación
- Producto real — Quiero que esto se convierta en una herramienta que pueda comercializar
- Construir en público — Documentar el proceso, recibir feedback, crear comunidad
El hackathon es el deadline más cercano y el que más presión genera.
El agente ahora genera tres tipos de estudios eléctricos: flujos de potencia, cortocircuitos y coordinación de protecciones.
El sábado solo podía correr flujos de potencia. Hoy el agente simula fallas trifásicas, calcula corrientes de cortocircuito, y genera informes ECAP con ajustes de relés. Las tres patas fundamentales de un estudio de conexión al sistema eléctrico. Los informes siguen siendo informes mediocres, pero sigue siendo un avance.
Pero con este avance me topé con un problema grande.
A medida que el Proyecto D.N crece, el agente se vuelve más complejo. Para soportar los tres tipos de estudios, llegué a las 30 herramientas disponibles. Y siento que se empezó a romper.
El problema cognitivo
No es que el modelo (Gemini 3 Flash y Gemini 3 Pro) sea malo. Es que estamos forzando a un solo "cerebro" a sostener demasiadas opciones al mismo tiempo.
Cuando le das 30 tools a un LLM en un loop ReAct simple, ocurren tres cosas:
Alucinaciones de herramientas. Empieza a inventar argumentos o a mezclar funciones que no existen.
Fatiga de atención. Pierde el hilo en procesos largos, como estudios que requieren 40+ pasos secuenciales.
Latencia. El prompt se vuelve gigante y cada decisión toma más tiempo del necesario.
Le encargué a mi otro agente Pedrito que hiciera un deep research y conversáramos qué era lo mejor que podíamos hacer. Estos son los 4 caminos que estoy explorando.
Cuatro caminos
1. Sub-Agentes
La idea clásica de divide y vencerás. En vez de un agente con 30 tools, tienes varios agentes especializados con menos de 10 cada uno.
En mi caso sería algo así: un Agente Simulador que solo conoce PowerFactory (correr flujos, simular fallas, extraer resultados), un Agente de Protecciones que configura relés y calcula ajustes, y un Agente Reportero que toma datos y genera PDFs con tablas y gráficos.
Arriba de todos ellos vive un orquestador. El usuario le dice "hazme un estudio ECAP", y el orquestador decide: primero le pido al Simulador que corra los cortocircuitos, después le paso esos resultados al de Protecciones para que calcule los ajustes, y finalmente el Reportero genera el informe.
Diagrama de arquitectura de sub-agentes
Me gusta conceptualmente porque cada agente se vuelve experto en su dominio. El Simulador no necesita saber nada de PDFs. El Reportero no necesita saber qué es un relé de sobrecorriente.
Pero me asusta la complejidad. De la nada tengo 4 agentes que coordinar en vez de uno. ¿Y si el orquestador también se confunde con tantas opciones? ¿Y si la comunicación entre agentes pierde información crítica?
2. Multi-Routing dinámico
Esta mantiene un solo cerebro pero con "carpetas" de herramientas que se activan según el contexto.
Imagina que el agente tiene acceso a un router inicial. Cuando llega una instrucción como "simula un cortocircuito", el router detecta que es una tarea de simulación y carga solo las 8 tools relacionadas: conectar a PowerFactory, definir falla, ejecutar cálculo, extraer corrientes, etc. Las otras 22 tools ni siquiera existen para esa llamada.
Si después el usuario dice "ahora genera el informe", el router cambia de contexto y carga el kit de reportería: crear documento, insertar tabla, agregar imagen, exportar PDF.
Diagrama de multi-routing dinámico
Me parece elegante en teoría. El agente siempre ve un conjunto manejable de herramientas (un kit), pero tiene acceso completo a través del routing.
En la práctica, ¿quién decide qué kit cargar? Necesito un clasificador antes del agente, otro modelo o un sistema de reglas que interprete la intención. Otra pieza que puede fallar, otro punto donde se pueden perder matices. "Simula un cortocircuito y después ajusta las protecciones" ¿activa un kit o dos?
3. Tool RAG (Retrieval Augmented Tools)
Esta me voló la cabeza cuando la descubrí. La idea es tratar las herramientas como si fueran documentos en un sistema RAG.
Cada tool tiene una descripción rica: qué hace, cuándo usarla, qué parámetros recibe, ejemplos de uso. Todas esas descripciones se indexan en una base de datos vectorial, igual que harías con documentos de texto.
Cuando llega una instrucción del usuario, el sistema hace una búsqueda semántica: "¿cuáles de mis 100 herramientas son más relevantes para esto?". Recupera las top 5 o 10, y solo esas se le pasan al modelo en el prompt.
Diagrama de Tool RAG
En teoría, esta es la que escala más brutalmente. Podría tener 500 tools y el agente siempre ve un conjunto pequeño y relevante. No hay límite práctico. Además, agregar una herramienta nueva es solo agregarla al índice — no tienes que reorganizar arquitecturas ni reentrenar nada.
Pero requiere describir cada herramienta con precisión quirúrgica. Si la descripción de simulate_three_phase_fault no menciona "cortocircuito trifásico", el retrieval no la va a encontrar cuando el usuario pida eso. La calidad del sistema depende de la calidad de las descripciones, y eso es trabajo manual intenso (o que bien podría hacer Pedrito).
4. Plan-and-Execute (El modelo Senior-Junior)
Esta es la que más me convence para el hackathon.
La arquitectura separa planificación de ejecución en dos agentes distintos. Un Planner recibe la instrucción completa del usuario y genera un plan: una lista ordenada de pasos que hay que ejecutar. Un Executor toma ese plan y ejecuta cada paso uno por uno, con acceso completo a todas las herramientas.
El Planner es el "senior" del equipo. No necesita saber los argumentos exactos de cada función ni cómo se llaman internamente. Solo necesita entender el dominio y pensar estratégicamente: "para hacer un estudio ECAP, primero necesito los datos del sistema, después simulo cortocircuitos en cada barra, después calculo los ajustes de protecciones, y finalmente genero el informe".
El Executor es el "junior". Recibe instrucciones atómicas como "simula un cortocircuito trifásico en la barra San Pedro 220kV" y las traduce a llamadas específicas de herramientas. No necesita entender el panorama completo, solo ejecutar bien cada paso.
Diagrama de Plan-and-Execute
¿Por qué esta me convence? Porque separa la carga cognitiva de forma natural. El Planner ve pocas herramientas abstractas ("simular falla", "calcular protecciones", "generar informe") mientras el Executor ve las 30 tools concretas pero solo necesita elegir una a la vez para un paso específico.
Además, puedo usar Gemini 3 Pro para planificar y Gemini 3 Flash para ejecutar. El cerebro caro piensa poco pero bien. El cerebro barato trabaja mucho pero simple. Optimizo costo y calidad al mismo tiempo.
Según la investigación de Pedrito esta es la arquitectura que más tracción tiene.
El bug que me está matando
Hay un error grave que no logro resolver. Algunos prompts están matando a D.N.
Gemini 3 no responde. Obtengo un status 500 que no debería pasar.
Lo más frustrante es la inconsistencia: hay veces que creo que hice algún cambio mal en mi código, y otras veces creo que Gemini 3 es el problema. Pedro también me está dando problemas, y Pedro usa Gemini 3.
Mi hipótesis: 30 es el límite práctico de tools. Más allá de eso, el sistema se vuelve inestable. Los informes son especialmente problemáticos —casi siempre mueren en ese paso—.
El agente pasó de sentirse muy estable a sentirse frágil.
Las próximas 36 horas
Con 2 semanas para el hackathon de Google, tengo que tomar una decisión de arquitectura. Y no me la puedo mandar.
Estos momentos son los que más me agradan. Tomar decisiones técnicas me encanta. Si elijo mal, pierdo días implementando algo que después tengo que rehacer. Si elijo bien, el agente escala y llego al hackathon con algo sólido.
Plan-and-Execute me convence conceptualmente, y después de investigar, parece ser el patrón que más tracción tiene en producción — LangGraph y el ADK de Google lo documentan como arquitectura de referencia.
Mis herramientas no son genéricas. Son llamadas a PowerFactory, configuraciones de relés específicos, generación de diagramas unifilares. ¿El Planner va a entender el dominio eléctrico lo suficiente como para generar buenos planes? ¿O voy a terminar con un senior que no sabe de ingeniería eléctrica dándole instrucciones a un junior que sí sabe?
Gemini 3 Last Exam
Gemini 3 tiene el mejor rendimiento en Humanity Last Exam por lo que el planner debería funcionar bien.
Voy a tomarme 36 horas para decidir. Prototipar algo mínimo de cada enfoque, ver cuál se siente más natural con mis herramientas actuales, y después commitear con todo.