PICasso genera circuitos fotónicos desde lenguaje natural

PICasso acierta la estructura de un circuito fotónico en hasta el 92,7% de los casos y su función en el 52%. Esa distancia entre dibujar algo que pasa las reglas de diseño y dibujar algo que además cumple la especificación óptica es el dato más honesto del paper publicado el 29 de agosto en arXiv.

El trabajo, PICasso: An AI-Enabled Design Framework for Autonomous Optimization of Silicon Photonic Devices, presenta un framework para sintetizar, verificar y optimizar circuitos fotónicos integrados (PIC) a partir de especificaciones escritas en lenguaje natural. La fotónica de silicio es el sustrato de los transceptores ópticos que mueven el tráfico dentro de los centros de datos, y su flujo de diseño sigue siendo bastante más artesanal que el de la electrónica digital.

Cómo funciona el pipeline

PICasso no le pide a un LLM que escriba el layout final. Encadena una generación en dos saltos, de lenguaje natural a YAML y de YAML a GDS, con inyección de conocimiento del PDK (el kit de diseño de la fundición), colocación y rutado automáticos, validación DRC/LVS y simulación fotónica basada en SAX. El modelo produce una representación intermedia declarativa y el resto de la cadena, que es determinista, comprueba lo que ha propuesto.

PIC-Set, el benchmark

Para medir todo esto los autores publican PIC-Set, un conjunto de 36 tareas de diseño parametrizadas que van desde primitivas fotónicas básicas hasta circuitos multicomponente. Sobre él comparan varios LLMs del estado del arte bajo un protocolo unificado, sin que el abstract enumere cuáles, con métricas nuevas: Spec@k estructural y funcional, eficiencia de optimización y robustez ante perturbaciones.

Las cifras que reporta el paper: Spec@3 estructural de hasta 92,7% y Spec@3 funcional de hasta 52% en los circuitos de mayor complejidad, siempre por encima de la generación directa con LLM sin el andamiaje alrededor. En la parte de optimización, la pérdida de inserción media baja de 4,98 dB a 3,25 dB, es decir 1,73 dB menos, en torno a un tercio.

Por qué el 52% es la cifra interesante

Un Spec@3 estructural del 92,7% significa que, en tres intentos, casi siempre sale un circuito bien formado: geometría legal, capas correctas, reglas del PDK respetadas. Un Spec@3 funcional del 52% significa que, en los casos difíciles, la mitad de esos circuitos bien formados no hace lo que se pidió. Es la misma brecha que aparece en generación de código al pasar de compila a supera los tests, y explica por qué el paso de simulación no es decorativo en este tipo de sistemas.

Qué se lleva de aquí quien monta agentes

La lección transferible no es fotónica. PICasso rinde porque nadie deja que el modelo emita el artefacto final: emite YAML, y ese YAML pasa por el PDK, por DRC/LVS y por un simulador antes de convertirse en GDS. Es la forma clásica de un pipeline con herramientas externas, el patrón que en el ecosistema Claude se implementa con MCP servers: el modelo propone, la herramienta verifica y el resultado de la verificación vuelve al bucle. Cuando el dominio tiene un validador objetivo y barato de ejecutar, ese diseño rinde bastante más que pedirle al modelo que se autocorrija leyendo su propia salida.

Vale la pena mirar también lo que el paper no dice. Treinta y seis tareas son pocas para hablar de cobertura, la robustez ante perturbaciones se mide dentro del mismo benchmark que se propone, y nada en el abstract sugiere que el diseñador humano salga del bucle.

Nos parece un trabajo útil sobre todo por PIC-Set. Un benchmark público que separa lo estructural de lo funcional obliga a que la próxima demo de diseño automático se mida por lo que el circuito hace, no por lo limpio que queda el layout.