Autores:
(1) Mingjie Liu, NVIDIA {Contribución igual};
(2) Teodor-Dumitru Ene, NVIDIA {Contribución igual};
(3) Robert Kirby, NVIDIA {Contribución igual};
(4) Chris Cheng, NVIDIA {Contribución igual};
(5) Nathaniel Pinckney, NVIDIA {Contribución igual};
(6) Rongjian Liang, NVIDIA {Contribución igual};
(7) Jonás Alben, NVIDIA;
(8) Himyanshu Anand, NVIDIA;
(9) Sanmitra Banerjee, NVIDIA;
(10) Ismet Bayraktaroglu, NVIDIA;
(11) Bonita Bhaskaran, NVIDIA;
(12) Bryan Catanzaro, NVIDIA;
(13) Arjun Chaudhuri, NVIDIA;
(14) Sharon Clay, NVIDIA;
(15) Bill Dally, NVIDIA;
(16) Laura Dang, NVIDIA;
(17) Parikshit Deshpande, NVIDIA;
(18) Siddhanth Dhodhi, NVIDIA;
(19) Sameer Halepete, NVIDIA;
(20) Eric Hill, NVIDIA;
(21) Jiashang Hu, NVIDIA;
(22) Sumit Jain, NVIDIA;
(23) Brucek Khailany, NVIDIA;
(24) George Kokai, NVIDIA;
(25) Kishor Kunal, NVIDIA;
(26) Xiaowei Li, NVIDIA;
(27) Charley Lind, NVIDIA;
(28) Hao Liu, NVIDIA;
(29) Stuart Oberman, NVIDIA;
(30) Sujeet Omar, NVIDIA;
(31) Sreedhar Pratty, NVIDIA;
(23) Jonathan Raiman, NVIDIA;
(33) Ambar Sarkar, NVIDIA;
(34) Zhengjiang Shao, NVIDIA;
(35) Hanfei Sun, NVIDIA;
(36) Pratik P. Suthar, NVIDIA;
(37) Varun Tej, NVIDIA;
(38) Walker Turner, NVIDIA;
(39) Kaizhe Xu, NVIDIA;
(40) Haoxing Ren, NVIDIA.
La colección se implementó con un conjunto de scripts de shell y Python, diseñados para identificar documentación y datos de diseño relevantes, convertirlos a texto sin formato, si corresponde, filtrarlos usando métricas de calidad básicas, calcular una suma de verificación para una deduplicación precisa de archivos y comprimirlos para su almacenamiento. El flujo de recopilación no utilizó scripts de recopilación y extracción específicos de LLM disponibles en el mercado, ya que nuestro objetivo era minimizar los requisitos de espacio mediante la recopilación de datos in situ de fuentes de datos internas (tanto sistemas de archivos en red como aplicaciones web internas). Para la recopilación basada en el sistema de archivos, los datos se mantuvieron en el lugar mientras se filtraban por calidad, en lugar de almacenar conjuntos adicionales de datos sin procesar localmente.
La recopilación de datos de diseño y verificación abarcó una variedad de archivos fuente, incluidos Verilog y VHDL (RTL y netlists), C++, Spice, Tcl, varios lenguajes de secuencias de comandos y archivos de configuración relacionados con la compilación. Los datos de los servicios web internos se recopilaron mediante llamadas API REST y rastreo convencional, y el formato HTML se eliminó utilizando la biblioteca Python de código abierto BeautifulSoup [52] en ambos casos para minimizar la eliminación inadvertida de ejemplos de codificación, a costa de introducir más calderas. barras de navegación de placas y otros elementos de la página HTML. Nuestro flujo de recopilación de datos admitía formatos de documentación convencionales, incluidos .docx, .pptx y .pdf, utilizando bibliotecas de conversión de Python y herramientas de código abierto disponibles.
Como se cree que la mayoría de los datos internos son de alta calidad, se aplicó un filtrado mínimo: se utilizó un filtrado de recuento de líneas para garantizar que se excluyeran los archivos extremadamente grandes o pequeños, y los archivos se clasificaron en categorías amplias, escritas manualmente o generadas por herramientas.
En esta sección presentamos resultados detallados sobre nuestros modelos preentrenados adaptativos de dominio. También detallamos nuestros experimentos de ablación sobre preentrenamiento adaptativo de dominio.
Hiperparámetros DAPT: Detalles presentados en la Tabla VI.
Resultados de la evaluación automática: presentamos resultados detallados sobre los puntos de referencia de la evaluación automática en la Tabla VII y la Tabla VIII. Para simplificar, en el resto de la sección presentamos resultados de referencia agregados para estudios de ablación:
• Chip : informamos resultados promedio en pruebas comparativas de diseño, secuencias de comandos, errores y circuitos en el dominio de la Tabla III (5 tomas).
• MMLU: Informamos los resultados generales de MMLU (5 disparos) [22], un punto de referencia agregado popular sobre una amplia variedad de temas.
• Razonamiento : Informamos resultados promedio en puntos de referencia públicos populares sobre razonamiento de sentido común (0-shot), incluidos Winogrande [53], hellaswag [54], ARC-easy [55] y RACE-High [56].
• Código : informamos la tasa de aprobación promedio de los puntos de referencia de codificación con decodificación voraz, incluidos HumanEval [23], VerilogEval-Machine [12] y VerilogEval-Human [12].
Aumento del tokenizador: experimentamos con DAPT utilizando el tokenizador LLaMA2 original y el tokenizador aumentado como se describe en la Sección III-A. La Figura 11 muestra la pérdida de entrenamiento suavizada para ChipNeMo con el tokenizador original sin modificar. En comparación con la Figura 2, observamos que un tokenizador aumentado tiene una mayor pérdida de entrenamiento durante la inicialización, debido a que nunca se observan tokens agregados durante el entrenamiento previo del modelo básico. Se logra una pérdida de entrenamiento similar para DAPT con 1 época.
La Tabla IX presenta los resultados agregados de las evaluaciones comparativas de automóviles. Observamos que el aumento cuidadoso del tokenizador y la inicialización del peso solo afectan ligeramente el rendimiento del modelo en los puntos de referencia académicos generales. DAPT mejoró significativamente los puntos de referencia de dominio con cualquier tokenizador, incluida la codificación Verilog (sin diferencias importantes en HumanEval). Concluimos que aumentar el tokenizador conlleva el beneficio de una mejora del tokenizador y de la eficiencia del entrenamiento sin degradación del lenguaje general del modelo ni de las capacidades de dominio.
Combinación de conjuntos de datos públicos: como se presentó en la Sección II-A, incluimos datos públicos en DAPT, tomados de conjuntos de datos públicos de uso común para el entrenamiento previo del modelo básico. Principalmente esperábamos que la combinación de datos públicos como Wikipedia en DAPT pudiera ayudar a "corregir" las perturbaciones provocadas por el aumento del tokenizador y mejorar las capacidades generales del lenguaje natural.
de modelos. Realizamos otra ronda de DAPT con aumento de tokenizador utilizando solo los datos del dominio, entrenando para la misma cantidad de pasos que equivalen aproximadamente a 1,1 época de los datos. Descubrimos que la combinación de datos públicos mejora ligeramente los resultados. Presentamos resultados detallados en la Tabla X.
La Figura 12 muestra la pérdida de entrenamiento para ChipNeMo-7B con tokenizadores aumentados que incluyen la combinación de conjuntos de datos públicos. Observamos grandes picos en la pérdida de entrenamiento en los pasos de entrenamiento iniciales y la pérdida de entrenamiento final para los modelos 7B fue incluso mejor que los hiperparámetros DAPT originales de 13B. Sin embargo, observamos una degradación sustancial en los puntos de referencia del lenguaje natural, como se muestra en la Tabla XII, incluido el diseño de chips en el dominio. Las capacidades de codificación mejoraron de acuerdo con los hallazgos de [32].
Destacamos que nuestro caso difiere del de [32]. Aunque también llevamos a cabo una inicialización de “preentrenamiento continuo” desde puntos de control previamente entrenados, preferiblemente queremos que el modelo mantenga altos grados de rendimiento en capacidades generales, mientras
destilar información y conocimiento del conjunto de datos del dominio (no visto en el preentrenamiento del modelo) en pesos del modelo. Por el contrario, [32] utilizan datos de código disponibles públicamente que carecen predominantemente de elementos de lenguaje natural, enfatizando su enfoque principal en tareas relacionadas con la codificación. Nuestra hipótesis es que una tasa de aprendizaje más pequeña jugó un doble papel para la adaptación del dominio, facilitando la destilación del conocimiento del dominio a través de DAPT y al mismo tiempo manteniendo un equilibrio que no se desvió demasiado del modelo base, preservando así las capacidades generales del lenguaje natural y mejorando significativamente el rendimiento en -tareas de dominio
Ajuste eficiente de parámetros (PEFT): el ajuste eficiente de parámetros congela los pesos del modelo previamente entrenado e inyecta parámetros entrenables en modelos de adaptadores más pequeños para un ajuste eficiente de las tareas posteriores. Exploramos el uso de PEFT en DAPT mediante Adaptación de bajo rango (LoRA) [16]. Dado que nuestra implementación de capa transformadora fusiona KQV en una sola proyección, agregamos adaptadores LoRA para una única proyección de bajo rango para cada capa de autoatención de manera combinada. Experimentamos en modelos LLaMA2-13B con el tokenizador LLaMA2 original, utilizando las mismas configuraciones de entrenamiento DAPT en la Tabla VI. Realizamos dos experimentos, introduciendo parámetros entrenables adicionales de 26,4 millones (pequeños) y 211,2 millones (grandes) respectivamente.
La Figura 13 muestra las curvas de pérdida de entrenamiento de los modelos LoRA y las compara con el entrenamiento con parámetros completos. Para ambos modelos LoRA, la pérdida converge rápidamente y deja de disminuir más allá de cierto punto. La Tabla XIII informa los resultados de la evaluación de los modelos LoRA. Ambos modelos LoRA tienen un rendimiento significativamente inferior al entrenamiento completo de parámetros en tareas de diseño de chips en el dominio. Los modelos LoRA mejoran en las tareas de diseño de chips en comparación con sus homólogos sin DAPT, y el modelo más grande muestra resultados ligeramente mejores (pero no significativos).
Generar muestras de capacitación manualmente requiere mucho esfuerzo, por lo que elegimos implementar un proceso para generarlas automáticamente. Dado que utilizamos el aprendizaje contrastivo para ajustar nuestro modelo, cada muestra requiere un conjunto de pasajes positivos y negativos, particularmente negativos duros para maximizar la precisión.
1) Procedimiento de muestreo del conjunto de datos: la Figura 14 describe los pasos seguidos para generar una muestra:
• Paso 1: seleccione aleatoriamente un pasaje del corpus del documento
• Paso 2: Utilice un modelo de lenguaje (Vicuña) para generar una consulta válida a partir del pasaje
• Paso 3: Utilice un modelo de recuperación preexistente (transformador de oraciones) para recuperar los N pasajes principales del corpus del documento para la consulta donde cada pasaje es potencialmente negativo.
• Paso 4: Es posible que algunos de los pasajes recuperados sean realmente positivos, así que utilice el mismo modelo de lenguaje para filtrar los pasajes positivos.
• Paso 5: Si no hay suficientes pasajes negativos después de este proceso de filtrado, complemente con pasajes aleatorios del corpus
Para nuestra investigación inicial utilizamos Vicuña [4] y Sentence Transformer [33]; sin embargo, pueden reemplazarse fácilmente con LLaMA2 [5] y BM25 [42] respectivamente para producir un modelo de recuperación que sea comercialmente viable.
2) Comparación de la calidad de los hits: no todos los hits son iguales. El pasaje del siguiente ejemplo de especificaciones responde clara y completamente a su consulta. El pasaje del ejemplo de compilación contiene la respuesta; sin embargo, se requiere más contexto para responder la consulta.
Ejemplo de especificación: el pasaje de acceso responde claramente a la consulta.
Ejemplo de compilación: se requiere información adicional para responder completamente la consulta. Por ejemplo: ¿Qué es una licencia de manejar? ¿Cómo sabemos que Arch-Build-Hotseat-XXX es una licencia de manejar?
D. Datos de evaluación adicionales
La Tabla XIV muestra los datos de evaluación de todos los modelos en la aplicación chatbot asistente de ingeniería.
La Tabla XV muestra los resultados de nuestra evaluación para todos los modelos en la tarea de generación de scripts EDA.
La Tabla XVI muestra los resultados de nuestra evaluación para todos los modelos en la tarea de análisis y resumen de errores.
1) Chatbot asistente de ingeniería:
2) Generación de scripts EDA: algunos nombres de funciones y comandos están ofuscados.
3) Resumen y análisis de errores: los nombres de usuario, los nombres de los chips y las rutas están ofuscados.
Este documento está disponible en arxiv bajo licencia CC 4.0.