Technisches Resümee: VEHBench

Problemstellung

Das Design von Vibrationsenergieerntem (Vibration Energy Harvesters, VEHs) für batteriefreie IoT-Geräte umfasst eng gekoppelte mechanisch-elektrische Interaktionen und strikte physikalische Randbedingungen (z. B. Vibrationsspektren, Leistungsziele, Größenbeschränkungen, Materialeigenschaften und Sicherheitsmargen). Während Large Language Models (LLMs) zunehmend als Schnittstellen für Engineering-Workflows eingesetzt werden – um Anforderungen zu übersetzen, Feedback zu prüfen und Designmodifikationen vorzuschlagen –, bewerten bestehende Engineering-Benchmarks primär die Validität des finalen Artefakts. Diese Endpunkt-Evaluierungen versäumen es, aufzuzeigen, wie sich LLMs über die verschiedenen Phasen eines gekoppelten physikalischen Design-Workflows hinweg verhalten. Speziell diagnostizieren aktuelle Benchmarks nicht, ob ein Modell unvollständige Briefings korrekt triagiert, nach physikalischem Feedback gebundene Edits vornimmt, aus korrumpierten Design-Trajektorien zurückkehrt oder explizite Selektionsrichtlinien einhält. Dieser Mangel an phasenlokaler Diagnostik macht es schwierig, spezifische Workflow-Fehler (z. B. Fehler bei der Eingabekontrolle vs. Suchfehler) zu identifizieren und erschwert die Auswahl oder das Routing von Modellen für spezifische Engineering-Rollen.

Methodik

Die Autoren führen VEHBench ein, einen auf Engineering spezialisierten diagnostischen Benchmark, der darauf ausgelegt ist, LLM-gestütztes VEH-Co-Design durch phasenlokale, Verifizierer-gestützte Aufgaben zu evaluieren.

Benchmark-Konstruktion

• Domäne: Der Benchmark konzentriert sich auf das Co-Design eines piezoelektrischen Cantilever-VEH in der frühen Phase, ein kompakter, aber gekoppelter Bereich, der Strukturmechanik, intelligente Materialien und Schaltungsdesign umfasst.
• Datenquelle: Die Aufgaben leiten sich aus einer Literaturrecherche von 209 Papern ab, woraus 52 bereinigte „Design-Anker“ (normalisierte physikalische Zustände mit Variablen, Grenzen und Randbedingungen) resultieren.
• Verifizierung: Ein analytischer physikalischer Oracle (basierend auf der Euler-Bernoulli-Balkentheorie und elektromechanischen Kopplungsgleichungen) berechnet die Durchführbarkeit und die Objektqualität. Es werden keine menschlichen Labels oder „LLM-as-a-judge“-Methoden zur Bewertung verwendet.
• Aufgaben-Dekomposition: Der Workflow wird in vier verschiedene Design-Rollen (Probes) unterteilt, die jeweils über spezifische vertrauenswürdige Zustände, zulässige Aktionen und Konsequenzen bei Fehlern verfügen:
  1. P1 (Spezifikations-Triage): Das Modell erhält ein Design-Briefing (vollständig, unvollständig oder unzulässig) und muss entscheiden, ob es einen Vorschlag unterbreitet, sich enthält oder fehlende Informationen anfordert.
  2. P2 (Verifizierer-gestützte Suche): Gegeben ein Seed-Design und Oracle-Feedback, führt das Modell gebundene Edits durch, um den Kandidaten zu verbessern.
  3. P3 (Wiederherstellung aus korrumpierten Zuständen): Das Modell wird einer korrumpierten oder irreführenden Design-Trajektorie ausgesetzt und muss zurücksetzen, neu verankern oder stabilisieren, um der Falle zu entkommen.
  4. P4 (Policy-konditionierte Selektion): Gegeben einem Pool an machbaren Kandidaten rankt oder selektiert das Modell basierend auf einer expliziten Engineering-Policy (z. B. Priorisierung von Leistung vs. Zuverlässigkeit).

Evaluationsrahmen

• Modelle: 12 vollständige Modellläufe (darunter Qwen, Gemini, DeepSeek, GPT, Hunyuan, etc.) wurden über alle 763 Aufgaben evaluiert.
• Metriken:
  • Headline-Metriken: P1-Composite (gewichteter Zertifizierungs-Score), P2 Final Feasible Power Ratio, P3-Success (finale Durchführbarkeit nach der Wiederherstellung) und P4 Kendall $\tau_b$ (Ranking-Konsistenz).
  • Diagnostische Profile: Response-Control-Profile (Aktionsdisziplin, Edit-Stil, Feedback-Konditionierung, State-Reset-Aufwand, Policy-Ausführung) wurden aus den Logs extrahiert, um Fehler auf Verhalten-Signale abzubilden.
  • Fehlerfamilien: Nicht-exklusive Fehlerraten (z. B. Over-Action, Infeasible Closure, Post-Escape Failure, Policy Mismatch) wurden berechnet, um spezifische Fehlermodi zu identifizieren.

Zentrale Beiträge

1. Benchmark-Framework (VEHBench): Der erste diagnostische Benchmark für LLM-gestütztes VEH-Design, der über die bloße Validität des finalen Artefakts hinausgeht, um das phasenlokale Designverhalten zu bewerten. Er kombiniert literaturbasierte Aufgabenkonstruktion, externe analytische Verifizierung und phasenspezifische Evaluierung.
2. Empirische Befunde & Interpretation: Die Autoren haben aktuelle LLMs systematisch evaluiert und festgestellt, dass die Leistungsfähigkeit stark phasenabhängig ist. Kein einzelnes Modell dominiert den gesamten Workflow. Sie führten ein Framework ein, das empirische Ergebnisse mit interpretierbaren Charakteristika (z. B. Aktionsdisziplin, gebundenes Editieren, State-Recovery) verknüpft.
3. Phasenbewusste Anleitung: Die Arbeit zeigt, wie phasenlokale Ergebnisse praktische Engineering-Anwendungen beeinflussen können, einschließlich Modellauswahl, Routing und Adaption. Sie identifiziert spezifische Fähigkeitslücken (z. B. Spezifikations-Triage, Wiederherstellung aus korrumpierten Zuständen) für zukünftige Engineering-Agenten.

Experimentelle Ergebnisse

• Phasenabhängige Rankings: Kein Modell führt den gesamten Workflow an.
  • P1 (Triage): qwen3-max schnitt am besten ab, indem es die Aktionsdisziplin (Unterdrückung unsicherer Einträge und Vermeidung von Fehlern bei fehlenden Informationen) balancierte.
  • P2 (Suche): gemini-3.1-pro-preview führte aufgrund hoher Feasibility Closure und nützlicher Power Ratios.
  • P3 (Recovery): hunyuan-hy3-preview zeichnete sich durch die Stabilisierung nach dem Entkommen aus korrumpierten Zuständen aus.
  • P4 (Selektion): gpt-5.4 erreichte die höchste Policy-Ausführung und Ranking-Konsistenz.
• Fehlermodi:
  • P1: Dominante Fehler waren „Over-Action“ (Vorschläge bei unzulässigen Briefings) und „Missing-Info Misses“, statt übermäßiger Verweigerung.
  • P2: Die meisten Modelle konnten die Output-Protokolle befolgen, scheiterten jedoch daran, den physikalischen Suchloop zu schließen (Infeasible Closure) oder erlitten Nutzenverluste.
  • P3: Der primäre Engpass war nicht das Entkommen aus der Falle, sondern die Stabilisierung des Zustands danach (Post-Escape Failure).
  • P4: Fehler waren primär „Policy Mismatch“ (Nicht-Ausführung der deklarierten Engineering-Prioritäten) statt Parsing-Fehler oder Auswahl unzulässiger Kandidaten.
• Intervention & Routing:
  • State Interface: Das Ersetzen der rohen korrumpierten Historie durch eine Verifizierer-autorisierte Zustandszusammenfassung verbesserte die P3-Recovery-Rate (von 50,0 % auf 63,2 % im Mittel) und reduzierte Kaskadenfehler.
  • Routing: Ein phasenbewusster Router (der verschiedene Modelle für verschiedene Phasen auswählt) verbesserte den mittleren normalisierten Held-out-Score von 0,892 (bester Single-Model-Fallback) auf 0,945, primär durch den Wechsel des P3-Spezialisten.

Bedeutung und Ansprüche

Das Paper behauptet, dass die Fähigkeit von LLMs im Engineering-Design rollenabhängig ist und dass aggregierte Rankings weniger aussagekräftig sind als die Phasenkompatibilität. VEHBench bietet eine Grundlage für die Evaluierung, Auswahl, das Routing und die Verbesserung von Verifizierer-gestützten Engineering-LLMs, indem es aufzeigt, wo das Workflow-Verhalten versagt.

Die Autoren betonen, dass VEHBench kein Ersatz für Finite-Elemente-Methoden (FEM)-Simulationen, Fertigungsprüfungen oder Hardware-Zertifizierungen ist. Stattdessen dient es als diagnostische Ebene, um zu bestimmen, ob ein LLM physikalische Validitätssignale in jeder Designphase angemessen nutzt. Der Benchmark ist auf analytisch verifizierbares Cantilever-VEH-Co-Design beschränkt, wobei die Autoren anmerken, dass dasselbe Gerüst für reichere Simulatoren und andere gekoppelte Domänen instanziiert werden kann. Die Arbeit argumenttiert, dass der Fokus für Engineering-Anwendungen von „autonomem Hardware-Design“ hin zu „phasenlokaler Assistenz“ rücken sollte, bei der Modelle basierend auf ihren spezifischen Verhaltensprofilen innerhalb des Design-Workflows ausgewählt und geroutet werden.