💻 computer science

MultModLM: A multi-modal benchmark for Large-Language Model based hardware schematic generation

Este artículo presenta MultModLM, un referente multimodal y un marco de evaluación integral para evaluar la capacidad de los Grandes Modelos de Lenguaje para generar esquemas de hardware a partir de descripciones RTL, revelando que, si bien los modelos producen resultados visualmente interpretables, tienen dificultades con la corrección funcional y que los evaluadores basados en LLM no son fiables para juzgar la precisión estructural en el diseño de hardware.

Autores originales: Dhruv Kulkarni, Sai Manoj Pudukotai Dinkarrao

Publicado 2026-06-29✓ Author reviewed ⓘ

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Dhruv Kulkarni, Sai Manoj Pudukotai Dinkarrao

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes a un bibliotecario muy inteligente y culto (el Modelo de Lenguaje Grande, o LLM) que sabe escribir historias sobre máquinas. Ahora, imagina que le pides a este bibliotecario que dibuje el plano de una máquina basándose únicamente en una descripción escrita de cómo funciona esa máquina.

Este artículo, titulado MultModLM, es esencialmente una boleta de calificaciones para estos "bibliotecarios" cuando intentan dibujar estos planos de máquinas (llamados esquemáticos de hardware) a partir de código escrito (llamado RTL).

Aquí está el desglose de lo que hicieron los autores y lo que encontraron, utilizando analogías sencillas:

1. El Problema: El "Eslabón Perdido"

Normalmente, cuando los ingenieros diseñan chips de computadora, escriben código (RTL) y luego utilizan un software especializado y costoso para convertir ese código en un dibujo visual (un esquemático). Es como tener una receta y necesitar que un chef profesional dibuje una imagen del plato.

Recientemente, los modelos de IA se han vuelto excelentes escribiendo código, pero nadie había probado si podían dibujar los diagramas de la máquina a partir de ese código. No había una "prueba" para ver si la IA podía hacer esto. Los autores crearon esta prueba, llamada MultModLM.

2. La Prueba: 99 Diferentes Rompecabezas

Los investigadores reunieron 99 diferentes "rompecabezas". Estas eran descripciones escritas de circuitos digitales, que iban desde contadores simples hasta complejas máquinas de verificación de números.

El Desafío: Entregaron estas descripciones escritas a dos de los mejores modelos de IA (GPT y Gemini) y les pidieron que dibujaran los diagramas del circuito.
El Giro: A diferencia de un problema matemático donde hay una sola respuesta correcta, hay muchas formas de dibujar la misma máquina. Al igual que puedes dibujar una casa con un techo rojo o uno azul y sigue siendo la misma casa, la IA podía dibujar el circuito de diferentes maneras. Esto hizo que calificar las respuestas fuera muy complicado.

3. El Sistema de Calificación: Un Panel de Jueces

Dado que no había un dibujo único "correcto", los autores no pudieron simplemente usar una computadora para verificar si el dibujo estaba bien. En su lugar, construyeron un panel de jueces de múltiples etapas:

El Artista se Califica a sí Mismo: La IA dibujó la imagen y luego calificó su propio trabajo.
El Juez Rival: El otro modelo de IA observó el dibujo y lo calificó contra el código original.
El Juez Ciego: Una IA miró solo el dibujo (sin ver el código) para ver si el dibujo tenía sentido por sí mismo.
El Experto Humano: Ingenieros reales observaron los dibujos para ver si eran realmente correctos.

Utilizaron una lista de verificación (rúbrica) para calificar aspectos como: "¿Se conectaron los cables correctamente?", "¿Se muestra la señal de reloj?", "¿Es el dibujo fácil de leer?".

4. El Gran Descubrimiento: Los Jueces de IA no tienen Ni Idea

Esta es la parte más sorprendente del artículo.

El Resultado: Cuando los investigadores compararon las puntuaciones dadas por los jueces de IA contra las puntuaciones dadas por los expertos humanos, encontraron casi cero concordancia.
La Analogía: Imagina que le pides a un robot que califique una pintura. El robot le da un 10/10 porque es colorida. El experto humano le da un 2/10 porque la perspectiva es incorrecta. El artículo encontró que los jueces de IA estaban esencialmente "adivinando" o alucinando cuando intentaban calificar estos dibujos técnicos. Estaban completamente desincronizados con los expertos humanos.

5. La Conclusión: La IA Puede Dibujar, Pero No Puede Verificar

El artículo concluye dos cosas principales:

La IA puede intentar dibujar: Los modelos pudieron producir imágenes que parecían diagramas de circuitos. No eran perfectos, pero eran visualmente interpretables.
La IA no puede ser el árbitro: No puedes confiar en una IA para decirte si un diseño de hardware es correcto. El método de "IA como juez", que funciona bien para escribir ensayos o código de texto, falla por completo cuando se trata de verificar la precisión estructural de los diagramas de hardware.

En resumen: Los autores construyeron una prueba para ver si la IA puede convertir código en imágenes de máquinas. Encontraron que, si bien la IA puede intentar dibujar las imágenes, es pésima calificándolas. Si quieres saber si un diseño de hardware es correcto, todavía necesitas a un experto humano, no a otra IA.

Basado en el documento proporcionado, aquí hay un resumen técnico detallado de MultModLM.

Planteamiento del Problema

Si bien los Modelos de Lenguaje de Gran Escala (LLMs) han visto una creciente adopción en el desarrollo de hardware para tareas como la generación de código, depuración y evaluación basada en texto, existe una brecha significativa en las tareas de hardware multimodales. Específicamente, no existe un benchmark actual para evaluar la capacidad de los LLMs para generar esquemas de hardware a partir de descripciones RTL (Register Transfer Level).

Esta brega es crítica porque:

No Unicidad de los Esquemas: A diferencia del código, donde a menudo se requiere un output específico, múltiples esquemas estructuralmente diferentes pueden ser funcionalmente equivalentes. Esto hace que definir una única "verdad fundamental" (ground truth) sea imposible.
Desafíos de Evaluación: Los outputs visuales no pueden ser directamente simulados o verificados formalmente de la misma manera que el código. Las herramientas EDA tradicionales (por ejemplo, Synopsys, Cadence) requeridas para la generación de esquemas son costosas y requieren un alto conocimiento especializado, lo que limita la accesibilidad para los investigadores.
Fiabilidad de los Jueces Automatizados: Existe una falta de comprensión sobre si los LLMs pueden evaluar de manera confiable la corrección estructural y funcional en dominios de hardware, un prerrequisito para una evaluación automatizada escalable.

Metodología

Los autores presentan MultModLM, un nuevo benchmark y un marco de evaluación de múltiples etapas diseñado para abordar estos desafíos.

1. Construcción del Conjunto de Datos (Dataset)

Alcance: El conjunto de datos consiste en 99 módulos RTL diversos provenientes de repositorios abiertos (por ejemplo, OpenRISC) y generación humana.
Composición: Los módulos cubren unidades aritméticas, máquinas de estados finitos (FSM), lógica de control y verificadores de propiedades numéricas (por ejemplo, detección de números de Armstrong, detección de palíndromos).
Complejidad: Los diseños varían desde circuitos combinacionales pequeños (1–20 líneas) hasta diseños secuenciales de múltiples etapas (hasta más de 430 líneas).
Verdad Fundamental (Ground Truth): No se proporcionan esquemas de verdad fundamental debido a la no unicidad de las representaciones de los esquemas. La corrección se evalúa mediante la equivalencia funcional con la descripción RTL a través de una rúbrica estructurada.

2. Pipeline de Evaluación
Para superar las limitaciones de la evaluación de un solo método, los autores proponen un pipeline de cinco etapas:

Prompting: Se instruye a los modelos para generar una imagen PNG clara e interpretable del esquema basada en el código RTL. Se aplican restricciones estrictas para evitar que los modelos recuperen imágenes externas o proporcionen únicamente explicaciones de texto.
Auto-evaluación: El modelo generador evalúa su propio output contra una rúbrica predefinida para establecer una línea base de sesgo de auto-evaluación.
Evaluación Cruzada con Anclaje (Grounded Cross-Evaluation): Un segundo modelo evalúa el esquema del modelo objetivo con acceso al código RTL original. Esto aproxima la evaluación objetiva al verificar la equivalencia lógica.
Evaluación Cruzada Ciega (Blind Cross-Evaluation): El segundo modelo evalúa el esquema sin acceso al código RTL para medir la coherencia visual y la auto-consistencia.
Evaluación Humana: Evaluadores humanos realizan una verificación estructurada utilizando la misma rúbrica para proporcionar una evaluación independiente.

3. Métricas de Evaluación

Calificación Basada en Rúbrica: Se utiliza una rúbrica definida en JSON con 8 criterios (por ejemplo, Fidelidad Estructural, Representación de la Ruta de Datos, Precisión de Reloj, Etiquetado de Señales). Cada criterio se califica como un Booleano Verdadero/Falso para evitar la subjetividad de las escalas graduadas.
Análisis Estadístico: Se calcula el Kappa de Cohen ( $\kappa$ ) para medir el acuerdo entre los evaluadores humanos y los evaluadores basados en LLM.
Precisión (Accuracy): Medida por el número de criterios de la rúbrica cumplidos (máximo 8 puntos por prompt).

Contribuciones Clave

Benchmark MultModLM: El primer benchmark multimodal específicamente diseñado para evaluar la generación de RTL a esquema utilizando LLMs.
Marco de Evaluación Estructurado: Un nuevo pipeline que combina la calificación basada en rúbricas, la evaluación entre modelos y la validación humana para manejar la no unicidad de los outputs de los esquemas.
Evidencia Empírica sobre LLM-como-Juez: El trabajo proporciona datos que demuestran las limitaciones de usar LLMs como evaluadores en dominios de precisión estructural.

Resultados Experimentales

El estudio evaluó modelos de última generación (GPT 5.2 Go y Gemini 3 Flash Pro) en el dataset de 99 módulos.

Fiabilidad del LLM-como-Juez: El hallazgo más significativo es que los evaluadores basados en LLM exhiben un acuerdo cercano a cero con los evaluadores humanos.
- Kappa de GPT vs. Humano: 0.013
- Kappa de Gemini vs. Humano: 0.000
- Esto indica que los LLMs son actualmente poco fiables como jueces automatizados para la corrección de esquemas de hardware, incluso cuando se les proporciona el código RTL de anclaje.
Desempeño del Modelo:
- Gemini mostró una precisión marginalmente mayor (0.314) que GPT (0.297) cuando fue calificado por el modelo secundario.
- Gemini funcionó mejor en criterios semánticos y funcionales (C1–C6), lo que sugiere que preserva mejor el núcleo lógico del RTL.
- GPT logró puntuaciones ligeramente más altas en criterios orientados a lo visual (C7–C8), aunque los autores señalan que esto puede reflejar la limpieza del diseño más que la adherencia estricta a las convenciones de esquemas.
Comparación de Ganador/Perdedor: En comparaciones por pares, Gemini ganó 37 prompts, GPT ganó 33, y 29 resultaron en empates.

Significancia y Reivindicaciones

El artículo afirma que MultModLM expone un cuello de botella fundamental en el campo: la incapacidad de evaluar de manera confiable los outputs multimodales de hardware.

Limitación del LLM-como-Juez: El acuerdo cercano a cero entre los LLM y los humanos revela que los LLM actuales no pueden ser confiables para evaluar la corrección estructural y funcional en dominios de hardware. Esto desafía la aplicabilidad de los paradigmas de "LLM-como-juez" en campos que requieren un razonamiento estructural preciso.
Necesidad de Nuevas Metodologías: Los hallazgos motivan el desarrollo de metodologías de evaluación más robustas y conscientes del dominio, así como de herramientas para la evaluación estructural (por ejemplo, verificadores de equivalencia formal) que puedan servir como proxies de la verdad fundamental a escala.
Dirección Futura: Si bien el conjunto de datos actual está destinado a la evaluación y no al entrenamiento, los autores sugieren que el trabajo futuro debería centrarse en extender el dataset para el ajuste fino (fine-tuning) y desarrollar herramientas automatizadas para cerrar la brecha entre los outputs visuales y la verificación formal.

El artículo concluye que, si bien los LLM pueden generar esquemas visualmente interpretables, su corrección funcional sigue siendo limitada, y la evaluación confiable de estos outputs sigue siendo un desafío abierto.