Engineering Systems for Data Analysis Using Interactive Structured Inductive Programming

Das Paper stellt iProg vor, ein Werkzeug für interaktives strukturiertes induktives Programmieren, das durch eine zweistufige Kollaboration zwischen Mensch und KI (Zerlegung in Datenflussdiagramme und Codegenerierung) unter Nutzung eines Intelligibilitätsprotokolls wissenschaftliche Datenanalysesysteme schneller, qualitativ hochwertiger und zuverlässiger entwickelt als herkömmliche Low-Code- oder No-Code-Ansätze.

Das Wesentliche

🛠️ iProg: Der Baumeister, der mit dem Architekten spricht

Stellen Sie sich vor, Sie wollen ein riesiges, kompliziertes Haus bauen (z. B. ein Computersystem, das wissenschaftliche Daten analysiert).

Das Problem:
Bisher gab es zwei extreme Wege:

1. Der alte Weg (Manuell): Ein Architekt und ein Baumeister planen alles von Hand. Das ist sehr zuverlässig und sicher, dauert aber ewig. Es ist wie das Bauen eines Hauses Stein für Stein mit einem Lineal und einem Bleistift.
2. Der neue "No-Code"-Weg (KI ohne Struktur): Sie rufen einen sehr schnellen, aber etwas chaotischen Bauarbeiter (eine KI) an und sagen: "Bau mir ein Haus!" Die KI wirft sofort Ziegelsteine in die Luft. Manchmal steht ein Haus da, aber oft ist das Dach schief, die Wände sind instabil oder es gibt gar kein Fundament. Das Ergebnis ist schnell, aber unzuverlässig.

Die Lösung: iProg
Die Autoren dieses Papers haben iProg entwickelt. Man kann sich iProg wie einen klugen Bauleiter vorstellen, der zwischen Ihnen (dem Experten) und der KI (dem schnellen Bauarbeiter) vermittelt.

Wie funktioniert das? (Die zwei Phasen)

Statt der KI einfach zu sagen "Baue das!", zwingt iProg die KI, erst einen Bauplan zu zeichnen, bevor sie auch nur einen Stein bewegt.

Phase 1: Der Bauplan (Die Struktur)

• Die Aufgabe: Sie beschreiben Ihr Problem in normalen Worten (z. B. "Wir müssen Protein-Sequenzen analysieren, um zu sehen, ob sie Bakterien töten").
• Die KI: Die KI schlägt einen Flussdiagramm-Plan (einen DFD) vor. Das ist wie eine Skizze, die zeigt: "Zuerst holen wir die Daten, dann reinigen wir sie, dann bauen wir ein Modell, dann testen wir es."
• Die Interaktion: Sie schauen sich den Plan an.
  • Ist alles richtig? -> Sie sagen "Zustimmen" (RATIFY).
  • Ist ein Schritt falsch? -> Sie sagen "Ablehnen" (REFUTE) oder "Ändern" (REVISE).
  • Analogie: Es ist wie beim Kochen. Die KI schlägt vor: "Wir machen zuerst den Salat, dann den Braten." Sie sagen: "Nein, der Salat wird warm, wenn wir den Braten machen. Mach erst den Braten, dann den Salat." Die KI passt den Plan an, bis Sie zufrieden sind.

Phase 2: Das Bauen (Der Code)

• Sobald der Plan steht, geht die KI los und baut jeden einzelnen Schritt des Plans.
• Aber sie baut nicht einfach los. Für jeden Schritt (z. B. "Daten laden") fragt sie: "Hier ist mein Code für diesen Schritt. Stimmt das?"
• Sie prüfen den Code. Wenn er gut ist, wird er in das Gesamtsystem eingebaut. Wenn nicht, wird er korrigiert.
• Analogie: Statt den ganzen Bauarbeiter zu feuern, wenn er einen Fehler macht, korrigiert der Bauleiter nur den einzelnen Ziegel, den er falsch gesetzt hat. Der Rest des Hauses bleibt stehen.

Warum ist das so toll? (Die Ergebnisse)

Die Autoren haben iProg an zwei echten wissenschaftlichen Projekten getestet (Astronomie und Biochemie). Hier ist, was passiert ist:

1. Besser als "No-Code": Wenn man der KI einfach alles überlässt (ohne Plan), scheitert sie oft. iProg hat fast immer funktionierende Systeme gebaut, während die "No-Code"-Versionen oft abgestürzt sind.
2. Schneller als manuell: Ein einzelner Mensch konnte mit iProg in wenigen Tagen Systeme bauen, für die früher ein ganzes Team wochenlang gebraucht hätte.
3. Höhere Qualität: Der Code war sauberer, besser strukturiert und leichter zu warten. Weil der Plan (der DFD) klar war, wusste jeder, was wohin gehört.

Die wichtigsten Erkenntnisse (in einfachen Worten)

• Struktur ist der Schlüssel: Wenn man der KI einen klaren Rahmen gibt (den Bauplan), versteht sie die Aufgabe viel besser. Sie weiß, wo sie anfangen und wo sie aufhören muss.
• Der Mensch muss im Loop bleiben: Die KI ist schnell, aber sie macht Fehler. Der Mensch muss wie ein Qualitätskontrolleur fungieren. Ohne diesen "Stempel der Zustimmung" (RATIFY) ist das Ergebnis oft Müll.
• Weniger Chaos, mehr Klarheit: Statt mit der KI zu "plaudern" (was oft zu Missverständnissen führt), kommunizieren sie mit klaren Signalen: "Ja", "Nein", "Ändere das". Das macht die Zusammenarbeit effizient.

Fazit

iProg ist wie ein Übersetzer und Bauleiter in einem. Es nimmt Ihre vage Idee, macht daraus einen klaren Bauplan, lässt die KI die Arbeit erledigen, aber behält die volle Kontrolle, damit am Ende ein stabiles, funktionierendes Haus steht – und das in einem Bruchteil der Zeit, die es früher gebraucht hätte.

Es zeigt uns: Die Zukunft liegt nicht darin, die KI allein zu lassen, sondern sie strukturiert zu führen.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Engineering Systems for Data Analysis Using Interactive Structured Inductive Programming" auf Deutsch:

1. Problemstellung

Die Entwicklung von Informationssystemen für die wissenschaftliche Datenanalyse ist mit erheblichen Herausforderungen verbunden:

• Komplexität: Wissenschaftliche Workflows umfassen Datenerfassung, Transformation, Modellierung, Validierung und Berichterstattung. Diese erfordern eine enge Zusammenarbeit zwischen Softwareingenieuren und Domänenspezialisten.
• Limitationen bestehender Ansätze:
  • Manuelle Entwicklung: Zuverlässig, aber zeitaufwendig und ressourcenintensiv.
  • „No-Code"/LLM-basierte Ansätze: Zwar schnell, aber oft unzuverlässig. Große Sprachmodelle (LLMs) neigen dazu, Code zu generieren, der fehlerhaft, nicht strukturiert oder schwer wartbar ist. Sie scheitern oft bei der mehrstufigen logischen Schlussfolgerung und dem Design komplexer Workflows.
• Kernbottleneck: Der kritische Engpass liegt in der Bestimmung einer geeigneten Systemdekomposition (Aufteilung des Problems in Teilaufgaben), bevor Code generiert werden kann.

2. Methodik: iProg (Interactive Structured Inductive Programming)

Das Paper stellt iProg vor, ein Werkzeug, das Interaktives Strukturiertes Induktives Programmieren (ISIP) nutzt, um die Lücke zwischen natürlicher Sprache und funktionierenden Informationssystemen zu schließen. Der Ansatz basiert auf einem Zwei-Phasen-Prozess, der durch ein 2-Wege-Intelligibilitäts-Protokoll (2-way Intelligibility) gesteuert wird, bei dem ein Mensch und ein LLM zusammenarbeiten.

A. Phase 1: Interaktive Strukturerkennung (iStruc)

• Ziel: Umwandlung einer natürlichen Sprachbeschreibung des Problems in eine deklariative Datenflussdiagramm (DFD)-Struktur.
• Prozess:
  1. Der LLM schlägt ein DFD vor, das Prozesse (Knoten) und Datenflüsse (Kanten) definiert.
  2. Jeder Prozess wird durch eine Spezifikation beschrieben: Beschreibung (natürliche Sprache), Vorbedingung (erforderlicher Zustand) und Nachbedingung (garantierter Zustand).
  3. Der Mensch bewertet den Vorschlag über ein Tagging-System: RATIFY (bestätigen), REFUTE (widerlegen) oder REJECT (ablehnen).
  4. Dieser Zyklus wiederholt sich, bis der Mensch das DFD ratifiziert. Dies erzwingt eine explizite Klärung von Annahmen und Schnittstellen.

B. Phase 2: Interaktive Code-Generierung (iCode)

• Ziel: Generierung von ausführbarem Code für jeden Prozess im ratifizierten DFD.
• Prozess:
  1. Basierend auf dem DFD traversiert iCode die Prozesse (breitensuchend).
  2. Für jeden Prozess nutzt der LLM die spezifischen Vor-/Nachbedingungen, um Code zu generieren.
  3. Der Mensch validiert den Code und die Erklärung des LLMs erneut über das Protokoll (RATIFY/REFUTE/REVISE).
  4. Validierte Komponenten werden zu einem end-to-end System zusammengesetzt.

C. Das Interaktionsprotokoll

Das Protokoll unterscheidet sich von offenen Dialogmodellen durch strenge Tags:

• Mensch: Sendet RATIFY, REFUTE, REJECT. (Kein REVISE vom Menschen, um die Verantwortung für die Änderung beim LLM zu lassen, der dann neu generiert).
• Maschine (LLM): Sendet RATIFY, REFUTE, REVISE.
• Zweck: Sicherstellung, dass sowohl der Code als auch die Erklärung für den Menschen verständlich und korrekt sind, bevor sie akzeptiert werden.

3. Hauptbeiträge

1. Methodologie: Ein Ansatz für semi-automatisiertes Software-Engineering, der LLMs nutzt, um (a) Systemdekompositionen aus natürlichen Sprachbeschreibungen zu identifizieren und (b) vom Menschen ratifizierten Code zu generieren. Dies behandelt wissenschaftliche Datenanalyse als workflow-orientierte Entwicklung.
2. Tool (iProg): Eine praktische Implementierung, die den Übergang von Problemstellungen in zertifizierte Systeme unterstützt. Das Tool ermöglicht die manuelle Bearbeitung von DFDs, die interaktive Identifizierung von Subprogrammen und die Ausführung von Code.
3. Empirische Evaluation: Nachweis, dass der Ansatz in der Lage ist, angemessene Zerlegungen zu finden und End-to-End-Systeme mit besserer Leistung und höherer Codequalität als Low-Code/No-Code-Alternativen zu konstruieren.

4. Ergebnisse (Empirische Evaluation)

Die Methode wurde an zwei realen wissenschaftlichen Projekten evaluiert:

1. Astrophysik (PHY): Vorhersage von Sternentstehungseigenschaften aus multi-spektralen Daten (GAMA-Katalog).
2. Biochemie (BIO): Klassifizierung von Proteinsequenzen als antimikrobielle Peptide (AMPs) mittels Machine Learning.

Vergleichsbaselines:

• iProg: Strukturierte, interaktive Methode.
• Low Code (LLM-k, CP-k): LLM mit freiem Feedback, aber ohne DFD-Strukturierung.
• No Code (LLM-0, CP-0): Direkte Generierung ohne menschliches Feedback.
• Manuell: Originalsysteme aus der Literatur.

Ergebnisse:

• Strukturqualität: iProg identifizierte DFDs, die stark mit den manuell entwickelten Referenzsystemen übereinstimmten (hohe Übereinstimmung bei Knoten und Kanten).
• Systemleistung:
  • iProg erzielte konsistent niedrigere Fehlerquoten als Low-Code-Ansätze.
  • „No-Code"-Ansätze scheiterten häufig an Laufzeitfehlern oder produzierten nicht-funktionale Systeme.
  • Low-Code-Ansätze funktionierten bei PHY teilweise, scheiterten aber komplett bei der komplexeren BIO-Aufgabe.
• Codequalität:
  • iProg generierte modularen, strukturierten Code mit expliziten Schnittstellen (Logik-Score: ~6.7/10 vs. ~1.8 bei Low Code).
  • Low-Code-Lösungen waren oft monolithisch und weniger wartbar.
• Entwicklungsaufwand:
  • iProg reduzierte die Entwicklungszeit drastisch im Vergleich zur manuellen Entwicklung (z. B. 4–10 Tage vs. 30–60 Tage bei PHY).
  • Im Vergleich zu No-Code-Ansätzen war der Aufwand ähnlich gering, führte aber zu funktionierenden Systemen.
• Vergleich mit Manueller Entwicklung: iProg erreichte bei PHY eine bessere Genauigkeit als das manuelle Originalsystem und bei BIO eine vergleichbare Genauigkeit, jedoch mit einem Bruchteil des Personalaufwands (0.13–0.3 Person-Monate vs. 2–6 Person-Monate).

5. Bedeutung und Schlussfolgerungen

Das Paper demonstriert, dass Interaktives Strukturiertes Induktives Programmieren ein vielversprechender Weg für das Engineering von Informationssystemen ist.

• Strukturierung ermöglicht Verständnis: Die DFD-basierte Modularisierung erleichtert das Verständnis komplexer Probleme und gezielte Änderungen (nur betroffene Module müssen neu generiert werden).
• Rolle des Menschen: Der Mensch fungiert als kritischer Validierer. Ohne menschliche Verifizierung (Ratifikation) neigen LLMs dazu, inkonsistente oder fehlerhafte Systeme zu produzieren. Das Protokoll erzwingt eine Konvergenz auf akzeptable Lösungen.
• Skalierbarkeit: Der Ansatz skaliert gut, da die Interaktionen kurz und fokussiert sind (ca. 3–4 Interaktionen für die Struktur, 2–3 pro Code-Modul).
• Zukunftspotenzial: Die Technik ist nicht auf Datenanalyse beschränkt, sondern anwendbar in Bereichen wie Energieanalyse, Umweltmonitoring und anderen datenintensiven Domänen.

Zusammenfassend zeigt iProg, dass die Kombination aus der Wissensbasis von LLMs (für Vorschläge) und menschlicher Validierung (für Korrektheit und Wartbarkeit) eine überlegene Alternative zu reinen „No-Code"-Ansätzen oder rein manueller Entwicklung darstellt.