Riepilogo Tecnico: VEHBench

Problematica

La progettazione di sistemi di recupero di energia vibratoria (Vibration Energy Harvesters - VEH) per dispositivi Internet of Things (IoT) privi di batteria comporta interazioni meccanico-elettriche strettamente accoppiate e vincoli fisici rigorosi (es. spettri di vibrazione, obiettivi di potenza, limiti dimensionali, proprietà dei materiali e margini di sicurezza). Sebbene i Large Language Models (LLM) siano sempre più utilizzati come interfacce per i flussi di lavoro ingegneristici — traducendo requisiti, revisionando feedback e proponendo modifiche al design — i benchmark ingegneristici esistenti valutano principalmente la validità dell'artefatto finale. Queste valutazioni terminali non riescono a rivelare come i modelli si comportino attraverso le distinte fasi di un flusso di lavoro di progettazione accoppiata. Nello specifico, gli attuali benchmark non diagnosticano se un modello sappia correttamente smistare brief incompleti, apportare modifiche vincolate dopo un feedback fisico, recuperare da traiettorie di progettazione corrotte o aderire a esplicite politiche di selezione. Questa mancanza di diagnosticità locale per fase rende difficile identificare fallimenti specifici del workflow (es. errori di controllo d'ingresso rispetto a fallimenti di ricerca) e ostacola la selezione o l'instradamento dei modelli per specifici ruoli ingegneristici.

Metodologia

Gli autori introducono VEHBench, un benchmark diagnostico nativo per l'ingegneria progettato per valutare la co-progettazione di VEH assistita da LLM attraverso task locali per fase, basati su un verificatore.

Costruzione del Benchmark

• Dominio: Il benchmark si concentra sulla co-progettazione precoce di VEH piezoelettrici a cantilever, un dominio compatto ma accoppiato che coinvolge dinamica strutturale, materiali intelligenti e progettazione di circuiti.
• Fonte dei Dati: I task derivano da un audit della letteratura di 209 articoli, che ha prodotto 52 "ancore di design" pulite (stati fisici normalizzati con variabili, limiti e vincoli).
• Verifica: Un oracolo fisico analitico (basato sulla teoria del fascio di Euler-Bernoulli a forma chiusa e sulle equazioni di accoppiamento elettromeccanico) calcola la fattibilità e la qualità dell'obiettivo. Non vengono utilizzate etichette umane o "LLM-as-a-judge" per la valutazione del punteggio.
• Decomposizione dei Task: Il workflow è scomposto in quattro distinti ruoli di progettazione (sonde), ciascuno con stati fidati specifici, azioni ammissibili e conseguenze di fallimento:
  1. P1 (Triage della Specificazione): Il modello riceve un brief di progettazione (completo, mancante o inammissibile) e deve decidere se proporre, astenersi o richiedere informazioni mancanti.
  2. P2 (Ricerca Guidata dal Verificatore): Dato un design iniziale e il feedback dell'oracolo, il modello esegue modifiche vincolate per migliorare il candidato.
  3. P3 (Recupero da Stato Corrotto): Il modello viene esposto a una traiettoria di progettazione corrotta o fuorviante e deve resettare, ri-ancorare o stabilizzare per uscire dalla trappola.
  4. P4 (Selezione Condizionata dalla Policy): Dato un pool di candidati fattibili, il modello classifica o seleziona in base a una esplicita policy ingegneristica (es. dare priorità alla potenza rispetto all'affidabilità).

Framework di Valutazione

• Modelli: Sono stati valutati 12 run completi di modelli (inclusi Qwen, Gemini, DeepSeek, GPT, Hunyuan, ecc.) attraverso tutti i 763 task.
• Metriche:
  • Metriche Principali: P1-Composite (punteggio di certificazione pesato), P2 Final Feasible Power Ratio, P3-Success (fattibilità finale dopo il recupero) e P4 Kendall $\tau_b$ (coerenza della classificazione).
  • Profili Diagnostici: I profili di risposta al controllo (Disciplina dell'azione, Stile di modifica, Condizionamento dal feedback, Sforzo di reset dello stato, Esecuzione della policy) sono stati estratti dai log per mappare i fallimenti a segnali comportamentali.
  • Famiglie di Errore: Sono stati calcolati i tassi di errore non esclusivi (es. eccessiva azione, chiusura inammissibile, fallimento post-uscita, mismatch della policy) per identificare specifici modi di fallimento.

Contributi Chiave

1. Framework di Benchmark (VEHBench): Il primo benchmark diagnostico per la progettazione di VEH assistita da LLM che va oltre la validità dell'artefatto finale per valutare il comportamento di progettazione locale per fase. Combina la costruzione di task basata sulla letteratura, la verifica analitica esterna e la valutazione specifica per fase.
2. Risultati Empirici e Interpretazione: Gli autori hanno valutato sistematicamente gli attuali LLM e hanno scoperto che la capacità è fortemente dipendente dalla fase. Nessun modello domina l'intero workflow. Hanno introdotto un framework che collega i risultati empirici a caratteristiche comportamentali interpretabili (es. disciplina dell'azione, modifica vincolata, recupero dello stato).
3. Guida Consapevole della Fase: Il documento dimostra come i risultati locali per fase possano informare applicazioni ingegneristiche pratiche, inclusa la selezione, l'instradamento e l'adattamento dei modelli. Identifica lacune di capacità specifiche (es. triage delle specifiche, recupero da stato corrotto) per futuri agenti ingegneristici.

Risultati Sperimentali

• Classifiche Dipendenti dalla Fase: Nessun modello guida l'intero workflow.
  • P1 (Triage): qwen3-max ha performato meglio bilanciando la disciplina dell'azione (sopprimendo entrate non sicure e mancanze di informazioni).
  • P2 (Ricerca): gemini-3.1-pro-preview ha guidato grazie all'alta chiusura fattibile e ai rapporti di potenza utili.
  • P3 (Recupero): hunyuan-hy3-preview eccelle nel stabilizzarsi dopo l'uscita da stati corrotti.
  • P4 (Selezione): gpt-5.4 ha ottenuto la più alta esecuzione della policy e coerenza di classificazione.
• Modi di Fallimento:
  • P1: Gli errori dominanti erano l'"eccessiva azione" (proporre quando i brief sono inammissibili) e le "mancanze di informazioni", piuttosto che l'eccessiva astensione.
  • P2: La maggior parte dei modelli poteva seguire i protocolli di output ma falliva nel chiudere il loop di ricerca fisica (chiusura inammissibile) o subiva perdite di utilità.
  • P3: Il collo di bottiglia principale non era l'uscita dalla trappola, ma la stabilizzazione dello stato successivo (fallimento post-uscita).
  • P4: I fallimenti erano principalmente di tipo "mismatch della policy" (fallire nell'eseguire le priorità ingegneristiche dichiarate) piuttosto che errori di parsing o selezione di candidati inammissibili.
• Intervento e Instradamento:
  • Interfaccia di Stato: Sostituire la cronologia corrotta grezza con un riepilogo dello stato redatto dal verificatore ha migliorato i tassi di recupero P3 (dal 50,0% al 63,2% di media) e ridotto i fallimenti a cascata.
  • Instradamento (Routing): Un router consapevole della fase (che seleziona modelli diversi per diverse fasi) ha migliorato il punteggio medio normalizzato tenuto fuori da 0,892 (il miglior singolo modello di fallback) a 0,945, principalmente cambiando lo specialista P3.

Significatività e Rivendicazioni

Il documento sostiene che la capacità degli LLM nella progettazione ingegneristica è dipendente dal ruolo e che le classifiche aggregate sono meno informative rispetto alla compatibilità per fase. VEHBench fornisce una base per valutare, selezionare, instradare e migliorare gli LLM ingegneristici basati su un verificatore, esponendo dove il comportamento del workflow fallisce.

Gli autori sottolineano che VEHBench non è un sostituto delle simulazioni FEM (Metodo degli Elementi Finiti), delle revisioni di produzione o della certificazione hardware. Serve invece come uno strato diagnostico per determinare se un LLM utilizzi appropriatamente i segnali di validità fisica in ogni fase del design. Il benchmark è limitato alla co-progettazione analiticamente verificabile di VEH a cantilever, con gli autori che notano come lo stesso scaffold possa essere istanziato per simulatori più ricchi e altri domini accoppiati. Il lavoro sostiene che, per le applicazioni ingegneristiche, l'attenzione debba spostarsi dall' "autonomia del design hardware" all' "assistenza locale per fase", dove i modelli vengono selezionati e instradati in base ai loro profili comportamentali specifici all'interno del workflow di progettazione.