Transcripción de ChipAgents: Cómo la IA agéntica está revolucionando los flujos de trabajo de EDA y diseño de chips
11 de junio de 2025 - Entrevista de Semiconductor Engineering con ChipAgents
Comprendiendo la transición de los LLM a la IA agéntica
Ann Mutschler: Soy Ann Mutschler, editora ejecutiva sénior en Semiconductor Engineering. Estoy aquí en ChipAgents con Mahir Arora para hablar sobre la IA agéntica. Mahir, gracias por acompañarme hoy. ¿Podrías explicar qué es la IA agéntica y qué significa para el diseñador de chips?
Mahir Arora: Los modelos de lenguaje extensos, o LLM, son una tecnología extremadamente reciente, y los agentes de IA son una tecnología aún más nueva. Ninguna de las dos se ha propagado realmente por completo en el panorama de EDA. Para hablar realmente de la diferencia entre los agentes de IA y los LLM, hay que remontarse a qué son exactamente los LLM y a algunas de sus deficiencias en el espacio del hardware; después podremos hablar de los agentes de IA y de cómo esto mejora las cosas a largo plazo para los ingenieros de diseño de hardware y los equipos de verificación. Creo que la mayoría de la gente está familiarizada con los LLM desde una perspectiva práctica. Todo el mundo ha utilizado algo como ChatGPT para tareas como redactar correos electrónicos, por ejemplo.
[Descripción visual: Mahir está de pie frente a una pizarra donde ha dibujado diagramas que explican la mecánica de los modelos de lenguaje extensos y el bucle de retroalimentación iterativo de la IA agéntica.]
Mahir Arora: He escrito algunas cosas en esta pizarra para explicar conceptos básicos sobre los LLM y los agentes de IA. Tendrán que disculpar mi letra, pero la idea central de los LLM es que realizan algo llamado predicción autorregresiva de tokens o modelado de secuencias autorregresivo. Los detalles de lo que esto significa son bastante sencillos. Si tienes un LLM potente, como GPT-4o, puedes plantearle una pregunta. La forma de proporcionar esa pregunta sería, por ejemplo: "¿cuánto es 2 más 2?". Esto se tokenizará. El método exacto de tokenización no es tan importante, pero la entrada se divide en partes que el LLM realmente puede entender. Una vez que proporcionas esta entrada, también puedes añadir un preámbulo, como: "la respuesta a 2 más 2 es". Lo que los LLM están fundamentalmente entrenados para hacer es rellenar este espacio en blanco al final. Hay una especie de incógnita, una máscara, que se coloca al final, y están entrenados para intentar predecir ese token.
Mahir Arora: Concretamente, desde el punto de vista matemático, lo que hacen los LLM es predecir una distribución de probabilidad. Dados todos los tokens de entrada previos, queremos intentar predecir cuál es el valor de la incógnita. Debido a que obtendrás una distribución de probabilidad al final y dado que tenemos un LLM potente que es bueno en esta tarea de predicción de tokens, para "2 más 2", sugerirá fuertemente que el resultado es 4. En mi ejemplo de juguete en la pizarra, muestra aproximadamente un 99% de probabilidad de que sea 4, un 1% de probabilidad de que sea 5, y una probabilidad de una en mil millones de que aparezca algo como "Madagascar", porque es solo una palabra aleatoria del idioma inglés, o de cualquier otro idioma en el caso de los LLM multilingües. Esto es genial para responder a una pregunta particular en esta forma artificial donde tenemos un prompt y solo queremos rellenar el espacio en blanco. Pero, ¿qué pasa si queremos algo más que simplemente rellenar espacios?
Mahir Arora: Para lograrlo, llegamos al modelado de secuencias autorregresivo. "Auto" significa a sí mismo, y "regresivo" es básicamente volver a sí mismo, por eso se llama autorregresivo. La idea es que, si quiero que mi LLM rellene una función completa, genere una página de texto, un ensayo entero o potencialmente una base de código completa, quiero que pase por el mismo proceso de modelar la distribución de salida potencial de un token, pero haciéndolo muchas, muchas veces. Aquí en la pizarra, he introducido en mi modelo un par de tokens de entrada para una función llamada "add", con un paréntesis de apertura. Ahora tengo el mismo problema que antes. Tengo que predecir este token faltante, al que he llamado "máscara". Hay un par de posibilidades para las salidas. Por ejemplo, podríamos obtener el token "num1" al final, o podríamos obtener un token como "a". Hay una probabilidad asignada a cada una de estas salidas. La magia proviene realmente del muestreo. Basándonos en esta distribución de probabilidad, podemos muestrear un token de salida potencial. Por ejemplo, podríamos muestrear "num1" o "a". En este caso, digamos que muestreamos "a". Ahora tomamos este token "a", lo volvemos a introducir en la entrada y continuamos el proceso. En el paso dos, tenemos "function add, paréntesis de apertura, a", y ahora el problema se repite. Podemos volver a introducir esto directamente para modelar autorregresivamente la siguiente secuencia.
El poder de la autorreflexión y los bucles de retroalimentación
Ann Mutschler: También iba a preguntarte sobre la autorreflexión. ¿Cómo interviene esto?
Mahir Arora: Esa es una gran pregunta. Para hablar de autorreflexión, tenemos que hablar un poco de lo que sucede una vez que pasas por n repeticiones de este proceso. Una vez que hemos pasado por n repeticiones, llegamos a la salida completa, que podría verse como: "function add, a coma b, return a plus b", y luego predice un token de parada para finalizar el proceso autorregresivo. Lo que notarás en este proceso es que cuando tomo una decisión, que es el proceso de muestreo donde elijo incluir "a" como mi salida, tengo que vivir con esa decisión. Cuando estoy devolviendo algo más adelante en la secuencia, no puedo cambiar de opinión de repente. Tengo que decir "return a plus b". No puedo decir "return num1 plus num2". Básicamente, las decisiones pasadas pueden informar mis decisiones futuras, pero lo contrario no es cierto. ¿Qué pasa si cometí un error en mi proceso de muestreo? ¿Qué pasa si, en lugar de "a", simplemente emití un paréntesis de cierre? Bueno, ahora estoy atascado. Fundamentalmente, voy a emitir algo incorrecto. La información no puede fluir en la otra dirección. ¿Cómo pasas de las decisiones futuras a impactar las decisiones pasadas? La consecuencia directa es que, si tengo decisiones pasadas incorrectas, garantizo decisiones futuras incorrectas, lo que garantiza un resultado general incorrecto. Esto nos vincula directamente con la autorreflexión, el refinamiento y la autocorrección. Ahí es donde entramos a continuación, y es donde podemos empezar a hablar de la IA agéntica.
Mahir Arora: Lo primero que hay que entender sobre los agentes es que se sitúan por encima de los LLM. Son una tecnología derivada de los LLM, pero la IA agéntica trata de todo un proceso, no simplemente de una utilización única de un LLM. Para hablar de agentes, autocorrección y cómo resuelven este problema fundamentalmente, tenemos que preparar el escenario.
Ann Mutschler: ¿Podrías profundizar en qué son los agentes?
Mahir Arora: Absolutamente. Para entender exactamente qué son los agentes, hay que comprender que la IA agéntica es un proceso. No es una única utilización de un LLM. Lo que realmente verás con los agentes es que son LLM acoplados a un proceso de búsqueda y, lo más crítico, a la retroalimentación. Utilizan la retroalimentación para autocorregirse, autoestabilizarse y, de hecho, ejecutar y tener éxito donde los LLM normalmente fallarían. Veamos un ejemplo práctico. Con un proceso agéntico, podrías tener como entrada para tu agente una tarea completa. Por ejemplo, quiero escribir un módulo Verilog, algo como un FIFO asíncrono. Los detalles del módulo no son demasiado importantes, pero lo que haremos es avanzar a través de varios turnos.
[Descripción visual: Mahir señala la pizarra ilustrando un proceso agéntico de varios turnos que cuenta con retroalimentación de compiladores, linters, bancos de pruebas y formas de onda.]
Mahir Arora: En el primer turno, el agente llamará a un LLM para producir una salida potencial. Producirá un archivo para mí, "fifo.sv", en SystemVerilog, que contiene este módulo. Pero seguimos teniendo todos los problemas con el modelado autorregresivo de antes, que se manifiestan en este primer turno. El agente puede establecer un conjunto de pines de entrada y decidir sobre ello, pero más adelante, podría usar una nueva entrada. Podría no haber definido un cable en algún lugar, pero ahora quiere usar ese cable. ¿Qué se supone que debe hacer? Si es solo un LLM, emitirá este código, te lo entregará, intentarás compilarlo y ejecutarlo, no funcionará y ese será el final de la historia. Eso no es lo que queremos. En realidad, queremos reflexión y retroalimentación. Lo siguiente que sucede después del turno uno es la retroalimentación. La retroalimentación puede provenir de muchas formas diferentes. Puede provenir de tus compiladores, tus linters o tus bancos de pruebas. Las aserciones pueden fallar, las pruebas pueden fallar, o puede haber salidas difíciles en tus registros que sugieran que algo anda mal, incluidas las salidas de formas de onda. Todas estas cosas son salidas que el proceso agéntico examinará. Introduces esta retroalimentación en el agente. El agente examinará esto en el contexto de su salida anterior y sintetizará que algo anda mal. Se dedicará a depurarlo, a averiguar cómo solucionar ese proceso y luego repetirá. Pasamos por el turno dos donde soluciona estos problemas, y luego potencialmente obtenemos más retroalimentación. Por ejemplo, hay más pruebas que fallan, o hay algunas formas de onda que son inconsistentes con lo que esperamos de nuestro modelo de referencia ideal. El agente continuará y seguirá solucionando ese proceso. El objetivo final es que no solo obtengas una instancia de intento de producir un módulo, sino que tengas un sistema que se autocorrige y se autoestabiliza a través del proceso de retroalimentación, produciendo finalmente una implementación correcta y funcional.
Agentes de IA en EDA y el benchmark Verilog-Eval
Ann Mutschler: ¿Cómo aparecerán los agentes en las herramientas de EDA?
Mahir Arora: Esa es una gran pregunta. En ChipAgents, producimos un producto que está específicamente diseñado para EDA, utilizando agentes como parte de su flujo de EDA diario. Los detalles de cómo aparecen abarcan todo tipo de casos de uso diferentes. Una cosa que es muy importante notar sobre los agentes es que el rendimiento de los LLM en hardware en comparación con el rendimiento de los agentes en hardware es dramáticamente diferente. Existe un benchmark muy común que se utiliza llamado Verilog-Eval, que fue construido por Nvidia. Lo que notarás es que, cuando utilizas un LLM estándar en estos benchmarks, donde la tarea es pasar de una descripción en lenguaje natural a una salida de módulo Verilog funcional, el rendimiento es realmente abismal. Puedes usar un modelo de lenguaje potente como GPT-4o, que funciona extremadamente bien en tareas de software en Python, pero funciona terriblemente mal en tareas de Verilog, obteniendo aproximadamente un 50% de tasa de precisión. Una tasa de precisión del 50% es terrible. Es una calificación reprobatoria, y no queremos usar tecnología así. Pero resulta que, una vez que comienzas a envolver tus LLM en un proceso agéntico, el rendimiento se dispara enormemente. Empiezas a acercarte al rango del 80% y 90%. El sistema que he estado describiendo aquí representa estos procesos en sus términos más simples, pero puedes hacer mucho para mejorarlos. En última instancia, podemos llevar el rendimiento al nivel del 99% o 99,7%. Mediante el uso de agentes, hemos terminado saturando estos benchmarks. Si bien los LLM no son capaces de esto por sí solos, los agentes sí lo son.
Mahir Arora: Esto explica por qué los LLM no han aparecido en los flujos diarios de los ingenieros de hardware, porque los LLM estándar no son lo suficientemente fiables para ser utilizados en el tipo de tareas que interesan a los ingenieros. Los agentes de IA, sin embargo, son lo suficientemente fiables para ser utilizados en estas situaciones. La forma más común en que vemos a nuestros clientes utilizar agentes de IA hoy en día es para realizar prototipado muy rápido. Si eres un ingeniero de diseño, quieres explorar varias decisiones microarquitectónicas diferentes y evaluar la potencia, el rendimiento y el área en todas ellas. Quieres encontrar la frontera de Pareto y elegir la que mejor funcione para tu caso de uso. Pero hay mucho esfuerzo dedicado a configurar esos experimentos. Tienes que manejar scripts de compilación, entornos de compilación y entornos de simulación, y tienes que integrar tu módulo con el aparato existente que existe para ejecutar esas pruebas. Los agentes realmente hacen un trabajo fantástico aquí. Puedes proporcionar tu descripción de microarquitectura a un agente, y él saldrá y recopilará información de forma autónoma de tus repositorios, documentación, especificaciones y otras modalidades. Extraerá esa información y hará un plan a largo plazo sobre cómo ejecutarla. Manejará la implementación del módulo utilizando la autocorrección y la autoestabilización de las que hablamos para asegurarse de que el módulo sea de alta calidad, y luego también hace el trabajo duro de la integración. Lo configurará para que realmente se alinee con toda tu infraestructura existente, ejecute esas pruebas, extraiga información de esos registros y luego te informe.
Agilización de la verificación y el análisis de sistemas
Ann Mutschler: Mahir, mencionaste la verificación anteriormente, y ese es un gran desafío para cada equipo de verificación y diseño. ¿Cómo jugarán un papel los agentes de IA allí?
Mahir Arora: Esa es una gran pregunta. En el frente de la verificación, la razón por la que la verificación es tan difícil es por el aumento exponencial en la complejidad de los chips que nos interesa verificar. Estamos tratando con billones de transistores en este punto, miles de millones en un sistema en chip (SOC) individual, y billones en todo el sistema general. ¿Cómo se supone que debes manejar y mantener esa complejidad? El gran problema que tienen los ingenieros de verificación es que deben salir y construir una comprensión mental de todo sobre el subsistema en el que están trabajando para verificar. No solo estás verificando un módulo; estás verificando un subsistema completo a la vez, y potencialmente una gran parte de tu SOC a la vez. ¿Cómo extraes toda esa información en primer lugar? Si bien es muy difícil para un humano leer decenas de miles o cientos de miles de líneas de código, eso es algo para lo que los agentes de IA son muy capaces. Puedes configurar un agente de IA en una tarea abierta, como averiguar exactamente cómo fluyen los datos a través de un sistema complejo. Ese agente hará un plan jerárquico y de largo alcance sobre cómo ir a buscar esa información. Buscará en todos estos lugares diferentes, e incluso si se va y no encuentra información en un lugar determinado, autocorregirá su propio plan. Usará la información recopilada para encontrar dónde más buscar, reunirá toda esa información y te explicará cómo fluyen los datos a través del sistema. A partir de ese punto, ahora que sabes cómo fluyen los datos a través del sistema, tienes una idea mucho mejor de cómo verificarlo realmente, qué casos extremos debes considerar y qué estímulo necesitas proporcionar al sistema también.
El impacto diario en los equipos de diseño y verificación
Ann Mutschler: ¿Cómo se verá eso para el ingeniero de diseño y verificación hoy? ¿Qué verán en su día a día?
Mahir Arora: En términos más generales, esto es realmente impactante para los equipos. Los agentes de IA funcionan muy bien en manos de una persona que tiene demasiadas tareas en su plato. Si estás en el lado del diseño, tu tarea principal podría ser armar algún tipo de microarquitectura. Si estás en el lado de la verificación, es armar un plan de verificación y tratar de averiguar cómo navegar inteligentemente por tu sistema hacia todas estas condiciones, restricciones y casos extremos interesantes. Pero también tienes muchas tareas adicionales. Tienes que configurar tu banco de pruebas, configurar el entorno y tomar tu plan de pruebas y escribirlo en términos de, por ejemplo, UVM, lo que requiere escribir muchas secuencias UVM. Con los agentes de IA, puedes enviar todas estas tareas de forma asíncrona en segundo plano. Puedes hacer que los agentes de IA trabajen en todas estas tareas simultáneamente.
Mahir Arora: Para un ingeniero de verificación, el flujo que vemos a menudo hoy en día es que tomarán el plan de verificación que tienen y un banco de pruebas existente, quizás de un procesador de una generación anterior. Proporcionarán esa información al agente y le pedirán que amplíe el banco de pruebas con las nuevas secuencias o características que deben verificarse según lo especificado en el plan de verificación. Esto permitirá que los equipos más pequeños se sientan como equipos mucho más grandes, y eso es realmente emocionante. Nosotros mismos somos una startup y trabajamos con muchas startups, así como con corporaciones muy grandes. Los equipos más pequeños sentirán un gran multiplicador de fuerza por el uso de agentes de IA. De repente, un par de ingenieros sénior sentirán que son un equipo de ingenieros sénior apoyados por un montón de ingenieros júnior para ayudarlos, lo cual será muy emocionante.
Aceleración de la incorporación de ingenieros júnior
Ann Mutschler: También quería preguntar sobre los ingenieros júnior. ¿Cómo puede esto ayudarlos a ponerse al día más rápidamente?
Mahir Arora: Esa es una gran pregunta. El gran problema con la incorporación de alguien que es particularmente nuevo es que hay una enorme cantidad de código con el que trabajar. Tienen que construir un modelo mental de todo sobre la base de código para averiguar cómo empezar a ampliarla o verificarla. Entender dónde está todo representa una tarea excepcionalmente difícil para un ser humano. Tenemos ojos de tamaño humano y leemos a velocidades humanas. Los LLM y los agentes de IA pueden leer a velocidades mucho más rápidas, gracias a la tecnología subyacente de los LLM que les permite procesar cosas en paralelo. Debido a eso, puedes preguntarle a un agente cómo funciona exactamente el sistema y hacer que haga algo como construir un diagrama de bloques de cómo funciona una ruta de datos en particular. Los agentes de IA pueden irse, encontrar toda la información necesaria que necesitan y producir esa documentación para ti. Esa es una tarea muy común que vemos que hacen nuestros clientes. Realmente ayuda con la incorporación de ingenieros más nuevos, asegurándose de que tengan un modelo mental sólido de cómo funcionan estos procesadores y sistemas grandes.
Abordar la seguridad de la IP y las limitaciones de cómputo
Ann Mutschler: La seguridad es un problema con la IA. ¿Cómo se ve eso para los agentes de IA y ChipAgents?
Mahir Arora: La seguridad es siempre un punto importante. La propiedad intelectual (IP) de todos es extremadamente crítica. ¿Cómo mantienes realmente esa seguridad de la IP mientras aprovechas las enormes mejoras de productividad de los agentes de IA? Esto definitivamente depende de cada empresa y de cada cliente, porque si realmente quieres usar agentes de IA, tienes que usar mucho cómputo. Los mejores agentes de IA funcionan con los mejores y más grandes modelos base que posteriormente se ajustan con una gran cantidad de datos de entrenamiento de agentes, y esos requieren servidores realmente potentes. Habrá algunas organizaciones que tengan ese poder de cómputo de sobra que puedan usar para la IA agéntica, pero también habrá empresas que necesiten ir a la nube para alquilar tiempo de servidor en servidores GPU muy grandes.
Mahir Arora: Para ChipAgents en particular, atendemos a todo tipo de clientes diferentes. Algunos clientes se sienten más cómodos usando nuestros despliegues en la nube donde adquirimos tiempo de GPU. Hacemos inferencia para ellos, y las garantías que proporcionamos son que todos los datos están cifrados en tránsito y cifrados en reposo, o solo se procesan efímeramente en la memoria y luego se les devuelven. Ese es un compromiso que funciona muy bien para muchos clientes diferentes, incluidas las empresas públicas. Hay algunas empresas muy grandes que tienen restricciones muy particulares, y a menudo nos piden que realicemos el despliegue en su propia nube. Es muy común que vayamos a un cliente que tiene una cuenta de AWS, por ejemplo, y nos proporcionen acceso durante un breve período de tiempo para configurar todo esto para ellos, de modo que puedan utilizarlo internamente.
Ann Mutschler: Mahir, gracias por todas estas explicaciones.
Mahir Arora: Muchas gracias por tu tiempo.