EPOCH: An Agentic Protocol for Multi-Round System Optimization

Das Paper stellt EPOCH vor, ein ingenieurtechnisches Protokoll für die mehrstufige Systemoptimierung in heterogenen Umgebungen, das durch eine strukturierte Trennung von Baseline-Erstellung und iterativer Selbstverbesserung sowie rollenbeschränkten Phasen eine koordinierte, stabile und nachvollziehbare autonome Optimierung von Prompts, Code und Modellkonfigurationen ermöglicht.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen sehr talentierten, aber manchmal etwas chaotischen Assistenten (eine Künstliche Intelligenz), der Ihnen helfen soll, ein komplexes Projekt zu verbessern – sei es ein Computerprogramm, eine Marketing-Strategie oder ein Rezept.

Das Problem bisher war: Wenn Sie diesen Assistenten bitten, etwas zu verbessern, tut er das oft wild durcheinander. Er ändert hier, löscht dort, vergisst zu prüfen, ob es wirklich besser wurde, und am Ende wissen Sie nicht mehr, wie er auf das Ergebnis gekommen ist. Es ist wie ein Koch, der ständig Zutaten hinzufügt, ohne zu schmecken, und am Ende niemand weiß, warum das Essen nun so schmeckt.

Die Autoren dieses Papers haben eine Lösung namens EPOCH entwickelt. Man kann sich EPOCH nicht als einen neuen „Super-Assistenten" vorstellen, sondern eher als einen strengen, aber fairen Bauleiter oder einen Regisseur, der dem Assistenten sagt, wie er arbeiten muss.

Hier ist, wie EPOCH funktioniert, einfach erklärt:

1. Der Grundgedanke: Ein Plan statt Chaos

EPOCH ist kein einzelner Trick, sondern ein Vertrag (ein Protokoll), der festlegt, wie Verbesserungen Schritt für Schritt passieren müssen. Es teilt die Arbeit in zwei große Phasen ein:

• Phase 1: Das Fundament legen. Bevor es losgeht, muss der Assistent erst einmal einen funktionierenden „Startzustand" schaffen. Wie sieht das aktuelle Haus aus? Gibt es überhaupt eine Tür? EPOCH sorgt dafür, dass wir einen soliden Ausgangspunkt haben, auf dem wir aufbauen können.
• Phase 2: Das iterative Bauen. Jetzt beginnt das eigentliche Spiel. Der Assistent darf das Haus verbessern, aber nur nach strengen Regeln.

2. Die vier Rollen im Team (Der Orchester-Direktor)

Das Geniale an EPOCH ist, dass es den Assistenten nicht alles allein machen lässt. Es teilt die Arbeit auf vier verschiedene „Rollen" auf, die wie ein Team in einer Fabrik zusammenarbeiten:

1. Der Architekt (Orchestrator): Er hält den Zeitplan im Auge. Er sagt: „Wir haben Zeit für 5 Versuche. Passen Sie auf, dass wir nicht zu viel ausgeben."
2. Der Detektiv (Investigator): Dieser sucht nach Fehlern. „Aha! Das Dach leckt hier!" oder „Der Code ist zu langsam." Er schlägt eine Idee vor: „Lass uns das Dach mit Ziegeln statt mit Pappe machen."
3. Der Handwerker (Executor): Dieser setzt die Idee um. Er nimmt die Ziegel und baut das Dach. Er darf aber nur das tun, was der Detektiv vorgeschlagen hat.
4. Der Prüfer (Reviewer): Das ist der wichtigste Teil! Dieser Prüfer ist völlig unabhängig. Er sieht sich das neue Dach an und sagt: „Ist es wirklich besser? Ja? Dann akzeptieren wir es. Nein? Dann abreißen und neu versuchen."

Warum ist das so wichtig?
Stellen Sie sich vor, der Handwerker würde auch selbst prüfen, ob sein Dach gut ist. Dann würde er wahrscheinlich lügen und sagen: „Ja, es ist toll!", nur damit er nicht arbeiten muss. Bei EPOCH sind derjenige, der die Idee hat, und derjenige, der sie prüft, getrennt. Das verhindert Betrug und sorgt dafür, dass nur echte Verbesserungen bleiben.

3. Die „Schleife" (Wie ein Video-Game)

EPOCH läuft in Runden ab, wie Level in einem Videospiel:

1. Beobachten: Wo stehen wir gerade?
2. Planen: Was können wir ändern?
3. Handeln: Wir ändern es.
4. Prüfen: Hat es funktioniert?
   • Ja: Wir speichern den neuen Stand und machen in der nächsten Runde weiter.
   • Nein: Wir verwerfen die Änderung und versuchen etwas anderes.

Jede dieser Änderungen wird protokolliert. Das ist wie ein Tagebuch. Wenn Sie später fragen: „Warum ist das System heute so schnell?", können Sie im Tagebuch nachlesen: „Ah, in Runde 3 hat der Handwerker den Motor getauscht, und der Prüfer hat es genehmigt."

4. Wo wird das benutzt?

Das Paper zeigt, dass dieser Bauleiter für ganz verschiedene Dinge funktioniert:

• Code schreiben: Wenn ein Programm zu langsam ist, hilft EPOCH, den Code zu optimieren, ohne dass er kaputtgeht.
• Einstellungen anpassen (Hyperparameter): Wie beim Autofahren: Soll das Auto schneller fahren (höhere Lernrate)? EPOCH testet es, prüft, ob es sicher ist, und entscheidet dann.
• Prompts verbessern: Wenn Sie einer KI sagen wollen, wie sie antworten soll, hilft EPOCH, die Anweisungen Schritt für Schritt zu verfeinern.
• Regeln aufstellen: Wenn Sie eine Liste von Regeln haben (z. B. „Wenn es regnet, nimm den Regenschirm"), hilft EPOCH, diese Regeln so anzupassen, dass sie perfekt funktionieren.

Zusammenfassung

EPOCH ist wie ein Disziplin-Coach für KI-Assistenten. Es sagt ihnen nicht, was sie denken sollen, sondern wie sie arbeiten sollen. Es sorgt dafür, dass:

• Jeder Schritt nachvollziehbar ist (Transparenz).
• Niemand sich selbst prüft (Fairness).
• Man weiß, wann man aufhören soll, weil es nichts mehr zu verbessern gibt (Effizienz).

Das Ziel ist nicht, die KI noch „intelligenter" zu machen, sondern sie zuverlässiger, sicherer und besser kontrollierbar zu machen, damit man ihr auch in der echten Welt (in Firmen, in der Medizin, in der Technik) vertrauen kann.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „EPOCH: An Agentic Protocol for Multi-Round System Optimization" auf Deutsch:

1. Problemstellung

Autonome Agenten werden zunehmend eingesetzt, um Prompts, Code und ML-Systeme durch iterative Ausführung und Feedback zu verbessern. Bisherige Ansätze sind jedoch meist als aufgaben spezifische Optimierungs-Schleifen (z. B. Prompt-Optimierung in DSPy, Hyperparameter-Suche mit AgentHPO) oder domänenspezifische Workflows konzipiert.

Es fehlt eine einheitliche Protokollschicht, die folgende Anforderungen erfüllt:

• Die Transformation einer Problembeschreibung in eine ausführbare Basislinie (Baseline).
• Das Management von multi-runden Selbstverbesserungen über heterogene Systemkomponenten hinweg (z. B. Prompts, Code, Konfigurationen, Regeln).
• Die Sicherstellung von Reproduzierbarkeit, Nachvollziehbarkeit (Traceability) und Evaluationsintegrität in Produktionsumgebungen, wo Systeme aus vielen interagierenden Komponenten bestehen.

Die Autoren argumentieren, dass das Fehlen einer standardisierten „Beobachten-Orientieren-Entscheiden-Agieren" (OODA)-Schleife für die Systemoptimierung die Stabilität und Zuverlässigkeit von automatisierten Verbesserungsworkflows in der Praxis einschränkt.

2. Methodik: Das EPOCH-Protokoll

EPOCH ist ein agentic Protokoll, das iterative Verbesserungen nicht als einzelnen Optimierer, sondern als strukturierten Prozess mit zwei Phasen und rollenbasierten Stadien organisiert.

A. Zwei-Phasen-Architektur

1. Phase I: Baseline Construction (Basislinien-Erstellung):

   • Transformiert eine Problemspezifikation in eine validierte, ausführbare Basislinie.
   • Rollen: Seed Planner (analysiert die Aufgabe und entwirft das System/Evaluierungsschnittstelle) und Baseline Executor (setzt das Design in lauffähigen Code um und generiert erste Metriken).
   • Falls eine validierte Basislinie bereits existiert, wird dieser Schritt auf eine Validierung reduziert.

2. Phase II: Multi-Round Self-Improvement (Iterative Selbstverbesserung):

   • Führt strukturierte Runden durch, um das System schrittweise zu verbessern.
   • Rollen:
     • Orchestrator: Verwaltet den Kontrollfluss, Budgets und Übergänge zwischen akzeptierten Zuständen.
     • Investigator: Analysiert das aktuelle System und generiert Hypothesen für Verbesserungen (unter Einhaltung von Constraints, z. B. Trennung von Trainings- und Evaluierungsdaten).
     • Executor: Implementiert die vorgeschlagenen Änderungen (z. B. Prompt-Änderungen, Hyperparameter-Tuning, Code-Refactoring).
     • Reviewer: Bewertet den Kandidatenzustand über eine standardisierte Schnittstelle und entscheidet über die Annahme oder Ablehnung.

B. Kernprinzipien

• Trennung von Hypothesenbildung und Evaluation: Der Agent, der eine Änderung vorschlägt oder implementiert, ist nicht derselbe, der sie bewertet. Dies verhindert Overfitting und Datenlecks.
• Canonical Command Interfaces: Alle Ausführungen nutzen standardisierte Schnittstellen, um „Evaluation Drift" (Veränderungen der Evaluierungsmethodik über die Zeit) zu vermeiden.
• Round-Level Tracking: Jede Runde wird als strukturierte Einheit mit Metriken, Delta-Änderungen und Entscheidungsgründen protokolliert. Dies ermöglicht eine vollständige Rekonstruktion der Optimierungshistorie.

3. Hauptbeiträge

• EPOCH-Protokoll: Ein agentic Protokoll, das Problemspezifikationen in ausführbare Basislinien umwandelt und multi-runde Selbstoptimierung über heterogene Modalitäten hinweg verwaltet.
• Zwei-Phasen-Orchestrierung: Eine Trennung zwischen der Etablierung einer Basislinie und der iterativen Verbesserung, sowie eine Dekomposition jeder Runde in getrennte Phasen für Planung, Implementierung und Evaluation.
• Einheitliche Abstraktion: Ein Framework für industrietaugliche Workflows mit standardisierten Schnittstellen und Nachverfolgbarkeit von Systemänderungen.
• Empirische Validierung: Demonstration des Protokolls in vier unterschiedlichen Szenarien (Prompt-Tuning, Hyperparameter-Tuning, regelbasierte Optimierung, Code-Verbesserung).

4. Ergebnisse (Empirische Evaluation)

Die Autoren evaluierten EPOCH in vier verschiedenen Aufgaben, wobei das zugrundeliegende Protokoll identisch blieb:

1. Code-Verbesserung (Fibonacci-Rechner):

   • Das System optimierte einen Fibonacci-Algorithmus unter einem Zeitbudget.
   • Ergebnis: EPOCH führte zunächst eine Korrektheitsprüfung durch (Bestehen aller Tests), wechselte dann automatisch zur Performance-Optimierung (von O(n) zu logarithmischer Rekursion und Nutzung von GMP-Bibliotheken) und terminierte selbstständig, wenn keine weiteren signifikanten Gewinne mehr möglich waren.

2. Hyperparameter-Tuning (MNIST Klassifikation):

   • Anpassung von Optimierern und Lernraten bei einem mobilen CNN.
   • Ergebnis: Das Protokoll zeigte strikte Trennung von Trainings- und Evaluierungsdaten. Es akzeptierte Verbesserungen (z. B. Wechsel zu AdamW), lehnte jedoch instabile Änderungen ab und nutzte Retry-Mechanismen (z. B. Wechsel zu SGD), um die beste Validierungsleistung zu erreichen, ohne Overfitting zu erzeugen.

3. Prompt-Tuning (SST-2 Sentiment-Analyse):

   • Optimierung von Prompts für ein festes LLM.
   • Ergebnis: Durch strikte Trennung von Trainings- und Evaluierungsdaten und Leckage-Checks gelang es, die Genauigkeit auf 100% zu steigern, ohne Evaluierungsdaten in den Prompt zu integrieren. Das System terminierte frühzeitig, als das Ziel erreicht war.

4. Regelbasierte Optimierung (Iris-Klassifikation):

   • Verfeinerung manueller Entscheidungsregeln.
   • Ergebnis: Das System verfeinerte Regeln bis zur perfekten Evaluierungsleistung. Weitere, spezifischere Anpassungen, die nur den Trainingsdatensatz verbesserten, wurden abgelehnt, um Overfitting zu vermeiden.

Gemeinsame Erkenntnisse:

• EPOCH wandelt Optimierung in eine Folge expliziter Zustandsübergänge um.
• Das Protokoll unterstützt Ablehnungen und Wiederholungen (Retries), ohne die Gesamtstruktur zu brechen.
• Es ermöglicht eine selbstständige Terminierung bei abnehmenden Grenzerträgen.

5. Bedeutung und Ausblick

Das Paper zeigt, dass eine protokollbasierte Orchestrierung heterogene Optimierungsworkflows (Code, Prompts, Regeln, Hyperparameter) koordinieren kann, ohne die Stabilität, Reproduzierbarkeit oder Evaluationsintegrität zu gefährden.

• Praktische Relevanz: Für Produktionsumgebungen ist EPOCH entscheidend, da es sicherstellt, dass iterative Verbesserungen auditierbar, nachvollziehbar und sicher in bestehende Workflows integrierbar sind.
• Zukunftsaussichten: Die Autoren sehen Potenzial in der Erweiterung von EPOCH von der Optimierung einzelner Artefakte hin zur Koordinierung multi-agentischer Systeme in komplexen Produktionsumgebungen (z. B. gleichzeitige Optimierung von Trainingspipelines, Inference-Strategien und Monitoring).

Zusammenfassend bietet EPOCH nicht einen neuen, spezifischen Optimierer, sondern eine Ingenieur-Infrastruktur, die den Prozess der autonomen Systemverbesserung standardisiert und industrialisierbar macht.