DUCTILE: Agentic LLM Orchestration of Engineering Analysis in Product Development Practice

Die Arbeit stellt DUCTILE vor, ein von einem LLM-Agenten gesteuertes Orchestrierungssystem, das in der Produktentwicklung adaptive Analysen durchführt, während Ingenieure die Aufsicht behalten, und demonstriert dessen Fähigkeit, in einer industriellen Anwendung robuste, fehlerfreie Ergebnisse trotz variierender Eingabeformate zu liefern.

Das Wesentliche

Hier ist eine einfache Erklärung des Papers „DUCTILE", als würde man es einem interessierten Laien beim Kaffee erzählen – mit ein paar bildhaften Vergleichen.

Das große Problem: Der „gläserne" Roboter

Stell dir vor, du hast einen sehr klugen, aber etwas starren Roboter-Assistenten in deiner Werkstatt. Dieser Roboter ist super darin, Aufgaben zu erledigen, solange alles genau so passiert, wie er es erwartet.

• Das Szenario: Ein Ingenieur sagt: „Bitte berechne die Belastung für diesen Flugzeugteil."
• Der Roboter: „Alles klar! Ich hole die Datei, die in JSON ist, rechne in Metern um und benenne den Knoten Port."
• Das Problem: Aber morgen kommt die Datei plötzlich als YAML, die Zahlen sind in Fuß (Imperial) und der Knoten heißt Links.
• Das Ergebnis: Der starre Roboter stolpert über diese winzigen Änderungen, wird verwirrt und sagt: „Fehler! Ich kann nicht weiterarbeiten."

In der echten Welt passiert das ständig. Software-Tools werden aktualisiert, Partner liefern Daten in neuen Formaten, oder die Regeln ändern sich. Die bisherigen Automatisierungen sind wie ein Schloss, das nur mit einem ganz bestimmten Schlüssel funktioniert. Wenn der Schlüssel auch nur einen Millimeter anders geformt ist, geht die Tür nicht auf. Ingenieure verbringen dann Stunden damit, den Schlüssel zu schleifen (Daten zu manuell umzuwandeln), statt das Flugzeug zu bauen.

Die Lösung: DUCTILE – Der flexible Dirigent

Die Autoren dieses Papers haben eine neue Idee namens DUCTILE entwickelt. Das klingt kompliziert, ist aber eigentlich ganz einfach:

Stell dir DUCTILE nicht als starren Roboter vor, sondern als einen klugen Dirigenten, der eine Orchestergruppe leitet.

1. Der Dirigent (Die KI-Agenten):
   Der Dirigent ist eine moderne Künstliche Intelligenz (ein sogenanntes „Large Language Model" oder LLM). Er ist nicht starr. Er kann lesen, verstehen und improvisieren. Wenn der Dirigent sieht, dass die Geige (das Tool) plötzlich in einem anderen Ton gestimmt ist, sagt er: „Aha, wir spielen jetzt in C-Dur statt in D-Dur." Er passt den Plan sofort an. Er versteht, dass „Links" dasselbe ist wie „Port", auch wenn die Wörter anders sind.

2. Das Orchester (Die bewährten Werkzeuge):
   Der Dirigent spielt nicht selbst die Instrumente. Das wäre zu riskant und ungenau. Stattdessen gibt er den Befehle an die echten, geprüften Instrumente (die alten, zuverlässigen Ingenieur-Software-Tools).

   • Die Regel: Der Dirigent (KI) denkt und plant. Die Instrumente (Software) rechnen und führen aus.
   • Warum? Weil die Instrumente mathematisch perfekt und zertifiziert sind. Die KI sorgt nur dafür, dass die richtigen Instrumente zum richtigen Zeitpunkt spielen, auch wenn die Partitur (die Eingabedaten) etwas anders aussieht als erwartet.

Wie funktioniert das in der Praxis?

Die Forscher haben das an einem echten Fall bei einem Flugzeughersteller getestet. Es ging um die Analyse von Belastungen auf ein Triebwerksteil.

Die Herausforderung:
Der Lieferant (OEM) schickte die Daten mit vier „Fehlern" (oder besser: Änderungen), die einen normalen Computer-Script sofort zum Absturz gebracht hätten:

1. Die Datei war im falschen Format (YAML statt JSON).
2. Die Einheiten waren falsch (Fuß statt Meter).
3. Die Namen der Teile waren anders (Links/Rechts statt Steuerbord/Backbord).
4. Es gab eine neue Korrekturformel, die in der Datei nicht stand, aber im Auftrag erwähnt wurde.

Die Lösung mit DUCTILE:

• Der KI-Direktor las den Auftrag und die alten Regeln.
• Er merkte sofort: „Oh, die Datei ist YAML. Kein Problem, ich übersetze sie für das Tool."
• Er sah die Fuß-Einheiten: „Okay, ich rechne alles in Meter um, bevor ich das Tool starte."
• Er las die Anmerkung zur Korrekturformel: „Ah, ich multipliziere die Kraft einfach mit 1,04."
• Er schrieb ein kleines Skript, rief die alten, sicheren Tools auf und lieferte das Ergebnis.

Das Ergebnis:
Der KI-Direktor hat die Aufgabe 10 Mal hintereinander erfolgreich gemeistert, obwohl die Daten jedes Mal leicht variierten. Zwei verschiedene Ingenieure haben mit dem System gearbeitet:

• Ingenieur 1 hat gesagt: „Mach das ganze Ding." -> Der Dirigent hat es erledigt.
• Ingenieur 2 hat gesagt: „Erkläre mir erst Schritt 1, dann Schritt 2." -> Der Dirigent hat Schritt für Schritt mitgearbeitet.
  Beide kamen zum selben, korrekten Ergebnis.

Warum ist das wichtig? (Die Metapher vom Bauherrn)

Stell dir vor, du baust ein Haus.

• Früher (Starre Automatisierung): Du hast einen Bagger, der nur geradeaus fährt. Wenn das Grundstück leicht geneigt ist oder ein Baum im Weg steht, bleibt der Bagger stehen. Du musst den Bagger manuell schieben oder einen neuen Bagger kaufen. Das kostet Zeit und Nerven.
• Jetzt (DUCTILE): Du hast einen Baggerführer, der ein KI-System hat. Der Baggerführer sieht den Baum, sagt: „Okay, wir fahren um den Baum herum." Er sieht die Neigung und sagt: „Ich justiere die Schaufel." Aber der Baggerführer vertraut auf die Mechanik des Baggers (die bewährten Tools), die physikalisch korrekt graben.

Der Clou: Der Ingenieur muss nicht mehr der Baggerführer sein, der jeden kleinen Stein wegräumt. Er ist der Bauherr, der sagt: „Das Haus soll hier stehen." Er überprüft, ob der Dirigent (die KI) die richtigen Entscheidungen trifft, aber er muss nicht mehr die Daten manuell umschreiben.

Was bedeutet das für die Zukunft?

• Weniger Frust: Ingenieure müssen nicht mehr stundenlang Daten „putzen" (Data Wrangling).
• Mehr Sicherheit: Da die KI nur plant und die alten, geprüften Tools rechnen, bleiben die Ergebnisse mathematisch sicher.
• Die menschliche Rolle: Die Ingenieure werden nicht ersetzt. Sie werden zu Supervisoren. Sie müssen dem Dirigent zuhören und prüfen: „Hast du wirklich verstanden, was ich will?" Das ist eine neue Art von Arbeit: weniger manuelles Tippen, mehr Überwachung und Urteilsvermögen.

Zusammenfassend:
DUCTILE ist wie ein flexibler Dolmetscher und Planer, der zwischen den chaotischen, sich ständig ändernden Anforderungen der echten Welt und den starren, aber perfekten Rechenmaschinen der Ingenieure vermittelt. Er macht die Automatisierung „zäh" (ductile), sodass sie nicht bricht, wenn sich die Welt ein wenig verändert.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „DUCTILE: Agentic LLM Orchestration of Engineering Analysis in Product Development Practice" auf Deutsch.

1. Problemstellung: Die Sprödigkeit (Brittleness) der Automatisierung

Der Kern des Problems liegt in der Sprödigkeit bestehender Automatisierungsansätze im Ingenieurwesen, insbesondere in der Produktentwicklung und der strukturellen Analyse (z. B. in der Luft- und Raumfahrt).

• Rigidität bestehender Systeme: Traditionelle Automatisierung (Skripte, PIDO-Plattformen, wissensbasierte Systeme) basiert auf deterministischen Schnittstellen zwischen Tools, Datenformaten und Prozessen.
• Anfälligkeit bei Änderungen: Sobald sich diese Schnittstellen ändern – sei es durch Tool-Updates, geänderte Anforderungen, neue Datenformate (z. B. von JSON zu YAML), andere Einheitensysteme oder Namenskonventionen – bricht die Automatisierung zusammen.
• Folgen: Ingenieure verbringen einen erheblichen Teil ihrer Zeit mit „Data Wrangling" (Bereinigung von Daten) und der Anpassung von Workflows, anstatt sich auf ingenieurtechnische Entscheidungen zu konzentrieren.
• Grenzen bestehender Lösungen:
  • Erweiterung deterministischer Regeln: Führt zu immer komplexeren Systemen mit neuen Fehlermodi.
  • Abhängigkeit von Experten: Erfordert manuelle Anpassungen pro Fall, was langsam ist und organisatorische Risiken schafft, wenn Experten fehlen.
  • KI-Ansätze (Generative Modelle): Diese generieren oft neue Designs oder Vorhersagen, können aber keine komplexen, dokumentierten Prozesse orchestrieren, bei denen spezifische, verifizierte Tools in einer definierten Reihenfolge aufgerufen werden müssen.

2. Methodik: Der DUCTILE-Ansatz

Das Paper stellt DUCTILE (Delegated, User-supervised Coordination of Tool- and document-Integrated LLM-Enabled) vor. Dies ist ein Ansatz zur Orchestrierung von Engineering-Analysen durch LLM-Agenten, der eine klare Trennung zwischen adaptiver Orchestrierung und deterministischer Ausführung vornimmt.

Kernprinzipien

1. Trennung von Orchestrierung und Ausführung:
   • Der LLM-Agent übernimmt die adaptive Orchestrierung: Er interpretiert dokumentierte Design-Praktiken, inspiziert Eingabedaten, erkennt Abweichungen und passt den Verarbeitungspfad an.
   • Verifizierte Engineering-Tools führen die eigentlichen Berechnungen deterministisch aus. Der Agent generiert den Code oder ruft die Tools auf, führt aber keine unsicheren Berechnungen selbst durch.
2. Technische Grundlagen des Agents:
   • Inferenz-Schleife: Nutzung von Large Language Models (LLMs) zur sequenziellen Token-Generierung.
   • Thinking Mode (Nachdenk-Modus): Der Agent nutzt einen „Scratchpad"-Modus, um sich selbst zu kritisieren, alternative Interpretationen zu prüfen und Fehler zu korrigieren, bevor er eine endgültige Antwort gibt. Dies reduziert Halluzinationen.
   • Tool Calling: Der Agent kann externe Tools (z. B. Python-Skripte, Datenbanken) aufrufen. Er lernt die APIs durch Lesen von Dokumentation (Zero-Shot) und plant Workflows basierend auf dem Kontext.
3. Architektur und Anforderungen:
   • Das System ist so gestaltet, dass es Inspektierbarkeit (R1), Reproduzierbarkeit (R2) und Rückverfolgbarkeit (R4) gewährleistet.
   • Der Agent arbeitet mit einem System-Prompt, der Aufgaben agnostisch hält, während spezifische Verfahren und Regeln zur Laufzeit aus Dokumenten geladen werden.
   • Der Ingenieur behält die letzte Verantwortung (Human-in-the-Loop) für die Überprüfung von Plänen und Ergebnissen.

3. Fallstudie und Experimente

Die Methode wurde in einer industriellen Anwendung bei GKN Aerospace (Schweden) getestet.

• Aufgabe: Strukturelle Festigkeitsanalyse einer Turbinen-Rückstruktur (Turbine Rear Structure - TRS).
• Szenario: Ein neuer OEM-Lieferant lieferte Lastdaten mit vier signifikanten Abweichungen gegenüber dem bisherigen Standard:
  1. Dateiformat: YAML statt JSON.
  2. Einheitensystem: Imperiale Einheiten statt SI.
  3. Benennung: Knotennamen „left/right" statt „port/starboard".
  4. Methodik: Ein Korrekturfaktor von 1,04 für die Fx-Kräfte, der in den Rohdaten fehlte, aber in der Aufgabenbeschreibung stand.
• Testbedingungen:
  • Der Agent wurde in einer Terminal-Umgebung (Claude Code) ausgeführt.
  • Zwei Ingenieure mit unterschiedlichen Supervisions-Stilen testeten das System:
    • Ingenieur 1 (Delegation): Überließ dem Agenten die gesamte Aufgabe und prüfte das Endergebnis.
    • Ingenieur 2 (Inkrementell): Prüfte jeden Zwischenschritt und gab den Agenten schrittweise Anweisungen.
  • Auswertung: Der Agent wurde 10 unabhängige Male auf demselben Szenario ausgeführt.

4. Ergebnisse

• Fehlererkennung und Anpassung: Der Agent identifizierte alle vier Abweichungen korrekt und passte den Workflow automatisch an (z. B. YAML-Parser schreiben, Einheiten umrechnen, Knotennamen mappen, Korrekturfaktor anwenden).
• Zuverlässigkeit: Alle 10 unabhängigen Durchläufe lieferten korrekte Ergebnisse, die mit den Referenzdaten eines Experten übereinstimmten.
• Metrik (Pass-k): Die Studie nutzte die Metrik „Pass-k" (Anzahl der erfolgreichen Durchläufe bei k Wiederholungen). Mit k=10 wurde eine hohe Zuverlässigkeit demonstriert.
• Supervision: Beide Ingenieurs-Stile (Delegation vs. Inkrementell) führten zum gleichen korrekten Ergebnis. Der Agent konnte sich an den unterschiedlichen Supervisions-Stil anpassen.
• Transparenz: Alle Zwischenschritte, Skripte und Logs waren für den Ingenieur einsehbar und überprüfbar.

5. Hauptbeiträge des Papers

1. Konzeptuelle Trennung: Etablierung eines Paradigmas, bei dem LLMs als Orchestrierungsschicht dienen, während deterministische Tools die Berechnungen übernehmen. Dies löst das Problem der Sprödigkeit bei sich ändernden Schnittstellen.
2. DUCTILE-Framework: Eine konkrete Implementierung, die Inspektierbarkeit, Reproduzierbarkeit und Auditierbarkeit in den Vordergrund stellt (entsprechend den Anforderungen R1-R12).
3. Industrielle Validierung: Demonstration, dass LLM-Agenten reale, komplexe Luftfahrt-Analyse-Workflows handhaben können, die traditionelle Skripte scheitern lassen würden.
4. Offene Ressourcen: Bereitstellung von Code, Evaluierungsskripten und Datensätzen für die Forschungsgemeinschaft.

6. Bedeutung und Implikationen

• Überwindung der Sprödigkeit: DUCTILE zeigt, wie man Engineering-Automatisierung robust gegenüber den unvermeidlichen Änderungen in Daten, Tools und Prozessen macht, ohne die ingenieurtechnische Strenge aufzugeben.
• Rolle des Ingenieurs: Der Ingenieur wandelt sich vom „Daten-Bereiniger" zum „Supervisor". Die Gefahr besteht jedoch, dass diese Supervisionsrolle ermüdend werden kann, wenn sie nicht gut gestaltet ist. Der Ansatz betont, dass das Urteilsvermögen (Judgment) beim Menschen bleiben muss, während die Dexterität (Handwerk/Tool-Bedienung) an den Agenten delegiert wird.
• Dokumentationsqualität: Der Ansatz macht hochwertige, strukturierte Dokumentation zwingend erforderlich, da der Agent auf diesen Dokumenten aufbaut. Dies fördert die explizite Wissensspeicherung in Organisationen.
• Zertifizierung und Sicherheit: Durch die Trennung von Orchestrierung (stochastisch) und Ausführung (deterministisch) bleibt das System für Zertifizierungsbehörden (z. B. in der Luftfahrt) akzeptabel, da die kritischen Berechnungen in verifizierten Tools laufen.

Fazit: Das Paper beweist, dass LLM-Agenten als adaptive Vermittler zwischen Ingenieuren und verifizierten Engineering-Tools eingesetzt werden können, um die Lücke zwischen sich wandelnden Produktanforderungen und starren Automatisierungssystemen zu schließen, ohne dabei die Sicherheit oder Nachvollziehbarkeit zu gefährden.