Resumen Técnico: VEHBench

Planteamiento del Problema

El diseño de recolectores de energía vibratoria (VEH, por sus siglas en inglés) para dispositivos de Internet de las Cosidades (IoT) sin batería implica interacciones mecánico-eléctricas estrechamente acopladas y restricciones físicas estrictas (espectros de vibración, objetivos de potencia, límites de tamaño, propiedades de materiales y márgenes de seguridad). Aunque los Modelos de Lenguaje Extensos (LLM) se utilizan cada vez más como interfaces para los flujos de trabajo de ingeniería —traduciendo requisitos, revisando la retroalimentación y proponiendo modificaciones de diseño—, los benchmarks de ingeniería existentes evalúan principalmente la validez del artefacto final. Estas evaluaciones de punto final no logran revelar cómo se comportan los LLM a través de las distintas etapas de un flujo de trabajo de diseño físico acoplado. Específicamente, los benchmarks actuales no diagnostican si un modelo realiza correctamente el triaje de informes incompletos, realiza ediciones acotadas tras la retroalimentación física, se recupera de trayectorias de diseño corruptas o se adhiere a políticas de selección explícitas. Esta falta de diagnosticidad local por etapa dificulta la identificación de fallos específicos del flujo de trabajo (por ejemplo, errores de control de entrada frente a fallos de búsqueda) y obstaculiza la selección o el enrutamiento de modelos para roles de ingeniería específicos.

Metodología

Los autores presentan VEHBench, un benchmark diagnóstico nativo de la ingeniería diseñado para evaluar el co-diseño de VEH asistido por LLM mediante tareas con verificación local por etapa.

Construcción del Benchmark

• Dominio: El benchmark se centra en el co-diseño inicial de un VEH piezoeléctrico en voladizo (cantilever), un dominio compacto pero acoplado que involucra dinámica estructural, materiales inteligentes y diseño de circuitos.
• Fuente de Datos: Las tareas se derivan de una auditoría bibliográfica de 209 artículos, lo que resultó en 52 "anclas de diseño" limpias (estados físicos normalizados con variables, límites y restricciones).
• Verificación: Un oráculo físico analítico (basado en la teoría de vigas de Euler-Bernoulli de forma cerrada y ecuaciones de acoplamiento electromecánico) calcula la viabilidad y la calidad del objetivo. No se utilizan etiquetas humanas ni "LLM como juez" para la puntuación.
• Descomposición de Tareas: El flujo de trabajo se descompone en cuatro roles de diseño distintos (sondas), cada uno con estados de confianza, acciones admisibles y consecuencias de fallo específicos:
  1. P1 (Triaje de Especificaciones): El modelo recibe un informe de diseño (completo, incompleto o infactible) y debe decidir si proponer, abstenerse o solicitar información faltante.
  2. P2 (Búsqueda Guiada por Verificador): Dado un diseño semilla y la retroalimentación del oráculo, el modelo realiza ediciones acotadas para mejorar el candidato.
  3. P3 (Recuperación de Estado Corrupto): El modelo es expuesto a una trayectoria de diseño corrupta o engañosa y debe reiniciar, re-anclar o estabilizarse para escapar de la trampa.
  4. P4 (Selección Condicionada por Política): Dado un grupo de candidatos viables, el modelo clasifica o selecciona basándose en una política de ingeniería explícita (por ejemplo, priorizar la potencia frente a la fiabilidad).

Marco de Evaluación

• Modelos: Se evaluaron 12 ejecuciones completas de modelos (incluyendo Qwen, Gemini, DeepSeek, GPT, Hunyuan, etc.) a través de las 763 tareas.
• Métricas:
  • Métricas Principales: P1-Compuesta (puntuación de certificación ponderada), Ratio de Potencia Viable Final de P2, P3-Éxito (viabilidad final tras la recuperación) y P4 Kendall $\tau_b$ (consistencia de clasificación).
  • Perfiles Diagnósticos: Se extrajeron perfiles de control de respuesta (Disciplina de Acción, Estilo de Edición, Acondicionamiento de Retroalimentación, Esfuerzo de Reinicio de Estado, Ejecución de Política) de los registros para mapear los fallos con señales de comportamiento.
  • Familias de Errores: Se calcularon tasas de error no exclusivas (por ejemplo, sobre-acción, cierre infactible, fallo post-escape, desajuste de política) para identificar modos de fallo específicos.

Contribuciones Clave

1. Marco de Benchmark (VEHBench): El primer benchmark diagnóstico para el diseño de VEH asistido por LLM que va más allá de la validez del artefacto final para evaluar el comportamiento de diseño local por etapa. Combina la construcción de tareas basada en literatura, verificación analítica externa y evaluación específica por etapa.
2. Hallazgos Empíricos e Interpretación: Los autores evaluaron sistemáticamente los LLM actuales y encontraron que la capacidad depende fuertemente de la etapa. Ningún modelo domina todo el flujo de trabajo. Introdujeron un marco que vincula los resultados empíricos con características de comportamiento interpretables (por ejemplo, disciplina de acción, edición acotada, recuperación de estado).
3. Guía Consciente de la Etapa: El artículo demuestra cómo los resultados locales por etapa pueden informar aplicaciones prácticas de ingeniería, incluyendo la selección, el enrutamiento y la adaptación de modelos. Identifica brechas de capacidad específicas (por ejemplo, triaje de especificaciones, recuperación de estado corrupto) para futuros agentes de ingeniería.

Resultados Experimentales

• Rankings Dependientes de la Etapa: Ningún modelo lidera el flujo de trabajo completo.
  • P1 (Triaje): qwen3-max tuvo el mejor desempeño al equilibrar la disciplina de acción (suprimir entradas inseguras y omisiones de información faltante).
  • P2 (Búsqueda): gemini-3.1-pro-preview lideró debido a un alto cierre viable y ratios de potencia útiles.
  • P3 (Recuperación): hunyuan-hy3-preview destacó en la estabilización tras escapar de estados corruptos.
  • P4 (Selección): gpt-5.4 logró la mayor ejecución de política y consistencia de clasificación.
• Modos de Fallo:
  • P1: Los errores dominantes fueron la "sobre-acción" (proponer cuando los informes son infactibles) y las "omisiones de información faltante", en lugar de la sobre-negativa.
  • P2: La mayoría de los modelos pudieron seguir los protocolos de salida pero fallaron en cerrar el bucle de búsqueda física (cierre infactible) o sufrieron pérdida de utilidad.
  • P3: El principal cuello de botella no fue escapar de la trampa, sino la estabilización del estado posterior (fallo post-escape).
  • P4: Los fallos fueron principalmente de "desajuste de política" (no ejecutar las prioridades de ingeniería establecidas) en lugar de errores de procesamiento o selección de candidatos infactibles.
• Intervención y Enrutamiento:
  • Interfaz de Estado: Reemplazar el historial corrupto bruto con un resumen de estado redactado por un verificador mejoró las tasas de recuperación de P3 (de un 50.0% a un 63.2% de media) y redujo los fallos en cascada.
  • Enrutamiento: Un enrutador consciente de la etapa (que selecciona diferentes modelos para diferentes etapas) mejoró la puntuación normalizada media de retención de 0.892 (el mejor fallback de un solo modelo) a 0.945, principalmente al cambiar al especialista de P3.

Significancia y Reivindicaciones

El artículo sostiene que la capacidad de los LLM en el diseño de ingeniería depende del rol. Los rankings agregados son menos informativos que la compatibilidad por etapa. VEHBench proporciona una base para evaluar, seleccionar, enrutar y mejorar los LLM de ingeniería con verificación por oráculo, exponiendo dónde falla el comportamiento del flujo de trabajo.

Los autores enfatizan que VEHBench no es un reemplazo para las simulaciones de Método de Elementos Finitos (FEM), revisiones de fabricación o certificación de hardware. En cambio, sirve como una capa diagnóstica para determinar si un LLM utiliza apropiadamente las señales de validez física en cada etapa del diseño. El benchmark se limita al co-diseño analíticamente verificable de VEH en voladizo, señalando los autores que el mismo andamiaje puede instanciarse para simuladores más ricos y otros dominios acoplados. El trabajo argumenta que, para aplicaciones de ingeniería, el enfoque debe cambiar de un "diseño de hardware autónomo" a una "asistencia local por etapa", donde los modelos se seleccionan y enrutan basándose en sus perfiles de comportamiento específicos dentro del flujo de trabajo de diseño.